Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Lurkily

  1. I think what we need is an expansion of propulsion systems that can utilize more fuel reserves, as well as other consumption, such as factories.  

    As for shields, I'd be okay with their current consumption, PLUS extra consumption to recharge after they go down.  I think limiting their standby consumption would just encourage overlapping shields against regular bullet fire.  Increased recharge would counterbalance decreased standby energy use in ONE shield, but not in overlapped or nested shields.  Since only one of those nested shields would be taking damage at a time, it would diminish the energy hit you took in using multiple shields, as long as you overlapped them well.

    I think there is currently enough advantage in careful nesting of shields that we don't need to further encourage it.

  2. 1 hour ago, unmog said:

    Uhm, noob question coming. What is zippering and how do I do it?

    1
    1

    Here is a subdrone I use to courier ore I don't want to carry back myself.  The ore containers were quite unstable when I tacked them on - because they're attached to my ship while I mine, they're subject to the full capabilities of my drone's maneuvering, not just the thrusters that are directly attached.

    EDIT: Ignore the logic.  It's a bit messy, still.  I had to rebuild it, and haven't yet cleaned it up.

      So what I did here is 'lace them up' like a pair of shoelaces.  The left parts can't pull away without pulling on the center mass, and on the bottom, pulling on the other chain of parts.  They can't 'peel away' without encountering resistance from the whole subdrone's mass.drone-sample.thumb.png.fb645a474d77104ddc34fdc12e05109e.png 

  3. Entity, I merged yours into this topic to preserve the 7 votes.  Hence why the links to yours no longer work.  Your post - perhaps because it's the oldest? - replaced the topic here, though.  I'm not really entirely sure why - merging acts a little funny around here.

    • Thanks 1
  4. Latin is also a language I hate.  EVERYTHING is dependent on form and declension.  Everything.  There is a proper word order, but it's a gentleman's handshake based on the habits of one popular dude's speeches.  Different word orders have no influence on meaning, other than being obviously incorrect.

    To be fair, I may just hate learning languages.

  5. But the brain has to communicate BACK to every turret.  And it has to give DIFFERENT commands to every turret.  The brain can't just say 'turn left' without talking to all turrets.  It has to say "Turret one, turn left."  That means the brain has to contain a separate set of logic for turret one.

    Even if each turret could give the logic input without giving input to other turrets, the logic still can't talk back without talking to everybody.  It's not really a failing of the current system; it's just a limitation of simple logic.  The circuit would have to accept input as to which turret is speaking, and be able to modify its output on that basis to give turret-specific outputs in order to change that, and we're talking about scripting, now.

  6. My first suggestions on the subjects were a bit awkward.  This suggestion is to have the option to use a 'chassis' with a drone core.  This would be several 1x1 blocks linked to the core in a pre-determined configuration. (And perhaps with more limited options available for a configurable chassis)

    Each of these parts would be connected in some stylish spaceship-shaped way to look nifty; but the connections would be far more resilient than a normal strut.  They would serve as resilient and stable anchors for other parts; but the configuration would also dictate some constraints to your design.  Various configurations might be suited for big ships, small ships, round ships, long ships, etc.  

    Chassis blocks should be a serious vulnerability.  Damage to them should also transmit damage to every connected part, including other chassis parts, and their regeneration of HP should be slow; if one is exposed to damage it should be a serious liability, and god forbid your chassis catch fire.

    This wouldn't offer complete rigidity; but it would offer, within certain constraints, a more stable environment for a larger build.

    it would, though, being fixed to the core, beg for the ability to rotate the core.

  7. 20 minutes ago, unmog said:

    Yea Im not sure I understood that at all. How would this help me build independant functional turrets? :)

    It probably wouldn't.  But say you wanted a world-crusher that descended smoothly, strip-mining a planet by altitude instead of just bouncing around drunkenly when it saw land - you could store a value, and every turn, add the current altimeter value to it, divide by two, and have the output overwrite that original value.  An infinite decaying average.

    Turrets are simple problems with simple solutions.  I don't think math would help you a great deal; you might read the hinge position of a different turret, to make sure they scanned and covered different directions with little overlap, I suppose.

    • Like 1
  8. Micah has mentioned that he'd like to apply conditions to the outputs of sensors.  What that means to me is that instead of having a 'tilted left' and 'tilted right' output, you would be able to configure 'Tilt between 5-85', 'tilt between 95-175', 'tilt between 185-265', and 'tilt between 275-355'.  That would fulfill even your most complex example there at the end.

    I may misinterpret his meaning, but I think that would be ideal for nearly any purpose. 

  9. Though I dearly want to know too, I agree with this.  Development always takes longer than it takes, and I've worked in communities before where they soured the community by missing deadlines that they imposed themselves.   

    • Like 2
  10. The output block, like other math blocks, would read a variable, and output a tag or key based on criteria configured in the block. 

    Each math block can read and output variables. They need input and output, of course. 

    Sensors would create the variable initially, and perhaps some logic parts could set a variable. 

  11. I seem to recall the devs having spoken about experiments with rigidity, and calling it boring; one reason I stepped away from ideas about rigid chassis or skeleton blocks/assemblies - it doesn't take many fully stable blocks to make a fully stable drone.  

    I'm not against the idea, but I'm trying to find solutions for coherence rather than rigidity, since rigid doesn't seem to be preferred.  I think perhaps they want to encourage the creative solutions to coherence, rather than obsolete them. 

  12. There are a lot of solutions to coherence through creative construction, such as 'zippering' or 'lacing' children so that the bottom pulls on the top and vice versa, and magnets can already be used this way to help coherence.  

    But with rigidity solutions resurging, I thought I'd test something else. 

    Interconnected drones have been tried, and apparently physics became taxing very quickly. 

  13. So I like logic they way it is, but they idea of analog readings and math keeps coming up. In asides and whispers, perhaps worried that it'll be shot down as embarrassingly out of character with Nimbatus.  I don't think I'd recommend it, but I have a concept on how to implement it. 

    This would be a second class of logic blocks - math blocks.  Only an output block would cross that divide, able to output a key or tag based on whether a variable is ==, !=, > or <.

    Sensors would have an option to output a variable, as well as ranged key/tag options. (Such as we use now.) Addition blocks could accept two variables and output a third, along with division, subtraction, multiplication, etc.  Thus you could do things like produce decaying averages of sensor readings, or whatever else you like. 

    I don't think I'll recommend this, though.  I think solutions to these problems largely exist in basic logic, and that introducing math obsoletes many creative solutions.  Like code, I think mathematical expertise would become a cost-of-entry for complex and efficient builds.  

    Right now, a smart novice or an experienced idiot can both work up to very complex behavior with very simple basic tools, and I think that is critical. 

    • Like 1
×
×
  • Create New...