Also, is there any particular design decision that made you use structures instead of classes or was it a case of a struct is the closest thing to a UDT that you were previously using?
Cheers,
Glenn.
Yes structures were the closest thing to UDT's. I tried to use classes so I could not be limited by the amount of solid objects a model could contain but it was too hard for me so I am sticking with what already works.
I think of these structures like big cubes where one element can see something it is connected to and also know what the other element sees. There is lots of code that looks like this everywhere. After some time it started to make sense and became intuitive
.ang = (pr(.jP(mS)).ang + pr(.jP(mS)).angB) - 90
opsAstdW = fTangent(.angA, .stdW)
'Joined wall
ofsXIn(ref, pr(.jP(mS)).x, pr(.jP(mS)).y, pr(.jP(mS)).ang, pr(.jP(mS)).adjL + aAngOfs)
'this wall
ofsXIn(ref, .x, .y, pr(.jP(mS)).ang + pr(.jP(mS)).angB, .stdW)
ofsYOut(ref, .x, .y, pr(.jP(mS)).ang + pr(.jP(mS)).angB, opsAstdW + pr(.jP(mS)).oMatT(0))
I learned that the whole buiding structure is basically 1 big object because changing one design element affects so many things in related (building) assemblies. The #1 design rule for this project was "no drafting" everything is parametric and is done and undone entirely in the program.
I have done some off the wall things like let the user design the building and then based of the weekly price of lumber, the size of the trucks, the onsite assembly order.....it will figure out the actual sizes of wall panels.
And to top that as if it were not already enough...this site crews assemble the building like 1,2,3,4,5,.....which has nothing to do with the real references that are only internal to the program. Hard to believe but I have seen that get messed up, and like with any new construction system ...no matter how well you think you have thought of everything all it takes is for something like this to happen and it goes bad.