Graf Zahl
Forum Legend
Posts: 4194
Registered: 01-03 |
Quasar said:
Suggestions:
1) In Eternity, the activation parameters, which are stored in the "extflags" field accessible via ExtraData, include the following flags:
* CROSS
* USE
* IMPACT
* PUSH
* PLAYER
* MONSTER
* MISSILE
* REPEAT
* 1SONLY
This allows a single line to be activated by any combination of thingtypes, methods, etc. I understand that ZDoom does not currently support this. How can it be handled?
That's precisely how I'd implement it, too. I don't like the limitations of ZDoom's current method and change it as soon as possible. Although ZDoom has one more activation type but that one is just a combination of two which are mentioned here already.
2) Z height should remain relative, as it was in Hexen. Otherwise, changing a sector floor height will require updating all z-positioned things inside the sector. Either that, or two different z fields could be created, one for relative height and one for absolute coordinate.
No need to change it. I see no need to have a second z-field. The only port which has implemented a few absolutely positioned things is Vavoom with its static lights but I see these more as an aberration than something that needs to be explicitly supported by another feature.
3) Hexen id's and Doom line tags have slightly different semantics. Tags default to 0, whereas id's default to -1 (lines without an id in Hexen cannot be addressed by a tag-style search at all, since they're never added to the line id lookup table). Should there be a separate "id" field for Hexen? This is how EE handles it internally, and even allows the id to be set explicitly via ExtraData, separately from the line tag.
That fully depends whether the format allows specifying doom format specials. If so it needs the tag parameter. I don't know Eternity's precise needs here but for ZDoom doesn't need to make the distinction. All Doom format specials are translated to Hexen format when the map is loaded so after that the tag as such is never needed anymore. This means it could take the place of the first of Hexen's line special args. Of course, in order to support Doom format maps it needs to set the id the same as the tag. But for the new format I'd do a strict separation between tags (which essentially are merely parameters for the line special) and id's.
4) While I'm aware this is just the basic specification, here are the new fields that EE currently supports for sectors:
* damageamount (int, damage every leveltime & damagemask tics)
* damagemask (int, determines frequency of damage)
* damagemod (string or int, method of damage (ice, fire, etc))
* floorterrain (string, name of TerrainType)
* floorangle (float, floor flat angle in degrees)
* floorxoffset (float)
* flooryoffset (float)
* ceilingterrain (string, name of TerrainType)
* ceilingangle (float)
* ceilingxoffset (float)
* ceilingyoffset (float)
* colormap_upper (string, colormap lump name)
* colormap_middle (string, colormap lump name)
* colormap_lower (string, colormap lump name)
ZDoom could support all of them - except 'ceilingterrain'. What's that being used for? For the 'damagemod' parameter, how would that work. I'm asking because ZDoom allows custom damage types so some minimal standard is required. I'm assuming that any damage type that is not known gets treated as 'no special damage type', right?
Another question: How to specify RGB colors? For ZDoom's colored lighting this is important. Just a string in "RR GG BB" format or better a hexadecimal integer 0xRRGGBB? I think this is something that needs to be cleared because color selection in an editor is logically best done with a special color selection dialog.
I know ZDoom also has sector specials that can be set via scripting and activate on various actions, such as an actor entering the sector or hitting the sector floor. Seems like another natural field to add.
These are done with special things that are placed in the sector so it's not needed to add them to the sector's properties. The current method has the advantage that an unlimited amount of actions can be placed in the same sector with each one having its own trigger type and I don't see it making editing any harder if it stays that way.
When we get into things like these, determining how and what DB will handle may get tricky. What sort of process will we use to work it out? While the standard that I specified allows for unknown keywords and fields, what recourse will we have if DB does not implement support for a given feature?
Is there perhaps a practical way for DB to support adding arbitrary information to entities? Such as a dialogue box that would pop up and have a text field into which the user could type a keyword/value pair? This would allow for adding fields that DB does not yet or will never support. I understand it adds more work to implementing this format, since things, lines, and sectors will be required to hold a list of string objects that describe their user-added fields. Seems fairly simple on the surface though.
[/quote]
Precisely what I think, too. The user should be able to add new fields at will to a simple property list where the fields are listed by name and the values can be edited. That way any port has the flexibility to add some extravagant stuff and it is immediately accessible to mappers.
Moriarti said:
In regards to flags, why represent them as a bitfield at all? Why not make each flag its own boolean field? This would simplify the map format so a reader wouldn't need to parse a flags string to extract each property out of it. Instead, it just sets a bit in its own internal flag(s) field(s) as it encounters a flag. Presumably any flag that doesn't appear as a field will default to off.
So the example from the opening post could be better written as:
code:
thing 245 { easy = 1; normal = 1; hard = 1; ambush = 1; }
Yeah. Why not? ;) It's certainly easier to parse than a bitmask with 'or' operators.
Yagisan said:
In summary:
Eternity: For
GZDoom: For
Doomsday: Against
Deng-NG: Against
[/B]
You can add ZDoom as well to that list because I'd never implement it in GZDoom but not ZDoom. And if ZDoom leads, Vavoom will eventually follow. I think Legacy will, too. Which only leaves the Doomsday faction out. I intentionally don't count the more 'classic' ports because due to their very nature I think it's unlikely that they will participate. But still, with the question mark behind Legacy (and EDGE, of course) that would mean broad support by ports that specialize in advanced mapping features.
Ajapted said:
Comments can be useful for debugging (especially writers). Quake 'map' format is text based and allows comments.
Comments in the text format: No. Makes no sense at all.
A 'comment' property for each sector/line/thing: Yes, why not. But that doesn't require any change in specification. If the property list is implemented any mapper could use some unused property names for comments. Let's just say that no active property must start with the word 'comment' and you are already done. ;)
CodeImp said:
Uhm, now I am confused. Aren't these the same as the ones I took from hexen in my proposal? just different names?
No. Hexen uses a bit mask that defines 8 types. This is a bit field that uses one bit for each so they can be freely combined (like a line that can both be activated and shot or a line that can be crossed by a player or a projectile.
No, if your engine internally works with relative Z heights, then you only have to take the absolute Z height from the map data and calculate the relative Z height for your entity at load time, once only. I think the value in the map format should be an absolute value, because X and Y are absolute as well.
I disagree. Relative is easier to use for mapping because you don't have to think actively about z-positioning. 0 means 'on floor' or 'on ceiling' depending on the SPAWNCEILING flag. If you make z absolute the mapper has to actively think about the z field each and every time he adjusts something in the map.
Lets just define 0 as nothing and if your engine encounters zero, don't add it to the list or simply do if(tag == 0) tag = -1; ? Tags are everywhere and are everything, lets not make an exception for the linedefs here because Hexen wanted to be a racists :P And we really shouldn't be using two fields for this IMO.
As I said before, the tag is better doubled by the first arg rather than the ID. For any new map format it's better to think of the tag as a parameter to the line's special type, not an integral linedef property. That's the ID now. Hexen's developers were correct when they made this distinction. They only made the fatal mistake to forget an 'id' field in their linedef structure to save an irrelevant amount of disk space (approx. 50 kb to be precise.)
Sure why not, I don't see a problem here. Just one little detail: Would you agree on putting the x/y at the end of the field name and do this throught the map format as a naming convention rule (highest significant identifier on the left)? So "floorxoffset" would be "flooroffsetx". Oh and while I'm on to naming conventions: why the underscore after colormap?
Yeah, x and y should be put to the end. As for underscores, why not? In fact I'd have used some for ceiling_/floor_* properties as well. If the property names are accessible in a list to the mapper their names should be made a bit more readable. 'colormap_upper' is certainly more readable than 'colormapupper'
Yes I think I will probably add a tab panel on each editing window for Things/Linedefs/Sectors that will just have a list of custom values to edit. Better yet, I'll probably make the list a sort of editor that recognizes names (from the Game Configuration) and gives the proper editing method (when the int field is supposed the be an action, it will allow you to choose from a list of actions) so that the Doom Builder interface won't need any changes for additional fields you might add later: just add the to the Game Configation as well and they are easier to edit!
Sounds good. ;)
RTC_Marine said:
How about a iwad identifier of sorts in the format? to distinguish which main game wad file it was intended to run with?
This may help clarify extreme similarities between one or two main wad files (ie plutonia or tnt or doom2)
Might be useful. Then again, might not be. For KDiZD it would have been a big help but for other maps it may become a nuisance. I often single maps and build episodes out of them and in such a case coding the required IWAD into the map is not that smart. I think for things like this external control lumps like (E)MAPINFO are better suited. Let's keep non-map related things out of here.
|
01-16-08 05:45 
