[r540M, old bug] Inert decorations sink through bridges

[Kate]

This one is quite obvious, I'll give a visual demonstration:

In the editor


Note how the torch is set to sit on the platform. The items on the platform are held up by bridge things, so naturally they should sit on top of them.

In-game


The torch spawns on the floor instead. The other inert decorations, bodies and such, do this too.

[Kate]

Cloning the objects via DECORATE and setting the CANPASS flag on them fixes the problem. Case of missing flag?

Just out of curiosity, if the standard solid decorations were set to be CANPASS by default (Unless where it would be needed to stop mapping errors where objects would accidently overlap and sit on top of one another, though I doubt there are many situations where this can happen), what would the performance hit be approximately? I doubt it would be too bad for most faster computers nowadays, heh.

[Graf Zahl]

This is not about performance hit. This is solely about the overlapping problem you mentioned. If that wasn't there this flag would not be necessary.

[Kate]

What about an option or compat flag for this then if it wouldn't be much trouble to add? "Decorations are height-sensitive (Default: Off)" then it could be specified on a per-map basis without having to worry about existing maps breaking unless it's left on. It'd be much simpler to have a compatibility option instead of having to replace all of the existing doom/doom2/etc. decorations for a few custom maps.

Of course if it turns out to be too much of a problem, it's something that can be lived without. Either way, this should probably be closed with a [Can't fix], or [Resolved] if you plan on putting in said compat option.

EDIT: Nevermind. Just the last line applies.

[HotWax]

A MAPINFO flag would be better.

[Nash]

I agree with Hotwax. If the mod needs it, the author should have the power to set it in MAPINFO.

[Graf Zahl]

The compatibility option won't be added. Compatiblity options are there for reenabling old, normally unwanted behavior in case a fix necessitates some incompatibility. That's not the case here. If you absolutely have to you can define your own items that behave as you need them to.

The option would be useless anyway because it would also cause the bridges themselves to stand on each other - and that's something you most certainly do *not* want.

[Kate]

*scratch scratch*

Forget everything I said.

Instead I back up the MAPINFO Option suggestion. That's what I should've said in the first place.

This is what happens when I lack sleep for a long period of time.

[Graf Zahl]

Wasn't I clear enough when I said that any such option would render the bridges themselves unusable? That means: No MAPINFO option.

[Kate]

You clearly misread. I only meant for this to affect the stock decorations, not all objects.

[Graf Zahl]

More hackery. No, thank you!

[Kate]

Okay, okay! Nevermind. [Can't fix]. Not such a big deal. Sheesh.

Edit: Okay, let me try this again, in a more timely manner. I'm dropping this issue and am waiting for it to be closed. Do not bother the topic. Thank you.

[Gez]

The only non-hacky way would be to change the items themselves in the pk3. You (SnowKate) could do that and then test a lot of wads (starting with full playthrough of the unmodified four Doom iwads) to see if it negatively affects existing maps. If it does, you've got no choice but to drop the issue.

[farhaven]

besides,what is the problem in adding the CANPASS flag to the decorations you use in your pwad? that only takes what? 5 minutes,and that includes going to the toilet and getting a fresh mug of coffee

[Kate]

besides,what is the problem in adding the CANPASS flag to the decorations you use in your pwad? that only takes what? 5 minutes,and that includes going to the toilet and getting a fresh mug of coffee

The problem is that the behavior isn't consistant with the usual standard behavior of objects like items and monsters being able to fall on top of other objects, thus the behavior was completely unexpected and doesn't really make any sense.

But since changing this would result in some extremely funky behavior (trust the Programmer to shed some light), it'd be better left unchanged.