GZDoom/MBF (wip), based on ZDoom r1817 and GZDoom r450

[Gez]

Okay, the experimental and community builds have been dormant for a little while so I figured I'd share the current state of my custom build, which contains a lot of stuff.

What is in it:
- Other experimental features which already have their own threads
- A lot of DeHackEd-related code to increase compatibility with MBF
- A tiny amount of code to increase compatibility with Vavoom

Here are my notes in the same style as rh-log (read from the bottom up):

- Added compatibility option to let friendly monsters pass through lines that
block monsters. MBF lets them do so, and you need go no farther than MAP01
to understand why it can be a good idea.
- Tried to load some Vavoom mods for testing modified Sector_SetContents
handling. Added support for Vavoom skyboxes and a couple of aliases in
MAPINFO for compatibility. Tweaked resourcefile a bit as well. Spent time
trying to understand why all the textures are rotated 180° instead of testing
the handling of Sector_SetContents... But it seems to work correctly anyway.
- Modified the code for handling Sector_SetContents to reflect the Vavoom wiki,
which showed this was changed in August 2008. (Vavoom's SVN history shows
actually that it was in October 2006, with r1783. Not sure why a page created
in June 2008 would have been so with obsolete content.)
- Added SMMU's NailBomb as two additional parameters for A_Explode. No code
was taken from SMMU or its successors, it was only based on documentation.
- Restored A_Turn as I couldn't successfully create on the fly the
"member variable angle + constant parameter" expression needed to fully
aliase it to A_SetAngle, and A_LineEffect because it's too soon for xlat.
- Added a renaming mechanism to dehacked, so A_Spawn is interpreted as
A_SpawnItem, and so on. This allowed to eliminate all "new" codepointers!
- Added remaining MBF functions: A_Spawn, A_Turn, A_Face, A_Scratch, etc.
- Fixed various problems in dehacked parameter code. That part is full of
traps. Moved the function to be run at the end of the dehacked loop, so as
to be sure all the states with the relevant code pointers have had their
misc1 and misc2 set. This required a new array to temporarily store them.
- Added hrange and vrange parameters to A_Mushroom, replacing the misc1 and
misc2 values. Created a function to interpret such MBF dehacked parameters
correctly and transform them into normal parameters.
- Added "param" console command to debug ZDoom's codepointer parameters.
- Added compatibility option for corpses being crushed into gibs, instead of
being replaced by gibs. This lets arch-viles resurrect gibs. Added hidden
compatibility flag for ghost monsters, and listed all levels that make use
of it in compatibility.txt.
- Updated custom bouncetypes to Randy's bounceflags. I had made sorta the same
thing, but not in the exact same way.
- Ported custom code from ZDoom to GZDoom.
- Fixed DeHackEd incompatibility with MUSHROOM.DEH, and submitted patch.
- Added as compatibility options the MBF pseudo-torque effect and the
possibility to have monsters affected by terrain effects such as pushers and
pullers. MBFEDIT!.WAD can now work at 100%.
- Changed gravity computation from P_ZMovement() into a macro. With MBF
bouncers, it is used in more places, so it's simpler that way. Tweaked
behavior of MBF-specific parts of the bouncing code so that DOGFLY.DEH works.
- Changed Graf's hack of Misc1 to signal a state was dehacked by one that
affects the state's defineflags. Implemented MBF-type params for A_Mushroom.
- Tweaked detection and treatment of MBF grenades by changing their rockettrail
to a grenadetrail and giving them the NOBLOOD flag. It was odd to see them
leaving blood decals, and leaving gibs if they exploded under a closed door.
- Fixed a dehacked bug when playing Artica: one of the items was dehacked to
have only the TRANSLUCENT flag. Since ZDoom didn't treat translucency as
being one of the flags from the first array, that meant the first array was
left untouched, and therefore did not clear the SOLID flag. Solved the
problem by reinstating the TRANSLUCENT flag at its proper place in DEHSUPP.
- Added stealth/friend hack so that the conflicting flag is interpreted
correctly. Fortunately, ZDoom blocked the upper bits so as to force use of
the mnemonics, allowing to be 100% sure when a monster is stealthy and when
it is friendly. Removed upper bit block for MBF compatibility.
- Added "info" console command to list an actor's flags and various other
variables that linetarget did not tell. Tweaked P_AimLineAttack() to let it
optionally check even non-shootable actors.
- Enhanced DeHackEd so that it could translate MBF's three new flags.
- Added MBF bounce types to the ZDoom bounce system, changed bouncetype in a
bitflag system. Added checks for bouncetype & BOUNCE_MBF at various places
where MBF has checks for flags & MF_BOUNCES.
- Implemented MBF "doom beta" codepointers, states and classes. Updated
DEHSUPP accordingly.
- Added A_SetVar and an array of ten variables that are usable in DECORATE.
This allows some rudimentary forms of scripting much more efficiently than
with inventory tokens, and no risk of collision with other stuff, contrarily
to A_SetArg.
- Added A_Log and A_PrintBold to DECORATE. Great for testing and debugging
actors.
- vcproject and svnrevision.h nitpicks.

Other features, like the ScriptedEffect powerups, the activationtype property and more predate this log, and they have their own threads anyway. Oh, and as always, there's a patch in the archive.

[Graf Zahl]

Your experimental builds contain some interesting features. However, if you only post them here they will most likely get lost Why don't you do some code submissions? The whole thing as it is is not of much use because it is littered with some things that won't become official. I did try to extract some stuff but I stopped at the most basic level.

[Gez]

Why don't you do some code submissions? The whole thing as it is is not of much use because it is littered with some things that won't become official.

Precisely for this reason. I'd have to know what you want and what you don't want to make the code submission patches accordingly.

[Graf Zahl]

I'm most interested in the MBF stuff. A lot of that has been on my wishlist for a long time but since the sources are so different I never got to do it.

I already added a few things in r1818 but since I have to extract it very carefully it's not an easy task.

I'm trying to do a bit more right now. A few things need to be cleaning up though. In particular I don't like how you hijacked A_Explode for the nail bomb function.

BTW, the crushing to gibs feature does not work. The way you try to get AActor's original state won't do what you intend

Other things that might cause problems are how you added fixed type support to the expression evaluator. This is something I intentionally skipped in anticipation of a proper scripting language where it would end up inconvenient baggage.

[Gez]

I'm trying to do a bit more right now. A few things need to be cleaning up though. In particular I don't like how you hijacked A_Explode for the nail bomb function.

A_NailBomb does the exact same thing as A_Explode, plus 30 line attacks in a circle, according to documentation. Making it an independent function would have meant either copying all the params from A_Explode as well, or make the radius damage effect not parameterizable.

BTW, the crushing to gibs feature does not work. The way you try to get AActor's original state won't do what you intend

Indeed it doesn't. Weird, I remember it working in the tests I had run at that time.

Actually the state thing does work. The error is in the boolean condition when I added the player exception after discovering why ZDoom did things this way to begin with. That is to say, with this fixed code, it works.

Code: Select all

		if ((state == AActor::FindState(NAME_Crush))	// Only use the default crushed state if:
			&& ((this->flags & MF_NOBLOOD)				// 1. the monster bleeeds,
			|| !(i_compatflags & COMPATF_CORPSEGIBS)	// 2. the compat setting is on,
			|| (sprites[state->sprite].numframes == 0)	// 3. the sprite is available,
			|| (this->player)))							// 4. and the thing isn't a player.

Other things that might cause problems are how you added fixed type support to the expression evaluator.

I couldn't find a way to pass that value correctly otherwise. Using a float resulted in something always rounded down to 0... It's just a hack for a dehacked feature. Given the different constructor needed to obtain fixed constants, I don't think this might affect DECORATE; a different workaround could be found once a different system is in place.

[Graf Zahl]

It will. All the expression evaluation code will go poof once Randy starts converting it to the VM.

Regarding FindState, all

Code: Select all

AActor::FindState(NAME_Crush)

does is to call the super class's function. It doesn't alter anything about the calling actor (which it can't considering that the runtime type is dynamic.) All this changes is the class in which it looks for the function. And FindState has not been overloaded so you'll call the same one no matter what.

For stuff like this it's a bad idea to use the same state label. Make it like the GenericFreezeDeath state and use a different label that doesn't interfere with normal game operation.

Furthermore, if you change this you will also have to alter the Gibs and RealGibs actors so that all 3 use the same state - and that Dehacked properly maps this state.

[Nash]

- Added A_SetVar and an array of ten variables that are usable in DECORATE.
This allows some rudimentary forms of scripting much more efficiently than
with inventory tokens, and no risk of collision with other stuff, contrarily
to A_SetArg.

I would love to see this integrated into ZDoom and GZDoom officially.

[Rachael]

I would love to see this integrated into ZDoom and GZDoom officially.

Me too, but you know what will happen with that...

"WFDS"

[baghead]

GezDoom huh? This will definitely be interesting.

Hey, if you need a logo for it, just let me know.

*ducks*

[Rachael]

I like logos.

[Gez]

- Added A_SetVar and an array of ten variables that are usable in DECORATE.
This allows some rudimentary forms of scripting much more efficiently than
with inventory tokens, and no risk of collision with other stuff, contrarily
to A_SetArg.

I would love to see this integrated into ZDoom and GZDoom officially.

There it is, as A_SetUserVar.

[Graf Zahl]

It was also extended to be accessible by ACS, too, which should make it really useful.

[Gez]

How about the GZDoom side of things? The dynlight defs for the beta plasmaballs have not been ported over.