Logic Part Improvement

[corona_wind]

I suggest borrowing a few features from real life microchips to make Nimbatus logic smaller and more straightforward.  Take it from the people who have to build it in real life, they know how to keep things simple.

• Output Enable - Nearly every real chip and sensor more complex than a NAND gate has at least one "OE" pin.  Why?  It's so convenient!  Imagine two proximity sensors on the same key, how to choose which one gets listened to?  In Nimbatus that needs three gates - two AND gates plus an inverter.  With real devices, you'd just turn one sensor off.
• Inverted Outputs - I'm not the first to ask for this and I know why -- half my logic is inverters!  There's no logic simplification for A&!B.  I always wish I had inverted outputs for:
  • Proximity sensors
  • Direction indicators
  • Toggle switches
  • Speedometers
  • Altitude Indicators
  • Impulse Drivers
  • Fuel Tanks
  • Actually -- anything and everything with outputs, no exceptions
• Complementary Outputs  - Just an 'invert this output' checkbox isn't enough.  All too often we need both outputs simultaneously.  You see this all the time in real microchips.  Look up "flip flop".
• Inverted Inputs - Given complementary outputs, there's extremely few places inverted inputs are still be needed, but the adjustable-strength engine is one.  I can never get that thing working quite right.  I'd ask for separate invert/not invert checkboxes for the throttle up and throttle down options.  Either that, or more consistent behavior when both inputs are activated.  Heck, how about both?

And now, a few basic parts I'd suggest adding.  I want to keep them simple.  I don't want to replace all the stuff people are building, just let them build things with fewer parts and especially, build things they couldn't before.

• Monostable Multivibrator - A "triggered impulse driver' which delivers only one pulse per activation.
• Jumper/Bus - A buffer that drives many output keys together.  What for?  "When you see the whites of the enemy's eyes, FIRE ALL ENGINES!"
• R/S Flip Flip - Similar to the on/off switch, with complementary outputs and more consistent behavior.  It's the one and only piece of logic needed for a basic 2-engine, 2-sensor wall follower!

And now, more esoteric things I know won't make it in the game but I'm hopeful for anyway because they're impractical to build right now:

• Priority Encoder - Suppose you have two sets of input, a direction indicator A B for 'move towards enemy' and a pair of proximity indicators C D for 'goodness the edge of the ring looks rather close'.  They control the same steering engines D E.  You can't use output enable for this, because you can't ignore the edge sensor when the bell tolls for thee.  The logic is something awkward like E=((A|B)&A)|(!(A|B)&C), F=((A|B)&B)|(!(A|B)&D), 9 gates, 7-8 if you cheat.  Even if it was a 2x3 part I'd save space.
• Binary Counter - Toggle-switches aren't good enough, a counter made from those causes glitches.  A real, synchronous, one-part counter of just 2 or 3 bits would save a lot of hair-pull.
• Binary 1-of-4 Decoder - To use with the binary counter.  It'd replace the "stop lights" I build from delay lines and xor gates.  What for?  Imagine this sequence:
  1. Charge pulse engine attached to dynamite.
  2. Decouple dynamite.
  3. Fire pulse engine.
  4. Detonate.
• Master-Slave Flip Flop - Kind of like a switch which can only change the instant its 'enable' input is activated.  The thorniest glitches sometimes require these to solve them.  They're a basic part in digital electronics, but want a ridiculous number of gates to make - at least nine per bit.  Nine.  Not to mention how slow they'd be built from basic parts, they'd take a handful of game ticks to respond.

[Micha]

Some solid suggestions here

[XeToRoG]

Inverted Outputs Yes please

[corona_wind]

Another place "inverted inputs" is really useful is the "output enable" above.  It's so helpful to invert OE that, in real life parts, OE usually comes inverted.

It'd mean sensors would come "default on" just like they are now unless you specifically pick a key to disable them, set OE to non-inverting, or both.

[Pillarship Employee #0]

Something like a minecraft repeater would be nice, after a delay it outputs the key for how long you held it before.

[pyz3n]

I look forward for this stuff to get implemented, it seems really nice! Even in my limited experience with logic I was really annoyed each time I had a tag whose only utility was to be inverted, so I'd end up with something like "TILTED RIGHT" (useless) and "NOT TILTED RIGHT" (which I actually needed). And the other suggestions look awesome too!

[Ru.St]

I subscribe to every word of this person, but I would also like to add that for height sensors it is necessary to implement a digital output in order to realize the effect of hovering, and in order to change the height of the hover it is necessary to add an adjustment option (for example, by turning the mouse wheel)

[pyz3n]

3 hours ago, Ru.St said:

 I subscribe to every word of this person, but I would also like to add that for height sensors it is necessary to implement a digital outpu t in order to realize the effect of hovering, and in order to change the height of the hover it is necessary to add an adjustment option (for example, by turning the mouse wheel)

I think for that an accelerometer/velocity sensor would be enough; see this proposal.