PrBoom-Plus, ver. 2.5.1.4

[printz]

It seems that (this) PrBoom-Plus doesn't really support MBF Dehacked files!

I have another version installed on a Mac, 2.5.0.3, and it didn't support the BOUNCES flag on grenades! Now it works.

Neither this 2.5.0.6, nor 2.5.0.3, support the FRIEND thing flag in this situation: I have a player missile (BFG shot) set as a FRIEND. At death, it uses the "Spawn" code pointer to create a monster. That monster should inherit the FRIEND flag from the projectile and be an ally. But here in PrBoom, it doesn't happen.

Another projectile also set as FRIEND Spawns objects as it moves by. Each such object is an individual invisible friendly Chaser that has gravity. When a RandomJump in its walking cycle decides so, it will spawn a static flame and be removed. The problem with the flames is that in 2.5.0.6, the gravity of their spawners isn't there, resulting in some airborne flames! (it appears like both the walkers and the static flames lack gravity)

Is there a chance MBF mod support will be added, considering that PrBoom already has implemented a MBF compatibility mode?

[entryway]

Post your bex which works with MBF and does not work with prboom.

[printz]

Here it is: http://www.speedyshare.com/files/22653156/testsend.bex It's for Doom 1. Some things may not work out of the box, because I didn't include the graphics wad. Try the plasma gun and the BFG9000 respectively.

The plasma gun equivalent actually seems to work correctly. It was just that the graphics were displaced vertically upwards, resulting in a levitation illusion. The imported flame graphics were surrounded by empty space below and around.

The BFG9000 -- see how the big ball of death attacks you instead of enemies.

Slot 5 is the grenade launcher and fires TOUCHY+BOUNCES (not PROJECTILE) objects. Seems to work...

I wasn't able to even run PrBoom, after I set it to 1280x1024 resolution and 5:4 ratio -- it quits because of Signal 11 -- so I used GlBoom instead, without configuring it.

The shotgun will crash both ports (PrBoom, MBF), because uses inexistent SHT2 graphics (from the PWAD). Otherwise it works.

Does PrBoom read and recognize OPTIONS (setting-changing) lumps?

[myk]

printz said:
Does PrBoom read and recognize OPTIONS (setting-changing) lumps?

No.

[entryway]

printz said:

Neither this 2.5.0.6, nor 2.5.0.3, support the FRIEND thing flag in this situation: I have a player missile (BFG shot) set as a FRIEND. At death, it uses the "Spawn" code pointer to create a monster. That monster should inherit the FRIEND flag from the projectile and be an ally. But here in PrBoom, it doesn't happen.

Ask cph why he commented that code

void A_Spawn(mobj_t *mo)
{
  if (mo->state->misc1)
  {
    /* mobj_t *newmobj = */
    P_SpawnMobj(mo->x, mo->y, (mo->state->misc2 << FRACBITS) + mo->z,
      mo->state->misc1 - 1);
    /* CPhipps - no friendlyness (yet)
    newmobj->flags = (newmobj->flags & ~MF_FRIEND) | (mo->flags & MF_FRIEND);
    */
  }
}

Anybody know?

[printz]

myk said:

No.

That ain't so good, when you want to enforce gameplay and monster AI rules into your WAD. Some features may vary dramatically if the user hasn't got the compatibility settings intended by the developer, such as friendly monsters being unresponsive (unless someone's hurt), or no torque puzzles.

[entryway]

printz said:

I have a player missile (BFG shot) set as a FRIEND. At death, it uses the "Spawn" code pointer to create a monster. That monster should inherit the FRIEND flag from the projectile and be an ally. But here in PrBoom, it doesn't happen.

Fixed, but only for mbf compatibility (11), because prboom did not inherit friendlyness from first versions

[printz]

Thanks for the fix!

Now to see why OPTIONS isn't supported...

[RjY]

entryway said:

Ask cph why he commented that code
[...]
Anybody know?

I doubt it was intentionally disabled. I'll make some guesses.

In 1998 or whenever, cph took Boom and ported it to Linux, as LxDoom. Several months later MBF came out and he decided to merge MBF features into LxDoom instead of starting again. When you do something like this, you start with the "easy" parts and comment out things that break the build. (You can't do everything at once.) Merging friendly monster AI and dealing with all the godawful Killough obfuscations therein would be harder than just copypasting a few functions added to the end of a file.

So he copied A_Spawn and the other functions at the end of p_enemy.c and simply commented out the part about friendly monsters because the rest of LxDoom didn't support them yet. But, some time later, when he'd done friendly monsters, he forgot to go back and uncomment those lines from one obscure function. An oversight.

Then, no-one noticed before now, because nothing used A_Spawn. Consider, in order to use it, you'd have to be making a wad, advanced enough to be making a Dehacked patch for it. You'd have to know about MBF dehacked extensions, which had only just been released to the world, and have to knowingly use them in your patch, knowing that you'd be limiting your wad to one engine. It's not surprising that no wads circa 2000 used them (bar MBFEDIT!.WAD of course!)

[printz]

RjY said:

knowing that you'd be limiting your wad to one engine. It's not surprising that no wads circa 2000 used them (bar MBFEDIT!.WAD of course!)

Now it's not "one engine" though; Eternity and likely PrBoom (maybe also that CDoom) work too. I'm doing it on MBF features because ZDoom and Eternity offer too much freedom, but I still want to be able to mod the monsters and guns in a substantial manner, using Spawn, RandomJump and such. It's also personal preference.

PrBoom is a particularly popular port, and it even supports demo recording. Even if ZDoom wouldn't support my wad, I'd still count on the PrBoom fanbase, and even the possibility for someone to circulate demos of it, which isn't the case with ZDoom or any port (such as Eternity) whose major point is adding features and losing demo support.

EDIT: only now I saw there's TWO humongous PrBoom threads. Probably I should have posted my problems there not here, but eh.

[VinceDSS]

just a quick question, how hard would it be to implement decorate in prboom ? even in a more limited version than zdoom's

I am asking that because dehacked is so darn limited and forces you eliminate a lot of frames/items to add your own monsters...

And yet I do not want to use zdoom because I do not like : the mouse feel, ACS scripting, jumping and a bunch of other things

EDIT : I tried the skybox thing with the "test" prboom+ that goes with it and it doesnt show anything for me, only a large AASHITTY as sky texture. I also tried with compat 11 , still the same problem.

[Graf Zahl]

VinceDSS said:

just a quick question, how hard would it be to implement decorate in prboom ? even in a more limited version than zdoom's

It's a lot of groundwork up front because DECORATE is fully integrated into ZDoom's class hierarchy. Much of that needs to be simulated if you want to have class inheritance.

If you can do without that and restrict yourself to a limited subset of code pointers (namely the ones for Dehacked minus those which use the misc fields) it'd only require dynamic expansion of the mobjinfo table.

But it's still a lot of code that needs to be ported. ZDoom's DECORATE parser without the new code pointers is 270kb of source code.

[Gez]

VinceDSS said:

And yet I do not want to use zdoom because I do not like : the mouse feel, ACS scripting, jumping and a bunch of other things.

Eh, ACS is a question of levels, not of port -- you don't have to play scripted levels after all. Jumping is not bound to a key by default. And again, you don't have to play levels which require it. The mouse feel is a point I can sympathize with, though for me it's the reverse.

You could try Eternity. Well, it does have scripting, but nobody is using it. It also does have jumping, but again, you don't have to bind a key to it. And EDF is a powerful content definition language, which can be used to create new actors, modify existing ones, or even simply create a ton of new frames for a DEHACKED patch...

[entryway]

VinceDSS said:

EDIT : I tried the skybox thing with the "test" prboom+ that goes with it and it doesnt show anything for me, only a large AASHITTY as sky texture. I also tried with compat 11 , still the same problem.

Probably you have something wrong with your cfg, gl_skymode != 0 for example, or gl_texture_internal_hires != 1, or you tried in software mode, because it is GL feature.

[VinceDSS]

Oh I see, I tried in software mode, that explains it (I never try in GL).
Do you have plans to port it to software ?

Gez said:

Eh, ACS is a question of levels, not of port -- you don't have to play scripted levels after all. Jumping is not bound to a key by default. And again, you don't have to play levels which require it. The mouse feel is a point I can sympathize with, though for me it's the reverse.

You could try Eternity. Well, it does have scripting, but nobody is using it. It also does have jumping, but again, you don't have to bind a key to it. And EDF is a powerful content definition language, which can be used to create new actors, modify existing ones, or even simply create a ton of new frames for a DEHACKED patch...

That's a good idea, but unfortunately Eternity has nowhere near the same user base as zdoom , prboom and their clones. And since I want to aim my project at a larger user base, decorate sounds like a better idea.
The other, even better idea would be to extend dehacked to add your own frames, sounds, weapons, items and code pointers. That would make prboom so much more modable and yet remain old school.

[Gez]

VinceDSS said:

The other, even better idea would be to extend dehacked to add your own frames, sounds, weapons, items and code pointers. That would make prboom so much more modable and yet remain old school.

It's been done before. For example, by a rather obscure port called Fusion. It did not have much of a resounding success... (Heck, MBF has many additional frames for DeHackEd stuff, what with the dogs and beta items, but they are seldom used.)

[Quasar]

VinceDSS said:

...and code pointers...

That one's a very tall order indeed. For that you need a full Turing-complete scripting language with hooks into most of the native game engine functionality.

EE is planning to do this eventually as a system called "Aeon," which is likely to be based off of ECMAScript, though this isn't yet decided finally.

[entryway]

VinceDSS said:

Oh I see, I tried in software mode, that explains it (I never try in GL).
Do you have plans to port it to software ?

No. Never. It's GLDEFS stuff.

[VinceDSS]

Too bad :/ then I have no use for it, as it would limit a wad to glboom and gzdoom only.

[entryway]

VinceDSS said:

Too bad :/ then I have no use for it, as it would limit a wad to glboom and gzdoom only.

Generally, software mode does not need it, because it has no (proper) mlook. GLDEFS is just additional ability to make GL better in some situations. It does not limit a wad with anything. Except some ports which prefer to fail instead of skipping if they can't understand something in GLDEFS lump (risen3d as example)

[Never_Again]

[VinceDSS]

yes, we used MAPINFO in plutonia2 for disabling jump and add map names. I will most likely use it again.

To sum it up, besides Decorate that is limited to the zDoom clones, Dehacked and Boom are the only modding tools supported across the board?
That's a little sad considering how limited Dehacked is nowadays.

Would a concerted effort between ports help bring that further for the sake of the game ?

[entryway]

VinceDSS said:

yes, we used MAPINFO in plutonia2 for ... and add map names.

Bad idea to do something with port specific method if it can be done in universal way.

VinceDSS said:

That's a little sad considering how limited Dehacked is nowadays

Dehacked itself is ok, at least in terms of compatible ports, but dehacked tool could be better.

VinceDSS said:

Would a concerted effort between ports help bring that further for the sake of the game ?

Unlimited number of free states would be cool and that's all I need.

[VinceDSS]

Other important points : possibility add your own sprites, sounds and items w/o having to delete other ones.

As Quasar said, custom code pointers seem much harder to implement. Although there are a bunch of existing ones from hexen, heretic and strife which combined would offer a great variety for prboom and other ports.

A bit of cooperation between port makers would make the modders life a bit easier :) and probably the port coders's as well.

[entryway]

VinceDSS said:

Other important points : possibility add your own sprites, sounds and items(including monsters).

You do not need additional sprites at all, because you can use subframes of existing. That's enough.

A_PlaySound can play any sound, but number of sounds also could be unlimited.

VinceDSS said:

Although there are a bunch of existing ones from hexen/heretic and strife which combined would offer a great variety for prboom

Use MBF code-pointers instead. They are powerful.

VinceDSS said:

A bit of cooperation between port makers would make the modders life a bit easier :) and probably the port coders's as well.

Dehacked == cooperation between port makers

[VinceDSS]

is there an editor for MBF's dehacked format?

Or do I have to do it by hand with a text editor ?

entryway said:
Dehacked == cooperation between port makers [/B]

I agree, dehacked is part of almost every port out here.
Getting the community to work together to modify it would be a great achievement :)

But at the moment it hasn't changed since MBF has been out.

entryway said:

You do not need additional sprites at all, because you can use subframes of existing. That's enough.

I know about this, It is just that it gets very messy to have different sprites with the same subname.

[entryway]

VinceDSS said:

is there an editor for MBF's dehacked format?

Or do I have to do it by hand with a text editor ?

In any case, lack of proper editor is not a reason to support DECORATE/EDF/XYZ in compatible ports. Found a programmer and improve dehacked tool.

VinceDSS said:

I know about this, It is just that it gets very messy to have different sprites with the same subname.

But you do not need to force all ports to support your cool stuff just because existing stuff is hard to edit and can't be done with notepad.

[VinceDSS]

Whacked is a good start but it can be improved greatly.

[entryway]

VinceDSS said:

Getting the community to work together to modify it would be a great achievement :)

Try to map better instead :) It's Doom!

[VinceDSS]

mapping and item/monster editing are two completely different things to me.

I want to make doom maps, not Serious Sam / modern games wannabes :)
There are much much better and modern engines to do such things without losing your time.