corona_wind

The first tank placed is NOT the first depleted. It often acts that way, but the rules are actually a lot more byzantine. Controlling which tank gets depleted first means building your craft a very specific way then conducting the Fuel Tank Dance - something between a rain dance and the way bees wiggle to talk to each other - to inform your tanks which order they are supposed to tend towards. This is very inefficient, accidental behavior; we have no way to know what we just did without flying our craft. A better way would open up opportunities for multistage craft which eject tanks.

Some days I'm just not feeling subtle, and sometimes the ecologically sensitive solution to bees is robots which throw dynamite. It works quite well despite its random and terrifying backfires (usually solved by hitting tab). Once the factories are ready, single-click launches one missile, double-click launches two, then hold, then let go to detonate. One click gets a hammerhead. Two gets a genade launcher. The entire craft rotates to point at the cursor. It's weirdly accurate. It can william-tell a corporate fighter from across the screen with enough ordnance to carry it backwards like a bug on a windshield. Incidentally, did you know corporate forcefields aren't dynamite-proof?

? But they DON'T stick to your ship. They stick to whatever gets decoupled. Changing which end goes where would mean making the part tree go backwards, I think.

I've seen this happen too.

This was a fun idea. Min-maxing for speed gets tedious. Have the Grandfather Clock, which steers with reaction wheel:

OK, so what I'm talking about is a new kind of feedback loop. Rotating a position indicator on command lets it act as several new kinds of sensors: Compass / Heading Angular Velocity Angle ...as well as several other things I don't know how to describe yet. And probably more I haven't thought of. It's all in how you wire it. But it's a really cumbersome, slow, huge, wobbly part right now. Adding this talent to the basic directional indicator would be like adding five new parts to the game, not to mention, letting us use the same old part in ways it was awkward to do before, like at 45 degrees. Examples, examples. Click images for .DRN files. Something like this was one of my first designs. It's not the best thing ever, but you get the idea: The heading is controlled by rotating the gravity direction indicator. It acts like a compass. Knock it off course and it will turn back. Here's a better example: I built the wobbliest racer I could and added a stabilizer. The waypoint direction indicator on right controls the outer pair of engines in traditional fashion. The gravity direction indicator on left controls its own axle to keep itself pointed down. Put another way, it measures how fast your drone is turning, somewhat proportionally even - turn faster and you get longer pulses. This signal controls the inner pair of engines, damping the wobbles. And here's the craziest thing I've done with the idea: Proportional steering! The direction indicator is rigged to turn itself (not the craft -- it turns itself) towards the waypoint. The engine booms are turned by the same signal. So the direction indicator ends up measuring the exact angle between the craft and the waypoint, and pivots the engines a proportional angle, magnified a little to compensate for drift.

Gimbal just means a frame for something to spin in. Ookami-sama has it exactly right -- my idea is nothing but a direction indicator which spins on keypress and in the UI. The most obvious use: Fixed Rotation Sometimes you just need a tilted indicator. Hex, you showed me your Wraith rebuild. Wouldn't it be less awkward if you could punch -11 degrees into the UI? No more bouncy eyestalks, no more dead-zone tricks. That's the tip of the iceberg. If the angle can change during flight, that opens up so many options it's hard to list them all. I'll make a better showcase of the uses I've discovered so far once I'm home and can screenshot, etc.

Ignore the firey end of the engines. That corner is quite carefully placed the same distance from the center. Measuring in GIMP, there's exactly one pixel of difference between them, and I see where it comes from - the drone core is 191 pixels wide at maximum zoom. That doesn't divide evenly, causing it to project one pixel further on the left side of the grid than the right. There's a vertical difference too, but I'm less sure why, since the core's only 190 pixels tall.

And I have progress of a sort! The forward eye controls the outer pair of engines in standard fashion. The back eye controls the inner pair of engines in swapped fashion, with a little delay between them, so for an instant you get full-force turning, which rapidly becomes slow turning with only one inner and one outer engine active. Wraithlike steering without the drag. I might be able to simplify it more.

That's the point, yes, but if the core was a circle as you say, I'd expect the opposite to happen - the one closest to the center would block and the one farther out would not. So I'm still not sure what's happening here.

The racetrack is the worst place to fine-tune, can't zoom in, can't slow it down, just have to throw things at the wall monte carlo and see what happens. Sometimes you have to mock up a craft with a lot of LEDs and control it with cursor to see how it behaves to get what really happens. I think the game would be a lot duller if it weren't the slightest bit random. You have to make a bot that can respond to a variety of situations, not just a bouncy puck with nineteen VERY carefully aligned engines. And a three-star arena can't block you forever. Probably. Unless its champion is REALLY good. Also... Some of my most fun designs come from seeing a drone hit the wall, lose half its parts, and keep going in a new way. Have to stop and think, "How did it do that!? ..can I do that on purpose?"

Consuming lots of power would be a good tradeoff. But if we had the logic to drive a reaction wheel, why not just hook it up to rockets? Throw away the flywheel and you're left with... well... another wheel, a gimbal. In this case the direction indicator indicates gravity and controls its own pivot to constantly point down. This means it only twitches when you're turning. It works, but isn't exactly elegant (WIP). If the position indicator had gimbal settings, I could throw away the wonky joint and make something much faster and more stable. Are my drones supposed to win/lose the same sumo match pixel-perfect identically every time? They're nondeterministic but never "wrong" exactly. Sometimes it'll lose one part, sometimes another, but never anything I wouldn't have expected to happen, nothing absurd. I thought that was quite clever and wondered how you did it! If that's unintended, I'll wild-guess that something in damage processing or garbage collection is monkeying with the order of your data trees. We know the order of equal depth things is arbitrary - we tweak fuel flow by altering that order just by touching things. Memory management especially is quite nondeterministic and liable to move things this way and that depending on what memory is handy. If that's all that's happening, does it need to be fixed? I kind of like it. I haven't seen any logic errors I couldn't put down to propagation delay and part ordering.

Steering: Turning towards the setpoint. Stability: Stopping once you're there.

It only happens on the left. Mirror the engine and it only happens on the right.

The topic is "steering and stability". The Wraith isn't different from any one-sensor designs stability wise. If the only way to achieve stability is "build large", topic over I suppose.

When I say digital logic is too slow, I'm not kidding. One gate delay is the difference between steering and hitting walls. The same craft, without the gate delay but with equivalent dead weight, steers well. Perhaps several ticks of logic could happen per game tick, so a detector could fire and an engine could activate in the same tick?

I understand the point, but having tried it out, two sensor oscillates just as much as single sensor. They have no "brake" except drag and dead-zone.

[edit] I could be wrong.

Something is really wrong with Nimbatus' drag model right now. Pianos fly like feathers, feathers fly like pianos. How exactly is drag calculated right now? My best guess is per-part. In real life drag is per surface area. Unintended Side Effects Fixing drag should be a priority IMO. You still have a chance to change it right now, but wait too much longer and people will get attached to their designs. "Larger is better" in racing because the angular drag on large designs is ridiculous. Fidget spinners dominate in sumo because angular drag keeps their simple, barely controlled designs stable. Quick Fix #1: Scale By Square Root If drag right now is DRAG=sum(parts.drag), then DRAG = C * sqrt( sum(parts.drag) ); could be a quick fix. C is a large enough number that small drones still have significant drag. Weight will increase faster than drag, like it should. Quick Fix #2: Scale By Radius Even square rooted, the shape isn't taken into account. Twelve parts on the ends of long poles should have more drag than twelve parts closely packed. That could be included in the equation perhaps as DRAG=C * (RADIUS / sum(parts.mass) ) * sqrt(sum(parts.drag)); Less Quick Fix: Outermost Parts If a part has parts further out connected to it, don't count its drag, only its children. If a part has parts closer in connected to it, don't count their drag, only its drag. This is as close to "surface area" as can be gotten cheaply. New Parts for Dynamic Control High-drag blocks as suggested elsewhere in this forum will be important. Also the many uses of the gimbaled direction indicator. Come On, It Will Be Fun It's gonna be hilarious to watch fidget spinners going off like dynamite.

I think the drag model is really wrong right now, pianos steer like feathers and vice versa, but that's another thread. Waking up to my wrong assumptions has helped, and just talking this over has given me more ideas. I think I can make an angular accelerometer, just one more use of the gimbal.

This is the biggest barrier to succeeding in the racetrack. I've tried so many approaches, none of which work... Screw it, Don't Bother - Lots of little contraptions win races by bouncing or spinning with little regard to fine steering. You can get good speeds with a very small drone. But with 50% dead weight they can only go so fast. Direction Indicator Steering. Engines hooked directly to the direction indicator. Like above, your engines spend 50% of the time not working, and if you hit the dead spot, your ship just ... stops. Inverted Direction Indicator Steering. Instead of turning one engine on to steer, you turn one engine off. This sounds better and isn't. You spend all your time bouncing with one engine disabled anyway. Feel free to move your engines inward for less torque until you slam into walls. Alternately, you can increase the dead zone until you slam into walls. Drift Steering. Same as above with careful angling and placement of engines relative to center of mass to supply lateral acceleration. This helps avoid the walls, but promotes understeering, and can oscillate like anything else. Steering Compensation - Killing that oscillation by any means, including but not limited to: Springs - Lets you isolate oscillations to certain parts. Doesn't stop oscillations, but hey, at least you're pointed the right way more frequently. Pulse engines to stop your turn. This takes so much dead weight. I've seen racers that are 50% sideways pulse engine. Variable Speed Engines - I'll never run out of ideas for them, none of which ever work since they're SO LAGGY! Even just on/off has horrible lag. Byzantine Logic Arrangements - Delays, et cetera to reverse steering pre-emptively and halt overshoot. Still exploring this but even logic is slow at ramjet speeds. Rube Goldbergian Mechanical Arrangements - My specialty. I've made feedback loops of direction indicators and powered joints to manage over/understeer. Faster than digital logic. Maybe one day I'll find an arrangement that works in narrow turns. Not today. Brute Force - Make your ship so big oversteer is less of a problem and/or losing parts to impacts matters less. I've been able to think my way around most problems but this has me close to beat..

Then I'd say the system is working as intended. Nobody's cheesed you 0.005 seconds by nudging one fuel tank 3 pixels or whatever since downloaded drones don't count. So maybe pictures aren't so harmful after all. Fair enough. And yes, I love wonderfully impractical things! Hence putting rotary designs in the racetrack XD Steering is hard!

Next question, is it a #1-worthy design any more?

Devil's advocate: We actually compete in races. If you had a #1-worthy design, would you give it away so easily? Especially when you could find yourself fighting its clone in a three-star arena later, needing to beat it to progress through a system. This is a little different from 'free software' where, after giving something away, you still have it ... I also think the creative spirit of Nimbatus would suffer if we had to rebuild Best Known Racer 3.4 and upgrade our video cards to squeak out a win monte carlo. The 'best designs' should be somewhat secret just so they don't proliferate the way fidget spinners took over sumo. Bottom line, if people want to show off their designs, the game already has screenshots, gifs, and steam to opt into doing so.

Sensor-only guidance could be fun too, no "rabbit", just watching walls gravity and hazards. That's really really "fun" and takes a smarter drone. Though not that smart. Ever had a drone get 3/4 of the way to the finish line, decide "screw this" and turn back? All the way to the starting line? Fun times...