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

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

Moses - I just want to throw my two cents in on this, since your last post speaks specifically to me and The LOUD Project.

Almost every issue you mention there is implemented in The LOUD Project, and without getting into details, gives much of the results you seem to be aiming for. This is, in particular, true of the air balance. Greatly reduced flight times does indeed bring the usefulness of airpads and carriers to the forefront - while putting a reasonable leash on the dominance that air can have on the total game. LOUD also impairs the movement speed of significantly damaged air units making having nearby refuel and repair even more valuable.

Having T3 level transports, with practical self-defense, and enough robustness to be usable, is likewise, an important factor.

Lastly, the cost/production relationship for air units, in general, is overly favorable, which compounds it's impact on the game.

On the subject of fixed teleportation, while LOUD does have this, it's something seldom used, the necessity being mostly supplanted by air transport on all but the largest maps. There's also some mechanical and UI issues that could use some love. However, logistically speaking, it makes total sense.

The naval subject is one that suffers mostly from a poor choice of nomenclature. As soon as you use the word 'battleship' - you conjure up a certain image of capability - and there's no question that Supcom doesn't have BB level ships - relatively speaking. They are considerably much less capable by comparison. Even the entry level frigate is not much more than a sloop, and this is more in keeping with it's ability in the game.

As to your earlier post about radar and it's general capability, that indeed would change the way the game plays, and add a richer level of complexity to the intel/counter-intel game. Of course, there's always hope for the future.

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.

This is definitely a sound configuration issue - the final message in that crashlog that refers to the XACT issue, confirms it.

That's a boatload of processing, and you're only talking about a handful of units.

Depth charges were the first method to deliver a significant amount of the explosive power anywhere where it might actually hurt the submarine. Anyone imagining that surface detonations, of any magnitude, would have any significant impact on a fully submerged submarine are just dreaming - and supporting it as a viable game mechanic is just twisted.

Sorian for vanilla is quite a bit different than the version in FAF. There have been a lot of hands on it, at various points over it's history in FAF, in attempts to 'improve' it and also to make it compatible with some of the gameplay changes in FAF (like Support factories). Some of those changes have impacted fundamental relationships between defense building versus other things.

Your mention of the template function being broken does however indicate that you have a deeper issue, that perhaps only your GAME.LOG can reveal.

Good summary. A lot really has to do with both the AI's intentions with naval expansions - and the map makers understanding of how the AI interacts with the markers.

Each AI can, and often does, have different parameters for WHEN to expand, and how far to expand. As a result, the experience can vary rather wildly.

The AI developers have recently been talking about some logic to better understand what kind of naval investment is necessary, depending upon just how big a map is - and what % of the map is actually water. The idea being that the AI becomes aware that no matter what the markers may indicate - this map just isn't viable for naval work - or it's so significant that it should work much harder on naval.

And please, post the entire log - the last 100 lines is insufficient. I still see one XACT error in there, which means something is sound related - but - there's simply not enough log file to confirm it.

If you are throwing XACT errors in your log - then you have a sound issue related to Surround Sound - and you will crash randomly in the game, and reliably when you exit it. Simple as that.

Be aware, despite having set your sound hardware to physical stereo - Microsoft recently introduced it's own 'virtual surround' sound, which, as is typical for Microsoft, they quietly enabled it for you. You need to find that - and turn that off as well.

As long as you keep showing XACT errors thru your entire log - this problem will most certainly persist.

It's primarily related to AOE weapons - the tighter you cluster the shields, the more potential effects you will get from AOE weapons. AOE weapons have proliferated over the years, especially in mod packs like Total Mayhem, where a very large percentage of the units have AOE damage.

Unit balance is an entirely different subject, there is no argument that there are some built-in differences. However - to draw a line between the output of MEX - and the ability to play the game - is misleading. As prominent members of this community, we have a responsibility to those who are not, to have open and informative debate, and avoid trying to reinforce any particular position.

I'm glad you mentioned the subject of reclaim, and the impact that it can have on aggressive play. This is a much more relevant issue and one that should get more attention.

The pace of tech, and the effectiveness of units, are not related other than without tech, higher tier units are going to appear later rather than sooner. The game is not just about the units themselves, but which units you select, and how and when you employ them. If you choose to divert your income into one path versus another, and it fails, the responsibility is yours, not the output of your mass extractor.

Agreed - I don't see any value to changing MEX output, but the reclaim % is another issue. At present, the incentive to turtle up (figuratively) and boost yourself with reclaimed units, is perhaps, overly powerful.

They don't. There is no relationship between the units themselves - and the output of MEX. The units are relative to each other - not the underlying economy. This is why the game can work on any map. You could even taken the absolute extreme, and have a map where each player gets only 1 - it won't be an interesting game - but it will work. Conversely, and I do think this was the point of the OP, you could absolutely glut a map with mass, and there would be no point in ever leaving your starting point until you exhaust or exceed what you can reach immediately.

Those two extreme examples point out rather clearly the true relationship between the availability of mass (regardless of how much they output) and - this is the key point - the tech pacing. It has no impact whatsoever on the speed of the game itself - but it does have a direct impact on just when more advanced units will begin to appear - and associating one with the other is disingenuous.

There certainly is room for a discussion about the impact such a change might have on game flow, but a change to mass output , in of itself, won't change the gameplay - the economy is a level playing field, no matter what is done to it.

Mass points are pretty much the ONLY reason to leave home (unless there are unreasonably large reclaim fields - but that's another topic) - so making them more valuable - relative to wreckage reclaim, is the key point. As the OP points out - the value of the reclaim, in most any battle, makes it completely worth fighting on your OWN turf - and NOT fighting anywhere else. That's a fundamental of the current gameplay dynamic, and I agree it's worthy of re-evaluation.

Well - it's a long road to drive thru if you don't have some coding background.

For index is a looping structure that will go from the top of the table allUnits - to the bottom - one at a time.

unit:GetBlueprint() is a function which retrieves the blueprint data for the unit - drilling down in the blueprint specifically thru the General table (a specific part of the blueprint data) and looking for variable UnitName

Every unit has multiple categories specified in it's blueprint which determine what kind of a unit it might be - in the case of your code, it's trying to find only COMMAND units - so only the ACU will be found like this.

Depending upon which veteran level the ACU is at, the code appears to be creating a variable called newName - which is comprised of some symbols (<, [ - with the players name sandwiched inbetween.

And that's about it.

The problem won't be found in the MSI software, but in the OS - Win10 device properties