[LDCad] Shadow file contributions

[Fredrik Hareide]

Hi Roland,

I have started tinkering with some shadow files for some parts I needed it for and have some questions. 

First of all is it ok that I just add PRs to the github repo?

And second. For this example. Does it matter what orientation the lines are in for the window/door?

[Roland Melkert]

First of all is it ok that I just add PRs to the github repo?

Yes, I'll try to merge it without too long a delay (probably in the weekends).

And second. For this example. Does it matter what orientation the lines are in for the window/door?

It depends on the meta type some account for symmetry while others will snap 'dumb' meaning the dragged part will rotate so the meta xyz matches the destination mata's xyz.

The generic snap meta also has an option for it.

[Fredrik Hareide]

Yes, I'll try to merge it without too long a delay (probably in the weekends).

It depends on the meta type some account for symmetry while others will snap 'dumb' meaning the dragged part will rotate so the meta xyz matches the destination mata's xyz.

The generic snap meta also has an option for it.

Some of the parts I made shadow files for are unofficial. Is that fine too?

[Roland Melkert]

Some of the parts I made shadow files for are unofficial. Is that fine too?

The git repo is intended for official part shadows only. Mainly to spare me the paperwork of keeping them up to date when unofficial parts change.

But you can keep them in a second shadow, or maybe a branch inside your cloned fork of the library until they go official.

[Fredrik Hareide]

The git repo is intended for official part shadows only. Mainly to spare me the paperwork of keeping them up to date when unofficial parts change.

But you can keep them in a second shadow, or maybe a branch inside your cloned fork of the library until they go official.

Yep, they are currently in a branch in my repo. But I opened a PR on it. So can just ignore that then. In my opinion it would be nice to have unofficial here as well since the snapping information won't change much during a parts lifecycle. But thats my opinion. 

I just realized that there is an editor inside LDCad. Haha. I made the first versions in vscode with text only. This will probably be a bit easier.

I found the contributing.md file a bit late.

[Roland Melkert]

I just realized that there is an editor inside LDCad. Haha. I made the first versions in vscode with text only. This will probably be a bit easier.

Notepad is how I edited the first few hundred ones, but that got old very fast

Currently I also use tortoisegit and the git desktop to keep things somewhat workable.

[Fredrik Hareide]

Notepad is how I edited the first few hundred ones, but that got old very fast

Currently I also use tortoisegit and the git desktop to keep things somewhat workable.

I cloned the repo and opened the entire folder in vscode. That worked really well since I could open specific part files with Ctrl-p. Also I get the git history directly in vscode and can do the pushing from there.

Tortoisegir is also good. But depends what workflow you like. 

If you don't want to add unofficial. Are you OK with me hosting a official an unofficial on my github instead?

I do think you should change your mind and start adding unofficial as they are in that state for a long time. Also unofficial files was one of the reasons I chose to transition from Studio

[Roland Melkert]

I do think you should change your mind and start adding unofficial as they are in that state for a long time. Also unofficial files was one of the reasons I chose to transition from Studio

I've been thinking about this.

The main reason used to be maintainability but with the cleaner function introduced in 1.7 Beta1 this is less of an issue.

It also has been asked before and I don't want it to prevent people from donating to the project so I'm leaning towards lifting the restriction.

I only need to figure out an easy way to keep track of info about unofficial parts so when a part goes official the cleaner can detect it and remind me to check them once more.

Maybe something in the history lines like "Initial info for unofficial part ...." followed by "Made official" on a later date. This way the cleaner can detect if those lines match with the current ldraw.org status of the part.

I'll try to setup something soon (in beta2 dev) so for the time being don't let it stop you making shadow content for unofficial parts.

ps:
Did a quick look at your files and I noticed 80015 currently seems to have info for a smaller version of the part.
Also you corrected 86876 to have just 2 anti-studs, it has 3 on purpose though

Thanks for correcting the plate hinge, I forgot about those.

[Fredrik Hareide]

I've been thinking about this.

The main reason used to be maintainability but with the cleaner function introduced in 1.7 Beta1 this is less of an issue.

It also has been asked before and I don't want it to prevent people from donating to the project so I'm leaning towards lifting the restriction.

I only need to figure out an easy way to keep track of info about unofficial parts so when a part goes official the cleaner can detect it and remind me to check them once more.

Maybe something in the history lines like "Initial info for unofficial part ...." followed by "Made official" on a later date. This way the cleaner can detect if those lines match with the current ldraw.org status of the part.

I'll try to setup something soon (in beta2 dev) so for the time being don't let it stop you making shadow content for unofficial parts.

ps:
Did a quick look at your files and I noticed 80015 currently seems to have info for a smaller version of the part.
Also you corrected 86876 to have just 2 anti-studs, it has 3 on purpose though

Thanks for correcting the plate hinge, I forgot about those.

I think that is an excellent idea! That way Ldcad will be a better software. I will keep adding shadow parts and do PRs if you lift that restriction. Will benefit the program for sure  

The reason why I changes 86876 is because it wouldn't snap. I understood the reasoning behind three antistuds but it didn't work in LDcad. Maybe a bug?

[Fredrik Hareide]

A couple of questions

The first one. Is there a reason the connectivity isn't like this? This part often is placed on middle antistuds and this makes the snapping feel better.
   

Second question. I have make a bird with five prints and I want to make connectivity. But the bird is split in half in s01. So there is no common file that has the whole birds connecivity points. Is it ok to put the connectivity in s01 and get "double" connectivity? Or is that a bad idea?
The bird is 3918

Thanks!

[Roland Melkert]

The first one. Is there a reason the connectivity isn't like this? This part often is placed on middle antistuds and this makes the snapping feel better.

LDCad only has 1 on 1 snap point matching, so info on the central tubes will cause lots of unwanted snapping with most parts. But there are exceptions like the 86876 mentioned above.

I'm hoping to improve on this in 2.0 but it is low on my feature list as I always intended the snapping tool as a guidance tool not a full-blown simulation etc. So it basically expects the user to just grid move certain parts to their final destination.

Second question. I have make a bird with five prints and I want to make connectivity. But the bird is split in half in s01. So there is no common file that has the whole birds connecivity points. Is it ok to put the connectivity in s01 and get "double" connectivity? Or is that a bad idea?
The bird is 3918

You can add the data to s01 and change the inheritance mirroring property to none.
   

[Roland Melkert]

The reason why I changes 86876 is because it wouldn't snap.

It has the wrong gender setting I corrected it in my local clone and will sort out the merge later this weekend.

[Roland Melkert]

I have merged your changes.

Some notes:
- You forgot some 'todo' history lines.
- Some antistuds used the square shape instead of round and vice versa.
- 80015 had some duplicate info, I moved most to the subpart.

On a side note I polluted your pr with some other maintenance changes (Still working on finding the best workflow for processing pr's )

Also it might be easier to limit commits once you made the PR. Maybe make all your changes and do a PR once a week and start on another PR while I merge the previous one without having the risk of you adding something new to it at the same time.

PS I will add the unofficial status info to your parts later. Have to modify the shadow cleaning function first.

[Fredrik Hareide]

I have merged your changes.

Some notes:
- You forgot some 'todo' history lines.
- Some antistuds used the square shape instead of round and vice versa.
- 80015 had some duplicate info, I moved most to the subpart.

On a side note I polluted your pr with some other maintenance changes (Still working on finding the best workflow for processing pr's  )

Also it might be easier to limit commits once you made the PR. Maybe make all your changes and do a PR once a week and start on another PR while I merge the previous one without having the risk of you adding something new to it at the same time.

PS I will add the unofficial status info to your parts later. Have to modify the shadow cleaning function first.

Thanks! Yes I could certainly do that. Still learning so I was guess that some stuff was wrong. I'm glad you decided to add unofficial parts!

Looking forward to that change and will do my best to keep helping get more parts out.

[Roland Melkert]

Thanks! Yes I could certainly do that. Still learning so I was guess that some stuff was wrong. I'm glad you decided to add unofficial parts!

Same here, I use svn for all my other stuff. Soe notes i've seen mentioned here and there:

Make your local changes in a new branche, so you van pr that branch later.
Once the pr is made, start a new branch for changes you want to do in the next pr (basically avoid committing to main).
This way your local commits won't show up in a previous (open) pr.
Also sync your fork when I merge a pr or when you just want the latest base (upstream) version, this doc should help:
https://docs.github.com/en/pull-requests...rm=windows

Just some things I read/learned, I'm no git/github expert so maybe others have more/better pointers.

Looking forward to that change and will do my best to keep helping get more parts out.

It's already done in dev, but please don't wait on the new version to make more content.