EE and CChest2.wad Map24

[kristus]

I played Community Chest 2's Map24 in EE and at one point you can't progress in it, because a door switch won't work.
The only reason I can think of why it doesn't work is because the line in front of it got a horizontal texture scroll def on it.
I tried messing with compat flags to possibly deal with it, but since I was running with them all turned off. It really shouldn't be giving me any grief.

The Linedef No. is 9094.

[Grazza]

Yes, known issue (of the "Zdoomism" variety). This special linedef needed the passthru flag, but it never got it. IIRC, this was pointed out to BPRD before the wad was released but the change never got made. He didn't seem to appreciate why it was necessary.

So as things stand, it only works with Zdoom (or compatibles), or Prboom-plus with the relevant "compatibility with common mapping errors" setting enabled. That isn't a standard Boom or MBF option, of course.

I think someone also released a fixed version of the map as a pwad for demo-recording purposes, in tn31fix style.

[Quasar]

I will consider this, but it treads in that dark territory of redefining what is valid game data by modifying the program to accept erroneously made stuff :P I don't like going very far down that road.

[kristus]

Having a scrolling texture line in front of a switch hardly should be considered "erroneous" IMO. It's a non action linedef.

[printz]

kristus said:

Having a scrolling texture line in front of a switch hardly should be considered "erroneous" IMO. It's a non action linedef.

According to Boom, it should have the Pass-thru flag. It was pretty much Boom that set the standard. While they were at it, they could have made the scrolling linedefs innocuous to the Use button just like how they allowed simultaneous but independent floor and ceiling movements. But they didn't, and they let it to the mapper's freedom, by letting them use the Pass-thru bit wherever needed.

[esselfortium]

Heh. Slope lines, light transfers, and such have the same issue. I was pretty confused for a while trying to figure out why a couple of switches in one of my Vaporware maps were either not working or only working from very close up, until I remembered that the ceiling slope lines in front of them needed passthru. -_-

[printz]

Slopes? Which SVN? They're already in? Do they have the same specials as ZDoom?

[Gez]

printz said:

Slopes? Which SVN? They're already in? Do they have the same specials as ZDoom?

Yes, since r645 (well, it wasn't working then, but they're working now; the most recent tweak to te slope code was a bugfix in r913), and not exactly.

In Doom map format (no args for specials), the slope specials are:
{ 386, "Slope_FrontsectorFloor" },
{ 387, "Slope_FrontsectorCeiling" },
{ 388, "Slope_FrontsectorFloorAndCeiling" },
{ 389, "Slope_BacksectorFloor" },
{ 390, "Slope_BacksectorCeiling" },
{ 391, "Slope_BacksectorFloorAndCeiling" },
{ 392, "Slope_BackFloorAndFrontCeiling" },
{ 393, "Slope_BackCeilingAndFrontFloor" },

{ 394, "Slope_FrontFloorToTaggedSlope" },
{ 395, "Slope_FrontCeilingToTaggedSlope" },
{ 396, "Slope_FrontFloorAndCeilingToTaggedSlope" },

[Mordeth]

Slopes. O dear god...

















So, how does this work?

[Gez]

The slope linedefs work by aligning a sector (front or back) to reach the height of another (back or front) along the linedef.

The floor, the ceiling, or both can be sloped. The various linedefs listed above correspond to the possible combinations.

ZDoom instead has a single special (181:Plane_Align) but it requires Hexen format or UDMF because it uses parameters. ZDoom also has slope things (doomed nums 1500 and 1501), but they don't appear to be supported by Eternity.

[esselfortium]

Indeed. Slope things, vertex slopes, and other methods of sloping will most probably be added once UDMF is supported in Eternity. With the standard Doom map format, it's not really feasible in a way that wouldn't be hacky to implement and equally hacky to work with.

It's also worth noting that slopes currently only exist to the renderer. As far as the rest of the game is concerned, they're still flat surfaces. This means you can use them for fancy, elaborate architecture all you want (and this is really the fun part anyway), but their usage for ramps and such is comparatively limited.

[Graf Zahl]

Gez said:

ZDoom instead has a single special (181:Plane_Align) but it requires Hexen format or UDMF because it uses parameters.

How about this then?

340 = 0,		Plane_Align (1, 0)	// Slope front floor
341 = 0,		Plane_Align (0, 1)	// Slope front ceiling
342 = 0,		Plane_Align (1, 1)	// Slope front floor and ceiling
343 = 0,		Plane_Align (2, 0)	// Slope back floor
344 = 0,		Plane_Align (0, 2)	// Slope back ceiling
345 = 0,		Plane_Align (2, 2)	// Slope back floor and ceiling
346 = 0,		Plane_Align (2, 1)	// Slope b.f. and f.c.
347 = 0,		Plane_Align (1, 2)	// Slope f.f. and b.c.

[Gez]

Point. I see Eternity chose different values, which is a bit annoying.

[Graf Zahl]

AFAIK the ZDoom values were already used for other things. But that shouldn't be a big issue. I could add the Eternity values to ZDoom's translation tables so that there's a compatible way to define slopes that works in both ports.

Too bad that for portals it's not that easy because many of those values are already taken up by other things in ZDoom.


BTW, how do the types 394-396 work? These are something that ZDoom does not (yet) support in this fashion - but it's probably easy enough to add.

[Mordeth]

Graf Zahl said:
BTW, how do the types 394-396 work?

That's the part that confused me too.

[Graf Zahl]

Gez said:

{ 394, "Slope_FrontFloorToTaggedSlope" },
{ 395, "Slope_FrontCeilingToTaggedSlope" },
{ 396, "Slope_FrontFloorAndCeilingToTaggedSlope" },

I had to take a look at the source to see what these do. It's simple slope copy operations so these names are not that great.

[SoM]

Graf Zahl said:

I had to take a look at the source to see what these do. It's simple slope copy operations so these names are not that great.

No the names in the source actually kinda suck. If you want better names for what the line specials do, SL has an updated DoomBuilder2 config.

Edit: Also it should be noted that I used the same method of determining sector 'extent' that zdoom does (so mappers who are used to the zdoom method can use EE slopes without problems)


As for the copy specials:

394 - Copies the floor slope of a like-tagged sector to the frontsector of the line with the special.

395 - Copies the ceiling slope of a like-tagged sector to the frontsector of the line with the special.

396 - Copies both the floor and ceiling slope of a like-tagged sector to the frontsector of the line with the special.

I made the copy-line specials work this way so sector tags in-map could still be used for more important things like portals and doors and lifts and such.

[SoM]

Mordeth said:

Slopes. O dear god...

I know, I'm sorry mordeth. I'm so sorry.

[Graf Zahl]

SoM said:

I made the copy-line specials work this way so sector tags in-map could still be used for more important things like portals and doors and lifts and such.

So effectively they act like ZDoom's Copy Slope things? Ok, I think I'll add them to ZDoom anyway. Maybe someone making maps that should work with both ports will find them useful.

[printz]

Graf Zahl said:

I could add the Eternity values to ZDoom's translation tables so that there's a compatible way to define slopes that works in both ports.

You'd probably add redundant entries to your data tables because:

- most ZDoom maps are of Hexen format or UDMF, you wouldn't really need more Doom format linedefs;
- Eternity maps very likely have other EE-unique features (like EDF) so they won't work with ZDoom anyway.

If the map in question is for ZDoom-Doom format (rather unlikely) or Eternity format, and only using slopes, I then find it odd that the author chose to take a port just to use slopes and nothing more.

Anyway, the 394-396 linetypes really are interesting, and they would save me lots of trouble, because I don't know how to make vertex/thing slopes work...

@Gez and SoM: Mind if I copied some from your posts into the wiki? It's in editing reference/line types/slopes.

[Graf Zahl]

Can't you imagine someone wanting to make a map that's not ZDoom-exclusive but add some advanced features?

At the moment the only common ground is plain Boom.

But if you do Eternity/ZDoom projects you could already use 3DMidtex lines, decorative slopes and some limited portals and still target both ports, provided that both expose the feature to the mapper using the same methods. I think that is worth supporting.

Concerning the 3 copy line types, they are functionally identical to ZDoom's copy slope things. The only difference is that instead of placing such a thing in the sector to copy the slope to you tag one of its linedefs instead.

[Gez]

printz said:

@Gez and SoM: Mind if I copied some from your posts into the wiki? It's in editing reference/line types/slopes.

Why would I mind? All I did basically was open my Eternity project in VC++, hit Shift+Ctrl+F and entered "slopes" then copy/pasted from the results a chunk of code that seemed relevant.

[SoM]

@Gez and SoM: Mind if I copied some from your posts into the wiki? It's in editing reference/line types/slopes.

Have you done this yet? Where's the article?

[Gez]

You mean that?
http://eternity.youfailit.net/index.php?title=Slope_linedef_types