Lurkily

Does this ever end? Might I end up with an 81x81 death laser satellite?

I'd love to see these get an angle and range setting; tailor the durability for shields so that less coverage means a tougher shield.

What about concussion ammo? It's similar to what you're talking about, in that it uses shockwaves of compressed (explosively compressed) gas, and is meant to be less lethal, generally. It could be characterized by a much higher impact force without more damage. The issue currently is that I don't think terrain and ore are different things, in the code. I think that work will have to be done to separate these so that they can be affected differently and separately. It might be more realistic to simply ask them to further increase ore's resistance to digging. (It seems to take less damage from weapons.)

What about a sumo ring with nothing but a gravity well, with a few TNT bombs floating in it? Your goal isn't to push the enemy out of the ring, but to push him into contact with the TNT. Whoever detonates the TNT (Or whoever takes more damage from detonation) loses. Use a somewhat larger ring, and make exiting the ring a draw condition, so that runners aren't a useful option. This seems simple, but the logic to force someone INTO position is much more demanding than the logic to force someone OUT of position.

Not 100% certain I'm on board with skins, but I'm notoriously unconcerned with multiplayer, so maybe that's just me. I'm far more concerned with logic and sensors. Not trying to disparage . . . I just worry sometimes that the admins get less feedback about what's important to players than they'd like. Maybe some feedback polls should go up. Not that you have to listen to us, mind, I'm just firing off random thoughts. I'm also sick, so maybe not thinking clearly as I should. \

There have been a number of suggestions for a 'computer' or 'processor' block, which would contain a number of logic blocks in a second grid or table that you could open up. It would work as it is currently, except that the logic blocks would all operate from within a single part on your drone. (Keep that part safe!)

It IS rather overcomplicated to have to use two gates for this. If I were coding in almost any language, this would be one test; if A =1 and B=0. This is no more complex than if A=1 and B=1, a single AND block in our current layout. In fact, almost any other combination is a single block. I've long thought "If X is true and Y is false" is too challenging. You can get it to work, but it's not straightforward, and for people who aren't veteran coders, having very complex, (and at first glance, apparently useless gates) but not this option can be frustrating. I do think this would have to be a separate gate, though.

Personally, I think entering a TAG should disable the key input/output. You should get one or the other. It's weird to me that because you have the option of using tags, a part should gain more function (accept the tag OR keypress) when you use both. It almost makes it less of a helper option, and more of a correct decision in cases where it's helpful.

The problem is coming up with a mechanic that's easy and intuitive to explain to a user; a more complex or awkward mechanic might be worth it, if it's easier to explain.

What I'd like is for a selected logic part to have lines to every part its inputs or outputs are used by. Color those lines if they lead to something on the other side of a factory or decoupler, to indicate that they may not ALWAYS be connected. In addition, a fainter line indicating the inputs and outputs THOSE parts are connected to. So you see bright direct connections, and a hint of the larger web of interactions.

You know . . . another solution might be to just make a few large armor blocks. A 1x8 block, an 'L' block that's the size of two 1x4 blocks, etc. A couple bits like this would provide a structurally sound anchor that many parts could link to. It wouldn't eliminate wobble, but it would make the ship more cohesive. What about 'inertial dampeners', a part that specifically dampens physics a bit within the connected ship? They could require energy, but enough of them could make a ship rigid, too.

I have a drone that factory-prints ore couriers; a little ship with ore canisters that takes off for the hopper, drops the canisters in, and then self-destructs. These do not take friendly fire. When they're attacked, I've been able to damage their parts . . . . sometimes, and only after they're attacked. One damaged drone I wasn't able to destroy. I assumed it was because it had a functioning solar cell left, which I didn't recall on other sub-drones I destroyed. Maybe the criteria is something else.

Ooooooooooooooooooooh. I thought you meant something Reassembly style, where everything that generates forward thrust is fired when you hit forward, so the same thrusters are often used for multiple vectors. I see what you're getting at. CoM isn't a great way to do it, if that's how it's currently done. I admit I ignored it for the most part, and just accepted that it would always be wrong and need to be changed.

You can destroy any drone structure that no longer has energy or fuel attached to its structure, I believe. If there's a functional battery left on it, it's immune.

I also think directional sensors need an arc - reduce max range as you increase arc until you have a short-ranged 360 degree sensor. I've used hinges for sensor sweeps before, but it's not a great solution, nor is bristling your ship with sensors.

doesnt have to be soon, it would be a nice feature in the finished game The thing is, does it add enough value to justify development time that might be alternately spent improving the feature set?

This is actually something you can do with logic. Two directional sensors, tip them 45 degrees. If W and upright, hit the forward thrust. If W and turned right, etc. You'd need a lot. Just thinking about it for a couple seconds, my solution would require (assuming four thrust groups) 2 directional sensors' undivided attention and 16 AND blocks. There's probably a better way, though. Much easier to just have your drone self-orient so that it always faces the direction in which your controls make sense.

You could put critical sections of your ship on the other side of a factory block, and just discard and rebuild if you take damage. I made one ship that can basically "Escape pod" the core, and rebuild the whole drone.

Yeah, I think this is different enough to merit separation. I think integrating directional-sensor-style logic into the control of a weapon's rotation is something that should be seriously considered. What about a third weapon type that provides inputs for rotation, and outputs for whether the nearest enemy is clockwise or counter?

The reason I suggest making fused blocks fully rigid is because it requires no physics calculations, and doesn't risk circular connections that can play havoc with the math and increase physics requirements beyond what's reasonable for a small change. Greycore, another option is to 'lace up' your drone with the connections you make, like shoelaces. Bracket the outer hull of your ship in parts that are connected in a zigzag. Thus if the parts on the top of your ship try to pull away, they're also pulling against the bottom of your ship. If you lace most of your interior and exterior this way you'll still have some flex over distance, but you won't have issues like 'flaps' of your ship trying to peel away.

Agreed. Starting without being pre-printed makes sense, and it also makes it simple; it's just the factory's default state. There's less development time needed to polish the settings and the UI that way, time that can be reinvested in more features.

This is corrected, now. I hear what you're saying, but I don't think splitting the features of a sensor out into more sensors to limit the options per sensor is going to be less confusing.

I think things like impact force upgrades are probably better for this; air damage when we're going to be operating in space on some missions seems a little wonky. On the other hand, changing the magnet to an attractor/repulsor might be interesting; it's of really, really, really limited usefulness against actual enemies, right now

I think this is the kind of thing best left in an AND block.

I think he means remapping the hotkeys used in the build manager.