I think the intent is to demonstrate that the user owns a legal copy - and that intent is to clear their obligations - not the legal obligations of someone seeking to get around that. Of course it can be circumvented. So, technically - that's correct - it doesn't make YOU legally compliant, but it unbinds FAF from you in the legal sense by discharging their responsibility.

Rather than blaming the factory for the issue - you might wish to simply consider the scaling of naval units. There is a LOT of room to decrease the size, especially of the largest units - and I can say, having done this years ago in LOUD, ships rarely have issues leaving the yard now.

@Deribus Not sure - we've had the d3d_windowscursor command in-line at LOUD for more than a week now, but a couple of days ago, we had some new users showing up that continued to have the problem - using the absolutely latest drivers. The task manager services did the trick, which was good for the users - but the services restart themselves, and not too many users are comfortable with altering core services.

I sincerely hope that this problem gets a proper NVidia resolution, sooner than later, as it's driving people off of FA entirely, especially new users that already have to deal with surround sound issues.

We addressed this issue several years ago in LOUD - it was a rather simple fix - and it hasn't made the HARMS, or other T3 torpedo defense units, awesome or unkillable. What it has done is properly framed the submarine, torpedo and anti-torpedo units in a way that makes them viable, and a meaningful portion of the naval game. If you don't properly compose your fleets with the appropriate units, you should expect to be defeated.

It's an unintended side-effect of AOE which can easily be addressed either by altering the elevation value of the subs (which won't work on maps that have ultra-shallow water) or by having AOE range reduced whenever such projectiles impact water (which is a natural behavior).

@vanifica said in Questions about performance:

I would be totally into this. I guess I assumed LOUD worked by graphical changes, but I never tested it extensively since it didn't have an online client as far as I could tell.

They claim 5000 units without any simspeed issues IIRC. That does imply there's some "magic bullet" somewhere in the code they figured out?

This has long been a myth - LOUD never gained any real performance boost from suppression of graphics. We did toy with this several years ago, and it stuck for some reason. There are certainly some graphical things we simplified or tied to the SIM speed, but over time, most of the pretty was returned to normal.

As Jip rightly points out - there was never a 'magic bullet' - just a lot of patient work going thru almost the entire code base, implementing the techniques that Jip is encouraging FAF to adopt now. The gains are real, but the work is extensive, but not difficult.

@deribus said in Stronger ASF:

This is the approach LOUD takes.

That's not true - ASF stats are essentially identical except in their relative cost/firepower relationship to other units.

Map size has little to do with it - the real issue draws in two aspects - unit count (which is directly responsible for the SIM slowing down) and traffic issues (unit collisions).

While a smaller map does reduce the memory requirement a bit, it has no impact beyond that. Unit count (and the complexity of those units) has long been recognized as the largest influence on performance, and memory consumption - and this 'unresponsiveness' that you're seeing is related to that.

It can impact players at different times, as it's really a measure of CPU 'saturation' - and if the problem is severe enough, it can impact multiplayer games for all players.

Unit collisions play a very big role in this - so anytime you have a situation with a large number of those (like clumps of engineers all crowding around a factory), or traffic jams caused by really tight and complex terrain, you're going to see a very big upswing in CPU activity - which manifests as 'unresponsiveness'.

Currently 62.

You can experiment with the FiringRandomness values directly - in game - via Shift F6. This will give you access to the units data - and if you expand the appropriate weapon, you can directly adjust the randomness values and see them take effect.

This tool is useful for many values (but not all) and FiringRandomness is one that allows active changes.

Over short ranges, it will be hard to discern randomness at work - so you may need some rather significant values to really see it - but for long range weapons, it's very clear.

The expectations are always what get you.

Aside from the basic sound configuration - which it appears you have done - most motherboard manufacturers install an applet (usually found down in the system tray - near the time - that allows additional audio controls. These applications are typically the cause of the problem - uninstall them if you don't absolutely need them.

It is non-functional as far as I'm aware - at least with LOUD - however, I can attest, than in the days of the stock AI and Sorian - this command did essentially brain-dead the AI. Of course, you might say the vanilla AI, sometimes even with Sorian, was already that way.

Immediate desyncs, as soon as the game has started, are usually an indication of a map related issue.

Would it not be easier to just prohibit the UI from displaying Dummy Weapons in the rollover ?

The Fatboy II, at least in the incarnations I have seen, looks 'toyish' as do many SC2 units - and, just as most mod T4's - really overpowering.

The Wyvern Fatboy, likewise, in it's native form, is also largely overpowering.

Do keep in mind, it's a factory, not a super-hardened main battle tank. What you might wish to advocate for is a non-factory version of the Fatboy - with compensations based on the removal of the factory. The Wyvern Battlepack did something along this line, introducing the 'Wyvern Fatboy', which essentially removed the factory - and replaced it with a sizable artillery calibre weapon - but you get the idea.

A desync is, in every case, a situation where the data on one machine, is different than the data on another. This is invariably caused by different code producing a different result between one or more machines. The nature of the desync can tell you something about the cause.

Immediate desync messages are most often caused by the map being different.

In progress desyncs are most often caused by a mod, or other user addon, that has altered the game data in some fashion. These would be mods that change units, or gameplay or balance factors - rather than those which simply modify the UI.

In only the rarest of cases does an internet hiccup cause a data corruption, since the nature of the internet involves preventing pretty much exactly that from happening. I can likely count, on one hand, the number of times I've seen anything like that happening, it's far more likely you'd have a crash to desktop, than that result.

Other than the time taken to form up, formations are only as slow as their slowest unit.

In order to effect a movement bonus, the formation code would need to handle applying, and removing, buffs - to all the units involved - a costly process, especially in light of how often the formation code is called.

Yes - those filled with SND/XACT error messages - caused by surround sound.