Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Lurkily

  1. My suggestion would be to simply draw a border around any terrain piece that's a few pixels wide.  A 2-pixel border means that even a terrain scrap smaller than a pixel would show as a four-pixel bit of terrain.  It would be nice if weapons would collide with the border, too, so we could more easily clean up scraps.

    Collision with weapons would be nice too, to make it easier to clean up scraps, but I recognize that it might be hard, with larger terrain chunks, to determine which exact terrain should be destroyed by a collision with the border.

  2. A lot of times this means there's an overlap somewhere.  I also have this problem with hinges that have many parts attached.  If there's a single part with many attachments, try attaching some of those to a different parent, and see if it helps.  I usually don't have this problem with builds that don't have overlaps, lots of parts connected at extreme ranges just hanging in space, or a lot of parts attached to something mechanical, like a hinge.

    I agree that physics does need some attention; we shouldn't have to redesign to accommodate the limitations of the game engine.

  3. I do appreciate your effort to divide everything up; it makes it easier for us, and easier for the devs to categorize your ideas and use these forums as they were meant; as a tracking system for what the community wants.

    I think a ship should require at LEAST one storage battery, and should only be  able to provide as much power as the batteries can hold; in other words, if your ship draws 50 energy, and you only have 40 batteries, you're going to come up short, even if you have extra power.

    Though come to think of it, the reason for the problem may not be obvious to the player; perhaps it is too confusing for a new player, who might stack more and more generators and wonder why his shields won't stay up.

  4. By orientation - rotate the camera module to rotate the camera orientation.  The core rotation is the tricky part, but I feel like up in the editor should be up for the camera, if we can't get core rotation.

  5. I think it would require ore and terrain to be flagged differently, so the sensor return can be differentiated.  Exactly how difficult that really depends on exactly how they're represented by the code; it may be as simple as creating new settings for the sensor to return a detection event from, or it may require a rewrite of ore generation so that it's in a fully separate class from terrain.

    Whether or not it's feasible, I'll leave to the dev's discretion; but I would still really like it.  Even if differentiation is prohibitively difficult, nearest terrain (including ore) would still be great.

  6. We once had speedometers that had adjustable target speeds, I seem to recall, just as dynamic thrusters have adjustable thrust.  That's gone for some reason - I don't think it should be.  In fact, I think it should be expanded.

    Directional sensors really have only one meaningful range - the tolerance - to adjust.  But there are circumstances in which it might be useful to adjust it.  I'm not entirely sure what those are, but I am all for giving players the opportunity to find out.

    Altimeter settings could be very useful for autocompletion drones.  Miners could be set to slowly lower their altitude, then spike it whenever detecting terrain below them - in effect, they'd maintain an altitude related to surface peaks, not related to a specific distance, or having to leap back up every time it goes into a dip and finds terrain ahead of it.

    Speed sensors could be set to match velocity to a target; for instance, back when speedometers were adjustable, I once made an orbiter that maintained altitude not by upward thrust, but by moving so fast that it literally orbited the planet; it increased speed when it detected terrain.

  7. I'm not entirely sure they should provide a reading at all in these areas.  Upon thought, having a directional sensor set to gravity is an almost certain sign you're using the wrong design for the region.  Maybe you have it so it can also be used on planets, and that's fine, but there's no possible purpose to serve here.

    I also think that in Zero-G regions, the camera should always take its up-down orientation from your drone, instead of the level.  The designers seem to have gone to some trouble to be physically correct in some regards, such as space and movement and orientation having no meaning without a point of reference.  On a planet, that point would be the center of the planet, but in a Zero-G region, I'm not sure using the center of the map to orient the camera makes sense - nor does having an arbitrary orientation locked, as if space had a north and south.

    When you get too far out, you can get an arrow pointing you toward the center, as you do on planets, to make sure you don't get lost.

    • Like 2
  8. Not 100% sure I'm a fan of making a player stack energy just because a factory won't work without the full amount available at once.  I also don't think the problem with the design would be obvious; the factory would just not be working.

    I would drain it normally, but drain the full amount very quickly at the moment you print; also have a timed cooldown as you do now.  It would be fully disabling to have to print without an infrastructure, but it would still kind of function.  Slowly, with the dual delay of the cooldown and the energy drain.

     

  9. The test area has a false centerpoint below the bottom border; gravity sensors don't respect it, but altitude sensors do.  The degree of the effect on altitude in the test chamber also is defined by the planet you're currently visiting.

×
×
  • Create New...