Lurkily

I like the tractor-beam couplers, just that the magnets already exist; in case the barrier would be development resources, I wanted to provide an easily implemented option.

The issue, as it's been explained too late me, is that multiple and potentially circular connections can make physics potentially much more demanding than any benefit would justify.

Hmmmm. Hmmmmmmmmmm. All I can think of is to crisscross a few detectors around the magnet. Can they see barrels, etc?

There's no reason that +50% damage and +25% damage should cost the same amount. (The amount being one upgrade slot.) Instead of purpose-building, it encourages broad-spectrum weapons, and the all-upgrades-are-equal model discourages the use of downgrades. Instead of drones with a number of creative, purpose-built weapons, (My diggers, my long-range missiles, my close-in shotguns, my indiscriminate terrain obliterating grenades) you have more weapons seeking to use the BEST upgrades; and the most effective way to do that is to build weapons that are better at serving every purpose. Even if that's not your goal, that's where you end up. I suggest that every weapon have a certain number of upgrade points. Let's say 12. The most powerful upgrades should cost 4 points, as they do now; you get three badass upgrades. But say you only want a digger? Most upgrade trees only go out 5 or 6 tiers. So the core energy upgrade (Tier 0) can cost one point, along with Tier 2. Tier 2 and 3, 2 points, tier 4 and up, 3 points, and the last tier of any tree, four points. Downgrades can make a more focused weapon, but they're still a downgrade. They limit a weapon to a single task, even while they may improve that task, I think they should provide a rebate. But because higher-tiered downgrades aren't always more effective, higher tiers shouldn't grant higher rebates. In fact, I suggest a single point for any downgrade. This provides an incentive to focus your weapon's usefulness, and perhaps equip more types of weapon. But it also doesn't incentivize you (as much) to take every downgrade available so you can take more and more upgrades.

Honestly? I mean, really honestly? Why do even-numbered upgrades exist? They're awkward and weird. Let's replace them with something else. Instead of 2,3,4,5 beams, give us 3 and 5, and two something interesting. There are all sorts of cool tricks that lasers don't get, let's borrow some. AOE at laser impact. Generate a vacuum to suck enemies into the impact area. (stay on target ... stay on target ...) Auto-target the nearest terrain within an arc. (Sweep out those invisible particles, dammit!) Shape the beam like a travelling sine wave, same damage potential, but unfocused and more fanned-out. Increased elemental effect, with decreased damage. (I'm okay with a mixed effect here, since this is an inherent property of elemental damage.)

This is a common one; I'm certain I've seen similar suggestions before. Absolutely needed.

I'd worry that bots would try to use them to introduce weaponry into tournaments; freeze enemy thrusters, or set the enemy on fire.

The problem with very compact variables, is that sometimes you start writing and realize that two functions have the same initials; there are always ways to compress and streamline code after you're done making it functional. I wrote a little javascript in the early, early web, when we had to worry obsessively over load times, optimizing every image and script, and I could write very explicit code, then run a script to compress it to a nub. And remember, this game is meant to be accessible to novice programmers, or even non-programmers; they're exactly the market for this game. Hynekjhael has a valid point that would serve to improve gameplay. Attacking his cred as a programmer doesn't serve any purpose here.

Is that because programmers don't have these needs or challenges? Or because a programmer would understand that it's unreasonable to ask? (Is it unreasonable?) I'm not a professional programmer, but I've worked with C++ in my youth, and have a shallow familiarity with a number of scripting languages - javascript, lua, etc. I see nothing wrong with the idea that a programmer should want to be able to edit his inputs with ease, and that common sense should apply to the text fields used for it.

Just like magma planets; anything closer than a certain distance to the core is water. Spawn the planet with large interior gaps, or no interior mass below a certain altitude. Add water critters.

My understanding is that weapons are inherently different from other blocks, and that this is difficult to implement. I would like an upgrade tree for every category of items that exists, including gates to unlock new items. Armor, mechanics, fuel and energy, engines, weapons, sensors, logic. (Logic upgrades would probably consist primarily of unlocking new components.)

Or you could irritate your sumo opponent until they are forced to forfeit to make it stop.

So, I stumbled on a problem recently. I had a large drone that decoupled from the core and a factory, which flew off to hide. Thus I could rebuild my drone, if destroyed. My drone was big enough that I used a decoupler chain to distance it from the core. In addition, it would deploy sub-drones that would carry ore containers to the hopper, drop into them, and once they touch down in the hopper, they would self-destruct. Every time it did this, it was cutting off my main drone. Finally, Entity helped me figure out why. The decoupler that I had used to connect the body of the drone to the core fell into the hopper, and during the subdrone's self-destruct, it destroyed the parent block to ALL my drone body's blocks. It just fell dead, a puppet with its strings cut. So I request that the cascade of de-activation of drone parts, after the destruction of a part with children, does not cascade beyond a factory or beyond a decoupler. Even if they're still coupled, those parts may still be fully functional.

I've immediately stumbled on another problem; in my minor redesign to fix this, somehow my ore couriers don't work anymore. Now newly spawned ore-canisters cannot be filled by harvesting. (I had this working just fine previously, in a couple of drones.)

Oh, criminy, it's blowing up the parent decoupler, craptasm. THANK you for seeing that, I was beating my head against a wall! I figured it was something stupid that I did, but I thought it would be some weird signal issue. Thank you again.

This happens with enemies as well. If they spawn overlapping terrain, they can fly through it.

Would you prefer the spread be even, but not a single beam be exactly on target? There would be a hole with no lasers at your aim point, even if you used multiple overlapping lasers.

I have this drone; the core deploys the main body via a factory, (backup system, and the core serves as a homing beacon for ore couriers) and then I can build and release sub-drones that carry ore to the hopper. The problem is, the sub-drones self-destruct once they touch down in the hopper, to keep spare parts from piling up, and once they do, the ENTIRE main body of the drone goes dark. I can remanufacture it and find it again - the whole thing is there, dead and undamaged. I am attaching a drone file. F releases the ore courier - R to manufacture another. Get into the test arena, let the courier go, and watch it fall. (If you push it and it goes off-center, it'll go back up to 100 altitude before falling - because it can't know the hopper altitude. Just let it fall. ) EDIT: Or delete the central downward facing thruster, leaving it only capable of self-righting, and left-right orbit while at high altitude. Nimbatus tracker-core beacon.drn

I'm not certain about props; I don't like the idea of there being too many special-case "this one thing can only do this one thing and it's the only thing" scenarios. It introduces a tactical need, but the decision to use props on a water planet isn't a strategic choice - there are no strategic decisions when the answers are all correct or incorrect. I'm tentatively in favor of turbines; engines that work more effectively at lower altitudes, and because of what a turbine is, it's conceivable they could be suited to water, too. But . . . why would a thruster not work in water? I mean, it's not like a normal fire, the oxygen for burning a rocket is in the fuel.

Sorry. I clearly misread your intent there.

There's a reverse buffer gate in here somewhere that you should find and upvote.

I've been able to load ore into factory-built parts. One of my recent projects was an ore courier that would build with ore canisters, detach, then carry it back to the hopper. I can send that courier on multiple runs in a single mission, so I know it's not connected to whether it's the pre-built courier, or one of later manufacture. Absolutely 100% agree on directional sensors. I want 'nearest enemy,' 'nearest ore,' 'hopper,' and I want to be able to name a part, and have it point to that part. I also want a proximity sensor to measure distance to these things. I've considered math blocks that can read the value of some blocks (distance to detection from a directional sensor, current altitude from an altitude sensor, speed, etc) and perform a simple operation on it. Give them the ability to perform a simple operation and read other math blocks as well, and you'd have your number handling; in the end, a 'result' block could output a tag or keypress based on a test of equal, not equal, less than, greater than, etc.

But why is a smaller drone an issue? It's not like your competitors won't have the same capability, and you're still limited by part count, right?

I'm kind of agreed with others on this. First, we already sort of have this functionality, in that a module can output both a button and a tag. (Which I think is kind of cheaty, myself.) Second, it only requires one additional block, and very little complexity to do this. It isn't a confusing solution.

I actually have an electric lighter. Though it produces a heated arc, not actually flame. It makes real-world sense, but I'm not sure it's an improvement to gameplay to have this one weapon that doesn't act like other weapons. I think there'll be some confusion as people add more and more energy, and wonder why it isn't helping them. I did have a suggestion for a 'magazine' block; it would basically be weapon energy. Weapons could use regular energy with a debuff to every stat, but a magazine would be their optimal source, first choice, and specialized magazines with input activation could alter weapon behavior - give ammo special properties or different damage types.