@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.
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.
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.
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.
It's very common for unspecified Windows updates to reset audio hardware and other settings. Recently (last 6 months or so) they've introduced a new option for psuedo-surround sound which is playing havoc with Forged Alliance. Best advice - goto your hardware manager and remove (disable) all the extra sound devices you don't use. Remember, many monitors have built-in audio capability these days, and as was pointed out above, a lot of headsets use 'virtual surround' drivers that have a lot to do with frequent crashes.
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.
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.
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.
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.
Game performance is largely dominated by the number of units in the game - NOT the map size. However, since larger maps are often flooded with mass points, this will accelerate unit count growth, and quickly bring the game to the SIM saturation point. For the vanilla game, this starts around 1000 units, in total, on typical machines. This is usually countered by restricting gameplay to smaller maps, with restricted unit counts, and a very small number of AI.
This is a MUCH more visual application of the effect - very nice.