question

Laurenz Peleman avatar image
0 Likes"
Laurenz Peleman asked Mischa Spelt commented

Buildnodeflexscript on node with subnodes

Hello everyone

I am trying to assign some custom code 'on the fly' to the flow level triggers of a FloWorks flow tank, using the following code. The onpassfluidlevel node containing the level trigger code exists of different subnodes, corresponding to each defined level trigger, which require each some specific code.

treenode levelTriggers = getvarnode(flowTank, "onpassfluidlevel");
for (int i = 1; i <= levelTriggers.subnodes.length; i++) {
	string triggercode = "Object current = ownerobject( c ); Other code to add";
	setnodestr(levelTriggers.subnodes[i],triggercode);
	switch_flexscript(levelTriggers.subnodes[i], 1);
}
switch_flexscript(levelTriggers, 1);
buildnodeflexscript(levelTriggers);

What happens now is that, on executing the buildnodeflexscript command, the sudnodes are built (the red Flescript S in the model tree turns black) but the parent node (onpassfluidlevel) isn't. Hence, the code of the subnodes is not called. I tried to write additional buildnodeflexscript statements, either with the node or the flow tank object as argument, but whatever I tried, the parent node couldn't be built. Does anyone know how this can be overcome?

I post this question here because I think the behaviour is not related to FloWorks specifically, but to building nodes with subnodes in general.

Kind regards

Laurenz Peleman

Choose One
FloWorksdevelopment
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Phil BoBo avatar image
1 Like"
Phil BoBo answered Mischa Spelt commented

Does your levelTriggers node have a syntax error?

I just tested this with new nodes in a Processor's variables and it works fine:


flexscript-subnodes.png (138.3 KiB)
· 10
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Laurenz Peleman avatar image Laurenz Peleman commented ·

Thanks for your quick reply @phil.bobo. I don't think there is a syntax error, at least pasting the code manually in the level trigger sheet on the flow tank object does not give a warning message.

I think you added your return statements manually, i.e. without using setvarstr. Could that explain the different behaviour?

0 Likes 0 ·
Phil BoBo avatar image Phil BoBo ♦♦ Laurenz Peleman commented ·

It works fine that way too.

Before executing the script (the nodes have string data):

After executing the scripts:

0 Likes 0 ·
before.png (139.6 KiB)
after.png (141.1 KiB)
Laurenz Peleman avatar image Laurenz Peleman Phil BoBo ♦♦ commented ·

You are able to change the string code of the parent node, something I cannot do (nothing happens if I try). Could the node be protected some way, which causes building to fail as well?

0 Likes 0 ·
Show more comments
Laurenz Peleman avatar image Laurenz Peleman commented ·

Okay, my mistake, I thought it wouldn't make a difference, but apparently it does: the flow tank I am talking about is the flow tank on a flow vessel task executer object, not a 'real' flow tank. I am able to assign code to the onpassfluidlevel of the latter, but fail to do it for the vessel tank.

0 Likes 0 ·
Phil BoBo avatar image Phil BoBo ♦♦ Laurenz Peleman commented ·

The onpassfluidlevel variable on the FlowTaskExecuter's Tank doesn't have its dataType set. Right-click the node and select Node > Add Text Data or set its dataType using code:

treenode flowTank = model().find("FlowTaskExecuter1/Tank");
treenode levelTriggers = getvarnode(flowTank, "onpassfluidlevel");
levelTriggers.dataType = DATATYPE_STRING;
0 Likes 0 ·
Laurenz Peleman avatar image Laurenz Peleman Phil BoBo ♦♦ commented ·

Okay, so that allows me to turn the S black when building. However, in the Trigger Levels sheet of the vessel tank the code fields are still empty after building. Only if I stop the run, explicitly enter the code window and apply or save, the code seems to be 'recognized' when I resume the model run. Hence, the initial problem (on-the-fly code not running) is not solved yet.

0 Likes 0 ·
Show more comments