corona_wind

I think giving VTOL engines a really low exhaust velocity would solve their OP-ness without changing legit uses or breaking any saves. They'd top out at 10m/s or whatever no matter how many you have but give plenty of thrust at liftoff. They'd still be great for hovering craft and tiny 1-engine factory things, just not racing.

Someone has to say it. There is no motivation to avoid obstacles when you're rewarded for spamming enough VTOL engines to survive the death zones. None of the winning ships have more than a button as logic, unless it's redundant copies of the same button, again, to keep working despite flying straight through death zones. There should be fewer death zones and more just-plain-obstacles, of a sort that's difficult to brute force past. That might encourage a little more sophistication in designs. Why do VTOL engines work for anything but gravity, anyway?

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: Charge pulse engine attached to dynamite. Decouple dynamite. Fire pulse engine. 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.

I think I can explain this! I've noticed this and narrowed down when it happened. Nimbatus auto-assigns A/D/W to engines, guessing from where they're placed. If you copy-paste an auto-assigned engine, Nimbatus may assign it something else. If you ever change an engine's assignment, though, even to A/D again, Nimbatus will remember and keep it when pasted. So I think you had auto-assigned engines mixed up with your customs. When you pasted, the autos changed and the customs didn't.

Heh. I know what you mean. I first realized I might have a problem when I noticed the '3... 2... 1...' starting timer was slower than the sound! The game doesn't count "real time", but does act differently on a slow PC. I suppose it's making the time step larger, doing rougher calculations to keep up, causing the drone to act subtly different, and that "subtle" makes a huge difference to sensors. Reducing resolution and turning off anti-aliasing and bloom made Nimbatus playable for me.

If I want to weigh myself down with 37 tons of keymapping, that should be my perogative. 😛 Only a few things really deserve exclusion: Timing Elements Sensors Restrict those and there's nothing left to cheat with.

YES! So very much this. I came here to suggest exactly this. Active-low can cut the number of needed parts so much, which is why so many things in real-life work that way. Add to that R/S and J/K flip flops, and the logic elements would be fairly complete.