Achieve consistent conveyor belt behavior between GZDoom and Boom/DSDA-Doom

[Fernito]

I'm working on a CL9 wad that relies heavily on voodoo doll scripting. I've been fine tuning the timing of the actions using DSDA-Doom, but I just tested it with GZDoom and, to my dismay, I found out that conveyor belts behave quite differently on GZDoom. Basically, a lot of things break.

 

I was hoping there is some compat flag that I could enable to fix this, but I haven't been able to find anything related to it. Any thoughts?

[Bauul]

The best solution I've come across is to make 32 map-unit wide "buffer" sectors with texture-but-not-thing scroll applied to them between the different sectors that have thing-scrolling enabled. That way players don't get multiple scrolling effects at once. It's tedious to set up but the end result is often worth it.

[ViolentBeetle]

I think they'll roll consistently if the length of the line that makes them scroll is divisble by 32.

[Stabbey]

I think I heard that lines 32 map units long which have the conveyor action on them behave consistently across all ports.

[Fernito]

Thanks for your answers!

 

I just tested it and, sadly, that's not the case :/ I ran some experiments with line lengths of 32, 64, and 96, and it appears that objects move twice as fast in DSDA compared to GZDoom given the same line length. 

 

[Fernito]

PS: Actually if I create a test map from scratch, the behaviors are indeed consistent between GZDoom and DSDA. I have no idea why this is not the case in my wad... Aarrrrgh!!!

[Fernito]

I recorded a video showing the difference between both ports with a line of length 32:

 

[Xaser]

GZDoom has a "compat_boomscroll" compatibility flag you can set in ZMAPINFO -- try setting that and seeing if that resolves or improves the issue.

 

There's a weird "flaw" in Boom's conveyor belt code that has been carried forward into all demo-compatible ports (by necessity ofc): when a thing's bounding box touches more than one scrolling sector, the scroll thrust for all sectors is applied to the thing. This means, in effect, that if your scrolling conveyor belt is split into multiple sectors (which is almost always the case except for simple voodoo closet setups), then it's going to double-apply the scroll to actors for a couple of tics while it crosses the sector boundary. It's jank as hell, but it is what it is.

 

GZDoom by default only applies a single scroll thust at any given moment (IIRC if the actor is touching multiple scrollers it averages them all -- don't quote me on that though), but the compat_boomscroll flag re-enables the old behavior. No idea if that will make it 100% accurate, but it certainly won't hurt. :P

[Fernito]

@Xaser thanks a lot for your reply. Indeed, the different speed issue only happens in conveyor belts that are split into multiple sectors.

 

However, I already have all the "Boom (strict)" flags set in my ZMAPINFO, but that doesn't seem to fix the problem :/

defaultmap {
	NoJump
	NoCrouch
	NoFreelook
	compat_boomscroll = 1
	compat_missileclip = 1 
	compat_soundtarget = 1 
	compat_trace = 1 
	compat_maskedmidtex = 1
	compat_corpsegibs = 1 	
	compat_invisibility = 1 
	compat_nopassover = 1 
	compat_maskedmidtex = 1
	compat_sectorsounds = 1
}

And I can confirm that this flag is indeed applied if I go to the settings:

 

So yeah :/ I really don't know what's going on...

[Doomy__Doom]

Looking at the setup in the video, if the problem is due to conveyor being made of multiple sectors, why not just... not do that? Draw trigger lines completely inside a single conveyor sector. Something like this https://postimg.cc/s1Q06GfR.

 

If you need sectors because of changing textures/sector specials via linedef that ofc nulls the solution, but yours seems to be lighting-related from what I can tell.

[Fernito]

52 minutes ago, Doomy__Doom said:

Looking at the setup in the video, if the problem is due to conveyor being made of multiple sectors, why not just... not do that? Draw trigger lines completely inside a single conveyor sector. Something like this https://postimg.cc/s1Q06GfR.

 

If you need sectors because of changing textures/sector specials via linedef that ofc nulls the solution, but yours seems to be lighting-related from what I can tell.

 

Yes, in my case it's divided in several sectors for lighting purposes, and I'm not willing to sacrifice that, atmosphere is very important for what I'm trying to achieve. I guess one option would be to make the individual sectors 32 units wide such that the voodoo doll can only be on one sector at a time, I guess that wouldn't be such a big compromise.

 

But in any case, I can't understand why the compat_boomscroll flag is not doing what it's supposed to do :(

 

 

[Doomy__Doom]

2 hours ago, Fernito said:

But in any case, I can't understand why the compat_boomscroll flag is not doing what it's supposed to do :(

It does what it's supposed to. But what it's supposed to do according to GZDoom does not include voodoo dolls as per this comment (source: codebase, duh)

// Some levels designed with Boom in mind actually want things to accelerate
// at neighboring scrolling sector boundaries. But it is only important for
// non-player objects.
if (player != NULL || !(Level->i_compatflags & COMPATF_BOOMSCROLL))
{
		if (countx > 1)
		{
			cumm.X /= countx;
		}
		if (county > 1)
		{
			cumm.Y /= county;
		}
}

If you race a pair of dormant imps on cut-up vs single-sector scroller, you'll observe one being faster than the other. Voodoo dolls will move at the "gzdoom" speed.

 

I'd love to be wrong about this (and if someone knows better please correct me), but the practical test result is the above.

[Fernito]

53 minutes ago, Doomy__Doom said:

I'd love to be wrong about this (and if someone knows better please correct me), but the practical test result is the above.

 

I see :/ Yeah, I kept experimenting a bit, and even widening the sectors to 32 units, the dolls were considerably slower in GZDoom. I guess I'll just have to deal with it and make some compromises. 

[Fernito]

56 minutes ago, Bauul said:

The best solution I've come across is to make 32 map-unit wide "buffer" sectors with texture-but-not-thing scroll applied to them between the different sectors that have thing-scrolling enabled. That way players don't get multiple scrolling effects at once. It's tedious to set up but the end result is often worth it.

That is indeed the best solution. And not difficult to implement in my case, since I already made them 32 units wide and I don't care at all about the scrolling being visible, meaning I would only need to remove the tag. Thanks for the suggestion!

[Xaser]

15 hours ago, Doomy__Doom said:

It does what it's supposed to. But what it's supposed to do according to GZDoom does not include voodoo dolls as per this comment (source: codebase, duh)

 

This definitely seems like something to change on GZDoom's end, worth opening a bugreport there. I can't think of a reason why you'd want to exclude voodoo dolls from the comp flag; I've heard of plenty of voodoo-scripting-timing-difference anecdotes over the years and this is certainly a relevant thing (if not the thing).

Edited July 20 by Xaser : typo fixins

[rita remton]

hi! i don't know if this helps in your case, but this layered conveyor belt design works consistently in dsda, prboom and gzdoom. anyway, good luck!
 

 

[Fernito]

18 hours ago, rita remton said:

hi! i don't know if this helps in your case, but this layered conveyor belt design works consistently in dsda, prboom and gzdoom. anyway, good luck!

 

Hey, that's a very cool concept, I dig it :) Thanks a lot, but I already implement the solution Bauul suggested and it's working as intended :)