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.
Best posts made by Sprouto
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.
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).
Water depth is one of the factors that is involved here, but the effect is mostly related to AOE effects. A lot of weapons, strat bombs, battleship main guns, etc - all have great AOE range - and it's perfectly normal, above ground. However, the game mechanics don't know the difference, so these AOE effects reach down below the waves, to full effect.
For shallow waters, these are perfectly understandable, as many units are quite tall, and often, the water just isn't that deep - but - when we talk of submarines, the issue is one of their standard depth, which is specified in each submarines blueprint, and in most cases that depth is only 2 - which is insufficient to protect them from these surface-based AOE effects.
The correction, is a combination of things - first, make the submarine depth a bit greater, and second - introduce a reduction to AOE range when normal projectiles impact water.
@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.
@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 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.
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'.
Latest posts made by Sprouto
Yes - those filled with SND/XACT error messages - caused by surround sound.
I haven't looked at your work in some time - you've made great progress from the early days - that's for sure.
A badly behaved mod, or a new feature, that is getting stuck in a loop of some kind.
It's not practical to do so. The number of 'special' conditions that would need to be coded, to make the AI behave coherently, with all the possible permutations of unit restrictions, would be staggering to write - and create a monumental sucking noise on the performance.
DPS as a single metric is often the only one considered in most discussions - but you are so right - balance is a MUCH wider subject .
You have to look at the resource investment (not just mass) to arrive at, not only that DPS, but the associated HP and mobility factors that go with it. Range and AOE should also represent major modifiers to DPS cost - it takes more resources to fashion a longer ranged weapon - and more again to have a weapon that can affect an area - the bigger the area - the more resource costly that should be (especially with the linear AOE in this game).
Platform matters - and basic motivation should affect valuations - hovercraft for example, have versatility - but acceleration and inertial issues. Submersible units would require substantial reinforcement over a non-submersible unit, etc. Tanks have a mobility advantage over walkers in some circumstances, but are at a disadvantage in others - those are just some aspects to consider.
Having done that across a group of roughly comparable units - you need to examine those metrics - and put them in relation to other classes. For example, are air units performing better, or worse, in those respects - is this the fundamental reason that air dominates the game ? Are they getting a free pass in relation to everything else ?
You cannot boil it down to anecdotal observation, if the basis is not quantifiable - then neither will be the results.
@redx It's a measure of CPU saturation - and it starts with an individual's CPU - so while initially the problem is local to one user, it will eventually and usually quickly, result in apparent lag across the entire multiplayer session, as the others will end up waiting on the slow machine to catch up.
If it's your own units - yes - but it may be due to the AI, or other players. The game itself uses a queue to process orders - and that queue is processed at a finite rate. When hundreds of units are colliding - they're creating new orders to 'unbump' themselves - and your single order just gets swamped - and delayed.
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'.
If FAF had a penny for every time someone suggested shit like this, shit like this wouldn't get suggested anymore. But also, props to you for having the shittiest of shit suggestions
These kind of comments....says it all.