Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Lurkily

  1. Test flight is based on the planet - bigger planets will have higher altitudes.  

    I do agree that this is an issue that.  I'd prefer that the test flight have alititude ranging from 120 to -120, so that any altitude settings can be tested.

  2. I think the two schemes are largely equivalent until you get to the information offered by the connection and disconnection of signals.

    I've seen connection sensor ideas; in connection with the tracker you mentioned elsewhere, if you can point a connection sensor to a specific tracker, that would provide the same capability.  This seems a little more organic in the mechanics, though.

  3. I want more targets for directional sensors, and altitude to be expanded into a general-purpose range sensor for those same targets.

    Among these, I want to be able to detect the hopper, nearest enemy, nearest enemy structure, snake, either a specified target part or a specific beacon or tracker part.

    Speaking of which, trackers or beacons, each of which can be a target for a sensor.  ( Not just 'nearest', but a specific beacon.)

    If logic stays wireless, I want a 'physically connected to core' sensor.  If those trackers are implemented, also permit a connection to a specific tracker to be the criteria.

    I want a GPS locator.  It would operate much like the directional sensor, except instead of giving gravity's center in relation to you, it would give your location in relation to the planet.

  4.  There are a few things I think are crucial, and it'd interest me to know where they might fall on the roadmap. I'm not demanding answers - just saying that they're things I would be happy to see when you do post your roadmap. 

    I would like to know, if these things are planned, when it's planned to focus on:

    additional sensor criteria, streamlining logic performance, any work on the build UI, a tech or unlock system for unlocking basic parts, a drone building economy so that a player has to invest time to be able to build crazy massive drones, and last but not least,  campaign development.

    I know new competitive game modes like racing are next on your menu, so I know about where that falls.  

  5.  I've used delay for the same thing, but avoiding that instability also makes them unresponsive to changing circumstances, and almost fully useless for combat.  As I'm hoping that "nearest enemy" becomes a directional sensor criteria, I would like to see hinges respond to directional criteria with combat responsiveness.  In this case, the new hinge speed setting would probably also be more useful. 

  6. The problem is that when you have alot of weight on that hinge and need it to be quickly responsive, they will sometimes start to shake and spontaneously tear themselves apart just because they needed to make a small adjustment. 

    I had this happen repeatedly when I tried to use turreted guns and gravity/ distance sensor combos to focus fire on terrain peaks, to more smoothly orbit and grind down a world. Walker drones also had this issue, and most of the foot weight was gravity sensor.  It's been awhile since I used hinges though, so perhaps they're more stable now.

  7. I'm trying to get a straight answer on why wireless is preferable.  The two schemes are equal in most regards, in my opinion -- except that non wireless logic enables connection status to be used in logic. 

    Self - awareness is one of the biggest requirements for intelligent drone behavior. With these schemes mostly being equal, the increased self awareness is a very big point, in my opinion. 

    • Like 1
  8. 35 minutes ago, FreakyWaves said:

    yeah I tought about that but instead of having a table system  don't see how it could be a thing

    Now, you have to use a logic splitter to keep drones separate. If disconnection disconnected logic signals, losing a signal from the other side of the disconnection would provide feedback that you were disconnected. 

    Logic is wireless now, though.  I feel it's not intuitive, and that broken connections are useful information that can provide a drone with additional self awareness. 

  9. Honestly,  I like all of this.  I like the idea of printing more than one thing from a factory.  But I think we have a working system for factories now, and if we buck that, we do so at peril of introducing new problems. 

    Beyond that, a clipboard would be nice, but savable blueprints we can reopen at a later date would be more useful.  I would commit murder for a persistent blueprint book. 

  10. Unfortunately,  upgradable weapons are apparently inherently different from other blocks; it was a while ago that I was told that, but nothing I see indicates that this has changed. 

    Just throwing them on the tech tree isn't as simple as it sounds - but I would still like to see it happen. 

  11. Why should it be obvious that Logic is broadcast, though?  Fuel and energy trains you in the opposite concept, and the wireless connector strongly implies that logic isn't wireless by default.

    When I began with sub- drones, I re-worked logic three times before realizing that subdrone one was pushing subdrone two's buttons. 

    It does make things a little easier for a novice, but most novices aren't creating complex logic-driven deployable subdrones, and it takes away some cues that advanced users may have a use for. 

  12. 3 minutes ago, FreakyWaves said:

    Add a tracking option in the motorized hinges 

    That is my suggestion, yes. 

    On 10/16/2018 at 9:31 PM, Alpino_WILL_STEAL_ oats! said:

    You could do the exact same thing with a directional sensor and thrusters 

    You could, but then you wouldn't be able to track your target without rotating the entire ship. 

    If you want to use a hinge, then you've probably already considered accomplishing your goal without it, because of how clumsy they can be.  I think we should try and make them a more viable option.  The alternative is simply that we won't see a creative use of hinges because circumstances haven't enabled it.

  13. It feels like this is a very intelligent block, when compared to the simple outputs Nimbatus is characterized by.

    The recurring tracker suggestion (as a directional sensor target)  paired with the recurring range detector suggestion (like an altimeter,  but using other sensor targets - like a tracker) would serve these needs, and be in character with the logic already present without requiring new and unusual behavior. 

    • Like 1
  14. 20 minutes ago, Micha said:

    What about adding a new tracker part that sticks to the terrain, can be activated / deactivated and displays a customizable dot on the minimap while active? 

    We could also use it as target for the directional sensor 🤔

    He wants to track a location after destruction, though. 

    I am all for that, as long as you can name or tag them so a drone can seek a SPECIFIC tracker. But it wouldn't address ManTheMister's request. 

    • Like 1
  15. Are you saying that it would read contacts, assign them tags based on type, which would be passed to other sensors as dynamic criteria? 

    I'm gonna be honest, we have nothing like this running, and it's a little out of step with the simple logic solutions the game presents.  It's a good idea, but I'm not sure it's in character with Nimbatus.

    • Like 1
×
×
  • Create New...