Plutonia 2 bugs ?

Plutonia 2 is a conventionnal oldschool megawad, thus it is supposed to work with what it's intended to work, even if we are in 2008, end of story.

Map 24 - The blue key door is upper unpegged on both sides.

kristus said:

Well, that's not true. Dosbox works great.

If by "works great", you mean "doesn't have any sound on a lot of systems" then yeah, sure :P.

Sound always worked for me with it. In every version on every setup and in every game I've tried it with.

K!r4 said:

Plutonia 2 is a conventionnal oldschool megawad, thus it is supposed to work with what it's intended to work, even if we are in 2008, end of story.

And it does work with what it's intended to work with. Including extra lumps that improve the support for it in the engines that 99.9% of people are going to play it in anyway doesn't affect a wad's Doom2.exe support in any way.

Graf Zahl said:

I hope you are not serious!

I'm absolutely serious and I never play classic wad in unclassic port like zdoom or gzdoom etc.

Lost Heretic said:

I'm absolutely serious and I never play classic wad in unclassic port like zdoom or gzdoom etc.

Okay, so you shouldn't mind having lumps in the wad for other ports, that have no effect whatsoever on your classic Dooming experience. I don't understand what you're arguing here. You seem to be complaining about a vanilla-compatible wad because it makes itself sourceport-friendly as well?

esselfortium said:

vanilla-compatible wad

At least, it's not doom95 friendly, because of strange music names. Are there serious reasons for renaming?

Lost Heretic said:

I'm absolutely serious and I never play classic wad in unclassic port like zdoom or gzdoom etc.

Well, I do. And I certainly appreciate that the makers of this WAD are not as narrowminded as you (and unfortunately a few others as well.)


Concerning Dosbox, yes it works to a degree. But it's not just the DOS limitation that's a problem. What far to many people seem to forget is that many modern monitors are atrociously bad at low resolutions. Anything below 800x600 looks like utter shit on mine and I don't like playing in a window.

kristus said:

There's this soul sphere in Map03 that can only be picked up by Player 2 in coop. But it's very visible in SP. I'm don't know the reason for doing this. But it sure was fun running around the map endlessly trying to figure out how to get it. Also it makes it impossible to get 100/100/100.

There is a possibility of Strafe50 jump to the brown rock in front of the Soul Sphere and then only small AV jump is needed to get there ... so it's kind of supersecret ... but perhaps I will remake it that you will need to do only that S50 jump.

Graf Zahl said:

and I don't like playing in a window.

Please, add something like:

  Uint8 state;

  switch (Event->type)
  {
    case SDL_ACTIVEEVENT:
      state = SDL_GetAppState();
      window_focused = (state & SDL_APPINPUTFOCUS) && (state & SDL_APPACTIVE);
      if (!window_focused) {
        // e6y: Restoring of startup gamma if window loses focus
        gld_SetGammaRamp(-1);
      } else {
        gld_SetGammaRamp(useglgamma);
      }

Lost Heretic said:

I'm absolutely serious and I never play classic wad in unclassic port like zdoom or gzdoom etc.

Try PrBoom instead, or Chocolate-Doom.
You forget non-Windows users, what can I do with a Windows executable? Nearly nothing when it won’t be a pain to let all this doomer-friendly.

Lost Heretic said:

It's should be good, because pl2.wad it's a vanilla wad, and should be clean from lumps, which are unsupported in doom2 format. Thanks for understanding.

This just doesn't make sense. Instead of having one file that can be played with any compatible engine, you'd have three different files (two wads, one exe) and only one engine choice?

Lost Heretic said:

I'm absolutely serious and I never play classic wad in unclassic port like zdoom or gzdoom etc.

Does the presence of lumps that are ignored by the engine prevents you from doing so?

The presence of a MAPINFO lump in pl2.wad doesn't break anything for the vanilla engine, it's merely ignored. But for people who are not like you (they do exist, you know, in fact they're probably the majority of players nowadays) it means that it behaves correctly when using ZDoom or another port that is compatible with ZDoom-style MAPINFO lumps (Vavoom comes to mind, and the next version of Doomsday as well from what DaniJ said).

The irony here is that the purpose of that MAPINFO lump is to make sure the gameplay will be as classic as possible in ZDoom and others, disabling things like jumping and crouching that would otherwise be possible in your "purist" approach to wad-building.

Since a couple of text lumps are not going to increase the wad size by any relevant amount and since the game doesn't suffer from their presence even if the engine used doesn't support these lumps, there is absolutely no reason that makes sense behind removing them.

map21 (gzdoom): under one of the bridges, you can fall down into a "deepwater pit" at the two ends, and get stuck (highlighed in screenshot):

http://img134.imageshack.us/img134/6164/screenshotdoom200901042vr6.png

also:

entryway said to Graf Zahl:

Please, add something like: (...code..) in GZDoom

seconded, gl screensavers and the like mess up the gamma, if gzdoom is left unattended in a window

This area looks like it's prone to node building issues. Making the two invisible blocks 2 map units narrower should fix it.

entryway said:
At least, it's not doom95 friendly, because of strange music names. Are there serious reasons for renaming?

Actually, compared to Alien Vendetta it is Doom95 friendly, as AV crashes with Doom95 due to the included MIDIs. Yeah, we could have bothered to pass all the MIDIs through mid2mus, but the main objective was Doom2 compatibility, and mid2mus may have odd effects on the files. The renaming also allows you to see the initials of each author on the lumps, instead of the names of tracks from DOOM II, as credit for their work on the new music. Lastly, you can use original Plutonia tracks from different levels (such as in 23) without having to add the lump back into the WAD.

It also helped catch a PrBoom bug :p

Gez said:

This just doesn't make sense. Instead of having one file that can be played with any compatible engine, you'd have three different files (two wads, one exe) and only one engine choice?

Plus, including a modified version of the original .exe is actually illegal. That's one of the reasons .deh patches were invented.

Graf Zahl said:

Well, I do. And I certainly appreciate that the makers of this WAD are not as narrowminded as you (and unfortunately a few others as well.)


Concerning Dosbox, yes it works to a degree. But it's not just the DOS limitation that's a problem. What far to many people seem to forget is that many modern monitors are atrociously bad at low resolutions. Anything below 800x600 looks like utter shit on mine and I don't like playing in a window.

I run Dosbox at 1680x1050 and let dosbox itself (rather than my monitor) do the scaling. Looks fine then.

I don't see any harm in a MAPINFO lump being in the wad, since it in no way shape or form harms vanilla compatibility (and only serves to improve the usability on engines such as G/ZDoom.)

I'd like to see a PL2.EXE produced in the same fashion that an AV.EXE was for Alien Vendetta.

Question, Does having the DEHACKED lump included in the wad itself do any harm to playing on vanilla? (I know vanilla won't do anything with that Dehacked, since it's not a feature it supports).

@Mike.Reiner: No, the DEHACKED lump should be ignored like every other lump it doesn't recognize.

esselfortium said:

@Mike.Reiner: No, the DEHACKED lump should be ignored like every other lump it doesn't recognize.

Ah... well, in that case, why isn't the DEHACKED just included inside the wad itself? The MAPINFO then could be used solely for turning off things like Jump and making sure the compatibility flags are set properly.

I think there actually is a DEHACKED lump in the wad for convenience, but it's also included as the separate patch both so that it can be used with vanilla Dehacked as well as for ports that don't support reading it from a lump.

esselfortium said:

I think there actually is a DEHACKED lump in the wad for convenience, but it's also included as the separate patch both so that it can be used with vanilla Dehacked as well as for ports that don't support reading it from a lump.

Yep, just checked. You're right.

How does one go about creating a hypothetical PL2.EXE with the dehacked applied to it?

Edit: never mind, I got it. Used Cyber Dreams as a way to figure it out.

found some more on map23 (gzdoom):
- the lowered mancubi at ~ x:1090 y:610 in the first secret, are visible from the outside and can attack the player
- the blue/yellow door can only be opened twice from the blue side (altough this requires glitching by closing it from the yellow side)
- the nearby teleporter at x:480 y:1820 seems to be missing the teleport specials on the sides

Everything in-game is playable on Chocolate-Doom, but initial demo after title screen make game to quit, why?

GBT3 said:

Everything in-game is playable on Chocolate-Doom

Try map23. From start to the left.

MAP30, lindefs 226 & 1017 should be flipped, the player can easily get past them without dying as intented

esselfortium said:

And it does work with what it's intended to work with. Including extra lumps that improve the support for it in the engines that 99.9% of people are going to play it in anyway doesn't affect a wad's Doom2.exe support in any way.

Well, it's fair.

just found something that looks like another node building issue on map25 while playing in gzdoom:
there were two imps and a HK stuck below floor level, near the bridge with fake 3dmidtex, they are visible from the chaingunners' "fire-nest"

http://img510.imageshack.us/img510/4051/screenshotdoom200901051hq4.png

(the imps were be killed by exploding rockets on the floor above them)

If that's what I think it is it's the result of using an old node builder. Some older versions of BSP contain a bug that produces incorrect nodes. It was never noticed with Doom.exe due to an imprecision in some code that calculates on which side of a line a point is - but any port that has optimized or fixed this code may have problems with it.

And apparently this WAD's nodes were built with BSP - which I only can recommend to forget that it ever existed. Zennode and ZDBSP create much better nodes that work with all ports.

As far as I know maybe one level was built with BSP because it offered some advantage there (got rid of a HOM or something). For most, I think, ZenNode was used. Vince did the final builds, so he should know.

Lost Heretic said:
maybe will be better if you remove [...] demo4 from wad,

I missed this tidbit.

If you remove the fourth demo the Final DOOM executable will abort with an error after the third demo, like plain Plutonia does, because it demands four demos. This is a bug that comes from the engine's capability to run The Ultimate DOOM without somehow addressing that DOOM II games should run only three demos.

The fourth demo is there expressly for "vanilla" and not anything else. The MAPINFO is there mainly because ZDoom, which some people may use (at least esselfartium seems to think), has broken DeHackEd support: it can't read changed music names.