"Logic Enable" behavior

I have an idea for a new behavior block. My block, called Logic Enable, can be used to deactivate and reactivate other behavior blocks and links between them on command. It works like the Enable block, only this one enables and disables game logic. Here’s how it looks, for the most part:

The Logic Enable Block

The colors and font are not accurate, though. Here’s a list of what each input/output will do:

Note: when I say “link”, I mean the line connecting the inputs and outputs of different logic blocks.

Affect: Anything linked to this output will be affected by the enabling/disabling. A link from this output does not feed into another input. Instead, it attaches onto the selected blocks and links like a tentacle.
Enable: This triggers the reactivation of the behaviors linked to the “affect” output. If the logic connecting to the “affect” bulb is already enabled, nothing happens.
Disable: This triggers the deactivation of the behaviors linked to the “affect” output. If the logic connecting to the “affect” bulb is already disabled, nothing happens.
Out: When this Logic Enable block is used, anything connected to this output is also triggered.
Done: After this Logic Enable block is used, anything connected to this output is triggered.

Inside the block, there will be an option for a delay in tenths of a second.

I also want to request some global changes. When a link is disabled, it should turn darker in color. When it is normal and enabled, it should be the regular color. The same should go for behavior blocks.

That’s all I can think of for now. I hope this gets added in one day.

5 Likes

Isn’t this as if you input it into a switch?

3 Likes

No, since this would be used for things like bundles which can be complex to just turn off (for example our game, it’s possible, and you did it, but wouldn’t it just be easier if you could “disable” a bundle, stopping all code in it from running, without using any switches?) — it would simply stop all code from running somewhere.

I think the behavior would need to be changed a ton. For example, I think it doesn’t need an affect output. Just out and done.

It could definitely have the delay inside the behavior, but could also have an option to choose which bundle you’re affecting (rather than using the output) — so it can only be used for bundle enabling/disabling, and doesn’t require much code knowledge to use.

Would love to see it become some sort of behavior some day, and it’s been requested a few times.

I want an API behavior first.

2 Likes

I don’t think a behavior is the way to go here, it would add more wire messes than it needs to be.

Although,
I honestly think a new behavior input from the bundle list could take this idea. Adding enable on and enable off would effect all behaviors inside the bundle, without needing to add wires inside the bundle. Would be a nice way to control systems without making more switches and work arounds.

6 Likes

This is useful, was this what he was talking about and I was just misunderstanding?

1 Like

Yeah… You all are right. I wasn’t really thinking about convenience or simplification when I thought of it. My 12 year old brain didn’t take those into account.

1 Like