Jump to content
Stray Fawn Community
bdew54

Tags in version 0.9.6 (early access) don't work?

Recommended Posts

Hi, I have the following problem with Tags (essential for "programmer" mode, right?) 0.9.6 (early access)

The following switch has Input: "T" and Output [Tag: "Test", Key: "."] and is activated in my example screenshot.
The LEDs are linked in the following way:

upper left (Red) responds to: [Tag: none, Key: "."]
upper right (Green) responds to: [Tag: "Test", Key: "."]
down left (Red) responds to: [Tag: "Foo", Key: "."]
down right (Red) responds to: [Tag: "Test", Key: "/"]

afbeelding.png.68a13db0df712a1c166f365781bb78ba.png

If I understand the idea behind "Tags" correctly, only the green LED should have been activated, right? If not, could anyone please explain how "Tags" should be used? When building complex (autonomous) drones, the connection with a Tagged Key should be on the basis of correct combinations of Tags and Keys.

On a side note, I quite like the Idea of the "wired linking" that I have read in this Forum.

 

Cheers,

Boudewijn.

 

Share this post


Link to post
Share on other sites

Tags and keys on the inputs are handled with an 'or' logic, so if either one is true it will be active.

An Output also sets both the key and the tag to true when active.

Share this post


Link to post
Share on other sites

Ok that explains it. My question is: why would they be handled this way? Could you give me a good example how this is useful?

If they were handled via 'and' logic, you would be able to differentiate much more and keep track of all the functionality and keys. For instance you have two turrets that use two different sensors, I would like to be able to have the Tags either to 'turret_one' or 'turret_two' and the functionality of e.g. 'shoot' in both cases mapped to Key '1'.

In short, with 'and' logic, you would have effecively much more and more organized 'keys' at your disposal. Wouldn't that be nice ;)?

Thanks

Share this post


Link to post
Share on other sites

I don't think its possible.  It's not a matter of how tags work -- it's how gates work in general.  Pile up two gates with the same outputs, the game or's them.  Changing that behaviour would mean needing a whole new logic engine.

HOWEVER!

Invert your logic and what you're imagining is already possible.

I use primarily nor-gate logic.  With tags+keys, they work just great as 4-input nor gates, which makes them by far the most space-efficient gate in Nimbatus.

It's also possible to build a 4-input NAND with 2 gates instead of 3.  Just assign the same key as output and it works.  Plot out the logic of (A NAND B) OR (C NAND D) and you'll see it's identical to (A NAND B NAND C NAND D).

Share this post


Link to post
Share on other sites

And what good is a NOR gate?  It's helpful to think of them as "disable gates".  If any of the inputs are true, turn this off!  Do not ask "what engine do I turn on for this sensor?"  Ask "what engine do I turn off for this sensor?"  etc.  And anywhere you want to put an inverter, put a NOR gate instead.  You'll thank yourself later, when you find any reason you want to inhibit that signal.

ZyepT2L.png

This drone completes the "retrieve alien artifact" mission and has loads of different behaviours.  I select between them by abusing extra NOR gate inputs.  Inhibit all nor gates except these ones...  Then, inhibit all nor gates except *those* ones...  And at the end, I turn off all engines with the KILL signal, letting it fall right back into the bucket and carry the prize with it.

Share this post


Link to post
Share on other sites

Oh, and lastly:  AND/OR gates are not universal.  Because they can't invert, you can't build all possible machines from them.

NOR gates are universal.  You can build anything out of them, including AND logic.

So are NAND, but they don't get the full benefit of 4 inputs the way NOR does.  (And NOR gates cannot be piled up to make bigger NOR gates the way NAND can.)

 

Share this post


Link to post
Share on other sites

Thanks,

The NOR gate is indeed helpful (NAND even more), I guess it's back to the lab and build some!

Plus: I have solved my own problem of efficient keymapping (perhaps this is beginners knowledge, but anyway...) I now resort to ONLY using Tags and leaving the Keys blanco or: 'add key' (by pressing "Escape", otherwise they all are mapped to "left mouse button"...). This way I can use words/designations instead of single keys and such to relate input/output ports.

In relation to my first item in this thread:

switch has Input: "T" and Output: [Tag: "Test_1", Key: none]

upper left (Red) responds to:                [Tag: none, Key: "."]
upper right (Green) responds to:          [Tag: "Test_1", Key: none]
down left (Red) responds to:                 [Tag: "Foo", Key: "."]
down right (Red) responds to:              [Tag: "Test", Key: "/"]

Then only the green one lights up!

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...