Boom Scrolling Floor Issue

[myolden]

Hey all,

 

I've encountered a strange issue with scrolling floors in Boom and was hoping someone might have a solution. When I use Action 253 (Scroll Floor, Move Things) across connected sectors, Things in that sector will accelerate. It also appears that more connected sectors = more acceleration. Is there any way to build this same setup and keep the Things all moving at the same speed? I need to split the scrolling floors into different sectors so I can create a lighting effect, and plan on using Things as the "light source", but due to the acceleration the Things won't stay in sync with the light effect.

 

To demonstrate this, here's a quick video:

https://www.youtube.com/watch?v=wmUEuzkxrvk

 

And a screenshot of the demo in UDB:

[JadingTsunami]

Sounds like you have cases where the bounding box of the thing is in two sectors at once along its travel and the thrust is applied from both.

 

If you use teleporting linedefs (which preserve momentum) and a "dead" sector in the gap between each segment you may be able to avoid this effect. But it may create a juddery look; you'd have to try it.

[boris]

Since it works fine in GZDoom it might be affected by this Boom bug:

If you make your carrying action line much shorter you'll see that the thing get's a push each time it enters a new sector.

[Kain D.]

That's how this feature work in Boom sourceports. Scrolling floors are additive.

 

You can also set this behavior in Gzdoom, by using Mapinfo, or change it in compability options.

[traversd]

If you are looking to use the linedefs that border each sector in the arrangements on the right of your screenshot to make a pattern of light changes, you can possibly make all of the sectors a single sector with linedefs inside it so the scrolling action is only applied once. If you are need to activate floor texture changes etc then a single large sector like on the left of your screen shot and small enclosed sectors within it, with the necessary floor can be used for the script action.

[myolden]

10 hours ago, JadingTsunami said:

Sounds like you have cases where the bounding box of the thing is in two sectors at once along its travel and the thrust is applied from both.

 

If you use teleporting linedefs (which preserve momentum) and a "dead" sector in the gap between each segment you may be able to avoid this effect. But it may create a juddery look; you'd have to try it.

 

Yeah it's gotta be that or the Thing maintaining momentum from one sector + the velocity of the new sector. I'll have to experiment with the dead sector idea, but the jittering would probably not work for what I'm trying to do.

 

10 hours ago, boris said:

Since it works fine in GZDoom it might be affected by this Boom bug:

If you make your carrying action line much shorter you'll see that the thing get's a push each time it enters a new sector.

 

Yeah, the "push" is more obvious in the map I'm using this for, where the sectors are long enough that the additional velocity wears off.

 

5 hours ago, Kain D. said:

That's how this feature work in Boom sourceports. Scrolling floors are additive.

 

You can also set this behavior in Gzdoom, by using Mapinfo, or change it in compability options.

 

That is disappointing. I'm hoping there might be some kind of workaround.

 

4 hours ago, traversd said:

If you are looking to use the linedefs that border each sector in the arrangements on the right of your screenshot to make a pattern of light changes, you can possibly make all of the sectors a single sector with linedefs inside it so the scrolling action is only applied once. If you are need to activate floor texture changes etc then a single large sector like on the left of your screen shot and small enclosed sectors within it, with the necessary floor can be used for the script action.

 

I'm not entirely sure what you mean, but if I understand correctly you're suggesting I join the sectors? If I do that, then I can't light them individually. 

[JadingTsunami]

58 minutes ago, myolden said:

Yeah it's gotta be that or the Thing maintaining momentum from one sector + the velocity of the new sector. I'll have to experiment with the dead sector idea, but the jittering would probably not work for what I'm trying to do.

 

What effect are you trying to create? Can you use a self-referencing or "invisible" sector to pull the lights around?

[traversd]

1 hour ago, myolden said:

I'm not entirely sure what you mean, but if I understand correctly you're suggesting I join the sectors? If I do that, then I can't light them individually. 

 

The triangle sectors contain the light level/texture/type you want to transfer but are not tagged to scroll like the surrounding sector to avoid the additive effect. The highlighted linedefs have the actions to perform the transfers.

 

[myolden]

8 hours ago, JadingTsunami said:

 

What effect are you trying to create? Can you use a self-referencing or "invisible" sector to pull the lights around?

 

Essentially the map takes place on a vehicle, and I use scrolling floors/textures to create the illusion of motion. At the ends of the map, I progressively darken sectors to create a more natural looking "end". I also have trees placed outside the map which scroll and loop using silent teleports at each end of the map. The problem is that when the trees move through the scrolling floors where the lighting changes, they accelerate. This can cause them to "bunch up" and block the teleporter linedef. It's also going to cause other problems with other maps I haven't started yet that use a similar concept.

 

Screenshot:

Spoiler

 

 

7 hours ago, traversd said:

 

The triangle sectors contain the light level/texture/type you want to transfer but are not tagged to scroll like the surrounding sector to avoid the additive effect. The highlighted linedefs have the actions to perform the transfers.

 

 

I see what you mean now. I'm not using these scrolling floors as a voodoo conveyor. I'm lighting them, they're part of the map that's visible but outside the playable area. I need to divide parts of the scrolling floor into sectors so that they can have different lighting values.

Edited October 22, 2021 by myolden

[El Inferno]

Maybe you can make things stop after each loop, for example by flipping the target line direction. This way the speed won't accumulate.

Need to make sure that trees won't be getting stuck though 

[JadingTsunami]

5 hours ago, myolden said:

Essentially the map takes place on a vehicle, and I use scrolling floors/textures to create the illusion of motion. At the ends of the map, I progressively darken sectors to create a more natural looking "end".

 

In that case just teleport the trees outside the map into a holding area instead of restarting them immediately.

 

In the holding area you have a slower conveyor which will "drain" the extra acceleration. At the end of the holding area you teleport the trees back into the moving path.

[myolden]

4 minutes ago, JadingTsunami said:

 

In that case just teleport the trees outside the map into a holding area instead of restarting them immediately.

 

In the holding area you have a slower conveyor which will "drain" the extra acceleration. At the end of the holding area you teleport the trees back into the moving path.

 

26 minutes ago, El Inferno said:

Maybe you can make things stop after each loop, for example by flipping the target line direction. This way the speed won't accumulate.

Need to make sure that trees won't be getting stuck though 

 

The issue isn't caused by the loop, it's caused by the Things going through the gradient lighting. Below is a video of this in action, and if you watch you can see the issue crop up as Things scroll by - they change velocity as they go through the sectors with the gradient lighting and bump into one another. It seems like a minor issue, but it causes 2 problems in this particular map:

 

1. Things can become bunched up, blocking the teleport looping from one end of the map to another. 

2. It can break the illusion of movement as seen from the vehicle.

 

I planned on taking this concept and expanding on it with later maps - moving light effects, enemies on walkways outside the map, etc. So these problems will likely be compounded when I iterate on this concept and add more complexity to it, which is why I'm trying to find a workaround that allows multiple scrolling sectors to be adjacent to one another without causing this acceleration. 

 

 

 

 

[JadingTsunami]

31 minutes ago, myolden said:

The issue isn't caused by the loop, it's caused by the Things going through the gradient lighting.

 

I understand the issue. I tried the solution I proposed in a test map and it does appear to work.

 

You'll have to tune it to the specifics of your map.

[El Inferno]

Here's some "easy" alternative solution using referncing tricks and overlapping linedefs:

testscroll.zip

 

Note that those long horizontal lines are connected to sector 22 which in turn has tag 2 and so it scrolling. So anything which touches the lines will scroll as well. But the speed will not accumulate since this is technically only one sector which is scrolling! 

 

[myolden]

8 minutes ago, JadingTsunami said:

 

I understand the issue. I tried the solution I proposed in a test map and it does appear to work.

 

You'll have to tune it to the specifics of your map.

 

Can you send me the test map? I'm not certain how this fixes the issue.

 

5 minutes ago, El Inferno said:

Here's some "easy" alternative solution using referncing tricks and overlapping linedefs:

testscroll.zip

 

Note that those long horizontal lines are connected to sector 22 which in turn has tag 2 and so it scrolling. So anything which touches the lines will scroll as well. But the speed will not accumulate since this is technically only one sector which is scrolling! 

 

 

This is an interesting solution, but I'm a little confused as to how it's implemented. How did you connect those horizontal lines to sector 22? And get the horizontal lines to overlap with the sectors without creating vertices where they intersect?

 

As far as my purposes go, the only downside appears to be this grid shape that shows up in game. Not sure what causes that, though.

 

[El Inferno]

10 minutes ago, myolden said:

As far as my purposes go, the only downside appears to be this grid shape that shows up in game.

 

Yeah that's how software rendering reacts to badly connected lines. gl rendering looks better though still a bit buggy. 

To make overlapping lines you need to select this thing:  and then move a linedef where you want, the builder won't create new vertices. After that you probably want to switch back to "Merge dragged geometry"/"Replace dragged geometry"

To connect line to sector 22, just edit linedef window and change the entry "Sector index" for either front or back linedef to 22. 

[myolden]

3 minutes ago, El Inferno said:

 

Yeah that's how software rendering reacts to badly connected lines. gl rendering looks better though still a bit buggy. 

To make overlapping lines you need to select this thing:  and then move a linedef where you want, the builder won't create new vertices. After that you probably want to switch back to "Merge dragged geometry"/"Replace dragged geometry"

To connect line to sector 22, just edit linedef window and change the entry "Sector index" for either front or back linedef to 22. 

 

Wow, I had no idea that was even a thing. I'll try implementing this at some point and see how it works. Thanks!

[traversd]

It might only minimise the issue, but maybe try putting a non-scrolling sector between each scrolling sector such that the amount of time the objects are considered on both sectors is reduced?

[Nine Inch Heels]

I honestly don't even know why you would have that many tagged sectors within the conveyor in the first place, because it's entirely possible to use control sectors outside of the conveyor to adjust the lighting, rather than trying to build your conveyor such that it also contains the referential sectors that will change the lighting in your map...

 

It's entirely possible to have a line within a sector that doesn't somehow split the sector, and no boom-compatible port will ever give you any trouble for that. The lines will be triggered just as you would expect..

 

And as an added aside, if you happen to want your map to function exactly the same in GZDoom as well as DSDA-Doom, you'll want to stick to action 253/252 lines with a length of 32 or a multiple thereof, otherwise the difference in how either port "maths stuff" may cause your sequence to go "out of sync" in one of the two source ports, which is especially important for setups that rely heavily on timing in some fashion...

 

Thread with some related info:

 

Also, if you want to use any type of "blocker" to prevent the conveyor from running on map start, consider using these small triangles traversed has pulled up, but lower the floor of these triangles by any number of mapunits to avoid contact between a "thing" and non-scrolling parts of the conveyor for added consistency...

 

2 setups that use control sectors (Doom2 required, boom format):

crude demonstration of lighting that "cycles": lightingshit.zip

 

another crude demonstration of lighting that fades in or out: moarlight.zip

Edited November 3, 2021 by Nine Inch Heels

[myolden]

8 hours ago, Nine Inch Heels said:

I honestly don't even know why you would have that many tagged sectors within the conveyor in the first place, because it's entirely possible to use control sectors outside of the conveyor to adjust the lighting, rather than trying to build your conveyor such that it also contains the referential sectors that will change the lighting in your map...

 

It's entirely possible to have a line within a sector that doesn't somehow split the sector, and no boom-compatible port will ever give you any trouble for that. The lines will be triggered just as you would expect..

 

And as an added aside, if you happen to want your map to function exactly the same in GZDoom as well as DSDA-Doom, you'll want to stick to action 253/252 lines with a length of 32 or a multiple thereof, otherwise the difference in how either port "maths stuff" may cause your sequence to go "out of sync" in one of the two source ports, which is especially important for setups that rely heavily on timing in some fashion...

 

Thread with some related info:

 

Also, if you want to use any type of "blocker" to prevent the conveyor from running on map start, consider using these small triangles traversed has pulled up, but lower the floor of these triangles by any number of mapunits to avoid contact between a "thing" and non-scrolling parts of the conveyor for added consistency...

 

2 setups that use control sectors (Doom2 required, boom format):

crude demonstration of lighting that "cycles": lightingshit.zip

 

another crude demonstration of lighting that fades in or out: moarlight.zip

 

I feel like you're misunderstanding the nature of what I'm trying to do here. These are not voodoo conveyor belts. I'm using scrolling floors to create the illusion of motion in a map that takes place on a vehicle.

 

Watch this video. It shows what the map looks like when you're standing on the vehicle and looking off into the scenery. You can see how I'm using multiple sectors to create a "fade" in the distance.
 

 

Edited November 3, 2021 by myolden

[Nine Inch Heels]

4 hours ago, myolden said:

I feel like you're misunderstanding the nature of what I'm trying to do here. These are not voodoo conveyor belts. I'm using scrolling floors to create the illusion of motion in a map that takes place on a vehicle.

I guess that's what happens when I'm browsing the web late at night... Although...

 

...Looking at this for a moment, you can still get around the problem of having the objects scroll across multiple sectors, which messes with the timing and the speed there... You could put the trees on proverbial rials (2 rails, which are one singular scrolling sector each, raised by just 1mu), while you use any number of sectors you think you need between and on either side of those rails to create the lighting effect...

 

If I'm not entirely mistaken, the trees should then also fade out, provided their centre is above a sector with the desired lighting...

[myolden]

18 minutes ago, Nine Inch Heels said:

I guess that's what happens when I'm browsing the web late at night... Although...

 

...Looking at this for a moment, you can still get around the problem of having the objects scroll across multiple sectors, which messes with the timing and the speed there... You could put the trees on proverbial rials (2 rails, which are one singular scrolling sector each, raised by just 1mu), while you use any number of sectors you think you need between and on either side of those rails to create the lighting effect...

 

If I'm not entirely mistaken, the trees should then also fade out, provided their centre is above a sector with the desired lighting...

 

That's an interesting idea. I'll give it a shot and see how it goes. Thank you!