Hex7

I think the magnets are mainly just a slight augmentation of shotguns. While the shotguns provide the vast majority of the thrust, they act over a very short distance/time and so you're somewhat limited in how much performance you can get out of them before things break. The magnets provide a tiny bit of additional accelerating force with little to no risk of breakage or slowdown on the main craft. But it is worth emphasizing how tiny that impact is. The difference between the second best dragster (without magnet-enhanced starting) and the first place dragster (with it) is less than 0.05 seconds. On most courses, it won't matter. ------ You probably could use a purely magnetic jump start, but I'm skeptical that would be better than regular thrusters.

I assume the game has every part contribute to drag at all times (no occlusion). This causes drag to scale linearly to mass. So bigger objects of the same density will stop at the same rate as smaller objects. While in the real world drag usually scales at around mass^(2/3), since mass scales with volume (r^3), while drag scales with surface area (r^2). So bigger objects of the same density will stop at a slower rate as smaller objects. -- So you might intuitively think "add drag occlusion!", but this suffers from the fact that we're in 2D space so we'd end up with drag that behaves like mass^(1/2). Larger objects slow down even slower than they would in the real world. In addition, you would have to partner this with thrust occlusion (no thrusters in front of thrusters), or large craft would go supersonic while small craft could barely move. Then there's other issues like the computational intensity of figuring out at every frame what's occluded and what's not. Along with this there's the issue of how drone's are held together. Without crosslinking between parts, large drones are physically weaker and would readily tear themselves apart if they reached similar angular velocity as small drones. -- I guess you could just do some cheaty physics hacking and just have drone drag behave as mass^(2/3), but this will likely have problems as well. You'd have to add a thrust = mass^(2/3), or you'd again see issues of top speed variance with size. I'm struggling right now to envision how that would then work in an angular velocity case, but I suspect it would go weird. Assuming it didn't, we'd be back again at the weakness of large drones issue, which would upset countless people for marginal upside. -- Personally, I don't see a problem with the current drag model that's more serious than the problems arising from trying to fix it. That being said, maybe there's a way to thread that needle that I'm just not seeing.

Would mind throwing together a couple -simple- examples of a crude gimbal in action. Ideally with an actual drone file to poke at either uploading here or to Steam. I think I'm starting to see the usefulness of what you're asking for, but the presentation is still going mostly over my head. I doubt I'm alone in that respect.

I was thinking perhaps what we're missing here are reaction wheel parts to soak up excess angular momentum. I'm still trying to figure out how exactly that might work, so that it's powerful enough to be useful, but not so much that it makes rotational thrusters obsolete. ------- I got it to work. It's fairly simple to do an A-B-AB scheme using a single direction sensor and a NOR gate, so it's A-B-norAB. The thrusters just respond to either A or B (depending on their side) and a norAB tag. Although having done it, maybe that was obvious all along and I'm just being daft.

Would you mind going into a little bit about you understand to be the fundamental issue of 'steering and stability' and the distinction between the two. Your opening post doesn't actually address what you see as an optimal or ideal case of steering and/or stability, so it feels like we're having a conversation about something I can't see.

It should be noted that drone isn't mirror symmetric (the lower engine is slightly further left). The true issue seems to be that the drone core is more of a circle than a proper octagon. That might be intentional. I'm not sure.

I always viewed the randomness as sort of a mixed blessing. While it does occasionally screw you over, it also occasionally falls in your favor and pulls a win out of the jaws of near certain defeat. I think I'd hate it if there were only one possible outcome to a given race. ----- R.I.P. walled drone. It's racing with RNGesus now.

I'm not entirely sure what the point is you're trying to make about there being no brake. I never said or intended to imply there was any special breaking going on. Many if not all wraith designs, especially without careful refinement -will- oscillate to varying degrees. Indeed there's some minor oscillating visible in the last few frames of the first wraith GIF above. The main advantage of wraithing over one-sensor designs is that it has 3 active states (A , B and AB) instead of the 2 (A and B). That third state enables the drone to maintain it's current orientation at 100% thrust, something a one sensor design can't match (at least not without multiple* logic gates). A badly balanced and calibrated wraith will wildly swing from A, thru AB to B and back. Going to 100% thrust for only a small fraction of the travel time. However, the one-sensor design, no matter how well balanced, has to go straight from A to B and back, never hitting 100% thrust at all. As I tried to explain originally, in the right circumstances, due to the right mix of forces (yes, including drag) and sensor settings, the wraith drone will not swing thru the AB portion, but come to rest there and stay at a full 100% thrust until the waypoint moves relative to the drone. The wraith's advantage isn't that it never oscillates, it's that the third state allows it to achieve a higher thrust and maintain a preferred orientation even if somewhat crudely. My last comment about the wraith narrowly beating the one-sensor was just the result of me doing my own little analysis of whether the additional mass and drag of a second sensor is compensated by the slightly higher thrust and control, which I felt was still an open question. At least in that case, the trade-off is worth it for about 2 or 3% additional speed overall. That isn't to say wraithing is always a good (or the best) idea. ------- *I just thought of how one might do an A-B-AB scheme with a sensor and a single logic gate. I haven't tested it, yet, but I'll revisit the subject if I get it to work sometime.

Can now confirm. Fuel dragging a wraith gives +10 steering and an unforeseen +25 motion sickness induction. . ----- A similar design using only one direction sensor for a more conventional control scheme had similar, but slightly worse performance. So wraithing even at the small scale has its perks.

If Markus and company are really looking for a way to make tracks more afterburner friendly, rather than completely overhauling the tracks, I would just have the waypoint shift farther ahead at high speed. Right now, afterburner drones have only a small fraction of a second notice before they enter a turn, the only way to really deal with that is insane angular speeds. If the waypoint position was customizable or at least linear speed dependent, we'd have a lot easier time making drones that can adequately anticipate an upcoming turn and behave appropriately.

So far the most capable racer design I've found is that of Wing Wraith by Gorggeron (cycle through the hard designs versus racing and it'll turn up eventually). It combines the best of max speed (all thrusters point forward and fire on straightaways) with the ability to turn sharply (all thrusters can potentially participate in turning). If you're not familiar with it, here's a wraith-based design I spent a bit of time working on for Cygnus. Each 'eye' controls the opposing wing. While the waypoint is more or less centered, both wings activate. If the waypoint moves off to the side of the midline of the drone, the eye controlling the corresponding wing shuts off causing the entire craft to rapidly torque back toward the waypoint. If the balance of torque, angular momentum and the eye deadzone angle is right, the inactive wing reignites fast enough to prevent oversteer and the fishtailing that entails. ---- I also made a functionally similar, but conceptually simpler control scheme with the eyes creating a parallel center channel, where the width and angling of the channel can be easily manipulated by merely moving the eyes themselves. Here's a design I made for Picses, that tries to stay to the right, inside track for that course. --- Having worked with wraith designs, I'm still frankly a bit perplexed as to how some players have managed to navigate hydrus in so little time. Even wraith-types have real trouble with turning that fast at afterburner speeds. The only thing I can figure is that they're possibly using some combination of fuel dragging for better turn handling (shown below) and selectively decoupling spent fuel cans, but I've yet to actually come up with a successful amalgam of all these elements and I'm not sure if a viable hybrid is possible.

Yep. It / they are still #1 or adjacent as of a few minute ago. And based on the lack of nearby times, no one has even bothered to try to reverse engineer the proper #1 case. Frankly the game is kind of a ghost town as of late, but that's a separate issue. ------------- Truth of truths is that I'm obsessed with Nani. And I really just want access to all the wonderfully beautiful, but fully impractical designs like Nani out there. I've been spending part of my time trying to come up with a practical reason to use some Nani-like drogue chutes on a design. Have you met Nani? Nani is love. Nani is life. Seriously though. It's probably the best thing I've found via the training opponents and I wish there was more stuff out there like it. It irks me that there probably is already, but there's no proper way to showcase this sort of stuff in-game.

As I alluded to above, you can always choose not to upload your drone (or the best / latest variant), if design stealing is something the player cares about. There's already a system for exactly that in the 'training opponent' versus system and it could be made opt-in instead of opt-out for time trials quite easily. I definitely hear you though about the concern that convergent homogeneity toward the =best= design which is freely available is something to be avoided. I suppose my best response to that is to say I hope the Dev's are actually moving to a more varied system of races in the future. Regardless of how publicly available the best designs are, if the races are always exactly the same, sooner or later everyone is effectively going to arrive at the 'best' whether it be by direct copying or through convergent trial-and-error. What I think we should be more focused on to prevent this are ways that a race can be varied, from one run to the next either by just starting at different points along the circuit or having some form of procedural generation. If the race itself is always changing than a =best= design can't really exist, and the design landscape remains fertile for innovation no matter the level of sharing. If secrecy is a necessary part of the game's final form, than Nimbatus is probably not going to do well long term. Full disclosure, the answer to your initial question corona, "If you had a #1-worthy design, would you give it away so easily?", is that I have actually done just that. It admittedly took me few days of internal debate, but I did post #1 grade designs to steam. Ultimately a ranking is just a number. Having other people potentially use and improve your designs (or vice versa) is way more fun. And that was really my point from the start.

I was thinking while building the gun racer that it would be a cool additional challenge (in addition to manual and autonomous modes) to have a Single-VTOL-Guidance challenge. All sensors are forbidden and you can only use a single VTOL block in addition to whatever primary thrust source you're using. It'd be a really difficult balancing act to try getting the most responsiveness possible out of a single tiny block. Probably shouldn't be a thing for races with death pads, but everything else seems possible.

Yeah. I think those are just a thing now. I have drones generally capable of beating any competition, so I generally look forward to more of those. If you don't, there's usually always a way around any single particular solar system isn't there? If you had a galaxy with nothing but competitions, that might be a bit much.