Jump to content
Stray Fawn Community

corona_wind

Member
  • Content Count

    85
  • Joined

  • Last visited

Community Reputation

63 Excellent

About corona_wind

  • Rank
    Crackpot Inventor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Flip it around - "it works fine for me, therefore nothing's wrong" is equal and opposite to the hostility you imagine. The devs acknowledge the problem, and the #1 Nimbatus racewinner has no solution but "build large". The issue is real. I just want to discuss the nature of the bug and find solutions.
  2. Cryo-TNT for volcanoes, bio-TNT to cover up some turrets while you hurry away with toxic cans, plasma to light torches, kinetic for shield generators. Grenade launchers cut through dirt like butter, and dirt won't actually hurt anything except yourself, so maybe dirtballs aren't as OP as they sound? I'm sure it'd be loathed in PvP if there was ever a PvP with weapons.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. If you use Windows, you can fix that with the ancient joymouse program.
  13. 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...
  14. 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?
  15. 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.
×
×
  • Create New...