New EDF Progress

Here's an example thing type entry from the newly converted frame and thing data:

thingtype Dsparil {
  spawnstate = S_SOR2_LOOK1
  spawnhealth = 3500
  seestate = S_SOR2_WALK1
  seesound = sorsit-
  attacksound = soratk-
  painstate = S_SOR2_PAIN1
  painchance = 32
  painsound = sorpai-
  missilestate = S_SOR2_ATK1
  deathstate = S_SOR2_DIE1
  speed = 14
  radius = 16.0
  height = 70.0
  mass = 300
  activesound = soract-
  flags = SOLID|SHOOTABLE|DROPOFF|COUNTKILL
  flags2 = E3M8BOSS|BOSS|FOOTCLIP
  flags3 = LOUDACTIVE|DMGIGNORED|BOSSIGNORE
  dehackednum = 202
}

The code is free format of course, with a couple of exceptions. Fields can be in any order, and if left out, will default to a documented value (sometimes but not always zero). Basic EDF (sprites, things, and frames, with no new fields added specifically to take advantage of EDF) is a giant step closer to completion now!

I would like to say this put my fears that EDF would be complex to rest. EDF, combined with dehacked, bex and Small will be one of the greatest tools you could use for a mod.

Looks a lot like DeHacked/ZDoom lumps, which means it'll be an easy transition.

eternity is going to own!

but i'm a little confused by the flags, flags2 and flags3 properties. couldn't you've come up with some better names?

Don't you think that it would make sense to integrate the states into the actor and not make them separate entities? I am currently trying to figure out what was done to the objects in the Doom64 TC (which is DED-format for JDoom which is quite similar to what you have posted.)It is a nightmare to read this stuff (not to mention error prone)

I would define the states as follows (the rest of your format is ok.)

	States
	{
	Spawn:
		POSS A 10 A_Look
		POSS B 10 A_Look
		Goto Spawn
	See:
		POSS A 4 A_Chase
		POSS A 4 A_Chase
		POSS B 4 A_Chase
		POSS B 4 A_Chase
		POSS C 4 A_Chase
		POSS C 4 A_Chase
		POSS D 4 A_Chase
		POSS D 4 A_Chase
		Goto See
	Missile:
		POSS E 10 A_FaceTarget
		POSS F 8 A_PosAttack
		POSS E 8
		Goto See
	Pain:
		...
		(and so on)
	}

The biggest advantage of something like this is that all state linking is done automatically which would reduce the amount of work to create new actors considerably.

That sounds like a pretty good idea. How would you handle "random" attacks like the Maulotaur though?

States cannot be integrated into actors compatibly. Keep in mind you can still use DeHackEd even after EDF is loaded, and you can even edit the new things added via EDF with DeHackEd (although the point of doing that is nil). Also, some states are used by multiple actors, including S_NULL, which is used by almost every single thing in the game to indicate that it can be removed safely. It would be silly to duplicate these states inside every thing; the state count would increase by hundreds with no increase in functionality.

I understand your reasoning behind the idea though. It would be a lot easier to deal with the states if they were in one place with the thing that uses them. However, I am currently thinking about making a visual EDF editor that lets you manipulate things and their frames as conceptual objects rather than as text. If I go ahead with this, then finding the associated frames will be much easier -- its likely there would be a "frame trace" function that collects all the states the thing can normally enter, and possibly more when it knows special information about the codepointers being used (RandomJump, for instance, would be easily traceable too).

schepe said:

eternity is going to own!

but i'm a little confused by the flags, flags2 and flags3 properties. couldn't you've come up with some better names?

The names aren't that unclear compared to the flags' actual functions, and are the same as the names used in DeHackEd (the same parsing code is used, in fact).

The only distinctions between the 3 flags fields are the flags that they can be assigned. There's only 32 bits in each word, short of using an int64, which has relatively poor portability, and I've defined enough flags to need 3 words so far. All of this stuff will be documented, of course (its already documented in the DeHackEd docs, in fact, and will be duplicated in the EDF docs for completeness). Also, if I complete the visual editor, setting and unsetting flags there will be as simple as using check boxes on a property pane.

Quasar said:

The only distinctions between the 3 flags fields are the flags that they can be assigned. There's only 32 bits in each word, short of using an int64, which has relatively poor portability, and I've defined enough flags to need 3 words so far. All of this stuff will be documented, of course (its already documented in the DeHackEd docs, in fact, and will be duplicated in the EDF docs for completeness). Also, if I complete the visual editor, setting and unsetting flags there will be as simple as using check boxes on a property pane.

Merge them into a single "flags" setting and make it so EDF assigns the flags to the right word automatically. People really shouldnt have to worry about getting the right flag for the right word.

Yeah. Some more code in the parser. But not THAT much.
you could even keep the old method too, but called flags1 flags2 and flags3, so people could choose to use it instead of the nice flags which the parser breaks down into the former three automaticaly.

BTW, I'm considering implementing a combined flags field since you guys requested it. It *WILL* have to use a different parsing function, but I don't think that's a bad thing, necessarily. I haven't gotten to this yet, as of the first alpha test release though.