MLCad ~movedto buggy???

[Philippe Hurbain]

I just discovered that MLCad seems to ignore transformation matrix and origin offset when it "upgrades" older version parts!
Attached a sample file and the buggy result I get after "upgrade" and save with MLCad.
Now I am appaled
Did I miss something and is this a known bug?

[Stephen]

MLCad doesn't appear to ignore the transformation for me.

If I build a model now with a u9131.dat and 132-old.dat then I have to rotate 132-old.dat to get them to match, but presumably since there is a transformation in the current 132-old.dat then if I had built the model 5 years ago I wouldn't have needed that same rotation - all tyres would be 1 0 0 0 1 0 0 0 1 with the side of my "car" in MLCad's "front" view - as you get now with u9131.dat.

But if MLCad loads an old model now with the old part at 1 0 0 0 1 0 0 0 1 it then detects the new part (which is internally oriented differently from the old part) and if I allow it to "upgrade" the part it does apply the transformation from 132-old.dat which causes it to negate the internal rotation that took place when the part was originally changed.

Apologies if I've totally missed the point - this is more than a little confusing without access to how 132-old.dat presumably used to look before 2011 and with a model built back then. But answering "yes" or "no" to the "upgrade?" prompt does provide different results - so transformation is not being ignored (I didn't test with origin offset).

[Philippe Hurbain]

Indeed, I was not probably very clear. The problem is indeed that if I answer "yes" to "upgrade" I get a wrong result... If I answer no, the movedto file becomes a plain regular file, and the included transformation is properly done.

[Stephen]

In my mind answering "yes" to "upgrade" gives the correct result.

I'm assuming in the history of this tyre, whatever part number it has, the part's definition has internally been rotated at some point.

Answering "no" would give the wrong result - in the sense that viewing the old model with the old part number that now links to the new part but without the transformation applied (because you chose "no") means the tyre would face the wrong way.

The logic only looks wrong to me if you now create a new model and add 132-old.dat, since the first reload+upgrade of this model will flip the tyres the wrong way, but you're not supposed to be using the part on new models. The upgrade, I have assumed, is for fixing old models, and choosing "yes" seems to do what I'd expect.

[Philippe Hurbain]

Mmmhhh... headache now stronger!
According to me, testmoved.ldr above is the old file created before moved to. If I look at it using LDView, it looks right.
testmovedmlcad.ldr is the saved upgarded file in MLCad - and it does look wrong in LDView! So imho there IS a problem: "Upgrading" files gives breaks the file.

[Stephen]

According to me, testmoved.ldr above is the old file created before moved to. If I look at it using LDView, it looks right.
testmovedmlcad.ldr is the saved upgarded file in MLCad - and it does look wrong in LDView! So imho there IS a problem: "Upgrading" files gives breaks the file.

But testmoved.ldr presumably isn't really an old file in the sense of "old model". You've just created it, using the current incarnation of the parts library, right?

I think the MLCad upgrade process is for upgrading old models that used old parts, not new models using old parts whose definitions have been internally rotated in their more recent history. If you added 132-old.dat now to a model of a car whose side was visible in MLCad's "front" view you would need to rotate the tyre. But I don't think that would always have been the case with an earlier version of the parts library. We're trading the rotation from the upgrade process against the rotation that occurred in the past when the part was modified.

I think.

Mmmhhh... headache now stronger!

I know the feeling! I'm sending you my paracetamol bill ;-)

[Stephen]

Ok, having looked at this some more, I think you may be correct and my earlier assertion about how things are handled when a part has deliberately had its orientation changed in the past may not be correct. I created my own new part, used it in an "old" model, redefined the part with a ~moveto/rotation to keep compatibility, and nothing I do now will cause MLCad to display it correctly. But to be honest my head hurts and my brain can't take any more now, so depending on what anyone else here says, I may attempt the experiment again when/if my brain recovers.

[Philippe Hurbain]

Yes, I think we need fresh blood here

[Stephen]

It's no fun getting old. 20 years ago I would have had this one sussed in 5 minutes.

For what it's worth, I found an old lugnet post talking about a slightly earlier edition of MLCad that seems to confirm that MLCAD does indeed not honour the translation/rotation on a ~moveto, and the same probably still applies to 3.4.

[Magnus Forsberg]

To me everything looks to be correct.

The problem is that you might be tempted to "see" the current part "132-old" as being the same as the old part. It is not. The current file, the Moved to-file, shows a part in the same position as the old file, but you are actually looking at u9131.

Any model, new or old, containing a reference to the file "132-old.dat" is correctly being updated, and rotated, by MLCad if you answer Yes .

[Philippe Hurbain]

I don't undertand why the transformation matrix for u9131 (after upgrade) remains the same as it was for 132-old, despite different orientation ?!?

Why the same file, before and after "upgrade", look different (eg. with LDView)? imho they shouldn't!

[Magnus Forsberg]

Does this help?

Try inlining the line with 132-old.dat in your file testmoved.ldr.

1 7 0 0 0 1 0 0 0 1 0 0 0 1 132-old.dat

Code:

1 7 0 0 0 0 0 -1 0 1 0 1 0 0 u9131.dat

Then perform the rotation described in the Move to-file, 90 degrees around y-axis.

Code:

1 7 0 0 0 1 0 0 0 1 0 0 0 1 u9131.dat

The result will be the same as your file testmovedmlcad.ldr

[Philippe Hurbain]

Mmhhh... no, if I inline then apply movedto transformation (which, imho, means "apply twice the moved to transformation to u9131 - why twice???) I get this result, different from MLCad upgrade:

Code:

1 7 0 0 0 -1 0 0 0 1 0 0 0 -1 u9131.dat

Anyway, I have a file (testmoved.ldr) that looks good in LDView, LDCad, MLCad without performing upgrade or MLCad after performing upgrade before save/reload:

  testmoved.png (Size: 16.19 KB / Downloads: 2)
...but is plain wrong after "upgrade"/save/reload.

  testmovedmlcad.png (Size: 11.9 KB / Downloads: 2)

I am not so much concerned (yet) by the way to achieve correct result than by the wrong thing I see...

[Stephen]

I just changed this (removed irrelevant lines from this posting):

Code:

0 ~Moved to u9131
0 Name: 132-old.dat
1 16 0 0 0 0 0 -1 0 1 0 1 0 0 u9131.dat

into this:

Code:

0 ~Moved to 3001
0 Name: 132-old.dat
1 16 0 0 0 0 0 -1 0 1 0 1 0 0 u9131.dat

MLCad's "upgrade" turned my tyre into a brick. So it only appears to read the first line, see the "~Moved to", substitute the part number in the model, and totally dispense with the rest of the ~movedto file ignoring any type 1 record (colour, matrix translation/rotation, part number) that was defined.

I'm now having a hard time believing this approach could ever be considered fully correct, either for a part that now links to another part with a different rotation, or for a part that had it's origin/rotation changed in the past and an old model built before that change (although that case sure is confusing).

Sure it updates the part numbers to the correct modern parts, and works perfectly for parts that have identical origin/rotation, but that's all. I'm beginning to suspect that's all it was ever intended to do, and had development continued he would have eventually got around to processing the type 1. At the end of the day you don't need to upgrade, the old parts will always have an alias or ~movedto, but if you do upgrade then you probably need to manually fix some broken parts, which is what you've discovered.

[Philippe Hurbain]

Thanks Stephen for making this clear! the 3001 trick is a stroke of genius. So definitely DON'T UPGRADE old models...

[Stephen]

Well, I'm not sure I'd say "never" to an upgrade.

It's not something I've done (yet) but if I were resurrecting an old model (that prompted for upgrade) with the intention of spending some time enchancing it, I would probably elect to go for the upgrade purely to stop all the upgrade prompts every time I went to work on it. But I would save it under a new name and do a "diff" to see what changed, then manually visually inspect the changed parts for correctness

[Philippe Hurbain]

Fortunately there is a simpler and more automatic process: load file in MPDcenter -> Edit/update ~moved to reference -> save. But keeping old file and make a visual check remains a good practice...

[Magnus Forsberg]

And yet, it works somehow, anyway...
We do have many examples of moved and rotated parts, by Moved to-files.

I made a similar attempt to edit the Move to-file.
The first line is read, and a replacement is done. 3001 instead of u9131.
But the transformation matrix line seems to be only read the first time a new Moved to-file is found by MLCad. It is not possible to make it read it again. Any edited move to-file is ignored. LDview and LDCad do read the edited file and show a 'deformed' result.

Could it be that MLCad somehow records and remembers each new Move to-file?

Here are some more strange things MLCad does.

When I open MLCad, it performs a scan of my library. The file parts.lst is read, but also all the first lines of every header in my library. Any file with a updated/changed description placed in unofficial\parts is showed in MLCad as a useable part. Both parts will be usable if the old description is present in parts.lst even if you delete the old file from parts folder.

Try this. Create a new file 'abc.dat'. Give it the description "Blue box" and place a blue box-prim in it. Save it in the parts folder.
Add 'abc.dat' and 'Blue box' somewere in 'parts.list'
Place a copy of the file in unofficial\parts, but change colour of the box to red and add the word 'red' to the description. Open MLCad and you will find two parts called 'Blue box' and 'Blue box red', but you'll only see blue boxes.

Close MLCad and delete the file in parts folder. Reopen it and you will still see both parts, but now they are red.

It was earlier possible to edit the file mlcad.grp, but today it is obsolete. The information is stored inside the registry.

I know for a fact that it is impossble to remove, or move, the file 'stud.dat'. MLCad will simply stop working.

[Stephen]

For what it's worth, I wrote a script to find how many parts are affected and ran it on my parts directory (mostly six months or so out of date). Assuming the script to have no mistakes (always a possibility!) then of the 675 parts found with a ~moveto only 30 were affected.

Script (enclosed) looks for parts with a "~Moved to" containing any type 1 with non-standard matrix. It generates an LDR (enclosed, with slight positional improvements) with pairs of aligned parts (red=oldpart, green=newpart). Upgrading the LDR with MLCad 3.4 "breaks" the position of all the red upgraded parts, as shown in the jpegs (although not always clear from the 2D jpeg until you inspect it properly in 3D).

BEFORE UPGRADE:
   
AFTER UPGRADE:
   

[Chris Dee]

Yes these changes are deliberate. It was never intended that tools should infer anything from the description line. It is merely that - a description. The type 1 line and its transformation matrix must be processed by any tool seeking to replace a moved to file with its target. That way the results of a substitution should be identical to leaving the moved to file in the model and allowing the normal type 1 line processing to take place.

[Steffen]

+100

[Magnus Forsberg]

Why are you using the old partnumbers?

The problem is that you can not create a new file today using the old partnumbers and expect them to be unaffected by the Move to-files. If you today make a model using the old partnumber, you are infact using a "ghost" file, showing a part in the position of where it used to be. Your model will be affected by the Move to-file the next time you open it in MLCad.

If you want to use the old partnumber today, you need to "un-move" it. Revers the transformation matrix described in the Move to-file. If you then open that model in MLCad it will perform a "correct" replacement of that part.

MLCad will allway perform a correct transformation on any file contaning the old partnumbers.
It simply doesn't know if it is a new file, or an old file created prior to the creation of the Moved to-file.

[Philippe Hurbain]

I don't get your point, Magnus. There is no difference between a file created years ago and one created today?

The moved to transformation is done precisely to compensate for the changes made in the "recent" version of part, so that the old part is displayed the same way as it was when it did contained actual code instead of moved to code. And MLCad does show the part correctly, it's just the "upgrade" process that breaks things.

[Magnus Forsberg]

No, there is a difference.
The difference is that the same partnumber (132-old.dat) today only contains an instruction to move parts,
and a "ghost image" of where it used to be.

Maybe a picture will show it better:

   

[Roland Melkert]

I don't understand Magnus point ether, his above picture proves MLCad doesn't apply the 132-old.dat transformation as it should when doing an upgrade.

It's clearly just replacing the .dat reference while keeping the original transformation.

There are no old and or new parts there are only transformations. If you put an ~moved part in a new model it should only affect the BOM before and after the upgrade while visually remaining the same as the moved to transformation tells the parse (like any other reference) how to bring the target part into the local space of the current file.

[Magnus Forsberg]

I think I can understand you all.
The rotation matrix is unaffected by the information in in the Move to-file.

I'm only looking at the actual result.
Somehow MLCad is replacing partnumber '132-old' with 'u9131'. And a correct movement takes place.

The new file '132-old' now only contains information on how to replace it with 'u9131'.
You should not use the old partnumbers.