| |
In 973p11.dat the first line reads:
0 ~Moved to 973p1a, 973p1b, 973p1c
L3P can obviously handle this correctly, but my utility movedto.exe for one,
treats the input like this:
1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p11.dat
is altered to:
1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p1a, 973p1b, 973p1c.dat
Not very good...
Is there any spec supporting this strange usage?
Is it really LDraw compatible? Or will original LDraw and other renderers have
similar problems as my utilities?
/Tore
(Btw, how is it supposed to be interpreted???)
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In 973p11.dat the first line reads:
> 0 ~Moved to 973p1a, 973p1b, 973p1c
>
>
> L3P can obviously handle this correctly, but my utility movedto.exe for one,
> treats the input like this:
> 1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p11.dat
>
> is altered to:
>
> 1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p1a, 973p1b, 973p1c.dat
You are not supposed to actually use the information in the comment,
it's only informational.
The ~ tells mklist to ignore this part.
Just ignore the line, the following line type 1 will automatically redirect you to the new part.
/Lars
|
|
| |
In lugnet.cad, Lars C. Hassing wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > In 973p11.dat the first line reads:
> > 0 ~Moved to 973p1a, 973p1b, 973p1c
> >
> >
> > L3P can obviously handle this correctly, but my utility movedto.exe for one,
> > treats the input like this:
> > 1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p11.dat
> >
> > is altered to:
> >
> > 1 1 0 0 0 1 0 0 0 1 0 0 0 1 973p1a, 973p1b, 973p1c.dat
>
> You are not supposed to actually use the information in the comment,
> it's only informational.
When rendering Datsville, you'll recieve several hundreds of "Part n Moved moved
to nn" messages. It is totally necessary to find a way to eliminate them, so I
invented the movedto utility.
> The ~ tells mklist to ignore this part.
Yes, that's one of the uses for the "~Moved to..." statement.
> Just ignore the line, the following line type 1 will automatically redirect you to the new part.
Ignoring is not an option. There just has to be a way automatically replace
references to renamed files, especially considered the enormous rate of
renaming/renumbering official part. My method worked until this problem popped
up.
Btw, doesn't MLCad also have a feature to replace references to moved files? I
don't use MLCad, but doesn't multiple movedto argument mess things up for MLCad,
too?
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> > The ~ tells mklist to ignore this part.
>
> Yes, that's one of the uses for the "~Moved to..." statement.
>
> > Just ignore the line, the following line type 1 will automatically redirect you to the new part.
>
> Ignoring is not an option. There just has to be a way automatically replace
> references to renamed files, especially considered the enormous rate of
> renaming/renumbering official part. My method worked until this problem popped
> up.
There is: use the file referenced by the type 1 line in the MovedTo file.
> Btw, doesn't MLCad also have a feature to replace references to moved files? I
> don't use MLCad, but doesn't multiple movedto argument mess things up for MLCad,
> too?
Yes, MLCad messes this up as well. The problem is that you're using the 0
~MovedTo comment as a reference instead of the type 1 line in the file. 0
~MovedTo is a comment and not a META command and shouldn't be treated as such.
-Orion
|
|
| |
In lugnet.cad, Orion Pobursky wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > > The ~ tells mklist to ignore this part.
> >
> > Yes, that's one of the uses for the "~Moved to..." statement.
> >
> > > Just ignore the line, the following line type 1 will automatically redirect you to the new part.
> >
> > Ignoring is not an option. There just has to be a way automatically replace
> > references to renamed files, especially considered the enormous rate of
> > renaming/renumbering official part. My method worked until this problem popped
> > up.
>
> There is: use the file referenced by the type 1 line in the MovedTo file.
Sorry, I'm a little bit slow. Exactly how am I supposed to do that with
973p11.dat? And then make this a generic routine for a utility to handle
automatically?
>
> > Btw, doesn't MLCad also have a feature to replace references to moved files? I
> > don't use MLCad, but doesn't multiple movedto argument mess things up for MLCad,
> > too?
>
> Yes, MLCad messes this up as well. The problem is that you're using the 0
> ~MovedTo comment as a reference instead of the type 1 line in the file. 0
> ~MovedTo is a comment and not a META command and shouldn't be treated as such.
>
> -Orion
My opinion is that neither MLCad nor MovedTo.exe messes anything up. I think
it's the multiple MovedTo arguments that messes everything up, and the change of
its usage, be it just a comment or not. And not to mention to have rendering
code in a MovedTo file! It should be illegal. :)
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Orion Pobursky wrote:
> > In lugnet.cad, Tore Eriksson wrote:
> > > > The ~ tells mklist to ignore this part.
> > >
> > > Yes, that's one of the uses for the "~Moved to..." statement.
> > >
> > > > Just ignore the line, the following line type 1 will automatically redirect you to the new part.
> > >
> > > Ignoring is not an option. There just has to be a way automatically replace
> > > references to renamed files, especially considered the enormous rate of
> > > renaming/renumbering official part. My method worked until this problem popped
> > > up.
> >
> > There is: use the file referenced by the type 1 line in the MovedTo file.
>
> Sorry, I'm a little bit slow. Exactly how am I supposed to do that with
> 973p11.dat? And then make this a generic routine for a utility to handle
> automatically?
I had a look at 973p11.dat and I see what you mean. I'm not sure.
> >
> > > Btw, doesn't MLCad also have a feature to replace references to moved files? I
> > > don't use MLCad, but doesn't multiple movedto argument mess things up for MLCad,
> > > too?
> >
> > Yes, MLCad messes this up as well. The problem is that you're using the 0
> > ~MovedTo comment as a reference instead of the type 1 line in the file. 0
> > ~MovedTo is a comment and not a META command and shouldn't be treated as such.
> >
> > -Orion
>
> My opinion is that neither MLCad nor MovedTo.exe messes anything up. I think
> it's the multiple MovedTo arguments that messes everything up, and the change of
> its usage, be it just a comment or not. And not to mention to have rendering
> code in a MovedTo file! It should be illegal. :)
The rendering code is very neccessary. Not all LDraw programs automatically
detect the fact the a file ahas been moved. If there were no rending code the
the model could potentially have missing pieces.
-Orion
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In 973p11.dat the first line reads:
> 0 ~Moved to 973p1a, 973p1b, 973p1c
>
> Is there any spec supporting this strange usage?
> Is it really LDraw compatible? Or will original LDraw and other renderers have
> similar problems as my utilities?
Sorry, Tore, but this usage was unavoidable. This isn't a normal part-move, the
migration from 973p11 to 973p1a, 973p1b, and 973p1c is fixing an anomoly in the parts
library. 973p11 is coded so that the undecorated surfaces of the part are a fixed
color, and the patterned areas are variable-colored. The new files are code in the
normal manner -- the patterns are fixed-color, and the part is variable-colored.
At the time 973p11.dat was created, having a variable-colored pattern was considered
useful, because it allowed one part file to model 3 different patterns. However, in
every other case, in LDraw and outside of LDraw (for example, on Peeron), patterns
are treated as fixed-colored. Basically, 973p11.dat is incompatible with other parts
catalogs.
> (Btw, how is it supposed to be interpreted???)
The translation is like this: Look in the model file to see what color is being used
against 973p11.dat. Translate as follows:
black 973p11.dat --> white 973p1a.dat
blue 973p11.dat --> white 973p1b.dat
red 973p11.dat --> white 973p1c.dat
green 973p11.dat --> white 973p1j.dat
other 973p11.dat --> no translation possible
Unfortunately, that requires code in your part-move program to handle 973p11.dat (and
some earlier changes of the same nature, released in the last year or so).
Another thought for rendering datsville: delete all the WRITE lines out of the
moved-to stub files.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Tore Eriksson wrote:
>
> > In 973p11.dat the first line reads:
> > 0 ~Moved to 973p1a, 973p1b, 973p1c
> >
> > Is there any spec supporting this strange usage?
> > Is it really LDraw compatible? Or will original LDraw and other renderers have
> > similar problems as my utilities?
>
> Sorry, Tore, but this usage was unavoidable.
I do denifinitely no agree at all. (Did anybody expect me to? ;) )
> This isn't a normal part-move, the
> migration from 973p11 to 973p1a, 973p1b, and 973p1c is fixing an anomoly in the parts
> library. 973p11 is coded so that the undecorated surfaces of the part are a fixed
> color, and the patterned areas are variable-colored. The new files are code in the
> normal manner -- the patterns are fixed-color, and the part is variable-colored.
>
> At the time 973p11.dat was created, having a variable-colored pattern was considered
> useful, because it allowed one part file to model 3 different patterns. However, in
> every other case, in LDraw and outside of LDraw (for example, on Peeron), patterns
> are treated as fixed-colored. Basically, 973p11.dat is incompatible with other parts
> catalogs.
>
> > (Btw, how is it supposed to be interpreted???)
>
> The translation is like this: Look in the model file to see what color is being used
> against 973p11.dat. Translate as follows:
> black 973p11.dat --> white 973p1a.dat
> blue 973p11.dat --> white 973p1b.dat
> red 973p11.dat --> white 973p1c.dat
> green 973p11.dat --> white 973p1j.dat
> other 973p11.dat --> no translation possible
>
> Unfortunately, that requires code in your part-move program to handle 973p11.dat (and
> some earlier changes of the same nature, released in the last year or so).
>
> Another thought for rendering datsville: delete all the WRITE lines out of the
> moved-to stub files.
>
> Steve
Tell me you are not serious about that. Is that what we are supposed to
recommend all MLCad users when they stumble on this issue, as well as I have to
recommend it to any movedto.exe-users (if any)?
A far better solution had been to keep the 973p11.dat as base part but retitle
it to "~Minifig Torso with Dungarees Pattern", and then let p1a, p1b, p1c, and
p1j call on p11 with hardcoded colours, or, if that is impossible, with other
subparts. That shouldn't cause Peeron any problems, I think(?) AND, most
important, full backwards compability will be restored.
I suggest that these LDraw incompatible part be fixed to the next part update,
not the softwares that stumbles upon them.
/Tore
|
|
| |
"Tore Eriksson" <tore.eriksson@mbox325.swipnet.se> schrieb im Newsbeitrag
news:Hu4JnF.15r3@lugnet.com...
<SNIP>
> >
> > Yes, MLCad messes this up as well. The problem is that you're using the • 0
> > ~MovedTo comment as a reference instead of the type 1 line in the file. • 0
> > ~MovedTo is a comment and not a META command and shouldn't be treated as • such.
> >
> > -Orion
>
> My opinion is that neither MLCad nor MovedTo.exe messes anything up. I • think
> it's the multiple MovedTo arguments that messes everything up, and the • change of
> its usage, be it just a comment or not. And not to mention to have • rendering
> code in a MovedTo file! It should be illegal. :)
MLCad does not mess it up, but doesn't detect more levels yet. Indirectly
you get it done, if you load a model several time until no ~movedto parts
are used anymore :-)
Michael
|
|
| |
In lugnet.cad, Michael Lachmann wrote:
>
> "Tore Eriksson" <tore.eriksson@mbox325.swipnet.se> schrieb im Newsbeitrag
> news:Hu4JnF.15r3@lugnet.com...
> <SNIP>
> > >
> > > Yes, MLCad messes this up as well. The problem is that you're using the 0
> > > ~MovedTo comment as a reference instead of the type 1 line in the file. 0
> > > ~MovedTo is a comment and not a META command and shouldn't be treated as such.
> > >
> > > -Orion
> >
> > My opinion is that neither MLCad nor MovedTo.exe messes anything up. I think
> > it's the multiple MovedTo arguments that messes everything up, and the change of
> > its usage, be it just a comment or not. And not to mention to have rendering
> > code in a MovedTo file! It should be illegal. :)
>
>
> MLCad does not mess it up, but doesn't detect more levels yet. Indirectly
> you get it done, if you load a model several time until no ~movedto parts
> are used anymore :-)
>
> Michael
It did for me. When MLCad found the refernce to 973p11.dat and asked if I
wanted to upgrade, it changed all the "973p11.dat" references to "973p1a,.dat"
references. Note the ",".
-Orion
|
|
| |
> A far better solution had been to keep the 973p11.dat as base part but retitle
> it to "~Minifig Torso with Dungarees Pattern",
Sorry, skip the rest of the statement. No need to touch the parts with
hard-coded pattern (p1a, p1b, p1c, and p1j).
The un-orthodox moved to - remark can be altered to a genuine remark statement,
like this:
0 ~Minifig Torso with Dungarees Pattern
0 Name: 973p11.dat
0 Author: Chris Dee <chris_w_dee@hotmail.com>
0 (LDRAW_ORG Part UPDATE 2003-02)
0 REM Moved to 973p1a, 973p1b, 973p1c
and, of cousre likewise:
0 ~Minifig Torso with Futuron Pattern
0 Name: 973p15.dat
0 Author: Chris Dee (chris_w_dee@hotmail.com)
0 (LDRAW_ORG Part UPDATE 2003-03)
0 REM Moved to 973p1d, 973p1e
... and so on with 973p35.dat and 973p37.dat. Are there any more?
With these changes, everyone as well as all applications should be happy (I
hope...)
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> > A far better solution had been to keep the 973p11.dat as base part but retitle
> > it to "~Minifig Torso with Dungarees Pattern",
>
> Sorry, skip the rest of the statement. No need to touch the parts with
> hard-coded pattern (p1a, p1b, p1c, and p1j).
>
> The un-orthodox moved to - remark can be altered to a genuine remark statement,
> like this:
>
> 0 ~Minifig Torso with Dungarees Pattern
> 0 Name: 973p11.dat
> 0 Author: Chris Dee <chris_w_dee@hotmail.com>
> 0 (LDRAW_ORG Part UPDATE 2003-02)
> 0 REM Moved to 973p1a, 973p1b, 973p1c
>
> and, of cousre likewise:
>
> 0 ~Minifig Torso with Futuron Pattern
> 0 Name: 973p15.dat
> 0 Author: Chris Dee (chris_w_dee@hotmail.com)
> 0 (LDRAW_ORG Part UPDATE 2003-03)
> 0 REM Moved to 973p1d, 973p1e
>
> ... and so on with 973p35.dat and 973p37.dat. Are there any more?
>
> With these changes, everyone as well as all applications should be happy (I
> hope...)
>
>
> /Tore
Yes, I guess this would work. although I'd prefer to add "(Deprecated)" or
something similar to the title. I'm just dismayed that it has taken 7 months for
anyone to realise that this causes problems with the toolset.
The full list is :
973p11 ~Moved to 973p1a, 973p1b, 973p1c
973p15 ~Moved to 973p1d, 973p1e
973p35 ~Moved to 973p3n, 973p3q
973p37 ~Moved to 973p3r, 973p3s
973p4a ~Moved to 973p4n, 973p4q
973p65 ~Moved to 973p6b, 973p6c, 973p6d, 973p6e
I'll add these to the PT.
Chris
|
|
| |
In lugnet.cad, Chris Dee wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > > A far better solution had been to keep the 973p11.dat as base part but retitle
> > > it to "~Minifig Torso with Dungarees Pattern",
> >
> > Sorry, skip the rest of the statement. No need to touch the parts with
> > hard-coded pattern (p1a, p1b, p1c, and p1j).
> >
> > The un-orthodox moved to - remark can be altered to a genuine remark statement,
> > like this:
> >
> > 0 ~Minifig Torso with Dungarees Pattern
> > 0 Name: 973p11.dat
> > 0 Author: Chris Dee <chris_w_dee@hotmail.com>
> > 0 (LDRAW_ORG Part UPDATE 2003-02)
> > 0 REM Moved to 973p1a, 973p1b, 973p1c
> >
> > and, of cousre likewise:
> >
> > 0 ~Minifig Torso with Futuron Pattern
> > 0 Name: 973p15.dat
> > 0 Author: Chris Dee (chris_w_dee@hotmail.com)
> > 0 (LDRAW_ORG Part UPDATE 2003-03)
> > 0 REM Moved to 973p1d, 973p1e
> >
> > ... and so on with 973p35.dat and 973p37.dat. Are there any more?
> >
> > With these changes, everyone as well as all applications should be happy (I
> > hope...)
> >
> >
> > /Tore
>
> Yes, I guess this would work. although I'd prefer to add "(Deprecated)" or
> something similar to the title.
Never heard the word "deprecated" before, but I can guess its meaning from the
context. It's fine, "(Obsolete)" could maybe work too, but I don't care that
much about the words chosen, long as it doesn't interfer with any tools.
> I'm just dismayed that it has taken 7 months for
> anyone to realise that this causes problems with the toolset.
Once I thought I was quite good at English, but that was before I started hang
around in RTL. (It started with a correction of "of coarse"...) Now I've come to
realize of my limits. :) I guess dismayed - never heard that word either! -
means something like disappointed or surprised in a slightly negative way, and I
can understand your feelings.
Well, the Datsville project has been almost dead (from my side) for the past
part updates, until the very nice recent animation woke up my interest again. As
movedto.exe was born from the needs of Datsville and I rarely use it outside
Datsville, the problem was not discovered until I ran that utility just the
other day.
If I gave these files a Certify vote in te PT, I am highly co-responsible for
this problem...
>
> The full list is :
> 973p11 ~Moved to 973p1a, 973p1b, 973p1c
> 973p15 ~Moved to 973p1d, 973p1e
> 973p35 ~Moved to 973p3n, 973p3q
> 973p37 ~Moved to 973p3r, 973p3s
> 973p4a ~Moved to 973p4n, 973p4q
> 973p65 ~Moved to 973p6b, 973p6c, 973p6d, 973p6e
>
> I'll add these to the PT.
>
> Chris
Thanks Chris! I humbly suggest that the words "Moved to" can be changed into
"Replaced by" to avoid confusion, but I promise I will not be upset if the
suggestion is turned down.
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Chris Dee wrote:
> > Yes, I guess this would work. although I'd prefer to add "(Deprecated)" or
> > something similar to the title.
> Thanks Chris! I humbly suggest that the words "Moved to" can be changed into
> "Replaced by" to avoid confusion, but I promise I will not be upset if the
> suggestion is turned down.
"~Replaced by" is a good option. "Depecrated" is more meaningful to
computer-language geeks, but I think "~Replaced by" would do the job.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Tore Eriksson wrote:
> > In lugnet.cad, Chris Dee wrote:
> > > Yes, I guess this would work. although I'd prefer to add "(Deprecated)" or
> > > something similar to the title.
>
> > Thanks Chris! I humbly suggest that the words "Moved to" can be changed into
> > "Replaced by" to avoid confusion, but I promise I will not be upset if the
> > suggestion is turned down.
>
> "~Replaced by" is a good option. "Depecrated" is more meaningful to
> computer-language geeks, but I think "~Replaced by" would do the job.
I'd like to see us stick with "deprecated" if we possibly can. Even if we have
to explain it to E2L speakers, because it has a very precise meaning which is
just the meaning we want, I think.
|
|
| |
"Tore Eriksson" <tore.eriksson@mbox325.swipnet.se> schrieb im Newsbeitrag
news:Hu5oLv.Eu4@lugnet.com...
> Please have a look at my suggestion on how to solve this problem, and let • me
> know what you think:
> http://news.lugnet.com/cad/?n=11200
>
> /Tore
But this is just a workarround to avoid any message. It won't solve the
problem. I could imagine, doing a repetative check for moved parts, until I
do not find any newer ...
Michael
|
|
| |
In lugnet.cad, Chris Dee wrote:
>
> The full list is :
> 973p11 ~Moved to 973p1a, 973p1b, 973p1c
> 973p15 ~Moved to 973p1d, 973p1e
> 973p35 ~Moved to 973p3n, 973p3q
> 973p37 ~Moved to 973p3r, 973p3s
> 973p4a ~Moved to 973p4n, 973p4q
> 973p65 ~Moved to 973p6b, 973p6c, 973p6d, 973p6e
>
> I'll add these to the PT.
There's also
3846p43.dat ~Moved to 3846p45, 3846p46
|
|
| |
In lugnet.cad, Andrew Westrate wrote:
> In lugnet.cad, Chris Dee wrote:
> >
> > The full list is :
> > 973p11 ~Moved to 973p1a, 973p1b, 973p1c
> > 973p15 ~Moved to 973p1d, 973p1e
> > 973p35 ~Moved to 973p3n, 973p3q
> > 973p37 ~Moved to 973p3r, 973p3s
> > 973p4a ~Moved to 973p4n, 973p4q
> > 973p65 ~Moved to 973p6b, 973p6c, 973p6d, 973p6e
> >
> > I'll add these to the PT.
>
>
> There's also
> 3846p43.dat ~Moved to 3846p45, 3846p46
Thanks for finding that. I have submitted a fix to the Parts Tracker.
Chris
|
|
|
