Another feature script ID error...

darren_13

@opPlane: Parent Id FIZxwPCJn00T9Nq_1.0 used at two non-contiguous points in operation history (Cannot have FIZxwPCJn00T9Nq_1.deleteBodies2.3 between FIZxwPCJn00T9Nq_1.0.SparPlanes and FIZxwPCJn00T9Nq_1.0.0)

I don't know what is wrong with this clearly the ID'd are different because they are unique strings... the ID + i + string should be seen as unique if ALL of those are the same then there should be an issue, otherwise, it should be fine?

Thanks in advance,
Darren

ilya_baran

From the message, it looks like you forgot the "+ i" portion of the opDeleteBodies id, but it's a bit hard to tell without a link to your document.

darren_13

Hi @ilya_baran, sorry here it is: https://cad.onshape.com/documents/95877be3b17f49277e87a2c3/w/b503830fd20472014beb1221/e/4c4431103f44e823aca947dd

the document is located in folder 'wing structure creator' and the script is the second one 'wing structure parametric'

I changed it a little here is the input:

//create the planes for cutting the spars

                    halfPlanes[i] = opPlane(context, id + "IBeamPlanes" + i, {

                            "plane" : plane(halfBasePoints[i], halfNorm[i], xhalfVector[i]),

                            "width" : wingLen,

                            "height" : circRadius.distance

                    });

and here is the new error:
@opPlane: Parent Id FIZxwPCJn00T9Nq_1.IBeamPlanes used at two non-contiguous points in operation history (Cannot have FIZxwPCJn00T9Nq_1.halfSplit.0 between FIZxwPCJn00T9Nq_1.IBeamPlanes.0 and FIZxwPCJn00T9Nq_1.IBeamPlanes.1)

the problem I believe is on line 391



Cheers,
Darren

ilya_baran

Ok, you have a slightly complicated flow structure, so assigning operation ids needs to be done carefully.
The first problem is actually in line 321, where the id should be id + "SparPlanes" + i rather than id + i + "SparPlanes" -- this is backwards from the usual advice of id + index + operation, but in your case, you have multiple for loops in your feature, so you need a unique string id to distinguish them that must come before the iterator variable.  Your other loops do this.

The second issue I can see is where you suspect: the ids in lines 391 and 399. Change
id + "IBeamPlanes" + i   to   id + "loopId" + i + "IBeamPlanes"
and
id + "halfSplit" + i   to   id + "loopId" + i + "halfSplit"
(where "loopId" is whatever you want to call that entire loop) and I think the ids at least should work.

darren_13

Cheers @ilya_baran, worked like a charm.

Darren

yurii_haiovyi

Just my 2 cents, but this thing is so unnecessarily annoying.

NeilCooke

yurii_haiovyi said:

Just my 2 cents, but this thing is so unnecessarily annoying.

We didn't do it this way just to annoy you.

ilya_baran

Actually, @NeilCooke, I have an old email where Lana proposed a much simpler solution and the rest of us shot it down because "yeah, but this will annoy Yurii on the forum in 10 years".

In seriousness, I agree about annoying, but I think it is largely necessary.  The necessity for the id system stems from the fact that downstream features have to refer robustly to topology created by the custom feature, and the hierarchical ids are part of what makes this possible (they also make it possible for features to control somewhat how the references resolve if the feature definition changes).  As complicated as it is for the FS authors, it's far more complex on the inside, but I think that's the price of exposing parametric regeneration as much as we have.

yurii_haiovyi

NeilCooke said:

yurii_haiovyi said:

Just my 2 cents, but this thing is so unnecessarily annoying.

We didn't do it this way just to annoy you.

Sir, I believe you. The question is could it be done better? And the next post actually explains it pretty well.

yurii_haiovyi

ilya_baran said:

Actually, @NeilCooke, I have an old email where Lana proposed a much simpler solution and the rest of us shot it down because "yeah, but this will annoy Yurii on the forum in 10 years".

In seriousness, I agree about annoying, but I think it is largely necessary.  The necessity for the id system stems from the fact that downstream features have to refer robustly to topology created by the custom feature, and the hierarchical ids are part of what makes this possible (they also make it possible for features to control somewhat how the references resolve if the feature definition changes).  As complicated as it is for the FS authors, it's far more complex on the inside, but I think that's the price of exposing parametric regeneration as much as we have.

When you say it's complex I totally believe you. But let's just put it this way, with the current state of documentation it's not easy to figure out that id is in fact an array and one can concat multiple arrays using "+" similar to say Groovy. That's the only biggest point I've tried to make.

ilya_baran

Ok, your issue is different than I assumed.  Out documentation for this is here: https://cad.onshape.com/FsDoc/library.html#Id -- @yurii_haiovyi did you have trouble finding it, or deciphering its meaning?