Quasar
Moderator
Posts: 2133
Registered: 08-00 |
Strife flags info: Thanks Graf, will amend the standard.
Thing height as float: Missed this, should definitely be float, for consistency if for no other reason.
SPAC flags with Boom specials: I thought we agreed that the activation info for DOOM-style line specials (including BOOM generalized specials) should be implicitly defined - IE, line type 1 is "Dr Door Open Wait Close (monsters can activate)" regardless of what the SPAC flags say. Having it any other way makes the namespace standardization of considerably less value. Consider that an automated map converter would then need to understand the semantics behind every special in the Doom, Heretic, and Strife namespaces in order to properly set the SPAC flags, rather than being able to simply leave them zero and have the special work as normal.
In your ZDoom namespace you only deal with parameterized line specials, so it shouldn't be a problem for you. When converting Doom maps you already never had that information. Not having to deal with it now means you can use the same code you use now to load Doom maps when dealing with UDMF namespace Doom. Introducing SPAC into that formula will complicate things for you. If people want to use the SPAC data, shouldn't they be using either Hexen or ZDoom namespace? This is the way that I look at it. It may not be ideal but it does have some advantages.
Class bits: Not a big deal to me what number they start at, I was just thinking in programmer-ese when starting them at 0. I can change this.
Doom/Boom specials on things: See the above point about using SPAC with Doom specials. I think the same thing applies here. It makes no sense to try to use them on things because Doom has no mechanism for dispatching its line specials from mobj_t's. Its system is hardwired to work only from linedefs (and employing hacks to accomplish it, like Lee Killough's LineSpecial codepointer, can lead to some nasty side effects on the map).
Defaults: I think keeping flags off by default is still the best policy. I understand that it can be a pain to type these bits when creating a map by hand, but remember that we consider hand generation of maps a low priority. This format is primarily text due to the advantage this presents to universal support and infinite extensibility vs. the port lockdown and limitations inherent in the binary map format.
Tag in args[0] for Doom-style specials: I am not opposed to that at all. It makes a lot of sense actually because this is where Hexen specials store their tags. It would keep the whole tag vs. id issue from being so irritating. This barely requires any change to the specification.
Comments: I am in favor of them. CodeImp's cfg parser already handles them. I left them out only because it is impractical for most editor utilities to maintain them when rewriting the file. If CodeImp is not opposed, I will add support for at least single-line comments. Multiline comments, however, can be considered harmful due to their inability to nest. This would not override the inclusion of the comment field in blocks, however, since it CAN be maintained by editors, and as CodeImp notes, could actually be displayed in-editor as helpful info to the end user.
|
05-11-08 16:58 
