NEW feature: line specials activated by moving polyobjects

I've just added a new feature: linedef specials which can be activated by polyobjects which move (or sweep) over them. This practically means that a polyobject can now move over an area, triggering all sorts of effects as it advances, such as doors opening, lights going up etc. It cannot teleport yet; that may be added later as an argument for the Teleport parameterized specials. But otherwise, it works by checking if the polyobject's centre point (not the spawn spot, but the average of the vertices!) passes over the linedef. This means that even rotating polyobjects may trigger linedefs.

To implement it in ExtraData: set the POLYOBJECT|CROSS extflags.
To implement it in UDMF: set polycross = true; for the linedef.

Example wad which uses a polyobject to call ActivatorSound and operate a door in ACS. To move it, press any of its east, north or west sides (if one doesn't work, try another!).

As always, you may have to wait for the next build to be published on http://devbuilds.drdteam.org/eternity.

The factory possibilities ';,,;'

<3 printz; this is too awesome. I want to hear more about the specials it can do, but from the sounds of it, player-only triggers may not be player-only anymore :)

printz said:

the polyobject's centre point (not the spawn spot, but the average of the vertices!)

Why that choice?

It's a compromise. If the choice was the spawn spot, rotating polyobjects wouldn't activate anything, so I chose the center point, so that it will still move with the rotation if the spawn spot is eccentric.

Fonze said:

but from the sounds of it, player-only triggers may not be player-only anymore :)

Didn't you read it? It implements a completely new and discrete activation type for this. This certainly won't trigger any existing actions, or it'd be a major mod breaker.


Gotta try that myself, I wish a mod like Super Sonic Doom had had such an option or a lot less things would have ended up broken in there.

printz said:

It's a compromise. If the choice was the spawn spot, rotating polyobjects wouldn't activate anything, so I chose the center point, so that it will still move with the rotation if the spawn spot is eccentric.

What about the "front" vertice relative to the polyobject's direction of movement? Or what about to allow any vertice of the polyobject to activate the line, but then disable that polyobject's ability to re-activate that line until the polyobject stops overlapping the line, in case the line's action is repeatable.

Graf Zahl said:

Didn't you read it? It implements a completely new and discrete activation type for this. This certainly won't trigger any existing actions, or it'd be a major mod breaker.


Gotta try that myself, I wish a mod like Super Sonic Doom had had such an option or a lot less things would have ended up broken in there.

I meant actions typically reserved for players like floor movers, not necessarily the exact triggers/action numbers themselves.

Fonze said:

I meant actions typically reserved for players like floor movers.

They haven't been reserved to players since Boom - and especially not since Hexen. Don't think so vanilla! :D

Graf Zahl said:

They haven't been reserved to players since Boom - and especially not since Hexen. Don't think so vanilla! :D

Hehe, yes; you're right.

This is really exciting news though.

scifista42 said:

What about the "front" vertice relative to the polyobject's direction of movement? Or what about to allow any vertice of the polyobject to activate the line, but then disable that polyobject's ability to re-activate that line until the polyobject stops overlapping the line, in case the line's action is repeatable.

I will see about that when I get demands from mod authors. So far I've chosen a simple and yet flexible enough model.

I think that mucking around with the current simple approach is only going to make this thing more messy instead of more powerful. Even for actors tiggering a special only the center matters, why should this be different?

Probably because polyobjs tend to be much larger than actors, and you don't really see people building stuff to be triggered by spider masterminds.

I still think the main attraction here is to have the ability to get controlled triggering of an action depending on the polyobject's position and for that the center spot sounds like the best option because mathematically it produces by far the least mess. If you start using vertices it will get tricky. Should it only trigger on map-placed vertices or also on ones used for splitting sidedefs into segs, for example - or what if the vertices entirely bypass the trigger line on both sides - then nothing will happen at all!

Crateline

Sorry I could not get the sky or scrolling floor script working despite many tries.

Pinchy said:

Crateline

Sorry I could not get the sky or scrolling floor script working despite many tries.

Thanks for the map! The issues that I've seen in your wad are:
1. You're trying to use a classic-style texture patch as the sky, instead of a full texture. To make it work, use TX_START...TX_END instead of PP_START...PP_END. The method you tried to use actually requires some additional lumps copied and modified from the IWAD, which are PNAMES and TEXTURE1 and are trickier to maintain, but in this case, just replace PP_... with TX_... (Just so you know, the P_/PP_ prefixes are purely conventional and are ignored by Doom).

2. The polyobject-activated line is too far off behind. You need to make sure that the centre point of the polyobject crosses through it. To avoid uncertain situations, also make sure that the final position of polyobject's centre doesn't lie exactly on the line, but behind it. Since you've put more vertices to the right of the polyobject, the centre point will be pulled more to the left than the apparent centre of the square.

In general, the central coordinates aren't accurately the same as the centroid (centre of mass) of a polygon in math. Instead, they're merely the average of the polyobject's vertex coordinates. Only the vertices in the editor are counted; the ones added by the node builder (if applicable) are ignored.

Hey thanks for the reply, here's what I've done:

1 - Fixed the sky with the entry rename
2 - Moved the polyobject lines triggered by the moving battery so that when the battery stops it cannot be overlapping the polyobject at all. Then added a fine tuned tics based delay to that script so it activates at the exact moment it stops in the slot as before.

http://www.mediafire.com/file/jv9ifbnt5ackj6l/

I don't know what to do about the scrolling floor lines not working:

Scroll_Floor(11, 16, 0, 1);
Scroll_Floor(1001, 16, 0, 1);
Scroll_Floor(1002, 16, 0, 1);

These are meant to just scroll the grates at the same speed as the crates as to give the appearance the belt is turning on.

You could join the IRC like Altaz for feedback there as well.

As I explained, there are two versions of Scroll_Floor and EE only has the line version, which is static init (runs once at map start). I'm trying to figure out how to deal with this but EE just doesn't seem to be able to let you override a line special on that based on caller, and given that the line is static init, you can't even call the function past the first instance of the map being run. This might not be an issue if it weren't for the fact that the function with the code 223 is already used (or will by, by CheckWeapon). I'm trying to figure out a fix but this is really bloody annoying.

printz is usually in #noteternityenginerelated.

EDIT: I have an idea! Working on it now. It'll be a decent chunk of effort but it paves the way to be able to better handle similar instances in future.

I think I was sent a version outside of the forums so I'm putting the link here as a record.

Cratline

I'll try out new features when I get the chance - Had a real tough map to finish lately in my own project.