indeed - I think the only behaviour that would make sense would be to block/drop. If you really need a bypass you can add a wire to the correct place.
Also you would want to visually make the nodes look disabled so you know to turn them back on later etc... - having three states makes that less understandable
3 Likes
Anyway, i thought about my use cases and i would rarely use it, so i hope it's lowest priority - also because of this "interesting" screenshot in the request...
Indeed - it would be higher on the priority list if was requested more politely.
3 Likes
Please can we have a runtime enable/disable of node/wire?
Ps incase anyone reads this and mistakenly thinks it was me who posted the "idiots" - it wasn't - and they'd be idiots 
Yes. We will add an option to the Node edit dialog to disable/enable the node. It has been asked for plenty of times over the years and some of the reasons for not doing it have slowly disappeared as we've made other changes.
As has been well discussed, we are still not at the point to consider the wires having properties.
@goofball - Implying the project maintainers are idiots in your very first post to the forum is not a great start. I look forward to your future contributions to the community - but please think about your choice of language.
1 Like
If this facility was to be implemented - then I think this is the requirement spec
My use case would be to ease debugging/development - you could just duplicate an existing node and wire it in parallel to existing one - deactivate existing one and play around with new node - then either keep new node or revert to old one (but leaving the other one deactivated for future use)
These are both great points -- I agree that dropping the msg object is the only really valid use case, and I would think that it's the simplest to implement in a generic way (so custom nodes don't have to add logic to handle the disabled state).
Every node is presumably placed into a flow to do something, which generally means it will modify the msg data as it passes through. Some exceptions are:
- the "no-op" functions some people use to coalesce and/or route wires (by def, already a pass-thru)
- storage nodes that have the side effect of saving information but not changing the msg (although these types of nodes are "sinks" that consume the msg and don't need to pass it on anyways)
- nodes meant to drive sensors/displays/motors/lights (blocking the msg would disable the action from reaching the device -- generally also would be a sink)
So what am I missing? If I bypassed almost any one of my nodes, the next node wouldn't receive the msg formatted the way it was expected, and at best would not know what to do with it -- at worst, it would make a bad decision based on the "missing" information that the disabled node was supposed to provide.
1 Like
Personally I hope it's possible to operate this disabling at runtime. I.e. no modification or deploy.
If not then perhaps a clickable toggle node that can be placed in the wires to simply inhibit message flow so that at runtime, we can interrupt flow (to say break a loop or suppress something temporary without modifying flow)
As for what and how, my thoughts on disabling a node would be any/all inputs and outputs would not be triggered (if possible in a generic core and common (non breaking) way that operates the same on all existing nodes).
If the wanted behaviour is "deploy-less", this can already be done using an inject node and a gate-like node (or a custom function node that would retain its state as opened/closed) .... ... inject a msg, which closes or opens the gate which will drop or forward the msg according to its open/close state ...
So maybe the "deploy-less" feature could be some kind of "inject" node with an input. Clicking the button would drop any incoming msg ... I think it would be maybe easier to implement and could be later (in future releases) expanded to a full "gate" node like some contrib nodes I've seen: responding to close/open actions based on msg properties, letting go X msgs at a time etc ...
The only drawback I can think of for now is that buttons are meant to be displayed instead of inputs (like the inject node) or instead of outputs (like the debug node)... where would the button be drawn ? top of the node ? ...
I am aware of this but it's clunky and not built in.
I don't think an inline clickable toggle (without injects and without flow or global state) of some kind would take much doing. Effort vs benefit is decent.
As for node disable, I expect that probably will be a deploy thing but if possible at runtime then that would be a great benefit.
That's why I propose it to be a built-in node: some kind of gate node with a button to open/close the gate.
After all, more than disabling nodes we're talking about disabling a flow after a given point ... that point could be a special gate node with a button.
Ah miss read. Sorry. Yes. I said something similar on my first post in this thread. If the gate had 2 outputs, the 2nd could provide alternative msg flow path (for debug or emergency situations- off the top of my head).
But yes. Definitely built in and definitely runtime :).
Ahh but if you are using it for debugging you would have to add the nodes, connect the wires, deploy and then press the tab...but wait, I need to turn off another node...add the node, connect the wire, deploy, press the tab and test.
Or I could disconnect the wire, deploy, test
Or if you can disable the node - open the node, disable it, test.
I'm actually pretty happy disconnecting the wire and testing.
That's fine if it's just one wire. If it links to several or stretches down past others (i.e. not obvious where to reconnect).
It's just not the ideal tbh. I favour a more elegant solution.
What you're saying is akin to deleting a line of code as opposed to commenting it out.
I'm not sure why so many people are ready to accept status quo when we can have more tools in the virtual tool bag.
I can think of several ways to no-op a node.
-
- Stick a no-op function into the wire into the node you want to turn off: payload="";return msg;
-
- Break the wire to the node.
-
- If you want it dashboard switchable function, use a switch or button to set a variable then test the variable in the no-op function or a switch node.
What I can't think of is, why?
- If you want it dashboard switchable function, use a switch or button to set a variable then test the variable in the no-op function or a switch node.
Then use a link node to collect all the wires. To break the link just double-click it and link to a null link that goes nowhere. Or fan-in to a link node, link to a switch then fan-out through another link.
Hi @SteveMann, thanks for the comments but if you see the gif I posted in this thread yesterday you would see I'm not looking for workarounds and it's not like I haven't thought of every one of the workarounds offered by people, it's just that they don't fit.
Untill someone can tell me how to halt flow of messages at runtime
- without adding some combination of inject & flow or global flags
- without modifying / deploying (either breaking wire or adding a noop)
...then it doesn't fit.
I don't think a debug switch/gate node is a big ask and I believe it will be well used. A simple and effective node that would simplify many debug / bypass / link-out situations without the need to modify a flow or litter it with injects and context flags.
1 Like
Actually @SteveMann you have given me a thought.
To avoid adding a new node to the default pallet, the link node could be modified (in a none breaking way / backwards compatible) to have a runtime toggle that enables/disables flow of messages. That would satisfy the requirements 
Ummm, why not just insert the following as the first line of the node you want to disable:
return;
or
return null;
st
Like an enable pin on a chip?
