FeiXue

Two possibly controversial suggestions. Mostly because of non-trivial implementation requirements but maybe there are also some balancing issues I'm not aware of that stand in the way. With container avoidance maneuver and under normal gravity it takes drone more than 30 seconds to land and start mission completion procedures. Once landing logic and equipment is done we are left with watching those 30 seconds or more of 'cut scene' for every change we make. "Death by thousand cuts" wouldn't be such a bad description although I'm told original loses some of its richness in translation. As is usually the case. Idea is to allow one and only one 'checkpoint'. Position of core gets saved, that's all. So upon changing of drone build and selecting "Launch from checkpoint" instead of regular "Launch drone", core is placed at save location and rest is built around that. It is player's responsibility to make sure build hasn't changed in a way that would cause collision with terrain/objects. You just use same procedure that gets called when Factory prints. Would further restrict placement of checkpoint at no more than one minute after launch. Building autonomous machine that is capable of performing at least one task in fairly demanding environment quickly leads to quite sizable contraption. Factory, and often more than one, becomes almost if not completely mandatory since moving that large piece of machinery around is pretty inefficient. Indication of center of mass is a useful tool. However, there are two limitations that diminish its value. One is the fact that it doesn't take into account Factory's Printed/Not printed state. CoM will always show indicator as if drone was launched with all Factories at Printed. Second, and possibly even bigger problem, is Factory prints themselves. Those are the ones that do all the dirty work and balancing them out is lots more frustrating without CoM indicator. So this is two step thingy; one is for main CoM to take Factory/ies Printed state into account and second is having 'sub-CoM' indicator. One would select a part and upon pressing/clicking "Show CoM" center of mass for that object and all its child objects would be shown. This wouldn't be a toggle like main CoM is but would work only for as long as button/key is active. Incidentally, how that "Grid off" coming along?

I'll just continue this thread; imho keeps things easier to ignore 😁 This one is about something I call "Stuck on pebbles". It is fairly common problem plaguing games almost since Pong. Consider attached image. It's been mangled heavily but Steam creates jpegs so I had to start with fuzziness. Shows a Factory built detached probe designed to go around in constricting spiral (best 'blind hen' I've come up thus far) and hopefully stumble upon a resource pile. Look at objects outlined orange and lime. They are what one might call regular shape objects aka rectangular. In between is pink object, a thruster. Which is irregular. Its exhaust has no-collision property which is spot on. But since it is shorter in the y axis it creates a dent in the structure. Because it is impossible to keep probe really leveled due to low gravity and thrust force probe wiggles on its way. Yes, I did try several wheeled approaches, doesn't work. Those get stuck even faster. That dent, as you can see causes probe to get stuck. This time it was tiny bump in terrain, more often is few pixels one can barely notice that drills or lasers missed. Such minuscule bumps and stray pixels is what I call pebbles. Anybody with any experience in gaming has encountered situation where controlled object; usually more or less good representation of humanoid body, gets stuck on two inch part of environment while the controller is screaming, either out loud or within "Just bloody step over it!". In 3D virtual worlds there are all sorts of problems preventing good resolution. Luckily, here we only have two dimensions and one solution developed to alleviate some of the problems described above can be fairly easily implemented. In 3D environments, mostly action games, they are often referred to as invisible walls. Many have smashed their virtual heads against them, many have shook their smashed heads at their existence but they are the lesser of evils. In 2D, they provide solution to a problem and frankly, few will even notice their existence. Every irregular object has a rectangular invisible boundary so it fits nicely into the rest of the structure. This imho, should be even extended to regular objects since they all have rounded corners to be more aesthetically pleasing; which is good. But even that microscopic trough can and will get a pixel splinter stuck in. Of course, ideal solution would be to upgrade collision logic but I find that unnecessary complication.

for a girl to cultivate within herself invincible summer days. Bit of a long one, I'm afraid. Parts probably belong somewhere else but you'll live. This all concerns fully auto mode as that's the only part of the game I'm interested in. How does one find resources in fully autonomous mode? Short of some sort of 'blind hen' logic the size of quarter of a planet. What's the reason for enormous container floating just out of reach of ground contraptions and smack bellow mothership? We need to include logic for landing procedure to avoid it, anything that wants to deposit needs thrusters anyway plus entrance is from above. Not to mention avoiding its thrusters. So another fairly elaborate logic to 'park' and then get out unscathed. Would it be really so bad if a) it was 10x smaller and on the ground or b) reasonable proximity to mothership would empty resource container? Ability to name parts. All the code is already there; used in add/change tag. Just needs a click event on default part name in its properties window. Somewhere somebody mentioned advanced programming of drone(s). Words like Python and LUA were heard. How exactly do you envision doing that w/o parts having unique IDs? I mean, they already have unique IDs, they have to. A label would be next logical step, no? Speaking of properties window, so much space, so little content 😋 Orange buttons could be half the size, that makes room for 3rd button that would display green part when needed and applicable and make room for many things that one wished were there but are not. For instance, Inverse checkbox for logic gates. NOT gate is just inverted IF gate, AND gate with both inputs inverted makes a NAND gate, etc. Any reason impulses, buffers and delays are limited to 10 seconds? Surely it's not for fear of slider becoming to sensitive as there exists long impulse giver. I'm an amateur at logic circuits on the best of my days but isn't a counter a basic block of said devices? Sure, we can build one, one switch and one gate for every number. So one would think is a simple splitter; one output, two outputs. Preferably more outputs. Implementing 4. and adding blue portion I'd say 6 would easily fit. Debug. I mean do I even need to explain this? For starters simple log file would go a long way. Granted 3. needs to be implemented first or it makes no sense. Going on a limb, clock is 60 Hz, hopefully not tied to framerate. Add simple onStateChange event, err it's already there just needs another listener, and we're looking at 100ish short lines per second? Which is peanuts. Roasted but not salted. Before going full on programming interface maybe a part that works akin to Factory in that it takes say 4 inputs, can accommodate dozen or so logic parts and has 2 outputs. In editor one would simply tie all logic to it and define inputs/outputs but when drone is launched all that is 'hidden' and only chip is visible. Disabled it in competitive as I believe Factory is if you wish. There could also be a limit on how many one core can handle, or maybe soft cap based on energy. There's a whole section almost like this on mechanical side but maybe next time.