Posts made by Sprouto

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.

@redx It's a measure of CPU saturation - and it starts with an individual's CPU - so while initially the problem is local to one user, it will eventually and usually quickly, result in apparent lag across the entire multiplayer session, as the others will end up waiting on the slow machine to catch up.

If it's your own units - yes - but it may be due to the AI, or other players. The game itself uses a queue to process orders - and that queue is processed at a finite rate. When hundreds of units are colliding - they're creating new orders to 'unbump' themselves - and your single order just gets swamped - and delayed.

Map size has little to do with it - the real issue draws in two aspects - unit count (which is directly responsible for the SIM slowing down) and traffic issues (unit collisions).

While a smaller map does reduce the memory requirement a bit, it has no impact beyond that. Unit count (and the complexity of those units) has long been recognized as the largest influence on performance, and memory consumption - and this 'unresponsiveness' that you're seeing is related to that.

It can impact players at different times, as it's really a measure of CPU 'saturation' - and if the problem is severe enough, it can impact multiplayer games for all players.

Unit collisions play a very big role in this - so anytime you have a situation with a large number of those (like clumps of engineers all crowding around a factory), or traffic jams caused by really tight and complex terrain, you're going to see a very big upswing in CPU activity - which manifests as 'unresponsiveness'.

If FAF had a penny for every time someone suggested shit like this, shit like this wouldn't get suggested anymore. But also, props to you for having the shittiest of shit suggestions

These kind of comments....says it all.

We use a fair bit of Wyvern with LOUD, so if you could specify the unit in question, I can have a look at the rigging and see if we solved it. I'll be honest though, quite a bit of Wyvern was lifted from other mods, so we discarded significant portions of it.

If a second weapon is utilizing the same muzzle then this might explain your issue - the aim is being co-opted by the second weapon. Beams have no arc - whereas projectiles usually do, and the muzzle velocity, in conjunction with that arc, may in fact be raising the muzzle bone ever so slightly, throwing the aim off.

You can test this by disabling the 2nd weapon temporarily, to remove any such interaction.