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

[Gez]

35 minutes ago, scifista42 said:

(SLADE3 has the column labels swapped).

No longer!

[Zemini]

I can use the ExMx code for my maps even if they load up on the Doom2 wad right?  I can also use MAPXX within the same one or will that confuse the game?  Would like to know before I change everything. I am doing this so I can organize my maps easier.

 

Also, what is a good episode length?  I know D1 had 8 levels (Plus a secret level) but I am aiming for 5 levels, plus a final boss hell level as a climax to the episode.

Edited May 9, 2017 by Zemini

[Dragonfly]

So I have a lot of 3D floors here, but items are not spawning on top of these 3D floors and all instead decide to float in mid air with no relation to the height set. This is happening despite having a Z-height set to above the height of the 3D floor. Interestingly though, the dynamic lights from these actors are displaying in the CORRECT locations. Screenshots:

 

 

 

 

 

UPDATE:

 

After further investigation I am none-the-wiser, but the floating objects are way above where they were and are almost where intended. Some of them actually ARE where they should be:

 

 

[everennui]

I have link sectors set to Floor_LowerByValue and everything works as one piece. Now I need to find out how to crush the player. There is nothing like ceiling_raiseandcrush or floor_lowerandcrush that I can use in the master control linked sector. I tried using various other combinations of crush, but it didn't work/elevator breaks. I can't even think of how to do this.

 

On the bright side my elevator can no longer be broke! ...but I really would like to figure out this crusher. I'd be more than happy to donate my map snippet as a sample wad for posterity sake if I can figure it out.

[everennui]

12 minutes ago, Dragonfly said:

So I have a lot of 3D floors here, but items are not spawning on top of these 3D floors and all instead decide to float in mid air with no relation to the height set. This is happening despite having a Z-height set to above the height of the 3D floor. Interestingly though, the dynamic lights from these actors are displaying in the CORRECT locations. Screenshots:

 

 

 

 

 

UPDATE:

 

After further investigation I am none-the-wiser, but the floating objects are way above where they were and are almost where intended. Some of them actually ARE where they should be:

 

 

I don't think they need a z-height. Maybe having one is throwing it off. Go into visual mode and use the mouse scroll and shift to get them where you want them.

[Dragonfly]

Thanks for the suggestion @everennui, but the mouse scroll is what gives them a Z-height. :)

 

I came back to say I fixed it! It was due to the size of the hitboxes - the very edges of the items were clipping into an outer 3D floor, causing them to incorrectly position themselves. Moving the items a couple of map pixels away from the 3D floors that build up the wall made them act as expected. :D

 

 

[Gez]

34 minutes ago, everennui said:

I don't think they need a z-height. Maybe having one is throwing it off. Go into visual mode and use the mouse scroll and shift to get them where you want them.

What do you think a Z-height is? :p

[everennui]

6 minutes ago, Gez said:

What do you think a Z-height is? :p

I guess I never noticed that the texts fields for the Z position changed. :/

[Nevander]

1 hour ago, Dragonfly said:

I came back to say I fixed it! It was due to the size of the hitboxes - the very edges of the items were clipping into an outer 3D floor, causing them to incorrectly position themselves. Moving the items a couple of map pixels away from the 3D floors that build up the wall made them act as expected. :D

If you hadn't posted this, it was what I was going to say actually. If you notice in your first picture, the hitbox edge of the bonuses are inside the outer wall. Unfortunately in Doom, the entire actor is considered a box and will stick to edges even if the logical center (the sprite only) is well within the space. One solution is to redefine the actor's height and radius to be only the exact size of the actor, however that would require you to modify the original actor of course. Your solution was the most efficient, but it may get tricky with spacing if you want them exactly centered on each platform if the platforms are small enough.

[scifista42]

9 hours ago, everennui said:

There is nothing like ceiling_raiseandcrush or floor_lowerandcrush that I can use in the master control linked sector.

Why not? As far as I know, it's the right way to do it and possibly the only way.

[Gez]

10 hours ago, Zemini said:

I can use the ExMx code for my maps even if they load up on the Doom2 wad right?  I can also use MAPXX within the same one or will that confuse the game?  Would like to know before I change everything. I am doing this so I can organize my maps easier.

 

Also, what is a good episode length?  I know D1 had 8 levels (Plus a secret level) but I am aiming for 5 levels, plus a final boss hell level as a climax to the episode.

If you target a port with MAPINFO then yes it should be fine.

 

As for a good length for an episode, 5 or 6 levels sounds just fine. Chex Quest has five level episodes, for example. Really the length of an episode depends on how long each map is, and how many maps there are in total. Like if you have 36 maps and you put them into 12 episodes of 3 maps each, it's going to be a bit overkill; but on the other hand three-map-long episodes could work if you had a total of nine or twelve maps.

[torekk]

Can anyone tell me why the left structure works with a floor lower linedef, but the right one doesn't?

 

Both structures are inside a room, so they're both enclosed in another sector. They also have the correct height value for the floor/ceiling, however it seems those inner angled walls are something that doom doesn't like? Or is this some mystery magic going on with Eureka Doom Editor?

[scifista42]

The problem can't be in the angles. A stuck thing might be blocking sector movement, or one of the inner sectors adjancent to the moving structure has such a height that influences the movement (depending on whether you've using "Floor lower to lowest floor" or "Floor lower to highest floor" etc.).

[torekk]

The linedef type is S1 Floor down LEF, and the problem was a stuck actor. The bigger square on the lower right on the right side is a mancubus, I mean in theory it should be fine but practically one of it's edges is touching the structure's linedef. After moving the mancubus a bit, it works however as intended.

[scifista42]

Oh, so the inner squares are things and not sectors. The one that touches the structure's edge is definitely the source of the problem, then.

[everennui]

That moment you figure out crushing 3D Floors.

 

 

Generic_Floor

Edited May 10, 2017 by everennui

[Spectre01]

I just noticed this bad boy testing in software mode. There's supposed to be a wall there and the 'tron floor rises up. Looks fine in GLBoom+.

 

[Phade102]

1 hour ago, Spectre01 said:

I just noticed this bad boy testing in software mode. There's supposed to be a wall there and the 'tron floor rises up. Looks fine in GLBoom+.

 

While I cant help you, maybe uploading a picture of the editor view, as well as a picture of how it works normally? it could be a software renderer issue?

[Spectre01]

Looks like this in the editor and in GL-based ports.

[Albertoni]

12 hours ago, Spectre01 said:

in GL-based ports

Had the same problem a while back. The solution was to change the nodebuilder. Tools -> Game Configuration -> Choose your format on the left -> Nodebuilder, then switch both to ZDBSP - Normal (zero reject).

 

---------------------------

 

Alright, so this sky looks real weird on software while GZDoom looks as intended. I wanted to know if there's an easy way to fix it.

 

https://www.dropbox.com/s/avzinge73u4zgmg/IdleDoom.wad?dl=1

[Spectre01]

I've just tried that @Albertoni and still getting the same bug. Not the only place either as I first though. I'm guessing that's a slime trail in the first image and I have no idea what's happening in the 2nd one. Thanks software mode, I just wanted to map.

[Albertoni]

You could post the map, you know. Being able to see is better than guessing :P

[Bauul]

I'm really struggling to clear a line action in ACS (UDMF), and would love some advice!

 

Say I have a linedef with the tag 7, and I want to clear its action using a switch elsewhere, would this script do it?

 

script 1 (void)
{
	SetLineSpecial(7, 0);
}

It just seems to do nothing at all.  Anyone any ideas?

 

Edited May 12, 2017 by Bauul

[scifista42]

The script should work, so the possibilities are:

1. The line's tag isn't 7 (sometimes people confuse it with linedef index).

2. The script isn't compiled.

3. The script's intended trigger doesn't activate the script (use PrintBold in the script to see if it gets activated).

4. The line action that you want to clear is one of the types whose effect cannot be cancelled by clearing it, like Static_Init.

Edited May 12, 2017 by scifista42

[Bauul]

7 minutes ago, scifista42 said:

The script should work, so the possibilities are:

1. The line's tag isn't 7 (sometimes people confuse it with linedef index).

2. The script isn't compiled.

3. The script's intended trigger doesn't activate the script (use PrintBold in the script to see if it gets activated).

4. The line action that you want to clear is one of the types whose effect cannot be cancelled by clearing it, like Static_Init.

Thanks, I'll try those out. The action is 156: Line_SetPortal. Can you recall if that's one that can't be cleared? 

[scifista42]

Line_SetPortal is a static effect and so it can't be cancelled by clearing it, but you can use https://zdoom.org/wiki/Line_SetPortalTarget to swap portal destinations dynamically.

[Albertoni]

99% sure you can't clear that one. Just 99% though.

 

 

Anyway, reposting my problem since it got buried helping other people:

This sky looks real weird on software while GZDoom looks as intended. I wanted to know if there's an easy way to fix it.

 

https://www.dropbox.com/s/avzinge73u4zgmg/IdleDoom.wad?dl=1

[Bauul]

5 minutes ago, scifista42 said:

Line_SetPortal is a static effect and so it can't be cancelled by clearing it, but you can use https://zdoom.org/wiki/Line_SetPortalTarget to swap portal destinations dynamically.

Thanks, as soon as you said there were some actions that couldn't be changed I knew that was it.

 

Annoyingly I'm not trying to redirect the portal, but simply remove it altogether. What I could do is build another portal immediately at it's back, and redirect to that. Close enough that the player doesn't realize they're walking through a portal.

 

Ok, sounds like a plan. Thanks for the quick reply! I was going blind staring at that script trying to work out what I'd done wrong!

[scifista42]

14 minutes ago, Albertoni said:

This sky looks real weird on software

I'm not sure how you mean it. I couldn't run the map in ZDoom, but I looked at it in GZDoom's software mode and it seemed normal to me. You can't have the "vanish into a single color when looking up or down" effect in the software renderer.

8 minutes ago, Bauul said:

Annoyingly I'm not trying to redirect the portal, but simply remove it altogether.

Not sure if it's going to work, but try setting "targetline" to "0" in Line_SetPortalTarget.

Edited May 12, 2017 by scifista42

[Albertoni]

7 minutes ago, scifista42 said:

I'm not sure how you mean it.

Compare these pictures. Software GZDoom first, hardware GZDoom second. Sorry for the huge attachments.

Spoiler