Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
cycloid

ReHacked ReThunk!

Recommended Posts

disclaimer: these are just the Ramblings Of A Madman and should be ignored

weekend off, rethink and a new idea, BEX extended DEH so how about we extend REH in a simple to use and simple to impliment way


first, imagine you wanted to make a variation on the imp, but didnt want to messa about copying over the frames/bits/sounds/settings

thing 25 (Impaled human)
{
   rh_cloneThing = 3001
}
thing 3001 being the imp and thing 25 hereafter being an exact copy with the exact same behaviours, frames, ressurectability, flags, etc. Provided the REH file is parsed and actioned in a single thread no circular references can occur hence
thing 25 (Impaled human)
{
   rh_cloneThing = 3001
}

thing 3001
{
   Hit points = 90
}
Thing 25 is now a standard imp
Thing 3001 is an imp, but with 90 health (default is 60)

Thing 25, being processed earlier in the REH file does NOT inherit the later changes to the imp as the thing is a direct memory copy of the original state of the imp

this can be achieved via a rehacked.c and rehacked.h file, which i plan to incorporate to WINMBF if i get any chance to work out how to build this thing, flowchart


1. process REH file as if it's DEH
2. encounter rh_cloneThing
3. call rehacked.c with struct of current thing and id num of thing to copy
4. reh_cloneThing function copies structs and values from numbered thing into current thing, returns back to REH/DEH parse function
5. REH/DEH parse function continues oblivious to what just happened


REH FLAGS

to be held in a new 32 bit int for each thing, called something like bits_rehacked.

RH_FAST (0x01)
monster acts like a fast monster, regardless of command line/config setting

RH_RESPAWN (0x02)
monster respawns like -respawn, collectible thing will also respawn similar to -altdeath switch.



so to create a fast imp we can do this
thing 25 (Impaled human)
{
   rh_cloneThing = 3001
   rh_flags = RH_FAST
}
we'd probably want it to be a different color, so using the green imp sprites in place of the standard imp
thing 25 (Impaled human)
{
   rh_cloneThing = 3001
   rh_flags = RH_FAST
}

thing 3001 (Imp)
{
   Bits = SOLID + SHOOTABLE + COUNTKILL + TRANSLATION2
}
the usual imp is now brown, as it has the brown color transform flag in place, the copied imp is green (as per the sprites) and fast, but otherwise identical to the orignal imp


easy peasy!


todo: allow any monster to spawn any other thing as a missile, heh (which presumably could lead to REH implimented monster spawner things)

Share this post


Link to post

ahem

here: http://www.cyclomedia.co.uk/doom/reh/reh_v003.zip
is a zip containing a custom build of WinMBF with REH support, only REH_Clone is supported but that's because i kludged it together in about an hour. theres a test wad,patch and the effected source files (behold my 733t hax0r sk|77z!)


here we go: test map with a tree, an archvile, an imp, some hardware and an exit.



here it is with the REH file applied, two imps, identical, cloned infact. all the archvile mechanics and end-of level kills stats work as expected



ok, so my choice of colors isnt great but you get the point.


below are the contents of the .reh file needed to produce the above effect, most of which is probably redundant, the last two lines are the important bits

Patch File for DeHackEd v3.0
Doom version = 21
Patch format = 6

Thing 98 (Brown Stub)
REH_Clone = 3001
here's the reh file included in the zip, to test that the imps really are different
Patch File for DeHackEd v3.0
Doom version = 21
Patch format = 6

Thing 98 (Brown Stub)
REH_Clone = 12 (Imp)
bits = SOLID + SHOOTABLE + NOBLOOD + COUNTKILL

Thing 12 (Imp)
bits = SOLID + SHOOTABLE + SHADOW + COUNTKILL
the original imp is now a shadowed imp, the cloned imp has a pointless bullet puff effect when you shoot it. silly, but as a proof-of-concept i think it's hit the spot

Share this post


Link to post

So far, I don't really see much advantage. The cloning may only take up a few lines of code, but it basically does this:

Patch File for DeHackEd v3.0

Thing 98 (Brown Stub)
Initial frame = 442
Hit points = 60
First moving frame = 444
Alert sound = 39
Injury frame = 455
Pain chance = 200
Pain sound = 27
Close attack frame = 452
Far attack frame = 452
Death frame = 457
Exploding frame = 462
Death sound = 62
Speed = 8
Width = 1310720
Height = 3670016
Action sound = 76
Bits = 4194310
Respawn frame = 470
That code gives the Brown Stub all the properties of an imp. - It will look and act just like an imp in-game.

I created it with a few keystrokes using DEHACKED's internal copy function. It may look longer, but it is a system that already exists and probably didn't take any longer for me to create. Also, ports such as Edge and Zdoom can already do what your example does far more powerfully with their own internal systems.

Your's works, sure, but you do just seem to be reinventing the wheel. I see no additional advantage nor any great reason why a port author would want to adopt the system. At best, I see only one or two ports adopting it, leading to further disparity between the ports, not less.

Share this post


Link to post

just having fun when i'm supposed to be working i suppose, it'd be nice if other authors incorporated it but otherwise i suppose you could call it my own source port. which is why the GPL is fun

anyway the following flags now work

ALWAYSRESPAWN - will respawn as per nightmare mode regardless of game mode or skill setting

NORESPAWN - will never respawn, even in nightmare mode (does not effect archvile ressurections)

FAST - will act as a fast monster, regardless of game mode or skill setting

these are entered thus:

Patch File for DeHackEd v3.0
Doom version = 21
Patch format = 6

Thing 98 (Brown Stub)
REH_Clone = 12 (Imp)
REH_Bits = FAST

Thing 12 (Imp)
REH_Bits = ALWAYSRESPAWN
and look, in just a few lines i now have fast imps and respawning imps, your file may well be deh generated but consider this: i make a custom monster, totally DEH it up to the eyeballs and then want to create a subtle variation for another part of the megawad, provided the first creation's specs appear first in the REH file the second can just clone it and continue from there

REH_V004.zip is here


note that i've only implimented flag Mnemonics, no hard coded bit values are exposed, so in theory eternity could support the first two by just munging it's own internal flaggage.

next: track down those green imp sprites set, or have i imagined their existence?

Share this post


Link to post

Indeed it does:
http://www.doomworld.com/idgames/index.php?id=11108

Rip 'em if you want 'em. :)

cycloid said:

just having fun when i'm supposed to be working i suppose, it'd be nice if other authors incorporated it but otherwise i suppose you could call it my own source port. which is why the GPL is fun


Can't say fairer than that. :)

Share this post


Link to post

cheers NJ, here is rehv005.zip

It includes the green imp and a new experimental development,
REH_TroopAttack allows you to set the thing num of any thing you want the monster to fire instead of an imp fireball when it uses the TroopAttack action:

#new fire imp uses green imp sprites translated to appear red
Thing 98 (Fire Imp)
REH_Clone = 12 (Imp)
REH_Bits = FAST
REH_TroopAttack = 99 (Imp Flame)
Bits = SOLID + SHOOTABLE + COUNTKILL + TRANSLATION + UNUSED1

#set normal imp to brownify the green sprites
Thing 12 (Imp)
Bits = SOLID + SHOOTABLE + COUNTKILL + UNUSED1

Thing 99 (Imp Flame)
REH_Clone = 10 (Mancubus Fireball)
There's a sanity check in place, it'll quit out with an error if you supply a thing id that's not a missile, though it does raise the possibility of monster spawners.

a simpler override would be changing it to REH_MissileThing and overriding all the monster fire functions for that monster, but that would prevent you creating monsters that fire multiple different missles. But if i were to add overrides for all the monster missile things then that'd create a lot of redundant ints in the mobjinfo struct. hmmm

Fun though, the above patch produces a Red, Fast imp that fires Mancubus Fireballs. nasty! But the simplest use of this would be to clone the imp fireball and up it's speed to 20, fully completing the Red Imp's -fast emulation.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×