Voodoo telefrag insta-death

[wesleyjohnson]

DoomLegacy, trying to get voodoo doll teleport insta-death to work better with ic2005.wad.
Our voodoo doll is not the original code, it gives the voodoo doll its own player, so as to eliminate most of the wierd side effects (I did that on purpose).
Using a voodoo for insta-death by teleport is one sideeffect that appears to be necessary for some wads (used to kill players when the design needs to to turn if on/off).

One reason to do it this way is because I intercept the instadeath and give a console control modified effect. For coop play the server can set it to ZAP instead of DIE.

It seems to be a one-shot effect to start with, so is not all that compatible with multiplayer play to start with. But that never stopped users from trying, so I need to find a best-effort solution.

I got it to kill the single player, and on multiplayer am trying to identify the player who triggered it, so as to put the damage on him.
I realize that there is an indefinite amount of decoupling due to wad design, and the kill could be delayed by an indefinite time as the voodoo doll works its way to where it telefrags.

I still got player1 touching the electric door and player2 explodes.
I can fix that, eventually.

Anyone been down this path before and have any useful revelations to share ??

[kb1]

If it were me, I would put back the original code. Here's why:

1. Voodoo dolls are quirky, as you've mentioned.
2. Anyone using them should know that.
3. Any maps already using them most-likely depend on dolls being pretty close to original, if not exact.
4. You'd probably have to test a lot of maps to prove a custom implementation.

Then again, I'm not sure what your goals are. If you want to make a reliable script object, for new maps, maybe make a new object, with all your fixes, to be used in new maps, and leave the original mechanism to it's own devices, which, puts the ball back into the mapper's court, so to speak. At the same time, this allows you to modify at will, without worrying about breaking old maps.

Changing something this fundamental would scare the hell out of me, anyway! Good luck.

[Graf Zahl]

Agreed. Voodoo dolls very much depend on being linked to the original player. ZDoom avoids troublesome side effects by checking if the current actor is the real player to skip that code (e.g. everything related to altering the view position is protected like that.)

[DaniJ]

Giving the doll's their own players you'd surely end up with far more code to achieve the same result. I don't understand why this was ever necessary in Legacy(?)

[Graf Zahl]

It was accidentally removed when in earlier versions the player spawning code was rewritten using a table to store the start coordinates instead of spawning the player actor directly. As a result of this rewrite the duplicated player starts which caused voodoo dolls to appear just got lost before the map was started.

And the early Legacy coders were not the best, unfortunately, so they never addressed the issues they caused with it. It's not the only problem they caused by careless code reshuffling.

[wesleyjohnson]

I probably could not make the original code work that well. There already was a compile-time option to just link the voodoo doll to players[0], which would do most of that. But there is so much code changed that I cannot trust maintaining accidental behavior that I do not even know about.

That is why I am not trying to keep all the accidental behavior, as most of it broke the wad and the play. I made the voodoo guy a separate player to break that link.

Voodoo dolls can teleport and trip linedefs like the original, which seems to be their main use.
This voodoo telefrag does seem to be one valid use.
I think it is the only reasonable one.
Are there any other good uses that appear in wads ??

I do not care for the one where you shoot the voodoo doll and player[0] gets hurt.
The only other one I can think of is sending a voodoo doll into a damage sector in order to kill the player slowly. Trouble is there is nothing the player can do at that point, so it does not make for a good wad anyway.
And the effects only work in single player and are act weird in coop.

I already have voodoo telefrag working in single player. It is multiplayer that is the problem, and that did not work for the original code anyway, either. (Does anyone know otherwise??)
Player 3 would touch the electric fence and player1 across the room would explode because the voodoo doll was always tied to one player.

I can move around who explodes but cannot reliably find the player that touched the electric fence.

I am getting to the point of considering voodoo telefrag and multiplayer to be incompatible. Even if I could find the right player, the effect would work only once and not again. After one player gets fragged, everyone else can walk though unharmed.

The other reason is that I want to make an option to reduce that insta-death into damage or a zap. That too only works once.

A linedef and sector type that did this inherently and repeatable
would be much better than these wad tricks.

[Graf Zahl]

wesleyjohnson said:

Voodoo dolls can teleport and trip linedefs like the original, which seems to be their main use.
This voodoo telefrag does seem to be one valid use.
I think it is the only reasonable one.
Are there any other good uses that appear in wads ??

Oh, but it is valid use. Aside from triggering linedefs there's 2 other very valid uses for Voodoo dolls:

1. Damging the player, either by telefrag or exploding barrels around the voodoo doll.
2. Have the player pick up items. You can see a good use of this in the start area of Plutonia MAP06.

Both of these uses require the voodoo doll to be linked to the real player, although admittedly it can be replicated with a few more checks in the code for these actions.

[wesleyjohnson]

Thanks, that is what I needed to know. Especially Plutonia, which is one wad where I think we need to maintain compatibility, no matter what they did.

Looks like it will easier to approach this the other way. Tie the voodoo doll back to player[0] and invent some way to detect and intercept the voodoo doll for specific cases.
And intercept it when it tries to change the player viewpoint (as in ZDoom) ?? Do you remember where, that sounds like more than a fews days of searching for whatever that is about. I am going to look for something in MovePlayer and thereabouts that needs to be protected.

[Graf Zahl]

wesleyjohnson said:

And intercept it when it tries to change the player viewpoint (as in ZDoom) ?? Do you remember where, that sounds like more than a fews days of searching for whatever that is about. I am going to look for something in MovePlayer and thereabouts that needs to be protected.

I can't point you to precise pieces in the code but it's inside the player movement code which alters 'deltaviewheight' if the player steps up and down. Obviously, since voodoo dolls were never considered when Doom was developed, this code also gets executed when a voodoo doll is carried over a step - something that definitely can happen on conveyor belts used for scripting events.

[kristus]

Graf Zahl said:

It was accidentally removed when in earlier versions the player spawning code was rewritten using a table to store the start coordinates instead of spawning the player actor directly. As a result of this rewrite the duplicated player starts which caused voodoo dolls to appear just got lost before the map was started.

And the early Legacy coders were not the best, unfortunately, so they never addressed the issues they caused with it. It's not the only problem they caused by careless code reshuffling.

When I talked to them about this, quite a while ago now. They claimed they did it on purpose because of all the bugs and issues they claimed the voodoo dolls involved. (I'm guessing it's the ghost issues and such that Wesley was thinking of as well)

[Graf Zahl]

Ugh... I wouldn't have expected that although in hindsight it doesn't really surprise me.

[wesleyjohnson]

I am trying to tie it to players[0] again. I expect that I will find out several months from now why they took it out. I probably don't dare release this until I have researched every weird voodoo effect every known.
I will have to look for all kind of places where thing reactions affect the thing->player, and decide if they should go through.
Kind of makes me wonder if I wasn't right the first time, with a separate voodoo player.

Made a test wad with all the voodoo tricks that I could think of.
* voodoo telefrag
* voodoo picks up BFG and ammo
* voodoo linedef triggers (light levels)
* voodoo gets shot by player with weapon (one of each type weapon)
* voodoo gets shot by imp.

Those all work in single player.

Did I miss anything important ??
* voodoo with barrels and crusher to detonate them ??
* voodoo under crusher ??

Had to fix some strange things in coop and deathmatch.
* Multiplayer shooting, when target is voodoo doll, I change the target to the source player and the source player thing, so you can only shoot yourself, no matter who you are. I recommend this for other ports too.
* I block voodoo telefrag in deathmatch, but not in coop.

* voodoo walks through damaging sector does not work, and does not work in prboom either, and probably should not because damaging sector tests cycle through the player list, not through things.

Still am fighting with the multiplayer voodoo interactions (which really was my original question).

In multiplayer:
* Could randomly pick victim for voodoo doll damage. (unsatisfying)
* Could change all voodoo dolls to point to player that just walked over a triggering linedef. (one loop over all things?)
* Could track last player that triggered linedef, record that into voodoo doll when they trip a linedef, and when voodoo doll gets into DamageMobj, put the damage on that player. (About 10 lines of code, but it does not work yet, keep ending up with NULL ptrs).

Got any better ideas ??
Any other similar port behavior ??

[DaniJ]

Can you provide a quick overview of Legacy's multiplayer architecture? In a "true" client/server model for example, there is no need even unlink the player from the voodoo doll because dolls exist purely server-side and therefore cannot affect the local viewplayer.

[wesleyjohnson]

I am testing in splitplayer mode, and that would of course know everything. Network play I do not know that well. The server and client all run the same code base. The server just gets some extra privileges.

That is another possible problem. If other mobj effects get reported to the clients, then voodoo dolls should to. I do not even have a good way to test network play, as my work machine is standalone. I will have to take over another machine and get some network cable.

The network code is where Legacy-2.0 got hung up on.

[wesleyjohnson]

Voodoo dolls on starting points for player2,3, and 4.
Did anyone ever use them.

I think I should block most Ghost and Zombie effects.

[Graf Zahl]

wesleyjohnson said:

Voodoo dolls on starting points for player2,3, and 4.
Did anyone ever use them.

Plutonia MAP06.

[DaniJ]

wesleyjohnson said:

The server and client all run the same code base. The server just gets some extra privileges.

Does Legacy implement client sessions? How is player input handled; using ticcmds describing actual device input events, like vanilla DOOM?

Voodoo dolls on starting points for player2,3, and 4.
Did anyone ever use them.

My advice is to implement support so that at least one voodoo doll can be present for each concurrent player in the world. So if Legacy supports 32 players that means the potential for at least 32 voodoo dolls. Even though DOOM only has spawn spots for players 1-4. This then allows a direct map between player and doll(s), which should make handling them easier to deal with.

Also, in a client/server model you probably want to spawn them all, always (regardless of the actual number of "real" players in the game).

However bear in mind that many of the tricks involving voodoo dolls simply won't and can't work in a client/server architecture.

[tempun]

wesleyjohnson said:

Did I miss anything important ??
* voodoo with barrels and crusher to detonate them ??
* voodoo under crusher ??

Probably.

wesleyjohnson said:

* I block voodoo telefrag in deathmatch, but not in coop.

In DM voodoo dolls don't exist at all AFAIK.

wesleyjohnson said:

Still am fighting with the multiplayer voodoo interactions (which really was my original question).

In multiplayer:
.....

Damage the corresponding player (if it's coop, dolls don't exist otherwise).

[Graf Zahl]

tempun said:

Probably.In DM voodoo dolls don't exist at all AFAIK.

To be precise, the regular player starts are completely ignored in DM and player spawning is done differently.

[wesleyjohnson]

Well, I got voodoo dolls present in deathmatch too, and have tested that the voodoo telefrag is now blocked. I did not do anything extra to get them.

I have also tested with prboom, as a reference and have noticed the following.
prboom does NOT damage the player when voodoo doll is next exploding barrels.
prboom does NOT create a voodoo doll for extra player2 start.

I also got a zombie when I shot at more than one voodoo doll.
Something even more weird when you shoot your voodoo doll, heal some, and then finish him off. I did read the wiki on voodoo dolls and got some of its voodoo demonstration wads.
Not knowing of any really good use for these effects.

I am tempted to eliminate them altogether by synchronizing the player and mobj health.
I am just not sure what to do with the voodoo doll health. Force it to the same as the player before applying any damage effects sounds safe.

I suppose that Plutonia has got a map that uses Zombie too ??

Yea, the Plutonia fix of having a voodoo for each player, is in direct conflict with my plan for directing the voodoo effect to the player that triggered it (assuming I ever get that to work).

Will have to have a switch for Plutonia, and provide different behavior for other wads.

Don't think that a voodooo doll for each player will do anything, they have to be in the right position to do anything useful.
I could just as well detect the voodoo doll and give everyone playing the same reward.

Thanks for the information.

[wesleyjohnson]

On sever play vrs voodoo doll.
Each client will start the same map, so they will create all the same things, including the same voodoo dolls.
Voodoo dolls are not spawned by player starts, I am creating them deliberately as extra player starts are detected in the map, when one already exists.
If I can have a conveyor started by one player and the other player can see it move, then a voodoo doll on that conveyor should work just as well.
If the clients are keeping their things in sync by network messages, when they get picked up, when linedefs are triggered, then one voodoo on one client doing something, it should happen on the other clients too.

I will have to test this eventually.

[tempun]

wesleyjohnson said:

I have also tested with prboom, as a reference and have noticed the following.
prboom does NOT damage the player when voodoo doll is next exploding barrels.
prboom does NOT create a voodoo doll for extra player2 start.

Well it does both (for me; I used v2.5.0 w/default settings). Don't know what version do you use. (Or do you mean that player 2 doll isn't spawned in single player? That's correct behavior.)

wesleyjohnson said:

I am tempted to eliminate them altogether by synchronizing the player and mobj health.
I am just not sure what to do with the voodoo doll health. Force it to the same as the player before applying any damage effects sounds safe.

This is what ZDoom did, and there wasn't much complaints, so it's probably OK.

wesleyjohnson said:

I suppose that Plutonia has got a map that uses Zombie too ??

Don't think so.

wesleyjohnson said:

directing the voodoo effect to the player that triggered it (assuming I ever get that to work).

Why do you insist on that? Seems pointless to me.

wesleyjohnson said:

Will have to have a switch for Plutonia, and provide different behavior for other wads.

Please make vanilla Doom's behavior the default.

wesleyjohnson said:

Don't think that a voodooo doll for each player will do anything, they have to be in the right position to do anything useful.
I could just as well detect the voodoo doll and give everyone playing the same reward.

That would be difficult.

[wesleyjohnson]

I got some test cases that I think should work better.

ic2005.wad has these electric arc doors.
If player2 walks through the arc, player1 should not be the one killed.

If player2 shoots a voodoo doll, assuming the wad has left one visible, then that player should get damaged. This is because of playing coop on wads that only have player1 voodoo dolls. There are many more of these than the ones that tried to provide a voodoo doll for each.

I may have to switch this too based on detecting any player2 voodoo dolls, vrs only a bunch of player1 voodoo dolls.

Is is OK if the voodoo doll gets no damage at all, and remains standing when the player dies, or is there some WAD that needs to him to keel over too? One variation redirects the damage to the players actual mobj, and gets the voodoo doll out of the damage effects altogether, so the voodoo never gets damaged itself.