Lurkily

I thought that's what he suggested, that the Nimbatus vacuum stuff up from you instead of dropping it in a hopper. Substantively means in a meaningful or important way, while substantially means to a significant extent. They're similar, but the connotations differ in a manner similar to 'quantity vs quality'.

This seems like you could implement it with some logic and dynamic thrusters. I once suggested wings; a piece which would generate upward trust, based on a combination of altitude and speed. I once suggested wings; a piece which would generate upward trust, based on a combination of altitude and speed. There doesn't seem to be a lot of love for atmospheric mechanics.

Bio is energy?

I'm not sure if that's substantively different from this suggestion. Can you elaborate?

Additionally, use these templates, instead of constructed drone parts, as factory outputs. That would make self-replicating drones more realistic.

I would definitely kill a man for a blueprint book I could transfer from creation to creation.

I'm not sure about purchasing more upgrade slots. Being able to add EVERY fire-speed and projectile-count upgrade would be silly. I do think, however, that weapon downgrades are too harsh in occupying an upgrade slot. I think weapon downgrades should CREATE an upgrade slot, so that tailoring your weapon for a specific use -- thus making it less useful for any other thing - doesn't prevent you from using upgrades for that purpose, too. For instance, I wanted a terrain-eating flamer. I added particle gravity, particle bounce, and particle lifetime, to try and create a carpet of particles that would eat into terrain. Of course, this begs for digging upgrades, too, but I'm out of slots. Take out gravity, or bounce, and the effect doesn't work. Take out lifetime, and the effect is almost fully negated, as well.

I guess my concern is that Sumo tactics can be so weird and unpredictable, that there might be a crappy drone out that that can't really beat anything, but due to deterministic behavior, happens to have your drone's number, and can knock you out with a fluke. Sure, part of the challenge is to design against that kind of thing, but I personally like the idea, more, of earning points in a battle, and taking the average of your last 25 or however many battles as your rating, then derive a ranking from that rating. You can limit who you can challenge by the delta in those ratings, fluke wins and fluke losses will eventually vanish from your ratings, and it seems relatively simple to program, maintain, and organize, without needing arbitrary cutoff points between classifications. You can still use classifications as signifiers of player skill, as an accomplishment granted.

I would LOVE being able to set the ground on fire, or wash it with acid. Something that would propagate, but each child propagation less effective, until it ran out of either propagation or terrain. Here's for nanite weaponry!

I assumed inefficiency was the limiting factor, but with the high energy output you mentioned, I wasn't sure. Thanks for clarifying.

I think in maximizing understanding, you need to pace player's exposure to new blocks. At first, even armor, engines, and guns is more than enough for a new player to have trouble understanding. I absolutely think new technologies should be unlocked through progression, to allow players some exposure to a new technology before giving them more - otherwise you risk information overload. My personal opinion is that research should be taken out of the weapon designer; only show researched tech there. Elsewhere you should have a real tech tree. Anything other than thrusters, basic blasters and hinges, basic energy and fuel, and basic armor should be behind progression gates. My recommendation would be not to reward either focused or broad research; that is, limit price escalation with advanced technologies so that people can research many things, or focus on the things that suit their style, without necessarily falling behind either way. I would sort the tree the same way the build categories are sorted; energy/fuel research, mechanical research, weapon research, engine research, logic research, etc. I would also make starting technologies very cheap, to allow players to expand their basic capabilities quickly, and give them a taste of how more advanced entries can benefit them.

That's more of a new weapon type, or a flamer upgrade, than a damage type. I am in favor of a weapontype that acts more like liquid; if the no-damage-to-ore upgrades ever become a thing, it would be a good miner.

The topic is confusing, so bear with me while I clarify. Currently, if I build a drone with a chain of factories, I'll start the game with every factory complete, and every sub-part of those factories complete, and when I release those parts, the factories will very very slowly rebuild the entire mass. I would prefer to start with these things unbuilt. Thus instead, you will start without all your completed drones. Instead, the first factory will construct its sub-drone, as well as the second factory. The second drone will construct the third factory, etc. This will permit the building of a 'seed' that you can release which can grow into a swarm, or a progressively more complex structure. For instance, you could drop a factory that just spawned a scanning gun turret and a factory. That factory might spawn armor and a couple more factories, which would, in turn, spawn more armor and guns, to create a progressively more fortified creation. As it stands now we enter the game with an entire castle built, and when we drop the one factory, it builds the entire creation at once, or nothing. An alternative might be to make the factory construct in tiers; direct children first, then children of children, then grandchildren, great-grandchildren, etc; this would also serve the purpose of making construction less of an all-or-nothing affair, and more of an organic process that can happen in stages.

I would actually prefer this to the current hopper. Automated drones have issues with gettting over/under that hopper.

Here's a question. Why not replace all your energy with fuel tanks and fuel cells?

Ah, heat sinks. (Which is basically a fancy name for a radiator.) Have them equalize temperature between themselves and other nearby parts that have at least a minimum temperature gradient. Perhaps have them work in concert with directly linked radiator (Or permit the creation of non-physics linkages for this purpose) so that chains of them can work in concert, and have them equalize temp. That way they won't completely isolate your ship from harm until your ship is entirely on fire or entirely frozen, but they will still help dissipate the impact of heating and cooling. I like this. It gets my vote. Heaters and coolers can work in concerts with these to help provide more distributed climate control, too.

What about something more like traditional flak shells, just explode at the end of a trajectory? Projectile lifetime + big bang (You can use that on guns/shotguns, right?) might be suitable, and is more representative of how flak really works, if I recall. Doesn't real flak, WWII style, have to be ranged for its target to explode in proximity?

I set up some missiles as heat seekers. I was going to use them as more or less untargeted weapons; a satellite factory would manufacture orbiters that would rain death from above, and heat seeking would help home those shots in on any hostile target. That doesn't seem to be happening.

I have to say, I'm a little split on the division between biological and technological enemies. It seems to limit the ability to make really interesting builds (Like magnetically guided missiles) that can be really useful. I like the requirement to play more tactically, but I feel like this will stifle the drive to be really creative; that people will just add more guns instead of trying to do really interesting stuff.

To be fair, though . . . . . . . It would be interesting to see blocks where you can set up the X and Y axis with an array of inputs, and outputs in a table produced between them, so that you could easily see the result of any combination of inputs, and could cascade a single input or combination of inputs into complex results. But then, that would also obsolete a lot of existing blocks, so I'm not sure how good an idea it is.

For simple tank steering, this should be doable with two logic blocks; If W output A, and If W output D. Two more for reverse, if you don't just turn around to back up.

I know I've posted before about having an 'angle' to detectors that is inversely proportional to the maximum range. Why not treat them like directional sensors? Directional sensors have a range and an angle of 0-360. Zero degrees is a straight line with a long maximum range, and as you increase the angle, the maximum range goes down. You can have a short-ranged omnidirectional sensor, or a long-ranged laser sensor. You can set two arcs up with a gap between them, and these can be used almost as a directional sensor; anything falling within the arc of your sensors, you can align a weapon on. I would suggest making these function like a directional sensor, with two halves and a tolerance, but that might be a little overcomplex, and I don't think two sensors is overkill for a targeting system. (The directional sensor is way too big, but the directional sensors not so much.)

I like the altimeter! My laptop was busted for a while, so I was out of circulation while it got fixed. I am disappointed in one respect, though. My concept was intended to be used for automated, intelligent behavior; to do this, you have to be able to adjust to the planet's unique geometry. Perhaps the planet's got a lot of peaks, and you need a higher cruising altitude. I think both the altimeter and speedometer need a key input to adjust the target speed/altitude. What I intend to do is make an orbiter; dynamic thrusters that use lateral thrust, not vertical, to literally orbit a planet through velocity alone. I'd have it adjust speed to match the altimeter, and slowly lower the altimeter's target, bumping it back up when downward sensors located enemies or terrain. Forward sensors would have to deal with detecting and evading the resource bucket on the ship's circuit around the planet. As you can see, adjustment of sensor targets may be really, really important for developing actually intelligent behavior.

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.

And, not to labor the point, but -100% damage to ores would be nice for us fans of autonomous drones.