TA Spring Sound bug ever since the first version came out

[evilzippy2000]

Has anyone got a fix for the Metal convertors ie when they shut down and start the noise is Deaffffening I mean it is sooooo loud u have to turn the speakers almost off lol, all other sounds are fine level wise give me the god damn sound file and i will edit it lol. does anyone know how I can extract it delete it what ever is needed .............to make life a bit more easier.

would be greatfull

Thx

.... p.s it would be a nice xmas pressie if this was fixed finally , btw sound issue is on more than 3 pcs so its nothing todo with my systems

[Guessmyname]

Turn down max simultaneous sounds in settings.exe

[evilzippy2000]

thank you I will give that a try

[Tribulexrenamed]

Its not a bug and it has nothing to do with spring.

[Argh]

Its not a bug and it has nothing to do with spring.

Well, I'm afraid I'd have to disagree with that.

Here's why:

A. The "maximum simultaneous sounds fix" just lowers the number of sound files that are allowed to be playing at once. It's like solving the problem of hearing dinner conversation in a restaurant by declaring that if there are 100 people talking, at all kinds of volumes, that we want to hear only X number of them, pulled out of a hat.

Obviously... you don't get logical results from that. It'd make more sense to limit the number of sounds played through based on their distance, however... the last time I checked, it's not filtered in any way. So, you may be hearing a factory off-screen, gunshots from a soldier on-screen, and be wasting the other 14 out of 16 "slots" on very faint foot-step sounds from distant sources. In OTA mods, it's harder to see how badly this works- in P.U.R.E., it's completely obvious, because I have a lot of ambient noise sources.

Modern soundcards, even supposedly-crappy chipset stuff on motherboards... can easily handle 32 or more simultaneous sounds playing through at once, often more. The problem is how multiples of the same sound occurring during a given frame is handled.

Currently, there's some logic in Spring that's supposed to prevent more than X from playing, period. However, it'd be smarter to add the number of simultaneous occurrences together, then multiply the volume- if greater than 100%, then halt at 100%, so that Spring won't cause horrible clipping. Set the "standard" level of a sound to 50%, and voila- one instance of a sound is fairly quiet, multiples are quite loud, and no clipping, and it'd save the soundcards from being overworked, and allow more sounds to play simultaneously in most situations with lower overhead.

B. The second problem is that the Unit Reply volume wasn't working correctly, due to using the incorrect Registry entry in SpringSettings. I believe this has already been addressed. Unit Replies have the same problem as multiple sounds playing on the same frame, and should be cured the same way- the only difference is that they won't ever fade with distance, and should have an artificial ceiling set by the user control, imo.

C. The third problem is that sound's fadeout due to distance is handled in a very user-unfriendly fashion.

Instead of specifying a fadeout distance, where past N you hear 0% of the resulting sound, the current system calls for a "volume", which then drops off after passing through a range-based formula- the "volume" defines the range, but the resulting relationship isn't very straightforward. I.E., I can go fetch that math for you, but most of you won't understand what it means, and it's not user-friendly, nor is it labeled in a way that has anything to do with what it does- "volume" is the term for the actual loudness of a sound, but what this actually does is to affect attenuation from the point-source.

[lurker]

Spring does have code to only play one unit reply of a type in a singe frame.

[Argh]

Spring does have code to only play one unit reply of a type in a singe frame.

Er, I didn't say otherwise, did I? <reads>

No... what I was saying was: "Currently, there's some logic in Spring that's supposed to prevent more than X from playing, period."- IIRC, there's checker code that's supposedly there to prevent clipping. It doesn't work, never has.

"The second problem is that the Unit Reply volume wasn't working correctly" refers to a bug that was fixed in SpringSettings, again IIRC, after I pestered people about it.

At any rate, for more about this, read here.

[lurker]

I thought you meant the max sounds by X, rather than something very small.

[evilzippy2000]

shame the metal convertors directly can not be disabled all together as its the one unit no one cares to hear, turning from on to off and vice versa, also has anyone heard a hisssing sound being played when units can not build or the path is obstructed lol, I feel so much can be cleaned up before moving on to adding to spring fine tune it at as it is, then maybe there would be far less Dsyncs occuring, anyway I cant moan to much these guys are stars for keeping an old game alive just we always want something better its only a human desire after all

[Google_Frog]

Metal Maker noises aren't a Spring bug. They're a decision on the part of the mod maker, complain to him.

[Tribulexrenamed]

Metal Maker noises aren't a Spring bug. They're a decision on the part of the mod maker, complain to him.

Well, I'm afraid I'd have to agree with that

[evilzippy2000]

yay I shall do just that thanks

[Noruas]

Its important that we keep this because any porcer who makes metal makers deserve this, its a feature.

[Forboding Angel]

yay I've been waiting for a spot that I can use this image...

featurebug.jpg

(13.02 KiB) Downloaded 41 times

[evilzippy2000]

lol thanks for sharing