Udonhef2bmad

Totally agree with you on most of these points. Deploy costs should vary on parts, encouraging use of logic parts and penalizing overuse of weapons and thrusters. It's a drone game after all. The scrapping after returning at end of mission idea is neat too. Balance-wise, i'd favor the removal of wifi ressources, fuel, and batteries altogether. My engineer campaign's economical issues got to an end the moment I stepped on a ressource planet and unleashed my automized miner underlings. Wifi fuel and energy also makes other classes abilities useless when compared to each other. It's just too op. I'm all for those quirky ways to get around these kind of issues, ie researcher doesn't need fuel, but only batteries, and each class should get some sort of ressource buff too. The tech tree should be available to everyone and in exchange, researcher gets 1-2 extra upgrade slots. I doubt alot of people took fighter. He should get block regen and +50% damage or something. Returning to the deposit is in my opinion a good gameplay mechanic. It adds more spice to the game. Also mentioning that alot of missions use it. I'm fine with the current ressource system. A dev also indicated some sort of way to get rid of stuff. I'm hoping for a trading system. That'd be nice.

Yesterday i made a special sumo drone : Yes. Another shooting sumo. I think it's cool af but its firerate is low, it misfires alot, and the projectiles barely manage to scrape anyhting off the ennemy at all. I'll post some "sucessful" shots beneath since max file size is 16mb and sumo arena eats a.way all the space.

Engineer is the best choice overall. The drone's size is highly minimised since it doesn't have to carry fuel, batteries or ressource tanks. Just slap them on a satellite or leave them in the nimbatus container. High hp is cool, but you don't need to be a juggernaugt if you don't get hit You can be just as fast as a pilot if you're not carrying extra ballast Miner isn't really worth anything at the moment : What if i don't want to break that cover? Miner should get extra ressources from mining Researcher is decent as you get to choose the weapon you need, but eventually you'll get more than enough weapons with the other captains Best thing yet, ressource planets are a walk in the park since you don't need to get to the container every run and you can send out small ressource drones to do the work for you. Also you get a 50% discount for all launches, allowing you to send drones twice as big as the other captains for the same price. Ps: I only played engineer so far, and honestly i'd have money problems if there weren't those ressource planets around. That and the deploy discount make me wonder: Do other classes struggle with money?

Yeah. Although instead of deleting i'd rather have a trading system that allows you to sell items for unobtainium and/or a "scrap" function returning small amounts of tritium back for each part. Actually, why not make a more developped trading system, where prizes change depending on the shop? That way, you'd have to travel from location to location for profit. That'd be another way of getting cash. Reminds me of a flash game that was based on this : https://armorgames.com/play/4480/frontier

I love those huge ships, to some extent. I actually messed up trying to make a gigantic snake and purposely built beyond the building grids to do so. Little did i know that it crashed the game and damaged my DirectX pilots. Had to reset my pc since i had no idea on how to repair them. I used to build some pretty quirky stuff myself, actually managed to win 2 keys doing so. This game is like my pride as a builder.

Alright, you got me, still i do want a directionnal sensor approach. You must really want that glass of water. These swam drones do look awesome and simple, and it looks like you made them too, am i wrong?

Well, if you're all about rules, then sorry to break it to you but one of them mentionned to use only one directional sensor. The english language is such a beautiful thing, you can change the meaning of a sentence without touching it. Thought you could just avoid using it? Think again.😜 Also these swarms look pretty neat, they're so small i can't even see what they're made of.

That's actually a pretty compact way to do it i didn't think about. You do get minus points for that extra fuel consumption (vectors are fuel hungry) and lower thrust that get in the way. And those are pretty major setbacks for a medium class compact drone. That being said, this does open ways for mini recon drones. A for effort, but i'm still not satisified.

Well i do know that a sensor duo works better for precision when it comes to tolerance as it narrows the tolerance zone down to basically a stripe. But i know for a fact that a single sensor provides enough info to maneuver the drone. I mean everyone could pinpoint a direction if they are told to either turn left or right. It all comes down to how you process it. I'm trying to avoid using a dual sensor to lighten the build and make it as compact as can be. That's some NASA level stuff right there. Also i don't want my drone to look like one giant floaty face. Take it that way: No tolerance, you only know when you're tilted left or right from the target. To point towards said target you'd have to spin right when the target's at your right and left when it's at your left. To stabilise you'd have to use less and less force on each of your correctionnal thrusts until the that force becomes null, facing the target. I believe the main issue when it comes to this method is how to process the 3rd step and by that i mean gradually lowering the thrust. I've been thinking since i can't access any values and don't wanna pick those wierd green boosters, to use time instead to notch down the thrust. Sill testing.

Well yeah these are hefty requirements. I was kinda hoping some vets had already cleared this issue but apparently not. Just clearing things up, I asked to try to keep the logic simple, implying to keep the logic as simple as possible, but since the task is that difficult, you might want to ignore that one. I did try to do that on my own, though. I gotta admit that having both a frictionless and bob-less stablisation build is hard. Would be much easier if there were ways to interact with variables higher than 0 and 1, like the directional sensor outputting a 0-360 value you could use to gradually activate thrusters with. That being said i do believe there is a way to do it with the current system.

I've been working on a simple drone in order to try out what the new galaxy has to offer. (previous beta builds poofed away) I want my drone to tilt towards the mouse since i like to pilot using left/right to strafe and leaving the directions the sensors. The Problem: The drone keeps bobbing left and right when adjusting its angle to the mouse. I'm looking for : - A fast progressive stabilisation, not a never ending bobbing ride. - Using only one directional sensor. I want my drone light. - 4 Thrusters only. Or at least as little as you can. The kind of thruster doesnt matter as long as it's controllable. - Logic parts on the other hand are not an issue as they'll be aboard an orbital satellite. Try to keep it simple though. - Directional sensor must be null. That means no tolerance. I want precision (I use it backwards, yes) - For perfection purposes, I want it to stabilise in a frictionless environment, too. That means no bobbing without air resistance, too. Pretty sure most of you experienced this issue so let's settle this problem once and for all with a contest. First to fullfill my request gets a glass of water (though i won't pay the transportation costs so you'll have to go get it yourself. Also you'll have to return the glass). That's pretty much it. Thanks for reading

I've used them a bit when i made swarm drones or deployable units, however it's was kind of a pain to activate them once deployed as they either had to detect their deployment or be kept activated. I'm suggesting to add at least one exception keybind, so that a command can pass through the splitter and complete whatever business needs to be done on the other side.