\\ and \" are already in the UDMF specifications.
And yes ofcourse the tool that reads/writes the UDMF should perform the string escaping, it has always been that way.
But I don't understand what you mean by texture names should not use escape characters? They are just strings as well and for them the same rules apply. No parser is going to 'think' any different about them than that they are strings just like any other. So a texture named BLA"BLA must always be stored in the UDMF text as upper="BLA\"BLA"; Unless we make some exceptional notation for them, but that would be dirty IMO. Ofcourse, after a parser reads the UDMF text, it will unescape that string and return the value of the upper field normally as BLA"BLA. The same goes for textures with \ in their name and if we decide to use these other escape characters, it also goes or textures with a newline in their name (laugh, but it is possible).
DoomEdNumb > 32768
Moderator: GZDoom Developers
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: DoomEdNumb > 32768
Let's just hope it never happens...
Wanna bet that some port gets it wrong eventually?
Wanna bet that some port gets it wrong eventually?
Re: DoomEdNumb > 32768
OK so the consensus seems to be to just keep the grammar for string literals the same, and to define additional escape characters. I will work on this and post a 1.2 candidate specification in the DWF source ports forum.