Heretic Moss Problem

[Lutz]

As I mentioned, I am trying to polish up an old Heretic level, and have run into a problem with the moss and hanging skull objects. I have two sectors (call A them C) separated by a thin (< 32 units) sector B. If I place a moss object in sector B but then trigger a "lower floor" action that affects sector C, the moss object jumps down and sticks to the floor of the lowering sector and ends up hugging the ground (ditto for the skulls). Has anyone seen this before? Are there any solutions/work-arounds?

BTW, for the moment I've only tested this is ZDoom [version something relatively recent; not the absolute latest, though].

[andrewj]

How much vertical room is in sector B?

Try making sector C (the one which lowers) 1 unit lower than sector B.

[Lutz]

The lowering sector needs to have a floor higher than the ceiling of the narrow sector so as to hide some bad guys. From the side, the sectors start like this:

 -----------|   |-----|
            |   |     |
            |   |  C  |
            |   |-----|
            |---|
      A       B |
 -----------|---|

...and should end up like this:

 -----------|   |-----|
            |   |     |
            |   |     |
            |   |     |
            |---|     |
      A       B    C  |
 -----------|---|-----|

I suppose I could try turning sector C into an elevator and raising the ceiling and floor together, but I don't know if that would solve anything, either.

[Gez]

I'd suppose it's because of the objects' radius that makes them partly in sector C. Try moving them away, or creating a DECORATE variant with a smaller radius.
The moss actors and the various skulls have a radius of 20, which means they need to be at least 20 units away from a sector in order not to be within it. Amusingly, the hanging corpse has a much smaller radius.


Note that an object considers that its ceiling height is the lowest ceiling of all the sectors it is in, and its floor height the highest floor of all all the same sectors.

[Lutz]

Gez said:

I'd suppose it's because of the objects' radius that makes them partly in sector C

I assumed that was part of the problem, but that doesn't explain (to me, anyway) why a ceiling clinger would snap to the floor. I get that they might snap to the lowest ceiling out of A, B, or C, but not why an object attached to the ceiling "lets go" and falls...

[andrewj]

Gez said:

I'd suppose it's because of the objects' radius that makes them partly in sector C.

Yes almost certainly.

Moving them away from the line is probably the only thing you can do and stay Vanilla compatible (the code suggests that setting the line to block monsters might work, but I'm guessing that would mess up your gameplay).

UPDATE: It falls because once sector C starts moving, it finds the highest floor to consider itself "on the floor" (which is now sector C), and "onfloor" things always rise and fall with their floor

[Lüt]

Object jumping has been a recurring ZDoom-specific issue for me. One map I was doing had a large round pillar with torches on top spread in 2 rings, a large outer one of small red torches and a smaller inner one of large red torches. All were "overlapping" as far as actual object width was concerned (though the sprites themselves weren't). At one point, the pillar was to rise a few stories to signify completion of the zone. The torches worked fine in every other port, but in ZDoom, they began piling on top of eachother in a giant shifting stack that rose some 384 pixels up to the sky, and kept bouncing up and down between that entire floor-to-ceiling gap until the pillar finally reached its top height and stopped moving, then they all fell back into place.

The general rule of thumb is, don't test in ZDoom unless you're building a ZDoom specific map. A while ago, we had so many maps coming through /newstuff that didn't work in their intended port because the author only tested in ZDoom and accidentally made something that could only work in ZDoom that reviewers just settled for putting "DOES NOT WORK IN INTENDED SOURCE PORT" instead of doing a review. ZDoom changes much core functionality, and the changes aren't considered "bugs" even when they break things that originally worked, so you'll likely be stuck with solving such compatibility issues if you want the map to work in multiple boom-based ports.

But there aren't many other options. If you want a Boom-based port with the closest thing to how the original game would function, I'd recommend bugging Quasar to hurry up with Heretic support in Eternity :P

[Gez]

Lüt said:

ZDoom changes much core functionality, and the changes aren't considered "bugs" even when they break things that originally worked

It depends whether the original behavior is, itself, caused by a bug or not. There were plenty of times when a discrepancy between vanilla and ZDoom, after being reported on the ZDoom bug forums, led to a change in the ZDoom code to either reestablish vanilla behavior globally or through a compat flag.

I.e., for an example related to this one, the radius of the Hexen small and large flames was reduced to 15 to fix a problem in Deathkings of the Dark Citadel (one of the flames in the chimney of the first map did not descend with the rest of the platform), the Hexen jumping height has been decreased, the character classes have obtained the NODMGTHRUST flag, in Heretic the pods have had their push code changed so that they'd be pushed as far as they did in vanilla by the pod generators, a compat flag has been added for minotaur floor fire on floorclipping terrain, and so on.

Make a small vanilla wad that illustrates the problem (works in vanilla, doesn't work in ZDoom), attach it to a new thread in the bugs forum explaining the issue, and you'll get either the problem addressed directly or, if it's not considered to be a bug, you'll usually be given a workaround on how to obtain the same behavior as vanilla in your map (without hurting compatibility with other ports).

[Quasar]

Lüt said:

But there aren't many other options. If you want a Boom-based port with the closest thing to how the original game would function, I'd recommend bugging Quasar to hurry up with Heretic support in Eternity :P

To be honest EE's Heretic support is not that pure, due to the fact that I ended up writing so much of the support from scratch while the code was still under lock and key. But, that being said, I have done some work recently to improve compatibility issues, now that I have Choco Heretic breathing down my neck ;)

Telling me to hurry may not help much though. Keep in mind I am crazy about Heretic; it's one of my most favorite games period. But what it's waiting on is a fundamental rewrite of a very large and important portion of the game engine (the weapon system) and that's so arduous that I don't even like to think about it >_<

[kristus]

Any decorative entity that doesn't block would be best suited as 1 unit wide.

[Graf Zahl]

Gez said:

Make a small vanilla wad that illustrates the problem (works in vanilla, doesn't work in ZDoom), attach it to a new thread in the bugs forum explaining the issue, and you'll get either the problem addressed directly or, if it's not considered to be a bug, you'll usually be given a workaround on how to obtain the same behavior as vanilla in your map (without hurting compatibility with other ports).

You know, some people prefer to whine and complain instead of being constructive with such issues.

[Lüt]

Quasar said:

To be honest EE's Heretic support is not that pure, due to the fact that I ended up writing so much of the support from scratch while the code was still under lock and key. But, that being said, I have done some work recently to improve compatibility issues, now that I have Choco Heretic breathing down my neck ;)

Yeah I knew about the rewrites, but I figured you'd be replacing them with the original code as soon as you could get it.

Personally, as long as portals are working, I can (re)design my maps first and worry about monster/ammo balance once they're all done, which may take a while since I'm doing 3 episodes, so no rush necessary on my end ;)

Graf Zahl said:

You know, some people prefer to whine and complain instead of being constructive with such issues.

What's to whine and complain about? You've made it quite blatantly clear that these interaction systems were changed intentionally and won't be reverted back. Stuff works different on purpose, and I'm just explaining that to him.

[Gez]

Lüt said:

You've made it quite blatantly clear that these interaction systems were changed intentionally and won't be reverted back.

Not all of them.

[Graf Zahl]

Lüt said:

What's to whine and complain about? You've made it quite blatantly clear that these interaction systems were changed intentionally and won't be reverted back. Stuff works different on purpose, and I'm just explaining that to him.

The original code is broken beyond repair. How else can things work that shouldn't to begin with?

Each time problems like this get reported and I check them out it's only bugs in the engine that make things work like they do.

Still, if you find a problem, please report it instead of making another 'ZDoom sucks' (intentional exaggeration!) post. Sometimes it is actually possible to address such problems!

[kristus]

Speaking of compat flags. Are they possible to activate with the mapinfo lump?

[Gez]

kristus said:

Speaking of compat flags. Are they possible to activate with the mapinfo lump?

Most of them, yes.

[Graf Zahl]

Speaking of MAPINFO, why this for compat_anybossdeath?

"There is no MAPINFO name for this option; new levels should not use it."

With the same reasoning most other compat flags also shouldn't be exposed. The main reason these were added is so that end users can create MAPINFOs for PWADs that can fix compatibility issues without having to set them manually. This one's no exception .

The only ones that were intentionally not added are options that have detrimental effects on how the engine behaves (wallrunning or silent BFG for example.)

[Lutz]

Why can't everybody play nice...?

Anyway, thanks for the help. Hopefully, I will not spark more sniping, but for the record: is a ceiling clinger snapping to a nearby moving floor considered a "bug" or a "peculiarity" or what? Also (since I'm currently at work and cannot test it right away), what happens to a ceiling clinger if the ceiling of the sector it's in starts moving?

[Gez]

Lutz said:

for the record: is a ceiling clinger snapping to a nearby moving floor considered a "bug" or a "peculiarity" or what?

Does it happen with vanilla as well? You're the one with the map, and unless it's in Hexen map format or UDMF you should be able to try it with DOSBox and other ports such as jHeretic.

[Vermil]

What Lutz is describing is simply a peculiarity in the Vanilla engine. ZDoom and Doomsday are both port's which retain it.

If a ceiling hanging mobj over laps two sectors and the floor of one of them, for whatever reason, raises/lowers past the ceiling of the other, the ceiling hanging mobj will lose its ceiling hanging property.

Lutz said:

what happens to a ceiling clinger if the ceiling of the sector it's in starts moving?

When a ceiling moves down, any ceiling hanging mobjs move down with it. When a ceiling moves up, any ceiling hanging mobj's will not move up with it and hence simply float in mid air. Another peculiarity retained by most ports.

[EarthQuake]

Vermil said:

When a ceiling moves up, any ceiling hanging mobj's will not move up with it and hence simply float in mid air.

That's really quite interesting! I never knew Vanilla Doom did that, although I knew there were problems with things catching on the edges of nearby raising/lowering walls. Does anyone know the specifics behind the "spawn on ceiling" thing flag? To me it sounds like it doesn't actually connect the thing to the ceiling, but rather spawns it there (as the flag name suggests), and (maybe?) flips on the NOGRAVITY bit.

Also, does the Doom Wiki have this listed as one of Doom's bugs? ...Regarding the ceiling spawner issue, that is.

[Gez]

EarthQuake said:

To me it sounds like it doesn't actually connect the thing to the ceiling, but rather spawns it there (as the flag name suggests)

Yup. It's not to be confused with the CEILINGHUGGER flag (which is used at least in Hexen for one component of the mage's lightning). The FLOORHUGGER and CEILINGHUGGER flags are put on projectiles which are expected to travel across several sectors and therefore encounter elevation changes. But SPAWNCEILING decorations are supposed to stay where they are forever, and the issue of changing ceiling heights has not been thought off.

That is why I was talking about testing it in Vanilla, as everybody else (except Andrew J who looked up the Heretic source code) was busy saying it's ZDoom's fault because it fixed bugs and it shouldn't fix bugs because it's bad yadda yadda -- it turns out it's one of the vanilla bugs that ZDoom didn't fix.

[Graf Zahl]

Gez said:

it turns out it's one of the vanilla bugs that ZDoom didn't fix.

If I'd ever fix this I would make the fixed behavior depend on a flag.

[Gez]

Well as far as ZDoom is concerned, a simple decorate lump in the mod with "actor newmoss1 : moss1 replaces moss1 { radius 1 }" (repeat line as appropriate for other concerned actors) is all that's needed to eradicate the bug in the mod. There are similar workarounds for other ports with EDF, DDF, even HeHackEd.

[Vermil]

EarthQuake said:

Does anyone know the specifics behind the "spawn on ceiling" thing flag?

All the spawn ceiling flag does is spawn the mobj on the ceiling of the sector at map start up. Nothing else.

For instance a mobj with the spawn ceiling flag will also need the no gravity flag to actually stay up there. Else it will imediately fall to the ground after the map has started.

[Creaphis]

This thread gave me the urge to make a demo wad but in the process it kind of became off-topic.

(Heretic e1m1, vanilla or ZDoom.)

[Gez]

Creaphis said:

This thread gave me the urge to make a demo wad but in the process it kind of became off-topic.

(Heretic e1m1, vanilla or ZDoom.)

Odd. The effect is broken in GZDoom, though (and I'd suppose other GL renderers).

[Graf Zahl]

I can't do much about it. Changing this would cause more problems than it'd solve.

[Creaphis]

At least the blue one still works, which is most relevant to this thread anyway. I noticed a while ago that once a key marker sphere is spawned it has no further association with its base or with floor or ceiling heights, and will not move until it is physically pushed by the floor or ceiling.

[Vermil]

Gez said:

Odd. The effect is broken in GZDoom, though (and I'd suppose other GL renderers).

Actually, GZDoom seems to be the only OpenGL port that can't do this effect.