LDraw.org Discussion Forums

Full Version: LDInspector
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
(2020-02-25, 21:37)Stefan Frenz Wrote: [ -> ]Thanks for testing and reporting. Hum, the "jdk-13.0.2.jdk/Contents/Home/bin/java" seems strange to me, it should read "jdk-13.0.2/bin/java". But the exception seems to be an independent issue, did you use the "last" version of LDInspector? Hum, this thread is messed Blush  up - I think it's in post #30... Big Grin

The JDK was placed there by the package installer from AdoptOpenJDK, so I left it there and just changed the pathname to match it (after several "no such directory" messages).

I'm pretty sure I used the LDInspector version from post #24 instead, so I will try the one from post #30. EDIT: Hey, that worked! Now to mess around with it a bit.  Smile
(2020-02-26, 21:07)N. W. Perry Wrote: [ -> ]The JDK was placed there by the package installer from AdoptOpenJDK, so I left it there and just changed the pathname to match it (after several "no such directory" messages).

I'm pretty sure I used the LDInspector version from post #24 instead, so I will try the one from post #30. EDIT: Hey, that worked! Now to mess around with it a bit.  Smile
Thanks for reporting - I checked the version in #24, and ooops. Blush  I'm sorry, that one was too buggy. Sad
I'm happy to read that it works with the one from #30, please let me know what you like, dislike, wish. Smile
(2020-02-26, 21:19)Stefan Frenz Wrote: [ -> ]Thanks for reporting - I checked the version in #24, and ooops. Blush  I'm sorry, that one was too buggy. Sad
I'm happy to read that it works with the one from #30, please let me know what you like, dislike, wish. Smile

Well, it's pretty slick, I can say. The UI is clean and everything works well—and at the same time, I get the idea there's a lot more I could be doing if I poked around some more. (Maybe some tooltips to explain the different functions would be helpful?)

So far, I've re-checked my OMR folder for compliance, after already checking it in MPDCenter, and while I didn't discover any new compliance issues, I did find a file error that I had missed—an embedded but unreferenced subfile that I'd fixed in my personal copy of the model but not in my OMR-ized version.

Incidentally, it also flagged my rigid (flex system) hoses as being non-rubber colored. That's intentional, since I feel like these parts are closer to the hard ABS plastic than to the softer, rubber-like "classic" hoses, but I admit that's a total guess since I don't own any of these parts in real life.  Tongue

Anyway, I look forward to unlocking more of the secrets of this tool. I have a feeling it's going to crop up often in the future, as I come across various tasks that I need to do, especially to a bunch of files at once.
(2020-02-27, 1:01)N. W. Perry Wrote: [ -> ]Incidentally, it also flagged my rigid (flex system) hoses as being non-rubber colored. That's intentional, since I feel like these parts are closer to the hard ABS plastic than to the softer, rubber-like "classic" hoses, but I admit that's a total guess since I don't own any of these parts in real life.  Tongue

Anyway, I look forward to unlocking more of the secrets of this tool. I have a feeling it's going to crop up often in the future, as I come across various tasks that I need to do, especially to a bunch of files at once.
Thanks a lot!  Smile

The rubber-color-checks are (hopefully!) marked as "hint" and have something "perhaps" in the message - that is just because I missed to change my wheel-rubber-color repeatedly. Me too having some parts with non-rubber-color by intention, so I just ignore my own hint. Wink  Ignoring my hint seems easier to me than not-forgetting to change the color. Big Grin

If you need to check OMR-compliance with a bunch of files at once: if you start LDInspector with filenames as parameters, there will be no GUI but the OMR-checks will be done for each given file with output to console. I use this in my (local) git repository before I commit "almost done" models. If you use my starter-script, just add "$@" at the end:
Code:
java -.... ldinsp.LDInspector "$@"

If there are other tasks that may fit your batch processing needs (e.g. export to OBJ format), please let me know - should be done easily.
(2020-02-27, 1:01)N. W. Perry Wrote: [ -> ]I did find a file error that I had missed—an embedded but unreferenced subfile that I'd fixed in my personal copy of the model but not in my OMR-ized version.
Speaking of embedded but not referenced files, when I tried to check my 42105 catamaran model, LDinspector issued a warning for the TEXMAP-able subfiles of the sails (66645as01/66645bs01)
(2020-02-27, 8:47)Philippe Hurbain Wrote: [ -> ]Speaking of embedded but not referenced files, when I tried to check my 42105 catamaran model, LDinspector issued a warning for the TEXMAP-able subfiles of the sails (66645as01/66645bs01)
Thanks for reporting. Smile

The mentioned parts are referenced in a meta/comment line like
Code:
0 !: 1 16 -0.25 0 0 -1 0 0 0 1 0 0 0 1 42105 - s\42105 - 66645as01.dat
Those are not evaluated by LDInspector so far (at the moment, I track only part-ref lines and the LDCad-specials like paths). I will try to find the TEXMAP-spec and try to include appropriate handling. Maybe next version. Wink
(2020-02-27, 9:51)Stefan Frenz Wrote: [ -> ]The mentioned parts are referenced in a meta/comment line like
Those are not evaluated by LDInspector so far
I guessed that Wink
As far as I understood the spec for the TEXMAP extension, the check would only require checking for lines starting with "0 !: 1 ... FILENAME" and handle them as "1 ... FILENAME". I've implemented this, now the checks result in "file ok" for the catamaran (thanks for pointing to that example!). Smile

The alternative would have been to search all comment/meta lines and therein count sub-part-filenames as "used". This would be extension-safe for all other extensions using file references, but it would (a) slow down the check and (b) also accidentally count files as used even if they are only used in real comments (for example after changing a reference and keeping the old one for history/user-information purpose as in this example). I've implemented this and removed it quickly as (b) came into mind... Wink 

So my question is: are there any other known extensions using file references, LDInspector should take care of?
The LDCad-specials should be taken care of already (thanks again for your help Roland!).
(2020-02-27, 13:11)Stefan Frenz Wrote: [ -> ]So my question is: are there any other known extensions using file references, LDInspector should take care of?
The LDCad-specials should be taken care of already (thanks again for your help Roland!).

No official META commands. Unofficial ones are not disallowed by the OMR but the correctness is on the author
Thanks! Smile
Ok, so I put the installer and jar-file on my private page with a link to this thread and the wiki. On the latter one I still would like to put the docu, how-to, use-cases etc. to enable others to edit them if they like to.
(2020-02-27, 8:47)Philippe Hurbain Wrote: [ -> ]Speaking of embedded but not referenced files, when I tried to check my 42105 catamaran model, LDinspector issued a warning for the TEXMAP-able subfiles of the sails (66645as01/66645bs01)
With the current version the catamaran should be rated "ok". Smile
(2020-02-27, 14:32)Stefan Frenz Wrote: [ -> ]With the current version the catamaran should be rated "ok". Smile
It does Cool
(2020-02-27, 14:30)Stefan Frenz Wrote: [ -> ]Ok, so I put the installer and jar-file on my private page with a link to this thread and the wiki. On the latter one I still would like to put the docu, how-to, use-cases etc. to enable others to edit them if they like to.

That's fine. Again, we can host, that's not a problem. However, it isn't preferred to make this a widespread practice as we do have limited space (not that we're close to exceeding it right now).
(2020-02-26, 19:42)Stefan Frenz Wrote: [ -> ]I got an account and played a bit - looks perfect. Smile So I will put all future how-to's, docus and up-to-date-files there.
I put some first content to the wiki and updated the snapshot version of LDInspector.

I must admit that it's too much text, I doubt anyone will read it. Wink  But there is also a first howto: how to get an inventory from Bricklink and post-process it. Thanks to the available gallery-slideshow this is much easier than creating an animated gif - and it's never too slow or too fast. Big Grin
I'm still finding that I have to either create a new workspace, or load a saved one, each time I open the program. Could there be one loaded by default, or have I not set it up correctly to do so? Does it need to be in the same directory as the .jar file? (And does that .jar file have to be inside the Java Virtual Machines directory in the "innards" of my system?)
(2020-03-02, 17:25)N. W. Perry Wrote: [ -> ]Does it need to be in the same directory as the .jar file? (And does that .jar file have to be inside the Java Virtual Machines directory in the "innards" of my system?)
Speaking for Linux/MacOS versions: if your starter file changes the directory to the one the jar-file is in, you have to put your LDInspector.ldi there. But if you set all Java-paths correctly (which I have no idea for MacOS), you may start LDInspector from any directory and have another LDInspector.ldi in each one. So it's up to your preferences: either change path to (any) directory or not, LDInspector will try to load it's configuration there. The time I had the Windows-test-machine, I couldn't get the batch file working successfully at the same time without parameters and with one or more parameters.

Maybe LDInspector could offer a command line option? Something like
Code:
java .... ldinsp.LDInspector -data PATH_AND_FILE.ldi
This would allow even for Windows to have multiple workspace configurations.

Shell I? Wink
(2020-02-25, 11:51)Willy Tschager Wrote: [ -> ]Fix movetos
The current version supports this one as well as setting author and license, either via "Quick-Fix" on the OMR-Check pane or via separate buttons on the newly invented Edit pane.

The other edit-features will take some more time...
(2020-02-09, 14:43)Orion Pobursky Wrote: [ -> ]there will be some crazy edge case
While looking at my code, again I thought about the filename check currently implemented in LDInspector. At the moment, the check searches for numbers at the filename beginning ("10246" of "10246 - Detectives Office.mpd"). But researching for sets containing not only digits, I found those crazy edge cases like set C001 (Star Wars Clock) or set EL136 (Dino Attack Minifigure).

What is the preferred way for LDInspector to check given filenames?

  1. Accept only numbers as set identifier: treat "C001 - Star Wars Clock.mpd" as "error" (current implementation).
  2. Hint/warn about possible wrong set identifier: treat "C001 - ..." as "ok", but hint/warn about possibly wrong set identifier (my favorite).
  3. Accept anything with space-dash-space as valid set identifier. This would treat "Star - Wars Clock.mpd" as "ok" accidentally (having "Star" as set identifier and "Wars Clock" as set name).

Thanks for sharing your votes.
2 Is my favorite too. When there is no clear and definitive option, allow the user to do what it wants, but warn for possible mistakes.
I added a separate Edit pane, but beware of the red buttons - they will change the underlying file immediately. Wink Additionally, now there are quick-fix buttons on the OMR-Check pane, they also will change the underlying file and re-check which will perhaps result in other/more/same buttons, as each tries to fix as fine-granular as possible - except for "Fix All".

Exclamation Exclamation  Please try the red buttons only with files which you don't need anymore or which are backed up. Exclamation Exclamation 

Said that, I would appreciate feedback for functionality, user interface, bugs, wishes. Link is the same to the current version. Smile
(2020-03-09, 8:28)Philippe Hurbain Wrote: [ -> ]2 Is my favorite too. When there is no clear and definitive option, allow the user to do what it wants, but warn for possible mistakes.
Thank you, done. Smile
(2020-02-25, 11:51)Willy Tschager Wrote: [ -> ]but I don't know how to:

Fix movetos
Inline unofficials with the correct OMR-nomenclatura
Fix description
Fix filename
Hi Willy,

the first official version 0.1 Big Grin  supports automatic fixing for those issues (and some more), and the current version also supports "repeated fix" to solve problems repeatedly until there is no more automatically fixable issue (this will become version 0.2 after including some more features which are not yet added to the "current" version).

I made two little howto's at the wiki: check for OMR compliance and fix OMR compliance issues.

The help/hint texts could be better and more informative, but hopefully with the automatic-fix-feature the hints are (a) not needed that much or (b) lead into the right direction. As always: any suggestion is warmly welcome.

Best regards
Stefan
Feature suggestion: How about a check for whether all referenced submodels (i.e., non-part files) are set to color 16?
(2020-03-19, 1:39)N. W. Perry Wrote: [ -> ]Feature suggestion: How about a check for whether all referenced submodels (i.e., non-part files) are set to color 16?
Would be a no-brainer. Smile  But I'm not sure about the benefit, and for example paths for hoses in LDCad are referenced with color and are implemented as ldr submodels with color 16...
(2020-03-19, 6:23)Stefan Frenz Wrote: [ -> ]Would be a no-brainer. Smile  But I'm not sure about the benefit, and for example paths for hoses in LDCad are referenced with color and are implemented as ldr submodels with color 16...

Well, I'm not sure either. It occurred to me as I spent about an hour going through my models after realizing that all of the subfiles were assigned to various colors despite not needing to be, since all colors are assigned inside the subfiles. On the other hand, they don't need not to be, either; and indeed, in some cases a subfile should be assigned a specific color. Perhaps it just appeals to those of us with an organizational nature. Smile

It would be a warning/suggestion check, rather than an error, of course. But maybe all I really wanted was the ability to select all submodels and/or assign all of them to a specific color (perhaps in LDCad's clean-up dialog).
Today I released version 0.2 as current version, main changes since 0.1 are:
  • Doing repeated-checks after name-change.
  • Added option to embed unofficial/all used parts.
  • Added clipboard functions to Edit pane.
  • Added direct links to online help and version-check.
  • Added direct links to source on Web pane.

Especially the Edit pane got major updates: part-ref replacement, inline parts and a (very basic) clipboard function that allows copying models from one file to another.

As always: all suggestions are warmly welcome, thanks for testing and reporting. Smile 
Best regards
Stefan
* install_lin.sh installs javafx-sdk-13.0.2 and jdk-13.0.2 then complaints that ldinsp.jar is missing.
* downlaoded ldinsp.jar as well but run didn't start up
* renamed ldinsp02.jar to ldinsp.jar and got the prog running.

w.
Thank you very much for reporting. To ensure I fully understand: you downloaded the installer without ldinsp.jar in the same directory, started the installer which failed, then downloaded ldinsp.jar, and it did not work? Indeed the correct run script is only created if ldinsp.jar is existing during install. Hmm. So if ldinsp.jar is not there yet, downloading afterwards without starting the install script again does not create the correct run script. Sad

As there is a downloadable jar at a fixed place since some time, the installer should download LDInspector instead of complaining it's not there! Blush I will update this.
(2020-04-04, 13:40)Stefan Frenz Wrote: [ -> ]I will update this.
That was easier than I thought. Smile  The current installer is tested to work on Linux with better behavior. Smile The windows installer is updated but untested as I don't have access to a Windows machine right now (will test later if  Cool nobody else is faster). and seems to work, too. Smile
(2020-03-20, 1:19)N. W. Perry Wrote: [ -> ]It would be a warning/suggestion check, rather than an error, of course. But maybe all I really wanted was the ability to select all submodels and/or assign all of them to a specific color (perhaps in LDCad's clean-up dialog).
Hi there,

the check is not implemented, but you can bulk-change referenced part colors with the current version on the Edit pane, which has a new line to change (all) color references to another one and a combined filter+set function. So if you have multiple references to a part (in the screenshot: "603-1 - sidecar.ldr"), you can filter the name and set the color (pay attention to the checkboxes on the right) and replace all colors to the selected one.

I know that this is not really what you wanted - the check is missing and there is no simple way to insert part names. I still have not an optimal feeling about setting all internal part (sub-model) references to color 16: the "parent" color during rendering does not makes sense to me here, and paths in LDCad are modeled in way that I like very much - but would prevent this type of change. If you really really really Wink  like to have this feature, I would invent a special NWPerry-button. Big Grin 

Best regards,
Stefan
(2020-03-03, 6:35)Stefan Frenz Wrote: [ -> ]Speaking for Linux/MacOS versions: if your starter file changes the directory to the one the jar-file is in, you have to put your LDInspector.ldi there. But if you set all Java-paths correctly (which I have no idea for MacOS), you may start LDInspector from any directory and have another LDInspector.ldi in each one.

This worked very easily; I just put the .ldi file next to the .jar file in the same directory, and it started right up without complaint.

I am also not too sure how best to change Java paths, and not sure it's worth researching. As long as I have my starter file in the Applications folder (after all, it is itself an application), I have no trouble locating the program.

Quote:Maybe LDInspector could offer a command line option? Something like
Code:
java .... ldinsp.LDInspector -data PATH_AND_FILE.ldi
This would allow even for Windows to have multiple workspace configurations.

Shell I? Wink

I can make it work either way, but that may well be useful to others. (For one thing, it would allow me to put my workspace back into the more logical Application Support directory, rather than deep in my system library where password authentication is required.)
(2020-04-04, 14:05)Stefan Frenz Wrote: [ -> ]Hi there,

the check is not implemented, but you can bulk-change referenced part colors with the current version on the Edit pane, which has a new line to change (all) color references to another one and a combined filter+set function. So if you have multiple references to a part (in the screenshot: "603-1 - sidecar.ldr"), you can filter the name and set the color (pay attention to the checkboxes on the right) and replace all colors to the selected one.

I know that this is not really what you wanted - the check is missing and there is no simple way to insert part names. I still have not an optimal feeling about setting all internal part (sub-model) references to color 16: the "parent" color during rendering does not makes sense to me here, and paths in LDCad are modeled in way that I like very much - but would prevent this type of change. If you really really really Wink  like to have this feature, I would invent a special NWPerry-button. Big Grin 

Best regards,
Stefan
 Honor though it would be, no need to go out of your way on my account.  Wink  But an exchange color feature seems handy regardless.
* The installation under win was smooth but you should add a note to the wiki in case the install.bat is stored in the program folder it has to be run with admin privileges.
* I'm still confused that something like the Workspace is positioned on the left border and not the items section I work with every day
* After setting workspace for the first time it should be automatically saved (to <user>\Appdata)at the closing of the dialog.


* I used [attachment=5062] for testing - which is pure hell.
* I do not like the fact that my file is overwritten right away and that no backup is created. I would prefer a Save button, which saves all the modification at the very end.
* I don't like the order how the checks are presented. A mirrored part to me is secondary, while a correct header is key.
* 0 FILE 364 - Harbour Scene - Warehouse - String.ldr has (among other things a license issue) The quickfix confirmed that a licences has been added but didn't show up in Source. I had to load another subfile and then reload the String to get rid of the error in the OMR-check
* My .mpd will never be OMRized because of: "error: file contains sub-parts, but filename does not end with .mpd"
* Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0
* Does not update .mpd content after unofficial files have been imported
* FIlename of imported unofficial files is wrong.
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "

w.
(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
Thank you very much for testing and reporting all the details, which I will look at as soon as possible. Also thank you for giving a hint for the model that is tested.

You mention the filename "s\364 - u[.]". In fact the imported files with leading pathnames I don't understand completely and therefore would assume, that the test therefore is not done correctly. With your hint, I would re-write this test and adopt the naming of inlined files.

The save-will-overwrite-thing doesn't convince me, either. I will have to completely re-design the GUI for file editing.
...had a closer look in the last days. Smile

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* The installation under win was smooth but you should add a note to the wiki in case the install.bat is stored in the program folder it has to be run with admin privileges.
* After setting workspace for the first time it should be automatically saved (to <user>\Appdata)at the closing of the dialog.
* I used 364 for testing - which is pure hell.
* I do not like the fact that my file is overwritten right away and that no backup is created. I would prefer a Save button, which saves all the modification at the very end.
* I don't like the order how the checks are presented. A mirrored part to me is secondary, while a correct header is key.
* 0 FILE 364 - Harbour Scene - Warehouse - String.ldr has (among other things a license issue) The quickfix confirmed that a licences has been added but didn't show up in Source. I had to load another subfile and then reload the String to get rid of the error in the OMR-check
I work on them, some are fixed in the current version. Especially mirrored parts are shown only once per subfile, so in your test case the output becomes readable.


(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* I'm still confused that something like the Workspace is positioned on the left border and not the items section I work with every day
I'm sorry: I believe that I didn't get your point. On the left side you can place the directories and/or files you work with every day. After selecting one file, you get all functions available at the moment. Or did you mean that the Item pane should be in the middle between the selection and the functions pane? Huh

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0
All unknown 0-lines are ignored, yes. Should there be another test to indicate non-OMR-meta lines?

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* FIlename of imported unofficial files is wrong.
Hum, I don't find one, so I guess I don't understand file constraints, yet. For example, the file "u9132c04.dat" is imported with header
Code:
0 FILE u9132c04.dat
0 ~Axle Steel  4 x  72 LDU with Two Wheels  6.4 x  8 with Tyres  3/100 x  8 Double Smooth
0 Name: u9132c04.dat
Could you please give me a hint what is wrong or what file is imported with wrong filename?

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* Does not update .mpd content after unofficial files have been imported
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
* My .mpd will never be OMRized because of: "error: file contains sub-parts, but filename does not end with .mpd"
I wasn't able to reproduce this behavior with the current version. Could you please send me the content of ldiver.txt file in your ldinsp.jar?

Thanks again for testing, I really appreciate your feedback. Smile 
Best regards - Stefan
I'll comment on the rest when I have a bit more time

(2020-04-12, 6:21)Stefan Frenz Wrote: [ -> ]I'm sorry: I believe that I didn't get your point. On the left side you can place the directories and/or files you work with every day. After selecting one file, you get all functions available at the moment. Or did you mean that the Item pane should be in the middle between the selection and the functions pane? Huh

[attachment=5090]

(2020-04-12, 6:21)Stefan Frenz Wrote: [ -> ]All unknown 0-lines are ignored, yes. Should there be another test to indicate non-OMR-meta lines?

Jepp!

w.
(2020-04-12, 6:21)Stefan Frenz Wrote: [ -> ]Hum, I don't find one, so I guess I don't understand file constraints, yet. For example, the file "u9132c04.dat" is imported with header
Code:
0 FILE u9132c04.dat
0 ~Axle Steel  4 x  72 LDU with Two Wheels  6.4 x  8 with Tyres  3/100 x  8 Double Smooth
0 Name: u9132c04.dat
Could you please give me a hint what is wrong or what file is imported with wrong filename?

https://www.ldraw.org/article/593.html#m..._structure

Unofficial parts are allowed to be used, but must be included in the MPD as referenced subfiles. The filename of the unofficial part is subject to the following naming rules:
Code:
<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat
Where:

Code:
<Set Number>
is the the number printed on the model's container.

Code:
<Optional Qualifier>
is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.

Code:
<Unofficial Part Number>
is the unofficial part number assigned in that very moment.
Example:

Code:
33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat

The OMRized version of the file above can be found here.

w.
Ah, now I got it! Big Grin  So the buttons will look like this in the next version:
[attachment=5092]

The check against additional meta-lines will be included, too.
Hum, hm, uh, yes. Angel  I have to admit: my statement was misleading. For OMR-models, the names have to be in the way described in your link, and hopefully the name check detects this correctly. On the Edit pane the "inline unofficial parts" is not OMR compliant as well as the "inline unofficial parts" on the OMR-check page, at least if it is not followed by the name-compliance-check. My idea was that inlining is separated from naming - inlining just does inlining, the name-check afterwards does (should do) the renaming to OMR-compliance.

After your explanation now I see that importing unofficial files without clear statement about the name is misleading for the user. I will add an option to either inline without name change or inline with OMR-prefixing. Thanks! Smile
(2020-04-12, 13:01)Stefan Frenz Wrote: [ -> ]The check against additional meta-lines will be included, too.
...just wanted to implement this, but I could not get a complete list of meta lines that are part of the OMR handling itself. In the official OMR model database I found for example the following ones:
Code:
0 !LDRAW_ORG Model
0 !HISTORY 2018-01-08 [bercik] OMR version by Robert Paciorek [bercik] with perrmision of juraj3579
0 !HISTORY 2015-10-28 [Philo] Subparted from Marc Klein initial design
0 //connhole
0 // History:
0 // 2000-05-07 [PTadmin] Official Update 2000-01
0 !KEYWORDS flexible, string, rope
0 UNOFFICIAL PRIMITIVE
0 !HELP Released under a dual license, you can choise "CCAL version 2.0" or "BSD/MIT-type licence":
0 !HELP This material is distributed WITHOUT any warranty, use at YOUR own risk.
0 NOFILE
and many LDCad/TEXMAP specific ones I would always treat as valid like the following ones:
Code:
0 !LDCAD CONTENT [type=spring] [addFallBack=default] [cRes=16] [cResLD=16] [cDia=14] [cRoll=0] [wRes=8] [wResLD=8] [wDia=0.5mm] [wCol=494] [sepMesh=false]
0 !LDCAD GENERATED [generator=LDCad 1.6b]
0 !TEXMAP START PLANAR 0 -34 -255 0 -34 34 0 500 -255 6209851bp01.png
Code:
0 !TEXMAP FALLBACK
Code:
0 !TEXMAP END

So it seems that only 0-lines are invalid, if they don't have "//" or "!" in front? In the above examples, that would be "UNOFFICIAL PRIMITIVE" and "NOFILE"?
Hi,
great to see something like this written in Java. Sadfully my Java skills are nearly null I am coding in vb.net.
There is mono out for use net applications under linux. I tried my first application also against mono. But at some point it was so much more effort to also get this running under linux additional to a non existing renderer that I could use also under linux, I did not do any more efforts in this.
Maybe it is just some little tuning necessary today (mono is developing) to get it to work, but I did not remember how I did that.
So I like to help in which way however.

cu
mikeheide
(2020-04-12, 20:20)Michael Heidemann Wrote: [ -> ]So I like to help in which way however.
Hi Mike,

thanks for your nice words and helping offer. I looked at MPDCenter to get it running way before this strange idea of writing my own tool for an ecosystem that I surely don't know enough about. I was just playing around with LDraw building some models for OMR and tried to reduce my mistake-frequence... Big Grin

Maybe it would be possible to get the source code of MPDCenter? I would like to try to understand what and how the checks are done there and compare the algorithm against mine. So eventually LDInspector may have some "MPDCenter-mode" with at least similar results. Wink

Best regards
Stefan
(2020-04-12, 12:21)Willy Tschager Wrote: [ -> ]The OMRized version of the file above can be found here.
The current LDInspector-version seems to be messed up completely in terms of filenames. Sad  Re-checking the prior working test cases like 31084 OMR just show the same "problem" (but it's root is clearly not in the file but in LDInspector). Seems like the "optimization and refactoring" was too optimistic. Sad

Another question arises: what should be done if the filename contains "-1" like in "31084-1 - xxx" but the inlined parts have prefix without "-1" like "31084 - xxx"? With the coming version, this will be treated as "ok"...?
Thanks for pointing at comment metas. In the official OMR database I found the file for 4565 which starts as following
Code:
0 FILE 4565 - main.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 main
0 Name: 4565 - main.ldr
0 Author: Robert Paciorek [bercik]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !HELP Copyright (c) 2002-2017, Robert Paciorek (http://www.opcode.eu.org/)
0 !HELP Released under a dual license, you can choise "CCAL version 2.0" or "BSD/MIT-type licence":
0 !HELP Redistribution and use in source or any others forms, with or without modification, ARE PERMITTED provided save information about author(s).
0 !HELP This material is distributed WITHOUT any warranty, use at YOUR own risk.

This completely breaks the current logic of meta handling in LDInspector: all versions up to the current one treat the first non-FILE-meta as description - which in this case leads to "!LEOCAD" instead of "main" as description.

This would not have come to my attention without the meta check. Smile Fixing this will take some more time...
In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.ht...ght=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.ht...ght=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...
(2020-04-13, 9:08)Stefan Frenz Wrote: [ -> ]In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.ht...ght=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.ht...ght=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...
This is the source I used for MPDCenter:
https://www.ldraw.org/article/47.html

In MPDCenter the 0 FILE or 0 NOFILE will just tell that a new file inside the mpd content file is starting/ending. Ignoring is not the best option but can result in the same result but it might be different.
cu
Mikeheide
(2020-04-13, 9:08)Stefan Frenz Wrote: [ -> ]In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.ht...ght=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.ht...ght=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...
As far as I can see you missed some basics.
If a file contains a 0 FILE line it is a mpd content file. If it does not contain a 0 FILE statement it is a plain ldraw file.
mpd content files are created because it was only possible to share your moc if you give all files you used to the next user. If you missed a single file, your model was broken. Just for unofficial or private made parts this was a mess. If we now add a 0 FILE in front of each single file and optional a 0 NOFILE at the end we can just combine those file by adding them (at that time this was done by console statements).
I hope this remembering is not too far away from real creation process Cool
(2020-04-13, 18:24)Michael Heidemann Wrote: [ -> ]As far as I can see you missed some basics.
Indeed! Smile  Thanks for helping out, especially the link to the "0 NOFILE" got me out of my messy thoughts. Smile
Hi Willy, hi all,

thanks again for your detailed notes.  Smile  Most of them I tried to handle for the current version which is online right now:

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* The installation under win was smooth but you should add a note to the wiki in case the install.bat is stored in the program folder it has to be run with admin privileges.
Done.

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* I'm still confused that something like the Workspace is positioned on the left border and not the items section I work with every day
Modified positioning. My first intention was to guide the new user from left to right in the tool bar, but you are right: most users will be used to have items left.

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* After setting workspace for the first time it should be automatically saved (to <user>\Appdata)at the closing of the dialog.
LDInspector now asks for configuration saving if it was started without configuration. At the moment the save dialog uses the "current directory" and not <user>\Appdata because I like the idea of having something portable. If LDInspector is "installed" on a portable medium like an USB stick, the configuration should go there in my oppinion.

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* I do not like the fact that my file is overwritten right away and that no backup is created. I would prefer a Save button, which saves all the modification at the very end.
I completely rewrote the concept of writing to files. The red buttons now do not overwrite the file, all changes are in memory until you activate "Save" button on the Item pane. This is much better, but I still don't like the current behavior of LDInspector to close or refresh without notice or confirmation if there is unsaved data. This needs some more work...

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* I don't like the order how the checks are presented. A mirrored part to me is secondary, while a correct header is key.
The mirror check is moved downwards and mirrors of the same part only take one line per sub-model, so output flooding as with LS60 in your example should be cured.

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* 0 FILE 364 - Harbour Scene - Warehouse - String.ldr has (among other things a license issue) The quickfix confirmed that a licences has been added but didn't show up in Source. I had to load another subfile and then reload the String to get rid of the error in the OMR-check
* My .mpd will never be OMRized because of: "error: file contains sub-parts, but filename does not end with .mpd"
* Does not update .mpd content after unofficial files have been imported
Double checked these three, but could not reproduce it with my current version.

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* FIlename of imported unofficial files is wrong.
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
I rewrote most of the code for filename checking and filename generating. Hopefully it is better starting with the current version!  Smile

(2020-04-08, 11:52)Willy Tschager Wrote: [ -> ]* Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0
I added a quick check for "unexpected" metas, but it only showed that I didn't understand the LDraw file format, yet.  Sad  So the current version does some checks, but the checks are not valid at the moment - instead they prove invalid file reading by the LDInspector LDraw parser. Especially unexpected meta lines before the description meta, but also even before the author meta breakes LDInspector edit code:

Code:
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
This breakes because LDInspector requires the first non-file-meta to be the description at the moment, so "!LEOCAD" is taken as description by accident. Even worse, the name tag is not written back correctly because my understand until last week  Blush  was that the header lines are always fixed. My only source of LDraw models is LDCad, which generates only very nice files. Smile Additionally, reading the article https://forums.ldraw.org/thread-23904.html makes me thinking of re-writing the case-sensitivity of my parser. Sad  I know, the file format is "grown historically", but making a difference between "0 FILE" and "0 File" depending on existence of other metas does not make me feel happy.

This leads to another substantial question: at the moment, LDInspector does only minimal change, i.e. writing a file will keep as many original lines as possible. Even correctly parsed files are not completely rebuild from the parsed structure but original source code will be inserted - for example to avoid floating point precision loss and to keep intentional formatting or comments. But with all those "special quirks" (with my understanding of last week) at least the meta handling has to be re-done. Even if all LDraw software would produce such nice files as LDCad does - "old files" should work with LDInspector, too. I would like to do the header parsing again, but at the moment I feel that I still don't understand all meta considerations.

Long story short: I will test some more officially released OMR files, but Willy's hint to un-OMR-ized 364 was extremely helpful. Smile  So if you have non-LDCad-files that should be "ok" or have still known issues and that break LDInspector in some way, they most likely will be very helpful, too.

Thanks for all your feedback helping me on my way towards LDInspector 0.3...  Wink
Pages: 1 2 3 4