Doom monster
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > DECORATE states near 100%
Pages (2): [1] 2 »  
Author
All times are GMT. The time now is 09:44. Post New Thread    Post A Reply
Quasar
Moderator


Posts: 6088
Registered: 08-00


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).

code:
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 "@ }

Last edited by Quasar on 06-23-10 at 19:05

Old Post 06-23-10 08:27 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
A Major Doomworld Concern


Posts: 6613
Registered: 01-02


http://sl4.poned.com/emot/emot-toot.gif

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 :)

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

Old Post 06-23-10 08:35 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Csonicgo


Posts: 4450
Registered: 03-04


WOOOOOOO thank you Quas!

Old Post 06-23-10 08:40 #
Csonicgo is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07


So "Null" has to be explicitly stated for states that have no codepointers?

Old Post 06-23-10 10:03 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
D_GARG
Forum Regular


Posts: 915
Registered: 12-09


[lights went off] woooOOoww!

Old Post 06-23-10 11:11 #
D_GARG is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 06-23-10 18:37 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Use3D
Forum Legend


Posts: 4714
Registered: 04-02



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.

Old Post 06-23-10 18:50 #
Use3D is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 06-23-10 18:58 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
phi108
Member


Posts: 560
Registered: 03-08


Really cool stuff, thanks Quasar!

Old Post 06-23-10 19:41 #
phi108 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Stilgar
Junior Member


Posts: 218
Registered: 07-06


Does this bring us any closer to seeing Heretic be playable?

Old Post 06-23-10 20:09 #
Stilgar is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07



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.

Old Post 06-23-10 21:58 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 06-23-10 23:19 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00


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.

Old Post 06-24-10 10:07 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06


How are the frames defined DECORATE-style going to be named? They're independent from the thingtypes in Eternity, unlike ZDoom.

Old Post 06-24-10 10:35 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07


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.

Old Post 06-24-10 11:10 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 06-24-10 18:27 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06



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.

Old Post 08-11-10 22:53 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07



printz said:
Speaking of RandomJump, how are the misc1 and misc2 fields handled in the Decorate heredoc syntax?

They're the offsets in DECORATE.

Old Post 08-11-10 22:58 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06


Are Eternity's frame-pointing codepointers currently supporting state labels?

Old Post 08-11-10 23:12 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 08-12-10 06:02 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07



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.

Old Post 08-12-10 08:20 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06



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?

Last edited by printz on 08-12-10 at 09:20

Old Post 08-12-10 08:57 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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:
code:
thingtype Foo { spawnstate S_FOO } thingtype Bar { inherits Foo states = @" Spawn: goto Super::Spawn "@ }

Last edited by Quasar on 08-12-10 at 14:39

Old Post 08-12-10 14:26 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06



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.

Last edited by printz on 08-12-10 at 16:28

Old Post 08-12-10 15:31 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06


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.

Last edited by printz on 08-12-10 at 17:12

Old Post 08-12-10 17:03 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6088
Registered: 08-00



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.

Old Post 08-12-10 17:20 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06


Example with crash:
code:
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 with
code:
Z_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).

code:
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:
http://i38.tinypic.com/2saxf93.png

Last edited by printz on 08-12-10 at 18:40

Old Post 08-12-10 18:19 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07


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.

Old Post 08-12-10 18:30 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8885
Registered: 06-06



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).

Old Post 08-12-10 18:47 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11217
Registered: 07-07



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.

Old Post 08-12-10 18:54 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 09:44. Post New Thread    Post A Reply
Pages (2): [1] 2 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > DECORATE states near 100%

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.