Parameters in nested objects

[neilmcallister]

I have all sorts of ideas of things I want to try scripting.  Almost all of them will involve nested macro calls, but in particular, I want to be able to select from different sub-parts.

I have worked out how to do the interface tabs with each script having its own interface tabs.  What I am confused by is how the parameters work.  Are all parameters taken from the parent script?  I had assumed that each script would use its own parameters but it seems that this is not the case.  Does this mean that the parent script has to have parameters available (possibly with generic names) for all possible child scripts?

Ideally, I would like the parent to need to know nothing about the child, but I fear that this involves rather greater encapsulation than GDL provides.

[runxel]

Deep dive (no pun intended) into GDL. Okay, so imagine a door and its handle. What would the handle, as a macro, need to know? Actually not that much, only the position. But that could be done in the parent – transformations propagate through into macros (the stack as well, btw)! So a macro could be very self-sustaining.

But of course this is not entirely true in the real world. You would want e.g. to set attributes, like the surface of the handle. As soon you want to do that, this specific parameter would need to be in both the master and the macros, however not necessarily under the same name, even tho it makes things much easier for the coder, since you need to pass it down. The easiest method is just to "call "myMacro", parameters ALL". This implicit approach would mean the need to have common names in both caller and callee tho. But you can pass them explicitly, too: "call "myMacro, parameters A=myVar".

If you do not pass any parameters then the macro does not get informed about anything. So it really is up to you and your style – and what you want to achieve, of course.

The other way is possible, too. You can return data from the callee by writing their parameter/variable names (coma delimited) after a final "END" in your code. Sometimes you first need the very same variables which you then would use. This can be seen in some GS ootb objects by the way. Macros are getting called twice, but only the second time the macro does add something geometric to the scene.

[neilmcallister]

To continue your door handle analogy, different door handles will need different parameters - a bar handle might need a length, a knob might only need a surface finish.  What I was hoping is that the door didn't need to know what parameters a particular handle needed but just called the UI script of the handle (passing minimal information such as door thickness) which would allow for whatever parameter that handle needed.  That would mean that in the future, I could create a new type of handle that required special custom parameters without having to edit the door to add those parameters - or possibly edit a whole range of door objects that all can use that handle.

Unfortunately it seems that while the door can call the UI script of the handle, the values are stored in the parameters of the door, not of the handle and therefore the door has to have all possible parameters available and pass them (either all or specific ones) to the handle.  I can make this work, it just will make it clunkier - particularly if I have multiple levels of nesting (for example door frame => door leaf => handle)

[runxel · Accepted solution]

Correct. Good summary of how things are. All possible parameters must live in the main object, too. No way to circumvent that.

[neilmcallister]

OK.  Thanks.  That is what I suspected but wanted to check.

[Lingwisyer]

I made a couple of related wishes regarding parameter transfers. Parameter inheritance would make using things such as GS door macros actually viable...