Quasar Posted June 23, 2010 As of r1234, EE's edf-branch has reached full maturity with the completion of DECORATE states, and the branch will be merged with trunk tomorrow after additional testing. Here is a functional example EDF which reimplements the DoomImp using DECORATE state syntax (inheritance is not used to avoid inheriting any states from the normal DoomImp, for full proof of concept). stdinclude("root.edf") thingtype DoomImpTest { doomednum 20001 spawnhealth 60 seesound bgsit1 painchance 200 painsound popain deathsound bgdth1 speed 8 height 56.0 activesound bgact cflags SOLID|SHOOTABLE|COUNTKILL|FOOTCLIP|SPACMONSTER|PASSMOBJ obituary_normal "felt some DECORATE states" obituary_melee "felt some DECORATE states" states = @" Spawn: TROO AB 10 A_Look loop See: TROO AABBCCDD 3 A_Chase loop Pain: TROO H 2 TROO H 2 A_Pain goto See Melee: Missile: TROO EF 8 A_FaceTarget TROO G 6 A_TroopAttack goto See Death: TROO I 8 TROO J 8 A_Scream TROO K 6 TROO L 6 A_Fall TROO M -1 XDeath: TROO N 5 TROO O 5 A_XScream TROO P 5 TROO Q 5 A_Fall TROO RST 5 TROO U -1 Raise: TROO ML 8 TROO KJI 6 goto See "@ } 0 Share this post Link to post
esselfortium Posted June 23, 2010 Awesome. Having seen all the effort and internal reworking it took to make EE capable of handling it, I have to reiterate how much I hugely appreciate the lengths you've gone to in order to make this possible. Defining objects in EDF just got a whole lot quicker :) 0 Share this post Link to post
Gez Posted June 23, 2010 So "Null" has to be explicitly stated for states that have no codepointers? 0 Share this post Link to post
Quasar Posted June 23, 2010 Gez said:So "Null" has to be explicitly stated for states that have no codepointers? At the moment yes. Evidently I somehow missed that you're allowed to skip it. Looks like I get to do a shit load of work to fix this now. 0 Share this post Link to post
Use Posted June 23, 2010 Quasar said:At the moment yes. Evidently I somehow missed that you're allowed to skip it. Looks like I get to do a shit load of work to fix this now. Does that really need to be fixed? It's not that big a deal to use null directly. 0 Share this post Link to post
Quasar Posted June 23, 2010 Use3D said:Does that really need to be fixed? It's not that big a deal to use null directly. I already have it fixed ;) And it is, since this is supposed to be as copypastable from DECORATE as is possible for EE. As of right now the one thing you have to do is change codepointers. I'll be implementing some of the important DECORATE pointers though, particularly various Jump pointers. But that work will be done in trunk after the merge, as it's not strictly anything to do with EDF itself. 0 Share this post Link to post
Stilgar Posted June 23, 2010 Does this bring us any closer to seeing Heretic be playable? 0 Share this post Link to post
Gez Posted June 23, 2010 Stilgar said:Does this bring us any closer to seeing Heretic be playable? I think it's unrelated. Heretic (and Hexen, and Strife) are waiting for a rework of the inventory and weapon systems. 0 Share this post Link to post
Quasar Posted June 23, 2010 Gez said:I think it's unrelated. Heretic (and Hexen, and Strife) are waiting for a rework of the inventory and weapon systems. It's partially related in that DECORATE states will be used in the weapon and inventory definitions :) I realized that these should go in first about half a year ago and so I suspended any further work on them until this prerequisite was finished. 0 Share this post Link to post
Quasar Posted June 24, 2010 Double posting to note that edf-branch has now been merged with trunk. DECORATE state support in EDF will officially debut with the next SVN revision upload. A new official release, codename Resheph, will follow this pretty swiftly. I just need to finish the LevelInfo rewrite I started the other day and it will be ready to ship. 0 Share this post Link to post
printz Posted June 24, 2010 How are the frames defined DECORATE-style going to be named? They're independent from the thingtypes in Eternity, unlike ZDoom. 0 Share this post Link to post
Gez Posted June 24, 2010 Why would they need a different name? It's not like the rest of the actor definition is DECORATE-style after all. Just the states. r1247 is online by the way. 0 Share this post Link to post
Quasar Posted June 24, 2010 printz said:How are the frames defined DECORATE-style going to be named? They're independent from the thingtypes in Eternity, unlike ZDoom. Unsure of what you really mean here, since DECORATE-block-defined states are not in fact "independent" of the thingtype in the sense that they do not have public names or DeHackEd numbers. Internally they are given the name {DS %d} with %d being an arbitrary ordinal representing the order in which they were defined. However this is not a name you can use with external frame targeting because it is not added into the hash table. It's only for internal use; for example, when printing an object's metatable, its metastates must have valid names to print. Note it is also not a name that can conflict with any valid frame mnemonic, since {} characters are not syntactically allowed within them. Eternity's various codepointers which can take frames to jump to will most likely be modified to additionally accept DECORATE state labels (which really amounts to saying they'll be extended to access metastate labels). When an argument doesn't match one in the hash table, I can look at the object's metatable and see if it has a state matching that description. 0 Share this post Link to post
printz Posted August 11, 2010 Quasar said:I'll be implementing some of the important DECORATE pointers though, particularly various Jump pointers.Eternity already has RandomJump, CounterJump and so on. Probably you're adding A_Jump to simplify the DECORATE->EDF copy-pasting process. Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax? Is the '=' sign required before the heredoc? Anyway, thanks a ton, because I'm also copying popular bestiary monsters into my EE work. 0 Share this post Link to post
Gez Posted August 11, 2010 printz said:Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax? They're the offsets in DECORATE. 0 Share this post Link to post
printz Posted August 11, 2010 Are Eternity's frame-pointing codepointers currently supporting state labels? 0 Share this post Link to post
Quasar Posted August 12, 2010 printz said:Eternity already has RandomJump, CounterJump and so on. Probably you're adding A_Jump to simplify the DECORATE->EDF copy-pasting process. Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax? Is the '=' sign required before the heredoc? Anyway, thanks a ton, because I'm also copying popular bestiary monsters into my EE work. A_RandomJump isn't currently compatible with DECORATE states because I haven't implemented offset() syntax (yet?). Though it may also be possible for me to simply define an alternate way to use the pointer with the normal args instead of misc fields. (The args didn't exist in MBF so it's not a compatibility issue). A_Jump is already implemented, and can address any DECORATE state label. A_Jump supports its own random jump ability, and so it kinda makes adapting A_RandomJump less important. It expressly and intentionally does *not* support global state names, so as to remain roughly equivalent to ZDoom's implementation. All other Eternity pointers that pre-existed will currently (as of a very recent SVN revision) check for a global state name first, and, having failed to find a match, will then check DECORATE state labels (both native and metastate labels will be matched properly - ie. Spawn, or Death.Fire, or Foobar). This allows them to seamlessly extend to DECORATE states. Do note btw that EE has for quite a while now supported A_ prefixes on action names even outside of DECORATE states. If the A_ is found, it is simply stripped off before trying to match the function against the internal bexptrs hash table. And no, equals signs are not required anywhere in EDF any more. I just prefer to put one there myself because to me it looks odd without it, kinda like the states keyword is just detached out there by itself. 0 Share this post Link to post
Gez Posted August 12, 2010 Quasar said:A_RandomJump isn't currently compatible with DECORATE states because I haven't implemented offset() syntax (yet?). Though it may also be possible for me to simply define an alternate way to use the pointer with the normal args instead of misc fields. (The args didn't exist in MBF so it's not a compatibility issue). When I wrote some hacky way to add MBF dehacked compatibility to ZDoom, that's kinda what I did. The RandomJump call is remapped to A_Jump, and the misc values are turned into real parameters. EE doesn't need to do that of course since it already has these functions anyway; but yeah it'd make a lot more sense to use the parameters there. 0 Share this post Link to post
printz Posted August 12, 2010 Quasar said:Unsure of what you really mean here, since DECORATE-block-defined states are not in fact "independent" of the thingtype in the sense that they do not have public names or DeHackEd numbers.What I tried to say in that post was that if thing frames are defined via Decorate, I won't be able to create Delta structures to individual frames any more, so it will be more work to patch a custom monster from another mod to act slightly differently. I trust that there'll still be a root FRAMES.EDF containing classically defined frames? 0 Share this post Link to post
Quasar Posted August 12, 2010 printz said:What I tried to say in that post was that if thing frames are defined via Decorate, I won't be able to create Delta structures to individual frames any more, so it will be more work to patch a custom monster from another mod to act slightly differently. I trust that there'll still be a root FRAMES.EDF containing classically defined frames? For compatibility reasons, yes, the frames for DOOM objects must remain defined as global states. I may or may not convert Heretic's objects to DECORATE states; it depends on the feedback I get in response to this idea. Strife and Hexen's things will be defined using them from the get-go. It will soon be possible to completely replace (including via DoomEdNum) objects by inheriting from them, and at that point, what you'd do rather than use a framedelta is simply replace the state sequences that need to be different. The rest will be inherited, and can be used by utilization of the Super:: specifier, a parent thingtype namespace, or just the simple bare label name if it hasn't been overridden in the child type, in goto labels and A_Jump targets. The only reason this hasn't been possible up til now is because Lee's DoomEdNum hash table is volatile and doesn't guarantee that the newest thing using a DoomEdNum is necessarily the one that will be gotten from the hash table. I intend to replace that hash with one that has the guaranteed properties of EE's other hashes. This is the sexy thing about metatables - I just call MetaCopyTable and an inheriting thing automagically gets all of its parent's metastates :D EDIT: It's probably important for me to mention this fact explicitly: Even an object which does not use DECORATE states can be inherited from and have its native state fields referenced using the corresponding DECORATE state labels. Native state labels currently include Spawn, See, Pain, Missile, Melee, Death, XDeath, Raise, and Crash. So for instance this is perfectly valid (however pointless - there are actual possible uses for it, of course) EDF:thingtype Foo { spawnstate S_FOO } thingtype Bar { inherits Foo states = @" Spawn: goto Super::Spawn "@ } 0 Share this post Link to post
printz Posted August 12, 2010 Quasar said:For compatibility reasons, yes, the frames for DOOM objects must remain defined as global states. I may or may not convert Heretic's objects to DECORATE states; it depends on the feedback I get in response to this idea. Strife and Hexen's things will be defined using them from the get-go. It will soon be possible to completely replace (including via DoomEdNum) objects by inheriting from them, and at that point, what you'd do rather than use a framedelta is simply replace the state sequences that need to be different.That would prevent me from creating very compact EDF patches that only replace individual frame details (such as making already existing frames faster or changing their codepointers). Since there's already the Heretic frame list inside its FRAMES.EDF, why scrap it? Different thing species won't be able to reference common frames. I know I'll be able to rewrite each sequence for each species, but having a common pool of frames sounds cleaner to me, than an exact copy for each object. Because this is not exact DECORATE, maybe you can add new features to it? Like an optional mnemonic field to each frame (similar in necessity to how the Dehackednum was in the old days), that makes the frame public. The mnemonic will probably be read as S_thingname_framename. Hopefully the DECORATE will be released readable in the EDF, unlike with ZDoom, where I have to read the wiki and hope it's up to date. Is the "replaces" declarator supported? Are custom fields, as well? EDIT: there are a few equivalent but differently named codepointers, such as A_CustomMissile having to become A_MissileAttack. 0 Share this post Link to post
printz Posted August 12, 2010 Tested with r1292, the "bright" keyword causes the game to crash. EDIT: the offset() syntax is important, because Spawn, PlaySound, Mushroom and so on need it. 0 Share this post Link to post
Quasar Posted August 12, 2010 printz said:Tested with r1292, the "bright" keyword causes the game to crash. EDIT: the offset() syntax is important, because Spawn, PlaySound, Mushroom and so on need it. Crash how? Is that really all the info you can give me? offset will probably be added when weapons are added, but I don't want pointers using it to pass parameters. Spawn will be one-upped by a DECORATE-compatible pointer. PlaySound is already one-upped by PlaySoundEx. Mushroom is a special case and I will consider it by itself. 0 Share this post Link to post
printz Posted August 12, 2010 Example with crash:thingtype CacoLichFlameFar { basictype projectile seesound lichflam speed 30.0 radius 16.0 height 6.0 damage 2 addflags TLSTYLEADD translucency 80% states @" Spawn: CFIR ABCDEFGHIJKLMOP 1 bright Stop Death: CFIR HIJKLMOP 1 bright Stop "@ } Result: After monster tries to shoot said projectile, the game bombs withZ_Realloc: Failure trying to allocate 838860800 bytes Source: .\source\r_things.c:409 In addition, right before the bombing, I see the additively translucent picture of an Imp instead of the projectiles. It only happens if I go melee with that monster (in which case, the creature fires these things instead, described below). At range, it shoots what you see above, and in effect, nothing in-game happens (no projectile). thingtype CacoLichFlame { inherits CacoLichFlameFar speed 28.0 radius 15.0 damage 1 } Quasar said:Mushroom is a special case and I will consider it by itself. I have a MBF mod that uses the two misc parameters to make the mushroom explosion more horizontal, thus more effective. Are you sure it's a good idea to abandon its parameters? Here's a pic of firing them with undefault params: 0 Share this post Link to post
Gez Posted August 12, 2010 For Mushroom, I'd advise simply doing it like ZDoom does: instead of misc1 and misc2, you can use the fourth and fifth parameters. Using Offset(x, y) to pass parameters is frankly counter-intuitive and the illustration of a slavish devotion to the implementation details inherited from an old hack. 0 Share this post Link to post
printz Posted August 12, 2010 Quasar said:Spawn will be one-upped by a DECORATE-compatible pointer. PlaySound is already one-upped by PlaySoundEx. Mushroom is a special case and I will consider it by itself. What else is left: Turn, Face (does ZDoom have equivalents?), Scratch (important, could use expanding), LineEffect (pretty interesting codepointer if I may say so). 0 Share this post Link to post
Gez Posted August 12, 2010 printz said:What else is left: Turn, Face (does ZDoom have equivalents?) http://zdoom.org/wiki/A_SetAngle printz said:Scratch (important, could use expanding) http://zdoom.org/wiki/A_CustomMeleeAttack printz said:LineEffect (pretty interesting codepointer if I may say so). ZDoom allows to put call to action specials instead of a codepointer. If Eternity copies this convention, it's a lot more user-friendly than using a number. 0 Share this post Link to post