LDInspector


LDInspector
#1
Hi there,

first of all, I would like to say my thanks to Roland for LDCad and to Philippe, Willy, Johann and Magnus for helping me out drawing models and making them OMR compliant.

After making the same mistakes multiple times and because I don't get MPDCenter running on my Linux box, I wrote a small Java tool to:
  • inspect and preview ldr/mpd files, list/preview sub-files
  • check OMR-compliance and some subtle things (like tires having Rubber color)
  • organize part lists (pbg import / export and generated from ldr/mpd files)
  • get part lists from Bricklink and Rebrickable with preview and pbg export
  • compare part lists of arbitrary source
  • search parts by description / filename / origin
I don't know if this software would be of any interest to the community. It is in some kind of early pre-alpha state, but if there are brave testers, I would be happy to get feedback or just "does not work" messages. Maybe it even helps other Linux-LDrawers to get their files OMR compliant? The gui requires JavaFX (see here), everything else is "plain Java" (version >=11).

Any suggestion or feedback is warmly welcome.

Best regards
Stefan

PS: If this is the wrong forum, please Administrator move it to another one.


Attached Files Thumbnail(s)
                       

.gif   LDI_CheckCmd.gif (Size: 24.3 KB / Downloads: 592)
Reply
RE: LDInspector
#2
Attached is today's snapshot jar (renamed to "zip" because the board does not allow jar-files; please rename to "ldinsp.jar" before using it). You'll need OpenJDK >=11 and JavaFX >=11 (at least the three libraries base, controls and graphics). To start the GUI, just enter:

Code:
java --module-path ldinsp.jar:javafx.base.jar:javafx.controls.jar:javafx.graphics.jar -m LDInspector/ldinsp.LDInspector

On the first start, there will be an example context configuration allowing some basic things. To have the "real" function, you'll need to "Config." the Workspace with an official and/or unofficial directory or zip file. If you would like to test the web functionality, you may enter a web cache prefix (which is best using a sub-directory), so all web files are stored locally and therefore are loaded only once. Then the configuration may be saved, and if the filename is LDInspector.ldi in the currently active directory, it will be used as configuration for future starts.

As mentioned above, it is in pre-alpha state.  Angel

Please use the updated versions below, this version is kept for discussion history reasons only.


Attached Files
.zip   ldinsp.zip (Size: 345.91 KB / Downloads: 6)
Reply
RE: LDInspector
#15
(2020-02-07, 22:16)Stefan Frenz Wrote: As mentioned above, it is in pre-alpha state.  Angel
There was a bug in configuration saving that prevented a configured web cache path to be loaded on restart. Attached is a fixed version that also includes a "load all images" button in web view to ease part identification.

Please use the updated versions below, this version is kept for discussion history reasons only.


Attached Files
.zip   ldinsp.zip (Size: 352.75 KB / Downloads: 3)
Reply
RE: LDInspector
#3
I could definitely see making use of a tool like this myself. I can run MPDCenter all right, but I have found it a little glitchy and wouldn't mind an alternative. So maybe I'll take a look at yours when I have occasion to check some files.

One thing to note, I see that you test for the optional qualifier in an OMR filename and that it's only required if greater than 1. However, according to the OMR spec, that's only true for the base MPD filename; for its subfiles, the qualifier is required even when it would be 1. (That seems weird and is probably just a discrepancy in the specification, but that's how it currently reads.)
Reply
RE: LDInspector
#4
(2020-02-08, 5:39)N. W. Perry Wrote: One thing to note, I see that you test for the optional qualifier in an OMR filename and that it's only required if greater than 1. However, according to the OMR spec, that's only true for the base MPD filename; for its subfiles, the qualifier is required even when it would be 1. (That seems weird and is probably just a discrepancy in the specification, but that's how it currently reads.)
Thanks for the hint. Smile  To be honest, now I'm completely lost. Huh If I understood your point correctly, the filename would be without "-1" (e.g. "123 - Setname.mpd"), but all the subfile names in this mpd would be with "-1" (e.g. "123-1 - Left Hose.ldr").

Some time ago ™ I thought having "-1" everywhere is a good idea: it would sync the numbers with Bricklink and Rebrickable, where "-1" is always present even for the first model (as far as I know). On my attempt creating the fire boat 4025 (see here), Johann explained OMR rules and OMRized my file (thank you very much!): the "-1" is removed everywhere, what I think is consequent and corresponds perfectly to the spec. In fact, another check done by my program is "are all numbers at the start of filename and subfile-names identical", which I treat being very reasonable.

For the subfiles I understand the spec (here
Code:
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.
that the "-1" would be required if there is another set with that number, but not added if there is no other set with that number. So at the time of modelling the first set, it seems to be kind of "not forbidden" and "not required" (how could I know if there would be another set with that number in the future?). It well may be another misunderstanding of mine. Blush I will happily adopt the check as soon as I have a new understanding. Wink 

I'm still a newbie here and I think the specification is done with many things in mind that I don't know and I am not aware of. And my English is not the very best, so another source of misunderstanding appears... Nevertheless, at this moment I would prefer an "-1" rule like "The -1 may be added or skipped for the first model, but the file and all its subfiles should be numbered consistently".

Said all that, I have the feeling that the "-1" seems to be not that critical: even my "-1" files are uploaded "as is" (thank you!). So my program reports the "-1" as hint and not as an error. Smile
Reply
RE: LDInspector
#7
Could it be that the confusion comes from the fact that we are using the same suffix to describe different situations?

I see mainly three situations
1.)
The same setnumer is used on different markets.
347-1, Fire station, European version
347-2, Basic Building Set
347-3, Hospital - Lucy Lamb and Charlie Cat Visit Dr. Dog, European version of 137-1
347-4, Fire station, US version

2.)
The same set is used to build more than one, different models. Mainly Technic or 3in1 sets.
42079-1,  A-model, Forklift
42079-2,  B-model, Towing truck

3.)
The same set contains more than one model.
75893-1,  build 1, Dodge Challenger
75893-2,  build 2, Starter lights "christmas tree"
75893-3,  build 3, Dodge Charger

Another confusion is that we don't use the same suffix, like Bricklink or Brickset use it.

A third confusion is that we don't use the same term to describe the same thing.
There's a big difference between a submodel and a sub assembly.
Reply
RE: LDInspector
#9
(2020-02-08, 11:20)Magnus Forsberg Wrote: I see mainly three situations
Thanks for this! In fact I always had focused on your first situation.

Your second situation seemed to me always being "same number with name extension" like in 31084:
31084-1 - Pirate Roller Coaster.mpd  => main model
31084-1 - Pirate Roller Coaster - Ship ride.mpd => alternate build
31084-1 - Pirate Roller Coaster - Skull ride.mpd => another alternate build
I'm pretty happy with this naming scheme.

Your third situation I've lost completely, but I thought this would be identical to the second point without having a "main" model like in 42023:
42023-1 - Construction Crew - Dump Truck.mpd => one of three vehicles: the dump truck
42023-1 - Construction Crew - Excavator.mpd => one of three vehicles: the excavator
42023-1 - Construction Crew - Wheel Loader.mpd => one of three vehicles: wheel loader
I'm happy with this naming scheme, although I admit that it's not clear if all models together are in the set or if these are alternate builds and the main model is not modeled yet. But I would strongly prefer the way done for 42023 with all having the same number.


(2020-02-08, 11:20)Magnus Forsberg Wrote: There's a big difference between a submodel and a sub assembly.
Indeed I have never thought of the difference between sub model and sub assembly. Thanks again! My files are not too complex yet, so I think I always have only used sub assembly so far - except for my compilation of Knight's Castle and Shell Mini Bags with several models in one file.
Reply
RE: LDInspector
#10
(2020-02-08, 15:37)Stefan Frenz Wrote: Your third situation I've lost completely, but I thought this would be identical to the second point without having a "main" model like in 42023:
42023-1 - Construction Crew - Dump Truck.mpd => one of three vehicles: the dump truck
42023-1 - Construction Crew - Excavator.mpd => one of three vehicles: the excavator
42023-1 - Construction Crew - Wheel Loader.mpd => one of three vehicles: wheel loader
I'm happy with this naming scheme, although I admit that it's not clear if all models together are in the set or if these are alternate builds and the main model is not modeled yet. But I would strongly prefer the way done for 42023 with all having the same number.

I don't know what the specs say, but I would say that it is wrong.

IMHO, it should be like this.
42023-1 - Construction Crew - Assembly.MPD (containing all three models)
42023-1 - Construction Crew - Dump Truck.LDR
42023-1 - Construction Crew - Excavator.LDR
42023-1 - Construction Crew - Wheel Loader.LDR

Note the difference in the file endings.
Reply
RE: LDInspector
#11
(2020-02-08, 17:34)Magnus Forsberg Wrote: IMHO, it should be like this.
42023-1 - Construction Crew - Assembly.MPD (containing all three models)
42023-1 - Construction Crew - Dump Truck.LDR
42023-1 - Construction Crew - Excavator.LDR
42023-1 - Construction Crew - Wheel Loader.LDR
Ah, thanks! Smile  Although I had assumed that nowhere the "-1" should appear and the main file containing all three models should be without the " - Assembly", otherwise it could be a secondary model, couldn't it? And as far as I understand the spec, the set name should not appear for all sub-files in an mpd? Summing up, I would have assumed that:
  • the filename is "42023 - Construction Crew.mpd",
  • in this mpd file the first sub-file is the main sub-file named "42023 - Main.ldr",
    • the main sub-file has exactly three part-ref-lines to the three sub-models,
  • the sub-models are modeled each in separate sub-files:
    • sub-model for the dump truck, named "42023 - Dump Truck.ldr",
    • sub-model for the excavator, named "42023 - Excavator.ldr",
    • sub-model for the wheel loader, named "42023 - Wheel Loader.ldr",
  • there may be even more sub-files in the mpd
    • but they are sub-assemblies, not sub-models,
    • and should not appear in the main sub-file.
Is this plausible, wrong or maybe correct?

Anyhow: as LDInspector checks for file-name-structure, sub-file-name-structure, therefore used numbers and so on, I think the differences between sub-models and sub-assemblies have still to be handled by the user and not the program (but as user I never distinguished this before, so it helps me understanding!).
Reply
RE: LDInspector
#12
Don't get too "wrapped around the axle" trying to get the file structure perfect. I'm sure there will be some crazy edge case that will come along and show that the spec has flaws. The OMR isn't the parts library so the OMR spec is more of a guideline and as long as everything "makes sense" then it's good enough.
Reply
RE: LDInspector
#13
(2020-02-09, 14:43)Orion Pobursky Wrote: as long as everything "makes sense" then it's good enough.
I'm very happy with that. Smile  And if there is something that can be checked by software, I'm willing to implement it. Smile
Reply
RE: LDInspector
#14
Yes OK,

Let me once more emphasis that I'm only voicing my interpretation of the general difference between mpd / ldr / dat -files.
Not the OMR specifications.

Sub-assemblies should be placed in model.ldr file.
i.e. Sub-assemblies to the excavator should be placed in the Excavator.ldr file.

Let me share my version of the set 42023
  • All I need to build the model is there. All the steps from the official BI.
  • And all I need to manipulate the model, if I want to change the angle of the tipper bed. All I need to do is to select the bed and the "parts" that move together with the bed.


Attached Files
.mpd   42023.mpd (Size: 47.15 KB / Downloads: 4)
Reply
RE: LDInspector
#69
(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.
Reply
RE: LDInspector
#70
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.
Reply
RE: LDInspector
#72
(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
Reply
RE: LDInspector
#8
(2020-02-08, 8:31)Stefan Frenz Wrote: For the subfiles I understand the spec (here
Code:
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>.
that the "-1" would be required if there is another set with that number, but not added if there is no other set with that number. So at the time of modelling the first set, it seems to be kind of "not forbidden" and "not required" (how could I know if there would be another set with that number in the future?). It well may be another misunderstanding of mine. Blush I will happily adopt the check as soon as I have a new understanding. Wink 

That's right, but for the base filename (the MPD as a whole), the spec is different:

Quote:Each MPD for the set will be named in the following manner:
<Set Number>[-<Optional Qualifier>] - <Set Name>[ - <Sub Model Name>]

Where:
<Optional Qualifier>: Is a sequential number, starting with 2.

The <Optional Qualifier> is not mandatory and gets added only if there is more than one set that could be assigned the same <Set Number>. The first set using a given number would be understood to never contain the qualifier however numbering should start with the oldest set and some investigation should be done in existing set databases.


So it's pretty clear that the intent is not to use 1 at all in the base filename, even when the set is the first of several with the same number. But, as you've quoted, the qualifier in subfile names does start at 1, not 2, and that it's "added if there is more than one set that could be assigned <Set Number>."

But as you also say, it seems reasonable that the start of every subfile name should be identical to that of the main file, and I have a feeling this is the intent of the specification. So it might be worth clarifying with the Standards Board (which I've now done).
Reply
RE: LDInspector
#5
This is highly welcomed as I wasn't successful either to run MPDCenter on my linux machine. Will have a look!

w.
LEGO ergo sum
Reply
RE: LDInspector
#6
Please report without restraint, I'm motivated to develop the program to be "usable". Smile
Reply
RE: LDInspector
#16
(2020-02-07, 21:50)Stefan Frenz Wrote: The gui requires JavaFX (see here), everything else is "plain Java" (version >=11).

Yet an additional install. It's not that I'm a hard core linux user. Would a all-in-one be possible.

w.
LEGO ergo sum
Reply
RE: LDInspector
#17
Thanks for trying. Attached is an All-in-One-zip for Linux 64 bit systems, only Java>=11 is required. Please unpack to any user directory and start run.sh script. I hope that I integrated all required libs...

Edit: Removed ~8 MB zip with integrated libs as it doesn't seem to work.
Reply
RE: LDInspector
#18
(2020-02-11, 18:57)Stefan Frenz Wrote: Thanks for trying. Attached is an All-in-One-zip for Linux 64 bit systems, only Java>=11 is required. Please unpack to any user directory and start run.sh script. I hope that I integrated all required libs...

Ain't workin

w.
LEGO ergo sum
Reply
RE: LDInspector
#19
(2020-02-12, 7:31)Willy Tschager Wrote: Ain't workin
Oh, I'm very sorry, perhaps some libraries are still missing. Does any message appear? Should I bundle with Java?
Reply
RE: LDInspector
#20
Hi Willy,

if you could give it another chance, attached is a zip file containing LDInspector and four bash scripts
  • 1_download.sh to download Java and JavaFX
  • 2_extract.sh to extract downloaded Java and JavaFX
  • 3_delete_unneeded.sh to remove no more needed archives
  • 4_run.sh to run LDInspector
Please download the zip file, extract anywhere, in a terminal change to this directory and run the scripts like "./1_download.sh". Scripts 1-3 could be integrated into one single "installer" and with more checks, but for debugging purpose I treat it easier to have all steps separated and without any further checks that may fail by accident. I also tried a "complete all-in-one", but this would be ~180 MB for Java and JavaFX, so it seems not be appropriate to upload this to the forum.

Thanks for reporting and best regards
Stefan


Attached Files
.zip   LDInspector.zip (Size: 331.01 KB / Downloads: 4)
Reply
RE: LDInspector
#21
(2020-02-13, 9:36)Stefan Frenz Wrote: Thanks for reporting and best regards
Stefan

Believe it or not but I got it running. Now I need to know some things:

1. How do I create a desktop starter for it, 'cos mine isn't working on Linux Mint
2. I presume the prog wants to know where my LDraw library is - but it didn't ask at start-up
3. I tried to load an .mpd via "Workspace -> Load" but nothing happens
4. I'm irritated by the fact that the prog apparently closes and re-opens after I had hit "Load". - It does the same thing after I opened the "Info" dialog and pushed "OK".

w.
LEGO ergo sum
Reply
RE: LDInspector
#22
Smile  Thank you very much! Smile 

ad 1: Right-click on the desktop, select "Create Launcher", select the 4_run.sh script as "Command" and ensure to have the right "Working Directory" pointing to the directory where the run script is stored. The latter is needed because the starter-script at the moment assumes that it is run in its own directory, which isn't checked and isn't ensured. Now knowing that LDInspector runs on your machine, I will beautify the scripts.

ad 2: By default without configuration, LDInspector uses some kind of minimalistic internal data to enable playing even without LDraw. Please click on "Config." to configure paths to LDraw (if unconfigured, there will be an entry "Test", which should be removed if a real LDraw-directory or complete.zip-file is used). The "Load" button does not load a file but a workspace configuration. In a workspace there may be "loose items" which refer to parts by name, "file references" which refer to a single file by its name, "directory references" which refer to a complete directory by name and other things. I use this to have a default configuration having a reference to my OMR-working-directory and a reference to the downloaded official OMR-files, so configured once I don't need to adjust configuration or "load" files anymore.

ad 3: Yes. Sad  I think the program is not self-explainatory enough (see 2). Please click "File" to refer to a mpd file (if you save the workspace after that, the file-reference will stay there on program-restart). I'll document the workflow and give examples here.

ad 4: Yes. Sad Sad  This is due to a bug of JavaFX that is known for years, but it doesn't get fixed. The bug prevents resizing the main window as soon as a modal window is shown. The only workaround keeping the main window resizable is to hide and re-show the main window. In fact I was very undecided what is worse: having the window unresizeable or hide+show it.
Reply
RE: LDInspector
#23
(2020-02-13, 20:40)Willy Tschager Wrote: working on Linux Mint

Which version of Linux Mint do you use? Maybe it is possible to run something like
Code:
sudo apt-get install openjdk-11-jre openjfx

If this is installed and the ldinsp.jar is in the current directory, the following command should start LDInspector
Code:
java --module-path ldinsp.jar:/usr/share/openjfx/lib -m LDInspector/ldinsp.LDInspector

I think this would be much easier than downloading Java and JavaFX in a script, additionally the system updates will ensure having an up-to-date environment. A drawback is that it is not self-contained / portable and requires root access to the machine...
Reply
RE: LDInspector
#28
(2020-02-14, 15:14)Stefan Frenz Wrote: Which version of Linux Mint do you use?

Linux Mint 18.3 Sylvia

(2020-02-14, 15:14)Stefan Frenz Wrote: Maybe it is possible to run something like
Code:
sudo apt-get install openjdk-11-jre openjfx

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.     
Statusinformationen werden eingelesen.... Fertig
E: Paket openjdk-11-jre kann nicht gefunden werden.
LEGO ergo sum
Reply
RE: LDInspector
#29
Ok, so this is not an option anymore. Thanks for reporting! I will make an installer with download.
Reply
RE: LDInspector
#30
Attached is an updated version of LDInspector, asking for a configuration if started without one (thanks for hinting this might be helpful) and with some new features and bugfixes. Also attached is an installer for Linux and Windows: both download required files and create an appropriate starter script.

Edit: updated install zip as suggested by Willy.


Attached Files
.zip   ldinsp.zip (Size: 375.48 KB / Downloads: 7)
.zip   ldiinstall.zip (Size: 1.25 KB / Downloads: 3)
Reply
RE: LDInspector
#31
(2020-02-21, 9:41)Stefan Frenz Wrote: Attached is an updated version of LDInspector, asking for a configuration if started without one (thanks for hinting this might be helpful) and with some new features and bugfixes. Also attached is an installer for Linux and Windows: both download required files and create an appropriate starter script.

Please add "Linux" or "Windows" to the file name. I'm supposed to remove the old version?

w.
LEGO ergo sum
Reply
RE: LDInspector
#32
Done.  Smile The new version should have more features and less bugs than the old ones, so please use this one and remove the old ones.
Reply
RE: LDInspector
#33
(2020-02-21, 9:41)Stefan Frenz Wrote: Attached is an updated version of LDInspector, asking for a configuration if started without one (thanks for hinting this might be helpful) and with some new features and bugfixes. Also attached is an installer for Linux and Windows: both download required files and create an appropriate starter script.

Edit: updated install zip as suggested by Willy.

I get:

"missing ldinsp.jar, please put it in /home/..."

Could you pack a readme file with instructions how to run the .sh script?

w.
LEGO ergo sum
Reply
RE: LDInspector
#34
Thanks for reporting, attached is an updated version with readme. At the moment I'm quite unsure what is best - I thought of the following:
  • Pack install script and ldinsp together in one zip, user would have to start install and should get it working. Pro: single file; con: always update script+insp together even if not required.
  • Keep install script and ldinsp separated, user has to ensure install-script and ldinsp is in the same directory. Pro: user has more control; con: higher fail quote.
  • Only provide install script, this script downloads newest version of ldinsp itself. Pro: could be used to automatically check for updates; con: at the moment I don't know where (in the web) to put the file - at the moment only this LDraw Forum community is involved...
The board prevents uploading jar and sh files (with good cause), so the user always has to "do something".

Does the install script work if both install-script and ldinsp (zip or jar) are in the same directory?


Attached Files
.zip   ldiinst.zip (Size: 1.64 KB / Downloads: 5)
Reply
RE: LDInspector
#35
(2020-02-23, 11:36)Stefan Frenz Wrote:
  • Only provide install script, this script downloads newest version of ldinsp itself. Pro: could be used to automatically check for updates; con: at the moment I don't know where (in the web) to put the file - at the moment only this LDraw Forum community is involved...
Personally speaking I would prefer this method.

w.
LEGO ergo sum
Reply
RE: LDInspector
#41
Hi Stefan,
Can't seem to be able to install it on my (win10) machine...
Code:
BITSADMIN version 3.0
BITS administration utility.
(C) Copyright Microsoft Corp.

Invalid argument.

BITSADMIN version 3.0
BITS administration utility.
(C) Copyright Microsoft Corp.

Invalid argument.
'unzip' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
Impossible de trouver D:\Mes documents\Bureau\ldinst\openjdk-13.0.2_windows-x64_bin.zip
Le chemin d’accès spécifié est introuvable.

BITSADMIN version 3.0
BITS administration utility.
(C) Copyright Microsoft Corp.

Invalid argument.

BITSADMIN version 3.0
BITS administration utility.
(C) Copyright Microsoft Corp.

Invalid argument.
'unzip' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
Impossible de trouver D:\Mes documents\Bureau\ldinst\openjfx-13.0.2_windows-x64_bin-sdk.zip
Le chemin d’accès spécifié est introuvable.
LDInspector environment installed, please start LDInspector with "run.bat"
Appuyez sur une touche pour continuer...
Reply
RE: LDInspector
#42
Hum. Sad  Thanks for reporting! Smile  

Maybe you could test again with the attached installer and report? I changed the way the current directory is used...

I still don't have a reliable windows machine to test on, sorry. Blush


Attached Files
.zip   ldiinst.zip (Size: 1.64 KB / Downloads: 6)
Reply
RE: LDInspector
#43
(2020-02-25, 15:47)Stefan Frenz Wrote: Hum. Sad  Thanks for reporting! Smile  

Maybe you could test again with the attached installer and report? I changed the way the current directory is used...

I still don't have a reliable windows machine to test on, sorry. Blush
Install worked! Now I need to play with program Wink
Reply
RE: LDInspector
#44
(2020-02-25, 16:14)Philippe Hurbain Wrote: Install worked! Now I need to play with program Wink
It will require MUCH more exploration time (and maybe to read some documentation if/when it's available Big Grin ) but it's very impressive so far! And very fast...
Reply
RE: LDInspector
#45
Thanks a lot for testing, reporting and the nice words! Smile There are still many things that are "work in progress" and therefore changing frequently, but some use case descriptions are found below in post 27 (animated gifs). Hopefully they bring light to what I was thinking of...

If there is anything you would like to have, to not have or to have changed: please let me know!  Smile
Reply
RE: LDInspector
#24
Updated version with support for step-by-step render preview and some bugfixes.

Edit: removed very buggy file. Sorry to all of you testing and thank you N.W.Perry for reporting the exception!
Reply
RE: LDInspector
#25
(2020-02-14, 15:15)Stefan Frenz Wrote: Updated version with support for step-by-step render preview and some bugfixes.

Still working on getting this to run; I'm a bit mixed up which of the various procedures I should be using (Mac OS 10.14.6 here)?
Reply
RE: LDInspector
#26
(2020-02-14, 16:16)N. W. Perry Wrote: I'm a bit mixed up which of the various procedures I should be using (Mac OS 10.14.6 here)?
I'm sorry for that. I don't have a Mac to test and some colleagues reported some caveats for Java on Mac (perhaps they are >=MacOS 10.15), but I would assume that if you have java and openjfx installed, it should ™ work. You can get JavaFX from gluon and Java from Oracle or AdoptOpenJDK.
Reply
RE: LDInspector
#46
(2020-02-14, 16:37)Stefan Frenz Wrote: I'm sorry for that. I don't have a Mac to test and some colleagues reported some caveats for Java on Mac (perhaps they are >=MacOS 10.15), but I would assume that if you have java and openjfx installed, it should ™ work. You can get JavaFX from gluon and Java from Oracle or AdoptOpenJDK.

OK, I've downloaded both version 11 and version 13 of JavaFX, where do I place the files I've downloaded?
Reply
RE: LDInspector
#47
Please try the following directory structure:

Code:
../somePath/ldinsp.jar
../somePath/jdk-13.0.2               <<< therein should be Java13, among others a directory "lib"
../somePath/javafx-sdk-13.0.2     <<< therein should be jFX, among others a directory "lib"


then in a terminal the following should start LDInspector:

Code:
cd ../somePath
jdk-13.0.2/bin/java --module-path .:javafx-sdk-13.0.2/lib/ -m LDInspector/ldinsp.LDInspector


Thanks for testing!
Reply
RE: LDInspector
#48
(2020-02-25, 17:56)Stefan Frenz Wrote: Please try the following directory structure:

Code:
../somePath/ldinsp.jar
../somePath/jdk-13.0.2               <<< therein should be Java13, among others a directory "lib"
../somePath/javafx-sdk-13.0.2     <<< therein should be jFX, among others a directory "lib"


then in a terminal the following should start LDInspector:

Code:
cd /Library/Java/JavaVirtualMachines
jdk-13.0.2.jdk/Contents/Home/bin/java --module-path .:javafx-sdk-13.0.2/lib/ -m LDInspector/ldinsp.LDInspector


Thanks for testing!

Thanks! After revising the terminal commands (shown here for my own copy/paste purposes) to reflect actual directory structure, I get this error:

Code:
Exception in Application start method
Exception in thread "main" java.lang.RuntimeException: Exception in Application start method
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
    at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.lang.Error: Unresolved compilation problem:
    The method getSourceSize() is undefined for the type LDIData

    at LDInspector/ldinsp.gui.view.LDIVItem.refresh(LDIVItem.java:324)
    at LDInspector/ldinsp.gui.view.LDIVItem.onTabSelection(LDIVItem.java:271)
    at LDInspector/ldinsp.gui.LDIGui.tabChanged(LDIGui.java:662)
    at LDInspector/ldinsp.gui.LDIGui.<init>(LDIGui.java:292)
    at LDInspector/ldinsp.LDIGuiStarter.start(LDIGuiStarter.java:33)
    at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:455)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
    at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
    at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
Reply
RE: LDInspector
#49
(2020-02-25, 21:15)N. W. Perry Wrote:
Code:
jdk-13.0.2.jdk/Contents/Home/bin/java --module-path .:javafx-sdk-13.0.2/lib/ -m LDInspector/ldinsp.LDInspector
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
Reply
RE: LDInspector
#51
(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
Reply
RE: LDInspector
#52
(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
Reply
RE: LDInspector
#53
(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.
Reply
RE: LDInspector
#54
(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.
Reply
RE: LDInspector
#66
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?)
Reply
RE: LDInspector
#67
(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
Reply
RE: LDInspector
#82
(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.)
Reply
RE: LDInspector
#55
(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)
Reply
RE: LDInspector
#56
(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
Reply
RE: LDInspector
#57
(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
Reply
RE: LDInspector
#58
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!).
Reply
RE: LDInspector
#59
(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
Reply
RE: LDInspector
#60
Thanks! Smile
Reply
RE: LDInspector
#62
(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
Reply
RE: LDInspector
#63
(2020-02-27, 14:32)Stefan Frenz Wrote: With the current version the catamaran should be rated "ok". Smile
It does Cool
Reply
RE: LDInspector
#27
Attached are four example use cases. Please click on the preview-images to have animated GIFs.

Use case 1: preview mpd (more useful if there is a directory with many mpds to preview)
   

Use case 2: check mpd for OMR compliance
   

Use case 3: create part list from Bricklink web info (useful before making the mpd to get a Bricklink-pbg and afterwards to check parts count); this use case is split into six steps as they are independent and the gif-image-filesize limit is 500 kb...

3.1: search sets and get the inventory from Bricklink
   

3.2: resolve nested inventories for missing or unofficial parts
   

3.3: replace Bricklink-listed but LDraw-missing parts by manual search+replace
   

3.4: automatically replace all ~moved parts
   

3.5: create part list and export to LDCad pbg or Bricklink XML
   

3.6: compare used parts in mpd versus listed parts in part list
   

use case 4: create part list from Rebrickable web info and/or get pbg file directly
   
Reply
RE: LDInspector
#36
Stefan,

would it be possible to put all this stuff at the LDraw wiki?

w.
LEGO ergo sum
Reply
RE: LDInspector
#39
(2020-02-25, 11:29)Willy Tschager Wrote: would it be possible to put all this stuff at the LDraw wiki?
Hi Willy,

yes, of course! I just requested a wiki account. Smile  Maybe the wiki also would be a place to put the always-up-to-date version of LDInspector?

Best regards
Stefan
Reply
RE: LDInspector
#40
(2020-02-25, 13:10)Stefan Frenz Wrote: Hi Willy,

yes, of course! I just requested a wiki account. Smile  Maybe the wiki also would be a place to put the always-up-to-date version of LDInspector?

Best regards
Stefan

Well. I think I'd prefer Github/SourceForge/etc but we can host in a pinch.
Reply
RE: LDInspector
#61
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.
Reply
RE: LDInspector
#64
(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).
Reply
RE: LDInspector
#50
Hi Willy,

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.
Thanks again!

Best regards
Stefan
Reply
RE: LDInspector
#65
(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
Reply
RE: LDInspector
#37
This is impressive, especially the amount of data you pull form it. However I have some suggestions:

* Please rename "Check" to "OMR-Check" and place the tab between "Item" and "Render"
* I loaded a .ldr file with unofficial part. I get all warnings but I don't know how to:

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

* In the PartList Chart I would prefer the long name "Official" "Unofficial" instead of "ofc", "uno"
* Does "ign" stand for "Ignor"?

w.
LEGO ergo sum
Reply
RE: LDInspector
#38
Thanks a lot! Smile

(2020-02-25, 11:51)Willy Tschager Wrote: * Please rename "Check" to "OMR-Check" and place the tab between "Item" and "Render"
* In the PartList Chart I would prefer the long name "Official" "Unofficial" instead of "ofc", "uno"
Done.

(2020-02-25, 11:51)Willy Tschager Wrote: * I loaded a .ldr file with unofficial part. I get all warnings but I don't know how to:

Fix movetos
Inline unofficials with the correct OMR-nomenclatura
Fix description
Fix filename
Yes, at the moment there is no hint about how to fix. I plan to implement some kind of "quick fix" which should fix all errors/warnings that can be fixed automatically. But at the moment, LDInspector only reads user data and never writes them back - I'm still unsure about the preferred user interface therefore. For all other errors (like "part missing") I plan to give some more information about what is wrong and how it could be fixed.

(2020-02-25, 11:51)Willy Tschager Wrote: * Does "ign" stand for "Ignor"?
Yes. At the moment every check that is started will print exactly one line. Would you prefer skipping the output of ignored checks?

Thank you very much for repeated testing. I really do appreciate your feedback very much.  Smile
Reply
RE: LDInspector
#68
(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...
Reply
RE: LDInspector
#71
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
Reply
RE: LDInspector
#73
(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
Reply
RE: LDInspector
#74
Feature suggestion: How about a check for whether all referenced submodels (i.e., non-part files) are set to color 16?
Reply
RE: LDInspector
#75
(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...
Reply
RE: LDInspector
#76
(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).
Reply
RE: LDInspector
#81
(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


Attached Files Thumbnail(s)
   
Reply
RE: LDInspector
#83
(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.
Reply
LDInspector version 0.2
#77
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
Reply
RE: LDInspector version 0.2
#78
* 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.
LEGO ergo sum
Reply
RE: LDInspector version 0.2
#79
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.
Reply
RE: LDInspector version 0.2
#80
(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
Reply
RE: LDInspector version 0.2
#84
* 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
.mpd   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.
LEGO ergo sum
Reply
RE: LDInspector version 0.2
#85
(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.
Reply
RE: LDInspector version 0.2
#86
...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
Reply
RE: LDInspector version 0.2
#87
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

   

(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.
LEGO ergo sum
Reply
RE: LDInspector version 0.2
#89
Ah, now I got it! Big Grin  So the buttons will look like this in the next version:
   

The check against additional meta-lines will be included, too.
Reply
RE: LDInspector version 0.2
#91
(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"?
Reply
RE: LDInspector version 0.2
#95
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...
Reply
RE: LDInspector version 0.2
#96
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...
Reply
RE: LDInspector version 0.2
#97
(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
Reply
RE: LDInspector version 0.2
#98
(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
Reply
RE: LDInspector version 0.2
#99
(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
Reply
Header Meta question
I'm very sorry for asking again. After reading several documents (like File Format, Official META Commands and Library Header Specification, thank you Mike for explicitly pointing to the Specifications Main Page) over and over again, and also after reading the corresponding part of MPDCenter-Source (where I found "IsValidHeaderMetaCommand" which allows at most "Name:, Author:, !KEYWORDS, !CATEGORY, !LICENSE, !LDRAW_ORG, !HISTORY, CMDLINE, BFC, !HELP"; thank again to Mike for providing), I still think that

(2020-04-13, 7:53)Stefan Frenz Wrote:
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
could be invalid at the "0 !LEOCAD" Meta line in the header, especially because it is before the description "0 main".

So there are some options how LDInspector handles something like "0 !LEOCAD":
  1. Treat them generally as valid / ignore them, regardless of their position. Then I don't understand the docs, but it would be the easiest option to implement. Sad
  2. Treat them as invalid, but keep their position even if file is saved lateron. This would make LDInspector handling such lines equal to unresolvable references or mirrored parts (line is wrong, but you are the boss). This seems the neatest option to me, although it is the complicated one. Smile
  3. Treat them as invalid if position is before Author and always write them back after the header if file is saved. Diff to opt2: do not try to keep those meta lines before any Author field (line is wrong, and it is fixed always). Maybe this is what is wanted? Huh
  4. Not a real option: treat description and header as being "too" invalid. This is the current behavior of LDInspector I would like to change and I'm sure nobody wants to have, especially because there are some more "official OMR" files containing "0 !LEOCAD" before the description meta. Cool
Did I miss something? Do you have an advice for me or a wish how LDInspector should behave?

Thanks in advance and best regards
Stefan
Reply
RE: Header Meta question
(2020-04-30, 12:34)Stefan Frenz Wrote: Did I miss something? Do you have an advice for me or a wish how LDInspector should behave?
After thinking two nights about it and reading the LEOCad meta command description, it seems that they need to be at this place for LEOCad. So it will become something between option 1 and 2: be able to read and generally ignore additional metas in the header and do not move them, write them back at the same position of not explicitly (re)moved, and offer an option to automatically (re)move them for OMR compliance.
Reply
RE: Header Meta question
(2020-05-02, 9:53)Stefan Frenz Wrote: After thinking two nights about it and reading the LEOCad meta command description, it seems that they need to be at this place for LEOCad. So it will become something between option 1 and 2: be able to read and generally ignore additional metas in the header and do not move them, write them back at the same position of not explicitly (re)moved, and offer an option to automatically (re)move them for OMR compliance.

I meant to reply earlier but got distracted,

Anyway, from a File Format standpoint, having a meta probably isn't desired as the first line of a file as it should result in the META being ignored and the line being consider the file title.

https://www.ldraw.org/article/218.html#lt0
"If the first line of a file is a line type 0 the remainder of the line is considered the file title (see Library Header specification). This overrides any META commands on that line."

Therefore, it's not "illegal" but, also, not recommend as it should (if the program fully conforms to the spec) lead to an unexpected outcome. You might want to inform Leonardo to change this behavior.
Reply
RE: Header Meta question
(2020-05-02, 12:42)Orion Pobursky Wrote: [...] having a meta probably isn't desired as the first line of a file as it should result in the META being ignored and the line being consider the file title.
[...] 218 "If the first line of a file is a line type 0 the remainder of the line is considered the file title (see Library Header specification). This overrides any META commands on that line."
Therefore, it's not "illegal" but, also, not recommend as it should (if the program fully conforms to the spec) lead to an unexpected outcome. [...]
Thank you very much for confirming! Smile  Indeed LDInspector took this line as description ("file title") which only showed up because of Willy's hint about unneeded META commands. Smile
Reply
RE: Header Meta question
(2020-05-02, 12:42)Orion Pobursky Wrote: Therefore, it's not "illegal" but, also, not recommend as it should (if the program fully conforms to the spec) lead to an unexpected outcome. You might want to inform Leonardo to change this behavior.

I think that behavior is from before there was an OMR header and the first line being the description was only official for the parts library. I'll change the save format to be OMR compliant.
Reply
RE: LDInspector version 0.2
#88
(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.
LEGO ergo sum
Reply
RE: LDInspector version 0.2
#90
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
Reply
RE: LDInspector version 0.2
#94
(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"...?
Reply
RE: LDInspector version 0.2
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
Reply
RE: LDInspector version 0.2
(2020-04-14, 8:18)Stefan Frenz Wrote: Thanks for all your feedback helping me on my way towards LDInspector 0.3...  Wink

Willy's a taskmaster but a good one. I remember when I was active developing LDDP, when ever I would drop a new version, he'd come back with 30 more things for me to do. Made that program so much better. If I could find a good way to port it over to free compilers, I'd start developing again.
Reply
RE: LDInspector version 0.2
(2020-04-14, 19:51)Orion Pobursky Wrote: Willy's a taskmaster but a good one. I remember when I was active developing LDDP, when ever I would drop a new version, he'd come back with 30 more things for me to do. Made that program so much better.
Yes, I am very happy with the feedback and I value the time spent for testing and reporting.  Smile  Smile  Smile

(2020-04-14, 19:51)Orion Pobursky Wrote: If I could find a good way to port it over to free compilers, I'd start developing again.
Thanks for hinting towards LDDP. I didn't use it so far, but by looking at the screenshots and description, I have a strong feeling that the planned source code editing in LDInspector either will be not considered useful or will encounter very similar questions.  Wink  LDDP is written in Delphi and C++, isn't it?
Reply
RE: LDInspector version 0.2
(2020-04-15, 1:23)Stefan Frenz Wrote: LDDP is written in Delphi and C++, isn't it?

Just Delphi. But I don't want to pay for that any more. I tried to port to Lazarus/FreePascal but I'm using Scintilla editor control and some other third party controls that made life difficult. Also, if I switched to Lazarus's syntax highlighter control, I'd have to write a syntax highlighter plugin which I'm not excited about. LDPE has pretty much supplanted LDDP functionality anyway.
Reply
current version update
The current version checks for unsaved data before exit/refresh/load. Smile  For the next version still missing is the parser re-write to read FILE/File/file correctly and to detect additional comments (meta lines) in the first three lines correctly like in OMR 4565.
Reply
RE: LDInspector version 0.2
(2020-04-08, 11:52)Willy Tschager Wrote: * Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
Hi Willy, hi Roland,

thanks for insisting. I found the LDInspector branch and the comment I made: I adopted the LDCad behavior by integrating the prefix into the path. For example my small harbor sentry file was cleaned up by LDCad and afterwards contains "6245 - s\2551s01.dat" and not "s\6245 - 2551s01.dat".

I think the latter is what is wanted, but even if I change the filename to "s\6245 - 2551s01.dat" and then do LDCad cleanup again, it is changed to "6245 - s\6245 - 2551s01.dat". I am sure Roland has done the cleanup in this way by reason, but now I'm confused. Angel

Thanks for clarification and best regards
Stefan
Reply
RE: LDInspector version 0.2
(2020-05-01, 15:54)Stefan Frenz Wrote: I think the latter is what is wanted, but even if I change the filename to "s\6245 - 2551s01.dat" and then do LDCad cleanup again, it is changed to "6245 - s\6245 - 2551s01.dat". I am sure Roland has done the cleanup in this way by reason, but now I'm confused. Angel

It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d Angry
Reply
RE: LDInspector version 0.2
(2020-05-01, 18:01)Roland Melkert Wrote: It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d Angry
Thank you very much for the fast response! And please don't feel angry Smile
Reply
RE: LDInspector version 0.2
(2020-05-01, 18:59)Stefan Frenz Wrote: please don't feel angry Smile

Just a bit bummed the brand new paint job already has a scratch on it. Undecided
Reply
RE: LDInspector
#92
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
Reply
RE: LDInspector
#93
(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
Reply
LDInspector - BrickLink Web search broken
Bricklink just changed something at the web page / json return string, so LDInspector's BrickLink search on Web pane does not return anything at the moment with all versions. I'm working on this...
Reply
RE: LDInspector - BrickLink Web search broken
Big Grin  Ok, Bricklink didn't change anything, they were in maintenance mode. Big Grin  Unfortunately, LDInspector cached even the "maintenance" message. Starting with the next version (not uploaded yet), LDInspector will dismiss cached web resources on structural errors.
Reply
LDInspector version 0.3
Thank you very much Willy, Roland, Orion and Mike for your help, suggestion and confirmation. So today I released version 0.3 as current version, main changes since 0.2 are:
  • Updated main toolbar (now re-ordered and colored).
  • Re-implemented file-save, now only on demand.
  • Added part/color replacement on Edit pane.
  • Beautified OMR compliance check reports.
  • Fixed filename checks containing path.
  • Fixed file extension file type check.
  • Added dispensable meta check.
  • Added part preview to Web pane.
  • Automatic web cache dismiss after error.
  • Optimized Rebrickable / Bricklink part replacement.
  • Now rating moved parts as "warning" instead of "error".
  • Now accepting non-spec-conforming files with meta before description.

As always: all suggestions are warmly welcome, thanks for testing and reporting. [Image: smile.png] 
Best regards
Stefan
Reply
RE: LDInspector
Not specific to the current version, but I get this non-error message each time I start the program:
Code:
objc[74433]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffa5d083d8) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x132ec9f50). One of the two will be used. Which one is undefined.

It's probably something to do with my own system—or MacOS in general—but I don't know whether it's a user issue or a developer one.
Reply
RE: LDInspector
Good to know that this problem arises with LDInspector, too, but this is an Apple problem out of my access. Citing StackOverflow: "There's nothing you can do about this. It's an Apple problem, but it's probably harmless."
Reply
RE: LDInspector
(2020-05-07, 5:10)Stefan Frenz Wrote: Good to know that this problem arises with LDInspector, too, but this is an Apple problem out of my access. Citing StackOverflow: "There's nothing you can do about this. It's an Apple problem, but it's probably harmless."

Good, then I'll not worry about it. :-)
Reply
RE: LDInspector
There is a new unofficial version of LDInspector that fixes a bug in the header-line check after automatic name/rename-fix.

Additionally, in the PartList-view there is a new experimental feature to get the price for a part from Bricklink (you can choose used/new parts and already-sold/to-be-sold prices). Unfortunately, this works only for few parts, then BrickLink prevent further requests, so this will be replaced in future versions. For example, Rebrickable has complete lists of prices like in
  https://rebrickable.com/parts/14395/bric...#buy_parts
which is way more than I have in mind - I just want to have an idea of the price, for example if an alternate part or another color is much cheaper, or if the part could be replaced by another one that is much cheaper. To do this search in LDInspector with more search options than available in Rebrickable, I would like to include prices of parts. Does anyone know an online price database for new/used parts that can be queried?

As always: any help or suggestion is warmly welcome.
Reply
RE: LDInspector
(2020-08-17, 9:56)Stefan Frenz Wrote: There is a new unofficial version of LDInspector that fixes a bug in the header-line check after automatic name/rename-fix.

Additionally, in the PartList-view there is a new experimental feature to get the price for a part from Bricklink (you can choose used/new parts and already-sold/to-be-sold prices). Unfortunately, this works only for few parts, then BrickLink prevent further requests, so this will be replaced in future versions. For example, Rebrickable has complete lists of prices like in
  https://rebrickable.com/parts/14395/bric...#buy_parts
which is way more than I have in mind - I just want to have an idea of the price, for example if an alternate part or another color is much cheaper, or if the part could be replaced by another one that is much cheaper. To do this search in LDInspector with more search options than available in Rebrickable, I would like to include prices of parts. Does anyone know an online price database for new/used parts that can be queried?

As always: any help or suggestion is warmly welcome.
You should watch out for using Rebrickable too. They have started blocking non-browser users, such as apps using their color sheet.
Reply
RE: LDInspector
(2020-08-17, 12:05)Lasse Deleuran Wrote: You should watch out for using Rebrickable too. They have started blocking non-browser users, such as apps using their color sheet.
Thanks. Smile
Reply
RE: LDInspector
(2020-08-17, 12:05)Lasse Deleuran Wrote: You should watch out for using Rebrickable too. They have started blocking non-browser users, such as apps using their color sheet.

As far as I know, you just can't ping too much. With the PBG generator, I throttle the requests to prevent this (I actually had triggered temporarily IP ban due to a bug in my code). I do know they removed the ability to get the parts lists for MOCs.
Reply
RE: LDInspector
Thanks for this, too. Smile  For Rebrickable I have a best-guess connection throttle algorithm which seems to work most of the time (which results in horrible timing for large part lists).

There are other sites with "part out values" like brickmerge.de - somehow they must obtain part prices... Does anybody know how? Thanks in advance.
Reply
RE: LDInspector
(2020-08-17, 14:52)Stefan Frenz Wrote: Thanks for this, too. Smile  For Rebrickable I have a best-guess connection throttle algorithm which seems to work most of the time (which results in horrible timing for large part lists).

There are other sites with "part out values" like brickmerge.de - somehow they must obtain part prices... Does anybody know how? Thanks in advance.

They probably have BrickLink API access. Since BrickLink requires you to have a static IP and there's no way we're going to pay for that, BrickLink API access (However useful it may be) isn't going to happen anytime soon here at LDraw.

The other option is to severely throttle your page requests. 2 sec between requests or something ridiculous like that.
Reply
RE: LDInspector
(2020-08-17, 14:57)Orion Pobursky Wrote: They probably have BrickLink API access. Since BrickLink requires you to have a static IP and there's no way we're going to pay for that, BrickLink API access (However useful it may be) isn't going to happen anytime soon here at LDraw.

The other option is to severely throttle your page requests. 2 sec between requests or something ridiculous like that.
Indeed I don't have static IP at home (not even real IPv4 anymore).  Sad  For some "long term" huge pausing between requests would do it, yes, but for my use-case I would interactively search for a part replacement based on price (not only on price, but as one of many criteria), so for each part to be replaced I would search for at least a dozen other ones. If there is no online-database with hard access restriction, I was in hope to get something like Rebrickable's downloadable set inventories files with price per colored part... Angel
Reply
RE: LDInspector
Detailled use case: having an LDraw model, I would like to get an idea how much each part costs. This can be easily done with Rebrickable as registered user by uploading the part list and looking at the prices. To my knowledge, these addtional steps are not (easily) possible:
  • If a part has a very high price, I would like to replace this part by a similar one with some kind of associative search. For example a 6556 (white 9.07 Euro, tan 16.81 Euro) could be replaced by 4033 (white avg. 9.90 Euro, tan not avail.; this would not be an option) or 60594 (white 0.20 Euro, tan 0.25 Euro; this would be much cheaper if one accepts the model change).
  • If some parts are very expensive in a particular color or if I'm in search of alternative colors, I would like to check what colors are available for those parts, i.e. in which colors are all selected parts available, instantly showing the price. Rebrickable helps with "similar colors", but (to my knowledge) the result is (a) based on my existing parts and (b) treats each part separately. For example, having 3005 and 3010 and 3020 (brick 1x1, brick 1x4, plate 2x4), I would like to get a list with prices for all colors, in which all three parts are available (3010 is not buyable in bright green, so this would be out instantly; black is 0.10/0.14/0.12, dark bluish gray is 0.05/0.19/0.06; some more colors...).
Thanks for any suggestion. Smile
Reply
RE: LDInspector
Just reporting: I gave up on getting prices from BrickLink. Unfortunately, I did not found any other downloadable / requestable price database.

To get an idea of what I am searching for, I tried to get some information out of the data available from Rebrickable. Listing all parts in all sets from the downloadable Rebrickable's csv files, it seems that there are about 61k real parts (i.e. really existing combinations of part-ids and color-ids). Does this seem to be appropriate? Feeding those 61k back to Rebrickable, about 3k parts result in an error. Those without error divide into about 17k without and 41k with price information. The pipeline took about 8 hours. That's no option obviously. Wink  

It seems that prices will be removed from / not be integrated into LDInspector.
Reply
RE: LDInspector
How do I create a desktop starter for it, 'cos mine isn't working on Linux Mint
Reply
RE: LDInspector
I don't have Mint at hand, but according to https://forums.linuxmint.com/viewtopic.php?f=42&t=86813 you may add the launcher-editor to your desktop and then add a launcher for LDInspector. Or you follow simple instructions on https://blog.softhints.com/create-shortcut-linux-mint/ or according to https://www.heelpbook.net/2017/create-de...her-linux/ you could also directly create a desktop icon by creating a text file like this
Code:
[Desktop Entry]
Type=Application
Name=LDInspector
GenericName=LDInspector
Comment=LDInspector
Exec=/home/YOUR-PATH/TO-LDINSPECTOR/run.sh
Icon=/YOUR-PREFERRED-ICON
Terminal=false
Categories=Development;IDE;
Keywords=LDraw;
StartupWMClass=processing-app-Base
and save this in your ~/.local/share/applications directory.
Reply
LDInspector version 0.4
Today I released version 0.4 as current version, main changes since 0.3 are mostly "behind the scenes":
  • Removed non-constructive features.
  • Fixed several OMR header checks.
Thanks again for all contributions and feedback.  Smile
Reply
new LDInspector snapshot version
There is a new snapshot version. Changes:
  • added "export as new file" for clipboard on Edit-pane - now you can easily create a mpd-file containing all models in clipboard
  • more header checks, adopting some of the checks done in MPDCenter (thanks again Mike)
Any suggestion and feedback is highly welcome.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)