Feature Request: Switches
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Feature Request: Switches
Any chance you can add in some way to make all the switches in Doom sound different? For instance, the levers will be squeaky, the buttons will click, the sliders make their proper noises...etc? I've been considering doing that with Doom:OS, but can't find a proper way to do such a thing.
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
You can already make all the switches make a different sound. In fact, I have a file like that already, but it's got other stuff in it too ATM. I think you can assign different on and off sounds. You can also increase the number of frames for a switch so it doesn't just jump from off to on but can have intermediate steps to make the animation of a lever smoother.
A line like that in animdefs make the swxbrn1 switches behave as normal, but use the sound switches/clunk which I defined in sndinfo.
That one is for one of my own switches. Not sure if all the entries are required, but it works. The texture sw1nj15 passes through sw1nj15b, sw1nj15c and on to sw2nj15, showing each frame for 8 tics and playing switches/lever2 as it goes.
Although, I don't know if any of this would disrupt compatability with other ports. You may be able to set this up and simply have it ignored by Legacy etc.
Code: Select all
switch doom 1 SW1BRN1 on sound switches/clunk pic SW2BRN1 tics 0
Code: Select all
switch doom 3 sw1nj15 on sound switches/lever2 pic sw1nj15b tics 8 pic sw1nj15c tics 8 pic sw2nj15 tics 8 off sound switches/lever2 pic sw1nj15c tics 8 pic sw1nj15b tics 8 pic sw1nj15 tics 0
Although, I don't know if any of this would disrupt compatability with other ports. You may be able to set this up and simply have it ignored by Legacy etc.
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Correct me if i'm wrong, but I think the SNDINFO Lump is Zdoom only. However, other ports should ignore this lump, and play the WAD as normal (without the switch sounds).Enjay wrote:Although, I don't know if any of this would disrupt compatability with other ports. You may be able to set this up and simply have it ignored by Legacy etc.
Oh, and wildweasel, you should really try and learn ACS, it works wonders! (I'm still learning, but I can already tell that it's a winner!)
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Just out of curiosity, would ACS be very useful if I don't have any maps in my WAD? I don't even know how to map, nor do I care about learning how to map. So does ACS still work wonders without maps?Xaser wrote: Oh, and wildweasel, you should really try and learn ACS, it works wonders! (I'm still learning, but I can already tell that it's a winner!)
The closest I have come is running a Zdoom format map with no scripts on top of a IWAD that did have an open script printing a message on map01. When I started the game, the behavior lump from the IWAD was obviously being used because I got the text message show whilst playing the PWAD. This wasn't a one off where I accidentally compiled a script and stuck it in a WAD or something. It's happened a few times with different maps. It doesn't happen if the WAD loaded on top of the IWAD with the script is a regular Doom format map though.
As far as taking standard MAP01 and giving it a behaviour lump I dunno. I don't know what Zdoom looks at to determine whether a map is in ZdoomHexen format, or a traditional map. ZdoomHexen maps have the extra behavior lump. If Zdoom uses that to say "aha, this is a ZdoomHexen format map", then putting a behavior lump into a normal wad would get Zdoom thinking it was a ZdoomHexen map, but it wouldn't be and other data lumps would be in the wrong format.
Damn, even I don't understand what I just wrote.
As far as taking standard MAP01 and giving it a behaviour lump I dunno. I don't know what Zdoom looks at to determine whether a map is in ZdoomHexen format, or a traditional map. ZdoomHexen maps have the extra behavior lump. If Zdoom uses that to say "aha, this is a ZdoomHexen format map", then putting a behavior lump into a normal wad would get Zdoom thinking it was a ZdoomHexen map, but it wouldn't be and other data lumps would be in the wrong format.
Damn, even I don't understand what I just wrote.
differences between hexen and doom map formats:
- behavior lump
- things have tids, z heights, specials and args, which comes out to 7 extra fields
- linedefs, likewise, due to the non-hardcoded specials, have five extra fields
also you should note that if any of those values aren't used, they're still in the wad, just as zeros (or nulls), so a thing with a special and five args and a tid takes up the same amount of space as a thing without any of that :)
other than that the wad structure (headers and such) are exactly the same, and actually, and this is probably what occurs, zdoom doesn't really need to know what format a map is since it just converts them all to zdoom format before running them (in memory of course, not on disk), so I'd wager it probably doesn't even bother to check doom format maps, though it would have to be able to decipher between build and doom/hexen maps, which I'm sure is a simple matter of checking the file header. I ought to check the source before I start blabbing stuff, but it seems to make sense
- behavior lump
- things have tids, z heights, specials and args, which comes out to 7 extra fields
- linedefs, likewise, due to the non-hardcoded specials, have five extra fields
also you should note that if any of those values aren't used, they're still in the wad, just as zeros (or nulls), so a thing with a special and five args and a tid takes up the same amount of space as a thing without any of that :)
other than that the wad structure (headers and such) are exactly the same, and actually, and this is probably what occurs, zdoom doesn't really need to know what format a map is since it just converts them all to zdoom format before running them (in memory of course, not on disk), so I'd wager it probably doesn't even bother to check doom format maps, though it would have to be able to decipher between build and doom/hexen maps, which I'm sure is a simple matter of checking the file header. I ought to check the source before I start blabbing stuff, but it seems to make sense