Jump to content

Mapthing / EDF thing property access


printz

Recommended Posts

Is there a way, or will it be planned so I can set in the map editor (or ExtraData) custom variables for the thing, so they're accessible in EDF? Similar to how ZDoom's DECORATE allows access to a thing's args.

Share this post


Link to post
printz said:

Is there a way, or will it be planned so I can set in the map editor (or ExtraData) custom variables for the thing, so they're accessible in EDF? Similar to how ZDoom's DECORATE allows access to a thing's args.

That feature is planned for UDMF; but the parser used for EDF and ExtraData cannot tolerate field keys that it doesn't know about a priori. libConfuse is a "strongly typed" system in that when it sees a key, it assumes it already knows what kind of value will come on the other half of the assignment, be it a simple value, list, section, function call, or multi-valued field. This would force some kind of less natural syntax if it were to be supported there, such as:

customfield("name", "value")

Share this post


Link to post

Couldn't they all be declared in one of the core EDF files, so that libconfuse knows about them? That's what ZDoom does (check the code for the Actor class).

Share this post


Link to post
Quasar said:

That feature is planned for UDMF; but the parser used for EDF and ExtraData cannot tolerate field keys that it doesn't know about a priori.

What about making EDF codepointers have access to the five args that are already known by the parser in the mapthing block? Or even some way (flag, codepointer) that copies the mapthing args data into the actor's counters.

Share this post


Link to post
Gez said:

Couldn't they all be declared in one of the core EDF files, so that libconfuse knows about them? That's what ZDoom does (check the code for the Actor class).

Would require creating the cfg_opt_t at runtime, which is certainly not impossible. Really what I should do is add support for this at the library level, within libConfuse (something such as cfg_appendopts or cfg_dynamicopt, etc.), since it's already semi-capable of dealing with it.

This would allow libConfuse to become sort of introspective, as it would be defining the syntax to parse a language within a language which it parses.

It would require declaring the types as well as the names, however. Basically what you'd end up with would be very similar to the cfg_opt_t in C:

cfg_opt_t opts[] =
{
  CFG_STR("blah", "", CFGF_NONE),
  CFG_INT("foo",  0,  CFGF_LIST),
  CFG_END()
};
In libConfuse "metaprogramming" this would end up probably looking like:
entity blarg
{
  option blah, string, "", NONE
  option foo,  int,    0,  LIST
}
An interesting idea. The properties declared as such could be metatabled under the same keys and become accessible to anything in the game engine... ::drools::

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...