Lurkily

I'm not sure there's a difference between merchants, except some sell common, some sell rare. For piloted drones, shotguns. Towers and guided are too easy and cheaty, so I tend to eschew them. With shotguns, I like to look for cluster bullets, and extra bullets. For autonomous drones, I like straight guns with extra shots, cluster bullets. They can get over landscape and provide the best offense against the exploders, pouring damage on even terrain-protected hives before getting close. They're also highly effective at chewing up terrain without needing digging upgrades. Lasers are great diggers, Heat seeking is a plus on anything autonomous, but it's a rare upgrade. Flamers are good diggers for autonomy, too, they're not as scattery as sparkers, and not as needle-thin as lasers, more likely to carve a swath than poke a hole. Towers are useless on anything autonomous, so it can be a real bitch to equip an autonomous drone.

Asynch coop challenges would be awesome. I'm imagining a 2-on-3 battle arena, where you have to fight three identical foes, with a partner randomly pulled from a pool of other people's battle drones, having to modify your own drone to work effectively with your partner. Netplay can be touch. Generally accepted wisdom is that adding real-time multiplayer generally triples development time.

Good deal on fixing Impulse. Lacking finer control, this should make impulse workable for sequencing. It's not something you can start any old time without risking closing a closed hatch, for example, but it's a beginning. A couple of ideas I've had might be workable, with impulse being perfectly accurate. The pre-alpha, being a Kickstarter demo to say "We can do this!" isn't something I necessarily expected to see active updates on - I'm glad you didn't put off making any updates until the Steam Alpha opened.

That web is cool stuff. I'm gonna have to experiment

WOOT! Congratulations, guys!

So . . . . . I've made a couple of walkers. I've tried a few things, but my best efforts always involve thrusters for feet. I made a roller that is capable of rolling uphill, even across a ceiling. I made a rover that could, clumsily and without reliability, crawl down into a narrow hole and back out again. I'm currently working on a jumper. It uses one directional sensor to thrust down and forward, and slam down onto springs. Those springs are angles to tip it forward, and jump thrusters pound it back into the air, using a second directional sensor to launch it up and forward (tipped right). It's not going terribly well, but I'm making progress, and I'll complete it. I have identified a number of things that are really limiting my ability to make drones that are really interesting and distinct and unusual. In my quest to make walkers, rollers, rovers, landspeeders, climbers of all types, these are the issues that keep cropping up again and again. I wish directional sensors could be tuned to 'closest terrain'. I could make legs, wheels, and thrust that adjust themselves to climb weird terrain. Want to climb a wall? This could rotate a leg assembly to actually point at a wall, or lift and lower a wheel to match raised or lowered terrain On a side note, make directional sensors round or octagonal, so we can precisely aim them without having to put them on a stalk. I wish directional sensors had a 'angle' setting and at least double the range. (Decrease the max range as you increase the radius, for balance. They might even be effective enough at being consistently triggered that the above tweak to directional sensors wouldn't be needed. It'd still be helpful as hell, though. Also, I'd kiss you if you could make them smaller. I know they get harder to read, but this is just an absolute necessity if you're going to put it on a hinge to control moving parts. I wish I could 'pair' directional sensors and a 'range' sensor, so they'd read the direction and distance between the two blocks. Then I could make formations, like unconnected 'snake' drones and orbital sub-drones that spread out and seek enemies to fire at, then zip back to their station if they're too far away. I wish I could start an impulse gate, for just one cycle, on a keypress. Flip a switch on a delay after an event occurs. I need this for complex legs. I need this for simple jumper logic. I need this for transforming drones. I need this for so many things it's not even funny. I wish hinges had angle restrictions. I can get around speed controls with impulses ( .1 delay, .9 speed for 90% - .9/.1 for 10%, .1/.1 for 50%.) It isn't ideal, and it introduces destructive wobble sometimes, but it can be done. Effectively controlling autonomous events though requires sensors, and sensors sometimes don't get triggered - uneven terrain, whipping around because of some wobble, whatever. There's no way around requiring angle limitations on hinges. Someone will say directional sensors - but they are so big, and heavy enough, that they're implausible on most hinges, and only work when the entire ship is upright.

A walker! It works! Sort of. It walks up walls, too! (You may have noticed, all my autonomous drones must be able navigate upside-down.) The gif makes it look like it falls over - in reality, the directional sensor detected the blocked, and tipped it over to walk up the wall. shortly after, it made it up this blockage and over to the other side. Shortly after that, though, one of the logic sensors got blown off. The legs operate on an impulse at a delay of .1 and a duration of .1 - running at half speed, it's stable, but it tends to slip a lot at full steam. Other leg configurations are more stable, but I have trouble getting them to climb. The trick to climbing, it seems, is the sensor configuration. You need it to sense behind it easily - a long beam - so that when it climbs over a cliff it rights itself, instead of dragging on the ground behind rocket feet until it explodes. It had to sense in front of its feet, to keep from falling forward from the oversensitive rear sensor. Then it needs a front sensor for the big hills, and extra thrusters tied to that sensor. Tipping back will trigger the back sensor, and to climb, it has to overcome that.

No armament, but he's nimble. He's even got flames shooting out of his engine! Turns are especially fast, with the pods further out from the center of mass. He has more fuel than he needs, though, and more energy, too. (With low consumption, those flamers draw 17 power total.) The logic controls the thrusters, which are in four groups. Two groups per keypress. Thus all forward thrusters are used to accelerate forward, but you still retain a little manuevering capacity. (You'll turn a lot faster if you stop forward thrust, though.) Here's a test-run where I practice dodging some homing bullets.

Same, chrome works here. Something unusual about your local network? Tight security, maybe?

Connecting to the nearest piece creates a bundle of strings that flops all over the place. I usually try to connect as close to the brain as I can, if I can't connect directly to the brain. Then when I can't, I try to bracket high-mass structures connected close to center with the new connections, so that the sway from long connections dampens out - they're always pressed against something that resists wobble and sway, and anything between them is kind of 'contained'. They still look like a bag of legos, but they hold together, mostly.

Yes, yes, very yes. Some more challenges would be INSANE. Imagine a planet with 5 or 6 different challenges. Even larger than current planets. Maybe a heavily defended "Fort" or "Satellite / Station" in orbit that you have to destroy. I was thinking more of like the sumo and battle arenas - have some specialized arenas or missions that require autonomy, that require smarter behavior and guidance.

You could build that now with a motorized hinge. I have used that with some weapon targeting. I use it sometimes with autonomous drones that like even terrain, to 'detect' and target the tallest terrain in front of it.

I had issues with the gif, so here. A rover that'll climb walls, even the ceiling. She's not quick or nimble, but she works. Jagged terrain can catch behind the wheels, though.

The devs have mentioned that they are considering solutions to rigidity. I favor the idea of a 'chassis' layer that is fully rigid but introduces some challenges and weaknesses of its own to protect. Others favor adding a 'strut' part. (I think that might be better handled by just permitting an extra connection or two per part, rather than adding new parts - we already have struts, after all.) One thing you can do right now is to interleave connections. Instead of connecting in a straight line back to the brain, zigzag connections. Thus the panels at the top are resisted by the panels on the top when they try to split. I am attaching a drone that is nothing more than a collection of parts. Drag the solar panels closest to the brain around to see how I connected them. That pattern may or may not be fully optimal, but it will resist pulling into separate parts as you maneuver. UPDATE: I added engines and fuel so that you can manuever it off the bat (A and D, rotation only) to see how it holds together. Example.nimbatusdrone

This worked out better than expected. A rolling ball of heat-seeking shotgun death. The shotguns are focused inwards because I had concerns about enemies getting caught inside it, and because it gave me a slightly better spread as they left the ship. They aren't aimed, this bot is fully autonomous, so I wanted a good spread to let the homing property to its best.

Not sure it makes sense to discriminate between types of buildings. What would you do at a planet core, that would be prohibited by simply detecting it as an enemy structure? Either one can be safely destroyed.

Why not fold it into the directional sensor? The wider the radius, the shorter the maximum range. You can permit the player longer one-dimensional detection (which we also need) but then 360 degree but very short-range detection. It's a lot more flexible than two detectors with static values, too, without dropping the requirement for the player to find a balance between the two factors.

I've said some of this before. Here's a codified list of what I think is necessary. Hinges need the 'dynamic thruster' treatment. Increase speed, decrease speed, activate. Speed can be negative, to reverse direction. They also need a limit for movement range, so that missile hatches don't tear themselves off your ship just by opening too far. For rovers, some sort of terrain grabber so that thrust against the ground isn't the only way to gain traction. Curiousity doesn't need rocket engines. A 'timer' or 'clock' logic is needed. As things stand, I cannot find a straightforward way to make a sequence of events, which must occur in order or with a specific delay, (open a hatch THEN fire TNT missiles) in an autonomous drone. I have about six ideas for rolling (not wheeled) drones and leapfrog drones and flip drones and walker drones that are all ridiculously complicated to make autonomous without being able to program sequential actions. An altimeter would be really really nice. [Directional sensors need a "Width" setting. Increasing the width of the beam should reduce maximum range, so that a full 360 degree sensor is possible, but has a ridiculously small coverage. (Inverse square law.) A 1-dimensional line should have a ridiculously long maximum range. This will make it a lot easier to find a balance between coverage, and needing forests of sensors. sensor blocks that can be 'paired', and provide the direction/range to its paired block. Formation flight baby! I want a drone interceptors flying interdiction for a bomber wing! Fuel and energy and logic all need to be severed when connections are severed. Logic has a wireless block, and you might have wireless energy (with limits), but every drone should require separate fuel reserves. Not only does this make construction more interesting and demanding, it eliminates 'cheaty' drones (energy/fuel satellites that stay with Nimbatus, or detached combat drones that are not attacked) Detached parts need to be attacked by the enemy. Since pieces are never destroyed, have enemies attack anything that has both energy production and consumption, or both fuel production and fuel consumption, with a preference for producing/consuming blocks. This will make any group of parts that has any remaining function a target, but allow enemies to ignore defunct and broken drones, and prevent them from pounding on armor as a decoy all day just because you put a tiny solar cell and a motorized hinge on it - they'll focus on functional components instead of targeting armor. Yet, if you armor it right, you can still make effective decoys. More autonomous challenges. I would like to see maneuvering challenges. Hide-and-seek challenges. Mining challenges. Require the creation of a drone that can explore and find ore deposits from all corners of a complex tunnel system. (A maze runner.) Have a 'runner' drone, and require you to keep pace with erratic maneuvering, and stay in range. We absolutely need some kind of solution to provide ship rigidity. Reconstruction. I love TNT missiles, but they're almost useless without the ability to rebuild them. My suggestion for terrain grabbers: I want harpoon guns with spring connections and a fire/release terrain control, reel in control, and a reel out control. Because it's awesome, that's why. My suggestion for timer/clock/sequence logic: My suggestion is a block similar to 'impulse' that only triggers once. Input, delay time, activation time, and output. On receiving the input, it waits the delay time, outputs for the activation time. Once activated, it cannot be reactivated until the delay and activation is complete. My suggestiong for rebuilding: My previous suggestion was a 'nanite factory' that produced X nanites per turn. Have it split the nanites it makes between all connected parts that have damage to themselves or any child part, or a destroyed child part. Have THOSE parts divide nanites between every connected part with a damaged/destroyed child part. Thus you can rebuild parts, but taking damage slows down all reconstruction, and widespread damage isn't easy to recover from, requiring you to divide the production of nanites between many parts. Drone construction becomes important here, because part connections can dictate which parts have greater or lesser repair priority. Only detached ship parts that aren't connected to any other part should be considered 'destroyed' (with the exception of TNT) to prevent rebuilding things that are still functional and operating. Every part of a drone on the opposite side of a 'detachment' block should be destroyed, to avoid These 'destroyed' parts should eventually vanish from the map somehow, harmlessly self-destruct, to prevent a build-up of trash on the map.

Well, yeah, I get that, but they're also polar while these are apparently monopoles, so . . . sacrifice it on the altar of gameplay. Terrain grabbers would be great though. That bouncy thing in the gif I got via email would become more plausible. Maybe a weapon type that could fire a harpoon connected by a spring? It would need controls for firing, reeling in, and reeling out. Thus you could tether an enemy, trap it, and either reel it in, keep it at bay, or drag it into the line of weapon fire.

A nimbatus file with japanese characters in the filename? I don't think that's a nimbatus file . . . I think something is corrupted.

First, they're huge. Using them in any dynamic way isn't easy. Second, they can't grip terrain. I wanted to make a giant wheelbot, with an array of magnets that repelled on one side and attracted on the other, and rolled across the land sowing death and crushing destruction. I also wanted a surface patroller that lifted itself over the surface by repelling it, which would patrol the surface, following its contours. Please permit us to set magnets to terrain, enemies (to include projectiles), and 'all'.

Motorized hinge definitely needs more control. It needs the 'dynamic thruster' treatment, as well as angle limitations for its range of motion. We also need non-colliding pylons to mount them on so they can be stable.

XOR and NAND are weird. You can't really specify which should be true and which should be false - you'd lose the usefulness they're supposed to have. Because they don't care which input is triggered, they can do things that would otherwise take several simpler gates to replicate - such as changing the way thrusters fire if the ship detects walls closing in left and right, but not if there's only a wall to one side, or no walls detected. For the rest, you're right. The OR gate and the NOT gate could have their functions folded into other, more capable and simpler logic blocks.

That's my concern, as well, non-programmers being able to handle unusual gates. My thoughts on the matter is to make the gates themselves more capable. If you include an option for any gate criteria to be NOT, that combines the IF and NOT gates, makes the AND gate also a NOR gate and the gate you require, and makes a lot of drone programming a lot easier to handle for those unused to coding.

For if A and not B, (!B is 'not B,' right?) I usually have a NOT gate output C, if B is not pressed, and an AND gate for A and C. It took me a minute to organize that in my head, but once I did, it became easy. (It does require extra keypresses though, which sucks for complex craft.) So, in logical terms, IF !B { Output C } IF A && C { Output S (In this case, if using default controls) }