*** The "ask a miscellaneous editing question" thread ***

It appears that the first and foremost search result in Google for the search "Making a map for DOOM" is the webpage for Doombuilder2.. It's no wonder that those new to mapping will download DB2, use it and think no further about it.

In the DoomWiki, when searching for "Editor", there is no mention of any editor beyond Doombuilder2. Maybe someone could rectify that. I tried to fix it, but I cannot log in anymore.

The result is that countless times we have to draw attention to the fact that DoombuilderX, GZDoom Builder, GZDoom Builder Bugfix and Ultimate Doom Builder exist. I should not leave out Slade3 or Eureka.

I made some tutorials about starting to map, but they are contained in the tutorials sections of the Doomworld and ZDoom forums, but those sections seem to be unintuitive to access.

With Decorate, is there a way to make it so a weapon dropped by an enemy gives the same amount of ammo as when it's normally picked up? I have a weapon that gives 1 ammo and it appears to be getting rounded down to 0 when dropped.

edit: I solved it by making the weapon give 0 ammo, and replacing the drop with a CustomInventory item that grants the weapon and some ammo.

On lundi 1 juin 2020 at 12:55 AM, plums said:

With Decorate, is there a way to make it so a weapon dropped by an enemy gives the same amount of ammo as when it's normally picked up? I have a weapon that gives 1 ammo and it appears to be getting rounded down to 0 when dropped.

Yes.

DropItem Chaingun, 20

DropItem Shotgun, 8

Simple question (should be a part of the "basics" I still have to learn ;-) ):

I have a big monster closet with about 30 cacodemons inside. Once they are alerted seeing the player, they fly above a walkover line of type 126 "WR Teleport /mon" to teleport to another place in the room to make the ambush less predictable.

However, the majority of the cacodemons (around 20) simply fly straight to the player, ignoring the teleport line.

How can I fix this? I already tried it with a second teleport line behind the first one (attached to another tag/sector) in the case one of the monsters blocked others from reaching the teleporting spot, but that seems not to solve the problem. Both teleport linedefs point to the original position of the cacos.

Maybe has it to do with the cacodemons themselves (because they fly and do not "walk", but aren't they infinitely tall?)? I have another similar ambush in another place with other monsters and there it works perfectly ...

50 minutes ago, erzboesewicht said:

Simple question (should be a part of the "basics" I still have to learn ;-) ):

I have a big monster closet with about 30 cacodemons inside. Once they are alerted seeing the player, they fly above a walkover line of type 126 "WR Teleport /mon" to teleport to another place in the room to make the ambush less predictable.

However, the majority of the cacodemons (around 20) simply fly straight to the player, ignoring the teleport line.

How can I fix this? I already tried it with a second teleport line behind the first one (attached to another tag/sector) in the case one of the monsters blocked others from reaching the teleporting spot, but that seems not to solve the problem. Both teleport linedefs point to the original position of the cacos.

 

Maybe has it to do with the cacodemons themselves (because they fly and do not "walk", but aren't they infinitely tall?)? I have another similar ambush in another place with other monsters and there it works perfectly ...

Cacos teleport just fine, but even 2 lines might not be enough to have them clear the landing spot fast enough. Perhaps the better alternative would be to make an isolated sector, long but just one caco wide and join it (J in Doom Builder 2, probably others as well) with one of the sectors nearby. The sector in room should be selected first. Now cacos will wake up when you fire a gun in the room and all you need is a teleport line that would release them. If room is one caco-wide they'll all make it to the pad as they move back and forth.

Of course it won't quite work if it's your opening act. Perhaps a few single-use lines to flank player while majority of cacos fly from their original position would be a better fit.

That is very useful! So that is the reason why many Doom maps have these ultra-long and narrow sectors in the void, I always wondered about that ... I interpret that this basically means that the "landing spot" is a pretty small thing and must be totally cleared for other monsters to appear there. Thanks, that solves it!

@Alper002: Awesome tutorial, thanks!

@erzboesewicht, I think it'd be helpful for you to know of this tutorial to get to grips with teleport closets like that in detail.

Can I make a switch stay on or off until I trigger the script again, from the same line(toggle switch)?

10 minutes ago, aletheos eberlain said:

Can I make a switch stay on or off until I trigger the script again, from the same line(toggle switch)?

What you can do, is give the switch line in question a tag/id. Then, you can make sure the line special put on it is not repeatable. Then, after each time the script has been executed, use SetLineSpecial to give the line the script execution action again.

This works because when an action is not repeatable, Activating the line special simply removes the action from the line. Also, since the line is not set to repeatable, it never tries to switch back to it's original texture like repeatable switches do.

18 minutes ago, Alper002 said:

[Some brilliant fucking advice]

Thank you! This is going to be so amazingly useful, especially when I combine it with ANIMDEFS switches.

What exactly happens when floor raises by shortest texture? My assumption was that it will go 128 units up (If textures are all 128 units) but something else happens instead on my sector that is close to a wall.

I want to make a reverse Dead Simple where you first fight arachnotrons then mancubi rise from the floor.

Edit: Found the answer, there's a placeholder texture that is 64 units high. Keeping message in case someone saw it and wonders too.

Ok I give up, and gotta ask this stupid question. Using Ult Doom Builder. Can you select a group of sectors without it grabbing things too. I thought I had this one figured out in the past, but it's been re-bugging me for ages now. I've looked through all the settings... and if it exists, I'm not seeing it. :p

@Doom_Dude

@Dragonfly

Ahhh thanks man. I knew I had that figured out before. I probably even asked in this thread before. lol I'll probably loose that little button again, no doubt. ;)

It's cool, I forget where it is all the time, too. Took a couple of mins to find it again :P.

What's wrong here? I've perfect cube-model made in blender (or not made it is there when you start the program).
On modeldef I scaled it up with 64 64 64 resulting 128x128x ??? on Doom? As you can see height isn't right. ZScript height 128, radius 64.
Is this that pixelratio nonsense? I've set pixelratio to 1.0. What problems that will arise..

Also top and bottom doesn't render properly on Ultimate doom builder while in game it's ok:

UV-map (difference to upper pics, changed white to black..)

Why model? They are easier to put into a map, don't break map geometry, they can be pushed and destructed. While rotated ones causes another problem..

Do GZDoom and other limit-removing ports also remove the limit of 255 sector tags? I probably won't hit the limit, as I'm only at 153, the map is nearly complete, and I the only major thing I need more tags for are another 45-60 tags for (monster only) teleport destinations.
 
Also, another question: Why, for the love of .WAD, are each brick layers in the GSTONE texture different heights? I wanted to make a setpiece where it looks like a GSTONE wall had several bricks knocked out of it, but the inconsistent layers make it nigh-impossible to line up the texture with the holes.

On 6/4/2020 at 3:19 PM, erzboesewicht said:

Simple question (should be a part of the "basics" I still have to learn ;-) ):

I have a big monster closet with about 30 cacodemons inside. Once they are alerted seeing the player, they fly above a walkover line of type 126 "WR Teleport /mon" to teleport to another place in the room to make the ambush less predictable.

However, the majority of the cacodemons (around 20) simply fly straight to the player, ignoring the teleport line.

How can I fix this? I already tried it with a second teleport line behind the first one (attached to another tag/sector) in the case one of the monsters blocked others from reaching the teleporting spot, but that seems not to solve the problem. Both teleport linedefs point to the original position of the cacos.

 

Maybe has it to do with the cacodemons themselves (because they fly and do not "walk", but aren't they infinitely tall?)? I have another similar ambush in another place with other monsters and there it works perfectly ...

Have you considered having multiple teleport destinations, and segment the teleporter line so that different segments will go to different destinations? That will help spread them out even better. I use that a few places when I want a monster closet to scatter its contents across a map.

3 hours ago, Stabbey said:

Also, another question: Why, for the love of .WAD, are each brick layers in the GSTONE texture different heights? I wanted to make a setpiece where it looks like a GSTONE wall had several bricks knocked out of it, but the inconsistent layers make it nigh-impossible to line up the texture with the holes.

Have you tried unpegging texture around it? You'd need to still align the hole manually of course, visual mode might help.

On dimanche 14 juin 2020 at 1:49 PM, Jaska said:

On modeldef I scaled it up with 64 64 64 resulting 128x128x ??? on Doom? As you can see height isn't right. ZScript height 128, radius 64.
Is this that pixelratio nonsense? I've set pixelratio to 1.0. What problems that will arise..

Remember about aspect ratio? For in-game geometry, pixels are vertically 20% taller than they are wide. That means that if you make a 128x128x128 cube out of map geometry, it will not actually be a cube. (You want an actual cube, you make it 128x128x107. Well, technically, it should be 128x128x106⅔ to be really cubic but that's not really possible. 106 gives you 127.2, 107 gives you 128.4.)

If you put your 128x128x128 model cube next to it, the model will remain a cube but be shorter. Why are models not scaled vertically like the rest? Because models were most likely not made for Doom's wonky aspect ratio.

Basically, try pixelratio 1.2.

4 hours ago, Stabbey said:

Do GZDoom and other limit-removing ports also remove the limit of 255 sector tags?

Yes.

4 hours ago, Stabbey said:

Also, another question: Why, for the love of .WAD, are each brick layers in the GSTONE texture different heights? I wanted to make a setpiece where it looks like a GSTONE wall had several bricks knocked out of it, but the inconsistent layers make it nigh-impossible to line up the texture with the holes.

IIRC @Jimmy made a "fixed" version of this texture somewhere, along with other troublesome brick textures.

5 hours ago, Stabbey said:

Do GZDoom and other limit-removing ports also remove the limit of 255 sector tags? I probably won't hit the limit, as I'm only at 153, the map is nearly complete, and I the only major thing I need more tags for are another 45-60 tags for (monster only) teleport destinations.

The limit in limit-removing is 65536 (-32768 to 32767, though editors will show this as 0-65535), it was never 255, even in vanilla Doom. This includes tag 0, unless you are using GZDoom where it assigns 0 to special behaviour. You are thinking of Hexen-format maps, which has a data limit of a single byte to linedef arguments, thus physically can't address tags past 255 from linedefs though it still can from ACS.

hightag.zip

4 hours ago, Gez said:

Remember about aspect ratio? For in-game geometry, pixels are vertically 20% taller than they are wide. That means that if you make a 128x128x128 cube out of map geometry, it will not actually be a cube. (You want an actual cube, you make it 128x128x107. Well, technically, it should be 128x128x106⅔ to be really cubic but that's not really possible. 106 gives you 127.2, 107 gives you 128.4.)

 

If you put your 128x128x128 model cube next to it, the model will remain a cube but be shorter. Why are models not scaled vertically like the rest? Because models were most likely not made for Doom's wonky aspect ratio.

 

Basically, try pixelratio 1.2.

Oh damn.. Got back to this and I just had the pixelratio in a wrong place. I had it on GameDefaults instead of DefaultMap. 1.0 works fine now.

9 hours ago, Stabbey said:

Do GZDoom and other limit-removing ports also remove the limit of 255 sector tags? I probably won't hit the limit, as I'm only at 153, the map is nearly complete, and I the only major thing I need more tags for are another 45-60 tags for (monster only) teleport destinations.
 
Also, another question: Why, for the love of .WAD, are each brick layers in the GSTONE texture different heights? I wanted to make a setpiece where it looks like a GSTONE wall had several bricks knocked out of it, but the inconsistent layers make it nigh-impossible to line up the texture with the holes.

 

Don't know if these are how you like it but here is GSTONE variant:

What governs offset for blinking lights (1/2 Hz non-synchronous). Is it random? Sometimes I feel it's dependent on my point of view and not objective at all.

7 hours ago, ViolentBeetle said:

Have you tried unpegging texture around it? You'd need to still align the hole manually of course, visual mode might help.

I did, but when you align a texture the whole thing moves, you can't align upper and lower parts separately as far as I know.

I re-tried again making sure to set all lines to both unpegged and aligned everything else based around that alignment, and I did get something which looked acceptable.

I hadn't actually been expecting a response to that part, it was more of just a rant.

1 hour ago, Jaska said:

 

Don't know if these are how you like it but here is GSTONE variant:

I found a work-around for my problem, but thank you. I'll take a look at that thread if I decide I need to replace some textures. The one on that last page is the vine variant, which doesn't work aesthetically in this underground area, but I haven't checked the other 50 pages yet.

5 hours ago, Edward850 said:

The limit in limit-removing is 65536 (-32768 to 32767, though editors will show this as 0-65535), it was never 255, even in vanilla Doom. This includes tag 0, unless you are using GZDoom where it assigns 0 to special behaviour. You are thinking of Hexen-format maps, which has a data limit of a single byte to linedef arguments, thus physically can't address tags past 255 from linedefs though it still can from ACS.

 

hightag.zip

Good to know, I just thought I'd check and make sure. It's not like I could run this map in vanilla doom anyway:

1 minute ago, Stabbey said:

I did, but when you align a texture the whole thing moves, you can't align upper and lower parts separately as far as I know.

Well, you can't do it separately, but if both are unpegged, both a drawn from the ceiling, so they will at the very least be aligned with each other, so you can make holes in the walls in peace.

3 hours ago, Stabbey said:

when you align a texture the whole thing moves, you can't align upper and lower parts separately as far as I know.

3 hours ago, ViolentBeetle said:

you can't do it separately, but if both are unpegged, both a drawn from the ceiling, so they will at the very least be aligned with each other, so you can make holes in the walls in peace.

You can align them both separately in UDMF, but not in vanilla or Boom. I don't know about Eternity or DiH.

Has anyone done a big post on the mechanics of exploding barrels? I searched and didn't find a topic specifically on that.

I've determined that an exploding barrel can detonate another exploding barrel 244 units away from it (measured center to center), and at 248 units away, the second barrel just gets pushed slightly, but does not take enough damage to detonate.

I'm trying to do a suspense-building trick where I use crushers to detonate barrels, which fling corpses of monsters into various rooms, so the player is spooked by the mysteriously appearing corpses that weren't there before. I made a test map to try and figure out how many barrels something needs to die, and I used that information to create my map. However, it isn't working as planned.  Instead, the monsters get pushed through the teleporter lines alive.

The difference seems to be that in the test, the monsters were in isolated small closets, and in the actual map, it's one big long room, with one crusher activating a "fuse" that detonates other barrels in the chain. (The player doesn't witness the monsters arriving, so the slight delay from the propagation of the explosion is acceptable. I can use null space to separate the chains from contaminating each other, but I would still like to know more about the mechanics.

Detonating a thousand barrels at once makes GZDoom stutter even on my Doom Eternal-capable machine, and still doesn't seem to kill the enemies. It seems that stacking explosive barrels on top of each other absorbs some amount of the blast damage, but not all of it. 176 things in 11 piles of 16 kills a Baron of Hell, but 180 stacks of 1 barrel packed closely together and spreading out to up to 11 barrel-widths away will not kill the baron. I'd like to know how many barrels I need.

EDIT: I've gotten it down to 128 barrels in stacks of 6 or 7, no farther than 72 units away (center to center), but can I reduce it further?

...I tried playing around with smaller stacks farther apart, but that only increased the number of total barrels needed.

Surface area seems to matter as well, as a Mancubus can be taken down with a mere 20 barrels, but an Arachnotron, with a collision box apparently larger than its damage hitbox seems to need 44.

Bizarrely, Revenants seem to be ridiculously difficult to kill with barrels - at least spread out ones. On the other hand, placing three stacks of 128 barrels right next to them also fails to kill them. There is clearly a point of diminishing returns for stacked barrels, or some kind of cap or hard limit.

I'm still struggling to perfect my "teleport monster corpses" idea. After a lot of work, I've gotten it to largely work most of the time to teleport all the corpses... but it doesn't happen ALL the time.

Sometimes a monster is killed but not pushed over the line. Other times a Mancubus (or rarely, the Hell Knight) is pushed over, but not killed. It seems like there's wide variant in the damage from barrel explosions thanks to the RNG engine. I'm not sure what I can do to make the corpses teleport every time. I absolutely want to avoid the possibility of the monster teleporting still alive.

Other than continuing to tinker with number of barrels and exact placement of the monster's center relative to the teleport line, is there any advice anyone can think of?

EDIT: I've added more solid walls to ensure the explosion comes in from one angle, and re-aligned the barrels to match the gap. It's still largely working, but I am still getting edge cases where that Mancubus on the right either dies but doesn't get pushed, or gets pushed and doesn't die.

Oh ****. Changing pixelratio messed all my previous model's scaling of course. Now I have to rescale ~470 models and their collision 3d-sectors or stick to old pixelratio and scale y-axis there. Luckily I haven't used all models yet... Wonder why I didn't see messed y-scales earlier.. So frustrating. For sure this draws motivation down.

12 minutes ago, Jaska said:

Oh ****. Changing pixelratio messed all my previous model's scaling of course. Now I have to rescale ~470 models and their collision 3d-sectors or stick to old pixelratio and scale y-axis there. Luckily I haven't used all models yet... Wonder why I didn't see messed y-scales earlier.. So frustrating. For sure this draws motivation down.

There's probably a simpler alternative.

You needed pixelratio just for that cube, right? Then you can remove it to get things back to how they were before and use MODELDEF to scale your cube with the scale property.