LDraw.org Discussion Forums
LDCad 1.6 Alpha 3 (win+linux) - 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: LDCad 1.6 Alpha 3 (win+linux) (/thread-21643.html)

Pages: 1 2 3 4 5


RE: LDCad 1.6 Alpha 3 (win+linux) - Roland Melkert - 2016-07-07

(2016-07-06, 22:19)Niklas Buchmann Wrote: I keep losing work because of that bug (and because I'm often forgetting to save...) - weren't there plans for an autosave function at some point?

This is only in 1.6 I hope? Because the copy bug mentioned above is a 1.6 only issue as the affected code doesn't exist in 1.5.


RE: LDCad 1.6 Alpha 3 (win+linux) - Niklas Buchmann - 2016-07-07

(2016-07-07, 15:52)Roland Melkert Wrote:
(2016-07-06, 22:19)Niklas Buchmann Wrote: I keep losing work because of that bug (and because I'm often forgetting to save...) - weren't there plans for an autosave function at some point?

This is only in 1.6 I hope? Because the copy bug mentioned above is a 1.6 only issue as the affected code doesn't exist in 1.5.

Yes, this is in the 1.6 alphas only, I reported that bug in the 1.6 alpha 1 thread. In the previous alpha versions the crashes seemed to happen randomly and I could never find a pattern, the Alpha 3 however seems to crash every single time I use copy or cut.

I know that bug is there and I should remember to save before using copy (or avoid using copy/paste altogether in the alpha 3), but when I forget to and lose work I'm just angry at myself. Wink  After all, LDCad is a great, free piece of software and the new features of the 1.6 version outweigh the bugs for me.


RE: LDCad 1.6 Alpha 3 (win+linux) - Roland Melkert - 2016-07-07

(2016-07-07, 17:34)Niklas Buchmann Wrote: Yes, this is in the 1.6 alphas only, I reported that bug in the 1.6 alpha 1 thread. In the previous alpha versions the crashes seemed to happen randomly and I could never find a pattern, the Alpha 3 however seems to crash every single time I use copy or cut.

I know that bug is there and I should remember to save before using copy (or avoid using copy/paste altogether in the alpha 3), but when I forget to and lose work I'm just angry at myself. Wink  After all, LDCad is a great, free piece of software and the new features of the 1.6 version outweigh the bugs for me.

Ah good to know,

I don't really understand why it didn't crash always from the start as I was freeing the global copy paste options object instead of a local one (the difference one little '!' can make) Smile

I fixed the issue in the latest build.

I'll release an Alpha 3b later this week(end) hoping to collect some more issues first though.


LDCad 1.6 Alpha 3b (win+linux) - Roland Melkert - 2016-07-08

I've released Alpha 3b.

It fixed three semi severe issues, namely:

- '0 Unofficial part' failed to parse  (1.6 only bug)
- Copy now and then crashes the program  (1.6 only bug)
- Clicking a color bin menu item during startup / busy gui could crash the program (1.5 bug)

Hopefully this will be a more stable version.

As always any feedback on the new features / annoyances etc are welcome.


RE: LDCad 1.6 Alpha - Linux users question - Roland Melkert - 2016-07-08

A question to the (advanced) Linux users...

Should I keep compiling releases on (fully updated) Debian 7.5 to maximize compatibility or should I upgrade to Debian 8 ?


RE: LDCad 1.6 Alpha 3b (win+linux) - Philippe Hurbain - 2016-07-13

Hi Roland,
- Looks like DYNHP rendering mode is broken (does nothing)
- I no longer see the "unofficial" tag in parts bin, though option is said to be enabled
- Could it be possible for hide/unhide function not to reset current selection? Case in point, make a selection containing a completely hidden part AND the parts that hide it (eg. an axle 2 between two angle connectors)?
- Last line of 62531s01.dat shadow should be
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 8 2   R 6 16   R 8 2] [pos=-30 -40 -80] [ori=0 -1 0 1 0 0 0 0 1]
instead of
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 8 2   R 6 16   R 8 4] [pos=-30 -40 -80] [ori=0 -1 0 1 0 0 0 0 1]
(currently it prevents insertion of a pin long with bush that fits IRL).


RE: LDCad 1.6 Alpha 3b (win+linux) - Roland Melkert - 2016-07-13

(2016-07-13, 8:18)Philippe Hurbain Wrote: - Looks like DYNHP rendering mode is broken (does nothing)
- Last line of 62531s01.dat shadow should be
I noticed something weird about dynhp awhile ago but completely forgot about it Smile thanks for reminding me.

(2016-07-13, 8:18)Philippe Hurbain Wrote: - I no longer see the "unofficial" tag in parts bin, though option is said to be enabled
Yes it seems the filetype meta isn't read correctly at the moment causing the engine to 'guess' the filetype of even the library parts. Writing those metas has a flaw too so it is basically unusable at the moment, but it isn't too bad in practice though. It will be fixed in the next one.

(2016-07-13, 8:18)Philippe Hurbain Wrote: - Could it be possible for hide/unhide function not to reset current selection? Case in point, make a selection containing a completely hidden part AND the parts that hide it (eg. an axle 2 between two angle connectors)?
You mean when unhiding in the source window (which now allows for partial out of order unhiding). Or just in general when invisible things are selected?


RE: LDCad 1.6 Alpha 3b (win+linux) - Philippe Hurbain - 2016-07-13

I meant in general. Indeed I discovered that I can select hidden things in source window, but it's not so convenient...


RE: LDCad 1.6 Alpha 3 (win+linux) - Niklas Buchmann - 2016-07-13

I noticed two things regarding rotation and placement of parts:

1) Seems to be a bug: When you have a 'floating' part (mouse button held down) you can by default use the arrow keys to rotate it along the two axis of the current editing plane and PGUP/PGDN to rotate it along the normal of the editing plane. When the editing plane changes because you rotate the camera, those keys are updated to reflect the new editing plane. However, if you use the F/S/T keys to change the editing plane, that update does not happen and the rotation keys are still mapped to the old orientation of the editing plane.

2) The 1.6 version seems to have different options under 'editing movement pin' than before and I think it changed for the worse. You still have placement and rotation mapped to the current editing plane (I like to use CTRL+arrow keys to rotate parts, so that's good for me), but moving the selection center (I like to use SHIFT+arrow keys for this) is now mapped to the absolute XYZ coordinates. I think this is very counter-intuitive because you now have to deal with two different coordinate systems at the same time.
What I would like is to have the selection center movement mapped to the editing plane as well (the way it was in 1.5, I think) and possibly a global option of mapping all movements and rotations to the absolute XYZ coordinates.


RE: LDCad 1.6 Alpha 3 (win+linux) - Roland Melkert - 2016-07-13

(2016-07-13, 18:21)Niklas Buchmann Wrote: 1) Seems to be a bug: When you have a 'floating' part (mouse button held down) you can by default use the arrow keys to rotate it along the two axis of the current editing plane and PGUP/PGDN to rotate it along the normal of the editing plane. When the editing plane changes because you rotate the camera, those keys are updated to reflect the new editing plane. However, if you use the F/S/T keys to change the editing plane, that update does not happen and the rotation keys are still mapped to the old orientation of the editing plane.
I think the main thing here is you shouldn't be able to change the editing plane while holding a part in float this was blocked in 1.5 but somehow got unblocked while making the hot key changes. I'll block it again.


(2016-07-13, 18:21)Niklas Buchmann Wrote: 2) The 1.6 version seems to have different options under 'editing movement pin' than before and I think it changed for the worse. You still have placement and rotation mapped to the current editing plane (I like to use CTRL+arrow keys to rotate parts, so that's good for me), but moving the selection center (I like to use SHIFT+arrow keys for this) is now mapped to the absolute XYZ coordinates. I think this is very counter-intuitive because you now have to deal with two different coordinate systems at the same time.
What I would like is to have the selection center movement mapped to the editing plane as well (the way it was in 1.5, I think) and possibly a global option of mapping all movements and rotations to the absolute XYZ coordinates.
Everything should behave as in 1.5 per default, I'll recheck the default mappings thanks for reporting Niklas.