Scheduling objects

[pjatelier]

Hi

I have created some panels that i need to schedule the length.

The object is created by selecting two archicad profiles. one for profile and the second for the plan shape.

The idea of scheduling is to read the length of bounding box and rewrite A or B parameter.

Is it possible can anyone help? Thanks...

[MetalFingerz]

Hi @pjatelier ,

It is possible, you would need to put in the Main script something like :

A = Profile length

B = Plan shape length

And then in the Parameters script, you would need to add :

Parameters A = A

Parameters B = B

The A and B values should then reflect the dimensions you want.

Not possible, see @runxel 's reply

[runxel]

It is actually not possible (!).

The request of the bounding box of a profile from the profile manager is not permitted in the parameters script, so you can't do that.

A stupid workaround I'm using is to show the bounding box in the UI, with two boxes below, that the user has to fill in manually. As I said, it's stupid.

[MetalFingerz]

Hi @runxel ,

My bad I read it too fast, I hadn't thought of taking info from the bounding box.

[pjatelier]

Ok, but i dont agree on that

but i have got it for very short time. I have created separate value L.

Then when i run the script with debbuger with brakepoints L = the length of bounding box.

Sadly when the script ended L is not defined ones again. I need the way how to save it in to the object. PARAMETRES does not work or may be i use it wrong....

I think it is even possible to get geometry of the profile and put in to the 2d code. Have a look at the link

https://gdl.graphisoft.com/gdl_other_docs/profile-general-usage-and-limitations

here is the part form the code when i am getting the length of the bounding box....

DIM profile_bounding_box_22[]



BREAKPOINT 1
profile_x_size_22 = 0.0
profile_y_size_22 = 0.0



BREAKPOINT 1
req_result_22 = REQUEST ("PROFILE_DEFAULT_BOUNDINGBOX", var_22, profile_bounding_box_22)
IF req_result_22 > 0 THEN
BREAKPOINT 1
profile_x_size_22 = profile_bounding_box_22[3] - profile_bounding_box_22[1]
profile_y_size_22 = profile_bounding_box_22[4] - profile_bounding_box_22[2]

ENDIF
PARAMETERS L = profile_x_size_22
BREAKPOINT 1

[runxel · Accepted solution]

Yeah, because it does not work 😉 If you do not believe me then just look in the manual.

Of course you can request the BBox and then use it in the 2d script for whatever you want, but you can NOT use `parameters` on that bad boy.

[Barry Kelly]

I don't know if this will help but never just say ...

PARAMETERS L = profile_x_size_22

You should say ...

L = profile_x_size_22   !!! this sets the value of the parameter for use in script

PARAMETERS L = L   !!! this set the value of the parameter in the parameter list.

You actually need to set the value of the parameter to be used in the script as well as setting the value in the parameter list.

I think that is because setting value in the parameter list will not have any affect until the next time the script is run.

Barry.

[Lingwisyer]

Has there ever been input into why the command is disabled in the Parameter Script?

[Barry Kelly]

Many commands do not work in the parameter/master scripts.

Form something like 'scale', I can (kind of) understand because it is the same object with the same parameter script in different views of the plan at different scales but at the same time.

So the scale can only be determined in the 2D script when you actually see that object at that particular scale.

But something like a bounding box confuses me as this is just a size (distance) and that should be the same all of the time.

Barry.

[runxel]

---

@Barry Kelly wrote:

But something like a bounding box confuses me as this is just a size (distance) and that should be the same all of the time.

The reasoning behind this was to prevent the possibility of non-terminating loops. Like you depend on A and B but somehow make a loop where two values fight against eachother. At least this is how it was explained back then to me by GS.

While I can understand this, I think it is the wrong way, or at least there could have been different ways to prevent that. Or in other words: What we would need is a special kind of parameter that can not be used for calculations inside the object, but is for scheduling only.

This also makes me wonder if we will ever get the possibility of properties in relation to objects' parameters.