Why Are Secret Exits Hard Coded to Maps 15 and 31?

[Phobus]

That's probably voodoo dolls being moved onto health (or crushed)

[Quasar]

Personally for me BOOM team's largest error was not taking into account any of the pre-existing enhancements made to other variants of the idTech 1 engine in the form of Heretic, Hexen, and Strife, and taking into account the fact that descendent ports might want to add support for those games.

A whole lot of stuff they support could have been added in BOOM without the source code, as it's simple to see how they work from the outside.

[Maes]

Phobus said:

That's probably voodoo dolls being moved onto health (or crushed)

I wonder why such tricks aren't used more in vanilla Doom. Even without conveyor belts, it's possible to have "remote pickups" (by lowering or raising voodoo dolls into pick-up items), or having a "death timer" with a tall crushing ceiling or even lowering a voodoo doll into a floor that then turns into nukage with vanilla floor trickery.

[DuckReconMajor]

Maes said:

(by lowering or raising voodoo dolls into pick-up items)

If you're in the same position as a pick up item, and you are raised up or down, does it pick up?

[Memfis]

I do this a lot in my megawad. There is pepsi machines everywhere and when you press on them you get 5 hp. :)

[Gez]

Maes said:

I wonder why such tricks aren't used more in vanilla Doom.

Voodoo doll tricks don't work so well in multiplayer.

[Maes]

DuckReconMajor said:

If you're in the same position as a pick up item, and you are raised up or down, does it pick up?

More precisely: if you're within pickup radius from an item, if the height difference is too large then it's not picked up (e.g. items on ledges).

However, as the height different diminishes, at some point they ar picked up just fine. That's why sometimes you involuntarily pick stuff that's at the border of elevators as they rise or lower, just moments before you're able to see them.

[Memfis]

Btw you don't even need to move the player or the item. Sometimes moving nearby sectors also does the trick. example wad
(so I guess in voodoo doll scripts with barrels you can heal the player before the explosion to guarantee that he will not die even with 1 hp)

[tempun]

Quasar said:

Personally for me BOOM team's largest error was not taking into account any of the pre-existing enhancements made to other variants of the idTech 1 engine in the form of Heretic, Hexen, and Strife, and taking into account the fact that descendent ports might want to add support for those games.

The proper way IMHO is the Doomsday way, that is, loadable game modules. Although separate executables are OK also. This avoids sprinkling the code with tests if the current game is Heretic or Hexen to account for vital programming errors, and question of how to implement that piece of crap called ACS in Doom, and the like.

[Graf Zahl]

The proper way depends on what you want. If you want a feature-rich engine the Doomsday way is a dead end.

It only works if your main concern is compatibility at all costs and you don't really care about adding new features. Having your code base multiplied 3 or 4 times with only minor differences won't make working with the code any easier.

I guess we see how such engines get used: Play the original levels with enhanced graphics, not much use beyond that.

[Belial]

Maes said:

I wonder why such tricks aren't used more in vanilla Doom.

They aren't? I've seen them plenty of times since my first encounter with a voodoo doll in HR19.

[tempun]

Graf Zahl said:

It only works if your main concern is compatibility at all costs and you don't really care about adding new features. Having your code base multiplied 3 or 4 times with only minor differences won't make working with the code any easier.

inb4 DaniJ coming here and telling how much of the code is shared

[Graf Zahl]

Not enough if you can't use Hexen monsters in Doom... :P

[tempun]

Graf Zahl said:

Not enough if you can't use Hexen monsters in Doom... :P

No loss, IMO...
What features, btw? Graphics enhancement doesn't need features?

[Graf Zahl]

Graphics enhancement is not relevant in this context.

You made a blanket statement that different game modules were always the better approach - and that's something I disagree with - especially if your focus lies somewhere where such an approach might get in the way.

If graphics enhancement is all you are interested in, it might work - but if gameplay and editing features are you clearly do not want to scatter your code base into multiple parts that all need to be maintained.

Which doesn't mean that ZDoom did it all right. Especially in the early days some really bad design decisions were made that still plague the engine to this day

[DaniJ]

Graf Zahl said:

The proper way depends on what you want. If you want a feature-rich engine the Doomsday way is a dead end.

It only works if your main concern is compatibility at all costs and you don't really care about adding new features. Having your code base multiplied 3 or 4 times with only minor differences won't make working with the code any easier.

I guess we see how such engines get used: Play the original levels with enhanced graphics, not much use beyond that.

Abstraction, abstraction, abstraction :p

Of course its quicker to simply shove all the code into one executable with no real attention paid to top down design. Not to mention you can quickly hot wire in new fads when the need arises.

Please do show me all this unnecessarily duplicated code that supposedly lurks in our code base.

[Kira]

Phobus said:

Ahh, but what if some numbnuts writes in "33" for the map to be exited to? You'd then need the game to handle that in some way. There's more to programming these things than you think.

This sort of thing is why I love MAPINFO and think it would have been brilliant in the original doom.

I think it's nonsense. Numbnuts will always provocate stupid bugs with how things are. Like, uh, making a door that doesn't work.

[Graf Zahl]

DaniJ said:

Abstraction, abstraction, abstraction :p

Of course its quicker to simply shove all the code into one executable with no real attention paid to top down design. Not to mention you can quickly hot wire in new fads when the need arises.

Please do show me all this unnecessarily duplicated code that supposedly lurks in our code base.

You and your design philosophy...

I think abstraction for the sake of abstraction is nonsense, especially if you have to deal with a mess of source as Doom originally was.

Also, most of the game specific code in ZDoom is just exported action functions or native classes so that DECORATE can access them so at no point do they get in the way of any design goal.

The rest...
... well, some functions have become a bit disorganized but on the other side there's no feature that only works in one of the supported games - and that's what counts for me much, much more than some abstract design goals.

[DaniJ]

Why are you so intent on championing your (supposed lack of) design philosophy while decrying ours?

What makes you think its abstraction for the sake of it? When was the last time you actually looked at the Doomsday code base, six or more years ago maybe?

[Graf Zahl]

A year ago - and well - the code was a bit too abstract for my taste... :P

Sorry, but on this subject we'll never agree. In my opinion it's way overengineered and I just fail to see what good may come out of it.

I'm more a proponent of a direct approach to a problem and in 20 years of professional software development have always fared well by doing so.

On the other hand, I had to deal with lots of third party developed code that follow your design philosophy of abstraction. This was always the stuff that was hard to finalize into a releasable product. No idea if it was because the developers were bad or that the approach itself did not work for the projects they did.

[DaniJ]

Typically I also approach an unsolved problem with a direct approach. However, once understood (and given good reason to do so), I'll happily tear it up and integrate that understanding into the fabric of the architecture itself

Sometimes an abstraction may well be unnecessary from an engineerial perspective but that fact doesn't automatically equate as needless complication.

In Doomsday's case I readily acknowledge that it has a somewhat abstract outward appearance, although this is not without good reason (for an insight, take a look at our roadmap some time).

You say that our approach is a dead end and not conducive to maintaining a regular release cycle; need I remind you of ZDoom's last stable release date?

I agree we are unlikely to agree on a design front but how about we try not to personalize that disagreement.

[Graf Zahl]

DaniJ said:

You say that our approach is a dead end and not conducive to maintaining a regular release cycle; need I remind you of ZDoom's last stable release date?

That has nothing to do with development style but with personal issues that by now are irritating the entire ZDoom community (that is the parts that haven't given up on 'official'. Most don't care anymore and just use the SVN builds because those are up to date.)

What can you do if the person to call the shots just doesn't want to do a release? We've been dealing with this indecisiveness since 2005 and it just won't get better. :(

I guess having a roadmap to follow would only make things worse here.

[DaniJ]

(Forgive my lack of any understanding of the actual issue). If a stable release is being prevented merely because of long standing inter-personal issues among the development team, then perhaps an ultimatum is due for the sake of the project's future. Falling into a seemingly never-ending beta/unstable/whatever development non-cycle is never good, but for personal reasons on an open source hobby project??

[Graf Zahl]

DaniJ said:

(Forgive my lack of any understanding of the actual issue). If a stable release is being prevented merely because of long standing inter-personal issues among the development team, then perhaps an ultimatum is due for the sake of the project's future.

No, that's not it.

The release is prevented because Randy just won't do it.
It's not the first time that he waited - and waited - and waited.

DaniJ said:

Falling into a seemingly never-ending beta/unstable/whatever development non-cycle is never good

On that I fully agree. There have been several major new features that alone would have been worth a new release, just the one person who's the only one who can do it - just didn't.

The main motivation was apparently one particular critical bug - but that has been fixed months ago and presumably the new release was due when the bugs forum was cleaned sufficiently. But guess what: Development has slowed down and the bugs forum is filling up again.

But well, it's not my call and since there's the SVN builds the 'official' releases have somewhat devolved into a joke most ZDoomers don't care about anymore.

BTW, GZDoom *has* updated after the newly added features of 2010 - but after that not much has happened that justified another one.

[DaniJ]

I see. All I can really suggest is a pragmatic appeal; there will always be bugs (critical or otherwise) and that a stable release does not mean bug-free. (Though you've likely already been down that road).

From your perspective all you can really do is to continue releasing stable builds of GZDoom, as you have been. It would be a great shame to see ZDoom slowly fade into obscurity, but at least the users won't be left with no alternative.

[Siggi]

ZDoom's development situation seems very sad to me. It's like the project has no direction, no objective and no mile stones.
In a way, it's like there's only feature creep and no progress.

I've often wondered if ZDoom 2 should just be feature frozen, and then a ZDoom 3 announced where the first stage of development involved removing deprecated and redundant features, and coming up with a solid plan as to what ZDoom 3's future should be.

Of course, I have nothing to do with ZDoom's development, and the situation could be significantly less depressing than what I think it is.

[Gez]

ZDoom's development plan has always been "Randy works on what he wants to do when he wants to do it, until he changes his mind". In addition, other contributors do their own things.

I don't think it could be changed to something else.

And sure, the result is a lot of feature-creeping, but that is precisely what made ZDoom a popular modding platform in the Doom community.

[scalliano]

I wouldn't have it any other way, frankly.

I was originally a Doomsday fan, until I started modding for myself. I found Doonsday's XG system completely incomprehensible, and tutorials were a bit thin on the ground. Otherwise ToP may have had lens flares :P

[Blastfrog]

Siggi said:

ZDoom's development situation seems very sad to me. It's like the project has no direction, no objective and no mile stones.
In a way, it's like there's only feature creep and no progress.

That, and certain people refused to commit already written code to the official SVN repository just because the features weren't to their liking, despite the modding flexibility it would introduce, leading to a community branch, ToB GZDoom (which is really out of date now). Nash is making his own personal build for his Zombie mod, using more up to date GZDoom code, along with ToB features and some of his own, but he tells me that he's grown tired of modding for the Doom engine for anything advanced, as it's just far too limited of an engine. Can't say I blame him, I'm starting to feel the same way, and have started to learn how to use the UDK instead.

[DuckReconMajor]

I feel like a dumbass for using the release version of ZDoom now.