Willy Tschager Wrote:As it stands now the only think to do is adding the images for CYLINDRICAL and SPHERICAL projection methods and copy'n'paste the whole thing to the specs.
I wish that were the case, but I do not belive that it is.
There are substantial problems with the current definition of TEXMAP NEXT. Please refer to the list of code snippets here and Joshua's response here.
All of those snippets were derived from contradictory information in the specification which must be rectified in order to produce a parser. Unfortunately, the "correct" behavior Joshua specified makes the situation even murkier. Metas are ignored in some cases but not in others. NEXT can even capture geometry outside the scope of an enclosing texture, meaning nested NEXTs do not necessarily nest in their behavior (that is, they need not form a stack). This is very bad.
Also, textures absolutely should not be able to cross a STEP. Attempting to rearrange the location of the STEP as Joshua suggested is also not viable. The scoping needs to be clarified that textures automatically end at STEP, FILE, or NOFILE.
Regretfully, it is simply not possible for me to implement the specified promiscuous behavior of NEXT without throwing away my entire parser and UI. The good news is that my issues with NEXT are very much edge cases. The bad news is that defining a viable NEXT is quite difficult. Imagine a future meta command:
0 !MULTI-LINE-META-THAT-DRAWS-STUFF
0 // <drawing commands>
0 !MULTI-LINE-META-THAT-DRAWS-STUFF END
(not really all that weird, since we're in the midst of discussing one exactly like that.)
Suppose you now want to put a MULTI-LINE-META-THAT-DRAWS-STUFF into a TEXMAP NEXT. How many lines of scope does the NEXT have?
Alas, you can't answer the question in the same way across a parser which is aware of MULTI-LINE-META-THAT-DRAWS-STUFF and one that isn't.
Travis has suggested solving this problem by making it an error (or a no-op) for any NEXT to be followed by a linetype 0. This would solve the problem, but strikes me as being rather inelegant. I personally think it would be better to completely discard NEXT. It saves a whopping one line of LDraw code, but trades it for a complicated definition and implementation.
* * * *
On a much more minor note:
The fact that nesting !: is illegal must be clarified, as nesting is a logical consequence of the wording of the current specification.
The fact that filenames containing double quotes must be escaped with a backslash needs to be added to the spec. The corollary that \ as a path separator must be escaped as \\ also needs to be added.
* * * *
Hopefully these issues can be addressed, as I am very excited about the prospect of finally getting a texture standard formalized and implemented.
Allen