Lurkily

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I was browsing through older threads, and found this. Reassembly did it by having a 'factory' part which consisted of two parts that would construct anything placed between them in the editor. I like a different suggestion that's come up here, which is to reconstruct anything on the other side of a specialized decoupler, using the decoupled part to act as a 'core' for the detatched unit. (A target for enemies, an anchor by which to determine what is a part of the sub-drone, and if necessary, a signifier of when the drone can be considered 'destroyed'.)

So . . . why not just use plasma or kinetic? We already don't have a lot of diversity between the four damage types that exist. What would set acid apart?

Yes, remember, and YES, decoupler-center-of-mass.

But then you can't see. Let's make an enemy that you have to UTILIZE instead of kill.

I can get behind this one. I expect we'll be seeing more of this as some AI of note gets implemented, and enemies begin to roam more.

Exactly how I'd hope for this to work. In fact, I'd prefer it to be additional options to the current detector we have, rather than a new sensor, since in this layout it can mimic the detector's behavior.

This is exactly one of the things that I want paired distance sensors and directional sensors for. You can design drones that are engineered to maintain certain formations, and if one of those sensors is dumped in your collection bucket at the start of a level, (Or directional sensors that can point toward the nimbatus or collection bin) you could very easily use it as a landmark by which to position larger, global formations. The OTHER thing I want this for is to have a fleet of sub drones providing extra weaponry (like the 'options' in Gradius). Being able to pair directional sensors and know your distance to a specific drone part would enable some precision formation flying and drone fleets.

Scientific missions to capture specimens of a particular enemy type; whatever means necessary. It would require some equipment specialized to the task, and perhaps some interesting design, too.

I think distance from center keeps things simple, and detectors can help you learn and operate logically on distance from the surface. Besides, if you destroy the surface but maintain the same altitude, a satellite will lose effectiveness.

Personally, I'd like to see shields be something more like Wayward Terran Frontier, something regenerated from a source at the generators, but which you can dig a hole into. Right now you either have to overwhelm energy reserves, fire from within the shield, or destroy it entirely. It's either entirely effective or entirely ineffective.

Absolutely. Turn to a certain direction (Gravity, sumo center, cursor, etc,) and an offset. (So cruising thrusters could be gravity, offset by 90 degrees. I also would not mind going bigger than small thrusters; I made a drone with vectored thrust a long while back, and it required a ridiculous mess. You might balance their utility by limiting their arc to 90 degrees.

TNT weapons are sketchy until we can rebuild things that we decouple. Until then, they're a one-shot, and a severe liability if they're hit before they're used. Still, I think a solution to rebuilding sub-drones is a better solution to weapons with complex, intelligent behavior.

I can confirm that I have made both walkers and rovers in the alpha demo using this trick.