Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
iori

Boom rant

Recommended Posts

Ok, so I am working on a fairly large map.. have been for a while now. Stupidly I've been using zdoom to test it, and now even though I've made it boom compatible, other boom compatible ports dont like the 'physics' that I've (unwittingly) tuned to zdoom.

More specifically, I've made sort of a Rube Goldberg device in a sense. I rather large network of conveyers and voodoo dolls that work behind the scenes to make a rather long series of events happen. I am extremely perplexed to find that although everything works perfect in zdoom.. all other boom ports (tested in prboom, prboom+ and eternity) hate it. Eternity is the only one that actually still works, but all the timing is off. Anyway, I've spent days tuning this machine, only to figure out that it wont work right in any port except zdoom... Do I go back and try and rework it for prboom(+) from scratch? Or Eternity at least, considering the thing doesn't seem to function well in prboom..

I think what I need is someone experienced with the inner workings of the doom engine to show me what is wrong with my device in prboom. I would be glad to send the map over and explain how the machine works... or is even supposed to work. And you know, maybe get some advice in what to do to repair it for the 'real' Boom ports.

I'm just only -slightly- irritated right now. :/

Share this post


Link to post

Um. More like ZDoom rant. If you design a conveyor belt scripting system and test it with Pr and EE it will probbably break in ZDoom, and contrariwise. Because ZDoom changed something with the way conveyors work, probably because it was "the way it was meant to be" or some other nickbakery. Fraggles binary ripple counter, for instance, gays up for me in ZDoom, but works fine in Pr(+) and Eternity (obviously it doesnt work in Legacy).

I could tell you precisely how to fix the map in question if I could see it. Or just an example wad.

Share this post


Link to post

The scrollers work differently in ZDoom. Boom had a bug in that code which caused all objects on sector boundaries to be moved at full speed by all touching sectors. Needless to say it isn't pretty if you can see this but it can break complex setups. When I was creating my Caverns of Darkness patch I had the same problem that the conveyors didn't do what they were supposed to do so I added a MAPINFO flag (additive_scrollers.) Which reminds me that this needs to be put in the compatibility options menu.

Share this post


Link to post

You should be able to get your conveyor belt scripts to work in all boom compatable ports. I myself have sometimes found that some of my 'scripts' only work in Zdoom or prboom (or vice-versa), but with a bit of tweaking and testing, I think I've normally been able to get them to work across ports.

Regarding timing, I've found that conveyor belt speed varies greatly from port to port. Having longer conveyor belts for delayed actions in comparison to having shorter conveyor belts for more immediate actions, is thus going to lead to differences in your timing depending on what port you use. And if your 'script' actually relies on actions timed by conveyor belt length, that might explain why they work in one port and not another.

To get around these timing problems I tend to 'time' any events using lowering floors as opposed to longer conveyor belts. Whilst conveyor belt speed seems to vary across ports, lowering speed doesn't seem to vary anywhere near as much. So if you want to have a timed event, instead of using a really long conveyor belt for something that's delayed, simply put the voodoo doll on a conveyor built, but behind a series of high floors which lower. That way your timings should be roughly the same, irrespective of what port you use.

Hopefully that makes some sense. But anyway, if you're still having problems maybe I could take a look at it for you if you want.

Share this post


Link to post

Yeah it does make sense. I'll see what I can do with lowering floors then, thanks.

Share this post


Link to post
iori said:

Ok, so I am working on a fairly large map.. have been for a while now. Stupidly I've been using zdoom to test it, and now even though I've made it boom compatible, other boom compatible ports dont like the 'physics' that I've (unwittingly) tuned to zdoom.

I am extremely perplexed to find that although everything works perfect in zdoom.. all other boom ports (tested in prboom, prboom+ and eternity) hate it.


I'd be interested if it works under Risen3D

It is a boom compatible port.

Share this post


Link to post
iori said:

Ok, so I am working on a fairly large map.. have been for a while now. Stupidly I've been using zdoom to test it, and now even though I've made it boom compatible, other boom compatible ports dont like the 'physics' that I've (unwittingly) tuned to zdoom.


I'm working on a map in PRboom+ and have run into the same problem. I had been working under the assumption that if I used prboom with the '-compat 9' option most boom ports would be able to play it. wrong! Faster/Non working conveyors, non working 'teleport to line', HOM's with moving glass floors, invisible monsters, to name a few of the gltches. My favorite is the conveyor that works for 5 minutes and then stops. WTF? So I know what you're going through. Would be glad to take a look at your map as I have a few workarounds for the compatability issues.
BTW Anyone else think that 'Boom compatable' in most readme's and reviews should be changed to 'Tested with:'?

Share this post


Link to post
Checkmate said:

'-compat 9'

If you're using literally that, then that won't be working. It needs to be "-complevel 9" in the command line or "default_compatibility_level 9" in the cfg.

If you are using the Boom complevel correctly, and the behaviour doesn't exactly match that of Boom 2.02 or Prboom 2.02, then report it as a compatibility bug. In this respect it would be useful to record a demo showing exactly what the difference is (i.e. that works in Prboom+ but not in Prboom 2.02, or vice versa).

Share this post


Link to post
Grazza said:

If you're using literally that, then that won't be working. It needs to be "-complevel 9" in the command line or "default_compatibility_level 9" in the cfg.

If you are using the Boom complevel correctly, and the behaviour doesn't exactly match that of Boom 2.02 or Prboom 2.02, then report it as a compatibility bug. In this respect it would be useful to record a demo showing exactly what the difference is (i.e. that works in Prboom+ but not in Prboom 2.02, or vice versa).


I am using "-complevel 9" just couldn't remember it off the top of my head. And I was talking about my Prboom+(gl version) level breaking in other 'Boom compatable' ports,(Risen3d, zdoom, Legacy, etc.)not any of the other 'Prboom' flavors. Sorry if I wasn't clear. I have no doubt Prboom+ emulates Boom very well. It's those other ports that don't do so well...

Share this post


Link to post

As stated ZDoom fuxt the conveyor behaviour because of a bug that really could have been fixt another way. Legacy doesnt even have voodoo dolls, so its certainly no fault of prboom, the boom map format or anything outside of legacy that conveyor scripts fail in that. I have never used Risen 3D so I cannot tell you why a voodoo something wouldnt work in it.

I can say that voodoo doll/conveyor scripts that work with PrBoom(+) under the Boom complevel will also work with Boom, MBF, and Eternity.

Share this post


Link to post

There is another potential problem with cross-port compatibility in regard to voodoo dolls on conveyors, though I haven't verified whether or not this affects ZDoom. The problem is, under Boom-based ports, voodoo dolls can wall-run. Yup, that's right, if a voodoo doll is perfectly tangential to a vertical or horizontal wall on a conveyor, the conveyor can cause the voodoo doll to wall-run, causing it to move at a substantially greater speed than normal (sometimes it may even miss triggering linedefs because it is moving so fast).

The solution to that issue is to make sure the voodoo dolls don't touch the walls. There's actually no advantage to having the channels for voodoo dolls be only the width of one player, and it'll cause many problems (the dolls may also lag or get caught on other types of walls depending on the angles involved).

Share this post


Link to post

Interesting.. prboom+ works way better with complevel 9.. even better than eternity (with its default complevel.. if that can even be changed). Would it be ok to fix the problems enough to release the wad for prboom+ complevel 9 or equivilant?

I am rather annoyed that there isn't an established standard codebase for conveyors after the boom standard, for fixes and whatnot. Or perhaps prboom w/ complevel 9 is this standard, being that prboom is the 'official' successor to Boom? Anyway, I would rather take the simpler path, slightly tweaking timings for prboom+ complevel 9, rather than creating elaborate 'failsafes' for an already elaborate script. I'm already having enough trouble remembering why I made a control sector a certain way in the first place!

@hawkwind: I'll get risen3d to test with.. but I would strongly recommend a software port to play with (when its done), due to the way doom's light diminishing works to create atmosphere.

@quasar: Interesting... This hasn't plagued me yet, but good to know. Couldn't segmenting the offending line with vertices limit the wallrunning effect?

Share this post


Link to post

iori said:
Or perhaps prboom w/ complevel 9 is this standard, being that prboom is the 'official' successor to Boom?

For all practical purposes, that is Boom; or at least it tries as fully as possible to be like the DOS Boom. It's there to record or reproduce Boom demos to a tee, so the behavior has to be exacting.

Share this post


Link to post

Well, I fixed things perfecly for boom 2.02 now, so thanks for all the suggestions everyone. I came across grazza's thread in the demos forums about the compat levels, so I'm glad my level works perfectly in stock Boom, which was the effect I wanted from the start. :)

Share this post


Link to post
myk said:

For all practical purposes, that is Boom; or at least it tries as fully as possible to be like the DOS Boom. It's there to record or reproduce Boom demos to a tee, so the behavior has to be exacting.


A while ago I found a minor discrepency with something in one of my wads between Boom and PrBoom's complevel for Boom in a wad I was working on. I need to find that again and report it heh.

Share this post


Link to post

Eternity has made no intentional changes to BOOM's conveyor belt behavior. If it differs, then it's a bug and should be reported :)

That being said, however, Eternity is not BOOM-demo compatible for a number of reasons, the main one being that Lee Killough had to replace some of the buggier parts of BOOM (especially the sector friction code) in MBF. This means maps using such features won't play back demos in EE. I don't consider it a problem as 99.999% of demos anybody cares about watching are for DOOM v1.9 :)

For that matter, EE wouldn't be able to play many demos recorded in earlier versions of itself because I've had to make major structural changes to mouse look, terrain types, 3D object clipping, and 3DMidTex lines. Fortunately, I'm not aware of a single such demo so it ends up not mattering.

Share this post


Link to post

Actually, there are quite a lot of Boom 2.02 demos that have been recorded. I wouldn't like to hazard a guess at the percentage of demos at Opulent's DSDA that are Boom format, but it must be a few percent at least (maybe more than 10% even), and a lot of them are very well worth watching indeed. These are both from the days when Boom was the best option for limit-removing purposes, and also for wads that use Boom features or fixes (e.g. Vile Flesh, Scythe2 and CC2, are examples from the last few years).

I have noticed that quite a few don't play back with Eternity (including some I have recorded), but I had always presumed that this was due to it being based (via MBF) on Boom 2.01.

Share this post


Link to post

I never denied there are BOOM demos, but I think v1.9 sync is what's most important. It's not like I have a choice, anyway, because stuff like the old BOOM friction code cannot be restored without causing code explosion >_<

Share this post


Link to post

But you had understated its importance. Boom is clearly the second most important demo format, and you put 99.999% where I suggest 90% might be appropriate - not an insignificant discrepancy.

Share this post


Link to post
Grazza said:

But you had understated its importance. Boom is clearly the second most important demo format, and you put 99.999% where I suggest 90% might be appropriate - not an insignificant discrepancy.

OK I will concede that 99.999% is too much ;) But there *are* an awful lot of v1.9 demos, mainly since those are the only ones that competitions generally accept ^_^

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×