Basic types for things in EDF

I've added a "basictype" field to the EDF thingtype definition that allows you to specify, well, the basic type of the thing. What this means is that its flag values and possibly some other fields are set for you behind your back based on defaults that are stored inside the game engine. This has a serious advantage in that if what it takes to remain being a member of that basictype class changes between versions of the Eternity Engine due to addition of new flags, your thingtypes will automatically update themselves. An example of this is the new PASSMOBJ field. All monsters *should* have this field now, but EE can't know whether you want it on your old monsters without forcing ALL monsters to have it, and I can't do that. With this new feature, if your thing type used "basictype = Monster", then that flag would have been added automatically.

Here are the currently existing basictype classes, all 17 of them. I am posting this mostly to solicit user ideas for further classes. Each class currently only uses 16 bytes of memory so I'm not worried about adding lots of classes.

Monster
FlyingMonster
FriendlyHelper
Projectile
PlayerProjectile
Seeker
SolidDecor
HangingDecor
SolidHangingDecor
ShootableDecor
Fog
Item
ItemCount
TerrainBase
TerrainChunk
ControlPoint
ControlPointGrav

I figure some variations are not worth having a basictype for -- for example, an item that doesn't appear in Deathmatch. This is because it's simple enough to use "addflags = NOTDMATCH" after specifying the basictype. So far the only classes that do anything other than setting flags values are ControlPoint and ControlPointGrav, which set the thing's spawnstate to S_TNT1 if that state exists. But, I'll accept any suggestions that people feel would be useful.

What to do when I define something as a "monster" basetype, but which (unlike "monster"s) is not allowed to activate walk-over triggers? Or in other words, what if somebody wants to make a basetype Thing "A" which actually lacks/adds a certain flag you consider to be (not) a part of the that basetype definition? Will the customisation overwrite it anyway? Or will the basetype flags prevail? What if this situation happens with a flag that was not invented yet when a certain mod was released?

I know you want to avoid situations where you add a new flag (like spacmonster or what was it again) that would potentially break existing EDF mods because they would lack the new flag... but the other way around is also possible... you add a flag to a basetype which breaks existing mods that use that basetype.

I think you should use a general purpose inheritance scheme, where the base types are defined using EDF as well. When an EDF definition does not explicitly set a field or flag, look in the parent. (The actual implementation might be: copy parent data into child before parsing, and during parsing only set the fields/flags which are given).

addflags/remflags take precedence over any flags that are from the basictype. So if you do "basictype = Monster; remflags = SPACMONSTER" you have what is a Monster but doesn't have the ability to activate parameterized (Hexen-style) monster linedefs.

Flags are rarely added that affect compatibility in this manner. This is, in fact, the first time I've added a flag that has a large impact on backward compatibility for EDF patches, and I intend to avoid it in the future whenever possible.

Ajapted: EDF does already have a general inheritance scheme. The problem is I don't want these useless, "virtual" thing types in the mobjinfo itself, so I make it separate from inheritance. This also has the advantage of having a multiple-inheritance-like effect, as you can do this:

thingtype FlyingImp
{
   inherits = DoomImp
   basictype = FlyingMonster
}

The resulting thingtype behaves identically to the normal Imp but flies. If this were strictly reliant on inheritance, you'd have to modify DoomImp's basictype in order to change the effect it has on inheritance, or simply specify the flags manually like you have to right now.

OK I understand now what you are doing: this 'basictype' keyword is simply a short-hand way of setting a bunch of other fields/flags. Almost like a C/C++ macro, but the definition is hard-coded.

I don't know much about EDF, but this seems like the wrong approach to me (rather confusing). With inheritance you can do something like this: provide these base types as standard EDF entries (in your eternity.wad or wherever), and encourage everyone to inherit from them. For example:

thingtype std_Monster { ... }

thingtype DoomImp
{
  inherits = std_Monster
  ...
}

That still achieves what you wanted: the base types can be updated to reflect engine changes, and anything using them will automatically get the benefit.

I guess I don't like hard-coded stuff, which then needs to be documented. Keeping those bits in EDF makes it self-documenting.

My two cents anyway :).

There is only single inheritance, though. You cannot inherit from both a "virtual" type and a normal type, so following your suggestion would make the FlyingImp example impossible, and unnecessarily so.