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

Discussion about the experimental SVN builds

Moderators: Enjay, Dev Builds Team

Locked
User avatar
Gez
Developer
Developer
Posts: 1392
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Mon Sep 14, 2009 0:00

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.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

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

Post by Graf Zahl » Mon Sep 14, 2009 7:12

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.

User avatar
Gez
Developer
Developer
Posts: 1392
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Mon Sep 14, 2009 10:33

Graf Zahl wrote: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.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

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

Post by Graf Zahl » Mon Sep 14, 2009 10:49

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.

User avatar
Gez
Developer
Developer
Posts: 1392
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Mon Sep 14, 2009 13:08

Graf Zahl wrote: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.
Graf Zahl wrote: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.
Graf Zahl wrote: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.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

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

Post by Graf Zahl » Mon Sep 14, 2009 16:03

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.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

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

Post by Nash » Tue Sep 15, 2009 1:06

- 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. :)

User avatar
Rachael
Developer
Developer
Posts: 3606
Joined: Sat May 13, 2006 10:30

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

Post by Rachael » Tue Sep 15, 2009 1:44

Nash wrote:I would love to see this integrated into ZDoom and GZDoom officially. :)
Me too, but you know what will happen with that...

"WFDS"
Spoiler: Zen Sarcasm

baghead
Hosted
Posts: 37
Joined: Tue Dec 16, 2008 3:26
Contact:

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

Post by baghead » Tue Sep 15, 2009 3:33

GezDoom huh? This will definitely be interesting.

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

*ducks*

User avatar
Rachael
Developer
Developer
Posts: 3606
Joined: Sat May 13, 2006 10:30

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

Post by Rachael » Tue Sep 15, 2009 4:31

I like logos.
Spoiler: Zen Sarcasm

User avatar
Gez
Developer
Developer
Posts: 1392
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Tue Sep 15, 2009 7:40

Nash wrote:
- 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.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

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

Post by Graf Zahl » Tue Sep 15, 2009 7:41

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

User avatar
Gez
Developer
Developer
Posts: 1392
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Wed Sep 16, 2009 21:18

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

Locked

Return to “Experimental Builds”

Who is online

Users browsing this forum: No registered users and 1 guest