ZDoom

Graf Zahl wrote:There are more than enough reasons not to copy HUD messages by default.

Any scripted HUD for example.


As for the sounds - I noticed that when I load a saved game, I get the switch click sound that was made as I saved the game when I load it. surely that shouldn't happen? (Maybe it's even related to that crash I posted about over at GZdoom?)

For HUD messages it's an option but unfortunately some mappers are just too lazy to use it properly. There are more than enough reasons not to copy HUD messages by default.

Gez wrote:Welcome to Strife.

Heh, well I've never actually played that game for very long. One of these days I should sit down and play it for real...

Enjay wrote:Also, as an aside (and I know I'm guilty of not doing this too) when using hud messages, it's useful to have the hudmessage copied to the console. Print messages are automatically sent to the console but hudmessages aren't (just as well considering some of the uses that hudmessages have been put to) but it can be useful to copy important information to the console so that the player can check it if he misses it, or forgets it, or whatever.

Yes, this is always a good idea. Hudmessages to display the data, and send the important info to the console as well. It's a must if you're playing a project with lots of complicated scripted events and quest-related gameplay.

If you've never heard it before, how do you know it's important? eg, you've just finished a big battle and you hit the quicksave button just as a sound file starts. You maybe didn't even notice the sound starting, or had no idea that it was going to contain important informartion. However, you stop to listen and then, for what ever reason, you die, or quit or whatever, and you reload with the sound gone.

But yeah, backing it up with text should be done anyway IMO.

Also, as an aside (and I know I'm guilty of not doing this too) when using hud messages, it's useful to have the hudmessage copied to the console. Print messages are automatically sent to the console but hudmessages aren't (just as well considering some of the uses that hudmessages have been put to) but it can be useful to copy important information to the console so that the player can check it if he misses it, or forgets it, or whatever.

[edit]Kind of what Gez was saying I guess.[/edit]

Slasher wrote:IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

Welcome to Strife. It does have a log feature, but it isn't always used.

On the other hand, it could partially be called the player's fault as well. I mean come on, who saves and quits right in the middle of an important message?

Slasher wrote:IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

People still do it.

IMO, a sound that contains important information, that isn't also displayed as text or something, would be a bad design choice on the modder's part.

But otherwise yes, I agree and am pleased the annoying noise is gone.

Hence the "mainly".

Enjay wrote:

Changelog wrote:Any sounds that were playing when you saved will still be playing when you load.

Thank you. That's a mainly cosmetic,

Actually not. Imagine a sound containing an important message but interrupted by saving and quitting. You'd have had no chance to hear the rest.

Changelog wrote:Any sounds that were playing when you saved will still be playing when you load.

Thank you. That's a mainly cosmetic, but very, very welcome improvement.

...a design flaw which has now been rectified.

Also, this:

Graf Zahl wrote:It still crashed because it pointed to something invalid.

Was because the ambient sound called S_StartSound() without a valid point, and because S_RelinkSound() looked at points instead of actors. So it was two errors, working in tandem that caused it to crash. You fixed the one, so that stopped the crash and also properly flagged the actor as making a sound, which stopped it from trying to restart the sound every tic.

Ok, good to know. But since a design flaw isn't a bug...

This does highlight one major failing of looping sound playback: The caller is responsible for checking that a looping sound is still playing and restarting it if it stops. This should be handled transparently by the sound code.

I was able to fix the immediate cause but I don't know what caused it to make this odd buzzing noise instead. It sounds as if the sound was restarted over and over again so I suspect some hidden problem in the sound code that accidentally got triggered by the error in the ambient sound thing.

Maybe Randy can say more so I'm leaving this report open. My change was as follows:

Line 1884 in s_advsound.cpp:
The first parameter was NULL in the previous non-working revision.