LDInspector

[Orion Pobursky]

Thanks for all your feedback helping me on my way towards LDInspector 0.3... 

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.

[Stefan Frenz]

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.     

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.    LDDP is written in Delphi and C++, isn't it?

[Orion Pobursky]

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.

[Stefan Frenz]

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...

[Stefan Frenz]

  Ok, Bricklink didn't change anything, they were in maintenance mode.   Unfortunately, LDInspector cached even the "maintenance" message. Starting with the next version (not uploaded yet), LDInspector will dismiss cached web resources on structural errors.

[Stefan Frenz]

The current version checks for unsaved data before exit/refresh/load.   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.

[Stefan Frenz]

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

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.
   
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.
   
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?
   
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.
   

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

[Stefan Frenz]

* 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.

Thanks for clarification and best regards
Stefan

[Roland Melkert]

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.

It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d

[Stefan Frenz]

It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d

Thank you very much for the fast response! And please don't feel angry

[Roland Melkert]

please don't feel angry

Just a bit bummed the brand new paint job already has a scratch on it.

[Stefan Frenz]

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.

[Orion Pobursky]

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.

[Stefan Frenz]

[...] 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!   Indeed LDInspector took this line as description ("file title") which only showed up because of Willy's hint about unneeded META commands.

[Leonardo Zide]

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.

[Stefan Frenz]

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.  
Best regards
Stefan

[N. W. Perry]

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.

[Stefan Frenz]

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."

[N. W. Perry]

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. :-)

[Stefan Frenz]

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.

[Lasse Deleuran]

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.

[Stefan Frenz]

You should watch out for using Rebrickable too. They have started blocking non-browser users, such as apps using their color sheet.

Thanks.

[Orion Pobursky]

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.

[Stefan Frenz]

Thanks for this, too.   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.

[Orion Pobursky]

Thanks for this, too.   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.

[Stefan Frenz]

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).    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...

[Stefan Frenz]

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.

[Stefan Frenz]

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.  

It seems that prices will be removed from / not be integrated into LDInspector.

[rajubhaiya]

How do I create a desktop starter for it, 'cos mine isn't working on Linux Mint

[Stefan Frenz]

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.

[Stefan Frenz]

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. 

[Stefan Frenz]

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.

[Stefan Frenz]

There is a new snapshot version. Changes:

• fixed XML-export (was PBG-export even if XML was selected)
  
• added direct part list export on Item page for all part-containing types
  

Any suggestion and feedback is highly welcome.

[N. W. Perry]

So I tested my file "700-1-1 - Automatic Binding Bricks.mpd" and LDInspector found that the filename does not conform to the OMR standard because it doesn't match the set number + optional qualifier rule. In fact, the set number is "700-1" and the qualifier is "-1", so it should pass. Presumably the checker is confused by the extra hyphen.

(Actually the set number should be 700/1, but slashes mustn't appear in filenames. And 700.1 results in the same error message, probably for a similar reason.)

This is admittedly a fringe case, as there are not a whole lot of official models that will have slashes in their set numbers to begin with! But perhaps of interest as a mere curiosity.

[Stefan Frenz]

Thanks for testing and reporting. Indeed I assumed that set numbers do not include hyphens, and in most cases this would be a mistake. This is the regular expression I use for testing:

Code:

^([a-z0-9]+)(-[a-z0-9]+)? - (.*)

Hmmmm. What would be the desired behavior for LDInspector? I remember the discussion about the "-1" suffix...

[N. W. Perry]

Thanks for testing and reporting. Indeed I assumed that set numbers do not include hyphens, and in most cases this would be a mistake. This is the regular expression I use for testing:

Code:

^([a-z0-9]+)(-[a-z0-9]+)? - (.*)

Hmmmm. What would be the desired behavior for LDInspector? I remember the discussion about the "-1" suffix...

Does LDInspector test whether the set number itself is valid? If so, it should recognize 700-1. Or rather, it should recognize 700/1, but understand that "-" is a substitute for "/". So, in short, I guess it should allow "-" or maybe "." in addition to [a-z0-9] in the first string?

(Maybe the real problem isn't one of LDInspector at all, but rather of having a standard substitute for the / character in the LDraw format.)

The "-1" suffix is an additional quirk. True, it shouldn't be required for the oldest of multiple sets with the same number. But in this case, the "-1" represent the first of two variations of the same set. (Set 700/1 existed continuously from 1949 to 1965, but over that time the packaging and contents were continually varied.)

[Stefan Frenz]

Does LDInspector test whether the set number itself is valid? If so, it should recognize 700-1. Or rather, it should recognize 700/1, but understand that "-" is a substitute for "/". So, in short, I guess it should allow "-" or maybe "." in addition to [a-z0-9] in the first string?

(Maybe the real problem isn't one of LDInspector at all, but rather of having a standard substitute for the / character in the LDraw format.)

The "-1" suffix is an additional quirk. True, it shouldn't be required for the oldest of multiple sets with the same number. But in this case, the "-1" represent the first of two variations of the same set. (Set 700/1 existed continuously from 1949 to 1965, but over that time the packaging and contents were continually varied.)

Yes, LDInspector tests the set number and reports non-numbers as "contains non-numeric chars, which is very unlikely". Additional "-1" are hinted by "hint: optional qualifier is 1 (use only if it is greater than 1)". The second part after the set number is tested for numbers, too, resulting also in "contains non-numeric chars" if not a number.

I can add the "-" and/or "/" character for the set id which automatically would allow "700-1-1" and "700/1-1" - maybe another warning "which is very unlikely"? But, hum, I'm still not sure if adding this flexibility for some edge cases (or aren't they edges?) introduces problems for most other sets in checking file names. As I appreciate all feedback: maybe some other opinions from Johann or Philippe which helped me on my struggling way through the docs?

[Orion Pobursky]

I think in order to prevent parsing errors elsewhere, I'm going to change the OMR rules to have "/" replaced with "." like both Rebrickable and BrickLink do.

[N. W. Perry]

Yes, LDInspector tests the set number and reports non-numbers as "contains non-numeric chars, which is very unlikely". Additional "-1" are hinted by "hint: optional qualifier is 1 (use only if it is greater than 1)". The second part after the set number is tested for numbers, too, resulting also in "contains non-numeric chars" if not a number.

I can add the "-" and/or "/" character for the set id which automatically would allow "700-1-1" and "700/1-1" - maybe another warning "which is very unlikely"? But, hum, I'm still not sure if adding this flexibility for some edge cases (or aren't they edges?) introduces problems for most other sets in checking file names. As I appreciate all feedback: maybe some other opinions from Johann or Philippe which helped me on my struggling way through the docs?

They are definitely edge cases—I can't even think of another example where this would come up, at least for OMR purposes. Frankly, it's a stretch whether even these models fit within the spirit of the OMR. So I'd agree that it may not be worth allowing this flexibility, if it might cause other legitimate errors to be missed.

Here's an idea: what if we allow "." for the set id, but not "-" or "/" (because they cause other potential conflicts)? Then it could be understood that "." is the preferred substitute for "/" in set numbers, because there are a lot of early sets that use this character, even if they don't represent specific models. This matches the convention used by some of the inventory sites.

And then if the "." is found, it could trigger a hint or warning but not an error.

[Stefan Frenz]

Thank you for joining    I like the dot idea, so it would be kind of

Code:

^([a-z0-9\.]+)(-[a-z0-9]+)? - (.*)

to extend the basic set number by something with a dot, so "error free" are "700" (ok) and "700a" (unlikely because of "a") and "700.1" (unlikely because of "."), even "700.1.2" (unlikely because of "." and because of double use of ".") and "700.1-1" (unlikely because of "." and hinted for set-qualifier "-1"). But real errors are "700/1" (because of "/") or "700-1-1" (because of double "-").

[Stefan Frenz]

Here's an idea: what if we allow "." for the set id, but not "-" or "/" (because they cause other potential conflicts)? Then it could be understood that "." is the preferred substitute for "/" in set numbers, because there are a lot of early sets that use this character, even if they don't represent specific models. This matches the convention used by some of the inventory sites.

And then if the "." is found, it could trigger a hint or warning but not an error.

Hopefully with the above examples I understood it the way you mean it.   The more test cases with "ok" or all warning-able or hint-able messages I have, the more precise I can test my code.

[N. W. Perry]

Hopefully with the above examples I understood it the way you mean it.   The more test cases with "ok" or all warning-able or hint-able messages I have, the more precise I can test my code.

Yes, that sounds just right.  I did also think of allowing "_" instead of "." in case the dot causes problems. But I do like the dot better than the underscore, it just looks cleaner somehow!

So I'll adapt my model naming to use, e.g., 700.1-1.

[Stefan Frenz]

Thank you Orion and N.W.Perry for your input. I updated the current version of LDInspector accordingly.

[N. W. Perry]

Thank you Orion and N.W.Perry for your input. I updated the current version of LDInspector accordingly.

Works great!

[Stefan Frenz]

Thanks for the feedback!

[Stefan Frenz]

Today I released version 0.5 as current version, main changes since 0.4 are:

•     Added "Export clipboard to file" function.
  
•     Added Color-Overwrite and Color-Filter options to Render pane.
  
•     Fixed BrickLink-xml part list export and added directory to config file.
  
•     Added more informative logs for unsupported items.
  

Thanks again for all contributions and feedback.

[Stefan Frenz]

Today I released version 0.6 as current version, main changes since 0.5 are mostly "under the hood", but I added the coplanar triangle collision test (see also this thread) to the collision detection.

Attention: if you have some of the last versions running, please adopt your start script (most probably some "run.sh" or "run.bat" created by the installer) to start the changed GUI-starter. In detail, please replace the old starter class

Code:

LDInspector/ldinsp.LDInspector

by the new one

Code:

LDInspector/ldinsp.guifx.starter.LDIGuiStarter

Thanks again for all contributions and feedback.

[Stefan Frenz]

Thanks to Jaco for reporting the broken Windows installer, it should be fixed now.

[Jaco van der Molen]

Thanks to Jaco for reporting the broken Windows installer, it should be fixed now.

I tried the new installer, but it didn't download javafx-sdk-13.0.2 either.
It did download unzip and openjdk-13.0.2
I manually tried https://download2.gluonhq.com/openjfx/13...in-sdk.zip and that worked.
Extracting manualy did work and LDI starts

[Stefan Frenz]

I tried the new installer, but it didn't download javafx-sdk-13.0.2 either.
It did download unzip and openjdk-13.0.2
I manually tried https://download2.gluonhq.com/openjfx/13...in-sdk.zip and that worked.
Extracting manualy did work and LDI starts

Thanks for re-testing and your report.  This is would match the old installer's behavior.  The new installer should try to download version 17 of jdk and jfx.

Downloading the installer from my website (after clearing caches) should result in an installer containing this line:

Code:

curl https://download2.gluonhq.com/openjfx/17.0.2/openjfx-17.0.2_windows-x64_bin-sdk.zip -o "%mypath%\openjfx-17.0.2_windows-x64_bin-sdk.zip"

If there is still some "bitsadmin" or "13.0.2" in the file, I assume your download link is not the same as mine.   Did you use this one:

http://www.fam-frenz.de/stefan/ldiinst.zip

or another one?