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.

There is a flaw in the targeting process, where an empty launcher will remain 'locked' on the target - which prevents other launchers, which are loaded, from firing at that missile - it's called the 'shooter cap'.

What needs to happen, is that shortly after firing (even when there are additional rounds in the launcher), the launcher needs to go 'offline', and drop it's target - which will allow other launchers to engage the missile. Now, this is how the launchers are meant to work, and most of the time they do this, but - if there are a lot of launchers involved, and the primary happens to go empty - there's little to no chance that the target will drop, in time, for another launcher to perform an intercept.

This is the same mechanic that keeps all your SMD's from firing at the same inbound missile - so it's not something to be disabled.

@Laso That's essentially how M28 (and many previous AI as well) performs. It has information it shouldn't, and does things with units that you would find it either impossible or incredibly difficult to do. It's not, and doesn't claim to be, a level playing field.

There have been several attempts over the last decade+, to loosen the source code from it's rights holder. All have been denied or rebuffed, even with significant monetary offers. The game still provides a small, but steady, revenue stream, so it's still viewed as a productive asset. While that situation is most certainly declining, year over year, I don't imagine that any offer south of $100k is going to get a whole lot of notice.

I'd like to hope that I'm wrong, and sometime soon - but that's how it stands.

Interesting - I'll have to check if we even use SinkLower in our units.

LayerChangeOffsetHeight can alter which weapons will fire, and when they are seen as 'above water' - so quite likely this value exposes those bones that would otherwise be targetable. I've often worked this value carefully (especially with multi-weapon units) in order to get a better response to weapons firing when actually out of the water - so yes, it's a finnicky thing.

There's nothing quite normal about it - and it's a relatively easy fix.

In this circumstance, the spider's weapon is 'above water' and is allowed to fire. The body, however, is likely on the 'Seabed' layer - and as a result, your weapon is not likely allowed to target that layer.

Weapons aim at 'target bones', and in many cases, a unit will only have one, which often defaults to the 'root' bone (often around the base of the unit). Large units, like the spiderbot, should have multiple target bones specified - and ideally, there should be one up near the top of the unit, which would be targetable.

In order to check this, refer to the blueprint of both your unit (to see if it's allowed to target 'Seabed' targets - but is restricted to 'AboveWater' targets only) and the spiderbot, to insure that it has a targeting bone that would be above water when the weapon it has is.

It's not 'micro' at all - it's just lax coding.

The kind of crash you are describing is more consistent with something doing something illegal, rather than an out of memory error. Out of memory almost always will just dump you out to the desktop.

@Sainse Technically - the game can use up to 4GB of memory - but - due to the way that lua handles memory, the limit is about half of that. At some point, the number of units becomes the main reason that memory usage grows to that point (around 2GB) - and it will then simply crash to desktop.

The size of the map, and the number of units in the game, and to a lesser degree, the number of wrecks and props, contribute to the overall memory usage, for the main part. After that, the AI (and the number of them involved) plays the largest role in how memory is used up.

The game simply doesn't have the memory to support games that size - even if the performance could handle it.

There are a lot of other factors that can contribute to the 'threat' of a unit, beyond DPS, namely range, mobility & protection (HP) - all have a part to play in how 'threatening' a unit can be - and a discussion of those is likely beyond the scope of the question here. I'm not familiar with the contents of the FAF threat calculation, in as much as dovetailing threat to DPS was a big step forward when we introduced it in LOUD back in the day, so I was pleased to see that idea taken to heart some years later in FAF. It was abundantly clear, especially for AI (and the long standing issues with Sorian AI's in particular) that threat assessment, and understanding how it works internally, has a lot of follow-on impact on how any AI 'reads' a situation, and the map. It impacts almost every aspect of activity, pathfinding for example, and building position and selection, to name just two.