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

[Jaska]

15 minutes ago, Gez said:

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.

 

 

Yeah, after first shock that's what I'm going to do. However I will propably now see all other models being on wrong aspect ratio.

[ViolentBeetle]

On 7/25/2020 at 4:18 PM, Stabbey said:

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.

Try making a really big stack of barrels in the final explosion. Literally occupying the same spot.

 

So far it mostly worked for me.

[Stabbey]

I made some sectors, and a control sector in the null space. I added another sector next to the null space control sector with a different floor texture and 1 unit higher. I joined all the sectors together into one (except the one with a different floor texture), and put in a line with effect 22: W1 Raise Floor to Next Higher floor (changes texture). The floor correctly raises, but the texture does not change.

 

I thought this might be because some of the sectors I made had non-participating sectors enclosed inside. So I bridged the gap and merged the sectors so that the interior and exterior of my special sectors were one sector. But that didn't fix my problem with the non-changing floor texture. I don't know why. Is there a minimum height difference needed for the sector to change?

 

EDIT: I did a work-around, by instead having the sector which moves be the one surrounding the sectors, but I still don't know why the first way I attempted it did not work.

 

EDIT 2: WTF is wrong with this idiotic line special?! I had a different line with the same special trigger sectors tagged with 224, and in one instance I'm having it raise platforms from slime to connect to platforms with a metal floor texture, but instead the platforms end up with a completely different texture. ... EDIT 3: It's the texture of the sector the line is pointing into.

Edited August 7, 2020 by Stabbey

[Weird Sandwich]

Currently trying to make an outdoors map to learn how the sky texture works, is there a way to stop this from happening:

 

 

Trying to make doors and windows on buildings, the obvious solution seemed to be lowering the height of the surrounding sky to match the building height. But then the sky texture cuts into other buildings like this. Is there a way to work around this in DoombuilderX, or do I need to resort to lowering building heights, blocking LOS, etc?

[Alper002]

Nothing you can do about that, assuming you're using a limited mapping format like the vanilla one. In Boom format you could use action 242 in combination with a dummy sector to make it look as though there's a ceiling inside while there's technically a big hole in actuality(though there'll be other problems to work around if you do this). In ZDoom-based ports you can use 3d floors to better get around this as well.

 

Editor tends not to matter with regards to what you can do, what matters more is usually the sourceport compatibility you're developing for.

[Weird Sandwich]

Thanks for the quick reply!

 

I want to stay vanilla for now, so I guess I'll just need to get creative with LOS.

[aletheos eberlain]

What is going on here?

Spoiler

Why do I get these errors, and why does everything seem to work as intended anyway?

 

This is the contents of the DECORATE lump

Spoiler

actor ExplosionSpawner : SwitchingDecoration 25001 {
	+NOCLIP
	+NOBLOCKMAP
	+NOGRAVITY
	
	States {
		Spawn:
			TNT1 A -1
			Stop
		Active:
			TNT1 A -1 ACS_ExecuteAlways(139, 0, args[0], args[1], args[2])
			Stop
	}
}

actor ExplosionFX {
	+NOCLIP
	+NOBLOCKMAP
	+NOGRAVITY
	
	States {
		Spawn:
			MISL B 0
			MISL B 6 Bright A_PlaySound("misc/brainexplode")
			MISL C 5 Bright A_Explode(128, 128)
			MISL D 4 Bright
			Stop
	}
}

 

 

[Alper002]

GZDoom.pk3 contains the definition to the thing you are inheriting from, as well as the sprite TNTA1. Those errors are caused when it's not loaded in GZDB/UDB. Add them to the game configuration and exclude them from testing parameters to fix the errors.

 

The reason it works just fine when testing is because gzdoom loads gzdoom.pk3 by default at all times.

[Stabbey]

What on earth is happening here in this shot I took of my map running on a PRBoom+ port?

 

There's nothing fancy here, no tricks or anything. That HoM effect shouldn't exist, it's just plain BRICK10 texture on a single-sided wall. It looks fine in GZDoom, but for no apparent reason, it's all messed up in PRBoom+.

 

 

EDIT: SOLVED

 

While I'm at it, I've got another PRBoom+ problem: I have some sectors adjacent to each other, which I am trying to use the "floor raise to lowest ceiling" action to instantly drop them, and one is joined to a separate sector. Unfortunately, while this works in GZDoom, only one of them actually lowers, the rest stay in place. Any idea why?

Edited August 14, 2020 by Stabbey

[ViolentBeetle]

If you move your geometry around too much, sometimes builder bugs out and sets something incorrectly. GZDoom corrects it during the game but other ports don't. Try switching to "Make sectors" mode and click vigorously all over problematic area. At least that's how it worked for me.

 

The only scenario for the second problem I know of is that if monsters are clipped inside the geometry, they will block sectors from moving on ports other than GZ Doom. Indeed GZ Doom corrects a lot of issues.

[Stabbey]

15 minutes ago, ViolentBeetle said:

If you move your geometry around too much, sometimes builder bugs out and sets something incorrectly. GZDoom corrects it during the game but other ports don't. Try switching to "Make sectors" mode and click vigorously all over problematic area. At least that's how it worked for me.

 

The only scenario for the second problem I know of is that if monsters are clipped inside the geometry, they will block sectors from moving on ports other than GZ Doom. Indeed GZ Doom corrects a lot of issues.

 

Well, you solved my second problem, that's good.

 

Make Sectors in that area didn't help. Maybe I need to click more sectors around, not just the ones bordering the problem area?

[Stabbey]

Different question: If there is a monster-only teleport line, but the destination sector has a monster blocking line that would be within the interior of the monster if it were to teleport, would a monster crossing it teleport anyway and get stuck, or would the teleport completely fail to happen?

 

EDIT: Actually I think I already know the answer, as monsters will happily teleport into spaces too small for them and get stuck even when it's a solid wall blocking them.

[ViolentBeetle]

Monster will happily teleport into the wall, but won't teleport into impassable things, be it other monsters, player, barrels or decorations (I think decorations would qualify too, this one I never saw in the wild). Exception is MAP30 where it will telefrag the destination (Except I guess for decoration).

 

As for the make sector clicking, the goal is to force editor to recalculate what's on the sides of all problem linedefs. If that doesn't help, I don't know what does.

[Stabbey]

I decided to make the monster-only teleport lines 1-time only, and make the other lines in the sector monster-blocking lines to ensure the enemy crossed them.

 

All the make-sector-clicking didn't do anything. This (in GZDoom) is what it's supposed to look like. I'm not doing anything exciting with the walls there. They're just broken for no reason that I can see in prBoom+.

[Edward850]

Post the map. Diagnosing screenshots is too restrictive as the issue could be a long list of things.

[Stabbey]

32 minutes ago, Edward850 said:

Post the map. Diagnosing screenshots is too restrictive as the issue could be a long list of things.

 

Okay. It's ready for beta-testing anyway.

 

 

The section in question is through the teleporter in the "north-east" door from the octogon.

[Edward850]

@Stabbey You have used the flat texture SLIME13 on the walls in that room. This can't be done under Boom-compat as the renderer wasn't capable of swapping these texture types (flats and walls are two completely different kinds of graphics in Doom, as they required two different methods of rendering). Wall textures can only be used on walls, flats can only be used on floors and ceilings. As such, prBoom+ just draws nothing as it can't find a wall texture called SLIME13.

[Stabbey]

3 hours ago, Edward850 said:

@Stabbey You have used the flat texture SLIME13 on the walls in that room. This can't be done under Boom-compat as the renderer wasn't capable of swapping these texture types (flats and walls are two completely different kinds of graphics in Doom, as they required two different methods of rendering). Wall textures can only be used on walls, flats can only be used on floors and ceilings. As such, prBoom+ just draws nothing as it can't find a wall texture called SLIME13.

 

Thanks, that was probably a copy-paste error I missed because the texture is identical. I don't deliberately use flats for walls or walls for flats for that very reason.

 

EDIT: I found and fixed* a second instance of that sort of thing in the northwestern courtyard.

 

*Fixed will be in the next beta update.

Edited August 15, 2020 by Stabbey : just in case someone wants to point it out

[Jayextee]

Is it at all possible to entirely-remove options from GZDoom's menus?

I played a bit of a free game, Solace Dreams lately, which does this; running on an older version of GZDoom. This game had some beautiful polish, including very to-the-point menus containing only what the game itself required; no scrolling through two entire screens' worth of control options to cherry-pick the relevant ones whilst trying to guess which of the zillion mod-friendly options won't be needed this time, just the stuff the game itself has.

 

However, playing this game's data with an up-to-date version of GZDoom sticks all of the game's stuff at the bottom, past a --- divider, after all the now-extraneous fluff. It's horrific, and messy, and actually undoes a lot of the polish the game established IMO. I want to make a game eventually using GZDoom, but if I require the player to swim through a couple dozen options they shouldn't be using in my game, then I wouldn't consider it fit for purpose. Which is a shame, I like the port otherwise.

[Gez]

You can rename the generic "options menu" to something like "pointless power user settings" and make your own "options" menu containing just what you feel is needed.

[TheHambourgeois]

i cant find WILV or CWILV type lumps in heretic, does it just autogenerate the level names based on the strings and the graphical alphabets? ive never actually bothered changing the level names in an HHE patch/thinking about changing the intermissions screens for vanilla editing before lol

e: also why is my sky doing this?


here's what i have in slade: all the patches are 256x200 8bpp. One thing I notice that I am guessing is related is my sky patches are exactly 1kb larger than the heretic defaults (i.e. the heretic skies are 52.26kb and my patches are 53.26kb).

Edited August 18, 2020 by TheHambourgeois : new problem as well so might as well tack it on

[Stabbey]

I sometimes get this glitch when playing my maps in GZDoom: the map sees other, distant sectors through walls. I built the map using Ultimate Doom Builder.

 

 

This is a problem with the map's nodes, right? How can I fix it? I had something similar on a different map which I ran through ZokumBSP, but that didn't fix it.

 

 

****

 

Unrelated, another question. Is there some good way to make a sector tagged with a "blinking" sector effect to go to a steady illumination? The best I could think of was to fake it by using multiple sectors and a door opening to the fullbright effect, but if possible, a simpler way would be better.

Edited August 20, 2020 by Stabbey : second question

[Gradius]

So I'm trying to use voodoo-dolls and merged sectors to create a fairly simple effect in Boom-compat Doom 2: You hit a switch, and through some walk-repeatable trigger lines, it triggers some platforms to raise to a specific level, then descend back down to a set level slightly above the floor. Except with either Floor Lower to Nearest or Floor Lower to Lowest (which particularly confuses me) the floor will lower to my desired height... then after a second it drops down below that to the lowest floor. I even tried adding slightly higher surrounding sectors to the sectors around the 'real' floor instead of relying on my dummy floor... but it still descends past them even though they're the nearest floor. It's like by having dummy sectors the line gets triggered a second time after the first second finishes moving. Is there any way to avoid this behaviour? I'll attach the wad.

plattest.zip

[plums]

On 8/16/2020 at 12:54 PM, TheHambourgeois said:

i cant find WILV or CWILV type lumps in heretic, does it just autogenerate the level names based on the strings and the graphical alphabets?

Yeah. The ExMy part is included in the level name, and the intermission screen just lops that part off. I don't think any ports other than Chocolate/Crispy Heretic even support HHE patches so for compatibility you'll also need some kind of MAPINFO lump.

 

On 8/16/2020 at 12:54 PM, TheHambourgeois said:

e: also why is my sky doing this?

First of all, Heretic skies are hacky, and the textures should be 128px tall, with the patches still 200px tall. Look how it works in heretic.wad for an example.

 

Apart from that, recent versions of SLADE break up tall graphics so that Doom displays them properly, but this causes problems with Heretic. I guess there's still no way to turn that off, so use SLADE 3.1.1.5 or older. See @Gez's post here for an explanation:

 

 

 

[plums]

1 hour ago, Gradius said:

So I'm trying to use voodoo-dolls and merged sectors to create a fairly simple effect in Boom-compat Doom 2: You hit a switch, and through some walk-repeatable trigger lines, it triggers some platforms to raise to a specific level, then descend back down to a set level slightly above the floor. Except with either Floor Lower to Nearest or Floor Lower to Lowest (which particularly confuses me) the floor will lower to my desired height... then after a second it drops down below that to the lowest floor. I even tried adding slightly higher surrounding sectors to the sectors around the 'real' floor instead of relying on my dummy floor... but it still descends past them even though they're the nearest floor. It's like by having dummy sectors the line gets triggered a second time after the first second finishes moving. Is there any way to avoid this behaviour? I'll attach the wad.

plattest.zip

 

Remember that the actual sectors (as opposed to the control sectors) are also near floors.

 

There are lots of ways around this. The easiest one that comes to mind: you could use a generalized action to make them lower by shortest lower texture, and then put some textures on the control sectors that are the height you want them to move.

[Gradius]

16 minutes ago, plums said:

 

Remember that the actual sectors (as opposed to the control sectors) are also near floors.

 

There are lots of ways around this. The easiest one that comes to mind: you could use a generalized action to make them lower by shortest lower texture, and then put some textures on the control sectors that are the height you want them to move.

Which was why I added notches, so that the actual sectors' nearest floors were still at the correct height. Which make the behaviour, that effectively looks like it triggering twice, odd. Still, the generalized action route seems like less of a headache.

 

Edit: Lower by texture just causes weird wiggling before it finds the correct height. Now I'm wondering if my woes are from the voodoo doll legitimately retriggering the effect. Thought I had the timing down enough that this couldn't happen that quickly, so I'll cut a window between those areas and... yeah. The lift I have to let the doll move isn't closing in time to trap it back in the starting area. Argh. There's probably workaround I could do to prevent the doll from teleporting to the start before the lift is closed, but the amount of time the puzzle will take should even that out.

 

It's always the simple errors... and I thought I'd accounted for that too. :/

Edited August 21, 2020 by Gradius

[TheHambourgeois]

9 hours ago, plums said:

 

thanks a ton, I actually checked it at both texture sizes incase that was the culprit cause i did look at the iwad and serpent's wake as an example but obviously didn't figure it out if the issue is on slade's end

[Zolgia108]

i would like to ask a general opinion on this:

1) instadeath floors (when and why)

2) fast damaging floor (when and why)

 

im using them quite often in my wip wad, and i noticed that nobody likes them, i can accept that and can totally remove them, but i would like to understand why. Instadeath are there because some of the pits are meant to be unescapable. Fast damage is because it is more threatening and punishing.

 

[Stabbey]

A player, with skill, can dodge projectile attacks, evade melee attacks, and mitigate the damage they take from hitscanners. There is counter-play there. There is little to nothing a player can do to mitigate mandatory damage from a damage floor. It's not very fun to be killed by something you have no way to avoid taking damage from.

 

Why do you feel the need to make pits inescapable? Players can accept taking damage if they make a mistake and fall in, and have to move to get out, but having to restore back to the last save which is who knows how far back, without any recourse can feel unnecessarily punishing.

 

So my answers to your questions are:

 

1) Never. There should also never be inescapable pits.

2) Very rarely, these belong most often when there's a section you don't want to block off from the player or monsters, but don't want the players wandering around in.

[El Inferno]

How to rotate the grid in UDB?