Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
CodeImp

UDMF Request: Map-specific fields prefix

Recommended Posts

Someone raised a concern that when sourceports allow users to create custom UDMF fields to be read from the map elements with, for example, an ACS script, the user-defined fields could later conflict with the sourceport's supported fields when the sourceport implements fields with the same name the user chose to use for the custom fields in his map. Possibly, in worst case, breaking the map.

The idea to prevent this is simple. If we add a rule to the UDMF specifications that all fields meant for the map only must use the map_ prefix. This means that sourceports implementing support for special effects may NOT start their field names with map_.

(Doom Builder can help the user by already showing the map_ prefix in the custom field input box so the user does not have to type this, but, can remove it in case a sourceport-specific field has to be added)

Share this post


Link to post

I don't know if everyone will agree with me on this, but if a restriction like this is implemented, I think that violating it should probably result in a visible warning message (either in the console or just displayed as an ordinary ingame message, or whatever works) rather than completely preventing the map from running.

Share this post


Link to post

I would suggest the prefix "user_" rather than "map_" because the former corresponds precisely to what this is meant to do - support unambiguous user-defined fields that cannot conflict with port extensions. The latter suggests semantics which are unnecessarily restrictive.

In response to essel: In EE I intend to parse and store all fields, even ones that do not correspond to anything EE can use. In order to do that flexibly I am not going to care whether or not the prefix is actually there - that's for the user to worry about. To that end, I am not going to flood the console with possibly hundreds or even thousands of warning messages. So in short, no, that would not be an appropriate handling of unknown fields.

Share this post


Link to post
Quasar said:

To that end, I am not going to flood the console with possibly hundreds or even thousands of warning messages. So in short, no, that would not be an appropriate handling of unknown fields.


Maybe not in normal gameplay, but there could be a "strict mode" Eternity could be run in, which would report if unknown fields are used. It could be useful to find the source of an error if, say, a field is misspelled.

Share this post


Link to post

I could possibly see output to a log file. EE has log file systems for DeHackEd and EDF already, what's one more? :P It's more permanent than the console, which can lose information if it's flooded far enough, and easier to read too. Not to mention you can refer to it without leaving the game running, or having to explicitly run a dumplog command.

Share this post


Link to post

I think this should not be anything more than a naming convention like a guideline. The sourceport itsself may ignore unknown fields silently, there is nothing wrong with that. The user_ fields are meant to be read by scripting, but I don't want to forbid scripting to read any other field as well (this could even be useful).

Share this post


Link to post
CodeImp said:

The user_ fields are meant to be read by scripting, but I don't want to forbid scripting to read any other field as well (this could even be useful).



ZDoom does not store any standard fields in an accessible manner so in order to prevent incorrect use right from the start I'd block access to anything except properly prefixed fields to scripts.

If such a naming convention is not enforced people will not follow it and then later again they say 'ZDoom is not compatible to itself' although in 90% of all problem cases it's the mods that did not follow the specs and exploited definition holes that, when plugged, broke the mods. Not this time!

Share this post


Link to post

Although I have no vested interest in this I'll offer the following observation:

Why not simply extend the namespacing mechanism? Simply require that any new fields a user wishes to add are put into a namespace specifically for that purpose and that unknown fields in port-specific "official" namespaces are simply ignored by said ports during parsing. Then, when retrieving data from a subsystem like say, ACS, first check the port-specific namespace, then the user namespace.

Granted, that doesn't stop users from adding fields to other namespaces that may ultimately result in field-name collisions later on. However, given that this isn't meant to be a hand-written format I would expect that the chances of this are rather slim, especially given that at the time the user does it, their mod won't work how they intended anyway (can't find the data; unknown field "foobar").

EDIT: Made more verbose, for clarity.

Share this post


Link to post

I fail to see how it is that much more complex than what a compliant parser must do to read the UDMF spec as-is to be honest. Sure, there is a little more preprocessing to be done but its all very straight forward and you'd still end up with a one to one map between field names in the map format itself and the names by which they will be referenced at run time. Its not like we are talking dynamic scoping here.

As far as an editor is concerned, the solution presented would be even less of a hassle as in their domain, they don't care what namespace the fields are in so long as they ensure not to merge them.

Share this post


Link to post

Quasar, could you propose the change in the UDMF specs and post it here please? If we're going to put this convention in, then I'd like to do add code support in DB2 for it before DB2 is released.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×