Posts made by Sprouto

The kind of crash you are describing is more consistent with something doing something illegal, rather than an out of memory error. Out of memory almost always will just dump you out to the desktop.

@Sainse Technically - the game can use up to 4GB of memory - but - due to the way that lua handles memory, the limit is about half of that. At some point, the number of units becomes the main reason that memory usage grows to that point (around 2GB) - and it will then simply crash to desktop.

The size of the map, and the number of units in the game, and to a lesser degree, the number of wrecks and props, contribute to the overall memory usage, for the main part. After that, the AI (and the number of them involved) plays the largest role in how memory is used up.

The game simply doesn't have the memory to support games that size - even if the performance could handle it.

There are a lot of other factors that can contribute to the 'threat' of a unit, beyond DPS, namely range, mobility & protection (HP) - all have a part to play in how 'threatening' a unit can be - and a discussion of those is likely beyond the scope of the question here. I'm not familiar with the contents of the FAF threat calculation, in as much as dovetailing threat to DPS was a big step forward when we introduced it in LOUD back in the day, so I was pleased to see that idea taken to heart some years later in FAF. It was abundantly clear, especially for AI (and the long standing issues with Sorian AI's in particular) that threat assessment, and understanding how it works internally, has a lot of follow-on impact on how any AI 'reads' a situation, and the map. It impacts almost every aspect of activity, pathfinding for example, and building position and selection, to name just two.

The LOUD project has extensive work on threat values - and as you have already determined, modification of the blueprint values, at runtime, is the most accessible method of doing this. Your intent is aimed in the right direction - without meaningful, and accurate, threat values, no AI can make informed decisions based off of the data - and this is a long standing problem going back to the release of the game. No direction was provided, so many unit authors just dropped in values that made sense to them, and were not related to any particular capability of the units.

Since you have no surefire method of controlling the load order of mods, your blueprint changes are at the mercy of any other unit mods that may alter the values. As Maudlin identified, he sidestepped this issue by performing calculations similar to what you are proposing, but doing so on the fly, during the game. This gets around any question of the values in use, but it may have performance concerns - doing it during loading has no impact on the performance of the game itself.

DPS calculations are going to be an issue, as unit authors are not exactly consistent in how they arrive at the kind of damage output their units will put out. There are MANY combinations and control values that can impact the actual DPS calculation - it goes far beyond the 'RateOfFire' blueprint value, which many consider to be the 'be all and end all' of DPS calculations. It is not - and anyone who has done sufficient weapon 'rigging' can tell you the many pitfalls, in the blueprint values, that can lead to an erroneous DPS value.

One issue that is not addressable is the impact of unit enhancements on DPS - as the blueprint threat values, once set, are static for the duration.

The expectations are always what get you.

Aside from the basic sound configuration - which it appears you have done - most motherboard manufacturers install an applet (usually found down in the system tray - near the time - that allows additional audio controls. These applications are typically the cause of the problem - uninstall them if you don't absolutely need them.

It is non-functional as far as I'm aware - at least with LOUD - however, I can attest, than in the days of the stock AI and Sorian - this command did essentially brain-dead the AI. Of course, you might say the vanilla AI, sometimes even with Sorian, was already that way.

Immediate desyncs, as soon as the game has started, are usually an indication of a map related issue.

Would it not be easier to just prohibit the UI from displaying Dummy Weapons in the rollover ?

The Fatboy II, at least in the incarnations I have seen, looks 'toyish' as do many SC2 units - and, just as most mod T4's - really overpowering.

The Wyvern Fatboy, likewise, in it's native form, is also largely overpowering.

Do keep in mind, it's a factory, not a super-hardened main battle tank. What you might wish to advocate for is a non-factory version of the Fatboy - with compensations based on the removal of the factory. The Wyvern Battlepack did something along this line, introducing the 'Wyvern Fatboy', which essentially removed the factory - and replaced it with a sizable artillery calibre weapon - but you get the idea.

A desync is, in every case, a situation where the data on one machine, is different than the data on another. This is invariably caused by different code producing a different result between one or more machines. The nature of the desync can tell you something about the cause.

Immediate desync messages are most often caused by the map being different.

In progress desyncs are most often caused by a mod, or other user addon, that has altered the game data in some fashion. These would be mods that change units, or gameplay or balance factors - rather than those which simply modify the UI.

In only the rarest of cases does an internet hiccup cause a data corruption, since the nature of the internet involves preventing pretty much exactly that from happening. I can likely count, on one hand, the number of times I've seen anything like that happening, it's far more likely you'd have a crash to desktop, than that result.

Other than the time taken to form up, formations are only as slow as their slowest unit.

In order to effect a movement bonus, the formation code would need to handle applying, and removing, buffs - to all the units involved - a costly process, especially in light of how often the formation code is called.

Yes - those filled with SND/XACT error messages - caused by surround sound.

I haven't looked at your work in some time - you've made great progress from the early days - that's for sure.

Currently 62.

A badly behaved mod, or a new feature, that is getting stuck in a loop of some kind.

It's not practical to do so. The number of 'special' conditions that would need to be coded, to make the AI behave coherently, with all the possible permutations of unit restrictions, would be staggering to write - and create a monumental sucking noise on the performance.

DPS as a single metric is often the only one considered in most discussions - but you are so right - balance is a MUCH wider subject .

You have to look at the resource investment (not just mass) to arrive at, not only that DPS, but the associated HP and mobility factors that go with it. Range and AOE should also represent major modifiers to DPS cost - it takes more resources to fashion a longer ranged weapon - and more again to have a weapon that can affect an area - the bigger the area - the more resource costly that should be (especially with the linear AOE in this game).

Platform matters - and basic motivation should affect valuations - hovercraft for example, have versatility - but acceleration and inertial issues. Submersible units would require substantial reinforcement over a non-submersible unit, etc. Tanks have a mobility advantage over walkers in some circumstances, but are at a disadvantage in others - those are just some aspects to consider.

Having done that across a group of roughly comparable units - you need to examine those metrics - and put them in relation to other classes. For example, are air units performing better, or worse, in those respects - is this the fundamental reason that air dominates the game ? Are they getting a free pass in relation to everything else ?

You cannot boil it down to anecdotal observation, if the basis is not quantifiable - then neither will be the results.