Obligatory Legacy of Rust/ Nightdive Doom Port thread

[yum13241]

No, "the change to this music but once" I believe means "don't activate more than once". MUSINFO had to wait 1 second before changing the music because you can't set a thing as "activate once", or "only allow activation after 70 ticks have passed". Or it could mean "just don't loop lmao". The game has to be programmed to loop the MIDI, not the other way around (why do you think Bethesda can't get the song to loop right with their recordings?)

So MUSINFO taking up a few dozen editor numbers is not a problem. And it gives us a lump where we can see all the extra music used in all maps, so finding out about how a soundtrack is arranged requires only looking at MAPINFO and MUSINFO.

Don't waste water, even if you live by a river.

The problem is that when multiple mods add a crap ton of map-placeable objects. Just because it's not a concern now doesn't mean it can't be. If we just keep spamming these HACK things into specs, we'll run out of DoomEdNums. Why they couldn't make it take an argument is beyond me. Oh I remember, because we're still using the binary format from the 90's when there was a format that was INVENTED in the 90's, called Hexen format. It only took until the early 2000's until we had Doom/Heretic-in-Hexen, and then you'd have to wait a decade later for UDMF*. Is everyone going to support UDMF? It'd be delusional to say so. But using up DoomEdNums for no reason is stupid, and not being able to change the song instantly is dumb (because people made things do stuff linedefs were supposed to do). YOU HAD ONE JOB, MUSINFO!

MUSINFO is technologically worse (64 songs only, and of course, hack things), and while setting texture names is dumb, what can we do, a linedef to change music? Great idea!Then we can make that linedef reference a lump name and whether it should loop (default yes). If it does not correspond to a playable music file, the game notifies the user.
Now linedef ID's aren't that big of a deal (it's not possible to create your own linedefs), much less than DoomEdNums and MUSINFO slots, among other things, but name-ifying everything would be amazing (but a pipe dream at that).

*what does dropactors = true; do? If you're converting a Doom-in-Doom map to UDMF, apparently every tagged sector needs it to stay compatible.

[Phredreeke]

I think what yum is saying is players are used to be able to combine different Doom mods, and this risks Doom becoming like EDuke32 where different mods end up conflicting with each other. I'm not so sure that will be the case though, as gameplay mods makes more sense to do in GZDoom anyway

[Gez]

No, "the change to this music but once" I believe means "don't activate more than once". MUSINFO had to wait 1 second before changing the music because you can't set a thing as "activate once", or "only allow activation after 70 ticks have passed". Or it could mean "just don't loop lmao". The game has to be programmed to loop the MIDI, not the other way around (why do you think Bethesda can't get the song to loop right with their recordings?)

No, it's not a question of x1/xR activation, they have the whole enchilada of W1/WR/S1/SR/G1/GR for both the "play music and loop it" and the "play music but only once" effects.

It is absolutely, 100% percent about playing a music that doesn't loop.

MUSINFO's delay is absolutely not due to this; it is motivated by not wanting music to constantly change back and forth when the player moves along the border between two sectors. That's why it was implemented like this.

The sim part of the game (what handles players and monsters and sectors and stuff) does not have to care about music at all; that's why you can play without music and without changing the gameplay. It's the music engine of the game that plays the music, and in 100% of all community ports up to now, it has played music by looping it because that's what was needed in 100% of the cases until now.

The lack of looping in the recording is a failure of the recording to have proper loop points, and nothing more. MusicallyInspired has working music packs. Hulshult's remixed soundtrack also loops correctly.

The problem is that when multiple mods add a crap ton of map-placeable objects. Just because it's not a concern now doesn't mean it can't be. If we just keep spamming these HACK things into specs, we'll run out of DoomEdNums.

Yeah, sure. MUSINFO was in 2010, so about 17 years after Doom's original release, and it added 65 ednums. So at this definitely unsustainable rate of 65 ednums taken every 17 years, we will run out of ednums in 16 477 years. This is a crisis, people! We are in danger! Doom is dying!

MUSINFO is technologically worse (64 songs only, and of course, hack things)

Please refer me to the maps that really, really, really need more than 64 different songs during their gameplay.

The only situation I could see for that is a jukebox map. And it's going to be so incredibly tedious to type dozens upon dozens of song lump names in that over-64-song jukebox map's texture fields when it would be so much simpler (and easier to automatically generate) to use ACS for that.

I really don't understand why you have a beef with MUSINFO; it's been around for 14 years.

[Xaser]

Just to clarify this: the "play once" specials are indeed "play once, then stop playing music." This is behavior taken straight from vanilla Doom (i.e. the title screen). The next version of the ID24 spec will update the wording to state this more explicitly.

Speaking as a mapper: the 30-tic delay makes the MusicChanger things useless, and the delay was unnecessary in the first place -- if the intent was to prevent the music from flip-flopping when going back and forth between two sectors, then the mapper could've fixed that by just... not putting two MusicChanger things in adjacent sectors. -- There are other issues with the implementation too, e.g. MusicChangers can't be triggered by voodoo dolls, so there's plenty of good reason for redoing this as a line special instead.

Theoretically, ID24 could've still used the MUSINFO lump, using the line's tag field to resolve the music index, but eh, I didn't implement this part and I don't have a strong opinion; they're basically the same from an end user PoV. There's already precedent in Boom anyway for using the texture name field for things that aren't textures (i.e. colormaps for deep water), though GZDoom likely doesn't implement those so it may not have come up on GZDoom's radar yet.

[yum13241]

Well Xaser said what I was going to say, lol.

There's already precedent in Boom anyway for using the texture name field for things that aren't textures

Hopefully that's gone. The last thing we want is intentional HOM.

then the mapper could've fixed that by just... not putting two MusicChanger things in adjacent sectors

Who made them things anyway? Something like this was always meant to be a linedef, like MBF's "Change Sky" linedef. This is like saying the the Player #1 Start should've been a sector argument (like light level).

added 65 ednums <snip> we will run out of ednums in 16 477 years

You have to account for Doom's growth/decay as a game, as well as more people like you adding HACK things like this over time. If GZDoom had a limit on how many CVARs could be in a config file, we would've reached that since mods like Brutal Doom, ZMovement, Project Brutality, Ultimate Custom Doom, etc. So that number is more likely to be 20 years. Like I said earlier, even people that live next to rivers don't waste water (or at least they shouldn't). And MusicChangers have other technological problems. A mikoportal carrying a voodoo doll can't trigger them. This means you can't say, have a kill timer setup change the music the longer they take to stop the voodoo doll, to indicate time's almost up, unless you count on the player not being able to back-track.

I really don't understand why you have a beef with MUSINFO; it's been around for 14 years.

Just to be clear: I don't have beef with the people behind it, my "beef" is that IT HAD ONE JOB that it just DIDN'T do. Switching the fucking music. It makes you think your MIDI synth is freaking out. You may as well just tell the user to swap D_RUNNIN with D_SHAWN in your map when they get to the Cyberdemon part of the map. It'll work, with a lot of waiting, just like MUSINFO did.

I think what yum is saying is players are used to be able to combine different Doom mods, and this risks Doom becoming like EDuke32 where different mods end up conflicting with each other

Yes, among other things (Doom was designed like this). (I don't know much about EDuke32, does it use some sort of ID for everything placed in the game?)

God, I love the quote feature. IMO ID24 is a net benefit to Doom if and when the more, uh, questionable ways of adding things are rectified (I know Xaser isn't the only guy behind ID24, and I don't have any beef against him)

[Gez]

Hopefully that's gone. The last thing we want is intentional HOM.

You're not really consistent, are you?

Who made them things anyway?

Risen3D. They were adopted by PrBoom+ because Eternal wanted to use them and entryway usually implemented stuff needed by Eternal.

I wonder if they're still friends.

Something like this was always meant to be a linedef, like MBF's "Change Sky" linedef.

Change sky uses a valid texture.

Change music uses "an intentional HOM", as you put it.

You have to account for Doom's growth/decay as a game, as well as more people like you adding HACK things like this over time.

LOL.

The hack things I've added to the game are random spawners, they don't use any ednum by default.

If GZDoom had a limit on how many CVARs could be in a config file, we would've reached that since mods like Brutal Doom, ZMovement, Project Brutality, Ultimate Custom Doom, etc. So that number is more likely to be 20 years.

That you don't understand how your comparison is incredibly irrelevant shows that you don't understand the issue at all.

Editor numbers are something you can define in MAPINFO, by the way. You can clear them all out.

Also, you can run out of line types, because you can add new line types in XLAT. Man, now we can't add anything to the game without wasting rivers!

And MusicChangers have other technological problems. A mikoportal carrying a voodoo doll can't trigger them.

Mikoportals don't work at all in GZDoom.

Just to be clear: I don't have beef with the people behind it, my "beef" is that IT HAD ONE JOB that it just DIDN'T do. Switching the fucking music.

They do change the music. It's not instant, but they do it. Are players supposed to precisely know when they trigger something to the point that less than a second of delay is hurtful?

God, I love the quote feature. IMO ID24 is a net benefit to Doom if and when the more, uh, questionable ways of adding things are rectified (I know Xaser isn't the only guy behind ID24, and I don't have any beef against him)

ID24 adds a whole 54 new thing types. Shock, horror.

[Chris]

They do change the music. It's not instant, but they do it. Are players supposed to precisely know when they trigger something to the point that less than a second of delay is hurtful?

It can be a problem, yes. For reference, I consider OpenAL Soft's default 20ms period updates and 60ms latency target (so about 20ms between non-synchronized events, and can take up to 60ms between something happening to getting heard) to be a bit on the high side -- tolerable, for safety purposes, but it would be nice to set lower. A 30-tic delay for a 35hz engine is 857ms, more than 10x that amount and almost a full second. It won't always be a problem of course, and I wager 90 to 99% of the time it's perfectly fine for a music change. But when you do need more precision, you can really tell when you don't have it. As a quick'n'dirty hack I could see why they added such a delay to fix a potential issue on a tight schedule, but a proper method that can provide the extra precision when needed would be better for modding.

[Gez]

It can be a problem, yes. For reference, I consider OpenAL Soft's default 20ms period updates and 60ms latency target (so about 20ms between non-synchronized events, and can take up to 60ms between something happening to getting heard) to be a bit on the high side -- tolerable, for safety purposes, but it would be nice to set lower. A 30-tic delay for a 35hz engine is 857ms, more than 10x that amount and almost a full second.

Again, it's something that is triggered by the player moving into a sector. It's not something you can control precisely from the mod's side, because you don't control how the player moves their fingers; and it's something that is going to be very fuzzy from the player's side -- it's not like hitting a button, it's crossing an invisible boundary.

[Chris]

Again, it's something that is triggered by the player moving into a sector. It's not something you can control precisely from the mod's side, because you don't control how the player moves their fingers; and it's something that is going to be very fuzzy from the player's side -- it's not like hitting a button, it's crossing an invisible boundary.

A trigger is a trigger. Of course you can't control when the player crosses a line (aside from using voodoo dolls, which this expressly doesn't work with for some reason), just as you can't control when they press a button. But when the player does cross that line, the map's design can make a nearly one-second delay between the intended trigger and its effect noticeable and off-putting (especially if the player still has control, allowing them to move into a less than ideal position for the start of the new music track since you can't control how the player moves during the time between the trigger and its effect).

[Phredreeke]

Yes, among other things (Doom was designed like this). (I don't know much about EDuke32, does it use some sort of ID for everything placed in the game?)

I don't know about the scripting side but tiles (which are used for everything artwise, be it walls, floors/ceilings or sprites) have no names, only numeric IDs. The level editor helps slightly by giving known objects labels (sometimes reflecting on the game's development status with healing pickups being referred to as COLA and SIXPACK)

This isn't an EDuke32-specific thing btw, it applies to all Build engine games. Just that it's only really EDuke32 that has gameplay mods to it.

[yum13241]

Also, you can run out of line types, because you can add new line types in XLAT. Man, now we can't add anything to the game without wasting rivers!

That's a GZDoom specific feature, and you need to know C++ to add them anyway. At that point you may as well fork a source port for your mod. XLAT is the Doom2UDMF for GZDoom anyway, since GZDoom doesn't actually understand binary Doom maps.

The hack things I've added to the game are random spawners, they don't use any ednum by default.

You purposely misconstrue my meaning behind "hack thing". A hack thing is a thing that doesn't mean anything to the player. MusicChangers are a good example because the player cannot do anything with them, or have anything done to them. They exist to destroy themselves and change the music. DoomBuilderCamera is also a good example. Why did Doom Builder 2 place random garbage things anyway? The "Dead Lost Soul" would also be a hack thing if it weren't a leftover from when lost souls had a stupid psychic attack that could go through walls.

The reason I am not "consistent" is because all standards, in one way or another, rely on baggage from DOOM.EXE that's begging for death.

Editor numbers are something you can define in MAPINFO, by the way. You can clear them all out.

I think you meant ZMAPINFO. First of all, you have no idea what you're getting rid of if 2 mods use the same DoomEdNum, and then players will be confused when that happens, just like the stereotypical Brutal Doom addicts.

If I had to choose between MUSINFO and ID24's line music changes, I'd take the latter. If the ID24 music linedefs just took 2 arguments, "lump to play when going through the forward side" and "lump to play when going through the back side", that'd be perfect. You just have to handle D_ and O_, the latter of which is from the Kex port, which would already be handled by Xaser with the texture method anyway.

ID24 adds a whole 54 new thing types. Shock, horror.

First off, 54 (useful things) < 65 (hack things), and some of those 54 would've made it in the game if Tom Hall were President of iD. Doom would be a completely different game, probably for the worse, but those would be part of the base DoomEdNums.

Mikoportals don't work at all in GZDoom.

Voodoo doll zombification didn't either. (See CIVILIAN.WAD). Just use Boom conveyor belts instead, those will work better than Mikoportals actually. The point still stands. MusicChangers barely did their job.

User has been warned --Hellser

[phantombeta]

I think you meant ZMAPINFO. First of all, you have no idea what you're getting rid of if 2 mods use the same DoomEdNum, and then players will be confused when that happens, just like the stereotypical Brutal Doom addicts.

And do you know how many mods ACTUALLY define editor numbers? Because the answer is very few. Gameplay mods rarely define new editor numbers, it's primarily bigger mods with their own sub-modding communities like Hideous Destructor that do. The vast majority of things defining new editor numbers are maps with custom actors, and you're not gonna be loading multiple of those at once anyway.
And even if you're loading a mod that adds editor numbers together with a map that has custom actors, that's easily solved by loading the map after the mod- which you should already be doing anyway so mods won't override assets from the map!

[yum13241]

and you're not gonna be loading multiple of those at once anyway.

It depends on if you're loading a bunch of maps (single level wads exist), that all load their own copy of a monster pack like MEDB. Monster packs tend to eat up numbers quickly.

And before I get banned, I'm just going to say that I'm not saying, "REMOVE DOOMEDNUMS NOW!!!!!!!!!!!!!!!!!!!!!", rather, what I'm saying is that DoomEdNums have inherent limitations that we'll hit sooner or later, and some port authors will bite their own hands when that happens.

Anyways, we've talked about DoomEdNum obsolescence for long enough, IMO.


Building atop an ancient base is questionable (DEHACKED), that's what this thread's been about for a long while, lol.

[Rachael]

With the creator of this spec making posts like this, it's getting so incredibly difficult to take this whole kit and kaboodle seriously whatsoever. If this is how the future of "DOOM" will be handled, with such a laxidasical I-don't-care attitude towards people having legitimate concerns and flaming them instead of providing proof of how it can be handled (basically showing he has absolutely no knowledge whatsoever of what he is talking about) - he can have it. Alienating developers like this is how you lose them, everyone is just going to roll their own solutions and there will be no standards to follow.

[AlphaEnt]

I don't know exactly where to ask this, so considering some of the people that contributed to the port are around here, I feel like asking:
"Is there a way to force an uploaded mod to work on Doom 2/Nerve IWAD instead of Doom 1?"

Recently updated a mod of mine inside the kex port, then tweaked some details on slayers club page, but can't find a way to make the mod run on a specific IWAD, so i'm curious if there's an extra lump file required to to force an IWAD other than doom1.

Also, considering that if you load a mod, then go to switch game, it goes back to normal iwad's unloading the mod's, so idk if there's a way for players to choose which IWAD to play the mod's with.

(PS: I know, that loading the mod via steam parameters allows me to pick the iwad manually, but wanted to make it work inside the mods menu for those on consoles)