corona_wind

It's still the best I've done so far. I keep hitting walls, literally and figuratively, trying to improve it, which is one of the things motivating me to post this topic. If the indicator-on-a-stick was a dedicated part instead of a kludge, it would work a lot better.

If gravity went up instead of down, that would be a bug, whether the developers said so or not. This is how big and blatant the problem is. You're entitled to your own opinion. Myself, if gravity goes "up", I'm calling it a bug, even if they decide to retroactively say gravity just works backwards in the nimbatus universe. It's a model of a real life thing which does the complete opposite of what it's supposed to. Once again, I dare you to take my community challenge before saying the physics are fine. We need a way to stabilize small drones. Either fix the physics, or kludge something else. Maybe a tail fin. I don't think it would take much, and the developers even agree. They just don't want to break the racing scores.

Could you add a high-drag part, then? Tail fin, high-drag block, whatever you want to call it. Something with linear drag without excessive weight. I'm not the first to suggest this, but maybe the need is clearer now.

New blocks: Some part to control drag, which is wonky and uncontrollable right now. Some sort of high-drag block to help keep the end of a small craft behind itself. Movement: Improved sensors, especial the gimbal, which I've written pages about in another topic. Cosmetics: More interested in UI improvements than drone improvements.

Applying the normal kinds of weapons to TNT, we have: Kinetic, which we already have. Bio, aka "instant dirt". Plasma, or rather, thermite. Cryogenic, i.e. compressed gas charges.

Small racetrack drones have some advantage in speed per weight, but suffer a minor disadvantage in slamming into walls and exploding. It takes 2.5 to 3 extra tons of sensors and gates for me to make a "small" drone that can steer at all, and it's still nowhere near as stable as six hollow bricks. The Wraith is nothing but engines and tanks, and needs nothing more due to drag.

Not in Nimbatus, they don't. They fly around like cannonballs. Only large, heavy things fly like balloons, a bug people exploit and abuse on the racetrack. I realize it would have to be a kludge, but I still hope something can be done. The situation right now is a mess -- not "kind of off" but completely wrong. Could you adjust drag according to drone size just before launch? Not by rewriting Unity, just by fudging numbers inside the parts themselves.

Big drones are easier to control! They just stop, balloonlike, whenever you stop pushing them, in defiance of logic and physics. Small drones, meanwhile, careen around like speeding pianos. It's totally backwards and bonkers! Am I really the only one who sees this!? 😅 Come on... Take my community challenge if you doubt this.

In the demo, you got a neat close-up view of sumo stations you traveled to. It's not important to the UI, but I liked it.

If you use Windows, you can fix that with the ancient joymouse program.

As an addition to the game, no problem. There's no reason it couldn't work -- we have the mapping and logic to fly drones however we want. As a simplification? I really wouldn't want to see Nimbatus dumbed down to pure joystick. We know from games like KSP that construction becomes really awkward; analog stick is just no substitute for mouse. Also check out joystick emulators, a variety of ways to connect joysticks to non-joystick software. You might have everything you need already. I think they wanted to use analog stick as the mouse. The "standard" joystick these days has two analog sticks and half a dozen buttons all in easy reach. In some ways joystick is a lot more convenient. WASD would probably be mapped to a hat, pad, or stick, so make that five. You don't actually punch the dir indicator keys in flight either, so make that three. Someone with a really nice controller and ten years of xbox reflexes? Also, try and tell me you're not curious what monstrosities could be constructed from two independent cursors I could be biased, I spent a long long time finessing my controller layout for Kerbal Space Program. Now there's a program with a lot of keys...

I have a few tricks that make it into most of my drones. Latch A switch that, once pushed, stays on forever. Built from a buffer with its output on the same key as its input. You can also build it from an "or" gate or a time-delay gate. Boot Signal A latch plus an inverter(the one with the circle) to make a signal which starts "on", waits a moment, then turns off. You can control the on-time by changing the time on the time-delay. This is useful for drones which need a kick to get moving, either logically or physically. Turn Memory You can use sensors to avoid obstacles in races, etc, by having the right sensor turn off the left engine and vice versa. This pushes your drone away from hazards. But what happens if both sensors get blocked? Can't turn off both engines! You can use a pair of NAND gates, wired like this, to remember which sensor turned on first. S and R are sensor inputs, Q and Q' are engine outputs. It's always 1 1 when no sensors are triggered, but if both sensors get triggered, it remembers which sensor got triggered first and continues to turn that way. There's a rare glitch if both sensors go from 0 to 1 the exact same instant. Then it will flicker until one of the sensors turns off. This is not a bug, the real-life part does the same thing. What tricks do you use for nimbatus logic?

Death zones are very capricious and the one on that corner catches everybody. Make it deadlier and racing will be way more deterministic. Dodge or die. Besides that, most "random" breaking ought to get cleared up once we have proper slow-motion in testing. It took me hours to realize my back engines were hitting my front ones, for example - it wasn't random, but the only testing method I had, trial-and-error, made it look so. What's left are butterfly problems -- hitting that one-in-a-thousand logic hole, riding the edge of ramjet shutdown, knocking that one crucial gate off your nose, etc. I don't think these can be avoided without 100% pixel-perfect determinism, which would suck. But all these are design problems, avoidable.

My challenge: Make it to the end without VTOL or a direction indicator, in ten parts or less. This one is tricky. Meet the copepod: Also, the finish line is either terrain, obstacle, or danger zone, isn't that interesting.

Exactly, putting prefixes on your drones doesn't give you a list of prefixes.

Huh, how did you target your own blocks with a laser? Got some experimenting to do...

Yes, one of my favorite weapons is the "keep away beam", a 4-split bio laser with pushing effect and super long range. Nothing can swarm you. Just three of them make large hives a cinch. For carrying things, sucker beams are rather less careful than magnets; Rogium boxes chatter all the way back to the carrier. Sucker beams are great for scrap, since magnets transfer force both ways while beams do not.

That's interesting, as it's not at all what I experienced for fuel. I had a design where a ramjet and a fuel tank were attached to the same position indicator, and that tank got used first no matter how I danced the fuel dance. Though in retrospect that might have been another wrong assumption on my part. Anyway, the order right now - which tends towards outermost tanks being consumed last - makes it difficult to eject tanks.

A slightly slower web server still functions as a web server, a slightly slower racing car just loses. Don't forget that we are quite literally competing. Also, the point of the GPL and the free software movement it created is you're only allowed to play with the source if you keep it to yourself or distribute it in a way which respects the owners' rights, i.e. don't close it, sell it, or rebrand it as your own. It's the exact opposite of a free-for-all.

That is just weird. BOTH engines are plainly intruding on the collider, but only one collides!

Might "planet spinner" be a bit simple? Slap a laser on any sumo fidget spinner and presto.

Tank order only applies when all tanks/batteries are an equal number of nodes away from what's using them (see " building your craft a very specific way ") If any tank happens to be one node closer to an engine, it gets used first no matter what. Try sticking one of those drills right on a battery. This makes drop-tanks difficult, since the tank you're ejecting - one node further away - will probably be the last tank used! And yes, of course it's a list. The dance is what it takes to alter that list.

There are lots and lots of tricks to avoid using a button. and a few basic improvements to the way logic works may make the separate button part obsolete.

When the suggestion is "more X", X being something the game already has, probably safe to assume it's coming.

I think I just solved this mystery. We've all seen "dancing debris" that materialized half inside the landscape. I tried hitting one with a sucking laser and it fell into the center of the planet.