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.

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.

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.

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.

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.

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.

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.

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.

Sorian is most important historically for one simple reason - he demonstrated that much more was possible within the existing framework. This didn't happen overnight, and honestly, he moved on long before he achieved any kind of nirvana, but he raised the bar, and inspired others (myself included) to push on.

Having said that, the version of Sorian that is included with FAF has been edited six ways from tomorrow, not only to adapt to the gameplay changes introduced by FAF (like overcharge), but by well meaning types that, frankly, had little clue about what they were doing. It's only been over the last 3+ years that any serious attempt to move beyond Sorian, or fix some of the long standing issues with Sorian, has been addressed - and that's, at last, something to look forward to.

Bandwidth requirements should be very low - especially in the original IP implementation of the game. I can't speak for how much additional traffic FAF and it's ICE adapter would add, but I imagine it's possibly much more than the game itself.
The original game needed a very tiny amount of bandwidth PER player. I assume that the same still holds true - the number of players being a big factor in the amount required, along with the needs of the chat client, and all the housekeeping data that FAF might require for the ICE adapter and such.

I hope that's not the case, as that has a lot more ramifications than just DPS - especially if AOE radius hasn't been also substantially reduced. Firing Randomness is something that's handled by the engine, not the LUA code - so it would have to be a blueprint mod to adjust them in any global fashion. Either way - the value should show on the Unit data panel for both types of randomness.

As you rightly point out, beam weapons are unaffected by this value - but there is a field you should examine closely - UseFiringSolutionInsteadOfAimBone. This may completely bypass randomness since the aim bone is removed from the calculation entirely.

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.

These maps are a large step forward in visual appearance - and sure, that comes with a cost - but it's a positive for the entire game.

It's too bad that the code cannot or does not inform the user(s) about what is going on, but surely that's where the answer lies - not in forcing the map to compensate for shortcomings in the loading procedure. It has to be a much easier task to address than creating some additional layer of checking and custom code work on the part of the map-maker which is not enforced in the map editor so that every map would have the proper indication (not to mention the trove of maps that already exists).

It might be something to consider - we have this warning when we are out of mass or energy - perhaps there should be a similar warning when we are wasting mass and/or energy - as this is a common situation for someone who's having trouble managing their eco.

It is indeed heavily biased by the economy developed, and the value of what you kill - killing an ACU is worth a great deal of score. Kills aside, almost 2/3 of the score is simply mass and energy collected - including reclaim.

LOUD, and NOMADS, like FAF - just sit on top of the C-engine thru the API provided.

How did the T4 bomber reach your ACU ? If the AI could reach your ACU with a T4 bomber then the problem is not the AI's.

And check the 'spatial sound' tab - that needs to be turned off.

Why aren't the flak and AA systems found on the naval vessels similar to those found in the land units ?

It seems rather fundamental to grasping the use of, and balancing of - the entire class. There's no validity in supporting AA weaponry that's better - either in damage or range - than what you might find either in a mobile unit or a static emplacement. They should be almost identical in capability.