Voodoo Doll Boolean Switch

I need to create a system using conveyors and voodoo dolls in Boom that allows the voodoo doll to trigger a linedef action if a door is closed in it's path, and to perform another linedef action if the door is open.

I'm working on a project that requires a massive amount of voodoo dolls running along circuits much like that of a computer processor. The results from this switch system must be reliable, and the voodoo must pass through it quickly with relative ease.

I've exhaustively tried many combinations of things. The most obvious solution was to create the door with an angled wall so that when the voodoo doll collides with it, it is pushed over a bit following an alternate route. While it all seems simple in theory, it's quite difficult getting it set up to be reliable enough for my tasks.

1. The switch system must be able to pass a voodoo doll through multiple times per second, but not too fast as to cause the voodoo doll to clip through the linedef actions or teleport lines. The teleport lines are basically used to restart the system, teleporting the doll to the beginning so it may pass through it again.

2. The system must be reliable. When the door is closed, the first action must be activated, and only that one. When the door is open, only the second action must be activated. The door is the only way to influence the outcome of the system.

3. The system must use as few linedefs and sectors as possible. This is because the system will be copied and used hundreds of times in different parts of the map. Also, the larger and more complex it is, the longer it will take a voodoo doll to pass through it.

I'd rather not go into detail about what I'm working on, but it's a massive undertaking. Basically, if anyone can give some ideas on what I can do, please do.

Why aren't you just making two conveyor belts? I dunno, I didn't sleep, but that seemed like the most obvious solution to me.

Hm, angled walls were the first idea that came to me too. It's a shame to hear those aren't reliable. Maybe another idea will come to me.

By the way, I've noticed that when a thing enters a scrolling sector it may get an extra boost of speed in some engines, which can also make conveyor belts unreliable. Just something to watch out for.

Creaphis said:

By the way, I've noticed that when a thing enters a scrolling sector it may get an extra boost of speed in some engines, which can also make conveyor belts unreliable. Just something to watch out for.

I believe this was the original Boom behavior for them. In ZDoom it doesn't occur by default, but I think there's a compatibility flag for it.

Not sure if this gives you any ideas, but this binary counter works:
http://www.doomworld.com/idgames/index.php?id=14480

Here. I made this.

http://www.zshare.net/download/1726749924f4ae47/

Hopefully, once optimized, it should do what you need.


Another possibility (perhaps a better one) would be to have the door on a teleport destination instead of directly in the voodoo doll's path. If the door is closed, the destination is blocked and the teleport line is ignored. Boom's line-to-line teleporters would work best for this.


Another edit: Nevermind, Boom's line-to-line teleporters don't take ceiling height into account (you can get trapped in the roof) so this would only work with the teleports that use teleport destination things, and the teleport delay limits the speed at which this switch could operate.

Wow, I had no idea you could do that with a scrolling floor. The problem with the design though, is that I would be required to tag each and every one of these mechanisms by hand, and with requiring so many in the entire map, it's going to get tedious. Also, I suspect that if your contraption was sped up (remember I need the doll to move very quickly), it would probably fly off the conveyor.

There isn't a need to make a seperate branch entirely, just enough for the voodoo doll to trigger a different linedef action. It's actually preferable in my case if it led into the same teleport linedef.

I just recently created what I was kind of looking for, although it has one problem.

Looks something like this:

 _
|T|
|  \
|D 1|
|2  |
 \  |
  |_|

Where T is the beginning, D is the door, and 1/2 are the triggers. The conveyor moves at 512 speed, the player radius is 14, and the whole thing is 64w x 192h units. If the door is closed (it is triangular), the doll will activate linedef 1. If it's open, it will pass through to linedef 2. The voodoo doll currently moves through at about 2-3 times per second.

It currently uses 11 linedefs for the structure itself, 3 linedefs for the door, and 2 linedefs for each of the triggers. This doesn't count the teleport lines, which are shared between multiple systems like this.

That's 16 linedefs. But, when you multiply that by a minimum of 768, those numbers are daunting (like 12k linedefs). And that's probably only a third of these systems that I will require. It also doesn't count rest of the map.

So the system I just designed which has been the most efficient of them all so far, is not good enough. :(

Honestly, I just don't think it's possible. I will most likely have to find a different way of processing stuff so I can use less of these.

Don't give up! I want this mysterious idea of yours to become reality.

And yeah, boomref.txt has some interesting stuff in it.

I don't know what your switch really looks like, but your ASCII diagram is in a shape that could fit together with itself quite nicely. You should be able to lower your linedef-per-switch count somewhat by sharing borders between switches.

If you have to stick to Boom features, no, there's no better way. I think you may be able to get down to 12 linedefs for the structure but I really can't see any way to get lower than that.

If you need such mechanisms in larger quantity, I'm sorry that real scripting is the only working alternative.

Creaphis said:

I don't know what your switch really looks like, but your ASCII diagram is in a shape that could fit together with itself quite nicely. You should be able to lower your linedef-per-switch count somewhat by sharing borders between switches.

I thought the same thing, but the part is, sharing linedefs means those linedef will be impassible and two-sided and the voodoo dolls tend to stick to impassible linedefs. Also, placing these in the map as rooms (as compared to pools as they previously were), would reduce the sidedef count. Merging them together wouldn't be productive in that case.

And Graf Zahl: The point of this project is to demonstrate something that possibly could have been done a decade ago with Boom. If this ever gets finished and working, it's going to be very memorable, even by today's standards.

I do appreciate what you guys have to say though.

I find this very interesting. I just used your suggestions to get it down to 8 lines each (for 4 separately controlled doors). But I use two triggers each (just to make a light blink so you can visually see which switch is working), so if you only need 1 trigger that's only 6 each. And probably less as you can continue sharing lines as you add more doors.

Still that's a hell of a lot of tedious tagging; if you don't have an easy way to make a program do the tagging for you, probably do 100 a day or something and it'll be done in 7 days.. Not really sure exactly what you want and it might need tweaking.

(edit: hmm, I read the comment about sidedef count as opposed to linedef count; I have 'impassible' lines but I guess they have 2 sidedefs. Also would it help if all those doll sectors had no linedef textures and a single tessellating white pixel or something for the floor and ceiling if that saves space. whatever, here's the link)

http://www.sendspace.com/file/l2gu7h

Actually, that is not quite so bad, speedwise. It can be sped up a tremendous amount, but the only problem I see with it is your teleporting, which requires a butt load of more tags, as opposed to several line-to-line teleports stretched over multiple switches. However, it's tricky getting line-to-line teleporters to discard any side to side momentum that can build up and cause havoc at random. This was my main problem of using line-to-line teleporting.

I appreciate the help you guys are giving me, it's actually starting to get my brain thrown into the right gear. And by the way Creaphis, I cannot thank you enough for your wad, because it opened my eyes to the fact that doors can apply vectors to scrollers to change their speed and direction. I'm already using a system in my wad that takes advantage of this.

It gives a nice bouncing effect. ;)

If you end up with having to tag dozens of sectors, I'd suggest trying to build it with WadC, can save hours of tagging :)