Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Lurkily

  1. So downgrades, they can be useful. They can get your particles to the ground so they can eat downward, they can widen the spray of projectiles so your aim needn't be so precise, they can even help you propel your ship with recoil in a pinch. But they have one thing in common. They create a specialized, tactical weapon, one more useful in a narrow scope, and less useful for a broad range of things. They always diminish a weapon as they specialize it. So why not add an upgrade slot for every downgrade? Or for the first, third, fifth, etc slots, or whatever you want to do. The point is that making a highly specialized weapon can require downgrades that prevent you from using upgrades which would also be useful in that role. Because you've diminished its behavior to suit one purpose, you can't best suit that purpose. So I think that adding a downgrade should add one more slot for a weapons mod. That is all.
  2. Reverse minigun upgrade. Nice. It gets my stamp of approval.
  3. Even just 150 would take it out of the range of things that right now can sometimes find the highest fliers.
  4. I'd like to see ecosystem management as a quest goal. For instance, clean the parasites, sure, but you can't kill the space whale, OR the parasites. Instead, you have to heat them until they leave.
  5. It's generally accepted that adding real-time multiplayer takes triples the time and money required for release, if I remember correctly, just to give you a point of reference for what it actually means to the devs.
  6. My understanding is that it exponentially increases the physics calculations going on to have more than one directly connected part and the potential for circular propagation of forces.
  7. This, plus the timing stuff coming up, would make sequential, animated motions a LOT easier. These could control phase 1, phase two, phase three, etc of a sequence of timed motions.
  8. How about a 'more elemental effect' upgrade? You could also pair it with damage downgrades, and it would work with existing weapons.
  9. Let's get to the hard part. How would you explain this to a user? Looking at this with an eye for the clues it gives people, I don't think it would be at all clear to a user how to generate an output with these. Often the hardest part of things like this is presenting it in a way that they can pick up and use without a tutorial. This suggestion has been made before, though, and i supported it then, and support it now.
  10. Magnets can help a bit, here. I made a drone once that spawned with a bunch of weapon systems, and you could go back to them to swap one weapon system for another with magnets. It was less awesome than it sounds, more keystone cop than Gundam, but it worked. Real autonomous docking requires directional sensors AND distance sensors that can pair to a specific block, so a drone can seek that block at the right angle and speed.
  11. And I am abusing it heartily. So far I have made a satellite manufactory that squashes itself against the Nimbatus, magnets down, and pumps out 100-altitude drones that orbit and fire rockets downward. I've created factories that create ore blocks, then detach them on command to fly back to the hopper so I can manufacture more and keep mining. I've created a spinner that keeps at high altitude, and just manufactures tons and tons of wibbly-wobbly TNT missiles. I do think their building needs to be regulated, though. You can't build something out in stages; it all happens at once. If there are sub-factories, it doesn't stop there. You could build a bomber that could make and launch it's own TNT bombs, but it will also make all the bombs first, instead of launching the drone and letting it manufacture in flight. I'd like to see them, ideally, build in stages. Children, then grandchildren, then children of grandchildren. It would make the build process a lot more interesting to see.
  12. I kind of agree with this, but my uses for this have been REALLY limited. In a few cases, I've used two directionals with overlap to create four possible outputs. I once used four to get eight outputs for mouse-tracking, but it wasn't more useful when I was done. I think the trouble required to make it work and to make the UI relatable and simple might be more trouble than it's worth.
  13. What I do is use Q and E for turning, and A/D for strafing. I need four thruster groups to make it work; nose left, nose right, and tail left, tail right. If Q OR A is pressed, activate nose left. (Pushing it to the left, not the thrusters on the left. ) If Q or D is pressed, activate tail right . . . etc. You will need four groups of thrusters with different inputs, and four OR logic blocks to control them.
  14. What about allowing power transfer through magnetic contact? Magnetic induction or whatever you want to call it, it would let you 'dock' with a piece carrying fuel and power generation.
  15. I would love to (And I know, i know, I've said it before) be able to 'pair' directional blocks somehow so that they always pointed to each other. I have this dream of creating a drone fleet that operates like a bunch of gradius options, following me around in formation and firing at things with me. But to do that they need to know the direction to a specific drone or part, and the distance to a specific drone or part. being able to point directional sensors to each other, or to a selected 'part' is halfway done.
  16. And it's useful for the stupid idiotic stuff I try to do, like make drones with legs.
  17. Oooo. Line-of-sight energy transfer. Hmmmmm.
  18. I would display it in the editor by lists of thruster groupings. Each key that controls thrusters is a grouping, and you can list each key, with a sum of the thrust it generates. Some won't be useful - for instance, tank-style controls, which use the same thrusters for turning and moving forward, will probably list eight groupings for four actual controls - unless it can follow the logic all the way from the inputs to the thrusters, in which case twelve groupings for four control keys. (Forward, back, turn left and right.) But the operator should be able to make sense of his own groupings, too.
  19. I would like directional sensors that can track your position on the planet, from 1-360 degrees, with decimals. That and the altimeter would make it possible to make a drone that could seek fixed goals, like the hopper, and also avoid the hopper in their meanderings. (A pair of altimeters and a bit of logic could keep you out of a range of altitude whenever you're in a certain range of degrees.) I agree that resources should be detectable, and I would like to again take the opportunity to plug the idea of an 'angle' component to directional sensors that you could increase to 360, but that reduced maximum range as you increased the angle.
  20. I usually use a magnet somewhere, to make carrying them easy. I'm working on a magnet on a detachable return ship to carry them home for me.
  21. I created a factory that just keeps making high-altitude orbiting drones with downward-firing ice rockets. Magma is irritating, but surmountable by various means. You could also use a factory to drop wide-spraying cryo-sprayers beside a geyser. But yeah, the collection quests can be rough. At least notify us when there aren't enough left to complete the mission.
  22. I like this one. I think efficiency loss is the way to go with balance; with the player relying more on fuel, you'll have more explosive fuel tanks anyway.
  23. Put them on the other side of a factory, use an altimeter to get them to the right altitude to pass over your hopper, then let them fly themselves home.
  24. I guess I'm trying to see why this would be challenging or interesting, rather than simply different. It isn't a strategic or tactical decision, because you can tailor your drone to each world; in picking the right engine for the atmosphere, there would be no trade-off or drawback, just a correct and an incorrect decision. The space and speed required are entirely dependent on the responsiveness of the mechanics used to implement them, which is pretty much whatever the devs want them to be. I suspect the real reason is just that people don't want to throw ideas of aerodynamics into the mix of spaceflight - it could get confusing, fast.
×
×
  • Create New...