Jump to content
Stray Fawn Community


  • Content count

  • Joined

  • Last visited

  • Days Won


Lurkily last won the day on May 14

Lurkily had the most liked content!

Community Reputation

63 Excellent

About Lurkily

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Lurkily

    Right click to attach/detach

    I suspect that for computational and physics reasons, multiple connections is not likely -- it's not just an interface problem, in other words, it's by design. It was experimented with pre-demo, but was never released as a public build or a backer build. Rover solutions are supposed to be in the works, and various solutions to rigid drones, too.
  2. And, not to labor the point, but -100% damage to ores would be nice for us fans of autonomous drones.
  3. Lurkily

    Overwriting logic gate

    Take a look at this suggestion: This is a suggestion for a part that would provide a table of possible inputs. Thus you could map out several inputs, and the output produced by ANY possible combination of these inputs. I think this is a fantastic idea; it's more of a 'computer' part than a logic gate, but it lays out a lot of possible logic in a very easily understood way. This would do exactly what you need here, and much more besides.
  4. Lurkily

    Overwriting logic gate

    Input A produces output C Input B produces output D Input AB produces output D You can currently do this with four blocks. IF A, then 1. NAND outputs 2, if only A, or only B, is pressed. (Not both, or neither.) Output C, if both 1 AND 2 are input. IF input B, output D. You can reduce this to three if you merely use B as the final output, instead of requiring it to activate D. IF A, then 1 NAND outputs 2, if only A or D are pressed, not both or neither. If both 1 AND 2 are input, output C. Someone verify this though. It's the end of a long day.
  5. Lurkily

    Automatic Drones

    The crop duster by @Kabbyyss probably beat you by a week or so, @MLGTASTIC, but it wasn't nearly so large or complex. That dive-and-leap behavior is something I spent hours and hours and hours trying to eliminate. It's the natural state of all my automated drones, and I always needed lots of control thrust and lots of logic to control it. That's pretty good control for a first iteration.
  6. Lurkily

    Recource sender/receiver

    I'm gonna second this. Have the Nimbatus or the deposit bin also manufacture containers, and have the collector capable of drawing fuel or energy from the container until it's destroyed. I would suggest having the 'sending' be something the player has to engineer, though. It'll be a challenge, but I think the game logic is perfectly capable of engineering a relay drone to bring them to you. Some kind of grappler will be needed though, and container detection.
  7. Lurkily

    Part Placers

  8. Lurkily

    Not back compatible

    I have to admit, it would be nice to be able to import the drone designs, at least, from older versions; most of the components still do the same things. I have those old saves, but not exported drone files, so that's a loss.
  9. My biggest want is a way to sense the deposit bin. After that, my wish list for criteria goes: Drone self (Part connected to the sensor) Drone part (any drone part regardless of connection) Nimbatus (Because, who knows, one day I might want to.) Enemy unit Snake Enemy structure Ore Terrain Container Out of curiousity, what would you do differently between hives and transmitters? Both need killin'.
  10. I like that more than my original suggestion. In my suggestion, rotation would produce erratic near-zero vectors. By selecting only certain thruster groups (such as the port forward thrust to produce rotation, but not the rearward starboard thrust) you could check the effect of each sub-group of thrusters as well as larger groups. I dislike the idea of showing the vector of every thruster individually when they're selected. In an asymmetric drone, I feel that it wouldn't give a good idea of whether the sum of a large group of thrusters is aligned with the center of mass. I'd far prefer having one center of thrust, and one vector, for all currently selected thrusters. As an example, say you have a large bank of thrusters, and your center-of-mass isn't exactly aligned with any possible position a thruster would snap to. You would have to offset one or two thrusters instead of the whole bank to try and bring the sum of the thrust straight through the center of mass, and it can be hard to judge accurately.
  11. Lurkily

    Allow selecting multiple of the same part type

    What if all the parts were listed in a directory-tree-style menu to the left (in order of the number of connections from the core) and each part, in a submenu that you could expand or collapse, had properties you could copy and paste? You could mouse-over each part to highlight it, then click on certain property of a part to select it. In this menu, traditional windows file manager management could work. As an example, you could expand a detector's properties, select its range and CTRL-C to copy it, then CTRL-select every detector, and CTRL-V to 'paste' that property to them.
  12. Lurkily

    things to take in cosideration

    Keep in mind that we're in closed alpha. A lot of the structure that makes a game into something balanced and engaging are developed in this stage, so don't take the current state of things as an indication of how the dev wants the final product to look.
  13. Just in the editor, but here's the thing. My forward thrust usually isn't one thruster, it's usually a grouping. In some drones, I use logic to control turning thrusters so that they ALL contribute to forward thrust, and some turn on, others off, when I turn. What I'd like is to be able to enter inputs, and show the center-of-thrust and vector for all thrusters activated by that grouping. I would represent this as a circle for the center of thrust, and a line transecting that circle showing vector. For instance, if I enter the inputs for direct forward thrust, I should have a center of thrust that is on the ship's axis, and its thrust vector, the line transecting the center-of-thrust, should ALSO transect center-of-mass. If it does not, it will tell me that my ship has asymmetric thrust, and give me feedback on how bad it is, and how to fix it. If I enter the input for turning left, the center-of-thrust should be far from the center-of-mass, and the thrust vector, ideally, perpendicular to the center of mass. If I add the input for forward thrust, and the vector is closer and/or less perpendicular, this will show you exactly how much maneuverability you lose when you're also under forward thrust. Edit: The most ideal rotational thrust would not have a net vector at all, so a 'dead zone' for very slight vectors would probably be wise. CTRL-clicking to select groups of thrusters would also be a good alternative to entering inputs, and would let you select individual groupings that do the same thing - such as the port thrusters for turning CCW, and the starboard thrusters for turning CCW.
  14. I'd like a place I can enter an input, or a group of inputs that would activate thrusters. (For instance, W, or W and D, or W when a certain detector is also triggered) When thrusters are activated by the inputs entered, or by logic responding to those inputs, I'd like to see a circle indicate those thrusters' center of thrust (a circle, so that it is visible if aligned with the center of mass dot), and I'd like a line across the screen indicating the thrust vector. This way we can make sure, when we build an asymmetric drone, that we can align thrust with the center of mass. We can put the CoT beyond the CoM for stablility, or behind it for manueverability. (I don't know if the physics will bear that difference out, though.) The line will tell us if our thrust will cause our drone to drift - a thrust vector directly through the CoM will be a straight thrust. The further its closest point is from the CoM, the more the drone will turn.
  15. Lurkily

    New enemmy: steam monster

    I'd rather have them literally utilized in the level. If you need a light source, use the captured enemy for light. Use the exploding fireflies in a no-weapons level as your only weapon, so on and so forth.