Worst

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.

This mod is meant for co-op play and adds highlights or 'shadows' to your teammates when they are not in your direct line of sight. The highlights can be toggled on and off with a button or two. The idea is to make it faster and more intuitive to find where your teammates are at, without needing to obscure your view with the automap or coop spy. The current implementation is kinda crude as it is hardcoded to a marine shaped highlight, that only has walking and normal death frames. It also doesn't work great with the default Movebob value of 0.25, reducing it to at least 0.05 is recommended. The highlights also render wrong during coop spying, I might fix this eventually. If someone wants to use this mod in their mod or improve or copy it or whatever, feel free to do so. tmatehlt.zip

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.

You could also possibly make a brand new liquid animated flat if lava does not fit the theme of the area. I think players are likely to be more wary of 'liquid' flats that they don't recognize, anyway.

ACS has no classes or structs. If you are using ACS you have to make do with just arrays and global/world arrays(which are more dynamic). As an alternative, there are also ACS bytecode compilers such as BCC and GDCC that support more advanced features. Within custom acs functions, you may not use any functions that delay or may delay the execution of the code. If you need delays/waiting in your routine, you have to use a script for it. Keep in mind that you can have multiple instances of a script running by using ACS_ExecuteAlways or ACS_ExecuteWithResult or their named variants, so it's possible to have multiple other scripts or functions re-use the same script at more or less the same time. As for your example script, you could make it re-usable by multiple instances with ACS_ExecuteWithResult by keeping in memory the state of each door. // Using a dynamic world scope array to make tagging easy, but // the array should be initialized in an open script to prevent // old values from previous levels from carrying over. world int 1:doorState[]; //0=closed, 1=busy #define DR_CLOSED 0 #define DR_BUSY 1 // Use with 84:ACS_ExecuteWithResult(3, controlSectorTag, switchHeightMapLookupIndex) script 3 (int controlSectorTag, int switchHeightMapLookupIndex){ switch(doorState[controlSectorTag]){ case DR_CLOSED: // Door is closed if(checkPlayerDoorProximity( switchHeightMapLookupIndex)){ doorState[controlSectorTag] = DR_BUSY; FloorAndCeiling_RaiseByValue (controlSectorTag, 12, 64); PlaySound(switchHeightMap[switchHeightMapLookupIndex][2],"doors/dr1_open"); Delay(144); FloorAndCeiling_LowerByValue (controlSectorTag, 12, 64); PlaySound(switchHeightMap[switchHeightMapLookupIndex][2],"doors/dr1_clos"); TagWait(controlSectorTag); doorState[controlSectorTag] = DR_CLOSED; } else { SetResultValue(0); //Prevent switch animation } case DR_BUSY: // Door is busy default: SetResultValue(0); //Prevent switch animation } } Note that ACS_ExecuteWithResult will return a result value as soon as the script starts waiting or ends. So you can't use SetResultValue after a delay or wait.

Not standalone tools, but some FPS-roguelites such as Eldritch, Strafe and Tower of Guns feature some random level generation. Also there is 7 Days to die, an open-world survival FPS game, which has a random world generator that generates all the landscape and towns, though it uses randomized prefabs for buildings and other points of interest.

In the texture browser you also have the context menu option to export a texture made of multiple patches to a single PNG file.

Something to keep in mind when helping out someone asking for help in these forums, is that even if the person who started the thread turns out to be a jerk or something, if their problem is legitimate, there may very well be other people with the same problem, who may find help in your replies to the original poster. So unless it is something very specific, you are likely to help more people than just the person asking the question.

It could make sense for something like the Surface Duo, when it comes out.

Good point, I've edited my post accordingly.

If you mean the original wall line and the line of the new dummy sector that is drawn over it, then the answer is: you don't prevent it, but instead you adjust the new dummy sector floor and ceiling heights to be at the height level where you want the vertical split to be, so that there is no space between the floor and ceiling. After this you usually have to re-texture the line, since the new dummy sector will have erased the middle texture, and the new wall will actually be using an upper and a lower texture. You may also notice that both the upper and lower texture in the line will use the same offsets. This is a limitation of the doom map format, and you can't do much about it aside from changing 'Upper unpegged' and 'Lower unpegged' flags and hoping that it looks better. (UDMF map format however supports separate upper and lower texture offsets.)

When I want to stick to the grid and/or not adjust the linedef lenghts or sector heights, I usually split the textures horizontally or vertically, and then adjust the offsets if necessary. Horizontal splits: Vertical splits: Sometimes it may require multiple splits in the same linedef to get some of the textures to look decent. Edit: Added info on hiding the dummy sector of the vertical split.

Actually you can, there is this old quirk with pickup sprite names which seems to be barely documented anywhere, but may require some swapping of items for best effect:

Yeah, you should not have duplicates of SKY1 in the texture list, to make sure that the correct one is loaded. (It will load the first one with the matching name in the texture list.) Also the sky texture should be 256x128, just like the original sky texture definitions in Heretic.

This most likely is happening if your TEXTURE1 still contains the original switch texture with the same name. The game is then loading the original texture instead of your custom texture that is further down the list. To fix that, you gotta either: A) Delete the original texture, so that there are no duplicate texture names, leaving just your new texture. B) Edit the original texture and replace its contents with your custom patches. C) Edit the original texture to be wider, and include your custom patches in the added width, this way you can have both the original and the new switch texture, but you gotta play with the wall lenghts and texture offsets to make it work.

If you really need to visit some website, yet can't stand the ads, using a browser extension that lets you write custom javascript or CSS can at least help hide the ads.

The solution posted by Gez seems most appropiate for this scenario. There's another trick that can be done with custom bridge things, but you should really just use the correct 3D midtexture line flag here and disable the default impassable flag.

435 points, made it to level 3, then spent too much time in the blue, oops.

Just make every jump deal 1% damage and play a windows error sound; that should work for everyone.