Detect if a node is connected downstream

[chk]

I have a class that I need to call a function inside, once it is connected downstream to another node. Also I’d like to call another function when that link is deleted. So I need to detect if there is a link from that node downstream… how do I do that…?

[tonfilm]

you cannot detect links at runtime. the only thing you can do is whatever gets connected or disconnected informs your class via a method call/event/observable/callback that something happened.

pseudo code:

if input changed:
    disconnect from current class, connect to the new class
on dispose:
    disconnect from current class

[chk]

Hey nice! Took me a while to get what you’re talking about… so is this what you were talking about?

Thats the main patch, showing at the GetIsConnected method if it is connected.

That’s the ingoing class, listening to a value change being set from outside or actually from the bottom class.

And the bottom class, sending a constantly changing value in.

Using a Stopwatch feels stupid though… is there a suggestion for a better solution?

[tonfilm]

Instead of SetTime, you can just use Connect and count up, and Disconnect to count down, the IsConnected is true when the counter is > 0. and in the other (downstream) class you have to check for changes of the input, like in the pseudo-code above. if the input changes, Disconnect from the old one and Connect to the new one. Also, Disconnect on Dispose…

[tonfilm]

I’ve implemented the basics in the document below, it is packed as re-usable nodes, so you can add it to existing classes easily:

This is the input manager:

This is a connectable class:

IsConnected.vl (55.4 KB)

[chk]

Awesome, thank you! Will take my time to study this approach.

Here is also the patch to the example posted above:
DetectLinkConnection.vl (11.6 KB)

[sebescudie]

@tonfilm Thanks for sharing, this should definitely go in the help browser!

[gregsn]

@chk In your specific use case: Even though you’d maybe never do this, but what should happen when the stupid user of your nodes (you:)

• connects OutClass downstream
• yet another one
• disconnects first one
• disconnects second one

[chk]

I think that your described use case is likely to happen. That’s why my solution does not work in this case (or at least I will hit a wall with this approach really soon).

The example Tebjan posted is really cool in this regard, because every class / node that implements the interface can decide itself what do to with this information. Hope I am getting this right… please correct me if I am not.

[gregsn]

I didn’t dig into your and tebjans solutions. I was just wondering what’s the desired behavior and whether it’s an issue or not.

So, since you mention it could be an issue, give TreeNodeParentManager and TreeNodeChildrenManager a try. It is used inside Stride in order to manage the one (downstream) parent entity of a component, the downstream parent entity of an entity, the downstream scene of an entity and the parent scene of a scene.
It’s also used in Elementa to warn people, if they don’t build tree shaped object graphs.

• connects OutClass A downstream → OutClass A connected (InClass and OutClass A are aware of this one connection)
• yet another one → Parent A connected still (for both OutClass A and InClass only this one connection exists really - the managers shield this away from us), Parent B didn’t get notified of the link. Again the managers took care of it.
• disconnects first one → Parent A gets disconnected, Parent B gets connected
• disconnects second one → Parent B gets disconnected

In Stride e.g. a Teapot has an Entity node inside, which in turn has an EntityManager inside, which is only there to manage the connections and to warn…
In an earlier version it all was patched:

In current version some of it was needed in C#, so it moved there.

Maybe have a look at either Elementa or Stride for an example on how to use this stuff. Rule of thumb:

• the upstream node show have a ParentManager
• the downstream node should come with a ChildrenManager
  the idea here is that in the user patch the tree constructed with connected process nodes has its trunk at the bottom and its leaves at the top of your patch. The parent is downstream, The children are upstream. So up there - when looking downstream - you need the (wannabe) parents - the parent manager only allows one. Down there - looking upstream - you have all the children to manage.
  So a component in stride or elementa comes with a parentmanager only. It has no children to manage.
  
  

Parent and Children manager are somehow generic. Note that they need to be of the same type.
One last note: The way they are used inside Stride (with S&R nodes) is only due to the fact that Entity and Component are Stride types, which we didn’t want to wrap or change. Thus we weren’t able to just add properties that we would allow us to access the managers from the other end of the link and make them cooperate. Thus the S&R. But in your case you probably wouldn’t need that. You could just make the manager available and acces when needed.