Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Lurkily

  1. 4 hours ago, Markus said:

    Maybe we even have to increase the amount of air-resistance for the "high air-resistance" planets so that you really are forced to build different ships :) Of course only as long as it is still fun to play and we have parts which makes building such drones fun enough :) 

    1

    I guess my worry is that these propeller suggestions are a symptom of high air resistance just no being fun.  Everybody seems to want a way to negate it.

    My feeling is that wind and weather might be more fun, contentious, and interactive than just high air resistance.  After all, more wind, more weather, right?

    I don't actually mind having the capacity to build a massive drone that can do anything, but it should be an endgame project, enforced by progression mechanics.

    • Like 1
  2. I think the Altimeter should be reworked into a proximity sensor; but I agree that a rangefinder type item is important. 

    I'd like every part to be trackable, but trackers work too, and the devs have been talking trackers, so, trackers.

    Beyond that, I don't need parts so much; more sensor criteria, and local logic/wireless blocks not splitting signals ranks higher on my to-do list.  But piston parts.  Even just a spring with an input-adjustable length would do.

     

    • Like 1
  3. I can see atmosphere, really; you could make the argument than a very good propeller would be better in atmosphere than an inefficient thruster.  I just don't feel like they meet a need.  It obviates a challenge.  But we get this request a lot.

    I think we need to consider lowering the maximum range for air resistance, and when environmental effects are applied, (on the roadmap,) we need to angle for wind as a challenge on high air resistance planets, not resistance to motion.  What I'm getting from these propeller suggestions is that high air resistance isn't fun.

    If that's the case, eliminating the challenge it poses probably isn't the best way to address it; I question if we need it at all.  High air resistance planets should have unique conditions, but wind and weather are coming.

    As the Devs who comment on Nimbatus most, I would like to tag @Micha and @Markus to ask what their thoughts on the subject are.  Also, let me know if tagging you guys for an opinion is annoying.

    • Like 1
  4. Altitude would be a strategic decision; it has advantages and disadvantages you have to weigh.  I'm not sure why thrusters wouldn't work in water; "equal and opposite reaction" is what it is, in space or in water.

    At the moment though, I keep feeling like props are one of those "Let's make the challenging parts not challenging" things.

    As for all drones working everywhere, I suspect that when progression mechanics are implemented, and we can't built massive 400-part beasts that can factory-manufacture six different purpose-built drones on level one, we'll see more players with more than one drone in their roster. 

    I don't think a lack of diverse parts are the problem; I think no progression mechanics are the problem.

    • Like 2
  5. It's not really a matter of easy.  It's more a matter of wanting players to have meaningful,  strategic choices.  Any choice that has a right and a wrong answer isn't really meaningful or strategic - just correct or incorrect.  In this case, you'd have a 'correct' engine for worlds of high air resistance, and the dominant strategy would be to duplicate your drone, replacing all the engines with props.  I'm not really a fan of that, because it feels like adding busywork as a barrier to efficient design.

    I'd like to see more engine designs that require you to make a choice in a balance of efficiency versus power, or other factors, something that forces you to balance what you lose against what you gain.

    • Like 1
  6. 32 minutes ago, Philo said:

    Experimenting with obstacles in the autonomous drone racing mode. Not quite there yet xD
    Disclaimer: Not even sure if this will be in the game at all, just testing out some things :)

     

    THIS ABSOLUTELY HAS TO BE IN THE GAME, AT EXACTLY THIS OR GREATER LEVELS OF LETHALITY.

    • Haha 3
  7. I just want to keep away from having things respond to logic invisibly in any way.  If you have things going invisible as a part of their operation, it could make them hard to troubleshoot.  A toggle you can turn  things visible to troubleshoot, then turn them off when you've got them working.

  8. 7 hours ago, unmog said:

    Basically I could see some use of its current behavior. Though it'd be nice if we could use them as a way to isolate signals to just whats beyond. AKA, an empty battery signal not transmitting to the whole map just the part it was attached to. Or maybe Im just using them wrong~ it just seems like when its on everything can hear it regardless. An all or none scenario.

    Right now, only children can hear the wireless part; just as signals sent to a splitter can be heard by its children.

    For that scenario, an actual splitter would be useful, too.

  9. The devs have said that logic's connectivity, like fuel and energy, could be changed easily; that they made an arbitrary decision that it should be global, rather than there being a constraint upon it or having a reason for it, that it may change again in the future.  When splitters happened or why splitters happened isn't really relevant to what should happen.

    13 minutes ago, notsew93 said:

    If I had to hazard a guess

    The speculation you describe basically amounts to parts querying for connected signals, and can use the solution I presented for that.  Find a way to differentiate the signal, and generate a duplicate differentiated as wireless on the correct tree.  If a signal is wireless, and a wireless part is among your parents, then the call's for you.

    There are a lot of problems - code always presents a lot of problems.  A coder's job is solutions, and I think the beginning of a solution to any possible propagation model is pretty clearly visible.  Only the details are left, and those we can't predict without knowing the code.

  10. 3 hours ago, notsew93 said:

    without feeling like it is a quirky band-aid to an underlying propagation model problem

    I don't think this is a band-aid. I think this plus local logic is a complete solution that fulfills a multitude of logic requests.  Switchable splitters, wireless single -key transceivers, wireless transmitter/receiver pairs, they're all attempts to solve one little corner of the problem.  I don't think new logic parts are a solution.  I think they are the band-aid.

    Propagation is a pretty simple thing in principle, and when you need it to be selective, there's not usually a lot of more elegant solutions than making it selective - though I'd be pleased if someone managed to prove me wrong.

    3 hours ago, notsew93 said:

    Plus, if the wireless transmitter passes signals from the core up and down, but only returns signals from below, then suddenly it is asymmetric. How would a player figure out such a strange property without essentially a paragraph-sized tooltip?

     

     

    "Allows non-wireless signals to pass freely."  Is this less intuitive than a wireless connector blocking connections when we already have a connection blocker part right next to it?  The game doesn't imply it should, real life doesn't imply that it should, the player has no reason to expect it.

    In my opinion, the most confusing part of wireless connectors - that they speak only to children - is already in the game.

    3 hours ago, notsew93 said:

    Unfortunately, I fear that this change could require up to a total rewrite of the logic propagation - at present, there are no examples that I know of that pass certain signals selectively based on where they are sourced from. 

     

    I see a couple of paths to implementation present themselves, based on how logic works, which isn't fully clear. If parts reach out to find all connected signals, this might be more challenging than if each part receiving a signal forwards it on. 

    What you would need is to differentiate wireless signals from normal signals.  Once you have that, it's as easy as disregarding signals that are wireless, and a child of yourself, and the child of a wireless part. 

    But if signals actually do propagate, (in code, not in gameplay - parts might query for connected signals instead) I don't see much issue.  Have the wireless part propagate signals as normal, but have a special case for its own signals to propagate only to children.

     

     

×
×
  • Create New...