flaky HASNODE and ALLNODES behaviour

[DBowmanUDA]

I've been making some scripts that add and remove nodes. I have:
DECLARE FUNCTION ClearNodes { UNTIL NOT HASNODE { REMOVE NEXTNODE. }. }.
to clean up after 'experiments' and sometimes it reports 'no node to remove', this can be minutes after the last node manipulation.

Also I have:
DECLARE FUNCTION PrintNodes {
local x is 1.
FOR ANM IN ALLNODES {
PRINT "Node."+x+": "+NodeDesc( ANM ).
set x to x+1.
}.
}.
sometimes this does not see the last added node, but if I call it twice in a row
ADD aNode.
PrintNodes().
PrintNodes().
the missed node is shown in the second listing.

[ElWanderer]

It's probably a good idea to wait until the next physics tick when adding and removing nodes. E.g.

FUNCTION removeAllNodes
{
  UNTIL NOT HASNODE { REMOVE NEXTNODE. WAIT 0. }
}

[Efratror]

I made a test script which created a random amount of random nodes, prints them on screen(and in a logfile) and then deletes them again and loops back till an error is produced or the given time has ran out. It ran for half a hour without any hiccups. Here is the script and the logfile. But here's a quick summery:

for your code:
After REMOVE NEXTNODE. a WAIT 0. is essential like EIWanderer said. But also after ADD nodeX. a WAIT 0. is rather important. It gives KSP and kOS the time to execute the commands. So that there are really nodes or that the are cleared properly.

for the log:
Like i said it ran without any hiccups and produces in total 45003 nodes, printed them and cleared them afterwards.

[DBowmanUDA]

Thanks guys. If you are driving a script from the terminal manipulating
around 15 nodes; adding in a loop and later removing all in a loop it seems
to happen one time in 10-ish.

It sounds like you cannot do much if kOS is calling asynch code that does
not provide a callback...

The node adding is not fast, you can almost feel like you see them popping
in individually as it is. I'll try using the 'wait 0' only before printing
(add many in tight loop-stuffing the pipeline, wait 0, print all) and
change the removeNodes() to look how many there are first and remove that
many.

I don't suppose you all know why nodes are created with a UT but later you
can only get at ETA?

On Tue, Sep 13, 2016 at 9:06 AM, Max Avontuur notifications@github.com
wrote:

I made a test script which created a random amount of random nodes, prints
them on screen(and in a logfile) and then deletes them again and loops back
till an error is produced or the given time has ran out. It ran for half a
hour without any hiccups. Here is the script
https://1drv.ms/u/s!AoYzQWtVwI15hcAY3tn4aSxExyA23g and the logfile
https://1drv.ms/t/s!AoYzQWtVwI15hdQc7ahiQgILxvuCdQ. But here's a quick
summery:

for your code:
After REMOVE NEXTNODE. a WAIT 0. is essential like EIWanderer said. But
also after ADD nodeX. a WAIT 0. is rather important. It gives KSP and kOS
the time to execute the commands. So that there are really nodes or that
the are cleared properly.

for the log:
Like i said it ran without any hiccups and produces in total 45003 nodes,
printed them and cleared them afterwards.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1816 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUV5ENdjzYaeNgUv4oqJ44qG2oTXWZWpks5qpdrjgaJpZM4J6WAG
.

[Efratror]

Because the devs chose for this option, but if you want a TIMESPAN from it. You can use this.
TIME+nodeX:ETA and the suffixes of TIMESPAN are usable.

[hvacengi]

When we add the functionality of #1807, any opcode or function will be able to "yield" to the next update. Since I think the issues stem from the tight integration between nodes and UI update code, a simple one tick yield should fix most cases. Technically, FixedUpdate can run multiple times per UI update, so it would be more complete to instead wait until after the next UI update before returning from the add function.