Lurkily

Personally, I think resources are too rare for that - I don't think those parts would be used much, even if a player had unlocked all their research. They're just too exhaustible. Now, if you made these parts consume fuel and energy both, at a very high rate as they recharge, it might make them impossible to really spam without building a ridiculous support system for it, and might make the player consider more when it's appropriate to use a factory.

Someone suggested we get a momentum sensor that detected velocity only along the sensor's alignment.

Agreed; what we have is limiting, but enough, as long as we get sufficient capability in both sensors and logic. However, you don't have to transmit numbers. What about a math block that can read the value of specific parts; say you can tag a dynamic thruster, distance sensor, speedometer, or altimeter as a target. The output would read the thrust setting, distance of detection, speed, altitude, or other math blocks. A particular math block would be able to perform a test - equal, not equal, less than, greater than - and output a keypress or tag while true. Now that I explain it, a second implementation of another layer of math blocks does sound pretty challenging; just as challenging as implementing logic in the first place. But it doesn't necessarily have to interfere with the current logic blocks, either. However, it would make drones capable of more nuanced behavior - more capable of reacting to the degree of detection, rather than the yes/no all or nothing approach we have now. Right now if we need that, we have to make duplicate sensor and logic sets for each situation where we need the response to differ.

Making it a mod will generally kill it; Nimbatus doesn't have a broad audience. Making a niche market within a niche market that people have to seek out and do work to implement is generally unsuccessful, unless that niche market of the niche market is really, really, really, really enthusiastic.

I don't even think you need to ban it. The only issue I see is that a sumo bot could better protect vulnerable and awkward logic sets, and why is that a problem? It's not like everybody won't be able to use it. The logic parts would still count toward the part count and mass. I don't see the problem.

At the very least, start off factory-made batteries and fuel fully depleted.

I would say when in range, and the input is active, exert force on the coupler block to rotate it to it's coupled orientation, and pull it closer. Couple the blocks once they're close enough. I would replace the decoupler with a "coupler," since this basically obsoletes the decoupler.

Agreed. Some have said a square just fits better sometimes, but I don't think being flush helps stabilize a drone much, so if it's one or the other, I'd rather have them all round.

Try to be fair though; balance isn't fully implemented, so there are going to be things that still aren't balanced. I do agree that energy and fuel should be factory-built empty, and either recharge from their parent fuel/energy cells before detaching, or be forced to generate their own energy/fuel.

I remember those magnets, but even then an overlapped shield was more useful. I've always said, back to the closed alpha, that Magnets should be gravitic instead of magnetic. I get the tactical challenge in building for multiple enemy types, but it's just not useful enough, even for mechanical enemies, to build magnetic weapons for a subset of enemy types. PVP is the only use I see for them, or rarely, in ejecting drone parts, like factory outputs, or cohering a large drone.

Honestly, I think your logic now is quite capable. The only thing it's really lacking is mathematical operations. Those you can do now, but it's burdensome and not often useful. (For instance, if I want a smooth but responsive acceleration, I can't tell an engine to increase thrust by (total thrust) - (current thrust output) /2, which would keep bringing thrust halfway to 100% - initially a quick increase, but a slower, smoother approach to 100%. It's a useless example, but math and the handling of numbers is what you're really missing - just adding scripting removes the challenges that make the system interesting. Elsewhere, I repeated a quote from Brandon Sanderson about systems of magic in fiction; it's not what they can do that make them interesting, it's their limitations.

The directional sensors ALSO need to be able to use the hopper's location as a target. And yes, yes yes yes. Proximity sensor, absolutely. Just replace the altimeter with a proxy sensor, that has the planet's core as a criterion. Get rid of planet radius as a criterion, because then the same number doesn't mean the same distance on each world. I dearly, dearly want to be able to name or tag a part, and have directional and proximity sensors that will use the location of those parts as a criterion. (If there are duplicates, just detect the closest.) This would cover homing beacons, this would cover formation flight, this would cover self-awareness beyond what linear detectors can provide for drones that have moving parts - it would do so much for the capabilities of the drones to have an awareness of a SPECIFIC part.

I've mentioned it before; what about inertial dampeners? Straight out of star trek, according to lore they would basically limit the impact of physics in wobbling your ship. In terms of code, they would just make all nearby, or (dev's choice) all connected parts (whether through parent or child parts) more rigid. They would consume energy, so enough of them could make a ship fully rigid at a cost to your efficiency, and requiring you to adapt your construction to that need. This seems like a decent trade-off between oversimplifying shipbuilding (let's make everything rock-solid and simple!) and the current system, which forbids anything beyond a certain size, unless you want a drone made of Jell-O.

I'd support this. I've seen a number of similar suggestions for computers and processors before. I would still like the potential to compress logic somewhat; perhaps put a 3x3 grid for logic inside a 2x2 container.

How would that tell a drone whether it's still connected to the core? The interrupter will interrupt the signal while it's connected, too. There is no way to indicate that two drones once were part of the same structure, but at this moment, are not. You could use a switch activated by disconnecting them, but if you disconnect from a factory, then anything new you build will think it's also disconnected, until you toggle it. Then all the disconnected drones will shut down, thinking they're attached to the core again.

Honestly . . . the only thing I'd ever use magnets for again, that I can foresee, is cohering parts of a very large drone. They just aren't useful for anything but retrieval missions right now. They're rather ineffective against enemy fire, they ARE ineffective against most enemies . . . what if magnet connections could pass energy to a magneted drone? That might provide a second special-case use. I'm on the fence about suggesting the magnet just get outright replaced by the mining part, and allowing the mining part to directionally 'vacuum' objects to it.

I'd agree with that; I'm against code because it removes some logistical challenges, but also because it pushes out novice players from competitive play.

Eldrad, not really plausible. I mean it's possible, but it would mean circumventing the planet multiple times at different altitudes, which would require a set of maybe 10-20 altimeters and logic for when to use each one Markus, as long as we're talking sensors, directional sensors need the same thing.

Why worry about global at all? Make it all local, we have a wireless transmitter. When I was trying to make a subdrone that only engaged thrust when you disconnected it (and it was useless if it disconnected immediately) I was dismayed to learn that I couldn't reliably detect when it was connected, especially if I had more than one copy of it flying around.

I think you're right - but it's unfair, too, as being an early access title, balance isn't fully implemented. I also think that the limits of gameplay are exactly what make it interesting and challenging. Brandon Sanderson (Author) spoke once about systems of magic, and said that it's the limitations that make it interesting, not its capabilities. I think in a game like this, driven by logistical challenges, taking out logistics is counterproductive.

You can connect multiple children to one parent, but you can't connect a child to multiple parents. Some are seeking this to make more stable drones that don't want to split or peel apart under heavy forces. My understanding is that multiple parent connections makes physics more demanding, more than any benefit to gameplay would justify.

Honestly, you guys are the devs. The logic can be anything from "The inverse field flux of the quantum entanglement negates the quantum zero-state energy layer of a resource's mass matrix" to "Fairies did it."

Anything explosive is welcome here.

I've done world-breakers before. Autonomous drones whose sole purpose is to demolish every ounce of mass on a world. And it used to be possible to mine at the same time too, but no longer. So I have a goal now; a drone that will return to the hopper autonomously to drop autonomously mined material. The problem is, I can't figure out how to find the hopper. I had a working model, then I took it off my test planet and learned that the hopper is never at the same altitude twice; it has to be modified, tested, and re-modified for every planet, and being a percentage, a change of '10' means a different thing to the altimeter on each planet, too. My only other idea is to disconnect the drone core and smush it up against the Nimbatus to use as a homing beacon - it's a cheat, in my opinion, but it's all I got. Keep 100 altitude, cruise until the core enters the tolerance of a directional sensor, then cut altitude control to drop in. Maybe set off some TNT to self-destruct once a directional sensor hits bottom. Anybody got a better idea?

I have used Flamethrowers with engines purely for the visuals. I did a pod racer that had thruster groups on the end of strong springs, along with a flamethrower. It looked pretty nice.