LDCad 1.7 Alpha 1 (win+linux)


RE: LDCad 1.7 Alpha 1 (win+linux)
#51
(2021-08-12, 18:21)Roland Melkert Wrote: I've uploaded the part I already done, as it might be somewhat helpful.
http://www.melkert.net/LDCad/docs/scriptAPI2

Don't mind the 150 or so "todo's"  Big Grin

Please note there are some Alpha 2 things (input/control/etc) in there not available in 1.6/alpha1

Thanks, Roland! "todo's" are ok - still better than pure list of methods got from the dump function - if I wrote any which worked with ldc Big Grin
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#52
The order of pasted lines in src window (bug or feature?)

I found that if more lines are selected and copied in src window their order after pasting them is as they were marked, not as their "parents" are in. This gives more possible actions if you know about this but it can be very surprising if you don't Smile Is this intentional?

Note: usually the order of lines does not make a difference but some meta commands/comments order is important. STEPs, for example. Or the order of path points.

In nested mode, Path point can be duplicated only if just one is selected

After selecting more than one path point (in nested mode), Ins key does nothing, silently. Same with Ctrl-C,Ctrl-V in edit window. But Ctrl-C,Ctrl-V in source window works. If the submodel with the path is open in the edit window (no nested mode), Ins works.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#53
(2021-08-18, 14:09)Milan Vančura Wrote: The order of pasted lines in src window (bug or feature?)

I found that if more lines are selected and copied in src window their order after pasting them is as they were marked, not as their "parents" are in. This gives more possible actions if you know about this but it can be very surprising if you don't Smile Is this intentional?
This is intentional, mainly so you can reorganize step related things.

(2021-08-18, 14:09)Milan Vančura Wrote: In nested mode, Path point can be duplicated only if just one is selected
This sounds like a bug, I will look into it.

Thanks for reporting Milan.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#54
You might set the following on the wishlist (also for 2.0):

A "H" (something like the "unOff") in the parts bin indicates that the part has a !HELP line. A click on the "H" will show that !HELP line content.

w.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#55
(2021-08-19, 12:47)Willy Tschager Wrote: You might set the following on the wishlist (also for 2.0):

A "H" (something like the "unOff") in the parts bin indicates that the part has a !HELP line. A click on the "H" will show that !HELP line content.

w.

That's a good one.
I've often asked myself: - who, besides part authors, are able to read the Help info?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#56
Not a new issue, but it appears that the part count for the model correctly excludes any part refs that are duplicated due to buffer exchange. However, the parts within a submodel that is duplicated are not excluded (so they are double-counted and the final part count is too high).

Or maybe there's a setting I should check?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#57
(2021-11-10, 19:16)N. W. Perry Wrote: Not a new issue, but it appears that the part count for the model correctly excludes any part refs that are duplicated due to buffer exchange. However, the parts within a submodel that is duplicated are not excluded (so they are double-counted and the final part count is too high).

You mean it goes wrong when a submodel also uses buffer exchange or the whole (non exchange) model is counted?

Could you send me the problem file?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#58
(2021-11-10, 20:04)Roland Melkert Wrote: You mean it goes wrong when a submodel also uses buffer exchange or the whole (non exchange) model is counted?

I meant the second, but it may actually be both in this case.

Quote:Could you send me the problem file?

Yeah, here it is. (Note the main subfile is currently empty 'cos it's not finished yet.)

This model is actually progressively recursive, but I don't think that's the issue as it's present even at the first level of nesting. What I mean is that the submodel for box 1 is a subfile in box 2. Then that box 2 submodel is a subfile in box 3, and so on. So the double-counting starts to add up pretty quick.

I also include per-step part counts in the comments, which also reflect things like u-joints being actually one part instead of three, not counting stickers as parts, etc. So that doesn't exactly match LDCad's count, but I can at least account for the discrepancies.

(By the way, this is the same model in which I was having the snapping issue with axlehole prims, so maybe it will help to recreate that.)


Attached Files
.mpd   8448.mpd (Size: 966.36 KB / Downloads: 2)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#59
(2021-11-11, 1:56)N. W. Perry Wrote: I meant the second, but it may actually be both in this case.

I think I fixed it, how's this:
   

It's still 12 off but that's because of the universal joints.

I'm thinking about introducing a shadow meta to exclude certain parts from counts (e.g. the joint ends, so it only counts the joiners using an alternative part).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#60
(2021-11-11, 21:48)Roland Melkert Wrote: I think I fixed it, how's this:


It's still 12 off but that's because of the universal joints.

I'm thinking about introducing a shadow meta to exclude certain parts from counts (e.g. the joint ends, so it only counts the joiners using an alternative part).

Yeah, that should be right.

A shadow meta could be cool; of course you'd want to have the option to count those parts or not (and maybe whether or not to include stickers, etc.). But it's also true that I should probably be making better use of LDCad's shortcut templates, so that hinges and such are automatically broken up into component parts.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#61
Lately I've been using more and more Stud.io Part Designer to add several decorations to parts. Unfortunately LDCad can't render the produced parts. 

I've read this post from 2019:

https://forums.ldraw.org/thread-23400.html

From what I understand, what Part Designer does is converting the applied image (must be PNG) to Base64 and add it to a META command PE_TEX_INFO. This is very similar to LDraw texmap.

@Roland, would you think that it would be possible to add to LDCad in the future the possibility to parse this command and therefore load decorated parts created with Part Designer?

Thank you.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#62
While Roland is certainly free to do whatever he wants, I'd much rather see Stud.io change use the official METAs for this purpose. Given Bricklink's past track record in cooperating with other community projects, I'm not gonna hold my breath for that to happen though.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#63
(2021-12-10, 16:11)Orion Pobursky Wrote: While Roland is certainly free to do whatever he wants, I'd much rather see Stud.io change use the official METAs for this purpose. Given Bricklink's past track record in cooperating with other community projects, I'm not gonna hold my breath for that to happen though.

I agree with Orion on this.

I'm not saying I will never support it, but it is very low on my to do list.

Technically speaking their LDraw export should convert those meta's into TEXMAP ones.

Especially since their internal format is already LDraw (the thing I dislike the most of studio is the fact most of its users don't even know it's secretly LDraw to begin with).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#64
(2021-07-16, 23:00)Roland Melkert Wrote: </snip>

All feedback/bug reports are welcome.

I am experiencing what appears to be a bug with not being able to zoom in using the '+' key. The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

Is anyone else experiencing this?

Regards.

David
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#65
(2022-02-08, 6:25)David Manley Wrote: I am experiencing what appears to be a bug with not being able to zoom in using the '+' key. The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

Is anyone else experiencing this?

Regards.

David

Actually, yes, now that you mention it. I recently bought a Bluetooth keyboard (with numpad) because the built-in keyboard in my laptop (without numpad) stopped working. When I did that, I started to get behavior like you describe.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#66
(2022-02-08, 6:25)David Manley Wrote: The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

(2022-02-08, 14:02)N. W. Perry Wrote: Actually, yes, now that you mention it. I recently bought a Bluetooth keyboard (with numpad) because the built-in keyboard in my laptop (without numpad) stopped working. When I did that, I started to get behavior like you describe.

This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#67
(2022-02-08, 20:01)Roland Melkert Wrote: This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.

I had a similar problem with, I believe, the \ key, which is also duplicated on the numpad. For whatever reason, the built-in keyboard recognizes those keys as if they come from the non-existent numpad, but the external keyboard does not.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#68
(2022-02-08, 23:27)N. W. Perry Wrote: I had a similar problem with, I believe, the \ key, which is also duplicated on the numpad. For whatever reason, the built-in keyboard recognizes those keys as if they come from the non-existent numpad, but the external keyboard does not.

You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#69
(2022-02-09, 0:17)Roland Melkert Wrote: You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.

Yes, sorry, I meant the forward slash "/".
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#70
(2022-02-08, 20:01)Roland Melkert Wrote: This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.

Thanks Roland, shift + '+' worked. That combination is obvious now that I think about it.

David
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#71
(2022-02-09, 0:17)Roland Melkert Wrote: You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.

I've looked into this a little more, and it turns out that for me, it's not '+' that's the problem, it's '='. I cannot assign that key to a hotkey combination for some reason. If I assign SHIFT+'+' (which is really SHIFT+'='), then the main pad + key works. If I assign just '+', then the number pad + key works. But if I press the Sample button and hit = (without SHIFT), nothing happens. I don't happen to need this combo myself, but it is common to use = without SHIFT as a zoom in shortcut.

My issue with '/' turns out to be something else altogether: I was assigning this to collapse nodes in the Source window (this didn't previously have a hotkey assignment), and I didn't realize that to collapse the current node, you must first re-select that line, even if it's already selected. That may be by design, although it feels like a bug.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#72
(2022-02-11, 14:57)N. W. Perry Wrote: I've looked into this a little more, and it turns out that for me, it's not '+' that's the problem, it's '='. I cannot assign that key to a hotkey combination for some reason. If I assign SHIFT+'+' (which is really SHIFT+'='), then the main pad + key works. If I assign just '+', then the number pad + key works. But if I press the Sample button and hit = (without SHIFT), nothing happens. I don't happen to need this combo myself, but it is common to use = without SHIFT as a zoom in shortcut.
It seems I didn't add the '=' (nor '\') to the key list at all Big Grin


(2022-02-11, 14:57)N. W. Perry Wrote: My issue with '/' turns out to be something else altogether: I was assigning this to collapse nodes in the Source window (this didn't previously have a hotkey assignment), and I didn't realize that to collapse the current node, you must first re-select that line, even if it's already selected. That may be by design, although it feels like a bug.
This is indeed a bug.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#73
I can't remember if I've mentioned this before, but have you ever considered a way to view (if not also edit) the unaltered source of a file? This could be either as a "verbose" option for the source window, or maybe as a separate console window.

Right now I have to use an external editor, and there's no way to "poll" between the two programs. Also, the standard text editor on the Mac does not have a "reload" command (which is its own fault, of course), so I have to manually close and re-open the text file to see changes made in LDCad.

The types of source I most often need to see are a) group information, and b) exact dimensions of generated flexible parts, both of which I know have come up as possible features on their own. But it's also helpful sometimes to be able to quickly find something in an MPD file by using a text search, for example.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#74
(2022-02-17, 18:30)N. W. Perry Wrote: I can't remember if I've mentioned this before, but have you ever considered a way to view (if not also edit) the unaltered source of a file? This could be either as a "verbose" option for the source window, or maybe as a separate console window.

Right now I have to use an external editor, and there's no way to "poll" between the two programs. Also, the standard text editor on the Mac does not have a "reload" command (which is its own fault, of course), so I have to manually close and re-open the text file to see changes made in LDCad.

The types of source I most often need to see are a) group information, and b) exact dimensions of generated flexible parts, both of which I know have come up as possible features on their own. But it's also helpful sometimes to be able to quickly find something in an MPD file by using a text search, for example.

Group information is missing because it has a fairly complicated maintenance scheme. So in practice they are just fully regenerated upon save.

Flex dimensions are visible in 1.7 Alpha as part of the coordinate panel.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#75
Minor typo in the hotkey config file:
Code:
edtiSes_selRemoveRedir=

Probably only affects human readability…
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#76
(2022-03-03, 18:18)N. W. Perry Wrote: Minor typo in the hotkey config file:
Code:
edtiSes_selRemoveRedir=

Probably only affects human readability…

It is the 'remove redirections from selection' function, so I think it has the correct spelling unless I missing something.

It removes alias/coloured/moved/etc parts by replacing them with their targets.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#77
edti  should maybe be  edit ?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#78
(2022-03-03, 23:03)Magnus Forsberg Wrote: edti  should maybe be  edit ?

Didn't even noticed that Big Grin

I will fix that but it would revert to the default binding for anyone who ever changed it.

But I doubt that has been done often.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#79
(2022-03-03, 23:34)Roland Melkert Wrote: Didn't even noticed that Big Grin

I will fix that but it would revert to the default binding for anyone who ever changed it.

But I doubt that has been done often.

I only noticed that because I was going through my hotkeys manually and it was out of alphabetical order. Big Grin

I realized you can learn a lot about LDCad's capabilities by going through the possible hotkey commands…
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#80
(2022-03-04, 3:44)N. W. Perry Wrote: I realized you can learn a lot about LDCad's capabilities by going through the possible hotkey commands…

The hotkey dialog lists the same items, should be more readable Smile
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#81
(2022-03-04, 19:49)Roland Melkert Wrote: The hotkey dialog lists the same items, should be more readable Smile

True, although I found I can more easily search for duplicates across all the groups in the config file. The dialog only shows duplicates within each group. Also, some of the short names in the config file give an extra clue as to their function, especially for those that are similar.

By the way, if anyone is a Mac user and would like my hotkeys file, let me know. Mostly I've changed most instances of CTRL to ALT (which is CMD on the Mac) and changed INS to SPACE. (This is because the Mac has no Insert key, but also I've found I really dig inserting pieces with the space bar!)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#82
EDIT: see post below
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#83
EDIT: see post below
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#84
(2021-12-10, 20:21)Roland Melkert Wrote: I agree with Orion on this.

I'm not saying I will never support it, but it is very low on my to do list.

Technically speaking their LDraw export should convert those meta's into TEXMAP ones.

Especially since their internal format is already LDraw (the thing I dislike the most of studio is the fact most of its users don't even know it's secretly LDraw to begin with).

I believe that Lasse D's Sticker Builder and Pattern folder work with the LDraw standard.
https://brickhub.org/i/apps/sticker_builder.htm
https://brickhub.org/i/apps/pf.htm

Is that correct? I dont have a windows computer to test on currently.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#85
(2021-07-16, 23:00)Roland Melkert Wrote: Hello all,

I finally picked up working on LDCad 1.7 this week.

The first 1.7 test version is available at
http://www.melkert.net/LDCad/nextVer



Please note this is a unfinished potentially unstable version. DO NOT copy it over your existing installation.

New is:

!DATA support
It is fully integrated into the normal way of working, but it might need some additional tweaks based on feedback.

Collada export
This was intended as a blender export, but as I discovered glTF somewhere in the middle it is unfinished and might be removed again later. Unless someone has a good reason to support both glTF and collada.

glTF2 export
This format seems to be the better choice for a blender export workflow.
It is much more complete then the collada export, but still needs alot of work.
I'm very much looking for someone who wants to help me optimize the output for blender import.
It includes texture information, but for some reason blender doesn't use it. I'm still looking into that so if anyone knows more please let me know.


Besides the big features there are numerous tweaks and bug fixes, some of which I forgot to keep track of.

All feedback/bug reports are welcome.

Forgive my ignorance, but is it not possible to install the linux version on mac? I see some threads about using wine and will look into those soon but just had a high level thought about implementation and thought I would ask.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#86
(2022-03-10, 2:02)Cam's Bricks Wrote: I believe that Lasse D's Sticker Builder and Pattern folder work with the LDraw standard.
https://brickhub.org/i/apps/sticker_builder.htm
https://brickhub.org/i/apps/pf.htm

Is that correct? I dont have a windows computer to test on currently.

They use the general LDraw format, but the texture lines use the studio extension.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#87
(2022-03-10, 2:13)Cam's Bricks Wrote: Forgive my ignorance, but is it not possible to install the linux version on mac? I see some threads about using wine and will look into those soon but just had a high level thought about implementation and thought I would ask.

There is currently no native apple version, mostly because I don't use any apple product myself.

The WINE approach seems to work for most people though.

Alternative would be to dual boot into Linux (using a live ISO on usb thumbdrive if needed) or maybe parallels (never tried that but it seems logical).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#88
(NOTE: New stuff is at the end. I realized I made a lot of suggestions scattered around different replies, so this is mainly just to consolidate them in one post.)

Bugs/issues:

Copy/paste settings
  • There are 10 options in the copy/paste dialog but I only found 9 in the config file. The missing one appears to be "copyStripNonVis" (although this does appear to work in the GUI…?).
Hotkeys dialog
  • In edit placement control group: "Negative 54 degree rotation around Z-axis" (all the others correctly say "45 degree").
(By the way, is it me or are (ctrl+)right and left key descriptions opposite of what they really do (pos and neg Y rotation)? I've had to switch these to get the results I expect.)
  • In all the editing pin groups, "Negative movement on the current dead plane axis" seems to always be in the wrong subgroup (Center instead of Movement).
  • I'd like to be able to assign a hotkey to the apostrophe '  but it doesn't recognize it (cmd+' is standard for bringing up a prefs menu).
Animation playback issue moved to new thread.

Feature suggestions:

Paths
  • When dragging a bezier handle, could we maybe shift+drag to simultaneously change the following/preceding handle also? This would allow symmetrical reshaping. (Idea stolen from Inkscape.)
Editing
  • It would be very handy to have a 1-click rotation to that special value of 53.1301/36.8699 degrees (the 0.6 0.8 matrix), which is so central to Technic building. A grid stepping in this amount would be interesting, but I know these should really add up to 360, so maybe this is macro territory? Or maybe the manual rotation dialog could have radio buttons with these and certain other special angles (or even user-defined "favorite" angles)? <- I think the "favorites" idea is my favorite so far. Smile
Header dialog
  • This is very, very tiny…but maybe also trivial to fix. When opening the header dialog and switching to the "tags" tab, there is consistently a delay of 2-3 seconds while, I assume, the category and keywords lists are loaded. Maybe these lists should be loaded only when/if they are opened? because 99 times out of 100, I only go to that tab to set the file type (model, part, unofficial etc.) and don't need those drop-down lists at all.

    On the other hand, for the same reason, maybe the file type meta should be moved to the main page of the header dialog, because its official placement is in the main part of the header? Better still, could it be possible to set a default for the file type?
Rotation steps (NEW)
  • If a ROTSTEP meta appears at the end of a file, could there be an option for LDCad not to add an extra step number? That way, if the last step of a model has a rotation (or cancels a previous rotation), we can use the ROTSTEP function to display it correctly without having an extra blank step at the end of the model.
In the future (NEW):
I just realized that if LDCad 2.0 does come to pass, and if it does support all LPub metas as had been considered, then that means it will support BUILD_MOD, which is essentially identical to the FLOAT meta idea I've been wishing for for so long. Big Grin Big Grin Big Grin

If this is the case, I wonder if it would be possible (either as a user-configurable setting, or perhaps as an option in file cleanup) to comment out the type 1 lines between the BUILD_MOD BEGIN and BUILD_MOD END_MOD tags—in other words, the parts that exist in their temporary state? That way, the file that LDCad saves would contain no duplicate parts nor any helper parts, and thus be immediately viewable in LDView, Stud.io, etc. At the same time, LDCad would still display these commented lines during its own editing sessions.

In fact, at the risk of wishful thinking, this sounds simple enough, and fixes such a long-standing problem, that maybe BUILD_MOD might be able to appear in the nearer future than other LPub metas…? (And it might even be possible to do with the existing BUFEXCHG commands, too…)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#89
(2022-03-19, 18:12)N. W. Perry Wrote: hen dragging a bezier handle, could we maybe shift+drag to simultaneously change the following/preceding handle also? This would allow symmetrical reshaping. (Idea stolen from Inkscape.)
I like this idea, i will look into it for the next next version (Alpha 3/Beta 1)


(2022-03-19, 18:12)N. W. Perry Wrote: It would be very handy to have a 1-click rotation to that special value of 53.1301/36.8699 degrees (the 0.6 0.8 matrix), which is so central to Technic building. A grid stepping in this amount would be interesting, but I know these should really add up to 360, so maybe this is macro territory? Or maybe the manual rotation dialog could have radio buttons with these and certain other special angles (or even user-defined "favorite" angles)? <- [i]I think the "favorites" idea is my favorite so far. Smile
Favorite angles could be an interesting feature. It could be done with macro's too tough as you can assign hotkeys to macro's.


(2022-03-19, 18:12)N. W. Perry Wrote: This is very, very tiny…but maybe also trivial to fix. When opening the header dialog and switching to the "tags" tab, there is consistently a delay of 2-3 seconds while, I assume, the category and keywords lists are loaded. Maybe these lists should be loaded only when/if they are opened? because 99 times out of 100, I only go to that tab to set the file type (model, part, unofficial etc.) and don't need those drop-down lists at all.
I'll have to check but I'm fairly sure (some of) those lists are already loaded on demand. The issue is mainly caused by wxWidgets extremely slow list updates (even when you suppress screen updates), which might be addressed in one of their later builds.


(2022-03-19, 18:12)N. W. Perry Wrote: If a ROTSTEP meta appears at the end of a file, could there be an option for LDCad not to add an extra step number? That way, if the last step of a model has a rotation (or cancels a previous rotation), we can use the ROTSTEP function to display it correctly without having an extra blank step at the end of the model.[/list]
This is mostly a LDraw format problem as the step meta indicates the END of a step so there are always (step meta count + 1) steps in a model.
The step must be counted or you wouldn't be able to navigate (back) to the last step.
Could hide it in view mode though, but not sure if that's really worth all the hassle.


(2022-03-19, 18:12)N. W. Perry Wrote: If this is the case, I wonder if it would be possible (either as a user-configurable setting, or perhaps as an option in file cleanup) to comment out the type 1 lines between the BUILD_MOD BEGIN and BUILD_MOD END_MOD tags—in other words, the parts that exist in their temporary state? That way, the file that LDCad saves would contain no duplicate parts nor any helper parts, and thus be immediately viewable in LDView, Stud.io, etc. At the same time, LDCad would still display these commented lines during its own editing sessions.
There is a macro which does something very similar with the MLCad HIDE meta, maybe you can adapt that?


(2022-03-19, 18:12)N. W. Perry Wrote: In fact, at the risk of wishful thinking, this sounds simple enough, and fixes such a long-standing problem, that maybe BUILD_MOD might be able to appear in the nearer future than other LPub metas…? (And it might even be possible to do with the existing BUFEXCHG commands, too…)
2.0 is very unlikely to be picked up anytime soon given I hardly get to work on 1.7 these days.

The main reason I started a 1.7 is because 2.0 is nowhere near where I wanted it to be.

it's basically just an pseudo HTML 'div' orientated GUI rendering engine at the moment.
   

Don't mind the childish look, it uses hand drawn 'test' textures.

That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#90
(2022-03-19, 20:24)Roland Melkert Wrote: Favorite angles could be an interesting feature. It could be done with macro's too tough as you can assign hotkeys to macro's.

Indeed, although I think the favorites idea might be good enough to offer out of the box. (An extension of this idea might be "project parameters", where the user could select certain often-used values, like colors, rotation angles, etc. that are common to a specific model. But LDCad doesn't really work with project files, so this might be too much.)

(2022-03-19, 20:24)Roland Melkert Wrote: I'll have to check but I'm fairly sure (some of) those lists are already loaded on demand. The issue is mainly caused by wxWidgets extremely slow list updates (even when you suppress screen updates), which might be addressed in one of their later builds.

The more I think about it, it seems that allowing a default setting for the file type is probably the simplest/best. In fact, I think this might have even been a planned feature at one point. And it makes sense, since LDCad is an editor, that most files created by the user will be models by default (and then maybe you could have a check box for whether to add the LDRAW_ORG qualifier).

(2022-03-19, 20:24)Roland Melkert Wrote: This is mostly a LDraw format problem as the step meta indicates the END of a step so there are always (step meta count + 1) steps in a model.
The step must be counted or you wouldn't be able to navigate (back) to the last step.
Could hide it in view mode though, but not sure if that's really worth all the hassle.

Yes, or in this case, STEP meta + ROTSTEP meta + 1. Because I guess the ROTSTEP meta, what, takes the place of a STEP meta in the parser? My idea was that if a ROTSTEP meta (or even a regular STEP meta) occurs at the end of a file—i.e., has no geometry lines following it—then it could be excluded from the count, or alternately take the place of the +1. That way, the only step that wouldn't be counted is the empty extra one at the end, which is just what you'd want anyway.

I know this is a quirk of the LDraw spec, and of course you shouldn't have to re-work your program to account for its shortcomings. But then again, is the last step of a file required not to have a STEP meta, or just allowed not to? Because it seems to me that the last STEP meta of a file only indicates the end of the last step—not the existence of an additional step after it (you'd need to add at least one more part or something to imply that). But I also know that it might be a necessity of the coding process to be able to count the steps correctly.

(2022-03-19, 20:24)Roland Melkert Wrote: There is a macro which does something very similar with the MLCad HIDE meta, maybe you can adapt that?

Perhaps…although the difference is that these would be lines between two metas, and I think the MLCad metas affect only single lines? I could probably figure it out, though.

Thinking about it some more, all that's really necessary would be a commenting out function. You could select some lines in the source and window and just choose "comment out" from a menu. Or, you could have it configurable, where you have a dialog that gives you the option of commenting out all lines that either follow a specific meta (such as MLCAD HIDE or MLCAD GHOST), or are between two given metas (like BUFEXCHG STORE/RETRIEVE or BUILD_MOD BEGIN/END_MOD). Basically, a bunch of boolean options.

Though I do wish that BUILD_MOD (and BUFEXCHG, for that matter) had the fallback built in, so that other tools wouldn't have to adapt to them…

(2022-03-19, 20:24)Roland Melkert Wrote: That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.

I think they are definitely worth exploring, independently of whether you eventually support all of LPub's metas—which are very very many, as you know, and not all of them are of particular importance to an editing program.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#91
(2022-03-19, 20:24)Roland Melkert Wrote: That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.

The only downfall for that is that the develoment of LPub3D has again came to a stop some time ago.
I am uncertain of Trevor is still developing since I have lost contact with him too. I also have no idea if he reads the forums or comments in his Github page for LPub3D :-(

Does anyone have an idea where Trevor is and has contact with him?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#92
(2022-03-20, 15:35)Jaco van der Molen Wrote: The only downfall for that is that the develoment of LPub3D has again came to a stop some time ago.
I am uncertain of Trevor is still developing since I have lost contact with him too. I also have no idea if he reads the forums or comments in his Github page for LPub3D :-(

Does anyone have an idea where Trevor is and has contact with him?

His most recent post here was a year and some days ago, and the most recent updates to LPub3D appear to have been the October before that (2020).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#93
(2022-03-21, 1:08)N. W. Perry Wrote: His most recent post here was a year and some days ago, and the most recent updates to LPub3D appear to have been the October before that (2020).

Indeed. I was helping him test the buildmod feature, but suddenly all went silence.
It was (is) a very promising feature and we got things to work quite nice.
Still a few bugs here and there though.

I have tried to contact him, but he is not responding to e-mail, PM or Github messages.
I sincerly hope he is allright.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#94
(2022-03-21, 12:28)Jaco van der Molen Wrote: Indeed. I was helping him test the buildmod feature, but suddenly all went silence.
It was (is) a very promising feature and we got things to work quite nice.
Still a few bugs here and there though.

I have tried to contact him, but he is not responding to e-mail, PM or Github messages.
I sincerly hope he is allright.

I hope so too!
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#95
This looks like a bug specific to 1.7: The config file is set to 8 decimal places on the clipboard, but I'm consistently getting only 5 when copying values from selection info. I definitely got more decimal places in 1.6d.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#96
(2022-03-24, 4:22)N. W. Perry Wrote: This looks like a bug specific to 1.7: The config file is set to 8 decimal places on the clipboard, but I'm consistently getting only 5 when copying values from selection info. I definitely got more decimal places in 1.6d.

The setting is only for ldraw coordinates but I suppose it is logical to also use it for selection information.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#97
(2022-03-24, 18:36)Roland Melkert Wrote: The setting is only for ldraw coordinates but I suppose it is logical to also use it for selection information.

Never mind, my mind is going haywire. I was sure that there used to be more digits in 1.6, but indeed it captures only 5.

That said, with the default coord precision increased to 6 decimals, it would make sense to capture at least 6 for measured distances, also. (I'm not sure offhand how many decimal places would be necessary for angles to match the precision of the rotation matrix.)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#98
(2022-02-11, 18:56)Roland Melkert Wrote: This is indeed a bug.

Finally got around to fixing this bug, but it turns out not to be a bug Smile

It expand/collapses the current 'hot' node (meaning the one under the mouse cursor) not the selected one.

I did change the hint to reflect this though.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#99
(2022-04-10, 19:22)Roland Melkert Wrote: Finally got around to fixing this bug, but it turns out not to be a bug Smile

It expand/collapses the current 'hot' node (meaning the one under the mouse cursor) not the selected one.

I did change the hint to reflect this though.

Ah, perhaps that behavior will make more sense now!

Here's another thing: it seems like nag message states are not being retained for warnings about shadow editing. I know there are 2 or 3 different messages, but I feel like I've checked "don't show again" on all of them repeatedly, yet they keep appearing.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-10, 22:21)N. W. Perry Wrote: Here's another thing: it seems like nag message states are not being retained for warnings about shadow editing. I know there are 2 or 3 different messages, but I feel like I've checked "don't show again" on all of them repeatedly, yet they keep appearing.

Some of those messages will ask again the next time you start the program by design.

Mostly because they can cause unexpected behavior during usage.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)