Conveyor belt troubles/ impact on demos question

So this started off as more of a teleporter problem, but because of all the back-ups in place the issue has become more prevalent in the conveyor belt system. Mosters have a chance to completely stop moving while on the belt each time they bump into the one in front of them. Typically this problem occurs when one monster sees the player begins moving the opposite direction than the belt and holds up a line, which causes 2 monsters that both have not seen the player to stop momentarily before the first moving monster and the first of the latter two move on, leaving the second stuck until activation. After taking one step the monster always takes off on the belt again.
In a couple rare instances two can get stuck within each other, which is hard to tell because it's only 1 pixel-worth of overlap, but becomes apparent when the monsters fail to attack/move when they see you and when you knock one back they both resume motion like nothing happened. My assumption is that these are limitations within the game engine at this point, but any thoughts and help would be appreciated!

Thanks so far to those who have helped shed light on what's going on, but I'm not quite out of the woods yet here.

Still want to know how a demo doesn't desynch as a result of this type of stuff, especially when monster movement isn't recorded. To me, that means that it must be a fully-recreatable and dependable thing to happen, as if it were anything else the demo would desynch. Then again, perhaps it could be similar to the RNG for damage output. More info on this would be appriciated as well.

The OP:

What map format are you aiming for? Usually too many actions in one tic will result in undefined behavior.

See here: http://doomwiki.org/wiki/Spechits_overflow

Also, afaik, there is also a bug that sometimes causes linedef actions to not trigger, regardless of how many happen at once. It just seemingly doesn't activate for no reason at all, and I'm pretty sure it's just a limitation of the engine somewhere, or a bug.

I've noticed similar problems in zDoom in Hexen format, though it's been a while since I've encountered them so I cannot remember too many of the specifics on that. However, this map is in Boom format.

The strange thing about the demos is that they don't seem to desynch, which is a good thing and all; it's just puzzling to me. As ol' So-crates said, true knowledge exists in knowing that you know nothing, so hey, at least I'm that far. Still, self-deprecating aside this is something that has puzzled me for a while, though I suppose what was puzzling months and years ago could have been different problems that appear similar.

Thanks for the link to that article on Spechits overflow, that's a limitation of demos I never knew about. Could that seemingly-random bug you mentioned be due to a similar limitation within the game engine? I like to know how stuff works, so any foresight on this stuff to help me get to the root of the issue is appreciated, though I'm no programmer so I do not have the knowledge to start looking at the coding of it all.

I don't want to shamelessly plug a map just for these questions, but if it's absolutely necessary I suppose I can link it.

Fonze said:

I've noticed similar problems in zDoom in Hexen format, though it's been a while since I've encountered them so I cannot remember too many of the specifics on that. However, this map is in Boom format.

The map-format itself is guaranteed to not have anything to do with whatever issue you're encountering. ZDoom is also immune to spechits overflows (as with most ports starting from Boom, from my understanding). Spechits is entirely a Vanilla issue, and desyncs demos only because it rewrites undetermined memory.

Fonze said:

The second part of this question is: when the game misses an action or a trigger during gameplay, assuming its due to a limitation in the game's processing power/too many actions per tic, how does a demo recording manage to not desynch from having too many actions to choose from during a tic?

Demos don't record actions, they record player commands. What you're recording and playing back is what the network manager has created for each tic.
http://doomwiki.org/wiki/Demo

Fonze said:

When mapping on my current map, I've noticed that some teleporters work sometimes, yet not other times (once again).

What is supposed to get teleported? The player, or non-player objects?

Edward850 said:

The map-format itself is guaranteed to not have anything to do with whatever issue you're encountering. ZDoom is also immune to spechits overflows (as with most ports starting from Boom, from my understanding). Spechits is entirely a Vanilla issue, and desyncs demos only because it rewrites undetermined memory.

Demos don't record actions, they record player commands. What you're recording and playing back is what the network manager has created for each tic.
http://doomwiki.org/wiki/Demo

Interesting about the demos, it's been a while since I looked that stuff up so I had forgotten that it only records player commands as opposed to both those and what was going on in the environment. But then again I suppose that's why the wad file and engine are needed, heh.

Nice to know that about spechits too. But that only makes this a more puzzling phenomenon to me...

scifista42 said:

What is supposed to get teleported? The player, or non-player objects?

This example is non-player objects. More specifically, monsters on a conveyor belt that constantly scroll from map start and teleport to the next of 4 (total) conveyor belts to give the appearance of one long system. At map initialization, there are no issues, however, as the player progresses more teleporters are used. It's strange that it's always the same teleporters that seem to get put on hold, but I think I may have had another couple do it. I can't remember now as I usually put in back-ups automatically (which is probably because I've encountered this problem before enough times to make me create the habbit). Back to the example, by the time the player gets to the place in question, the monsters have backed up and cannot move as the teleporting lines are occupied on the sending end (as opposed to the receiving end). I know this is not due to the receiving end being blocked because the monsters are spaced and on a conveyor belt as soon as they hit their destination. My back-up for the back-up is simply a crusher to say basically a working system is better than one monster (or potentially 90% of them). Obviously I would rather avoid using that in the first place, but this is something I've been tinkering with for a few months now (on and off; mostly off) and the little optimizations I have done haven't accomplished much, though part of the problem there is that there are mosters ranging from big mancubi and small zombies that need to be accounted for.

Still, I don't think at this time that the conveyor system itself is flawed, but I'm trying to wrap my head around what makes the teleporters not work in the first place.

You know, an example may tell us more than a 1000 words. How about posting the map that's causing this problem?

True. Well here's the map. This is a big map so testing it will be something of a test of patience. The problem with this is that it is intermittent and a couple minutes in. My system of back-ups tend to work well so the problem is even that much tougher to consistently make happen. Perhaps tonight I'll try to isolate the problem a little better, but for now the problem is here:



And here's the map: https://www.dropbox.com/s/i3wel7g533645t3/TYTY_V21.9.1.zip?dl=0

*Edit*
Well, to confound things even further, after a little more than an hour of failures to recreate the problem I put the system to a stress test by adding in more monsters. It's hard to confirm its impact to some other teleports as they can easily be blocked (another reason to use back-up systems) but the only problem I was able (to confirm) to get to appear tonight was a blockage due to the sides of the conveyor belt. A mancubus stopped moving for no reason about 5-10 feet (~2-4 meters) out of the receiving end of one port. I could only see it through IDDT, so I couldn't see why he was stuck, then I accidentally opened a door which let sound run through and he unstuck himself. Now my mind works to patch this error up, but that is where I am now, patches on top of patches on top of broken dreams. I will likely make some block monster lines to try to fix the issue, but ultimately that will likely be a useless measure if we are to assume this one issue is with monsters "slipping" off the moving platform to the adjacent support. Feels like I'm going in circles here, missing the real problem(s).

I suppose I could remove all back-up systems to help make the issue more prevalent, but I will have to try that tomorrow.

It also dawns on me that in my optimizations I also untagged some of the ending sectors in each belt to prevent monsters from getting stuck before teleportation occurred, but after crossing the lines. Still, all this seems unnecessary for something so relatively simple.

There's a few important things to note here:

1. If an actor touches multiple sectors with a scroller, it will get accelerated by each one of them.
2. If the teleport destination is blocked, the teleport won't happen.
3. ZDoom fixes #1, unless a compatibility option is set.
4. As you noticed, the end sectors do not scroll.

So what can happen?

With the setup it is not guaranteed that the distance between monsters remains the same. They may get closer to each other - and then get stuck because when the second monster tries to teleport, the destination is blocked by the first one. And if only one monster gets stuck like that behind the last of your teleport lines there's no way out. It will block the place forever.

And your three-stage 'safety' may make things even worse because if something gets to the last of these teleports, the distance to the next one will be drastically shortened. Yes, it will most likely take a while for this to become unstable, but it's almost inevitable.

Interesting, I had a feeling my backups only delayed the inevitable.

To be honest, I haven't wanted to mess with the geometry of the section too much as I like the way my partner did those conveyor belts, with the gradient light fading out towards the ends, which means that those short sectors are unfortunately necessary. That is actually exactly one reason why I untagged some of those ending sectors. Like you said, the monsters speed up at the end of the chain. However, they also shoot out of the opposite side at that same higher speed so that difference should be offset just enough to not matter, especially with the last few sectors being untagged the monsters simply don't gain as much momentum before hitting the teleporter to hit each other, though they often collide shortly after teleporting as they lose momentum. I also didn't look into changing that too much because that acceleration also helps to space them apart a bit more before and immediately after the teleport.

That's interesting to note that it was the multiple sectors that caused the monsters to accelerate, I figured I just did something stupid somewhere, but was happy for the serendipity of it. I suppose it would look better (consistent on the ends) if that were changed, but that also screws with that lighting so that may be a bust. Still, I don't see the harm in that little bit of extra accelleration. But the ending sectors do not scroll because I made them not scroll with the arduous task of hitting the 0 button in the "tag" box. Heh, I joke, but seriously I had the problem before of a monster getting stuck behind the teleporting lines and being unable to move out of the corner because of the speed of the belt. (interesting side-note here) I had to make the belt fast to prevent monsters from walking backwards to the receiving end and never seeing the player (in other dimension). Still, at some point the monsters on the belt become alerted, so I think at that point the extra spacing from the acceleration becomes more important.

As for the 3 stage safety, I think I set the receiving lines as different and in the correct respective places, but now I need to check that to be sure I didn't pull a brain fart. But those extra 2 teleporting lines and crusher per belt were put in place because the first didn't work. I try to be thorough with my troubleshooting but it's been a while so I cannot remember exactly what order things went down.

If a monster gets stuck here it shouldn't block the place forever, though until they are alerted it's not like they're gonna unstuck themselves. I think I need to get another look at my teleporting line placement to be sure that the orders are reversed on the receiving end.

Still, as sure as I am of the systems ultimate failure, I wonder what exactly causes it to happen and how something so seemingly random is also picked up by demos.

Head scratchers >.<

*Edit*
More fiddling...

After another look apparently no I did not reverse the order of the receiving lines, but after doing so maybe I did that for a reason, heh. No need for them to shoot out of there like fat rockets, heh.

I think I may have figured out how to isolate one of the problems; using mancubi as the monster set, if one mancubus notices the player but the rest don't, then there is a 100% chance of causing a back-up. At first it is benign, but over the course of 30 seconds to a minute eventually a mancubus that has not noticed the player will stop. I guess he realizes that he's in the matrix and the laws of friction no longer apply or something; I didn't know monsters could think. I wonder if they question if they have souls... I think therefore I am? Sorry; day off and the tokillya was calling. Back to business, I took a couple screenies of this particular problem in apparently the most confusing way possible, by over-laying IDDT over top of them, so my apologies for that.


These guys are supposed to be going to the right.


These guys are supposed to be going towards the left.

As you can see, both blockages in this situation happened in the middle of the belt. I don't know what in the engine causes this, but I know in this case the symptoms are an unalerted monster on a moving platform bumping into an object that moves after contact, leaving the first monster stuck in place while still on the moving platform. This flaw is self-correcting, however, as once the monster wakes up he is picked back up by the moving floor. As you can see from the previous screenshots, I put in a giant sound tunnel so the two areas are tied together, though why I didn't just join the crushers all as one area is anyone's guess (maybe I just too distrustful of joining sectors). I wonder if the tiny supports could be causing this, but I know that the extra acceleration is not helping the situation, though how much it hurts it is probably only a question of time.



As for the short sectors causing extra speeds, perhaps I will experiment a bit with removing some and to Hell with the nice-looking gradient lighting. I don't want to take that route, but as Graf Zahl said that is the cause for the extra speed.



Perhaps everything here can be explained by problems erupting after only one monster has seen the player, if that is the case, then perhaps it is inevitable and the only real solution is to have failsafe after failsafe as I have been doing to just prolong the time required for an error to occur in hopes that the player reaches this point before they do. Seems a bit excessive, though.

This might be BS, but, I seem to remember that you can control the speed and direction of a conveyor belt, based on the height of a lift.

What I'm getting at is, maybe set your conveyor up to slow down, and reverse direction for a short period of time, carrying away the waiting monsters, and giving the stuck monster time to step out of the teleport. Then, reverse again, back to normal. The previously stuck monster will get teleported (cause the destination is probably clear now), and the others can follow.

This is an interesting situation. If you manage to solve it, please post a description of how you got it to work.

Actually that is a really good idea. Just put in a constant floor scroll/move things and use a scroll floor/move things when sector changes height in conjuction. I didn't even think about that as a solution, but I think it sounds like a great idea! Thank you for the thought; I'll give it a shot and post my results here when I'm done. Possibly tomorrow.

Update on the fix... More tinkering part 1,001.

Damn good idea kb1! The problem at this point wasn't so much the teleporters; it was monsters getting stuck in the middle of the line. As a matter of fact, now that I think about it I didn't even reflag (or need to) the teleporting sectors to be included in the moving portion of the belt. Idk, point is, with 3 teleporting lines the monsters never fail to teleport. They never really have for a while, I suppose, but I didn't realize until recently that the problem developed from the teleporters to the other monsters themselves. What I mean is that monster A sees the player and walks backward, against the belt. A bumps into B, B bumps into C. A and usually B too then move on while C holds up the rest, until he becomes alerted, at which point C will unstick himself. On one or two rare occasions I did see 2 monsters actually stick together and only a couple blasts (without killing them) of the SSG could dislodge them. You can guess that in that very last instance of two sticking together that they did not react to the player while stuck. In the majority of instances, they clearly do as they then unstick themselves.

Which brings me to where I am now, after your fantastic idea.

To all: I don't think I really need to do a tutorial on how to get to the point where I am at now. I think if basic conveyor belts are over one's head then this stuff will be pointless to read anyway. But kb1, if you want a tutorial on what I'm gonna do to fix this, then I'd be more than happy to put in a bunch of pictures and who knows, maybe I'll even smear some feces on them and call it writing 8D

Ok, for starters, we are in Boom format and I use BD2-- woah there buddy, don't open that can of worms-- DB2 because I'm just too much of a caveman for the GZ-goodness.

Ok, let's start with a shot of our work area:


No wait, the smaller one


Ok, as you can see there are 2 identical areas, both are of course connected and it's completely pointless to look at them both, so we will focus on just one.

So we have 2 different belts here. The one on top goes to the right while the one on the bottom goes to the left. Obviously we're gonna need 2 sets of lines here to account for the 2 different directions.



The first step is to add in dummy sectors. Dummies are awesome; they crash, they write books for us (since when did they change the meaning of "for" to "from?"), some of us are them (like me), and they even help us build Doom maps. Stand up guys, those dummies.



Back on subject, dummy sector it up and put an action of 248-Scroll Floor/Move Things when Sector Changes Height on it. You can't see my mouse apparently in these shots, but the line that you put it on should run parallel to the belt's desired direction. In this case, the highlighted line was the far south one of the southern dummy sector, while the second line was the north line of the north dummy sector. This tag is for our north belt, while the other is for the other. Do note that the side you put the line on is important, or more-so, the facing of the line, but that won't matter as the line won't work facing out of the sector it operates from. It's very important to note that the line always scrolls/moves left/right depending on whether the sector is moving up or down (I think that up goes left and down goes right) but if it goes the wrong way just edit+mirror the thing and good to go. It is also extremely important to note that the length of the line directly affects the speed of the moving whatever. But then again if you're reading this then you should already know that. If not the rest of this may not make sense as sometimes we all, myself included, take knowledge for granted, so though I'll try to fully explain everything, I'm sure I'll leave little bits and pieces out.

What is going to happen here is we are going to turn this sector into a crusher, which will cause it to constantly change height. What this basically means is that when the crusher moves up the belt will slow down, then while the crusher moves down the belt will speed up. It is important to make this crusher silent, unless you like the noise it makes or are willing to move it clear across the map where it cannot be heard. Where I put the crusher start lines are not important, but the action is 150-WR Crusher Start (silent). Make the tag the same as the tag in the dummy sectors. It is not necessary to have the same tag for both dummy sector and in-game conveyor belt, so we will avoid potential hazards there. I'm sure it is doable with ceiling height triggers on the triggers to change the belt's velocity in combination with fake floors/ceilings, but that's just a hassle. I made the dummy sector 128 pixels tall, which in combination with the 150 action gives each setting 4 seconds.

So now we have a conveyor belt that moves monsters and when a player steps over a line it changes direction every 4 seconds. But something's still not right; the walls (sides) of the belt itself do not change velocity as well.





Put in another line of the same facing and length and give it action 249-Scroll Wall when Sector Changes Height with the same tag as the walls of the conveyor belt to which the adjacent trigger belongs. In this case, that means that the south line has to get the tags from the north belt because the floor/things line in the same southern sector was also for the north belt. Basically just keep the tags together.

At this point we now have 2 belts that not only change direction, but that also look flush while they do it. There's just one thing left...



We have to make sure the player never knows what we did here today. Kinda like "the best way to know we did a good job is if nobody knows we did anything at all" or when you set a trap in wait for a friend and call it a practical joke, hey, whatever, the important thing is yes.



So what we do is make a line with action 74-WR Crusher Stop. Set the tag to the dummy sector, just as you did with the crusher start moments (ages?) ago.



Now at this point we have a system that will work on top of an already existing conveyor belt system which will change the velocity to two extremes determined by the direction of sector movement within the dummy sectors and the length of the trigger lines within the dummy sectors while keeping the walls and floors flush with one-another.





I hope that sums it all up nicely. If I left anything out just let me know and I'll provide another massive wall of text :)



*Edit*
I forgot to mention that the change in movement direction also unsticks any stuck monsters. It took me a while to get monsters to get stuck and it all happens so fast it's hard to tell exactly that it did just happen, but I've confirmed that stuck monsters are unstuck through this method.

Wow! I can't wait to see the end result!

And, nice tutorial. You know, that wall of text and pictures might have a better home in Ling's Doom Editing Tutorials...

So how am I going to know which map this is, so I can download it and play it? (Maybe update this thread with the wad name?) I'm anxious, man! I love to see a slick Boom map, with nicely-disguised Boom and Doom specials.

Keep up the good work.

Thanks! I think it turned out well, though I now question whether-or-not I want to vertically mirror the dummy sectors as I think I'd rather have the slow-to-reverse effect kick in first to dislodge stuck monsters quickly rather than the system taking 4 seconds to get to that phase. *shrug* Won't matter where the lines are now, but being a non-linear map I may have to move them around and tinker on their placement to optimize their use. We'll see; I usually just tend to make things more complicated as time goes on.

I'm glad you liked the tutorial. I think I misworded a couple spots and wasn't fully clear in a couple others; I corrected one or two just now. I'd be honored to write an article for the tutorials here at DoomWorld, but I think if Ling decides to include it and for me to do it it'd be far better for me to compose a brand new thread to cut out all the extra b/s in here that won't help people looking for a tutorial (like my OP and whatnot). Also, I could probably have written that better.

This map is Z0k and my submission for the Ty Tribute Project, affectionately titled "WormHell" because it pays tribute to a couple of our favorite maps that Ty designed (all or in part), both from TNT: MAP04 "Wormhole" and MAP19 "Shipping/Respawning" and we freely utilize the wormhole concept which becomes Hell (not really, but the possibility is there and that alone is enough to create some nice tension), and the map finishes in Hell. Idk, it was a pet name both of us came up with randomly on our own for the map and it makes so much sense it's stupid. Or something to that effect, hah. The map is currently in a rough beta stage now, but when I pass it back off to Z0k I'll re-release what I got since I originally designed the ammo off the way I play, which is incorrect, and what was extra I put off the beaten path so it's no surprise (in hindsight) that ammo counts were too low. I also will likely reduce the difficulty in some areas because I may have gone a bit overboard in my assumption of difficulty, though that may be mostly mitigated by extra ammo, so that may not change too much. My next version will be balanced a bit better and the conveyor belt should now not have any issues, assuming the player doesn't mind the speed of the thing changing as they enter the room. Here's a link to the version with low ammo counts (I'll update this link when I post the new version in a couple days): https://www.doomworld.com/vb/post/1536817
HMP is a more traditional UV experience.



Still, the nice thing about the belts is that through the use of triggers and dummy sectors you can make it start any speed, then change it on a whim to anything you desire, then do it again, and again. I'd love to see a Boom-compatible map taking place in a big-ass factory with assembly lines that go to random places that make no real sense in the real world and change velocity/direction as you move on them, like Satan is at the control desk. Then you finally get there and it's a bull, with no intelligence whatsoever. The biggest mystery is how he pushed those tiny buttons... Back on subject, the possibilities of belts are only limited by one's own imagination in Boom format. Same goes for most things when mapping for Doom; it's just hard to be able to recall everything at all times to know what combination you need to make the desired effect work. But if you keep tinkering on it long enough, and of course add a couple extra heads to the think tank, you can do just about anything. I think that that's one of my favorite things about mapping for Doom; dreaming up some gameplay idea and making stuff work. Stuff like the mechanics of triggers and monsters/encounters always interested me the most. Placing monsters and pick-ups involves strategy, not too much unlike a chess game. Play the right pieces in the right places for maximum effectiveness. Hordes of rev closets are fun, but vastly over-used. But I still have much to learn and I hope I never stop learning more about making good, fun maps. I also hope that this map will be fun for people to play and is a good homage to one of our greatest members, Ty Halderman.

I'm glad you guys are doing this thing for Ty. I'll check out this version tonight!