+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDInspector (/thread-23882.html)
RE: LDInspector - N. W. Perry - 2020-02-26
(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 messedup - I think it's in post #30...
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.
RE: LDInspector - Stefan Frenz - 2020-02-26
(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).Thanks for reporting - I checked the version in #24, and ooops.
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.
I'm sorry, that one was too buggy. 
I'm happy to read that it works with the one from #30, please let me know what you like, dislike, wish.
RE: LDInspector - N. W. Perry - 2020-02-27
(2020-02-26, 21:19)Stefan Frenz Wrote: Thanks for reporting - I checked the version in #24, and ooops.
I'm happy to read that it works with the one from #30, please let me know what you like, dislike, wish.
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.
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.
RE: LDInspector - Stefan Frenz - 2020-02-27
(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.Thanks a lot!
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.
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.
Ignoring my hint seems easier to me than not-forgetting to change the color. 
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.
RE: LDInspector - Philippe Hurbain - 2020-02-27
(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)
RE: LDInspector - Stefan Frenz - 2020-02-27
(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.
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
RE: LDInspector - Philippe Hurbain - 2020-02-27
(2020-02-27, 9:51)Stefan Frenz Wrote: The mentioned parts are referenced in a meta/comment line likeI guessed that
Those are not evaluated by LDInspector so far
RE: LDInspector - Stefan Frenz - 2020-02-27
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!).
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...
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!).
RE: LDInspector - Orion Pobursky - 2020-02-27
(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
RE: LDInspector - Stefan Frenz - 2020-02-27
Thanks!
RE: LDInspector - Stefan Frenz - 2020-02-27
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.
RE: LDInspector - Stefan Frenz - 2020-02-27
(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".
RE: LDInspector - Philippe Hurbain - 2020-02-27
(2020-02-27, 14:32)Stefan Frenz Wrote: With the current version the catamaran should be rated "ok".It does
RE: LDInspector - Orion Pobursky - 2020-02-27
(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).
RE: LDInspector - Stefan Frenz - 2020-02-28
(2020-02-26, 19:42)Stefan Frenz Wrote: I got an account and played a bit - looks perfect.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.
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.
RE: LDInspector - N. W. Perry - 2020-03-02
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?)
RE: LDInspector - Stefan Frenz - 2020-03-03
(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.ldiShell I?
RE: LDInspector - Stefan Frenz - 2020-03-04
(2020-02-25, 11:51)Willy Tschager Wrote: Fix movetosThe 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...
RE: LDInspector - Stefan Frenz - 2020-03-09
(2020-02-09, 14:43)Orion Pobursky Wrote: there will be some crazy edge caseWhile 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?
- Accept only numbers as set identifier: treat "C001 - Star Wars Clock.mpd" as "error" (current implementation).
- Hint/warn about possible wrong set identifier: treat "C001 - ..." as "ok", but hint/warn about possibly wrong set identifier (my favorite).
- 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.
RE: LDInspector - Philippe Hurbain - 2020-03-09
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.
RE: LDInspector - Stefan Frenz - 2020-03-10
I added a separate Edit pane, but beware of the red buttons - they will change the underlying file immediately.
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".
Please try the red buttons only with files which you don't need anymore or which are backed up. Said that, I would appreciate feedback for functionality, user interface, bugs, wishes. Link is the same to the current version.
RE: LDInspector - Stefan Frenz - 2020-03-10
(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.
RE: LDInspector - Stefan Frenz - 2020-03-16
(2020-02-25, 11:51)Willy Tschager Wrote: but I don't know how to:Hi Willy,
Fix movetos
Inline unofficials with the correct OMR-nomenclatura
Fix description
Fix filename
the first official version 0.1
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
RE: LDInspector - N. W. Perry - 2020-03-19
Feature suggestion: How about a check for whether all referenced submodels (i.e., non-part files) are set to color 16?
RE: LDInspector - Stefan Frenz - 2020-03-19
(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.
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...
RE: LDInspector - N. W. Perry - 2020-03-20
(2020-03-19, 6:23)Stefan Frenz Wrote: Would be a no-brainer.
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.
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).
LDInspector version 0.2 - Stefan Frenz - 2020-04-01
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.
Best regards
Stefan
RE: LDInspector version 0.2 - Willy Tschager - 2020-04-04
* 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.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-04
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.
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!
I will update this.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-04
(2020-04-04, 13:40)Stefan Frenz Wrote: I will update this.That was easier than I thought.
The current installer is tested to work on Linux with better behavior. The windows installer is updated but untested as I don't have access to a Windows machine right now (will test later if nobody else is faster). and seems to work, too.
RE: LDInspector - Stefan Frenz - 2020-04-04
(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
like to have this feature, I would invent a special NWPerry-button. Best regards,
Stefan
RE: LDInspector - N. W. Perry - 2020-04-04
(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
This would allow even for Windows to have multiple workspace configurations.Code:java .... ldinsp.LDInspector -data PATH_AND_FILE.ldi
Shell I?
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.)
RE: LDInspector - N. W. Perry - 2020-04-05
(2020-04-04, 14:05)Stefan Frenz Wrote: Hi there,Honor though it would be, no need to go out of your way on my account.
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
Best regards,
Stefan
But an exchange color feature seems handy regardless.
RE: LDInspector version 0.2 - Willy Tschager - 2020-04-08
* 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
364 - Harbour Scene.mpd (Size: 124.93 KB / Downloads: 4)
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.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-08
(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.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-12
...had a closer look in the last days.
(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.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.
* 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
(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 dayI'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?
(2020-04-08, 11:52)Willy Tschager Wrote: * Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0All 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(2020-04-08, 11:52)Willy Tschager Wrote: * Does not update .mpd content after unofficial files have been importedI 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?
* 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"
Thanks again for testing, I really appreciate your feedback.
Best regards - Stefan
RE: LDInspector version 0.2 - Willy Tschager - 2020-04-12
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?
(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.
RE: LDInspector version 0.2 - Willy Tschager - 2020-04-12
(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
Could you please give me a hint what is wrong or what file is imported with wrong filename?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
https://www.ldraw.org/article/593.html#mpd_file_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>.datCode:
<Set Number>Code:
<Optional Qualifier>Code:
<Unofficial Part Number>Example:
Code:
33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.datThe OMRized version of the file above can be found here.
w.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-12
Ah, now I got it!
So the buttons will look like this in the next version:The check against additional meta-lines will be included, too.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-12
Hum, hm, uh, yes.
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!
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-12
(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 NOFILECode:
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.pngCode:
0 !TEXMAP FALLBACKCode:
0 !TEXMAP ENDSo 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"?
RE: LDInspector - Michael Heidemann - 2020-04-12
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
RE: LDInspector - Stefan Frenz - 2020-04-13
(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...
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.
Best regards
Stefan
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13
(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.
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. 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"...?
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13
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.
Fixing this will take some more time...
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13
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
... Now I'm lost completely. There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=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.
Can anyone help me with this?
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...
RE: LDInspector version 0.2 - Michael Heidemann - 2020-04-13
(2020-04-13, 9:08)Stefan Frenz Wrote: In this file there are quite some more interesting lines that I don't understand.This is the source I used for MPDCenter:
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.html?highlight=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.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
...
There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=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.
Can anyone help me with this?
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
RE: LDInspector version 0.2 - Michael Heidemann - 2020-04-13
(2020-04-13, 9:08)Stefan Frenz Wrote: In this file there are quite some more interesting lines that I don't understand.As far as I can see you missed some basics.
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.html?highlight=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.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
...
There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=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.
Can anyone help me with this?
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
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13
(2020-04-13, 18:24)Michael Heidemann Wrote: As far as I can see you missed some basics.Indeed!
Thanks for helping out, especially the link to the "0 NOFILE" got me out of my messy thoughts.
RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-14
Hi Willy, hi all,
thanks again for your detailed notes.
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 dayModified 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-checkDouble checked these three, but could not reproduce it with my current version.
* 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
(2020-04-08, 11:52)Willy Tschager Wrote: * FIlename of imported unofficial files is wrong.I rewrote most of the code for filename checking and filename generating. Hopefully it is better starting with the current version!
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
(2020-04-08, 11:52)Willy Tschager Wrote: * Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0I added a quick check for "unexpected" metas, but it only showed that I didn't understand the LDraw file format, yet.
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 was that the header lines are always fixed. My only source of LDraw models is LDCad, which generates only very nice files. Additionally, reading the article https://forums.ldraw.org/thread-23904.html makes me thinking of re-writing the case-sensitivity of my parser. 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.
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...