![]() |
LDInspector - Printable Version +- LDraw.org Discussion Forums (https://forums.ldraw.org) +-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html) +--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html) +--- Thread: LDInspector (/thread-23882.html) |
RE: LDInspector version 0.2 - Orion Pobursky - 2020-04-14 (2020-04-14, 8:18)Stefan Frenz Wrote: 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. RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-15 (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. ![]() ![]() ![]() (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. ![]() RE: LDInspector version 0.2 - Orion Pobursky - 2020-04-15 (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. LDInspector - BrickLink Web search broken - Stefan Frenz - 2020-04-25 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... RE: LDInspector - BrickLink Web search broken - Stefan Frenz - 2020-04-25 ![]() ![]() current version update - Stefan Frenz - 2020-04-26 The current version checks for unsaved data before exit/refresh/load. ![]() Header Meta question - Stefan Frenz - 2020-04-30 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: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":
Thanks in advance and best regards Stefan RE: LDInspector version 0.2 - Stefan Frenz - 2020-05-01 (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. ![]() Thanks for clarification and best regards Stefan RE: LDInspector version 0.2 - Roland Melkert - 2020-05-01 (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. It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d ![]() RE: LDInspector version 0.2 - Stefan Frenz - 2020-05-01 (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.6dThank you very much for the fast response! And please don't feel angry ![]() RE: LDInspector version 0.2 - Roland Melkert - 2020-05-01 (2020-05-01, 18:59)Stefan Frenz Wrote: please don't feel angry Just a bit bummed the brand new paint job already has a scratch on it. ![]() RE: Header Meta question - Stefan Frenz - 2020-05-02 (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. RE: Header Meta question - Orion Pobursky - 2020-05-02 (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. RE: Header Meta question - Stefan Frenz - 2020-05-02 (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.Thank you very much for confirming! ![]() ![]() RE: Header Meta question - Leonardo Zide - 2020-05-03 (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. LDInspector version 0.3 - Stefan Frenz - 2020-05-06 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:
As always: all suggestions are warmly welcome, thanks for testing and reporting. ![]() Best regards Stefan RE: LDInspector - N. W. Perry - 2020-05-06 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. RE: LDInspector - Stefan Frenz - 2020-05-07 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." RE: LDInspector - N. W. Perry - 2020-05-07 (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. :-) RE: LDInspector - Stefan Frenz - 2020-08-17 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/brick-arch-1-x-5-x-4-continuous-bow-raised-underside-cross-supports/#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. RE: LDInspector - Lasse Deleuran - 2020-08-17 (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.You should watch out for using Rebrickable too. They have started blocking non-browser users, such as apps using their color sheet. RE: LDInspector - Stefan Frenz - 2020-08-17 (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. ![]() RE: LDInspector - Orion Pobursky - 2020-08-17 (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. RE: LDInspector - Stefan Frenz - 2020-08-17 Thanks for this, too. ![]() There are other sites with "part out values" like brickmerge.de - somehow they must obtain part prices... Does anybody know how? Thanks in advance. RE: LDInspector - Orion Pobursky - 2020-08-17 (2020-08-17, 14:52)Stefan Frenz Wrote: Thanks for this, too. 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. RE: LDInspector - Stefan Frenz - 2020-08-17 (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.Indeed I don't have static IP at home (not even real IPv4 anymore). ![]() ![]() RE: LDInspector - Stefan Frenz - 2020-08-18 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:
![]() RE: LDInspector - Stefan Frenz - 2020-08-29 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. RE: LDInspector - rajubhaiya - 2020-09-24 How do I create a desktop starter for it, 'cos mine isn't working on Linux Mint RE: LDInspector - Stefan Frenz - 2020-09-25 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-desktop-shortcut-launcher-linux/ you could also directly create a desktop icon by creating a text file like this Code: [Desktop Entry] LDInspector version 0.4 - Stefan Frenz - 2020-10-02 Today I released version 0.4 as current version, main changes since 0.3 are mostly "behind the scenes":
![]() new LDInspector snapshot version - Stefan Frenz - 2020-11-17 There is a new snapshot version. Changes:
new LDInspector snapshot version - Stefan Frenz - 2020-12-30 There is a new snapshot version. Changes:
RE: LDInspector - N. W. Perry - 2021-04-24 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. RE: LDInspector - Stefan Frenz - 2021-04-24 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... ![]() RE: LDInspector - N. W. Perry - 2021-04-24 (2021-04-24, 9:27)Stefan Frenz Wrote: 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: 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.) RE: LDInspector - Stefan Frenz - 2021-04-24 (2021-04-24, 13:33)N. W. Perry Wrote: 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?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? ![]() RE: LDInspector - Orion Pobursky - 2021-04-24 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. RE: LDInspector - N. W. Perry - 2021-04-24 (2021-04-24, 14:00)Stefan Frenz Wrote: 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. 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. RE: LDInspector - Stefan Frenz - 2021-04-24 Thank you for joining ![]() Code: ^([a-z0-9\.]+)(-[a-z0-9]+)? - (.*) RE: LDInspector - Stefan Frenz - 2021-04-24 (2021-04-24, 14:43)N. W. Perry Wrote: 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. Hopefully with the above examples I understood it the way you mean it. ![]() ![]() RE: LDInspector - N. W. Perry - 2021-04-24 (2021-04-24, 15:09)Stefan Frenz Wrote: Hopefully with the above examples I understood it the way you mean it. Yes, that sounds just right. ![]() So I'll adapt my model naming to use, e.g., 700.1-1. RE: LDInspector - Stefan Frenz - 2021-04-25 Thank you Orion and N.W.Perry for your input. I updated the current version of LDInspector accordingly. RE: LDInspector - N. W. Perry - 2021-04-25 (2021-04-25, 7:50)Stefan Frenz Wrote: Thank you Orion and N.W.Perry for your input. I updated the current version of LDInspector accordingly. Works great! RE: LDInspector - Stefan Frenz - 2021-04-25 Thanks for the feedback! ![]() LDInspector version 0.5 - Stefan Frenz - 2021-09-24 Today I released version 0.5 as current version, main changes since 0.4 are:
Thanks again for all contributions and feedback. LDInspector version 0.6 - Stefan Frenz - 2022-01-19 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. LDInspector Windows installer update - Stefan Frenz - 2022-03-15 Thanks to Jaco for reporting the broken Windows installer, it should be fixed now. RE: LDInspector Windows installer update - Jaco van der Molen - 2022-03-16 (2022-03-15, 16:53)Stefan Frenz Wrote: 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.0.2/openjfx-13.0.2_windows-x64_bin-sdk.zip and that worked. Extracting manualy did work and LDI starts RE: LDInspector Windows installer update - Stefan Frenz - 2022-03-16 (2022-03-16, 6:45)Jaco van der Molen Wrote: I tried the new installer, but it didn't download javafx-sdk-13.0.2 either. Thanks for re-testing and your report. ![]() ![]() 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. ![]() http://www.fam-frenz.de/stefan/ldiinst.zip or another one? |