Share this post

Link to post

Let me guess: you came from ZDoom, and then it didn't work in a more conservative engine?

This is a bit of a tangent, but I feel like explaining why this is anyway, at least from my understanding.

See, ZDoom only has one level mode, which may seem obvious if you don't think about it too hard, but there's a significant amount of difference between Doom and Hexen's level format. See, in Doom, there's S( witch ) and D( oor ) specials, while in Hexen, line specials and their trigger are separate parts of the linedef. And as it happens, Hexen combines the two into a single Use trigger. Which makes sense on its own on paper, but in execution there's the whole difference between D specials applying to the sector behind the line and S using the line's sector tag parameter.

But since every sector as a sector tag of 0 unless otherwise stated and having a linedef affect the entire map except sectors that were tagged was pretty much exclusively a mapping mistake with Hexen's line specials, they just used that "free" tag as a way to implement the D special logic into their own specials, aka instead of affecting sectors tagged 0, a special targeting the tag 0 instead targets the sector behind its line.

Cut back to ZDoom and the fact that it only has one level mode. See, when you're playing a Doom map in ZDoom, you aren't playing an close emulation of Doom's in-game map format like you are with a lot of other source ports ( with Eternity I believe outright having two different in-game map formats for the sake of Doom and Hexen / UDMF maps ), but rather the map data is read from the wad and translated into the in-game map format used for Hexen and UDMF. Which means line specials are translated from Doom line specials to their equivalent in Hexen - but here's the deal, whereas a D special is easily translated into a 0 tag target equivalent, what do you do with a S special that targets the 0 tag itself?

You end up with the exact equivalent - a special that does the same exact action that targets the 0 tag.

So it's not so much an intentional design decision as much as an oversight of how everything comes together internally that's just too old to really fix, considering people have made "ZDoom in Doom" format maps made with this quirk in mind, which ... ZDoom really has no way of differentiating between it and Boom, considering it's practically just Boom format with some extra actors and a sign for level editors to check for Decorate and MapInfo and the like.

Share this post

Link to post

There was a small but far-reaching oversight when the translation tables for Doom -> Hexen map format were made.

Keep in mind that this was in 1999, when binary formats and bit-shaving were "the things".

So, instead of making the translation tables text-based, they were binary, with an external compiler.

But since one of the overreaching goals of this setup was to create files as small as possible, it only handled the barest minimum of information.

And a simple flag 'do not allow 0-tags' was simply too much for such a setup, because apparently the flag byte was full.

Another weird consequence of this kind of ill-advised efficiency was that the format could not translate one of Strife's types because it required an argument of 1024. The solution was not to fix the format. No, the solution was to implement this single action through ACS...

It was only years later, around 2007 when I integrated the compiler into ZDoom, but then the damage was done, there were countless maps depending on this little quirk. Fixing the problem is a triviality but what's a fix worth that breaks existing maps? :(

Share this post

Link to post

I started mapping in Boom format only 10 days ago! (though I made 40+ Vanilla/LR maps).
Boom is a flexible and upgraded Doom but without any unnecessary twists. Such a Doom that was supposed to be released in 1993.

Share this post

Link to post

The existence of Boom as an unofficial standard is partly due to how Raven software handled its source release - for many years, it was not available under the GPL license. It seems that most doom ports switched to the GPL license, but ZDoom didn't, and was thus able to use Heretic and especially Hexen's code to expand what the port was capable of.

It's not that the other ports were unwilling to keep up with ZDoom, they couldn't do so, legally. Or at least, if they wanted to, they had to be selective about what they backported, in order to not touch a "derived from Raven" third rail.

I suppose the port authors could have always gone back to the Doom Source License if they wanted to follow suit. I have my suspicions as to why they didn't, but I don't presume to speak for them.

Edited April 16, 2017 by AlexMax

Share this post

Link to post

For me it's pretty simple. Boom maps still have that inherent Doom 'feel' to them while still allowing for some more advanced/useful features such as multiple action switches - it's as simple as that for me, nothing to do with source ports (i usually play with GZDoom anyway) or demos. zDoom specific maps hold no real appeal to me when something like Half Life exists and naturally offers that type of gameplay. Mouselook (especially) in Doom feels wrong to me.

The only mapping format i don't really understand is limit removing. It's neither here nor there, you might as well just do a Boom map and give yourself some extra options.

Share this post

Link to post

I personally find Boom to be a little irritating for me. There are some quirks that separate cl2 and cl9 for the worse, and having become aware of them they drive me crazy.

1. cl9 - If you run out of ammunition for the super shotgun, the reloading animation still has to complete even though you don't have any shells left. In cl2, you fire and the gun drops immediately after and switches to the next.

2. cl9 - If you run out of ammunition for another weapon, it will by default switch to your most powerful weapon with ammunition excepting the BFG and the rocketlauncher. However, in cl2, if you run out of shotgun shells, and the game wants to switch to your plasma gun, you can press 4 during the change weapon to animation to change to chaingun instead if you prefer not to use your cells. cl9 doesn't seem to allow this so you have to switch to your plasma gun, then switch again to the chaingun, which can be a serious timing problem in a precarious situation.

Boom certainly has some cool stuff like light transfers, height transfers, fake floors/ceilings and sky transfers. But for the most part I find having to scroll through all the list of linedef actions to be kind of tiring while mapping, especially when I usually stick to my short list of preferred linedef actions in which I memorized. Using any more advanced source port features unnecessarily complicates the issue even further.

What source port you choose to map for is entirely up to the user, but I have a certain ingrained belief in me that the further a source port strays away from the source material of the game, the less the modder actually enjoys the game as it is. And if that's the case, I have to be dubious about whether the person knows what they're doing or if their interests are going to align even slightly with mine as a player.

Share this post

Link to post

Weapon-changing code in PrBoom+ certainly needs attention. If only because it's still impossible* to choose SG and the fist directly, even though it's supposed to be a feature - which works in MBF. The code is broken.

* Actually there's a way: you need to edit the weapon preference order so that the fist comes before chainsaw, and SG comes before SSG. Then you'll be able to set separate buttons for all these weapons. But it's a lousy workaround.

41 minutes ago, 40oz said:

But for the most part I find having to scroll through all the list of linedef actions to be kind of tiring while mapping, especially when I usually stick to my short list of preferred linedef actions in which I memorized.

You don't have to use the common list, the actions are categorized. Unless you're talking about all the lists inside categories.

Edited April 16, 2017 by Da Werecat
: Corrected myself.

Share this post

Link to post

1. cl9 - If you run out of ammunition for the super shotgun, the reloading animation still has to complete even though you don't have any shells left. In cl2, you fire and the gun drops immediately after and switches to the next.

2. cl9 - If you run out of ammunition for another weapon, it will by default switch to your most powerful weapon with ammunition excepting the BFG and the rocketlauncher. However, in cl2, if you run out of shotgun shells, and the game wants to switch to your plasma gun, you can press 4 during the change weapon to animation to change to chaingun instead if you prefer not to use your cells. cl9 doesn't seem to allow this so you have to switch to your plasma gun, then switch again to the chaingun, which can be a serious timing problem in a precarious situation.

Oh wow.. I pretty much never play PrBoom, but that behavior is flat out incorrect. Loading 2 nonexistent shells? Lmao, how absurd! Both of these must have been oversights, but they would both be frustrating as all hell in a challenging area since it just leaves you exposed for longer than you should be for no reason at all.

Share this post

Link to post

You don't have to use the common list, the actions are categorized. Unless you're talking about all the lists inside categories.

It's just a preference issue. I don't find Doom 2 to be particularly lacking in any of the types of linedef actions I need and all the extra stuff seems like unimportant minutiae. Boom seems to include a wealth of seemingly unnecessary actions to fill in logical holes. Stuff like Gunfire Exit Level. Does anybody really need this?

(any answer you come up with is comparably more ridiculous from a player's first person perspective to switch exits or walkover exits)

Share this post

Link to post

That's not what turns it off to me. Chocolate, Crispy, Boom, MBF are all 4:3 only and all have valid uses. In this case what turns me off from Doom Legacy is that it has no aspect ratio correction whatsoever. If it's Doom Legacy and it isn't a multiple of 320x200, everything will look wrong. The fact that it doesn't provide 640x400 and 960x600 doesn't help matters...

Granted, that's just one of many issues with Doom Legacy. I'm pretty sure that once 3dge's split screen support is finished and or the Eternity Engine's support for Heretic is completed, the main thing Doom Legacy will be good for is Chex Quest Zorchmatch Splitscreen, and if ZDoom ever gets Split Screen support which Zandronom would inherit even that will be gone, with Sonic Robo Blast 2 the main part of Doom Legacy with any popularity...

Edited April 17, 2017 by Danfun64

Share this post

Link to post

I use Boom because for me it is the perfect middle ground between the simplicity of limit removing format and the complexity of ZDoom based formats, I get new super fun features and line actions to work with without getting bogged in all the extras I rarely use like ACS and speed settings.

Share this post

Link to post

(any answer you come up with is comparably more ridiculous from a player's first person perspective to switch exits or walkover exits)

My immediate first thought is an exit posed as some sort of train, trolley, or elevator that its operated externally - it seems pretty dang action movie to hop into a vehicle to anywhere else, and then blast the operation panel with a shotgun to get it rolling.

It's worth remembering, though, that having this sort of feature completeness is a big part of Boom - to the point where they flat-out added the ability to generate any combination of trigger, special, direction, speed, distance, etc.. I imagine a lot of the more superfluous specials came from before that feature was added, as a sort-of primitive form of Hexen's separation of trigger and special.

Share this post

Link to post

One, it puts forth that there's only one way to learn, and that just messing with stuff for the sake of learning how it works and experimenting with it is so bad that it deserves a label, despite the fact that that can be the best way for some people to learn.

a map's visuals or gimmicks can be the entire reason it exists in the first place.

I must have worded things in a way that can mean multiple things and so it was taken the wrong way here.

First, every map I made where I have learned something new, it was precisely what you described, messing with a feature to find out how it works through experimentation, sometimes at random.

Also, by gimmicks I mean something like adding a lot of slopes to a map without having a good knowledge of player speed and movement (by choosing to use these in your early maps) so that it causes a lot of bumps and snags similar to detailing that you can get stuck on. Not full map defining setups.

As for ACS, I prefer it much more over voodoo dolls now, having built some of the most complex I know of (see Cretaceous Cogs from Doomworld Roulette Session 2) as it allows me to get precision easily and loop things without having to rig together a mess in the void of the map that performs differently based on source port.

As an example, my setup in Piston Hurricane (Mayhem 2016) has a different timing in GZDoom than PrBoom.

Share this post

Link to post

I don't think programmers grasp that, for anyone who doesn't have experience with the C language, the above is confusing at best, and potentionally incomprehesible.

(Deleted rant about how horrible the syntax of C is, why BASIC would be a much better choice, and hacking ACS from ZDoom Wiki examples.)

However if you already making DOOM maps, then having a fake player doll trigger line actions as it moves along a conveyor belt is a simple concept to grasp, because you've already learnt all the things you need to know to make that work.

Share this post

Link to post

However if you already making DOOM maps, then having a fake player doll trigger line actions as it moves along a conveyor belt is a simple concept to grasp, because you've already learnt all the things you need to know to make that work.

Ouch! That's also a way of justifying crutches.

Can you tell me how far the player needs to move to get an interval of 1 second between two actions? Do you know how you have to place the lines so that they are guaranteed to get triggered at exactly the correct point in time?

Can you build a conveyor script that halts and continues when some other action is complete?

Even the simplest things will turn into a computational hassle you can only solve with trial and error.

With a text based script you just say 'delay(35) or (tagwait(5)' and do not need to think about it any further. In the time when you have gotten your conveyor to do what you want I would have written 10 scripts of the same simple type.

Share this post

Link to post

time=distance/speed; physics! Most ports come with timers too, btw. Also, mappers are free to place triggering-lines anywhere on the map, combined with the ability to delay actions through voodoo scripting (as well as other means), gives mappers total freedom on the timing of their mechanics in yes, Boom format. I have never felt limited in the timing aspect of Boom mapping. Boom format can even change the entire architecture of a map depending on the difficulty level.

6 minutes ago, Graf Zahl said:

Do you know how you have to place the lines so that they are guaranteed to get triggered at exactly the correct point in time?

Yeah, you open DB, mouse to where you want the first vertex, hit 'insert,' drag the mouse and left click it where you want it to go. Seriously, this is so stupid; exactly what I meant about bringing up minute details that are totally baseless.

Positioning plus time and maybe a few mechanical locks. The only limitation for the timing of a mechanic in Boom format would be thing-triggers, which have nothing to do with scripting and can often be accomplished in other ways anyway.

7 minutes ago, Graf Zahl said:

Can you build a conveyor script that halts and continues when some other action is complete?

Yes; easily. That's like basic conveyor belts right there. Scroll/move accelerate on sector changing height is a permanent change to the velocity of a sector.

I know you've seen the Boom calculators... even those monstrosities and fusterclucks-of-trigger/belts have few errors, most of which could probably have been rectified with a bit more care to the doll bumping into the walls.

8 minutes ago, Graf Zahl said:

Even the simplest things will turn into a computational hassle you can only solve with trial and error.

With a text based script you just say 'delay(35) or (tagwait(5)' and do not need to think about it any further. In the time when you have gotten your conveyor to do what you want I would have written 10 scripts of the same simple type.

Perhaps, but implementation is the quick part. This is the one point of your post that has legs to stand on: that typing is potentially faster than setting up a bunch of lines, but it just as often takes more than one line of code to equate to one triggering line in-map as it does a few lines of code equating to a hundred trigger-lines.

Both methods have areas where things can go wrong, down to even simple mistagging as all authors are human; every mechanic should be tested after implementation and it's capabilities to go right/wrong understood. One nice thing about voodoo dolls: it's very easy to see in-game where something goes wrong within the scripting itself, rather than relying on noticing a bug/symptom and combing through scripts from there.

Share this post

Link to post

I decided to conduct a little experiment to see what the difference is in actual practice: I would attempt to program the same small series of events using firstly a Boom Voodoo Doll, and then ACS. I've never used either, so it would mean starting from scratch for both approaches. All I have are vanilla mapping skills. This would be a genuine test of which is the more efficient approach.

The experiment would be to create a switch that lowered the door to the room the switch was in, turn off the lights, and open an adjacent monster closet.

Here's how it went:

Boom Voodoo Doll

I know broadly speaking that Voodoo Dolls impact the game as if they were a player, hence the name, so I figured I could use the Voodoo Doll along with a conveyor belt to trigger all three actions at once. In my mind, I'd use the switch in the room the raise a barrier on the conveyor belt, and allow the to Doll pass through the linedefs.

First up, I looked up how Voodoo Dolls work. A quick Google search got me to the Doom wiki, which said “Creation of a voodoo doll inside of a map is trivial; it is as simple as placing more than one player start for the same player inside of a map.”

So I added a second player start, tested the map, and promptly discovered it’s the first Player start that becomes a Doll, not the second. So I made sure to flip the player starts around.

I got my corridor set up where the conveyor belt would be, and added a mini sector at 55 units high which would act as my barrier. I then added three linedefs for the three actions. It took about 10 seconds to find the three linedef actions I wanted from the list in GZDB, and quickly lined up the tags. All that was left was to set up a conveyor belt.

Google searches didn’t work all that well - I couldn't find any single wiki or tutorial on "conveyor belts", so I started playing about: I set the Sector action to “wind” but that didn’t do anything. I tried putting in Pusher and Puller things, and they didn’t do anything either.

I Googled some more and found this thread. In it, Jodwin talks about “make the line controlling it shorter” which made me think I perhaps needed a control linedef. I added a linedef running down the center of the corridor, and looked at the Boom linedef properties. Sure enough at the bottom was a “Wind according to line vector” action. I tried that and bingo! Worked like a charm. I changed the length of the linedef to make it quicker and tested the map. Worked perfectly. There is a slight delay on pressing the switch to seeing the results, but I can live with it.

Total time: 12 minutes

Total in-game map tests: 3

Summary: Pretty straightforward. With the exception of getting the conveyor belt to work, everything made sense and worked like I expected it to.

ACS Approach

First up, I loaded up the Doom wiki's A Beginner's Guide to ACS and begun reading. I gathered what I was after was a "void" script, and that I needed to use Linedef action 80 to trigger it. I began by grabbing the example in the page.

script 2 (void)
{
print(s:"Bye World!");
}

I changed the script to "1", assigned the switch linedef to 80 and picked "1" as the script. Went in and tested and worked perfectly.

Next I Googled "ACS Doom Close Door". This page looked sensible. I copied a line from the example and made the necessary changes.

script 1 (void)
{
Door_Close(1, 32, 0);
}

The middle variable was said to control the speed, but the page didn't have any limits or examples, so I just left it at 32 hoping that was "normal".

I try to play the map, but get an error sign next to the "Door_Close" line. The usual "oh god what's wrong" feeling started creeping in whenever code doesn't work and you have no idea why. I wonder if it's the final variable, so I change that to a "1" and still get an error.

After comparing the line character by character and seeing no difference to the Wiki, I deleted the whole script and started again. I was halfway through rewriting it when I realized my mistake: the example on the very first page had left out the "#include "zcommon.acs"” part, so I added that in.

#include "zcommon.acs"
script 1 (void)
{
Door_Close(1, 32, 1);
}

Finally that works!

Ok, time to try opening the door. I Google "acs doom open door" and get two promising results: Door_Open and Door_Raise. I have no idea which I should use, so I stump for Door_Open. It seems to be the right choice, and looks similar to Door_Close. There's no example on the page, so I copy the line from the top and put it into the script.

The "11:" at the beginning isn't there in the Door_Close, so I guess it isn't needed and delete it. I give it a test and it works! No errors, phew.

Ok, final part, changing the light. I google "acs doom light level" and see a bunch of stuff that doesn't look quite right. Of the options, Light_Fade looks perhaps the closest. The instructions look clear enough, so I add it to my script and set the variables how I think I want them:

I test it and get an error. I wonder if it's because there's a space between the bottom two commands and their variables, but not the top one? I remove the spaces and try again, and still get an error. I'm about to delete the Light_Fade row and start from scratch when I spot the final character is wrong - it's a : not a ;. I make the final change and test it.

Summary: Not as difficult as I had expected it to be, but definitely work. Required a totally different mindset to mapping, a lot of Googling, and a lot of trial and error.

In conclusion

ACS is obviously more powerful than Boom Voodoo Dolls, and if you're familiar with it, likely quicker to write too. But it was an uphill struggle for me. The Boom approach was much, much simpler for me, as it built on my mapping skills I already have. ACS required starting from scratch, and it felt so much more intangible than the Boom approach. More than once I got an error that I just had no idea about, and had to scrap everything and start again, attempting to follow the examples to the letter. But building a corridor and putting in barriers and linedefs - that I know how to do. It just took so much less brain power.

Obviously if you know ACS that's the better approach, but hopefully this gives you an idea of why so many people like to stick to conveyor belts. They're just so much easier for a Doom mapper with no coding experience to get their heads around and get back to the important stuff: being creative and designing maps.

Share this post

Link to post

But it was an uphill struggle for me. The Boom approach was much, much simpler for me, as it built on my mapping skills I already have. ACS required starting from scratch, and it felt so much more intangible than the Boom approach. More than once I got an error that I just had no idea about, and had to scrap everything and start again, attempting to follow the examples to the letter. But building a corridor and putting in barriers and linedefs - that I know how to do. It just took so much less brain power.

I think you were a bit too quick to draw a conclusion, since you admitted yourself that this was the first attempt at ACS you tried.
Your mistakes were typical beginner's errors and your experience is really not representative for regular work as the first steps with a new tool are always a bit rough.

But that will quickly pass if you continue using it, once you have gained an understanding all this initial inertia will be gone - and then writing a few lines of script code will definitely go a lot faster than building a conveyor script.

Share this post

Link to post

Next I Googled "ACS Doom Close Door". This page looked sensible. I copied a line from the example and made the necessary changes.

script 1 (void)
{
Door_Close(1, 32, 0);
}

The middle variable was said to control the speed, but the page didn't have any limits or examples, so I just left it at 32 hoping that was "normal".

I... what? You take a line from an example, and then say there's no examples? Also did you miss all the "conversion from line types" section that gives you how the Doom-format specials are translated?

24 minutes ago, Bauul said:

Ok, time to try opening the door. I Google "acs doom open door" and get two promising results: Door_Open and Door_Raise. I have no idea which I should use, so I stump for Door_Open. It seems to be the right choice, and looks similar to Door_Close. There's no example on the page, so I copy the line from the top and put it into the script.

Share this post

Link to post

The Boom approach was much, much simpler for me, as it built on my mapping skills I already have.

Wow, are you telling me format X is easier because you already knew what you were doing? Shocker!

To be honest this is a huge post for nothing and comes down to one thing, most of you are not arguing from the stand point of someone who knows nothing, rather from the standpoint of someone with experience in X formats.

There is absolutely NOTHING intuitive about out of bounds conveyor belts with additional player 1 starts. Think about telling someone that who has never mapped for Doom. "Yea do make a "script" function you gotta make a conveyor belt outside the map and add a bunch of additional player 1 starts." It sounds absolutely ridiculous (because it is).

At the same time, there is nothing immediately intuitive about using ACS either. But at least it makes sense, even to a total dipshit like me who literally copy and pastes every script I ever do or have other people do it for me because I am completely incapable of doing it.

Both forms require actual "research" into mapping techniques, peeking into other maps to see how other people did cool functions you want to do, reading up wikis, etc. Claiming one or the other as inherently easier is stupid.

Share this post

Link to post

Nothing against Boom, but isn't it sad that PrBoom has been the sole obstacle to further advancement for too many years now?

Imagine where mapping could be if the most demo compatible engine had subscribed to some careful expansion of its feature set instead of just preserving the status quo...

Instead, we are still stuck with a 19 year old standard as the most widely accepted baseline. :(

Wow. PrBoom as the obstacle. Here's the way I see it - time for Memory Lane:

The Linux source was released. Very quickly afterwards, the Boom team (TeamTNT) worked diligently to remove original limitations, correct crashing bugs, and eliminate sources of undefined behavior, allowing demo compatibility to become a stable, viable thing.

They also wanted to add editing features, so they developed ways to add functionality that fit within the limitations of the original format. Boom added features that could be put into maps using existing map editors, or with minimal changes to those editors. Furthermore, they added features to the code in a highly unobtrusive way. This allows, to this day, the ability for coders to add Boom support to a vanilla engine, in a day or less. This was largely driven by Lee Killough. Say what you will about his coding style, but it cannot be denied that adding Boom support (and, subsequently MBF support) can be done rather painlessly, into just about any Doom code base you see fit.

This is important, for a few reasons:

There are lots of versions of Doom, that have been ported to an impressive number of systems. My claim is that Boom/MBF support can be added to any of those engines that are not totally out of room for new code.

Building a Doom port is an activity attempted by many. Some people start their programming careers by wanting to play with the Doom source (And, then they realize that they need to first learn the basics.) Furthermore, some people want to start with the original source, and try their hand at making some changes on their own. These people want to start at the simple end of the spectrum, and move forward from there. Having a nice, easy to implement upgrade available, like Boom or MBF, is a very welcoming path to take.

In the Good ol' Days, source ports authors had a chance to share code and ideas, because their code stayed near and dear to the original Linux source. So did Boom and MBF, so much so that many ports came to accept these as standard add-ons. In fact, for a short time, there was a Doom Committee dedicated to keeping ports compliant, by, for example, dolling out unused linedef types, or doomednums.

But then, a strange thing happened. For some reason, certain port authors had lots of ideas, and started refactoring their source to their liking, and adding features without much concern for what other port devs were doing. Whole systems were added - systems that required large custom libraries to support, or large custom modules to implement. Some of this was due to the desire to have one engine handle all of idTech1 games.

Code like this could no longer be shared with other port authors, unless those authors refactored all of their code to match, and included all of those libraries/modules to their otherwise-similar-to-original code. From this point, compatibility was truly lost, and that, my friends, is when "we got stuck with 19 year old standards."

As for PrBoom being the obstacle? This can't be further from the truth. PrBoom (especially PrBoom-Plus) is Doom with limits removed, Doom with crashing bugs eliminated, Doom with pretty close to perfect demo playback, Doom with source that looks like Doom.

Out of the mainstream choices, there are really only 3 versions of Doom that can state that they basically have completed their goals: Vanilla Doom, Chocolate Doom, and PrBoom-Plus. And, PrBoom-Plus has the most advanced editing features of the 3. PrBoom-Plus is the realization of what Boom and MBF were going for. That's makes PrBoom-Plus the definitive best port to add new editing features to. The new features could be of a ZDoom-flavor, a DoomsDay flavor, Vavoom, Edge, Eternity, Legacy, or all of the above, or none of the above. Or it could be left as-is.

My point is that, now, we have a mature, feature-rich, completed port that supports all of the "standard" features - features that can be added to any port. PrBoom-Plus has not inhibited progress. Instead, it provides a fast, efficient, stable platform for any new features to be safely and reliably added.

PrBoom was not the obstacle of progress: Instead, the mentality of sharing was lost. Port authors started refactoring their code bases, to the point that compatibility was no longer feasible. For example, I'd love to add some ZDoom functionality to my port, but ZDoom's code is so different, I wouldn't know where to begin. I guess there were good reasons to refactor like that, but I want my code to be more like vanilla.

So, why do people map for Boom format?

Because the maps will play in many ports.

Because Boom format is powerful.

Because Boom format is extremely stable: A map made 10 years ago will play fine 20 years from now.

Because that allows all of PrBoom-Plus's features to be demonstrated and used.

Share this post

Link to post

But that will quickly pass if you continue using it, once you have gained an understanding all this initial inertia will be gone - and then writing a few lines of script code will definitely go a lot faster than building a conveyor script

I think you're probably right! While it felt more alien to use, the end result did feel neater. It's also so much more powerful, so if I ever did want to do more complex stuff it's a skill that's definitely worth learning.

4 hours ago, Gez said:

I... what? You take a line from an example, and then say there's no examples? Also did you miss all the "conversion from line types" section that gives you how the Doom-format specials are translated?

I didn't spot that section, or I did but didn't understand what I was looking at. But that's not the point. The point was to attempt to share with you the experience of trying to use ACS for the first time. If I made a dumb mistake it's because that's what it's like. I was trying to do it honestly.

3 hours ago, Decay said:

Wow, are you telling me format X is easier because you already knew what you were doing? Shocker!

I didn't know for sure I knew what I was doing, that was what I was interested to find out. :) Turns out you're right: Boom conveyor belts do basically use all the same mapping techniques as normal mapping, so it makes perfect sense why people would by happy to stick to them. I'm glad I tried it out though, I personally feel a bit more educated on the whole subject.