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

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

I do believe that the original reason for removing the ability for T1 transports to carry the ACU was to curb exactly the kind of behavior that's being suggested. While it may seem like it would be interesting, it really encouraged a death-wish behavior that brought a spectacular number of games to a rather early and abrupt end.

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.

Safety from surface guns is the entire reason for submarines. That's why torpedoes were developed. The idea that you can sink submarines, under the water, with any kind of surface gun is bizarre, and makes the entire class pointless. If you support that kind of thinking, simply removed the subs from the game - and just have 'water' units - and go the final yard towards simplicity.

I'd like to dispel some of the popular myths about LOUD - and then discuss some of what's been mentioned here.

Firstly, while we have indeed 'flattened' some starting areas on maps, to permit LOUD to use his preset base layouts, we have not, in general, done any flattening on maps as a whole. We have certainly upscaled some smaller maps to 20k and 40k, and that has certainly smoothed the inclines in some places, but it was not a goal to 'flatten' any maps - rather - knowing what we know about AI, and map markers, we've remarked those maps we distribute thru LOUD to take advantage of that knowledge, and as such, they perform better, and the AI comprehends them so.

With regards to graphics and sound - yes - we have indeed suppressed many very minor things, and, in the past, we had entirely turned off certain effects such as contrails, or excessive particle effects, but, over the years, as we've found other places to gain, we've brought almost all of them back. As for sounds, yes - a great many ambient sounds have been turned off, but this is not for performance, but it pays dividends in memory consumption - which indirectly aids in performance, but moreso in LOUD's ability to support games with higher unit counts. In fact, LOUD has built a dynamic system which leaves all the effects functions in play until the SIM drops below 0, at which point they begin turning down or off entirely if the speed drops too low.

A great deal of LOUD's performance comes from an understanding of memory management, garbage collection, and methods to reduce both, and this has resulted in the rewriting of many core functions - and as noted above - 'declassing' which, as applied to what was noted above, means that Air units don't carry around baggage from other unit classes.

I'm not sure what the 'wrecks' comment is all about - LOUD has had naval wreckage for a long time, but again, similar to the effects, we decided on a dynamic system which will remove wrecks that are not reclaimed over time, resulting in dramatically improved entity count and significantly better memory management over the course of long games.

Now - all of this work in LOUD is pointed specifically at the long and very long games, on very large maps, with very high unit counts, and as such, the AI is not aimed at the FAF demographic. That it doesn't show well on 5k and 10k maps is intentional, and certain 'set piece' 20k maps, like Setons, offer limited tactical options that can make it rather easy to defeat a 1.0x LOUD, but that is why we continue to work on it - and having someone to converse with AI issues, after essentially working alone for most of the last decade is, at last, refreshing.

Uveso has advanced the AI for FAF a long way from it's crippled Sorian state, and along the way, crossed many of the same bridges as we had to cross in LOUD, especially in core areas like understanding the shortcomings of the default functions that support the AI, and taking advantage of some of the unused features available. I'm sure there will be more to come, and the opportunities to increase the performance (if it's even a concern in most FAF games) is there for the taking.

Both situations - damage from surface detonations and getting decent sonar from aircraft, are relatively easy fixes - simply limit AOE range when a projectile hits water, and you'll get a rather realistic simulation of the natural mechanic without taking ground fire completely out of the picture - in about 3 lines of code.

As for getting sonar from aircraft - it's actually already there - but - due to the elevation of the aircraft that have it - and the range of the sonar they carry - it actually doesn't penetrate a whole lot of water area. Either the sonar range would have to be adjusted for the elevation, or the sonar would have to emit from an invisible bone that hangs well below the aircraft. The proper solution would be to create an intel entity which drops from the aircraft, every few seconds, and if it lands in water, becomes a short term sonar buoy. The code for that too, is already in the game - it's used in the Aeon Eye of Rhianne, which creates a vision entity. This would be an adaptation of that.

The length of the pause is primarily determined by the number of units that have to be 'transferred' between players. This is a pretty costly process and can bring the SIM to a nearly total standstill. It might be worth considering inserting a global 'pause' - visible to all players - that doesn't unpause until all the work is complete.

There is a careful balance between the number of markers used - and the overall performance of the map when being played with AI.

In general terms, less markers is better - BUT - there is a maximum distance that an AI platoon will 'look' when it wants to path from one point to another - and this is different, for air, land and naval.

Air platoons will look for a start or end marker within about 250 ogrids ( about 5k ) of themselves or the goal. Likewise, Naval platoons will look for a start of end marker within about 200 ogrids ( about 4k ). Amphibious and Land platoons have a somewhat shorter seeking range of about 150 ogrids ( about 3k ).

If a platoon cannot find a start or end marker to get from where it is - to where it wants to go - pathfinding will often just fail - and the platoon can sometimes just go inert for the rest of the game.

Air markers have the least restriction, and for the best results, a default mapping of Air Markers that allows air platoons to navigate to all the 'Threat Blocks' on the map, is the most efficient. You can see the layout of these 'blocks' by turning on the AI Threat Grid in the tools section of the Ozonex map editor.

Essentially - you'll have a 16 x 16 grid that covers the entire map - which is the same as how the AI monitors threat. This kind of grid will allow an AI that takes advantage of threat measurements to 'thread the needle' and reach intended targets as safely as possible. You can make a default grid like this, for each map size, and simply load it - this saves you a lot of work putting down markers and linking them together.

Likewise, Naval markers are relatively free of restriction - but one - don't get too close to shore. Naval platoons are usually larger in size than most, and since a platoon will try to travel directly to a waypoint - if the point is too close to land, the formation runs the risk of getting 'hung up' - either on the shoreline - or on shallow water. Again, AI markers for movement do not need to be very specific - they only need to be general. The AI platoons will navigate themselves to the nearest marker to start movement, and navigate from the last marker in their path, to their intended goal.

Amphibious markers are REQUIRED. They are used mostly by engineers - and in this respect, they are somewhat unrestricted - but they will also be used by purely amphibious or hover platoons used by the AI. Be careful though - cliffs and tight terrain cause all kinds of path problems - and placing markers too close to cliff edges or river sides can cause issues. Sometimes, a platoon will see such a marker as the one closest to their goal - even though it's not physically capable of reaching it's goal - from a marker like that.

Land movement markers are the most work of all the 4 types. Since the distancing requirements are narrower ( to allow for finer movement paths ) you'll generally need more of them. Again - movement markers are general - and don't need to be too specific - except for tight terrain.

While platoons will 'form fit' themselves to pass thru tight terrain, the problems caused by this type of terrain are not solved by putting more markers on a map. In fact, especially for land platoons, too many markers of a short distance cause increasing movement delays - because - unlike human platoons - an AI platoon, that's in formation, will want to re-form at every movement marker. This is a shortcoming of the AI functions imbedded in the game - so often AI designers will forgo formation movement in favor of either really small platoons, or larger ones that just 'swarm' from point A to point B.

As cautioned before - be very careful about how close you put markers to terrain obstacles - the further away - the better. This tends to not only save a lot of extra processing by the AI, in pathfinding, but it will minimize the issues I mentioned previously about platoons thinking that crowding around the top of a cliff is the best way to get to movement marker that's too close to them, down in the valley.

Perhaps the big difference in build power is related to the ACU teleporting directly into the world, whereas the SACU come thru a gate, and don't have to undergo what must be a rather difficult and expensive process to reach the planet. Dunno really - just a thought to give some credence to the difference.

There is some difference - mostly related to the number of weapons, or the amount and type of intel generated, throw in the additional loads of any animations or blinking lights (which of themselves aren't a problem - but the SIM is responsible for tracking and initiating all those things) and movement, you get a picture of why this is not just a simple subject. From a simple memory standpoint - the overhead of a structure and a mobile unit are fairly similar. The impact on performance lies primarily there. Adjusting the unit cap impact of them won't alter the performance curve in any way - it will simply move the unit cap goalpost around a bit.

Wrecks are a little bit less of an issue, by definition they are very simple - but even so - the number of wrecks, and to a lesser degree, props - can add significantly to the processing overhead.

ALL units impact performance - buildings, units, wrecks.

We have an unlimited unit cap in LOUD - and while in one perspective that's nice to have, it's not a practical limit. Even on the best of days - with a very streamlined codebase like LOUD, on the fastest of machines, the practical upper limit, before you start seeing unit count induced side-effects, like severe UI lag, and SIM degradation - is about 5 thousand units - in total. We do, on rare instances, see games with 10k or more, but those are rare indeed - and usually involve 1 v 1 situations.

I hear what you say about unit cap being given the same kind of real estate, on the UI, as the other two resources - and I offer a suggestion here, that we've had in LOUD for several years now, unit cap growth.

It is possible to turn unit cap into another resource, one that can be managed by the player, or offered up as a reward for things like achieving veteran status. For example, in LOUD, we have various structural enhancements that will lower the unit cap cost of certain things like T2 and T3 Pgens, T3 shields, etc - giving the player the option to 'invest' in more unit cap with his resource base. Also, each level of veterancy grants additional unit cap, encouraging a certain kind of gameplay that's less wasteful - and it's permanent (unlike the structural enhancements). And lastly, that poor servant of the ACU - the SACU, gains additional value as a total replacement for your horde of lower level engineers by actually lowering your unit cap usage.

Long and short - it's possible to make some changes that make unit cap a flexible part of the 'Supreme Commander' experience and still have some kind of lid on potential performance issues.

This is more likely a case of the aiming bone and the weapon bone not being aligned - so the weapon always misses. This can be solved by the weapon value UseFiringSolutionInsteadofAimBone = true.

Sure - give the engineers more HP - in fact make them as tough as a light tank. However, that should cost additional mass - almost as much as the light tank - and - it should slow the engineer down. Ideally - make it an enhancement for your engineer - 'armor package' - with those results. Best of both worlds.

Energy - as a resource, is one of the more flexible ideas in the SC world. It's mutable - which it is not in Starcraft - you cannot convert energy to mass - and technically, a power plant in SC is converting mass to energy - but that's another subject. Mass, therefore, is pretty much the only resource in SC (hydrocarbons excepted).

I've always seen energy usage while constructing being more a factor of 'complexity' - air units don't use much mass due to the way they are constructed - but - require super high detailed work - something a tank, by comparison, doesn't require much of. Likewise, naval units are more brute force and ignorance than a tank, and generally require a lot more mass than a tank, but are, if anything, a bit less complex to construct.

Anyhow - that's my take on it.

Both situations - damage from surface detonations and getting decent sonar from aircraft, are relatively easy fixes - simply limit AOE range when a projectile hits water, and you'll get a rather realistic simulation of the natural mechanic without taking ground fire completely out of the picture - in about 3 lines of code.

As for getting sonar from aircraft - it's actually already there - but - due to the elevation of the aircraft that have it - and the range of the sonar they carry - it actually doesn't penetrate a whole lot of water area. Either the sonar range would have to be adjusted for the elevation, or the sonar would have to emit from an invisible bone that hangs well below the aircraft. The proper solution would be to create an intel entity which drops from the aircraft, every few seconds, and if it lands in water, becomes a short term sonar buoy. The code for that too, is already in the game - it's used in the Aeon Eye of Rhianne, which creates a vision entity. This would be an adaptation of that.

This doesn't look like a typical audio problem, at least from the log file - so the FAQ may not be of too much aid in this case. I would suggest disabling the audio as mentioned in the post above - and seeing if this resolves the crashing issue. Then move forward from there.

It's highly map dependent - that's for sure - a great many water maps have very shallow water which contributes to the issue as much as the AOE and depth of underwater units themselves. That's why I suggested simply reducing the AOE range on water impacts - this allows the ability to continue to exist - but moderates in a way that makes water depth a more important factor.

I don't, offhand, recall the AOE on the big battleship guns - but it's AOE radius is 4, or more, in some cases - that's really a great deal.

I would counter that by saying we see anything underwater being taken out with ground fire - so it's not exclusively the domain of submarines - which would be a natural conclusion. The only time we don't see that is with water depths greater than the AOE radius (and then some since those units are often a couple of units high themselves).

The AOE radius is truly the culprit - and no real analysis has ever been done to associate the range of AOE with the accuracy of a weapon, and that's especially true of all the large battleships - and - more important - just about every modded unit that's been introduced. The proliferation of AOE - on even the smallest units, is another subject though.