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.

@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.

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.

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.

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 thorough design, with solid OOP principles, and the simple fact that almost every feature of the game is exposed to modification, makes it the most extensible code I've ever personally had the pleasure to work with. It's almost 100% true - if you can dream it - you can do it. That's unique and that's what keeps me at it.

And the sheer size of many of the vessels.

The chance to hit is not determined by the size of the hitbox - but by the accuracy and tolerance values on the firing weapon. Again, the faction has zero to do with this - which I note you're not bringing up any more.

The only chance to 'dodge' comes from the ability to move out of that targeting solution - something that's more relative to the velocity of the projectile, and not the marginal velocity of the target - hitbox size can have a very tiny impact on that, provided the projectile is slow, and the ship moves very quickly (such as the UEF Cooper) - but that's about the only place that's going to be an issue.

In the real world, yes - the size of the vessel might have an impact on the ability to be targeted - but not in SCFA. I should point out that the hitbox - and the footprint - are two completely distinct and different things. Many of the ships have footprints much larger than the hitbox. This is abundantly true of most T2, and almost all the T3 units.

I've always pictured the GPG employees deciding upon things like 'game-enders' - and getting stumped - and just pulling numbers like '10K Mass and 1M Energy' because they couldn't find, or didn't have the time, to come up with a real answer.

@e33144211332424 said in Adjust the build skirt of naval factories:

I wouldn't be too sure about this being so clean of a fix considering it will mean a need to rebalance all the navy units to compensate for their additional nimbleness. RIP cybran t2 navy.

It would have no impact whatsoever on 'nimbleness'. Performance characteristics would remain unchanged - turn rates et al. Cybran ships don't have any mobility performance benefits over other factions - certainly not related to footprint size - and not in the unit blueprints either.

As for the fantasy ? That's entirely in one's own mind. LOUD has reduced almost all naval units, except the smallest, by upto 30%, and not one comment ever mentioned a suspension of disbelief - but, while I'm sure that's an issue for some - it's not a tangible issue.

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.

Why does it not have a limit ? Is it magical ?

@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.

This mod also has some invasive hooks to the UI and the game mechanics that make it questionable.

It is a valid option, but it's not super widespread - and it is a valid option in certain cases. Combined with the targeting interval - it can be a performance issue - especially if the priority list is long ( each and every category is checked every interval so it multiplies very quickly ).

It IS an NVidia issue. I've had this issue since 2017 - and if you go back to AMD, it goes away. I've seen it, since that time, on 3 different NVidia cards.