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

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.

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.

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.

The key performance issue with Cybran build bots is rather simple - unit count. Every one of those drones is a unit - and they are being created, and destroyed, at a rather fantastic pace. This has two long term side effects - each drone creates a new entity (unit) which has to be initialized just like any other unit - and when it's finished a task - it is destroyed. This process, of itself, is not very hard on the CPU except for the intangible effects of garbage collection.

The garbage collection process of SCFA can, by the time a game is more than 30 minutes old, consume almost 20%, or more, of all the clock cycles available to the SIM. Why ? Because the creation of new units, and new tables and variables in the code are too intensive - and the memory used must be reclaimed - only to be used again - in very quick succession.

The largest of all memory allocations in SCFA is the creation of a new unit. Anyone who has ever examined a blueprint for any unit knows just how many variables are involved - and that is the problem in a nutshell. If you reduce the creation of drones down to a modest level, you minimize this problem quite a bit. Now - in the end - it becomes a simple matter of aesthetic versus performance.

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.

@Broker You are correct -it's the Assist order you want, it works on ground, causing the air units to swirl around the point randomly, engaging units in the same fashion as patrol.

It could also be addressed by reducing the AOE of the bomb.

Being that the difference is one tick - the distance involved would have to be the distance the ACU can travel in a single tick. Assuming he has a nominal speed of 3, this would be a distance of 3 ogrids.

I would confirm this entire process by logging what the bomb is actually impacting with - is the bomb impacting the shield, the unit, or the ground ? And following thru the process to see what the damage is being applied against.

Aside from some general errors - the likely cause is right there at the bottom - SND and XACT. These errors are generated by your sound hardware being set to surround mode instead of stereo. Surround will cause the game to crash randomly, sometimes early sometimes late.

While you may have set your hardware to stereo, Microsoft has some virtual surround settings they bury in there - and I'll bet those might still be turned on (they have a nasty habit of turning those things back on when they do updates - and they don't tell you).

LOUD is specifically oriented on large maps, large unit counts and play against the AI. FAF has always been essentially oriented on smaller maps with lower unit counts aimed primarily at PvP play.

It's called the 'Guard' command.

This looks like a wonderful effort.

@kalethequick Ah shucks - I was just trying to add some meat to the conversation.

Normal AA missiles, in RL and in-game, are not AOE. I mean - yes - they explode - but we're talking about an AOE radius large enough to impact other nearby aircraft - which is a very large difference. There's a good reason that flak style AA weapons are still in use today - along with SAM - and there are excellent reasons why aircraft are generally NOT equipped with flak style weapons for A2A combat, but instead have A2A missiles or simple guns/cannon. (Good thing no one has mentioned enabling 'damage friendly' for flak weapons yet).

Flak weapons are, by definition, considerably simpler, more robust, easier to operate, cheaper - but decidedly less accurate, than SAM - and more well suited to area denial. This makes them ideal for cluster formations (read: gunships) and other low level air threats.

Speaking directly to the original topic: Air units are simply too plentiful and easily replaced - no one thinks about using them carefully.

Perhaps a T3 flak (rather than SAM) would be an idea. I can't think of any real world analogy to an airborne AOE platform, but there are certainly many ground based ones.

We have many maps that have resource densities just a high as many typical maps used in FAF. In fact, many of our users will sometimes bring over their favorite maps and utilize them with LOUD. While philosophically, we do see things differently, being the Supreme Commander, and having to make those decisions, is what it's all about. Certainly, the layout of a map can impact the value of some of those decisions.