Quasar
Moderator
Posts: 2203
Registered: 08-00 |
I think that communication is breaking down because my points just aren't getting through in a concise manner. Let me try to boil down what the real issues are here, and what are not issues:
Actual issues:
Various games define conflicting specials and thing type numbers. If the interpretation of these numbers is confined strictly to being determined by the IWAD in use, then it is impossible to present a unified set of such numbers. If, on the other hand, interpretation of the numbers is confined strictly to the unified set defined independently by each implementing port, then the following things become *impossible*:
1. Translating a binary map for the vanilla game engine (Doom, Heretic, Hexen, or Strife) into UDMF format and allowing it to be understood by ALL UDMF implementing source ports. Emphasis put on the important part.
2. Allowing editors to edit maps using the native set of line specials, thing type numbers, etc. that they have been accustomed to using for almost 15 years. I don't think the value of the availability of this 1:1 correspondence to the end user could be underestimated.
Some Examples:
A Doom Barrel is expected to be DoomEdNum 2035. However, in Heretic, the Pod is DoomEdNum 2035. Which should have precedence in a map that expects all defined object classes to be available? In EE, under a map marked as being untranslated (ie, the unified namespace), DoomBarrel wins, having 2035. But the Pod pays, getting translated to 7235.
In Heretic, sector type 15 is ice. In Strife, sector type 15 is instant death sector. In Doom, sector type 15 does nothing. In a unified space for a given port, each will be different. But no ports have ever agreed on how to disambiguate this stuff, so point 1 comes into play heavily here. It may be tempting to each of us to tell the other "do it my way," but we're going to get nowhere if we adapt that mentality.
We more or less implicitly agreed not to do such when we declined to standardize such line/sector/thing types.
Declaring that Doom and Hexen style specials cannot be intermixed by any port is actually a gigantic breach of this principle, in effect, because the absolute only difference between the two, and one that an editor can ignore entirely, is that one doesn't make use of any SPAC or args values that have been specified on the linedef.
Non-Issues:
Contrary to what you have stated, Graf, this should have absolutely no effect on the editor. The only thing the editor has to do is put a special number in the special field. It does not have to understand the semantics of that special. It doesn't have to disable the ability to set SPAC flags or args on such a line - nay, in fact, maybe the implementing port actually has uses for them in that case (EE does not, but it wouldn't stop somebody else).
Either special numbers have to be ENTIRELY defined by the implementing ports, or entirely defined by the standard. We decided, rightly I feel, that demanding implementation details is wrong. Let us stick to that now in finalizing the standard.
EE allowing intermixed special styles should not have any effect on ZDoom, unless ZDoom is intending to add support for Eternity maps, in which case the onus falls upon you or Randy to account for the differences in implementation between our two ports. Just as I have taken account of certain ZDoom implementation details as I have been implementing Hexen map format support. I do not think that it should be expected to be technically feasible for either of us to ever fully support the others' maps.
But the entire idea behind specifying the target port (be it one of the original EXEs or a newer one - the two are quite the same when you think about it) - is so that these differences can be understood and accounted for automatically.
As a thought experiment, let us say that someone is by mistake loading an Eternity map under ZDoom. Which is the better outcome?
1. The map attempts to load, and crashes the game.
2. The map loads silently without error message, and does not work.
3. The map loads with error messages, and does not work.
4. The map loads with error messages, and works partially.
5. The map loads and works perfectly.
Here are the necessary conditions for each:
1. UDMF does not specify target port. Incorrect interpretation of special numbers caused by assuming the host port's translation of such results in destabilizing the program. Quite possible even now with the binary map format.
2. UDMF does not specify target port, but the map just happens to not be able to crash the game, probably because the host port is well coded. Still, this is unfortunate.
3. UDMF specifies the target port. The host port does not implement a translation for the target port, but it CAN now let the user know they are not going to get what they expect. It is an improvement.
4. UDMF specifies the target port. The host port implements partial support for the target port's translation. Not mandatory for any port to do, but a good way to expand the scope of the program and move toward the elusive goal of cross-port map compatibility.
5. UMDF specifies the target port, and the host port has taken the trouble to use this vital information to fully translate the map into information that it understands. Again not mandatory. Again good.
The point is that the 3 GOOD options *require* the translation information to be stored in the UDMF map. Without it, we have actually made extremely little progress by defining this format :)
|
05-02-08 20:37 
