Did you know you can make a voodoo conveyor belt in vanilla Doom

6 minutes ago, Revae said:

If something deals 0 damage it no longer pushes right?

Correct. Also, to avoid unnecessary confusion, hurt floors deal damage, but don't have an impact on player inertia.

the 0 damage problem is exactly the reason why the current setup uses 2 mikoveyors, because when dealing 1 damage to the player on hntr or above it also means the very same barrel will deal 0 damage on itytd - and not move the player at all. At first I thought it's an easy fix, because I can just move the barrel closer, deal 2 damage (1 on itytd), and get away with it. And actually in some cases that's certainly feasible, but anything at least slightly "scripted" will take much longer to occur when the doll is only pushed by 1 damage instead of 2, so it fucks up the entire timing.

Does negative damage produce inertia? Could you have a throwaway monster that fires a negative damage fireball to pull the player off a ledge, while healing him? It would cost a monsters projectile in dehacked, but just a thought.

19 minutes ago, Revae said:

Does negative damage produce inertia? Could you have a throwaway monster that fires a negative damage fireball to pull the player off a ledge, while healing him? It would cost a monsters projectile in dehacked, but just a thought.

Wouldn't matter if it did or not as it produces more serious issues. For vanilla purposes, negative damage is logistically unusable.

1 hour ago, traversd said:

Yeh did think that, could even start the sequence maybe as a player runs over a damaging floor earlier in the map?

Yes, I think no one will notice the voodoo damage if you're being harmed already. But I didn't test it to make sure. If it's obligatory, I would put some health and use the effect 7 (-2 or 5 damage) so the experience could be less frustrating. Also, make sure that you can't find any radsuit nearby.

I really liked the Invulnerability method as well. It can be even better.
(oh, as it seems it will not push the player as well)

In my opinion, the easiest way to "mask the machine" is in scenarios where there's several hitscanners around. If the player can't see all of them at once, taking damage "from out of nowhere" will never feel like it isn't "plausible". Dropping players on hurt floors may give some manner of control in terms of when the damage tic happens after the machine is set in motion, but the problem is always that you can't ever guarantee that the tic from the hurt floor will be in sync with the explosion that moves the doll along the conveyor, so it'll miss the spot more often than not.

Alright, one last thing I did real quick... "Pre-loading" a doll with health to avoid unwanted death cases. Here's how:

I simply "cut" off a part of the geometry on which the dolls rests until it gets nudged, and lowered it. Since the "underflow" of the miko portal doesn't activate in a "resting position", this appears to be a stable setup. What I did then was to place another linedef that will raise the highlighted piece, and therefore move the actor. And moving the actor means it will check for items to pick up. So basically it's possible to "load" however much health/armour you need into the doll prior to the barrel's detonation.

Frankly, this isn't 100% failsafe by default, because in a normal gameplay scenario you can, in theory, only activate 1 linedef and not the other, but since it's possible to put 2 linedefs on top of each other by disabling your builder's "automerge geometry" feature, we have an easy workaround at our disposal, at least for any situation that involves walkover triggers.

With that said, it's feasible to nudge dolls extremely hard, if you provide a properly sized "buffer" by preloading, and this might allow mappers to have more control over the doll's velocity, meaning "faster sequences" of events, and perhaps also a more convenient speed for timers. Also you can stack 2 linedefs on the mikoveyor as well, chain several ones together for more extensive scripts when running them in sequence. (For example doll A triggers the barrel for doll B, while also allowing to preload etc)

Map: mikoveyor_preloader_v01.zip

Interesting! Even though i know absolutely nothing about Doom editing (i really am thinking about looking at the tutorials section for info/guidance and installing DB2/GZDooom Builder or one of the newer ones) i enjoy reading topics like this. Also seeing that new tricks are still being found in the vanilla Doom engine is really fascinating, especially after all of these years! 

When i first watched the video and since it was posted on April Fool's, i too thought it was a joke but it turned out that it wasn't haha! 

I played a bit with miko_01.wad in Eternity Engine dev build and noticed interesting things with gravity: if i quickly run through conveyor, i get shaked, but always get back to ground. If i drop in to conveyor, i get shaked too, but gravity takes vacation. Here's short demo.

converiment.7z

I love this fucking community. 

On 4/2/2019 at 7:29 PM, Linguica said:

Really? No one else thinks this is interesting? Isn't this, like, the vanilla-compat holy grail, being able to do Boom-esque scripted events?

Yes, it's impressive. Great find, Linguica! Great enhancements Nine Inch Heels!

13 hours ago, Revae said:

Now every vanilla level in the future is going to have penises hidden in the corners of the map. Fantastic work everyone. Progress is made.

Can't wait for the "mine is bigger than yours" contests.

OK now we are talking.

3 hours ago, Maes said:

 

Can't wait for the "mine is bigger than yours" contests.

Or "I have more of them!"

3 hours ago, Maes said:

 

Can't wait for the "mine is bigger than yours" contests.

Don't forget the age old length vs. girth, now relevant to vanilla Doom mapping!

Areas for further research:

• Add Boom functionality for compliant ports
• Make prefab as lightweight as possible, especially in blockmap
• Research how to turn / accelerate voodoo doll, as shown possible in https://www.doomworld.com/forum/post/1587643 where a barrel explosion causes the player to get wedged in a corner, speed up on their own, and void glide through a wall

On 4/4/2019 at 2:15 PM, Linguica said:

Top 10 Pictures Taken Moments Before Disaster

this is awesome linguica! will let you know what I create with this awesome technique!

@Nine Inch Heels did more work to streamline the mikoveyor, it's unfortunately less phallic and more utilitarian. She also says trying to implement a built-in Boom conveyor version will be problematic due to differences in how conveyors work between Boom and (you guessed it) GZDoom, so we'll see.

mikoveyor_preloader_v02.wad.zip

Might be overthinking a solution here, but maybe have an additional conveyor for (G)ZDoom, and use LOADACS to trigger a script that blocks off / removes the barrels from the other conveyor(s)?

...or just script the sequence as you intend it to work in LOADACS (remove the barrels, then trigger each action after a set delay). You could change the trigger in the map itself via an XLAT lump?

I know, I know, the above is all a bunch of gross hacks. :P

8 hours ago, Dragonfly said:

Might be overthinking a solution here, but maybe have an additional conveyor for (G)ZDoom, and use LOADACS to trigger a script that blocks off / removes the barrels from the other conveyor(s)?

 

...or just script the sequence as you intend it to work in LOADACS (remove the barrels, then trigger each action after a set delay). You could change the trigger in the map itself via an XLAT lump?

 

I know, I know, the above is all a bunch of gross hacks. :P

 

I honestly don't care how much of a hackjob something is, if...
-it works reliably
-mappers can be arsed to actually do it

-and it comes with copy+paste utility (like grab script from another wad/pk3 and it's fine)

Unfortunately there will still be some problems with this, like for example due to the way the the doll gets moved ahead of time to check for items (the small trick that is there to avoid unnecessary albeit unlikely death cases) will also need a workaround because otherwise the mikoveyors would still feed the doll whichever pickup was supposed to compensate for the incoming damage, and pickups that would count towards the item total would also need to get removed from the mikoveyors for the completionists in this community (not that I think there are that many, but still). Next big thing on the line is that, while you can replace mikoveyors and their functions with scripts in UDMF, you'd still need a boom compatible setup as well.
 

What I can do at this point is to create a prefab that will lock all mikoveyors with boom action 252 setups to not only get rid of the barrel explosions, but also pull items from the mikoveyors, and I can make it such that it only is effective in ports that support boom actions by default and doesn't crash for example choco doom (I've already experimented with this). Putting a Prb+ and GZ compatible conveyor in place is child's play in and of itself, and it's no biggie to add one to the prefab either (timing index included). But this will simply become progessively more unwieldy of a prefab then, and therefore less desireable to even use.

What would indeed make this whole thing a lot less of an issue is if it were possible to acccelerate the dolls to 35mu/sec on the mikoveyor (Ideally while still dealing only 1 point of damage so it doesn't "redscreen" players too much), because that's the only value that is equal in both PrB+ and GZdoom, as far as boom actions are considered. If I had that, I could build something that just works regardless of port period, but I really depend on this 35mu/sec speed to make it happen "now"... Alternatively, the ZDoom family would need to step in line with boom scroller speeds above or below 35mu/sec (it's high time after I dunno how many years of just not giving a damn, truth be told), meaning I wouldn't depend on getting a specific speed value out of a mikoveyor setup, and could instead simply work out the speed of the current setup, and see if I can set up a boom coveyor that matches the current behaviour.

The ZDoom ports don't need a conveyor belt.  They can use ACS to do the scripting.

4 minutes ago, Empyre said:

The ZDoom ports don't need a conveyor belt.  They can use ACS to do the scripting.

Point missed....

It's easier to have a compatible conveyor for anything boom or "higher", than it is to require a seperate setup/script for every "family" of ports

8 minutes ago, Nine Inch Heels said:

Point missed....

It's easier to have a compatible conveyor for anything boom or "higher", than it is to require a seperate setup/script for every "family" of ports

If Boom and the Zoom family handle conveyors differently, then it is not easier.  You already are talking about having two "scripts", so why not just one more.

1 hour ago, Empyre said:

If Boom and the Zoom family handle conveyors differently, then it is not easier.  You already are talking about having two "scripts", so why not just one more.

Because the ideal circumstance is to not need any ACS stuff at all, and instead having everything packed into 1 setup that just works no matter the circumstance. And the only reason this can't be accomplished easily is that ZDoom derivative ports couldn't be assed to step in line with their conveyor physics in literal years, in spite of reports that showed something didn't quite work the same way.

And since GZ's head honcho already made pretty clear what he thinks of this, chances are that people who want to use the current setup in their vanilla maps won't be able to cater to GZDoom anymore, unless every dedicated vanilla or maybe even boom mapper learned how to ACS just to get their stuff working in a format they didn't even want to use in the first place.

And when it's down to "Should 'nilla mappers learn how to ACS", or "Should ZDoom derivatives emulate (boom) features properly like they said they did" (see GZ's  """"""strict"""""" boom compatibility), then I'd say the ZDoom family should at least get conveyor behaviour right, instead of limiting a mapper's creativity.

I agree with @Empyre. If someone really wants to build a vanilla compatible map with this kind of trick in it, *and* have gzdoom support, then writing some ACS doesn't seem unreasonable. If only map editor prefab tools would support copying ACS along with map items; then it could just be part of the prefab just like your proposal. 

Although how well does acs in zdoom work with vanilla format maps: fewer linedef args, no TIDs etc?

Personally I wouldn't bother pursuing gzdoom compatibility and leave it up to them if they judge it worth it to fix compatibility with a scrollers etc 

So, the easiest solution is to just wait until the whole ZDoom family change how they've been implementing conveyors for a very long time (and wait for Zandronum to fully support voodoo dolls [none are supported in multiplayer emulation mode, my favorite way to play single-player])?  I counter that if the goal is to find the easiest thing for the mapper, then just use scripts to do the scripting and play the map in a port that supports ACS, rather than messing with a voodoo-doll-conveyor-belt work-around.  But, if the goal is to make the map fully function in any port, then my suggestion from earlier still stands: both kinds of conveyors and also ACS.

That said, I want to make it clear that I think this method of making conveyors in vanilla is very clever and Linguica deserves kudos for his ingenuity.  I am not trying to subtract from that.

Has anyone successfully got a voodoo doll through a teleport line and preserve momentum on the other side? for loops?