Worst

More or less the same bug is utilized in most rocket jumping wads made for ZDaemon / Skulltag / Zandronum or early ZDoom versions. In these sourceports combining the sector effect 11 with some of the boom generalized effects, results in the same 'buddha' effect even while the player is touching the floor. Sector specials (boom format): 11 + 32 = 43 : Damage -10 or 20% health and End level + Damage: 5 per second 11 + 64 = 75 : Damage -10 or 20% health and End level + Damage: 10 per second 11 + 96 = 107 : Damage -10 or 20% health and End level + Damage: 20 per second 11 + 256 = 267 : Damage -10 or 20% health and End level + Friction: Enabled 11 + 512 = 523 : Damage -10 or 20% health and End level + Wind: Enabled etc. Sector specials (zdoom hexen format): 75 + 768 = 843 : Damage -10 or 20% health and End level + Damage: 20 per second 75 + 2048 = 2123 : Damage -10 or 20% health and End level + Friction: Enabled 75 + 4096 = 4171 : Damage -10 or 20% health and End level + Pusher: Enabled etc.

Not sure how it is in vanilla hexen, but at least if you use a zdoom compatible engine, another way to get around the 1 byte limitation is by executing a script, and then using the same Floor_LowerByValue(tag,speed,dist) inside the script where it'll work with values greater than 255. Might be useful in the odd case where you need to move the floor by an amount that is not a multiple of 8, yet is greater than 255.

I made another test map, which uses single color flats and sky textures that are crafted to blend with them, to get a sort of a compromise solution to changing also the ground 'sky', but in this case it is just an illusion. This trick is also limited to setups where there are no ceilings breaking the continuous sky, so looking at your screenshot, it's probably not going to work for you though. boom_switch_change_voidsky_test.zip

Dos Boom definitely does not support DEHEXTRA. DeHackEd Extended is a fairly new extension to dehacked, and it did not exist 21 years ago when the latest version of Boom was released. If your mod still somehow works in it, my guess would be that it is overwriting some other memory in the process, and that this could lead to crashes or glitches during play.

Not sure what kind of method Gez had in mind, but one way I can think of accomplishing a dynamic sky change in Boom/MBF format is to surround the sky sectors with an outer layer of sky sectors that are initially hidden, and contain a different sky. Then a switch can be used to raise the ceiling of those outer layer sectors, overriding the sky of the sectors that these sectors surround. This trick will probably only work in specific setups where the sky is continuous throughout the entire area, and there are no roofs/ceilings or walls interrupting it. I attached an example map to my post. boom_switch_change_sky_trick.zip

By the way, not sure what the plan for this is, but I would suggest first releasing a release candidate, eg. "3x3_rc1.wad" so that the wad can be playtested and any map breaking issues that may have managed to slip in, can be fixed before the final version is uploaded to /idgames. In the best scenario, this could just mean having to rename the wad file if no major issues are found. I'm hoping that this suggestion doesn't go too much against the spirit of the project, and that it's worth-while to do so, in order to present a more solid megawad to the people wanting to play through it once it's finished.

One final update to my map: - Made one mandatory leap easier to pull off without straferun - Adjusted the position of some trees so they obscure the view less - Gave the player a little more room to maneuver outside Download: Immundus_Stagnum_v3.zip (wad filename is same as before, without '_v3' in it.)

The reason for that fatal error is probably because your dehacked file has state numbers (called 'frame' in dehacked) that don't exist in Boom: Frame 1089 Sprite number = 28 Sprite subnumber = 13 Next frame = 1090 Frame 1090 Sprite number = 28 Sprite subnumber = 14 Next frame = 1091 Frame 1091 Sprite number = 28 Sprite subnumber = 15 Next frame = 164 These frame numbers go past the last valid frame number, which is 967 in Boom.

Updated my map: - Implemented difficulty settings - Added some extra monsters for multiplayer - Fixed a few misaligned textures - Added some extra cover in a couple of spots when playing on easy - Made one secret less obvious, and another one more obvious - Adjusted many line flags to improve the automap view - Added some extra enemies in one part of the map, and a little extra ammo and health too Download: Immundus_Stagnum_v2.zip (I kept the wad filename the same as before, without '_v2' in it.)

This project sparked my interest in making a doom map with the given limits. It's been more than 10 years since I last made a proper singleplayer map, and I've not made many, so feedback is certainly appreciated. Out of habit, I spent a stupid amount of time detailing various parts of the map. Title: Immundus Stagnum Author: Worst-vd-plas Flats: CEIL5_1, FLOOR7_1, NUKAGE1 (+ F_SKY1) Textures: EXITDOOR, NUKEPOIS, TEKGREN1 (+ DOORBLU, DOORRED, DOORYEL, EXITSIGN) Sky: OBSKY458 (Generated with OBLIGE 7.70 seed 458963455) Music: "Wolverine" by Jimmy (from Smart CTF) Difficulty settings: No (Maybe I'll add some later, if there is still time for it) Multiplayer: Player starts are there, but it's not been balanced for it. Description: A some kind of toxic waste facility, where starting from the central hub room, you can proceed in multiple different directions. Download Immundus_Stagnum_v3.zip (current) Immundus_Stagnum.zip (old version) Screenshots

Your script still needs a bit of work for it to be multiplayer compatible, script 1 ENTER{ Thing_ChangeTID(0, 1000 + PlayerNumber()); ACS_Execute(2,0,0,0,0); } Because for script number 2 you are using ACS_Execute rather than ACS_ExecuteAlways, only one instance of it will run at a time. This means that only the first player will be able to run this script. Another issue in multiplayer is that script 2 only gets run during ENTER. That means that if a player dies and respawns in multiplayer, script 2 will not run again for them, as there is no RESPAWN script defined that would call script 2 again. Note that since you have a never ending loop with while(TRUE) in script 2, the script will keep running even after the player dies, but I think it may lose its activator after the player respawns. It would probably be a good idea to replace the while(TRUE) with for example while(GetActorProperty(0, APROP_Health) > 0) . Another problem is with the function str isInFootstepSector(void), as it always checks for the TID of the first player. This could be fixed by just adding the activator player number to the TID value that it checks: if(ThingCountSector (T_NONE, 1000 + PlayerNumber(), footstepTypesDef[a][0])){ Also when playing the footstep, script 2 always plays the sound at the first player. This again can be fixed by adding the activator player number to the TID that it uses: PlaySound(1000 + PlayerNumber(),_footstep); Btw. Instead of checking whether the player is in a tagged sector, another perhaps simpler approach would be to check what the floor texture under the players feet is. You can check this with GetActorFloorTexture. Also you may want to use GetActorFloorZ combined with GetActorZ to check if the player is off the ground or not, so that they don't make footstep sounds while falling through the air, etc.

Adding to the answer from boris: ACS only actually has one data type, which is the 32-bit integer. The other data types are just hacks built on top of the integer data type. Because of this, you can mix and match any data types within an array, since they are all integers in the end. Quoting ZDoom wiki:

That's true, if they happen to use ClearInventory or ClearActorInventory, and then supply the player with starting gear, then the exit item would also be removed since it does not have the INVENTORY.UNCLEARABLE flag set. But now that I think about it, there is also the possiblity that another pistol start mod could break this script if it runs right after this, and calls ClearInventory/ClearActorInventory and then removes the exit item, that this script gives the player at the end of the ENTER script. It does depend on which ENTER script gets executed first, but perhaps there should be a short delay before giving the player the exit item, to reduce the chance of another mod removing it right as they spawn.

I may be wrong about this, but I think if you convert your GZDoom-specific DECORATE to ZScript, Zandronum will ignore it and only load the DECORATE lump. However GZDoom will still load both lumps, and this might get tricky if you have an actor with GZDoom-specific bits, that should still be loaded in Zandronum, just without those GZDoom-specific properties. It may mean that you need to make two duplicates of the actor, and do some trick to make the game only use the ZScript version when playing in GZDoom.

I think rather than checking what equipment/health/armor the player has, a better approach would be to keep track of whether or not the player was alive prior to starting the current level. This way the script will still work as intended, even if the player happens to run the game with a mod that for example changes the starting equipment. I think one way of keeping track of this, would be with a special inventory item, which would be used to check if the player survived the previous map. On entering the map, a script would check if the player has the item, if they do, it's NOT a pistol start. If they don't have it (the player died and lost the item), it IS a pistol start. After these checks, and whatever actions follow them, the script would give the player the special inventory item again, so that on the next map load, the script can properly check for pistol start again. Decorate example: ACS example: I guess another possible approach could be using global variables and both an OPEN and UNLOADING script to keep track if a map was exited prior to loading the current map.