Lurkily

I'm already planning a system of cursor and directional sensor to auto-switch between camera blocks. More when I get home and try things out.

So one of these is like the impulse gate, but with a start-delay to engage more coordinated impulse control? I like this. If I understand buffer gates, they give an output while an input is received, but they don't start counting down to stop their output until that input stops, and that's what makes them special, yes? That you can start that countdown by releasing an input? There is a suggestion up (Mine, I admit) to add an optional input to impulse (or a new logic block entirely) that if set, would execute the delay and then the keypress, then stop without cycling, to enable complex sequences. This sounds like it would enable what you need. If your trigger is X, and you had a logic part output Y if it did not detect X, then an input of Y could start that one impulse cycle that output Z for a proscribed time. I can already imagine uses of a buffer gate that this could not handle, though, and I can imagine ways to handle most uses of that method with chains of buffer gates, so.....I had to ramble a little bit to think it through, but I think I agree with you.

I like it, but we're getting into more complex logic, which development seems to have steered clear of so far, though there was room to experiment with them in the pre-alpha demo. We're getting into things like named variables, while development wants to keep things very simple, on an input>logic>output basis. I think that without some feedback from parts like hinges, speedometers, adjustable thrusters, directional sensors, etc, and the ability to perform less than/greater than logic, we're going to have constraints upon the complexity of our drones.

I was thinking of a drone with chain of autonomous parts that just keep station above you in a magnetized, self-powered group, and being able to de-couple your weapon (at which point it'd be disconnected from an input and would magnetize to the satellite drone) and re-couple a different weapon. Your own personal tool rack, following you around in orbit.

At first, you collected weapons of greater rarity, and rarer weapons had more upgrade slots, 3 being the max, if I recall. Point being, if 3, 4, 5 breaks balance, you can always do the same with 2, 3, 4, or even 1, 2, 3.

Once again, I'm reminded of the 'truth table' input/output module.

There's a thought. Equip miners on a ship like a weapon or a module, and have them beeline for resources and, with some inefficiency involved, burrow through any terrain that gets in their way.

So I was thinking about a ship I made a while ago with vectored thrust, and why it was so difficult to make it behave intelligently. I needed it to be able to orient straight down, or straight back at need, and the only way to do that was to inch it backward, then rotate downward at full speed whenever I detected dirt too close. It would be nice if I could have logic output hinge controls IF low altitude AND being off-target were both true. AND it would be nice if I could level them off at altitude, too. But my ship had three thrusters, a detector, and a directional sensor on each hinge, and they already wanted to shake to pieces. So a solution came to me. Let's have a three-part directional sensor, and a four-part, and an eight-part. Three-part would enable specific behavior for a ship that's flipped fully upside-down. (Which will sometimes have thrusters that WOULD keep you upright jam you into the ground, instead.) Four-part would enable more complex navigational or scanning responses on parts that would, otherwise require lots of sensors. I once had to make a ship with four directional sensors, to provide eight navigational responses. Putting something like that on a HINGE is just a mess, and right now directional sensors are the only way to determine a hinge's facing.

No worries. Game design and function are things I have a bit of a fascination with. I like the tracker-style system. I haven't been around for a bit so I'm not sure how new it is, but it works for the whole alpha thing, it works very well.

Not sure what you mean by an event, in this context. But, in short, a hinge will be capable of 360 outputs - HingeX 0 throught HingeX 360. HingeX would be a name assigned by the player (Probably with a default of hinge1, hinge2, though they needn't be unique) and one or more of those outputs would always be active based on the hinge's position. This wouldn't be something the player had to configure as an output - more like an inherent property of the hinge. (Though you could require the player to activate it, if too many parts like this cause problems.) It would enable things like rotating a hinge until it meets a certain angle, without making it necessary to absolutely forbid the hinge from turning beyond that angle.

I very much like your plans, sir; requiring small ships is going to make things interesting. Putting it in a metal ship that you can't just torch clear will also be interesting. I've made a number of autonomous drones that can navigate planet cores and upside-down, and the challenge of this interests me. A few challenges: Tunnel cruisers - navigate a windy tunnel at the highest speed possible - the more you come in under par, the bigger your bonus. Very windy tunnels with a short-distance run, or gentle curves for a long, high-speed run. Treasure hunt - a small maze, complete with locked doors, keys, switches, and etc. This will require more logical detection, such as wide-angle detectors and directional sensors capable of locating keys or switches. No enemies and wider corridors, since tight navigation and combat aren't the point. Mining challenge. Small planet, weak enemies dropping in from orbit. Strip-mine every ounce of ore, and if you destroy any, you lose. Boss fight - Present a boss with a unique challenge (slow turning but with an armored front, or can only be killed by pushing it into a hazard, etc.) that you have to custom-build for. I'm sure I'll have more later.

Sure it is. The effects of particle gravity, particle bounce, and particle lifetime, plus 'do not damage ore', should be very much like this. I haven't experimented with the bounce/sticky part of the research tree yet, but based on its behavior in the upgrade preview thingy, I think that'll do fine.

If there's another feature request containing mine - for any of my posts - don't hesitate to let me know. I can comment on that instead and take mine down, so it doesn't split up attention in a way that might undermine the suggestion.

Not to the physics engine, surely. All I'm talking about are named inputs/outputs. We have these already. If you gave the player the ability to name the hinge, and gave an output that was the hinge's name plus angle, you'd be close to what I'm suggesting. This way, you could have logic that activates with an input of Hinge5 320, activating when the hinge is at a 320 degree angle. (Forty degrees off vertical.) The 'tolerance' is also an important part of making this a useful change, though. This suggestion is all logic; unless that's embedded in the physics system somehow, they shouldn't interfere with each other.

Omega, take a look at this one. This part can fully replace a number of logic gates, as well as compress the function of multiple and complex conditions into a relatively simple table.

So much depends on a hinge's orientation. They're usually controlling really important things - only important things care about facing. Weapons, thrusters, detectors. I would LOVE for a hinge to output it's user-configured name and its angle as an output. (Gun5 hinge 270.) Include a tolerance so that if my tolerance is five, it outputs Gun5 hinge 265 through Gun5 hinge 275. Hinges, detectors to output exact distance, engines for their specific thrust settings, a lot of blocks with adjustable settings can use this, and it will enable some "If greater then/if less than" logic.

It would be nice to see lines between unfinished planets and unrevealed planets, showing what would open access to what. It would be nice if some transmitters opened access to only a single planet in a random location, possibly (preferably) very far away. It would be nice to see your travel on the galaxy map, as you bounce between unlocked planets to path to your destination. (It's cosmetic, and it can be quick, but it'd be cool) I'd really like to see some ability (recovered artifacts?) to occasionally just negate a planet whose conditions you don't like. (That one weapon thing, ugh.) Just nuke the transmittter from orbit. I'd like to see some sort of enemy presence - perhaps taking back planets you have unlocked now and then, and moving between unconquered planets, leaving windows where they're more difficult (and rewarding) or easier (and less rewarding). EDIT: having bases you can take out to eliminate the respawn of defeated enemy groups in a region of the map would be cool, too.

I would appreciate a thruster that had its own internal hinge inputs.

I'm beginning to think we should start combining more and more of the logic gates into a 'computer' part, or parts.

My plan was to strap on a terrain detector, and push the altitude up several notches when it detects terrain too far inside weapon range, or terrain in FRONT of it, and just have it circle, then magnet in the full ones for retrieval, with a 'sense drone' sensor on top to shut off control while I empty them.

This might be more feasible if its connections functions as normal right now, but its connections much more rigid, ESPECIALLY to other connector blocks. Then you could use these blocks as a spine or a frame, and connect everything to them to make them more rigid. No telling what it'd do to physics, though.

Relatively few of them, mind; not everybody will like this. But autonomous challenges would be nice. Perhaps a specific arena that randomly generates missions of a particular type for autonomous runs, with hunt/kill, collection, mining, etc challenges available.

Honestly, I'd like to see everything treated as a weapon, with equip-able upgrades and the ability to make custom parts. But I have a sneaky suspicion that weapon parts are not like other parts, and that this wouldn't work.

My solution to building very large, stable drones, is the idea of building a frame or a chassis. The chassis would be constructed on a second layer that doesn't collide with, but can be connected to, the layer we use now. Chassis blocks would be large and unwieldy, requiring good design to use well, but you should be able to connect to any part of a chassis block. (Rather than only X distance from the center, a long block can be used to anchor a long ship.) These chassis blocks would be a structural weak point as anything damaging them would also deal somewhat reduced damage to every block connected to that chassis piece, based on proximity to the hit. (So if you built your drone around a single chassis piece, a hit to the chassis could damage every part of your ship at once.) If a chassis part is destroyed, every part attached to it should be destroyed. The advantage in them would be that any adjacent chassis parts would be treated as a single block for the purposes of physics. The core should be a chassis part. The result would be that players would have a set of tools that aren't mandatory (except the core, as it is now,) that could provide a very rigid frame for a large drone. Parts can be anchored to this rigid frame for solid construction, but the frame blocks are large, and the player will be constrained in design to build around the blocks. In addition, he'll have to protect them, because damage to them is a serious problem for the entire ship. In addition, if a chassis block is broken, it could separate chassis parts, breaking a ship's back, and it's rigidity; the chassis itself could become a liability. I realize that this is a somewhat ambitious suggestion, but I think it's a solid solution to permitting rigid ships that doesn't rely on multi-connections. If the hierarchical structure of connections is definitely needed to keep physics straight, then this may be a solution.

This goes back to my idea of being able to 'pair' blocks that would sense each other's direction and/or distance. This is a better idea, but I would want to be able to use more than one; we should be able to name them, and use that name as a variable to determine what the directional sensor seeks.