LDraw.org Discussion Forums

Full Version: Scoping rules for TEXMAP
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This is a proposal for changing the scoping rules for TEXMAP:

Add bolded text:
Quote:This texture will remain in effect until:
  • An END is given within the current file
  • The file in which the START is located ends
  • A STEP command is reached
The texture will remain active when processing an included file unless overridden within that file.

and change:
Quote:The END command stops using the current texture and restores the previous texture to current status. This means that nested commands with START will form a stack of textures and the END command will pop those textures. However, END cannot appear in a different file from START. If an END command is given in a sub file without a START having been given in that same file, the END stops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exitedhas no effect.

These scoping changes are critically important to implementing a hierarchical, object-oriented model to textures. It will be impossible for me to implement the standard as it currently exists. I already have a working implementation of the changes described above (*).


(*) with the exception of the stack behavior for nested textures, which is a simple enough addition
Seems logical to me, otherwise subfiles seem to be 'aware' of their callers, very bad object oriented behavior indeed. It also makes reusing such files weird in a strictly LDraw manner.
Does anyone else have input on this issue? I will call for votes in the next few days if I don't hear anything.

I think this may have been discussed before, but my memory is mush with respect to TEXMAP. Please give me a chance to look through the old discussions to see.

I'm happy with your proposed changes.
I'm fine with this change. However, now that we are deviating from the base spec provided to us, we need to make sure that it is clear that this is LDRaw.org's fork of the spec and not Joshua's
My goal has always been to simply clean up the sticky edge cases in this otherwise nice design. Unfortunately, there was no venue to do so beforehand. Joshua even seemed unsure how to interpret the specification himself on some of the stickiest edge cases. I am unaware of any means of dialogue with the parties responsible for the implementation Joshua advocates, nor am I aware of any way to even view or interact with their work.

In any event, it is impossible for me to implement this particular behavior as given, and I would suspect it to be similarly impossible (or immensely onerous) for anyone else to implement it. Since it would be quite peculiar for anyone to try and take advantage of the behavior as written, there isn't really a lot of harm in changing it either.

There is at least one other spec deficiency which must be corrected: the angle units on the other two texture types:
Hopefully the original developers step forward to answer this, or else we're just going to have to pick something.

I privately asked Joshua about these suggested changes, and he said they were OK.