Artinum

First, if you're going down this route, you're probably best with UDMF and GZDoom. The more vanilla formats won't support scripting and vanilla engines are unlikely to be happy either. But hey, that gives you a lot of power. You can include any number of music tracks in your map, and GZDoom is able to play many kinds (MP3, OGG, WAV, FLAC, MIDI and a number of more obscure formats). MP3/OGG is usually fine for most purposes, and MIDI files are both smaller (good for community projects or if you're trying to reduce file size for other reasons) and feel more "Doomy". The infamous MyHouse.WAD used both MP3/OGG and MIDI formats, the latter for its extended D_RUNNIN track and the former for the more ambient weirdness. You can specify which music track you want to play on starting the map in your MAPINFO file. If you don't want ANY music on starting, just include a short (few seconds) silent music file. Call it SILENT.MP3 or whatever. Doom is happy to play a two second loop of silence as a music track. ACS scripts can then be used to change the music whenever triggered - line actions, monster deaths, button presses, even just walking into a sector with an ActorEntersSector object - with the SetMusic("name") command. This can be pretty jarring, however, so you may want to fade music in and out with the SetMusicVolume() command. I wrote a fade script for a previous map that would fade out the current music and then fade in a new track based on a parameter passed to it, but note that you can't pass strings as parameters to ACS scripts, so if you want to parameterise a music fade script you'll need a lookup table for your track names. script "CrossfadeMusic" (int NewTrack) {//Switch from currently playing music to new track specified. int musicVolume = 1.0; while(musicVolume > 0) { musicVolume -= 0.05; SetMusicVolume(musicVolume); Delay(1); } SetMusic(MusicTable[NewTrack]); // MusicTable is an array of strings that holds my track names. NewTrack is the index for the next track. while(musicVolume < 1.0) { musicVolume += 0.05; SetMusicVolume(musicVolume); Delay(1); } } The other thing you can do is use PlaySound to create more dynamic music - playing small snippets of music as sound effects based on scripted events, possibly using delays to time them, would be more complicated to pull off... but it could sound quite impressive. You could, for instance, play a sequence of drums in a script when you spring your monster trap and loop that script until the monsters in the trap are all dead, and you could make the delay between the drum loops based on player health, so they get faster the closer you are to death.

My current project uses a mix of both the methods mentioned above. I have banners displayed on some walls that are simply lines a very small distance in front of the wall and they use midtextures. These have the advantage of transparency (you can see the wall behind them). I also have "paintings" that are inset sectors. Doing it this way allowed me to have another sector in front of those to make a wooden frame for them.

If you mean "share this map so multiple people can work on it at once", there is no easy way to do it. All you can do is put it somewhere everyone can access it and schedule when people are working on it so you don't conflict. Doing separate parts of a project (sprites, textures, sound effects, etc) would be trivially easy to sort out. That just needs a shared file storage area and some communication. You could potentially work on different parts of the same map independently by each building your own sections and then stitching them together later with copy/paste, though sorting out the mess afterwards may be more hassle than that's worth. Again, you'd need to communicate about shared styles, tagID ranges (to avoid conflicts) and so on.

Shouldn't that be: if(CheckInventory(KeyTypes[i]))

I've read this a few times now and I think I might be getting my head around it. You're saying that you have a WAD with a series of maps in it - the first six are your "normal" level progression, and the seventh is the final map. It's possible for a player to pick up more than one rune in a map, so they may not play all seven maps; they could jump to the final map from an earlier one than the sixth. In each map, there are various scripted points that can spawn runes - every time the player collects a rune, however, there's a chance for Joe to spawn, and then no more runes will spawn on that map. (This got a bit confusing as you refer to them as "keys" in that part of your post.) Kalensar's post is correct that you'll need to have some custom inventory items for your runes as regular keys won't travel between maps - you'll need something that is retained in inventory. However, the scripting for managing the Joe spawning would be ACS script. I'd set up a simple while(!JoeSpawned) loop in an ENTER script (where JoeSpawned is a boolean value that is set to TRUE when the obvious happens). Then your rune code would run in the middle, and the script would terminate after Joe pops up. However, you'd need the same script added to every map. Your Joe-spawning odds are just a matter of calling some random numbers and seeing what happens. You can make your life easier by setting up some INT constants at the top of your scripts and using those in the main code - then you can tweak just by changing the values of your constants rather than updating everything - but you'll still need to tweak them for every map, unless you do something clever with an #include statement. Ultimately, though, I wonder whether it's all worth it. There's something to be said for keeping things fairly linear. If your players reach the final map too quickly, they may feel a little cheated - playing through all of them, getting one rune per map, means they get maximum play.

You know, now you mention it, I think it had one of those set up as well (but the hub itself isn't set as a level - it just seems to be a virtual hub).

I don't know exactly how it works, but I have played a WAD in which the player is teleported to a new version of the map that is actually a second, separate map (and they are teleported back again later, too). They retain all keys between these two maps. The command used appears to be Teleport_NewMap. https://zdoom.org/wiki/Teleport_NewMap I've not used this one myself, but maybe this is what you need? I can't find anything else in this WAD that might be responsible - the scripting and Decorate areas are fairly straightforward.

Just wanted to follow up. This is working PERFECTLY. Getting the angles right took me a while (the wiki didn't explain the scale - eventually figured out that 0.25 is a ninety degree turn, and 0.75 is ninety degrees the other way) and the velocity took a bit of getting used to as well. But it works! Thanks so much for this - my crazy map idea is now taking shape...

Ooh, thanks for this. I've got a project or two in the back of my head that could certainly use some of those textures!

What do you mean "it doesn't spawn"? Are you unable to add them to your map? Are you getting the chaingun instead when you're using cheats? You need to tell us what's happening before we can diagnose much.

To the best of my knowledge, you can't get rid of the exit dialogue option. You can change what is displayed by adding Goodbye = "Goodbye text"; to the Page block, but you can't get rid of it entirely.

You'd need to replace it with your own code, I guess - apart from anything else, the standard PE code would spawn regular LS enemies without your variable check. If you can then spawn LS enemies as child objects to the parent PE class, you may be able to feed information back and forth. I've unearthed an old post that seems to be heading in a similar direction: Hopefully the code in there will help point you (OP, I mean) in the right direction!

A global event handler is probably overkill, but I'm not entirely sure how to work them and I don't know whether a smaller scope would be possible. You can certainly assign a value to each PE and then assign that same value to an equivalent variable in the LS objects when you spawn them, and you can certainly include some custom code in the LS's Die() function, but feeding data back to the PE could be out of scope. That said, I'm vaguely aware (since yesterday evening, when I was investigating something else) that there are parent/child relationships in ZScript, which might tie your PE parent to LS children - so you might be able to do something with that instead of using event handlers at all. However, I have no idea how to use them!

Ooh, nice - I'll have to try that. Setting the velocity directly after spawning them didn't work, but this might. However, I've had some progress with A_ThrustRadius - someone on Discord has provided me with some code that produces the desired effect... with imps. Still doesn't work for my custom enemies. Messing around with other monster types has been interesting; demons are pushed about quite happily, while Hell Knights are... sometimes pushed. Sometimes they just ignore it. Lost Souls go flying most dramatically. Cacodemons don't move at all. One theory here is that the enemy hitboxes are getting tangled up with each other and/or the corpse of the monster pushing them (?) and this could explain the erratic outcomes. More testing is required.

Inconclusive. Health bonuses don't have death states, so it isn't triggering on collection (and they only have spawn states, so it would trigger on map start if I used that). I'm not sure what else I could use to trigger it. However, the blast IS affecting monsters. Just only in the Z axis. The player is fully affected.