I corrected this issue, but I’m facing to another one!!..when the levels number (n) is odd the shaft family instance is created correctely to the last level, but when n is even, the last instance family is missed…
If I play on the level sequence parameter and vary it from (n-1 to n) or (n to n+1) I can get all my family instances only in the even or the odd case, but I can’t find the correct relation to get all instances in both cases combined
It’s best to fix the problem, not just the outcome. Why is one missing? Are you specifying the number of instances directly? Does it come from another calculation? Do you have a mismatch in list lengths somewhere that is leaving you one level short? If you can determine why it’s happening then we can fix it. Otherwise you’re just applying a band-aid over an issue that you don’t fully understand.
That being said, if it really is just an issue of odd vs even, you can check to see if your value is odd or even before adding an additional instance.
It’s sure I understand my issue and what I’m looking for
Have you take a look to my dynamo file?..I have entered all data that seeme necessary to me
The number of instances come from levels numbers…since each instance is linked to its lower level, that being said for me instances number should be n+1 …if I’ve total Height = 40 m and Instance Height = 4.00m so I should get 10 instances!!
I wasn’t trying to be dismissive. You even said it yourself, “I can’t find the correct relation to get all instances in both cases combined.” You’re asking for a solution to an evens vs odds problem when we don’t yet know what’s causing the discrepancy in the first place.
Your screenshots don’t show any of the node previews (to see what’s going on with your data) or your python code. We also can’t recreate your issue without a model, so all we can do is guess. It’s still unclear what exactly you’re dealing with.
I’m stating the obvious here, but that’s just simple math - obviously even or odd values don’t make a difference here. You’ll have to look at your outputs (and feel free to post new screenshots with node preview bubbles) and try to determine where the breakdown is occurring. It could be a rounding issue where the total height isn’t perfectly divisible by the level height.
I dont know where I wasn’t clear…although I posted my screenshot and my dynamo file (for the Revit model just open new project and run the script!!)
Ok…I put the issue another way:
I made changes in my script and for the moment I guess that the shaft total height value (H_Total) is multiple of the basic Shaft value (H_Shaft)…so levels number is (n = H_Total / H_Shaft),
If n is odd all my instances are created to the last one but if n is even they are not created and I should make changes in my script and set the creation sequance of the levels first group to (n-1) and(n) for the levels second group and vice versa
Note: The reason why I’ve set two levels group is to be able to rotate the even instances of 180 degrees and get my openings in my slabs interposed as shown below
Your script creates geometry from an external source. We do not have that external source to recreate the geometry and match your exact workflow. If we can’t do that, we can’t recreate the issue you are having.
Instead of asking people to download an unknown file (not that anyone thinks you’re attempting anything nefarious, but it will prevent a lot of people from taking those extra steps whether out of security concerns or just laziness) and expecting them to recreate all your work just to get the initial information, it’s much faster and easier for you to include screenshots with node preview bubbles (by which we mean all node preview bubbles, not just the ones you think are important.)
As Jacob mentioned, you can use TakeEveryNthItem from your full list of levels.
The initial family instance point location not coincides with the origin point , so I tanslate it with (x = -3.8 y =-3.8)…so that it coincides to the origin…but when I offset and rotate instances from list2 their locations are changed because their rotation axis is not their center and why they are not placed in their corresponding level?
You either need to take the family origin and rotation into account when moving or you need to specify the axis of rotation for the family (centered) so that you can ignore the origin offset. I would suggest the latter since you can use the calculated center for both the initial and duplicated instances of the family and not worry about any differences in origin.
I believe Archi-lab has a node that allows for a specified axis of rotation, otherwise you can use the API. Are the elements associated with the correct level? You’re placing all the new instances at the same point with no z-offset. You either need to supply a z-coordinate for individual points or translate the elements after they’ve been placed.
I think as said by Mr. Nick you have to try to find a node that changes your family insertion point (which is located at the bottom left BB Min of boudingbox in fact)
I tried to rotate family but as I am doing a move element (I must have an end of transaction pb)
edit: as an alternative, you can maybe create 2 family types (one with your dynamo geometry in one direction, and the other with a 180° rotation of your dynamo geometry)
hoping to help
I’ve not understand why I should delete everything!! …If I do that how I can get my inatances??
I should find a way how to translate the interposed instances after their rotation since their rotation axis is not their center but the bottom left point of their boudingbox !!
I want to confirm the level is correct first. Moving the elements by their X and Y distances is step two, but if the levels aren’t correct then you need to identify the cause and resolve that issue first.
If you want to ignore the stated level issue, give this a shot:
Take the bounding box of any one instance.
Get the minimum and maximum point.
Build a vector from the min point to the max point.
Pull the X and Y values of the vector.
Translate the rotated instances by those X and Y values.
Note: if ever you want a non-180 degree rotation you will need to do some trig based on the rotation angles.
I would recommend making sure that ignoring the rotation everything else is correct first though.
Sorry - missed a few steps as I was focused on the ‘what if not 180 bit).
1-4 as before.
5) Build a vector by the X and Y components
6) Element.MoveByVector to shift the rotated family instances by the vector.
In reality I found the solution before (my graph in post 7 was correct…I had to make a manipulation error I tried it again and it works perfectly)…I wanted to try your approch and see what it will give, it’s perfect but it’s longer than mine…in any case thanks a lot for your help