Lurkily

I have crafted an exquisite product, the product of hours of research, preparation, and thought. I have honed it through endless iterations. My creation shall dance, it shall weave, it shall bewilder its opponents as it threads the battlefield through the eye of war! It! Is! Gloriou- Yeah, got it. four thrusters, one fuel tank, three sensors. Next?

Make hinges dynamic. Have an 'activate rotation' key, and a key for increase/decreasing rotation value. The rotation value will be -100 (Full speed CCW) to 100 (Full speed CW) with zero being stationary. And if starting/stopping rotation could be more gradual (less of an instant 'jerk' that can shake attached parts) that would be nice. Damage seems . . . odd. If I escape without the destruction of a block, I am usually okay, even in later skirmishes. I almost never see 'the straw that broke the camel's back', a part blowing from minimal damage. I'm assuming they repair themselves. My suggestion for damage would be nanite factories. Require energy AND fuel. Provide nanite tanks to give the player a supply, but regenerate nanites only via the factories. One nanite equals one HP healed. (Or however much HP.) If attached parts are healed, start spreading nanites evenly to parts that are attached to the attached parts. This way you can control what systems are most directly supported by nanite factories. Lastly, if there's nothing to heal, have them rebuild broken blocks. After all, I have a TNT Missile ship/bomber with TNT MIRV warheads that I'm working on, and it's not going to work out very well if it can only fire each one once. Oh, and speaking of MIRVs, I'd like a separator that is less . . . passive. Having 'explosive seperators' that provide a push outward when separating would be great.

A lot is good here. If we're breaking logic into another layer, though, you can put it pretty much anywhere; your worries about center-of-mass affected by logic are basically over, unless your logic gets crazy. You might as well contain logic entirely in the drone brain. I think if we're going that route we might as well just build the logic in a separate interface, and leave it logical. The failing of this is that you won't have a visual display of what logical elements are activating while your ship flies around, without another logic display to show what happens while in flight.

I've done the same before; but autonomous drones are hard to program to use this properly. They want to thrust upward whenever they try and climb a hill. Most drones, you can make them to cope with this, but things get weird in certain circumstances - for example, they have problems when they're dug into a planet core, and have to climb out.

That's kind of what the game does now, except it only permits one connection per block. I was told an earlier build permitted free connection, but you could easily overwhelm the engine by connecting each block to every other block in range. While it would make things more stable, I was informed that the CPU load that developed from that many interconnections is significant. Even permitting limited interconnection, you introduce the possibility of circular physics interactions. That's a potential for physics bugs and CPU burden that might be best avoided, if possible, though it would be good to experiment with. It also doesn't introduce mechanics of build and mass challenges, or introduce real vulnerability.

Some missions could be related to planet types. Loose meteor fields with no gravity could be devoid of missions, but have chunks rich in resources. Random encounters in transit could require you to keep up with your mothership, while also fighting aliens trying to chase it. It would be interesting to have recurring events - every week or so, have a different event type (that rotate and repeat,) that you only get one shot to complete with a fully autonomous drone. Zero gravity survival, search and destroy, dig to the core and dig out again.

What if some mass blocks were part of a separate 'skeletal' layer? This layer could overlap with other blocks, only colliding with each other and weapons fire. Ship components could be anchored to these. Where they were adjacent to other skeletal blocks, they would be absolutely ridid, acting as a single body. (Until they were broken into parts by destruction.) Very large parts could be more mass-efficient, encouraging players to engineer around more complicated constraints. Everything else can be anchored to these, and regular mass-blocks in the regular layer would be able to act as armor without the threat that damage to the armor might damage the skeleton it's fused to. Skeletons should be severe weak points; my current thought is that if the enemy can damage a skeletal block, it should split that damage up, and deal it to every connected non-skeletal block. Large ships may experience skeletal damage under excessive maneuvers, so a degree of thought is still required in making big ships. You can't add a thousand thrusters and handle your battleship like a starfighter. The idea here is to permit more compact ships without sacrificing complexity, to be able to build big, rigid ships while still requiring trade-offs in both mass, vulnerability, and the stress applied to ships.

How CPU-intensive are planets? They seem pretty simple at the moment . . . so I had some thoughts on how to make them more complex. I have noticed planets can be pretty boring. They're big irregular balls, with sometimes some green that's hard to drill through and worth money. I'd like to see larger worlds, formations of various worthless mineral patterns underground that are harder to drill through, or easier, or burn. Larger caves or tunnels would be nifty, as would physics on parts of the world that you 'cut loose'. I'd like to see dynamic structures. Terrain that grows from a seed, so if you damage it, it will grow back until you damage the seed. Entire worlds that grow from the core hives, and can trap you underground if you start digging. Units that build armor around themselves. You could have trees grow from those seeds, or crystals, composed of damageable terrain. I'd also like to be able to turn on terrain in the testing area that regenerates damage, so you can test how a ship navigates unusual terrain, Some liquid physics would be nice. Particles that are affected by gravity and repel each other. Water might effectively absorb weapons fire, burning off slowly. Oil could be trapped underground and erupt when released, and destroy itself while spawning fire, if it's not under a certain amount of pressure from other oil particles (So only the surface burns) Liquid effects would also open the way for acid weapons. I'm going to stop now, or else my speculation would start getting a little wild (Waterworlds! Fish units! Meteors! Ice comets! Elemental interactions! Yeah, if I had my way you'd have to get a whole damn physics sandbox running.)

THAT'S what those things are good for. I'll have to experiment. Do they isolate logic and key outputs on only child parts, or . . . you know what, I'll experiment tonight. String or numerical inputs/outputs would be awesome, though. I've mentioned it before.

I've thought, at first, a cascade of impulses only active when the last impulse flipped a switch, could be used to set pre-programmed actions. (Like, set a turret to rotate x seconds). It doesn't really work, or is more complex than I anticipated. I suggest a modification to 'impulse'. When input of X, output of Y for configurable value of seconds. This could be used to replicate impulse's current behavior, with a little logic, but I almost never need impulse's current behavior. What I need are delays, clocks sequences. Hinges. They need a speed value. And to function as a real turret, they need a way to modify that value so that instead of herky-jerky wobbling, their speed can smoothly increase and decrease to find a target. I would like hinges to have an input to increase CW rotation (or decrease CCW), to increase CCW rotation (or decrease CW) , or to reduce rotation, by a configurable amount. That way a few detectors on a hinge-equipped weapon can turn weapons to focus on an enemy, slow them down, and try to lock them in while focused on the enemy. Detectors DEFINITELY need, at a minimum, to be able to slightly exceed the range of the longest-ranged weapon. We also definitely need detectors with an arc. Line detectors have their uses, but I have a few drones that are PLASTERED with line detectors to provide proper coverage. It's ridiculous. We need to either give line detectors a 'degrees' value, (Which can bottom out at zero for a line, or 360 for a circular area (Enemy detector!) ) Hinges need rotation limits, like gravity sensors, to indicated what angle they're turned at. An upper limit and a lower limit, and an option to generate an output when exceeding either angle. This way you can create weapons that scan a certain direction for enemies. Towers need hinge options. Have the option to fix them as guns (I've mentioned this before) and when fixed, give them all the rotation options that rotating hinges have. This will make towers useful on all drones, and give them advantages over fixed guns on all builds, autonomous and not.

I would be cool with that. Just warn us before we close out that things are floppy, and clearly indicate things that aren't connected. This would also help me figure out what the center of balance of my drone will be after cutting loose disconnecting parts, without deleting them and using CTRL-Z. You'd still need some UI element to indicate when an object would be disconnected if we dropped it there, I think.

Why so much logic, though? My similar build was a back of rotating lasers with one detector that was set to enemy. One button rotated the turret clockwise; the detector output rotated it counter. (This doesn't ALWAYS seem to work - you can add a NOT gate to rotate it clockwise if the detector output is NOT present.

I'd love a sensor like the gravity sensor (Or a modification of it) that links it to a specific block. I would also like rangefingers - circular rather than a line, range to closest terrain, closest enemy, range to a specific block, range to the planet's center. (Output when range is above a mark, and below a mark.) In combination, this would let us create formation flyers. And that would be awesome. I don't think these would be overpowered - line sensors have specific uses that can't really be replaced by these.

I have mixed feelings about this. I have so often been blindsided by not being able to place an object that I am constantly hitting your same problem. However, seeing what's not properly connected would be a problem in a dense build. I'd actually prefer to fix these issues immediately, than have to click out a warning, or possibly miss a warning if I don't have to click it. What shading things with a red outline while out of connection range, and shading a green outline around every part it can connect to? This'd give a clear indication that you need to connect a new part before placing it, AND indicate every part within reach of it when you carry it where you want to place it.

What do you mean by 'attach detachers'? There is a black that breaks away upon an input, if that's what you mean.

I figured I'd stumble on some things you're already working on, and that's okay. I'll keep pouring out the dumb stuff I think of; I think I'll have a dump on sensor ideas, shorty.

I remember the computational cost of the Red Rising games, with their fully destructible structures that computed structural support and stress. I kind of assumed this was an issue here too, but I didn't know. Closing a circle . . . well, it would help. You could enclose the outer hull. But that outer hull would still be a floppy sack. What about just fusing structural blocks that are adjacent into a single block? That way you could make a spine of structural blocks, and could connect to points other than the center - but the structural blocks themselves would act as a single rigid body. (Until they start getting destroyed, that is.) You could forge a skeleton that would be able to anchor the whole ship.

Logic can get confusing as hell. I'd like to be able to open an info panel (Optional, like center of gravity) that shows me ALL assigned keys, and if I select that key, highlights all blocks using it as an input or output. I'd like to be able to assign units to 'families' so that large arrays can share a value. (For example, large sensor arrays sharing a range.) I'd also like to be able to assign an input and output to things that isn't a key. The ship I'm currently working on has multiple segments, each of which need independent thrust and independent hinge control, and I'm running out of keys. Thus I could assign output 10 and input 10 to a thruster and sensor, despite neither of them actually needing a key assignment.

It could be done with simpler blocks. (Not simpler to understand, but built out of simpler blocks.) To activate 'drill to the core' for instance, have a gravity sensor output 1 and two. 3 will activate a switch that outputs 4. Stabilizing thrusters activate if 1 AND 3 (or 2 AND 3) are active. If one OR two are active, output 4. If four is not active, press the trigger keys for digging weapons and downward thrust. That will create a 'coring mode' that can be activated or deactivated with a keypress that will orient your ship towards the core, and if it's upright, will activate thrust and your digging weapons. (I'm sure I made an error somewhere, but you get the idea.) What would be a lot simpler (Again, simpler in the sense of using simpler tools) than macro blocks is to add a 'delay' value to switches. Thus button 1 can activate switch 2, which will wait 0 seconds, and be active however long you need it. Switch 3 upon input from 2 will wait X seconds, then activate for Y seconds. Switch 4 can be triggered by 3, etc etc. Alternately, every switch could actuate on a delay from keypress 1, if the range of values for the delay is large enough. This'd give you a way to build preset action sequences

Currently, I use a 'spine', and attach every part of my ship to the closest bit of spine to a center. (The brain is not always my center of mass.) I always try to place anything that exerts force so that it either pushes on this spine, or pushes on a flush stack of blocks connected to this spine. This can still result in some wiggly ships, but it seems to help keep more rigid than attaching everything sequentially in a chain. For example, I'll connect 1 to 0, (0 being the block at the center,) 2 to 0, 3 to zero, and as blocks get out of range, I'll connect 4 to 1, and 5 to 2, and always connect new blocks to the block closest to center. It would be nice, though, if flush parts would be treated as 'fused', if we won't be permitted to connect parts to multiple parts. (I see the danger -- every part might be connected to every other part, making any other configuration a 'wrong answer,' and having a dominant strategy isn't good for a game.)

• I would like to be able to combine certain utility sensors. I'd LOVE to be able to make an auto-digger using a gravity sensor to sweep lasers in an arc, but they're just too freaking big to hinge like that, and still pack in lots of lasers. • A logic switch (or an option on 'switch') that gives an output for X seconds output when an input is recieved. • Weapon control options. I REALLY REALLY want to lock towers to a direction. If you're making an autonomous drone it can be hell to find good weapons. The badass weapons are supposed to be better, so they always drop as towers. But autonomous drones can't use towers. It would be AMAZING if towers had options like, lock to a facing, continuously sweep a range of degrees at x speed, follow cursor, follow gravity, etc. For a digging drone, you could use this to get laser towers to effectively dig, by having them sweep (if 0 degrees is down) between -45 and 45 degrees. • Set small items like weapons and small sensors to circular for the sake of physics (or with the sensors, just make them circular) so that they can be rotated AND packed neatly without fucking over the physics. (It'd be great if items that SLIGHTLY overlapped just fused, and you just refused to let me overlap items more than by just a corner.) • Automatically connect things that are flush against each other, or at least give me some way to connect a part to multiple other parts. Or just give me some very large building blocks to use as a drone's 'spine'. Big ships have a lot (a lot) of wobble. • The ability to type values into text fields. • Rotation as one of those fields, so that you can adjust it precisely. • Is there a point to draining all fuel and energy tanks Sequentially? I don't understand why that's done or why it grants a benefit, at present. It'd be helpful if they drained all together, so each one was a representation of your resources. (Or! Resource bars on the drone brain.) • A 'camera' part, so that you can switch to viewing detached parts. • Do sparks collide with themselves? It seems that they might collide and prevent each other from progressing; their usefulness as a weapon is either a bit hampered, or a bit confusing. I'll probably have more, when I'm done breaking things later.

My problem with those impulse gates for laser sweeps is that they don't seem consistent. Over time an impulse gate and a not gate set to sweep a hinge back and forth will start edging a little more and a little more out of alignment until they're trying to collide with my own ship. I can't find a way to fix this without implementing a gravity sensor past the hinge, and those things are ugly and huge and limit the number of lasers I can fit.