Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Lurkily

  1. In fact, if we get sound, I'm gonna make a drone with a bank of multi-beam lasers in different colors flashing on and off to some horrible and stupid dance beat. Because reasons.
  2. Somebody really wants a pink drone.
  3. I want a disco ball on my drone.
  4. 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.
  5. 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.
  6. 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.
  7. Well, for one thing, it wouldn't bring as much concern of collateral damage. I can't use multi-beams for most of my harvesters, because they're too scattershot and end up eating ore instead of terrain. I mean the damage is there with or without the accuracy.
  8. 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.
  9. 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.
  10. . . . yet?
  11. I have long been a proponent of a round distance sensor, as well as directional sensor; They both sometimes have occasion to be rotated at odd angles.
  12. Are you guys trying something new with the distance sensors there? Do they look different, or is that low resolution speaking?
  13. Huh . . .I guess that's what that fourth pip means.
  14. THIS ABSOLUTELY HAS TO BE IN THE GAME, AT EXACTLY THIS OR GREATER LEVELS OF LETHALITY.
  15. Do you mean remapping the input in the build screen, or was there something else going on with keyboard or macro apps?
  16. 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.
  17. This was posted to Nimbatus feature requests. I moved your post to the correct subforum. Welcome to the community.
  18. Maybe a visibility toggle on the build menu? You can act or not on the signals with a little logic, so visibility is the critical issue.
  19. I am clueless. Autohotkey shouldn't be capable of this. It can send the keypress or not, but what the game does with that keypress is beyond it.
  20. 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.
  21. I've never had inputs changed. Are you positive they weren't always set to 'W', and it didn't take you a couple test runs to really get maneuvering and notice the problem? I've missed thruster problems before while absorbed with weapons testing, or whatnot.
  22. As for a method of differentiation, prefix a wireless signal with a character the player can't use, some weird unicode character. If a wireless part is your parent, strip those when you find that signal in your region of the signal tree, or when you query, or when signals propagate. However it works.
  23. 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. 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.
  24. 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. "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. 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.
  25. I gotcha. I just don't want to see this one left behind because it's over focused, and just looks cool. It can look cool and be more generalized too, I hope.
×
×
  • Create New...