Yet another Format proposal: ReHacked

Introduction:

I am revisiting an old topic suggested and discussed here (1), regarding allowing Things
to have certain dehacked flags set on a thing-per-thing basis, Eternity already has and plans
to support some of these suggestions (by cooencidence, i had nothing to do with it)

Summary:

Current doom exstensibility issues

1. Dehacked is a pain in the ass for changes to simple monster behaviours
2. ports impliment scripting and thing changes in radically different ways, e.g stealth
monsters are only available to a very small number of ports (some consider this
a Good Thing)
3. projectile types and behaviours are very limited



My (personal) ideal solution

a simple fun port that allows a wide range of per-thing flags, where the monster behaviours
can be changed on a whim where colors can be changed and fast and respawning monsters can be
set on the fly. Monstes would have green sprites as default (where appropriate, the cacodemon
would have green instead of red, for example, the port would then need an internal ReHacked defaults setup so that monsters appear and behave correctly off the bat if a ReHacked file is loaded)

this limits the dehackability as you would not be able to change the sprites used but
you would be able to have a brown fast cacodemon that fired homing barrels, probably

i might even code this, using winMBF as a base, but as i'm a dad and work full time
my coding time is quite limited


A proposed solution: ReHacked

notable points
1. similar to dehacked in that a plain text file is used to alter the behaviour of
things
2. similar to script in that particular behaviours can be changed
3. power-through-simplicity, there would be a fairly wide range of options, but utilising
existing known engine behaviour so that port implimentation would not be rocket science
4. possibly extensible to become part of the 32-bit map format proposal (2), but any future
changes must retain absolute backwards compatiblity with the first incarnation




Detail

Flags should be broken down to inlcude a per-thing flag, engines should check this during
thing behaviour calls alongside (and therefore override) the usual global behaviour and deh flags

The ReHacked lump or file should be parsed at load time after any deh or bex files

Some flags would only apply to monsters, some can apply to weapons and some to projectiles, behaviour to be decided



Current flags, this is off the top of my head and is by no means exhaustive

from command line

RESPAWN behaviour as -respawn (-altdeath for items)
FAST behaviour as -fast



from deh

COLOR1 Color 1: convert green to gray/red
COLOR2 Color 2: convert green to brown/red
TOUCHY land mine
AMBUSH


from boom AI behaviours

FRIENDLY on player's side
BACKUP monster will back away from target during fighting
AVOIDHAZARDS monster will avoid walking under crushers etc


from other ports

SEEKERMISSILE heat-seeking projectile (though might be appllicaple to DEATH monsters?)
LOGRAV thing experiences low gravity
NORESPAWN thing will not respawn, even in -respawn or -nightmare modes
STEALTH stealth monster



Application:

a means to transparently tie the monster behaviours to their things needs to be thought
up so that groups of monsters can easily be assigned a behaviour group and so the ReHacked
Definition will not break if a thing is deleted (and the orders mixed up). if this can be
done so that if an engine is not ReHacked compatible it will play as normal doom/boom
then that would be preferable

e.g. the following four map things are fast and gray, they fire red, heat seeking slimeballs and bite you like pinky demons when up close. The sprite would appear as whatever the things default sprite would be, but with the coloring applied.

32,33,34,68
{
	behaviour:	FAST,COLOR1;
	melee:		DEMONBITE;
	attack:		SLIMEMISSILE;
	missile: 	SEEKERMISSILE,COLOR1,COLOR2;
}

Future:

simple way to assign sprite groups to monsters, perhaps via a standard sprite naming convention for walk,attack,death frames etc. though
getting all that, along with directions and frames into 8 chars might be an art unto itself! e.g "sprites: C3" where C3WKa1a7 is a walking frame and C3Dc4 is a death frame. This would also
require a lot more coding for source ports, most of which are still hardcoded into the Sprites and Frames behaviour tables. (one solution is that the Frame behaviour would not change but the sprites would be substituted at render time, though this means that rules for missing replacement sprites would have to be thought up, e.g. the archvile attack is quite lengthy and would need a lot of custom sprite frames to replace)



Disclaimer:

This is a very rough bash together and so my technical details and assumptions are probably very wide of reality



References:

1. set deh flags on a thing-per thing basis
http://www.doomworld.com/vb/showthread.php?s=&threadid=36737&highlight=thing+flags

2. 32 bit map format proposal
http://www.doomworld.com/vb/showthread.php?s=&threadid=34323&highlight=map+wad+format

3. xwad format
http://www.doomworld.com/vb/showthread.php?s=&threadid=37025&highlight=map+wad+format

I guess the twist with cycloids proposal is being able to give different things in a map different properties, e.g. every imp could have a different speed. That straddles the line between thing definition and map format.

It's a feature that would be very nice to have, but it depends on having a new map format, and last time I looked the discussion about that went down the drain.

it wouldnt require a new map format per-se, it would work in the same way that DEH takes an existing map and changes the behaviour and apperance of the things in that map after the fact. The tricky part is linking the thing details in the ReHacked lump to the specific Things in the map that need to be effected. Currently each has an id derived from the order it appears in the list-of-things.

ideally the map editor could track these and update the ReHacked lump in real time as you shuffled your Things about. Otherwise you could just write down the ids of the desired things on a bit of paper before editing your ReHacked file

Part of the simplicity of this is that it would (in this instance) only use flags and behaviours that are already defined in most (boom based) source ports. e.g. they all have the demon spectre/shadow behaviour defined and know how to render that. The trick is to allow the mapper to render that on a per-Thing basis instead of having to set it for all Things of a certain Type as they would via dehacked.

Some behaviours, like Stealth only appear in certain engines at the moment, the solution to that is that if a port encountered a flag it did not understand it should simply ignore it. This future proofs the spec (as new behaviours wont break incompatible ports) and allows ports to retain own-features whilst still being able to claim ReHacked support. So in this example your stealth monsters would simply not be stealthy in some ports, which brings up the idea that ports could allow the player to override settings and behaviours. Which lets face it, you already can in deh anyway, or just IDDQD to get past annoying creations and scenarios.

If it can get a .hhe or a .hex to work with some of the modern ports I'm fully behind this.

cycloid said:

it wouldnt require a new map format per-se

In reality, I think it does. Because for a feature like this to really be useful to mappers, it requires direct support in the editor (like DoomBuilder). Keeping track of thing numbers manually can become really painful, just casually deleting a thing can change all the numbers.

Ajapted said:

for a feature like this to really be useful to mappers, it requires direct support in the editor (like DoomBuilder). Keeping track of thing numbers manually can become really painful, just casually deleting a thing can change all the numbers.

That's the big issue i'm up against, for starters it'd be obviously usefull to have an alias system, so you can name a monster type and then assign it to all your modified monsters:

MegaImg :: Imp
{
   behaviour: FAST;
   projectile: FASTMISSILE,DOUBLEDAMAGE;
}

and then tag those to all the imps that you want to become megaimps in each map in your megawad. How to do that is tricky. If we could find a bunch of linedef tags that no port uses then that might help:

1. put imps in a sector
2. tag a linedef with it's front sidedef referring to the sector with the ReHacked linenum
3. set the target of that linedef to the targetid of a monster type:

(not code, just in code format for clarity)

sector:  12

linedef: 123
   front sector num: 12
   back sector num: -
   action: 7337 (Apply ReHacked Tag to Things in Front Sector) 
   tag: 2

MegaImg
{
   thing: 3001 (Imp)
   tag: 2
   behaviour: FAST;
   projectile: FASTMISSILE,DOUBLEDAMAGE;
}

Though the definition exists in a text file an editor could then tie the two together. Here the tag is not targetting a sector but a ReHacked def. only imps in the tagged sector would be effected and this is no more complex (indeed i think it's simpler) than the boom transfer-heights system, which you really do have to be a rocket scientists to understand

cycloid said:

MegaImg :: Imp
{
   behaviour: FAST;
   projectile: FASTMISSILE,DOUBLEDAMAGE;
}

That really doesn't look too different to Zdoom's DECORATE.

Whilst I do see where you are trying to go with this, I suspect it is highly unlikely it will ever gain universal acceptance. DEHACKED is, apparently, already a bit problematic to support, most ports do not support HHE or HEX so an additional format seems even less likely. Coupled with the fact that individual ports are already pretty far along their own respective ways of doing things it will be very difficult for some ports to change to support an additional format.

cycloid said:

That's the big issue i'm up against, for starters it'd be obviously usefull to have an alias system, so you can name a monster type and then assign it to all your modified monsters

The simplest kind of alias system would be to assign a new doomnum (thing_id) and use that in the editor. Which would be no different from DeHackEd, except that you can add new things. (Oh and nicer syntax).

Therefore you could boil down the proposal to be: allow DeHackEd to add new things and frames and weapons etc. I think that has a lot more potential to be adopted, since it extends something most ports already have, rather than adds something completely new.

yeah the problem that i have with dehacked is, to be honest, that it's a complete farce. the BEX extensions should have disassociated the frames from the "big array o frames" but didnt. instead to make a minor change to a monster you have to copy the entire thing over to another thing and change the one tiny behaviour in some spare frames that you have to farm from somewhere. why couldnt each action just have it's own local frame array?, for example.

anyway, the idea i have is that if we can devise something very very simple (to start with) that's simple to impliment then it might get a chance of finding it's way into a few ports. imagine if ReHacked v0.1 only allowed you to set the spectre/shadow effect on monsters, that flag is already a per-species flag and wouldnt take much effort to rewire to become a per-monster flag

as for more advanced editing, like setting the speed of projectiles, that can be devised. but for the time being there are plenty of existing flags that can be put into a bitsReHacked field and tested against at render/thinker time