by Quasar » Sun May 31, 2009 5:09 pm
What you said about special numbers and trying to stay within the range of 255 raises an important issue which I was touching upon in the previous post. If EE and ZDoom will cooperate on a higher level spec for establishing Hexen-based lines and some common extensions within UDMF, we'll need a way to decide where the extensions will fit in the future should we decide to share more common functionality beyond the initial specification.
To me it's not important that any EE specials get crammed into the 0-255 range so you pretty much have freedom over that guaranteed
EE is going to freeze the Doom map format, and will consider the Hexen map format deprecated for purposes of making new maps. UDMF is going to be the "one way to the light" as far as EE editing goes in the future. We participated in defining this spec in order to put away problems like ExtraData and all the old BOOM hacks, so I feel justified in encouraging its use in any way possible, even if that encouragement might be construed as forceful to some extent
While I have your attention about UDMF-related things, there is an extension to the syntax which I believe would be very useful in general for expansions that need syntax that's not covered by the UDMF grammar (which was intentionally kept to the bare minimum, as you already know). This extension, heredocs, was already implemented in Eternity's EDF parser some time ago, and works like this:
Code: Select all
someblock
{
fieldname =
@"
Anything can be typed inside here. "" {} / \ * + () ; ; ;
It is multilined and everything within is interpreted literally
with no translation or syntactic evaluation.
"@
}
The syntax which EE uses for heredocs was adopted from the Windows Powershell language (IIRC anyway); languages which support them all have different syntax, but the @" "@ delimiters are what worked best in EDF. The important property of heredocs, as mentioned above, is that they support long, multiline literals that contain ordinarily reserved characters. They are also relatively easy to parse, requiring only a single character of look-ahead to check for the @ after any quotation mark found within. Other than that, their tokenization tends to be similar to but simpler that needed by ordinary string literals.
Some things we are planning EE could strongly benefit from the ability to embed such literals. If you think it's a good idea, we could talk to CodeImp and see if it can be put into a UDMF 1.2 specification. Lemme know what you think.
What you said about special numbers and trying to stay within the range of 255 raises an important issue which I was touching upon in the previous post. If EE and ZDoom will cooperate on a higher level spec for establishing Hexen-based lines and some common extensions within UDMF, we'll need a way to decide where the extensions will fit in the future should we decide to share more common functionality beyond the initial specification.
To me it's not important that any EE specials get crammed into the 0-255 range so you pretty much have freedom over that guaranteed ;) EE is going to freeze the Doom map format, and will consider the Hexen map format deprecated for purposes of making new maps. UDMF is going to be the "one way to the light" as far as EE editing goes in the future. We participated in defining this spec in order to put away problems like ExtraData and all the old BOOM hacks, so I feel justified in encouraging its use in any way possible, even if that encouragement might be construed as forceful to some extent :)
While I have your attention about UDMF-related things, there is an extension to the syntax which I believe would be very useful in general for expansions that need syntax that's not covered by the UDMF grammar (which was intentionally kept to the bare minimum, as you already know). This extension, heredocs, was already implemented in Eternity's EDF parser some time ago, and works like this:
[code]
someblock
{
fieldname =
@"
Anything can be typed inside here. "" {} / \ * + () ; ; ;
It is multilined and everything within is interpreted literally
with no translation or syntactic evaluation.
"@
}
[/code]
The syntax which EE uses for heredocs was adopted from the Windows Powershell language (IIRC anyway); languages which support them all have different syntax, but the @" "@ delimiters are what worked best in EDF. The important property of heredocs, as mentioned above, is that they support long, multiline literals that contain ordinarily reserved characters. They are also relatively easy to parse, requiring only a single character of look-ahead to check for the @ after any quotation mark found within. Other than that, their tokenization tends to be similar to but simpler that needed by ordinary string literals.
Some things we are planning EE could strongly benefit from the ability to embed such literals. If you think it's a good idea, we could talk to CodeImp and see if it can be put into a UDMF 1.2 specification. Lemme know what you think.