LDCad 1.5 Beta 1 (win+linux)

[Roland Melkert]

Hello all,

It took over a year since 1.4 Beta 1 but I'm hoping it is worth the wait / time spend.

For those who somehow missed the massive 1.5 Alpha thread on the forum, the major new features of 1.5 are:

Detachable color and part bin windows, of whom you can have multiple instances or none at all.
Extensive (optional) LDraw source window, with full nested editing support and a growing selection of line type property editing dialogs.
LDraw file reloading and external changes detection, and you can finally close files now.
Library part (shadow) editing, mostly intended for myself in order to add part snapping info so it is disabled by default and far from a full LDraw part editing solution.
Compressed (e.g. complete.zip) library support.
Single instance protection.

There are also loads of minor improvements etc, some of which are:
Better scrollbar handling
Bin window(s) can be used at a smaller width.
Part bin windows can render vertical or horizontal orientated.
And many more tweaks and adjustments etc.

I also added almost 600 new part snapping files to the default shadow library including info for doors, windows, windscreens, fences, bars, antenna's, plane parts, boat parts, minifig hats/hair and minifig accessories. Do note some (especially the doors and windows) need some additional work as I'm not sure how they behave/fit in real life any help on that is welcome.

Here are a couple of screen shots showing possible window configurations.

The 1.5 mascot example

An alternative layout

Editing shadow (snap) info

And I will add a new youtube demo clip later, if there is something particular you would want demonstrated feel free to ask.

As always the new version can be found at
http://www.melkert.net/LDCad/download

The windows setup version can be used to upgrade any previous version including ones installed by the AIOI.

I will update the documentation on my website to reflect the newest version in the next couple of days / week. For now the only thing you might need to know is how to dock windows. This is done by holding down 'ctrl' after you position the loose window roughly at the place you want it to go.



Lastly there might still be a problem with occasional crashes during closing the program at seemingly random intervals. I have tried a number of things to fix this and I haven't had a crash since the last adjustment myself, but as it might sometimes take days between occurrences I'm not sure it's really fixed.

So if you do have a crash on close down, please send me the contents of the logs folder as I added some extra messages to help pinpoint the crash location. The crash it self is relatively innocent as it will only result in a failure to write/update configuration files as it happens fairly late in the shutdown procedure.


Hope you like the new major version, any feedback / questions / suggestions are welcome.

[Jason Smith]

I'm loving it so far Roland, thank for all your continued hard work.

I did my usual dark mods to the gui, really enjoying the flexibility with the layout now.

   

[Owen Dive]

Nice work.

Here is the layout I find most useful:


Once I get sufficiently inspired, I'll make some icons for the toolbar functions that are missing them.

Owen.

[Jason Smith]

So I imagine if I fire up my second monitor again I should be able to drag all the tools to one side and have a full editor canvass on the other side?

[Jason Smith]

Okay, I'm sure I've missed the answer already somewhere but how do you lock the newly placed windows so they remain on startup. Also would locking that get rid of the top window header with the close button as you can see in my above ss.

EDIT: I have clicked on the "Lock docked Windows" in the GUI menu but it doesn't do anything.

EDIT2: I'm clearly doing something wrong as my main model panel (top right) gets buried and so does my compass.

[Jason McReynolds]

...how do you lock the newly placed windows so they remain on startup.

If I create a new window, docked or just floating, it appears again the next time I open the app. Maybe try uninstalling and re-installing this beta version.

Also would locking that get rid of the top window header with the close button as you can see in my above ss.

"Lock docked Windows" just prevents you from dragging the docked windows you have somewhere else, you can still re-size them though. Also, if you dock a window it gets rid of the header bar with the "X" button. I haven't played with it much, but just did some testing and you can see a screenshot of what I threw together for testing. If I close and re-launch, they all come back.

   

[Jason Smith]

Played with a new install and same thing. I can't get rid of the header on top of the new windows probably because the windows aren't docking or sticking, not sure what they're supposed to do.

3 images attached.

1st - windows setup before closing, 2nd - Opened after closing. 3rd - With model open, you see the compass just peaking out on the bottom left and the upper right panel is hidden under the parts window.

[Jason McReynolds]

Played with a new install and same thing. I can't get rid of the header on top of the new windows probably because the windows aren't docking or sticking, not sure what they're supposed to do.

3rd - With model open, you see the compass just peaking out on the bottom left and the upper right panel is hidden under the parts window.

Based on your screenshots, your windows aren't actually docked, they are just floating, and if they are floating they will cover up the compass and the session panel. If you want the compass and the session panel to be visible, you'll have to dock the windows and that will "push" them out. To dock a window, get it close to a side where you want it and then hover the mouse over it, press ctrl and then left-click and drag it to the side you want to dock it to (FYI, this is mentioned in the first post by Roland ). That should dock it and get the header out of the way. It will also push the compass and the session panel into view.

1st - windows setup before closing, 2nd - Opened after closing.

As far a why it's not saving the layout, I don't know. I set mine up just like your screenshot and when I closed and then re-opened it they were all still there and in the same/correct positions. For information, I'm running this on Windows 10.

[Owen Dive]

Those windows aren't docked: they're still floating, but you've resized them to look as though they're docked.
To dock a window, hold down CTRL while you're placing it.
When they're docked, they won't cover up the compass etc.

I can't speak for the repositioning on startup though. But that problem should fix itself once the windows are docked properly.

Owen.

EDIT: Beaten to the punch, it would seem.

[Jason Smith]

Thank you Jason, the control method worked and I'm a fool for not reading it in the first post. The windows also persisted when opened again so I guess they must need to be docked to remain in position. Wow, all this cause I didn't read a line... To be newbie friendly I vote for a simple right click dock option.

I'm having a lit bit of trouble placing a couple side by side, they just want to go full width, I'll keep playing.

Thank you as well Owen.

[Milan Vančura]

Hello Roland.

I was curious what is the difference between last Alpha and this Beta and I must say I'm fascinated! Of course, because of the snap info editor. It was easier to add missing snap info to the part then to place it manually to minifig's hand. Great!

One does not need to start MLCAD any longer and the created snap info is ready to use immediately, with no LDCad restart, no reconfiguration of ldraw library paths etc. I simply have two models open: the main one and the one with the part to fix. That's great not only for the main work but even for testing of the snap info correctness.

Unfortunately, I was not able to save the new information in any way then. Is that a bug or I missed something, please?
My workflow:

Saving:
1. turn snap editor on and click on the "Edit" icon of the desired part
2. new model for this part is open, add/fix the snap info there
2a. LDCad warns me that the original snap info comes from the zip file and so I'll have to save the result elsewhere
3. pressing "ctrl+S" does not cause any error message but saves nothing (expectable, after that warning, but some message would help here)
4. "File"->"Save as" menu item is grayed out so I cannot save it under another name or path
So what to do?

My workaround attempt:
Copy desired source file lines to the clipboard and edit the shadow file in the external editor (add header lines and save it to the parallel path as suggested in shadow/readme)

Using:
How to use that file? The ldraw configuration dialog does not allow two shadow paths for one library line. I can neither add another line with the same library path but different shadow path. Note this is a different case than with Unofficial parts: I have edited the info of the official part so (I believe) this info must be "coupled" with the official library of parts.
So I used a trick: a copy (symbolic link) of ldraw directory on the filesystem. But that does not work, too. The new snap info is simply ignored. Moreover I do not want to have such symlink as a permanent solution

So far, it's easy to fix the snap info but I'm able to use only that what I created in the current editing session. Help, Roland!

Edit: The example file I created is attached now. To check if I understand the mechanism correctly.

[Trevor Sandy]

This is a excellent exchange on expected usability.

I too struggled to understand the docking procedures on my first experience - I found it in an exchange on eurobricks somewhere.

I imagine there are probably very good reasons why LDCad's docking functionality was implemented in a very non-standard manner - like having your car's accelerator on the paddles behind the steering wheel - but to the unsuspecting user it can often be painful.

I also vote for a simple click-and-drag dock/undock function. I also vote for a solution that can undock outside the application window.

[Philippe Hurbain]

Hi Milan,
Your problem is that you try to edit the zipped version of the shadow library, and LDCad can't save your modifications in this format (here I got a warning telling me about the problem). What you must do is to open the shadow library file as a zip file (offLibShadow.csl in %appdata%\LDCad\shadow\offLib), extract its content in a folder, then change library location in LDCad to point to this folder (prefs->ldraw->search library paths).

[Roland Melkert]

As far a why it's not saving the layout, I don't know. I set mine up just like your screenshot and when I closed and then re-opened it they were all still there and in the same/correct positions. For information, I'm running this on Windows 10.

This might be a Linux only issue as I noticed before the main application window sometimes starts very small on xwindows. This probably caused the saved window positions to be truncated to keep them inside, I'll look into this issue.

[Roland Melkert]

So I imagine if I fire up my second monitor again I should be able to drag all the tools to one side and have a full editor canvass on the other side?

At the moment this is only possible if your (dual head) graphics card supports it and you stretch the application window it self across both screens. I do plan to add the possibility to open a second os level window containing a second OpenGL context / panel in a future version though.

I myself have two screens but I usually end up using the second to display the building instructions site/pdf so I didn't think it would be really needed

[Roland Melkert]

I imagine there are probably very good reasons why LDCad's docking functionality was implemented in a very non-standard manner - like having your car's accelerator on the paddles behind the steering wheel - but to the unsuspecting user it can often be painful.

As far I know the ctrl key usage is fairly common, only difference being it usually prevents auto docking during dragging. Something I found very annoying as the window will jump all over the place, so I inverted the key sort to speak.

I also vote for a solution that can undock outside the application window.

This is something I would like to add at some point. At first I was thinking to keep it for version 2.0, but as I don't see myself starting from scratch anytime soon I'll probably try something in 1.7 or something

[Roland Melkert]

They way Philippe wrote is the intended way of editing shadow files.

I usually have the official library compressed and the shadow library non compressed during shadow editing. This way you will be sure no official files are save to disk (this will otherwise happen when LDCad e.g. corrected the case of a type 1 line reference).

The example file I created is attached now. To check if I understand the mechanism correctly.

I somehow missed that one while working through the accessories group.

You info looks ok, I would add a bit more detail though, like so:

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 6 5   R 3.5 15] [slide=true] [pos=0 40 0]
0 !LDCAD SNAP_CYL [gender=M] [caps=two] [secs=R 4 13.5] [slide=true] [pos=0 16 0]

And maybe also some hole info for the stud hole. But you version should be enough for most situations.

[Roland Melkert]

I was curious what is the difference between last Alpha and this Beta and I must say I'm fascinated! Of course, because of the snap info editor. It was easier to add missing snap info to the part then to place it manually to minifig's hand. Great!

Beta 1 has 33 bugfixes over Alpha 4 and mainly adds part editing feature and has some part snapping meta tweaks. You'll find a full listing of changes in the docs\changeLog.txt file.

[Trevor Sandy]

How can I change the large font size in the main window center footer area?

In main.gui, startMenu_cap looks about the same font size but changing it does not affect the center footer area.

[Roland Melkert]

It's currently not adjustable as it size is the result of the other text using two lines. It's also the only text not rendered using OpenGL but plain GUI (wxWidgets) components. I have been considering an on/off option for the whole status bar after I add hint balloons though.

[Philippe Hurbain]

Great job on connectivity editing! It's a plasure to be able to define connectivity and test it at once in the same session.

I added connectivity to a few parts that missed it, zip file attached (is it the best way to share such information?).
One thing mildly bothers me: when you press insert to duplicate a snap meta, the new copy doesn't inherit it's parent parameters (this also annoys me for flex part control points)

Some notes on the parts I edited:
- arms of the 2717 Technic seat are not wide enough, that's why the connectivity cylinders poke inside.
- The Technic Chain Tread 38 connect easily together, but if I cap the bar part at both ends to limit sliding, I get no connectivity at all...?
- Speaking of sliding, what would you suggest to make these parts slide properly http://www.ldraw.org/cgi-bin/ptdetail.cg.../18942.dat http://www.ldraw.org/cgi-bin/ptdetail.cg.../18940.dat?

[Roland Melkert]

Great job on connectivity editing! It's a plasure to be able to define connectivity and test it at once in the same session.

Thanks, but I must say it was mostly for my own convenience

I added connectivity to a few parts that missed it, zip file attached (is it the best way to share such information?).

Loose parts are ok to mail / or post here, and I'll add them to the default shadow (after some optional tweaks etc) if they are new to it. But if you are very keen on donoting info it might be a good idea to work on a specific category bin group or range of themed parts etc. That way I will avoid them while processing pars myself

One thing mildly bothers me: when you press insert to duplicate a snap meta, the new copy doesn't inherit it's parent parameters (this also annoys me for flex part control points)

The insert key always adds the current 'work' part in its neutral state, unless there is a multiselection active in which case it will duplicate that. To always use duplicate even on single selections you can use ctrl+d .

The Technic Chain Tread 38 connect easily together, but if I cap the bar part at both ends to limit sliding, I get no connectivity at all...?

It might be grid stepping related or a bug, I'll look into it.

Speaking of sliding, what would you suggest to make these parts slide properly http://www.ldraw.org/cgi-bin/ptdetail.cg.../18942.dat http://www.ldraw.org/cgi-bin/ptdetail.cg.../18940.dat?

I would use square cylinder metas (or round ones, as it doesn't really matter in this case) using a group name to limit matches to these parts only.

Thanks for the part info.

[Jason McReynolds]

I added connectivity to a few parts that missed it, zip file attached (is it the best way to share such information?).

Loose parts are ok to mail / or post here, and I'll add them to the default shadow (after some optional tweaks etc) if they are new to it. But if you are very keen on donoting info it might be a good idea to work on a specific category bin group or range of themed parts etc. That way I will avoid them while processing pars myself

What about creating a repository on GitHub for all the shadow parts? That might be the easiest way to tack all the changes.

[Roland Melkert]

What about creating a repository on GitHub for all the shadow parts? That might be the easiest way to tack all the changes.

I have been looking into setting up svn.melkert.net (as I still prefer svn over git) for another reason so I might go that route.

[Jason McReynolds]

I have been looking into setting up svn.melkert.net (as I still prefer svn over git) for another reason so I might go that route.

That's great, a centralized, managed repository could come in real handy. svn, git, whatever, doesn't matter to me.

[Milan Vančura]

They way Philippe wrote is the intended way of editing shadow files.

I usually have the official library compressed and the shadow library non compressed during shadow editing. This way you will be sure no official files are save to disk (this will otherwise happen when LDCad e.g. corrected the case of a type 1 line reference).

Thank you both, Philippe and Roland. I misunderstood the warning because I hoped for a separate path of modified shadow files. However, this is not possible, true? So I extract the zip archive before running LDCad and use the 'diff' command later to find my changes I want to send you, Roland, back.

You info looks ok, I would add a bit more detail though, like so...

OK, I study the documentation

Great job on connectivity editing! It's a pleasure to be able to define connectivity and test it at once in the same session.

Thanks, but I must say it was mostly for my own convenience

Hehe I hope we already showed you the opposite is true! This is THE feature, pushing LDCad to completely new level of usability. Really great job!

One of this feature effects is that more people can contribute the snap data and (hopefully) save some of your time.

About the repository: good idea! I just, if I can, recommend git even you are familiar to svn so far - with git, you do not need to handle user rights (because we'll not need the write access), merging of branches is no longer a headache and, most important for you: you can see every commit as an e-mail (or "submit request") before you apply it to your tree. What saves a lot of time of the tree maintainer.
Of course, I'll respect any repository format you setup, I just wanted to share some years of experience to help you...

[Philippe Hurbain]

But if you are very keen on donoting info it might be a good idea to work on a specific category bin group or range of themed parts etc. That way I will avoid them while processing pars myself

Difficult to tell what I'm going to do next (probably the Technic engine block and related parts), I feel motivated when I need something
But I did a just series that I missed, the Technic buckets - zip attached.

To always use duplicate even on single selections you can use ctrl+d .

Thanks, I'll remember this one...

It might be grid stepping related or a bug, I'll look into it.

No, it was just sheer stupidity, I used a female cylinder insted of clips. Once the male cylinder was capped there was no way to get in Corrected in the zip.

I also considered doing the small tread link, but then I realized that stud3 was missing connectivity (the plates that can connect to tread link through stud3). Is there a good reason not to define stud3 shadow?

Going a bit deeper on stud connexions, I see this message in your stud2 shadow:

Code:

0 //Do note parts using this still need to (optionally) add the hole part of the stud.
0 // This is not done here because in most parts it will extend beyond the stud.

This should actually not happen with stud2, but only with stud2a (if the hole is longer, then the 4-4edge at stud2 base is not needed, so part author should use stud2a).

[Philippe Hurbain]

(probably the Technic engine block and related parts)

Done now, attached!

[Jason McReynolds]

I have been looking into setting up svn.melkert.net (as I still prefer svn over git) for another reason so I might go that route.

That's great, a centralized, managed repository could come in real handy. svn, git, whatever, doesn't matter to me.

About the repository: good idea! I just, if I can, recommend git even you are familiar to svn so far - with git, you do not need to handle user rights (because we'll not need the write access), merging of branches is no longer a headache and, most important for you: you can see every commit as an e-mail (or "submit request") before you apply it to your tree. What saves a lot of time of the tree maintainer.
Of course, I'll respect any repository format you setup, I just wanted to share some years of experience to help you...

I think I might reverse my impartiality a little after Milan's comment and side more with git. I think I was more excited about a central repository than anything. Thought I'd add a little more to Milan's comment about git. Not trying to gang up on you Roland!

I remember when I first started looking at version control software I used svn (was doing Android development). Then I talked to my brother, who had been doing web development for a decade, and he recommended git (he had used svn before). One of the big selling points for me with git was that it didn't litter all the directories with additional files. So, I tried it out, liked it, switched to git and haven't looked back. Haven't really had any gripes about it, but I'm no power user either. Merging is pretty straightforward too. My brother also mentioned Git-Flow (more here), which seemed pretty cool. However, my experience with git has been mostly for personal use. Just sharing my experience too.

[Roland Melkert]

But I did a just series that I missed, the Technic buckets - zip attached.

(probably the Technic engine block and related parts)

Done now, attached!

Thanks do you mind if I change the License to the non commercial one if I use these files for the default shadow. The auhor line will be preserved of course.

I also considered doing the small tread link, but then I realized that stud3 was missing connectivity (the plates that can connect to tread link through stud3). Is there a good reason not to define stud3 shadow?

None that I can think of, I probably thought it isn't needed and might cause unwanted snapping (like with stud4.dat) using the current one on one matching implementation. I'll check to see if it impacts many non plate parts and add it.

This should actually not happen with stud2, but only with stud2a (if the hole is longer, then the 4-4edge at stud2 base is not needed, so part author should use stud2a).

If so the stud2 can define the R 4 4 hole, and I'll move this message to stud2a and also check snap_incl usage. Thanks for the insight Philo.

[Roland Melkert]

Great job on connectivity editing! It's a pleasure to be able to define connectivity and test it at once in the same session.

Thanks, but I must say it was mostly for my own convenience

Hehe I hope we already showed you the opposite is true! This is THE feature, pushing LDCad to completely new level of usability. Really great job!

One of this feature effects is that more people can contribute the snap data and (hopefully) save some of your time.

Did not expect the shadow editing feature to be this popular indeed

About the repository: good idea! I just, if I can, recommend git even you are familiar to svn so far - with git, you do not need to handle user rights (because we'll not need the write access), merging of branches is no longer a headache and, most important for you: you can see every commit as an e-mail (or "submit request") before you apply it to your tree. What saves a lot of time of the tree maintainer.
Of course, I'll respect any repository format you setup, I just wanted to share some years of experience to help you...

My preference for svn is probably the result of me using it as a single user for my daily work. And I might be a bit bias as I didn't like the tortoisegit installation which was massive compared to the svn one. And for some reason git wont store empty folders which is something I use quite often.

But I might try git anyway as this will be a secondary storage after all.

[Steffen]

> About the repository: good idea! I just, if I can, recommend git even you are familiar to svn so far

I just wanted to fully agree here. svn is nearly dead now, and git is a really good choice.
I can warmly recommend the graphical user frontend SmartGit
for it if you don't want to use the command line.
It is free for non-commercial users and far better than gitk.
(And, no, I don't get money from them, just use that for years now in my job.)

[Philippe Hurbain]

Thanks do you mind if I change the License to the non commercial one if I use these files for the default shadow. The auhor line will be preserved of course.

No problem!

I'll check to see if it impacts many non plate parts and add it.

stud3 is used mainly in 1xN plates, tiles and bricks (the latter often Y-scaled).

[Milan Vančura]

Did not expect the shadow editing feature to be this popular indeed

Sure it is. One does not need to wait only but can fix problems himself. Hurray!

For example I often plan my vignettes in LDCad so I want to go through Minifig Utensil and similar categories. It's improved a lot comparing to last Alpha but there is still some room for fixes. The first set of my suggestions is attached:

95528 Minifig Bottle Cylindrical - false snap surfaces deleted, caps added - plus it uses the improved stud2 now
0 ~Minifig Conical Flask - Neck - I improved my previous version using also your comment (even I do not know what can fit to the hole of diameter 3.5 other than electrical pin)
stud2 - I believe there is not a reason why it should not snap to bar-like ends - or is it?

Edit: I fixed my nick in file headers and added a dynamite

[Milan Vančura]

My preference for svn is probably the result of me using it as a single user for my daily work. And I might be a bit bias as I didn't like the tortoisegit installation which was massive compared to the svn one. And for some reason git wont store empty folders which is something I use quite often.

But I might try git anyway as this will be a secondary storage after all.

Setting up the public svn repo and be aware of all attacks and hacks from internet is... Say, something I want to use as a punishment when/if somebody does something really bad to me. That's probably the most diplomatic phrase I could find

With git, nobody does not need any write access to your tree, no accounts at any server just to be able to cooperate with you - and you have even better and easier control what you accept. All you need is to publish a read-only access to your tree. We can send you our commits via e-mail or publish them here, in forum. As you wish, what's more comfortable for you. And we'll see which commits were accepted, automatically.

[Milan Vančura]

more accessories fixed, plus flowers and their stems as a bonus

I have checked all these connections with real parts, to be sure. Esp. those which may be surprising. All of them work perfectly.

Only problem I have is a snap definition of binoculars: each snap itself works well but two binoculars, one behind the other, do not snap correctly. Only one half/ocular (left or right) snaps each time. Can you look at it, please, Roland?

[Roland Melkert]

thanks for the mods Milan,

Only problem I have is a snap definition of binoculars: each snap itself works well but two binoculars, one behind the other, do not snap correctly. Only one half/ocular (left or right) snaps each time. Can you look at it, please, Roland?

I worked for me except it wend to far on one side (is that what you meant) which is caused by it having no caps. The aStud was also using caps=none instead of caps=one or was that on purpose?

I've corrected it, and replaced the identical ones with grid usage.

Code:

0 !LDCAD SNAP_CYL [gender=M] [caps=two] [secs=R 4 13] [slide=true] [pos=0 0 -7] [ori=1 0 0 0 0 1 0 -1 0] [grid=C 2 1 12 0]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 4 6] [pos=0 0 -18] [ori=1 0 0 0 0 1 0 -1 0] [grid=C 2 1 12 0]
0 !LDCAD SNAP_CYL [gender=M] [caps=one] [secs=R 4 2] [pos=0 0 8] [ori=1 0 0 0 0 1 0 -1 0] [grid=C 2 1 12 0]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 6 4] [pos=0 4 0]

I'll take a closer look to all your (and the other posted) files in the thread, and pack a new offLibShadow.csl later this week.

On a side note I've received some crash reports about using the part editor mode combined with the source window. So be sure to save often I think using the window undocked makes it more likely to happen though, not sure though as I'm still looking into this hard to replicate bug.

[Milan Vančura]

I've found the cause of my problem with binoculars: wrong expectation of mine
In other words: you can ignore that report of problem, at least for this version of LDCad. It is a feature request instead.

Because what I did was I tried to move a (slightly) rotated binoculars behind another ones and expected the snapping algorithm to "match both oculars snap points" => correcting the rotation angle of the new part. However, this is not supported in LDCad for any part or set of parts, only one snap connection is used each time - am I correct?

However, what about an improvement of this feature in next LDCad version(s)?
* let the user to choose the snap point (e.g. a center + axis of SNAP_CYL) as an origin of coordinates for part rotation
* let the user to turn on (temporarily) the snap function while moving or rotating the part using keyboard

The idea is to combine both the above, of course: turn the hinge until it snaps the other part of the model etc. Or rotate binoculars until the part snaps to the other binoculars

But not only that. One can use the second feature in case there is too many snap points in a small space. For example, it's difficult, sometimes, to place 40teeth gear on the axle because it snaps too often to pinholes instead of the central axle hole, esp. when viewing the gear from some angles.

[Milan Vančura]

Hope you like the new major version, any feedback / questions / suggestions are welcome.

I'm starting new "subthread" because this is not about snap data/editor

1.
I try to learn Trackball view rotation mode and I must say it's powerful and saves time when one can use it. However, it needs a free space (background visible) at the direction I want to turn to/from. This is not always possible, esp. if I need to zoom in for some detail editing. How do you handle that? Or can you reserve some modifier (like Alt) for this, instead of needing a background visible?

2.
LDCad crashed sometimes for me but very rarely and at random moments. What's the best way to provide you a useful information? Is a core file good for anything for you, for example? Or any debug mode I should turn on?

3.
"Save file" operation is still silent, even in cases the save operation was not successful (trying to 'save' into the zip fie etc.). Can you add a notice to the status bar?

[Philippe Hurbain]

1. Using the right mouse button instead of left one works even if you are not over background.
2. There is a log file (+ 2 older ones) in %appdata%\ldcad\logs

[Owen Dive]

1. Using the right mouse button instead of left one works even if you are not over background.

I try to do all my view rotation with the right mouse button, because Roland has hinted at a future version implementing rectangle-select of parts, which makes most sense to use left mouse button.

Owen.

[Philippe Hurbain]

On a side note I've received some crash reports about using the part editor mode combined with the source window. So be sure to save often I think using the window undocked makes it more likely to happen though, not sure though as I'm still looking into this hard to replicate bug.

Noticed that too, even with a docked window. I hoped to be able to get more significant diagnostic before reporting...

[Milan Vančura]

Thanks, Philippe, for the tip about RMB. That's exactly what I was looking for.

[Roland Melkert]

However, this is not supported in LDCad for any part or set of parts, only one snap connection is used each time - am I correct?

Yes currently the closest/best single connection is used to snap the whole dragged object. It will try to align the Y-axis though and for axles the roll. But still only for that one connection. I'm hoping to do multi connection matching in a future version but I'll have to figure out a efficient, multi threaded, way of doing it.

* let the user to choose the snap point (e.g. a center + axis of SNAP_CYL) as an origin of coordinates for part rotation
* let the user to turn on (temporarily) the snap function while moving or rotating the part using keyboard

How would you think choosing which connection to use should work in such a case?

The idea is to combine both the above, of course: turn the hinge until it snaps the other part of the model etc. Or rotate binoculars until the part snaps to the other binoculars

The current 'official' way of doing that is to select the existing bionculars before adding the second one. This will cause the second one to use the same orientation normal and snapping does the rest. Alternatively you can set a relative grid and press home while dragging a new part to reset it to the grid orientation.

But not only that. One can use the second feature in case there is too many snap points in a small space. For example, it's difficult, sometimes, to place 40teeth gear on the axle because it snaps too often to pinholes instead of the central axle hole, esp. when viewing the gear from some angles.

Yes this kinda annoys me too, I've tried to improve on it by letting sliding part 'stuck' to their last matched hole so it at least wont skip to another when you finally have it at the right place Letting the user choose a snapping point manually would solve this issue, but again how to do it gui wise.

[Roland Melkert]

Noticed that too, even with a docked window. I hoped to be able to get more significant diagnostic before reporting...

It is caused by an outdated source tree cache, but I'm having a hard time finding where it gets out of sync.

Only thing I noticed it tends to happen after file reloads (f5) combined with an undocked window (on top of an editor). any click on a source line might crash it in that situation. It does so more often when used on a slower pc. (e.g. it will crash before the 3rd time trying on my old xp pc).

[Roland Melkert]

I try to learn Trackball view rotation mode and I must say it's powerful and saves time when one can use it. However, it needs a free space (background visible) at the direction I want to turn to/from. This is not always possible, esp. if I need to zoom in for some detail editing. How do you handle that? Or can you reserve some modifier (like Alt) for this, instead of needing a background visible?

Like Philo and Owen wrote, the right mouse can be used for that, even during part dragging etc. And owen is right I might drop the left mouse behavior at some point in favor for multi selection.

LDCad crashed sometimes for me but very rarely and at random moments. What's the best way to provide you a useful information? Is a core file good for anything for you, for example? Or any debug mode I should turn on?

Was this during closing or when you clicked on a source window line as those are currently known issues. A core file is probably not usefull as I compile the releases with all possible stripping and GCC optimize level 2, resulting in virtually no debug info left. As for reporting the most important thing for me is a replication scheme, as it will be very difficult to find a bug other wise. But any pointers are welcome.

"Save file" operation is still silent, even in cases the save operation was not successful (trying to 'save' into the zip fie etc.). Can you add a notice to the status bar?

I did this on purpose thinking you have been warned when starting editing the part, it will display a normal fail message if the writable part can't be saved. But I suppose I can add a 'nag' message so you at least retain the option to disable it again.

[Milan Vančura]

LDCad crashed sometimes for me but very rarely and at random moments.
...

...As for reporting the most important thing for me is a replication scheme, as it will be very difficult to find a bug other wise. But any pointers are welcome.

I have left the basic message only to emphasize the problem: so far I was not able to reproduce any such crash. Only I know is that it is neither the case of those well-known you mentioned in the last comment. For example, LDCad crashed once when I edited the pneumatic hose path and put both endpoints at the same point in the space. Looks as a good example but it is not: I have not been able to reproduce that since that time. And other crashes are even harder to describe.
That's why I asked how to help you with that. Is there any cmdline option or config option to turn logging to be verbose enough it helps you? Or do you want to build a non-stripped binary for me? I'm ready to test it if you tell me what&how to turn the testing/debugging mode on.

"Save file" operation is still silent, even in cases the save operation was not successful (trying to 'save' into the zip fie etc.). Can you add a notice to the status bar?

I did this on purpose thinking you have been warned when starting editing the part, it will display a normal fail message if the writable part can't be saved. But I suppose I can add a 'nag' message so you at least retain the option to disable it again.

I'm sorry I'm not sure I parsed your answer correctly: I know about the warning popup window appearing when one starts to edit a part of a zip file. But I'm talking about a generic problem handling/reporting when the model is about to be saved. That's the problem. Another example, without any zip archive, to be more clear:

1. open/create some model, let's call it modeltest.mpd and save its first version containing one brick at 0,0,0 only
2. in your OS shell or file manager, make the file modeltest.mpd read-only (i.e. simulate a problem with file writing later)k
3. go back to LDCad and add another brick to the model
4. press ctrl-S - nothing visible happens (so the user expects the model is saved but that's not true)
5. press ctrl-W - a popup about non-saved modifications appears. Surprising for the user, he just "saved" the model - but "no problem" - he presses the "Yes" button and believes now the is saved for sure. No error message appears and the model window is closed!
7. load the model back - the first version without the second brick is what you can see, there is no way to see the second version, the one you believed (twice!) it is saved.

Same problem is with the file inside zip archive, only the problem description was more confusing. I hope it is clear now.

[Roland Melkert]

I have left the basic message only to emphasize the problem: so far I was not able to reproduce any such crash. Only I know is that it is neither the case of those well-known you mentioned in the last comment. For example, LDCad crashed once when I edited the pneumatic hose path and put both endpoints at the same point in the space. Looks as a good example but it is not: I have not been able to reproduce that since that time. And other crashes are even harder to describe.
That's why I asked how to help you with that. Is there any cmdline option or config option to turn logging to be verbose enough it helps you? Or do you want to build a non-stripped binary for me? I'm ready to test it if you tell me what&how to turn the testing/debugging mode on.

I strip the exe to keep the filesize down, but using the full debug version is also kinda useless for these kinds of 'random' errors as they often are related to speed or heap corruption. Both of which seem to occur less or none at all when running inside a debug session. Logging is currently forced to the max level (debug) as a result of some extra messages to help find the close down bug.

1. open/create some model, let's call it modeltest.mpd and save its first version containing one brick at 0,0,0 only
2. in your OS shell or file manager, make the file modeltest.mpd read-only (i.e. simulate a problem with file writing later)k
3. go back to LDCad and add another brick to the model
4. press ctrl-S - nothing visible happens (so the user expects the model is saved but that's not true)
5. press ctrl-W - a popup about non-saved modifications appears. Surprising for the user, he just "saved" the model - but "no problem" - he presses the "Yes" button and believes now the is saved for sure. No error message appears and the model window is closed!
7. load the model back - the first version without the second brick is what you can see, there is no way to see the second version, the one you believed (twice!) it is saved.

This is not supposed to go that way indeed, I'll fix / improve it for the next version.

Same problem is with the file inside zip archive, only the problem description was more confusing. I hope it is clear now.

This was the one I was talking about, it is mentioned in the log though I'll add a nag message for it.

[Roland Melkert]

Attached is a new shadow library file (rename it to .csl), it includes most changed/additions made by people other than me.

Thanks to all.

I do have some general notes on the donated files though.

• 6126: I'm not sure about the hole in the 'flame', shoudn't it be a clip and if so doesn't it need one on the other side too? I also moved this info to the subfile.
  
• All the traffic signs can be done by only adding the clip in the used primitive, so I've added that instead.
  
• I redid both flower parts as the perfectionist in me couldn't help be bothered by the tiny offsets. There are some tricks you can use in the editor to obtain orientations from primitive usage (4-4cyli.dat in this case), maybe I'll should make a tutorial for this.
  
• I noticed some of you used multiple meta's to describe the same shape (e.g. a bar with an axle section)., please use multiple sections in the same SNAP_CYL for this. I think I corrected them all but I might have missed some.
  
• Alias, color, moved to, etc parts should never have a shadow file, instead edit the real .dat it references. (Warning: a direct shadow for such an alias can even crash the application when rendered in the bin, as it is a situation I did not account for. Will fix it though).
  
• 2850a 2850b seem to be missing even with the 1501 update in place.
  
• Anti stud in between e.g. the 2x4 plain antistuds should currently not be included (i commented them out in 2717)
  

Don't feel bad/discouraged about the above notes, all info was still quite usable and is very much appreciated.

fun fact: You can use the 1501 library update zip without merging it with complete.zip by just adding it in front of the search paths using the same shadow as the off lib.

[Milan Vančura]

* let the user to choose the snap point (e.g. a center + axis of SNAP_CYL) as an origin of coordinates for part rotation
* let the user to turn on (temporarily) the snap function while moving or rotating the part using keyboard

How would you think choosing which connection to use should work in such a case?

I believe this is possible to do because LDCad already has all functions we need to combine. This is my idea as an example:
Start with a selection. When user presses a hotkey (newly defined) LDCad shows a mark for each snap position in a similar way it already does - a function "show snap points (F11)". Just use a mark shape which shows the orientation of that snap as well - something like a little pyramid pointing to the direction of the snap object axis (SNAP_CYL etc.). Then user can click on such pyramid and local grid is set according to that.

Thanks to the LDCad design, the above is enough and we do not need anything like "a hinge mode" etc. Only what the user needs to be able to do is to find&select the local coordination system.