LDraw.org Discussion Forums
LDCad 1.6 Beta 1 (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 Beta 1 (win+linux) (/thread-21955.html)

Pages: 1 2 3 4 5 6


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2016-12-23

(2016-12-23, 18:09)Milan Vančura Wrote:
(2016-12-23, 17:55)Roland Melkert Wrote: Are you both using Linux as I could only replicate it in the Linux version so far.
I'll try to fix this into a beta 1a asap.
The rounding thing might be harder to fix though

Yes, Linux. Debian Jessie (8.6), both 64bit and 32bit versions are affected by these two bugs.

For testing purposes, I do not need them fixed, I just reported them. I simply will use keyboard for rotations during the testing.

I've found the cause it's an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of thing Smile


RE: LDCad 1.6 Beta 1 (win+linux) - Merlijn Wissink - 2016-12-23

(2016-12-23, 18:41)Roland Melkert Wrote:
(2016-12-23, 18:09)Milan Vančura Wrote: Yes, Linux. Debian Jessie (8.6), both 64bit and 32bit versions are affected by these two bugs.

For testing purposes, I do not need them fixed, I just reported them. I simply will use keyboard for rotations during the testing.

I've found the cause its an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of things Smile

Well... I'm using Windows 10 Pro 64bit...


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2016-12-23

(2016-12-23, 18:47)Merlijn Wissink Wrote:
(2016-12-23, 18:41)Roland Melkert Wrote: I've found the cause its an array out of bounds thing concerning the editing pin disk's vertices. So it tries to render vertices from invalid memory. Windows doesn't seem to mind that sort of things Smile

Well... I'm using Windows 10 Pro 64bit...
Seems they improved on that then Smile

I'm regretting adding the 22.5 deg stuff as these bugs are related to those last minute changes. Including the rounding problem mentioned above as rotations through the keyboard were still using integer degrees (22 instead of 22.5 for a single step).

You can get rounding problems using 1 deg steps too, but it should take  longer then only 8 rotations though.

I've fixed both issues and if nothing else comes up I'll release Beta 1a around midnight (CET).

ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2016-12-23

(2016-12-23, 0:50)Milan Vančura Wrote: Other/remaining problems: "+" problem in the Part bin is still there, the hotkey configuration menu does not warn you about a hotkey conflict, the amount of actions there starts being really long and hard for overview; for example even (sub)menu items are not prefixed with same text, like "MENU:" and/or grouped together.
I haven't addressed the shift++ issue yet. I'll try to make the dialog a bit more user friendly in beta 2. You could also try editing the main.hkc file directly most variables are 'understandable' I think.

(2016-12-23, 0:50)Milan Vančura Wrote: Scripting: Please, can you summarize the extension of scripting API or send me your examples used for testing it? They do not need to be perfect and educational, I just need something to start with. You know, there will be a week between Christmas and the New Year, that's a good chance for me to have time for both LDCad and LPub3D.
Beta 1 has the new scripts (seeded) folder which contains a couple of global scripts by default. The samples one uses some of the new api objects (especially the wall and circle macro ones).

I've attached the animation script I used to make the https://youtu.be/34Ypp7HF1Dc  animation. I made that mainly to test / code the new aniTools module.

(2016-12-23, 0:50)Milan Vančura Wrote: This reminds me another question: LPub3D uses archives of LDraw library plus additional directories. Plus ldraw.ini file containing the configuration of that, optionally. I still do not know details but I want to ask you if LDCad knows to cooperate with LPub3D on this so I, the user, will touch the same LDraw library in both programs, including unofficial parts, shadow information etc.?
LPub3D seems to use normal zipped library files so you could point LDCad to the same ones (LDCad supports using zips as is too)


RE: LDCad 1.6 Beta 1 (win+linux) - Milan Vančura - 2016-12-23

(2016-12-23, 19:33)Roland Melkert Wrote: ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.

Sure, Roland. No stress Smile  As I wrote above, I do not need to have this fixed for testing. I do not want to stress you, I just described those bugs as well as I could.


LDCad 1.6 Beta 1a (win+linux) - Roland Melkert - 2016-12-23

As reported above Beta 1 has some problems concerning the editing pin and the new 22.5 deg rotate stepping.

I deemed these problems/bugs severe enough to do a update to Beta 1a only a day later.

It is highly recommended to upgrade to this version asap, sorry if you just upgraded.



(2016-12-23, 20:22)Milan Vančura Wrote:
(2016-12-23, 19:33)Roland Melkert Wrote: ps Milan: I tried making a binary patch using rdiff (linux) for you to try but it gave a >7MB file so you might as well wait on the 1a version I think.
Sure, Roland. No stress Smile  As I wrote above, I do not need to have this fixed for testing. I do not want to stress you, I just described those bugs as well as I could.
No stress, I just hate scratches on my brand new version Smile


RE: LDCad 1.6 Beta 1a (win+linux) - Philippe Hurbain - 2016-12-24

Quote:As reported above Beta 1 has some problems concerning the editing pin and the new 22.5 deg rotate stepping

Sorry to have pushed you to make this last minute change Sad


RE: LDCad 1.6 Beta 1a (win+linux) - Roland Melkert - 2016-12-24

(2016-12-24, 8:52)Philippe Hurbain Wrote: Sorry to have pushed you to make this last minute change Sad

Don't worry about it, the AV was more the result of me wanting to cleanup the pin disc rendering/interaction code in order to make it dynamic (the old one always used 360 segments, the new one takes the current stepping into account instead).


RE: LDCad 1.6 Beta 1 (win+linux) - TestOne - 2016-12-28

Hi all, one question aout snap information:
I've seen that there are some parts with wrong or missing snap information in the shadow library (as an example part 3839b and related have misaligned snap information for the handles, whilst part 3839a is ok). With parts like 3839b it isn't a problem to correct the snap point, but with parts like 58247 which one is the best way to find the right snap position (for vertical stands)? Is the 102° rotation a standard in all minifig accessories (I desumed it from the rotation matrix of already corrected parts), or is there a better way to find the correct orientation?
How do you choose the best orietnation/placement for part snapping when the snap information is missing or wrong? By analyzing the part elements?


RE: LDCad 1.6 Beta 1 (win+linux) - Roland Melkert - 2016-12-28

(2016-12-28, 15:33)TestOne Wrote: Hi all, one question aout snap information:
I've seen that there are some parts with wrong or missing snap information in the shadow library (as an example part 3839b and related have misaligned snap information for the handles, whilst part 3839a is ok). With parts like 3839b it isn't a problem to correct the snap point, but with parts like 58247 which one is the best way to find the right snap position (for vertical stands)? Is the 102° rotation a standard in all minifig accessories (I desumed it from the rotation matrix of already corrected parts), or is there a better way to find the correct orientation?
How do you choose the best orietnation/placement for part snapping when the snap information is missing or wrong? By analyzing the part elements?

3839b is indeed very wrong, 58247 is actually the way it is on purpose as I figured that part is mostly used with minifig hand clips. I will add the other cylinders for 58247 too.

As for finding the orientation of things, I usually try to find the used cyli reference by selecting them one by one in the source window combined with using 'o' in 2D mode.

The whole shadow editing thing is a bit limited as it is essentially 'hacked' in because LDCad was never designed to be a part editor.  It used to be only enabled in my debug builds as it isn't very user friendly to say the least Smile