One way that is automated would be using event controllers: turn off down thrusters, put on max override the up thrusters and turn them off also. Then set up the event controller: if speed is over 95 m/s turn off up thrusters, if speed is under 95 m/s turn them on This should mimic your manual pulse method You can set up a control bar with the turn on/off the up and down thrusters and the override of the down thrusters + turn on that event controller Or you can make it mimic the thruster override method: if speed is over 95 m/s decrease the override of the up thrusters, if speed is under 95 m/s increase the override of the up thrusters
I would modify a tiny bit by having the switch made at over 98 and under 96. That leaves a small wiggle room so that it does not create to much lag by switching way to fast.
My first trip to space was done with a shuttle that I designed specifically for the transition between planet-side and space. It has two large atmo thrusters pointing down, it’s set up for full atmospheric control (small thrusters in every other direction) and with a load of cargo, launching with the atmospheric is a bit slow, but once I begin to decelerate, I rotate upward 90° and fire the hydrogen thrusters. There are 3 large hydrogen thrusters on the back and they have no trouble putting me in space. Of course I have 4 large hydrogen tanks too, so I may be using more fuel than I realize. Figured why not carry a lot.
Thanks! For some reason TH-cam decided to remove my last reply. Probably because I mentioned something about the way this video ended. (Not sure how picky it is, so I'll leave it at that.) Thanks for watching. :)
Remotecontrol works fine as long as you set it up correctly. You do know that remote controls have their own internal speed limit right. So you could have set that to 99 m/s. As for direction. Orient it pointing forwards towards the cockpit(standard way). But choose UP direction and make sure both precision and avoid obstacles is off.
I did talk about the speed option in the video (maybe it was for the AI blocks, but it seems to have the same effect with remotes). It still uses a lot of fuel because it's always thrusting to try to maintain whatever speed you set it to. It thrusts, overshoots the desired speed, thrusts backward, etc. I tried a lot of different orientations and settings, but perhaps I'm still doing it wrong, I'll experiment with it more.
I didn't think of that while making the video, but a few people have mentioned methods using Event Controllers now. They sound like they work well, perhaps I'll make a follow-up video if I get enough new ideas.
@@ShiftyshadowTV, another variant would be having the thrust override method controlled by the Event Controller. Also, you can create a timer block that bumps your thrust override way up/down by putting the applicable thrusters into multiple groups, and using each of those groups to trigger the increase/decrease in all 9 slots of all 9 action bars in the timer. That makes it much faster to crank up your thrust override quickly.
Exemplary style. Clear, concise, relaxed and non-over-the-top voice-over, planned, smart use of time with background info while the flights are in progress, with an overview at the beginning, and luxury features like jump marks. A treat to watch, thanks!
one method that I didn't see was computer aided pulse thrusting, it works as follows put all up thrusters into a group, and all down thrusters into a group disable upwards and downwards thrusters, set upwards thrusters thrust override to 100%, and add an event controller make the event controller activate whenever speed is below 95 m/s, and have it turn on the upwards thrusters when below the threshold, and turn them off again when above the threshold. this method has all the advantages of pulse thrust and automated flight, but without the pesky features of AI thruster spam.
Yup, I've gotten a good stack of comments recommending event controller methods of one sort or another. It's definitely something I'm going to try out.
Thruster override (easy mode) - Turn upward thrusters, damps, and gyros off. Max out the upward thruster override. For launch, turn on thrusters while disconnecting. The thrusters are immediately at 100%. Adjust the override keeping between XX-99 km/s. XX is your preferred minimum speed, the lower the minimum speed, the longer the trip takes and the more fuel you spend. No reason to be afraid of going below 90 km/s because the whole point of doing an override is for easy mode. When you reach orbit, you will turn off the override and turn on gyros and damps. Much safer and only as inefficient as you care to be by picking your minimum speed. If efficiency is king, do it 100% manually. You will spend a lot more than 7 minutes configuring AI and Control blocks for very little fuel savings. Try to remove the remote control wobble by turning off the gyros. Maybe even setting a zero override on all other thrusters to prevent them from being misused by the remote control block. I think I have seen the last script on a few lets play and I don't think you scratched the surface of what it does. Looking forward to another small grid ep.
I'd suggest setting the gyro(s) to override (with the settings left at the default zeroed positions) rather than turning them off as this will actively work to keep your ship level and, should any other forces try to turn or flip your ship, it will act to prevent/reduce that with up to its maximum rotational power. Add a toggle on your hot bar to enable and disable the override for your gyro or gyros group so that if you need to quickly alter where you are heading (for instance if an asteroid pops up in your direction of travel) you aren't having to go into the control panel to disable the override.
I'll have to give some of those tips a try, for the remote control. Yeah, both scripts can do a lot more, I was just testing basic fuel efficiency. Setting up AI is only worth it if you have a base you often take off from. (Or you want to run drones.) Whenever available I think the scripts are probably best. You can set them up once and then they work anywhere. Looking forward to starting SGO up again.
@@PoolOfTrees I used the override to make an automatic surface to space ferry a while back. Not sure why I didn't think of it here. Might have helped with the Remote Control and AI blocks. Though, they seem to need control of at least one to function at all some times.
I find the pulsing to be the easiest way. However, I leave my inertial dampeners on and just switch off my Down thrusters. I usually have the down and backwards thrusters as separate groups on my toolbars for cruising or escaping gravity.
Good idea, I usually have the backwards thrusters on my hotbar as well, haven't ever done the down ones though. Would probably be less dangerous than messing with inertial dampeners all the time.
You can use the same method, for example, when approaching another asteroid. If you're 10 kilometers away and aiming to approach but only relying on visual judgment, there's a risk of nearly crashing into objects. By manually turning off your 'braking' thrusters (using the hotbar), you can keep the dampeners active and make slight adjustments to your course. This way, the dampeners work for you, eliminating the need to constantly press 'A' and 'D' to align the crosshair. This technique is equally effective when flying around an asteroid or navigating on a planet. It stands out as one of the most fuel-efficient and straightforward methods. I learned this tip from someone with over 6000 hours in Space Engineers. It's undoubtedly one of the best pieces of advice I've encountered.
Sad to see that the remote control is that buggy with such a simple task. Even the newer Artificial "Intelligence" blocks are so innefficent at their task.
I was impressed by those scripts. I certainly didn't expect them to be that efficient. Inversely, I hadn't expected the Remote Control or AI blocks to be so inefficient (and so much worse than just keeping you thumb or a weight pressing on the spacebar). If Keen could tweak the AI behaviour to reduce and increase thrust in the desired direction, rather than apply reverse thrust, to keep it around the desired speed limit (and obviously fix the 'wobbling around' issue) then that should make quite a bit of difference to fuel usage.
@@yle5788 I think that the remote and AI requires thrusters to exist and be enabled in every direction, but I've not tried testing without for a long time.
Man ended the video in style. Seriously, though, that was really informative. I've never actually used the Remote or AI Blocks to go to space from a planet and was quite surprised that they use such a ludicrous amount of fuel. It's almost 5x the minimum amount.
Basically with all others minor horizontal adjustments either weren't made or were made with small input values while AI blocks can only give on/off directions to make their adjustments (similar to a player actively flying a precise route) and this is the cause for much of their fuel burn. The 100 speed limit opposed to 99 probably didnt do many favors either though
8:44 Remove pilot error. You can stop thrusting when at 35+ km when already at max speed, since it takes a whole lotta time to decel to zero, in which you travel the rest of the way. Also, low-G saving, add a few small ion engines for the low-G part. They cost little in weight but can make a difference by keeping the speed up better. (Also, in space-engineer space ions rule, since they cost no resources to operate, for regular travel, besides (solar) power.)
just setup 2 event controllers 1 for escaping gravity, which turns off upward thrust at 95m/s 1 for controlled max speed, which turns off forward thrust at 95m/s both will greatly save fuel, while still allowing you to just hold space / forward
Good idea. I'm going to experiment with the Event Controllers and sort out a method that only takes me one button press. So I can walk away while I'm traveling.
The one problem I have with the thrust override method is for whatever reason Keen thought that a thruster being manually fired should have a higher TWR than one on max thrust override. Thus you could get a design that can make it to space under manual control, but will crash and burn if you activate thrust override method. Hate to mention, but one of the prebuilt buyable ships from the eco DLC does suffer from this issue terribly. With that said, I still love me some thrust override to space 😁
If have multiple thrusters, you can exponentially group them (group of 1,2,4,8, etc) and then thruster override the groups for very fine control. You can dial in exactly for perfect fuel efficiency and zero manual "wobble" in your thruster override inputs (becomes a gradual decrease as you climb)
im the someone in the comments you are doing thrust override incorrectly you only apply as much thrust as it takes to defeat gravity, never more just enough to increase in velocity. you will increase in velo slowly and then quickly (because gravity will become weaker over time) once you hit max speed, decrease one tick and let yourself reach equilibrium. once you hit eq you will again start to increase in velocity. only decrease once you hit max speed again repeat you can get to space from earth using around 1% - 3% of fuel (dependent on ship mass and size of tank used) and it takes ~the same amount of time as your other methods.
Well, I ran my own test on your world. My usual method was a lot worse than I thought it was, so I tuned it until I got a respectable time. Using my new method, I was able to get ship 2 into space in 7:20.67, and used 57499L of fuel. Your fastest time was 7:25 with constant thrust, and your most efficient fuel usage was manual pulse @ 55776L. I was faster than your fastest time and used just slightly more fuel than your most efficient method. Timing was as follows, which is slightly different than what I normally do. -Turn down thrust off, leave everything else on (turning off damps is noob mode, only bads turn off damps, discipline yourself and learn how to control your ship in every axis properly) -Set up thrust to 448Kn (max) and ascend until you achieve max velocity. -At an elevation of 9000m, decrease thrust to 288Kn, and then at the following elevations, decrease thrust again to the noted amount of Kn. Each of these settings will be just enough to defeat gravity, so you should remain at max velocity while spending as little fuel as possible. (I noted elevation, not gravity, I would have like to have noted gravity but just didn't.) 11Km = 216Kn 12.8Km = 192Kn 16Km = 144Kn 18Km = 120Kn 20.5Km = 96Kn 23.8Km = 72Kn 28Km = 48Kn 37Km = 24Kn (the lowest setting) This was somehow faster than max thrust and used a lot less fuel. I wish the event controller were placed facing backwards so that the elevation and the blue dot on the EC could be seen at the same time, but oh well.
For thruster override, I just hold space bar until I reach max speed, then engage the override. Doing it before you take off or as you take off is kind of goofy.
you can install some atmospheric or smaller hydrogen thrusters to allow you to hover first, which then allows you to ramp up thrust override on a bigger more efficient thruster if you want to do it manaully
Now I would have loved to see a variation of the second test, where, instead of staying at top speed, you only go to top speed, then wait till you're down to like 30 m/s or even lower and only then try to go back up to max speed (rinse and repeat). Thus, using more of the momentum. I guess the result will kinda be similar to the second test but will probably save a little bit because you will most likely reach 0g when you're not at 100m/s and thus you're saving the hydrogen needed to get yourself back up to max speed at the end. But it's also much less "taxing" as the second method as you only occasionally need to speed up again.
True, you could probably drift the last 5 to 10 km. I wouldn't recommend letting your speed drop too much till you are down to 0.3 g or less though. Before then you'll slow down kind of fast. Extra time spent in high gravity might actually require more time thrusting overall. Would be an interesting test.
Nice comparisons. I prefer thruster override because I tend to make more mistakes when I mess with the dampeners. Like you said it is a personal preference and do what works best for you. I've never tried those two scripts, I really like the fuel efficiency so I might give the ACC one a try.
Thanks! True, turning off dampeners is also potentially dangerous. Before this video I'd never tried the scripts either, but I'm definitely going to next time I'm playing survival. They have nice functionality for triggering other blocks (such as timers) when you reach space too.
Great video, but I went overboard and did the math. Also, a well optimized flight program should result in a burn of 52838 Liters of fuel. This is done by restricting the thrust to a specific value, based on the experienced gravity value, that would allow for a constant velocity of 100 m/s without accelerating or decelerating. I see other pulsing methods, but it is way more tedious and larger range of error.
Cool to know the optimal value for fuel use! I'm happy that it's pretty close to what I got in a few of the tests (~5% difference). Certainly close enough for me to feel good using them.
My favourite way to save fuel on the way to space is to have a single event controller that kills all the thrusters when the grid speed's above 97m/s, and back on again when it slows down. THen you just hold space down. The EC will pulse my thrust way better than I can. If I don't want to hold space, thrust override is compatible. It's about as efficient as any script, but works in any server.
if script is written properly, you can just set speed to max and script will ascend with perfect time/fuel consumption using the power of math. So, likely Blarg's ACC indeed could be more efficient and faster, if you set the speed to 100 :P
Yes, with a perfect script it could be better. Blarg's has a default speed of 95m/s which makes me think that is its optimal value (or close to it). It also says this on the workshop page: "Setting a target speed to the same or above the speed limit of your world will ruin the performance. Keep it a couple of m/s below."
I have my own cruise control script that I use on my own designs or I use override when flying someone else's. I'm pretty sure you could make a basic cruise control with an event controller that is basically the override method managed for you that I'd say might be a valid vanilla option. I remember trying to set up a drone world when I was new to the game so i was aware of the RC wiggle, still disappointing the state of non-scripted AI imo.
My CC script is built into a whole array of autopilot and datalink tools built into a custom GUI for a faction I'm trying to build for anyone wondering why I don't use a pre-built one.
I use hydrogen in the game extensively so will always do the same type of testing every time they update the game just to make sure. Personally i still use the old method of switching off the dampeners and just manually pulsing since it doesn't require anything more then a couple of button presses rather then setting up yet another dedicated toolbar just for one task. The ~2% or so of fuel that the trust override method can potentially save has never really mattered to me enough to make me prefer it over the classic pulsing method.
I turn my upwards thrusters off, keep dampeners on and pulse. I've also done the ion slingshot a couple times too... uses 0 hydrogen but you gotta get the platinum from salvage or meteor craters.
I don't know about yall, but, I'm using constant thrust lol! Decent time, fuel usage isn't the worst, yes skill based flight is attractive but uh, If were talking skill Id just learn how to use C# and write my own flight script. But most of all, Constant is braindead, and I like that. B)
Hey im not sure if you ever review player ships but, my first ever spaceship i made in space engineers survival i uploaded lately, I probably spent about 90 hours creating it and not knowing anything about the game, to making a flying frame with cargo, then building more and more and decorating at the end, (its only got the nanobot build and repair system for mods) Id really like to know how i could improve this ship thanks Its name is "the Dagoth" on the workshop
If you join my discord there is a channel called "review my build", I go through anything posted in there and take a look when I stream on Twitch.tv. I post all my stream VODs to my second channel www.youtube.com/@more_shifty. Alternatively, if you catch me streaming I'll take a look right away usually.
You're right, using event controllers for the pulsing is a major improvement. I didn't think of it until the many comments about them on this video. They're great.
The AI seems to need at least one thruster in each direction in order to work at all. You could turn off all but one, or only have atmospheric and ion thrusters in those directions though.
It blows my mind that Keen based a whole major update around that turd of an AI, presenting it proudly like a toddler does their first try at making art.
Hahaha, NO! I hunt typos obsessively, yet they cannot be avoided. I'm sure my videos are riddled with them. It's ok, after looking at something long enough it will always look normal.
I think overall manual and pulse is the best. That takes the least effort, easy to understand and what you gain by anything else is meglegable. Personally I wouldn't spend time with a script just for that extra few liters and few sec of gain..
Yeah, I tend to agree, but I've been experimenting with using event controllers to automate pulsing (since the many recommendations to do so in the comments here). It seems like a solid system. Easy to set up and use, maybe worth a try for you as well.
I like to put a Rotor with a small grid head on my large grids. The rotors small grid i call Brainz and put all the timer blocks, programmable blocks, an antenna, plushies and such onto it. So the logics look nice swirling around on a loose rotor and are easy to overlook and blueprint. I like the designs, i saw. The seem well thought. And having proofed usefull.
@@ShiftyshadowTV Do you do it the other way around to? Like putting a big battery and ore detector on a small ship. Btw.: Somehow I managed to put the comment under the wrong video. xD It should have gone under the one, where you showed and asked for tipps and tricks.
@@ShiftyshadowTVFor your fuel test it was entirely right to do it the way you did, but yes, definitely more usual to do when already airborne or to dial-in the thrust override before disconnecting from the connector/ground.
I think the biggest irony here is that there is a dual method that works quite well that saves you on fuel usage at the trade off of a little battery usage. regular Atmo thrusters, eight up thrust, four down thrust, two to maybe four each for horizontal. One large hydrogen thruster a the back with a small one on each port and then two forward hydrogen thrusters. Two batteries, two gyros, large tank, large cargo,, O2/H2 and a drill. Get up to the point where you're slowing down quite a bit with the atmos and then flip the nose up to an upward burn (Back thrust off) with using overrides to prevent fuel waste. Coming back down you do have to (usually) reverse burn your way back down until the atmos can really keep a potentially heavy load in the air, but then Then you're down back to the atmos again and it's sailing back to base. Not always the ideal if you're doing a bunch of cargo transfer beyond searching the asteroids for platinum and Uranium/building dual use bases and transferring specific types of cargo to and from as needed even after the space base is self sufficient.
one could turn off dampeners then try using an AI to keep planetary alignment together with 2 event controllers one that looks at speed and toggles thrust on off and one that turns the system off in space like what you did
I tried turning of dampeners, but as soon as I switch the AI on the dampeners turn back on automatically. It seems that the game won't use AI or Remotes without them. The event controller for toggling thrusters on and off would be good as an alternative to manual pulsing, but I don't know if it will work with AI blocks (for reasons similar to above). Definitely requires more testing on my part. Thanks for the ideas.
it seems the developers must have set Ai this way for performance reasons. well another way to solve fuel efficiency is to refine ores at the mining site and ship the ingots since they need less space and have lower weight. Then when waiting for ore to refine one could set up other mining sites all of which can later operate on drones. As for the cost for all of this I would set up my base on top of iron ore and then build basic refineries which are only about 20% less efficient on the common ores than the full refinery without modules but very cheap.@@ShiftyshadowTV
If you have a more reasonable speed limit atleast 300 at minimum but i like the speed of light as the limit, it gets way easier because you are not either hovering or bumping against a oppressive limit.
I always have a large rear thruster using thrust override, no fuel wasted, no fall risk. 90 degrees up on the first person hud. If your rear thruster can't hold the weight alone I pitch down a bit until I get on the edge of positive rate, just keep speed at 95-99 m/s. Downside is that u need allot of thrust.
You didn't use a simple event controller and timer method, that monitors speed and increases or decreases override accordingly. Other than scripts this is the most efficient and hands off method. Just level yourself, turn it on and let it fly straight up. No need for ai or remote controls.
I’m not saying you’re doing thruster override wrong but you’re understanding of thruster override is wrong and you’re presenting it as such. Thruster override ride wording is misleading I think that’s the problem. It seems like it’s overriding your input but it’s overriding the idle input. So let’s say you’re hovering at 36kn of power. Now let’s say you could use thruster over ride to turn them down to 35kn. You would very slowly fall out of the sky. But now you decide you don’t want to fall than you hit space bar for let’s say 10 seconds. Ypu would shoot up in the sky at 400kn thrust not 35kn. So this is equivalent in real life of setting your car cruise control at 35 mph then pushing the gas peddle to the floor speeding up to 80 mph as quickly as it would with out Cruze on. So with this information the way you did it and everyone else is doing it would be like setting your cruise control at 80 stopping at a stop sign then turning on Cruze from a dead stop. The correct way to do it is accelerate than set Cruze. If you ever seen a toddler try to drink from a cup with a bunch of ice in it. They tip it back and back and back till the ice comes crashing into their face and they spill the drink all over themselves. I’m not saying you’re doing this wrong in the same way I’m not saying that baby is drinking from a cup wrong.
Thruster override is not like cruise control, aside from that they both involve setting a number to be constant. Those numbers have different units, and very different implications. Cruise control automatically varies your force to keep you at the same speed (regardless of hills, etc.). Thruster override keeps you outputting a specific force (at minimum) with no regard to your speed. The point made in this video is that if you are using thruster override at maximum speed, while exiting gravity you will be burning more fuel than you need to. This is because you are exiting gravity. The further you go, the less thrust you need to maintain maximum speed. You can turn down your thruster override, sure, but you're not doing to do it perfectly. To use the car analogy, you're keeping your foot on the gas even though you've hit a truck in front of you and cannot possibly go faster. Sure, you ease up on the gas, but you're going down a hill and the hill is getting steeper every second. You need to constantly be reducing your thrust.
Since I do wanna use automated ships myself, what I take from this is: I need to use an event controller to turn off certain thursters prevent the ai flight block from constantly breaking and wasting fuel
If you can, turn off all but one small thruster in any direction you don't need. You'll have to keep at least one on in each direction otherwise the AI has a lot of trouble.
You can set in your hotbar a "cruise control" button! Meaning you turn off certain thrusters that you don't want firing in the direction you want to go! I tend to have a forward "cruise control" and for those ships that can leave planetside, upwards thrusters!
The 3rd method is the way I tend to go but I see that all the time the way you did it but I tend to get going to near max 1st then switch over so I can keep going up! Edit: oh they are on a hotbar I tend to not use so....
Nice video, I don't have any problems on how you did the test! Just not everyone has access to the 6th nor 7th due too server settings and many servers will not allow them due too some to most players don't know self control! They will over do or over use something just to make it easy just for them! Please note, I'm not saying all of them are doing it on purpose, just most are doing it not knowing it can cause server lag even while they are offline(or no one's near their stuff) so even though those seem the nicest to use, just not every server admin will allow it!
go up and hover then see what thrust your up thrusters are using. Then said that amount of thrust as your override using group controls then you can manually increase or decrease your override from there and there will be zero falling whatsoever
If you turned all other thrusters off in the flight ai except for the thrusters up if it would improve efficentcy due to the ai using the side thrusters constantly
When I tested this I tried that. The AI constantly turned all my thrusters back on. Also, it completely doesn't work if you don't have at least one thruster in each direction.
andrew's simple cruise control script is my script of choice. makes flying way more efficient and fun in general. which is especially handy for fighters which generally seem to be fairly limited on fuel just triple tap forward or up and you immediately accelerate to 100m/s
5:38 Simple logic, if speed >100 kill thruster set for one second, then reengage. You can leave it on, and simply keep "up" pressed. Overburn prevention. (mind high grav planets though. In 15+G's you can decel to negative in one second fast enough to never reach orbit.)
I wonder how efficient event controllers with thrust overrides would be. I say less efficient than doing the overrides by hand but definitely much more efficient than using ai to get to space. Max out overrides, when you get to 99m/s turn thrusters off, when it goes down to 95m/s or whatever you set it to, thrusters on.
I recently did this for one of my builds. I did 99m/s off 98m/s on and it worked well. I also turned off the downward thrusters for the accent. I would say it is just as efficient if not more so then doing a manual pulse.
Didn't know about the two scripts that you used, I tend to use them and before you say why ? I use PAM since I do a lot of asteroid mining while on the planet. I will try the two scripts you used.
@@ShiftyshadowTV 56,967L to orbit, using the space GPS coordinate as a target. I don't have accurate timing results but I would put it just under 8 minutes. If your destination is a docking port on a space station, this script will dock better than the AI blocks for a fraction of the fuel cost. Most of the setup is in configuring the script, connector, and antenna on destinations and the ship. Though once this is done you pick where you want to go from a list on your ship, push start and it will fly there. It will navigate in space or gravity much better than the AI blocks by not spamming thrust in every direction at once.
Aerojets can get speed up at low altitudes, with auto return to base, for a first stage, only needing hydrogen for the part where they become non-functional, and with that only hydrogen enough to keep the speed upwards positive, not max. Last part is ions.
10:34 Remote control only makes sense if the blocks like cockpit and logic are removed, and reduce weight to orbit. But also it makes piloting multiple vessels easier, for you can use the same groundstation for many vehicles.
Great vid Shifty ! Another way is to auto adjust override using an event controller block and timer to trigger for increase override at a minimum speed and another pair for decrease override at a maximum speed. net result is a rapid pulsating thrust that calms down as gravity diminishes
@@ShiftyshadowTV This is a console friendly way (no scripts) as I play SE on PS5. Should you try it, have the two timers call themselves to "trigger now"{loop} and also setup action to "Stop" the other timer. one timer will increase override until the other EC triggers its own timer. You can play with the EC blocks "Grid Speed Changed" thresholds to be closer or farther from each other. I usually set the Maximum EC to decrease thrust override => ~99ms and play with the Minimum EC threshold to increase thrust override =< 95-98ms. Try it out and let me know if you have any suggestions. Thanks again for your great vids!
@@CorbinDallas_Doc Nice, I use the self "trigger now" loop all the time. I'll give it a try next time I'm in survival. Good to know it works on console too.
You don't even need the timers, just use the event controller to turn the thrusters on and off with the override maxed out, I use two event controllers with 2-3 speed difference (I also tend to use a few others and timers to put the ship back in 'ready to fly mode' in space too).
I think that staying at 100 or 99+ms is crucial for saving fuel and time. also overide is the best way , but that was not an objective test in my opinion. The right way is to stay at 100ms and drop a few ticks every 15-40 seconds unless you start dropping speed. and overide is safe , as long as you can click on lower overide 10x before the ground.
@@ShiftyshadowTV I mean just stick to 100ms , why just holding it around 95ms , this 5ms make a big difference for 2 reason , first the time that would get you to space and 2nd the less time you need to get to space the less fuel you consume , results were pretty closed and you did mention that you are not favoring override , seem a bit biaised to me , but thats just my opinion ..
@@franki99bum If you use thruster override the way you described in your first comment you will get to space faster, but it will use more fuel than the way I used thruster override. The time you're saving is very small, and you're over thrusting for the entire journey. The over thrusting will use way more fuel than then amount you save by getting there a few seconds faster. If you don't believe this, for any reason, I gave you all the tools to test it yourself.
I never used any AI or scripts for escaping gravity, however, i do think that using the AI blocks are easier and more convenient for entry and landing the spacecraft.
Nice experiment and presentation, but two errors and one overlooked consideration: 1. Your ship design isn't capable of sitting level on the pad without being connected or having thrusters on, both of which handicapped the Thruster Override method. That's a ship design flaw, not an issue with Thrust Override. You probably wasted 1000+ L just faffing about thrusting against the connector and hovering over the pad, both unnecessary and unsafe. 2. Ascending slower equals wasted fuel, the opposite of efficiency. Always ascend at the maximum speed you're capable of. This is as true in a sim as it is in the real world, which is why IRL rockets subject astronauts to serious G forces. You can prove this to yourself by making the ascent at ~50 m/s, or installing a speed mod and ascending at 200 m/s or even higher. I get why you set the script to ascend at 99 instead of 100 m/s to avoid thrusting against the speed limiter, not arguing against that: just your false assertion that slower = efficiency. 3. A related issue that most players overlook is how long it takes you to get to your maximum speed. If a ship can only just get off the pad, hypothetically, and spends a minute or two before reaching top speed, that's a huge amount of fuel wasted. Ascent efficiency drops off rapidly when you get below ~110% thrust to weight ratio. I usually recommend 120-140% or better. This might be worth exploring in a follow-up video testing an overloaded ship that struggles to get off the pad, versus the same design with some extra thrusters (even atmospheric) to get up to max speed quickly. The results can be shocking: an underpowered ascent vehicle can use 2-3x the fuel. Google "Space Engineers thruster quick reference" (posted on Reddit and Imgur) for my handy reference to thrust values. Otherwise a great video, cheers.
Surely I did not do a perfect job on any of the flights; however, I feel that the accuracy of data gathered is sufficient for the comparisons and conclusions I made. Whenever I mentioned going slower it was specifically because the faster speeds tended to cap out against the speed limit occasionally (wasting more fuel than going slightly slower and not capping out ever). At 99 m/s, that specific script tended to over thrust occasionally. It was set to 95m/s ("slightly slower") by default, so I assumed that would be more efficient. I did consider how long ships were taking to reach max speed. I purposely loaded my ship down to the point where it had to spend a noticeable chunk of time accelerating, so that we could factor efficient acceleration input into the test. That factor made a difference for the various methods (slightly for thruster override, a lot for the AI Blocks, and a little for the scripts). Perhaps I should have elaborated on this in the video.
Know what's even more efficient? Using atmospheric thrusters 1st, then hydrogens AFTER the atmos stop lifting!!!! Hydrogens don't work too well in atmosphere.
With hydrogen thrusters the best efficiency isn't full thrust 100% of the time. Accelerate to max speed, then release the thrust, when it reaches half speed, accelerate back to 100% again, and release again. Repeat. Continuous thrust is only useful if you actually get the full acceleration from it, which happens when using no speed limit mods.
Also, you said thruster override is dangerous and could destroy your ship, but said nothing about how that could happen. No idea what you are talking about.
One way that is automated would be using event controllers: turn off down thrusters, put on max override the up thrusters and turn them off also. Then set up the event controller: if speed is over 95 m/s turn off up thrusters, if speed is under 95 m/s turn them on
This should mimic your manual pulse method
You can set up a control bar with the turn on/off the up and down thrusters and the override of the down thrusters + turn on that event controller
Or you can make it mimic the thruster override method: if speed is over 95 m/s decrease the override of the up thrusters, if speed is under 95 m/s increase the override of the up thrusters
I would modify a tiny bit by having the switch made at over 98 and under 96. That leaves a small wiggle room so that it does not create to much lag by switching way to fast.
This is much easier and the most efficient anwser
I genuinely expected this to be one of the vanilla automated options, I guess I've played too much SE to need a video like this
My first trip to space was done with a shuttle that I designed specifically for the transition between planet-side and space. It has two large atmo thrusters pointing down, it’s set up for full atmospheric control (small thrusters in every other direction) and with a load of cargo, launching with the atmospheric is a bit slow, but once I begin to decelerate, I rotate upward 90° and fire the hydrogen thrusters. There are 3 large hydrogen thrusters on the back and they have no trouble putting me in space. Of course I have 4 large hydrogen tanks too, so I may be using more fuel than I realize. Figured why not carry a lot.
If it works and you're happy with it then you're doing it right. :)
I also like to carry way more fuel than I think I'll need.
@@ShiftyshadowTV Can’t hurt to be prepared, as long as you’ve got the thrust to carry your preparations 😆
Great break down Shifty!
Thanks! For some reason TH-cam decided to remove my last reply. Probably because I mentioned something about the way this video ended. (Not sure how picky it is, so I'll leave it at that.) Thanks for watching. :)
@@ShiftyshadowTVInteresting. I bet this video was a lot of work man. Thanks again!
Remotecontrol works fine as long as you set it up correctly. You do know that remote controls have their own internal speed limit right. So you could have set that to 99 m/s. As for direction. Orient it pointing forwards towards the cockpit(standard way). But choose UP direction and make sure both precision and avoid obstacles is off.
I did talk about the speed option in the video (maybe it was for the AI blocks, but it seems to have the same effect with remotes). It still uses a lot of fuel because it's always thrusting to try to maintain whatever speed you set it to. It thrusts, overshoots the desired speed, thrusts backward, etc.
I tried a lot of different orientations and settings, but perhaps I'm still doing it wrong, I'll experiment with it more.
Nice vídeo, congrats.
Thanks, I've been wanting to test this forever, glad I could share it.
How about an automatic-pulse method using an Event Controller to toggle thrusters off/on based on a speed threshold.
I didn't think of that while making the video, but a few people have mentioned methods using Event Controllers now. They sound like they work well, perhaps I'll make a follow-up video if I get enough new ideas.
@@ShiftyshadowTV, another variant would be having the thrust override method controlled by the Event Controller.
Also, you can create a timer block that bumps your thrust override way up/down by putting the applicable thrusters into multiple groups, and using each of those groups to trigger the increase/decrease in all 9 slots of all 9 action bars in the timer. That makes it much faster to crank up your thrust override quickly.
Exemplary style. Clear, concise, relaxed and non-over-the-top voice-over, planned, smart use of time with background info while the flights are in progress, with an overview at the beginning, and luxury features like jump marks. A treat to watch, thanks!
Glad you enjoyed it! Looking forward to making more.
one method that I didn't see was computer aided pulse thrusting, it works as follows
put all up thrusters into a group, and all down thrusters into a group
disable upwards and downwards thrusters, set upwards thrusters thrust override to 100%, and add an event controller
make the event controller activate whenever speed is below 95 m/s, and have it turn on the upwards thrusters when below the threshold, and turn them off again when above the threshold.
this method has all the advantages of pulse thrust and automated flight, but without the pesky features of AI thruster spam.
Yup, I've gotten a good stack of comments recommending event controller methods of one sort or another. It's definitely something I'm going to try out.
Thruster override (easy mode) - Turn upward thrusters, damps, and gyros off. Max out the upward thruster override. For launch, turn on thrusters while disconnecting. The thrusters are immediately at 100%. Adjust the override keeping between XX-99 km/s. XX is your preferred minimum speed, the lower the minimum speed, the longer the trip takes and the more fuel you spend. No reason to be afraid of going below 90 km/s because the whole point of doing an override is for easy mode. When you reach orbit, you will turn off the override and turn on gyros and damps. Much safer and only as inefficient as you care to be by picking your minimum speed. If efficiency is king, do it 100% manually. You will spend a lot more than 7 minutes configuring AI and Control blocks for very little fuel savings. Try to remove the remote control wobble by turning off the gyros. Maybe even setting a zero override on all other thrusters to prevent them from being misused by the remote control block. I think I have seen the last script on a few lets play and I don't think you scratched the surface of what it does. Looking forward to another small grid ep.
I'd suggest setting the gyro(s) to override (with the settings left at the default zeroed positions) rather than turning them off as this will actively work to keep your ship level and, should any other forces try to turn or flip your ship, it will act to prevent/reduce that with up to its maximum rotational power. Add a toggle on your hot bar to enable and disable the override for your gyro or gyros group so that if you need to quickly alter where you are heading (for instance if an asteroid pops up in your direction of travel) you aren't having to go into the control panel to disable the override.
I'll have to give some of those tips a try, for the remote control. Yeah, both scripts can do a lot more, I was just testing basic fuel efficiency.
Setting up AI is only worth it if you have a base you often take off from. (Or you want to run drones.) Whenever available I think the scripts are probably best. You can set them up once and then they work anywhere.
Looking forward to starting SGO up again.
@@PoolOfTrees I used the override to make an automatic surface to space ferry a while back. Not sure why I didn't think of it here. Might have helped with the Remote Control and AI blocks. Though, they seem to need control of at least one to function at all some times.
why not go with 6000m/s?
@@AxoCatWasTaken100% agreed. If you up the speed limit past 99 km/s then you have no problems at all with wasting fuel.
I find the pulsing to be the easiest way. However, I leave my inertial dampeners on and just switch off my Down thrusters. I usually have the down and backwards thrusters as separate groups on my toolbars for cruising or escaping gravity.
Good idea, I usually have the backwards thrusters on my hotbar as well, haven't ever done the down ones though. Would probably be less dangerous than messing with inertial dampeners all the time.
I was going to say this. This is my method as well. It works great.
Downward thruster On/Off is only needed until you're in space.
You can use the same method, for example, when approaching another asteroid. If you're 10 kilometers away and aiming to approach but only relying on visual judgment, there's a risk of nearly crashing into objects. By manually turning off your 'braking' thrusters (using the hotbar), you can keep the dampeners active and make slight adjustments to your course. This way, the dampeners work for you, eliminating the need to constantly press 'A' and 'D' to align the crosshair.
This technique is equally effective when flying around an asteroid or navigating on a planet. It stands out as one of the most fuel-efficient and straightforward methods.
I learned this tip from someone with over 6000 hours in Space Engineers. It's undoubtedly one of the best pieces of advice I've encountered.
Sad to see that the remote control is that buggy with such a simple task. Even the newer Artificial "Intelligence" blocks are so innefficent at their task.
There's probably a way to get it to work better using event controllers, but by itself yeah, it was very inefficient.
They weren't designed with fuel efficiency in mind, rather flight stability and compatibility.
I was impressed by those scripts. I certainly didn't expect them to be that efficient. Inversely, I hadn't expected the Remote Control or AI blocks to be so inefficient (and so much worse than just keeping you thumb or a weight pressing on the spacebar). If Keen could tweak the AI behaviour to reduce and increase thrust in the desired direction, rather than apply reverse thrust, to keep it around the desired speed limit (and obviously fix the 'wobbling around' issue) then that should make quite a bit of difference to fuel usage.
Yeah it definitely would. I knew they would be worse, just not that much. I was expecting 10-30% more fuel consumption, not 75%!
That left me wondering what would happen if you just turned off all thrusters not going downwards.
@@yle5788 I think that the remote and AI requires thrusters to exist and be enabled in every direction, but I've not tried testing without for a long time.
@@PoolOfTrees no they don't require that.
As a software engineer I find it funny that he said that downloading the scripts is a hassle, but beyond that, great video.
Man ended the video in style.
Seriously, though, that was really informative. I've never actually used the Remote or AI Blocks to go to space from a planet and was quite surprised that they use such a ludicrous amount of fuel. It's almost 5x the minimum amount.
Yeah, I knew they were worse, but didn't expect them to be that far off.
Basically with all others minor horizontal adjustments either weren't made or were made with small input values while AI blocks can only give on/off directions to make their adjustments (similar to a player actively flying a precise route) and this is the cause for much of their fuel burn. The 100 speed limit opposed to 99 probably didnt do many favors either though
@@xxbongobazookaxx7170 Yup, the sideways thrust burned more than the up thrust for the AI.
8:44 Remove pilot error. You can stop thrusting when at 35+ km when already at max speed,
since it takes a whole lotta time to decel to zero, in which you travel the rest of the way.
Also, low-G saving, add a few small ion engines for the low-G part.
They cost little in weight but can make a difference by keeping the speed up better.
(Also, in space-engineer space ions rule, since they cost no resources to operate,
for regular travel, besides (solar) power.)
just setup 2 event controllers
1 for escaping gravity, which turns off upward thrust at 95m/s
1 for controlled max speed, which turns off forward thrust at 95m/s
both will greatly save fuel, while still allowing you to just hold space / forward
Good idea. I'm going to experiment with the Event Controllers and sort out a method that only takes me one button press. So I can walk away while I'm traveling.
The one problem I have with the thrust override method is for whatever reason Keen thought that a thruster being manually fired should have a higher TWR than one on max thrust override. Thus you could get a design that can make it to space under manual control, but will crash and burn if you activate thrust override method.
Hate to mention, but one of the prebuilt buyable ships from the eco DLC does suffer from this issue terribly.
With that said, I still love me some thrust override to space 😁
If have multiple thrusters, you can exponentially group them (group of 1,2,4,8, etc) and then thruster override the groups for very fine control. You can dial in exactly for perfect fuel efficiency and zero manual "wobble" in your thruster override inputs (becomes a gradual decrease as you climb)
im the someone in the comments
you are doing thrust override incorrectly
you only apply as much thrust as it takes to defeat gravity, never more
just enough to increase in velocity. you will increase in velo slowly and then quickly (because gravity will become weaker over time)
once you hit max speed, decrease one tick and let yourself reach equilibrium. once you hit eq you will again start to increase in velocity.
only decrease once you hit max speed again
repeat
you can get to space from earth using around 1% - 3% of fuel (dependent on ship mass and size of tank used) and it takes ~the same amount of time as your other methods.
Well, I ran my own test on your world.
My usual method was a lot worse than I thought it was, so I tuned it until I got a respectable time.
Using my new method, I was able to get ship 2 into space in 7:20.67, and used 57499L of fuel.
Your fastest time was 7:25 with constant thrust, and your most efficient fuel usage was manual pulse @ 55776L.
I was faster than your fastest time and used just slightly more fuel than your most efficient method.
Timing was as follows, which is slightly different than what I normally do.
-Turn down thrust off, leave everything else on (turning off damps is noob mode, only bads turn off damps, discipline yourself and learn how to control your ship in every axis properly)
-Set up thrust to 448Kn (max) and ascend until you achieve max velocity.
-At an elevation of 9000m, decrease thrust to 288Kn, and then at the following elevations, decrease thrust again to the noted amount of Kn. Each of these settings will be just enough to defeat gravity, so you should remain at max velocity while spending as little fuel as possible. (I noted elevation, not gravity, I would have like to have noted gravity but just didn't.)
11Km = 216Kn
12.8Km = 192Kn
16Km = 144Kn
18Km = 120Kn
20.5Km = 96Kn
23.8Km = 72Kn
28Km = 48Kn
37Km = 24Kn (the lowest setting)
This was somehow faster than max thrust and used a lot less fuel.
I wish the event controller were placed facing backwards so that the elevation and the blue dot on the EC could be seen at the same time, but oh well.
Did totally enjoy this video! Keep up the good work.
Thanks! Certainly more to come.
For thruster override, I just hold space bar until I reach max speed, then engage the override. Doing it before you take off or as you take off is kind of goofy.
you can install some atmospheric or smaller hydrogen thrusters to allow you to hover first, which then allows you to ramp up thrust override on a bigger more efficient thruster if you want to do it manaully
Rant: Damn it this is so well done nothing left for us... Joke aside thank you for going through this.
Now I would have loved to see a variation of the second test, where, instead of staying at top speed, you only go to top speed, then wait till you're down to like 30 m/s or even lower and only then try to go back up to max speed (rinse and repeat). Thus, using more of the momentum.
I guess the result will kinda be similar to the second test but will probably save a little bit because you will most likely reach 0g when you're not at 100m/s and thus you're saving the hydrogen needed to get yourself back up to max speed at the end.
But it's also much less "taxing" as the second method as you only occasionally need to speed up again.
True, you could probably drift the last 5 to 10 km. I wouldn't recommend letting your speed drop too much till you are down to 0.3 g or less though. Before then you'll slow down kind of fast. Extra time spent in high gravity might actually require more time thrusting overall. Would be an interesting test.
Nice comparisons. I prefer thruster override because I tend to make more mistakes when I mess with the dampeners. Like you said it is a personal preference and do what works best for you. I've never tried those two scripts, I really like the fuel efficiency so I might give the ACC one a try.
Thanks! True, turning off dampeners is also potentially dangerous. Before this video I'd never tried the scripts either, but I'm definitely going to next time I'm playing survival. They have nice functionality for triggering other blocks (such as timers) when you reach space too.
Great video, but I went overboard and did the math. Also, a well optimized flight program should result in a burn of 52838 Liters of fuel. This is done by restricting the thrust to a specific value, based on the experienced gravity value, that would allow for a constant velocity of 100 m/s without accelerating or decelerating. I see other pulsing methods, but it is way more tedious and larger range of error.
Cool to know the optimal value for fuel use! I'm happy that it's pretty close to what I got in a few of the tests (~5% difference). Certainly close enough for me to feel good using them.
My favourite way to save fuel on the way to space is to have a single event controller that kills all the thrusters when the grid speed's above 97m/s, and back on again when it slows down. THen you just hold space down. The EC will pulse my thrust way better than I can. If I don't want to hold space, thrust override is compatible. It's about as efficient as any script, but works in any server.
A lot of comments recommended the use of Event Controllers, and I have to say they're my new favorite way to do it as well.
if script is written properly, you can just set speed to max and script will ascend with perfect time/fuel consumption using the power of math.
So, likely Blarg's ACC indeed could be more efficient and faster, if you set the speed to 100 :P
Yes, with a perfect script it could be better.
Blarg's has a default speed of 95m/s which makes me think that is its optimal value (or close to it). It also says this on the workshop page: "Setting a target speed to the same or above the speed limit of your world will ruin the performance. Keep it a couple of m/s below."
I have my own cruise control script that I use on my own designs or I use override when flying someone else's. I'm pretty sure you could make a basic cruise control with an event controller that is basically the override method managed for you that I'd say might be a valid vanilla option. I remember trying to set up a drone world when I was new to the game so i was aware of the RC wiggle, still disappointing the state of non-scripted AI imo.
My CC script is built into a whole array of autopilot and datalink tools built into a custom GUI for a faction I'm trying to build for anyone wondering why I don't use a pre-built one.
i use thruster overide have it as it just barly lift at any time.
I use hydrogen in the game extensively so will always do the same type of testing every time they update the game just to make sure.
Personally i still use the old method of switching off the dampeners and just manually pulsing since it doesn't require anything more then a couple of button presses rather then setting up yet another dedicated toolbar just for one task. The ~2% or so of fuel that the trust override method can potentially save has never really mattered to me enough to make me prefer it over the classic pulsing method.
Same.
I turn my upwards thrusters off, keep dampeners on and pulse. I've also done the ion slingshot a couple times too... uses 0 hydrogen but you gotta get the platinum from salvage or meteor craters.
I've haven't done an ion liftoff since they removed Pt from planets. I think I prefer hydrogen for most things nowadays. Used to hate it.
I don't know about yall, but, I'm using constant thrust lol!
Decent time, fuel usage isn't the worst, yes skill based flight is attractive but uh, If were talking skill Id just learn how to use C# and write my own flight script.
But most of all, Constant is braindead, and I like that. B)
Gotta do what you enjoy. Nothing wrong with that.
override with event controller (turn off when max speed, turn on when below 95) is the most simple and efficient automatic method.
Yup, didn't try that till after making the video. There are about a million ways to use an event controller to simplify the process.
Hey im not sure if you ever review player ships but, my first ever spaceship i made in space engineers survival i uploaded lately, I probably spent about 90 hours creating it and not knowing anything about the game, to making a flying frame with cargo, then building more and more and decorating at the end, (its only got the nanobot build and repair system for mods) Id really like to know how i could improve this ship thanks Its name is "the Dagoth" on the workshop
If you join my discord there is a channel called "review my build", I go through anything posted in there and take a look when I stream on Twitch.tv. I post all my stream VODs to my second channel www.youtube.com/@more_shifty.
Alternatively, if you catch me streaming I'll take a look right away usually.
I feel like event controllers could operate the manual override method. Thanks for the video, the results were interesting!
You're right, using event controllers for the pulsing is a major improvement. I didn't think of it until the many comments about them on this video. They're great.
wow great vid. ? have you tried the Manual Pulse To Auto Pulse using A event controller some people use 2 ECs but one can be using slot 1 & 2
Thanks. I have not tried event controllers, but a number of people have recommended it now. I'll be giving it a shot next time I'm in survival.
What about remote control/AI Flight with only the upwards thruster enabled?
The AI seems to need at least one thruster in each direction in order to work at all. You could turn off all but one, or only have atmospheric and ion thrusters in those directions though.
Nice. It would be interesting to know what the scripts are actually doing to get that efficiency.
I've never dug into the coding itself, would be interesting. I doubt I'll do it until I want to make one myself though.
It blows my mind that Keen based a whole major update around that turd of an AI, presenting it proudly like a toddler does their first try at making art.
After so many years watching Keen just producing one pile of mediocre crap after the next one, I found it everything _but_ mind-blowing, frankly.
just strap trhusters to your base and set sail
/me rages and rants in the comments!
/me pours fuel on the fire!
@@ShiftyshadowTVDon't you mean "Feul"? ... like it says on the LCD? lol
Hahaha, NO! I hunt typos obsessively, yet they cannot be avoided. I'm sure my videos are riddled with them.
It's ok, after looking at something long enough it will always look normal.
@@ShiftyshadowTV I know! I only noticed after watching the ending again, after your last comment lol
I think overall manual and pulse is the best. That takes the least effort, easy to understand and what you gain by anything else is meglegable. Personally I wouldn't spend time with a script just for that extra few liters and few sec of gain..
Yeah, I tend to agree, but I've been experimenting with using event controllers to automate pulsing (since the many recommendations to do so in the comments here). It seems like a solid system. Easy to set up and use, maybe worth a try for you as well.
@@ShiftyshadowTV I'll check. Or we can have a contest, if we ever end up in coop. 😄
How about one with event controllers doing thrust overrides?
A few (lot of) people have recommended this since. It's definitely a good way to do it, maybe my new favorite.
I like to put a Rotor with a small grid head on my large grids. The rotors small grid i call Brainz and put all the timer blocks, programmable blocks, an antenna, plushies and such onto it. So the logics look nice swirling around on a loose rotor and are easy to overlook and blueprint.
I like the designs, i saw. The seem well thought. And having proofed usefull.
I do that too sometimes. Also put my antenna on it to save space.
@@ShiftyshadowTV
Do you do it the other way around to? Like putting a big battery and ore detector on a small ship.
Btw.: Somehow I managed to put the comment under the wrong video. xD It should have gone under the one, where you showed and asked for tipps and tricks.
@@alfredwayne7002 All good. I do put a large grid ore detector on a small grid ship for scouting ores on planets.
I do the override method but i prefer to start airborne
I think most people do that, high enough that they don't actually crash. I was being a little silly in the video. :)
@@ShiftyshadowTV tbh its entirely fair to assume the average SE player has less than 5 iq...
@@Cuteseals2 Hahahaha, I'm definitely part of that crew sometimes.
@@ShiftyshadowTVFor your fuel test it was entirely right to do it the way you did, but yes, definitely more usual to do when already airborne or to dial-in the thrust override before disconnecting from the connector/ground.
What about thruster override managed by event block
Definitely a good idea.
I think the biggest irony here is that there is a dual method that works quite well that saves you on fuel usage at the trade off of a little battery usage. regular Atmo thrusters, eight up thrust, four down thrust, two to maybe four each for horizontal. One large hydrogen thruster a the back with a small one on each port and then two forward hydrogen thrusters. Two batteries, two gyros, large tank, large cargo,, O2/H2 and a drill. Get up to the point where you're slowing down quite a bit with the atmos and then flip the nose up to an upward burn (Back thrust off) with using overrides to prevent fuel waste. Coming back down you do have to (usually) reverse burn your way back down until the atmos can really keep a potentially heavy load in the air, but then Then you're down back to the atmos again and it's sailing back to base. Not always the ideal if you're doing a bunch of cargo transfer beyond searching the asteroids for platinum and Uranium/building dual use bases and transferring specific types of cargo to and from as needed even after the space base is self sufficient.
one could turn off dampeners then try using an AI to keep planetary alignment together with 2 event controllers one that looks at speed and toggles thrust on off and one that turns the system off in space like what you did
I tried turning of dampeners, but as soon as I switch the AI on the dampeners turn back on automatically. It seems that the game won't use AI or Remotes without them.
The event controller for toggling thrusters on and off would be good as an alternative to manual pulsing, but I don't know if it will work with AI blocks (for reasons similar to above). Definitely requires more testing on my part. Thanks for the ideas.
it seems the developers must have set Ai this way for performance reasons. well another way to solve fuel efficiency is to refine ores at the mining site and ship the ingots since they need less space and have lower weight. Then when waiting for ore to refine one could set up other mining sites all of which can later operate on drones. As for the cost for all of this I would set up my base on top of iron ore and then build basic refineries which are only about 20% less efficient on the common ores than the full refinery without modules but very cheap.@@ShiftyshadowTV
If you have a more reasonable speed limit atleast 300 at minimum but i like the speed of light as the limit, it gets way easier because you are not either hovering or bumping against a oppressive limit.
I always have a large rear thruster using thrust override, no fuel wasted, no fall risk. 90 degrees up on the first person hud. If your rear thruster can't hold the weight alone I pitch down a bit until I get on the edge of positive rate, just keep speed at 95-99 m/s. Downside is that u need allot of thrust.
I would use event controllers. If the speed is 99 m/s, turn off the thruster.
A lot of people have recommended this, and I've since tested it. It is a very good way of doing it.
@@ShiftyshadowTV I'm glad I didn't invent something stupid. It would be interesting to compare the times with the other variants.
Why no Elevator music tho? 😅
Haha, I've done that in other videos. Too busy talking in this one.
Blargs is best, been using it for years.
This was my first time trying it. It was definitely satisfying.
You didn't use a simple event controller and timer method, that monitors speed and increases or decreases override accordingly. Other than scripts this is the most efficient and hands off method. Just level yourself, turn it on and let it fly straight up. No need for ai or remote controls.
Very excellent video! It's amazing how much time and effort you put into this. Thank you very much! Very informative!
Thanks! It was a fun project and I learned a lot along the way.
Event controller?
PAM?
Definitely going to try the Event Controller. There are a lot of ways it could be used to simplify the manual stuff.
This will put the "NOOOO YOU CAN'T DO IT THIS WAY" milk drinkers in place.
They'll probably rant that I didn't do the tests right (as a few already have). Haha. It's ok though, everyone can play, and say, what want.
7:28 Yep. The way I do it is manually get up to speed and then spam Override Up. You lose almost no speed and never lose altitude.
Solid way to do it.
I’m not saying you’re doing thruster override wrong but you’re understanding of thruster override is wrong and you’re presenting it as such.
Thruster override ride wording is misleading I think that’s the problem. It seems like it’s overriding your input but it’s overriding the idle input.
So let’s say you’re hovering at 36kn of power. Now let’s say you could use thruster over ride to turn them down to 35kn. You would very slowly fall out of the sky. But now you decide you don’t want to fall than you hit space bar for let’s say 10 seconds. Ypu would shoot up in the sky at 400kn thrust not 35kn.
So this is equivalent in real life of setting your car cruise control at 35 mph then pushing the gas peddle to the floor speeding up to 80 mph as quickly as it would with out Cruze on.
So with this information the way you did it and everyone else is doing it would be like setting your cruise control at 80 stopping at a stop sign then turning on Cruze from a dead stop. The correct way to do it is accelerate than set Cruze.
If you ever seen a toddler try to drink from a cup with a bunch of ice in it. They tip it back and back and back till the ice comes crashing into their face and they spill the drink all over themselves. I’m not saying you’re doing this wrong in the same way I’m not saying that baby is drinking from a cup wrong.
Thruster override is not like cruise control, aside from that they both involve setting a number to be constant. Those numbers have different units, and very different implications. Cruise control automatically varies your force to keep you at the same speed (regardless of hills, etc.). Thruster override keeps you outputting a specific force (at minimum) with no regard to your speed.
The point made in this video is that if you are using thruster override at maximum speed, while exiting gravity you will be burning more fuel than you need to. This is because you are exiting gravity. The further you go, the less thrust you need to maintain maximum speed. You can turn down your thruster override, sure, but you're not doing to do it perfectly.
To use the car analogy, you're keeping your foot on the gas even though you've hit a truck in front of you and cannot possibly go faster. Sure, you ease up on the gas, but you're going down a hill and the hill is getting steeper every second. You need to constantly be reducing your thrust.
Yea.. you did taking off with override wrong 🤔
Since I do wanna use automated ships myself, what I take from this is: I need to use an event controller to turn off certain thursters prevent the ai flight block from constantly breaking and wasting fuel
If you can, turn off all but one small thruster in any direction you don't need. You'll have to keep at least one on in each direction otherwise the AI has a lot of trouble.
You could use hydrogen only in the up direction and then atmospheric and ion thrusters in the other directions. This would save a lot of fuel.
You can set in your hotbar a "cruise control" button! Meaning you turn off certain thrusters that you don't want firing in the direction you want to go! I tend to have a forward "cruise control" and for those ships that can leave planetside, upwards thrusters!
The 3rd method is the way I tend to go but I see that all the time the way you did it but I tend to get going to near max 1st then switch over so I can keep going up!
Edit: oh they are on a hotbar I tend to not use so....
Nice video, I don't have any problems on how you did the test! Just not everyone has access to the 6th nor 7th due too server settings and many servers will not allow them due too some to most players don't know self control! They will over do or over use something just to make it easy just for them! Please note, I'm not saying all of them are doing it on purpose, just most are doing it not knowing it can cause server lag even while they are offline(or no one's near their stuff) so even though those seem the nicest to use, just not every server admin will allow it!
go up and hover then see what thrust your up thrusters are using. Then said that amount of thrust as your override using group controls then you can manually increase or decrease your override from there and there will be zero falling whatsoever
Good way to do it for sure.
If you turned all other thrusters off in the flight ai except for the thrusters up if it would improve efficentcy due to the ai using the side thrusters constantly
When I tested this I tried that. The AI constantly turned all my thrusters back on. Also, it completely doesn't work if you don't have at least one thruster in each direction.
andrew's simple cruise control script is my script of choice. makes flying way more efficient and fun in general. which is especially handy for fighters which generally seem to be fairly limited on fuel
just triple tap forward or up and you immediately accelerate to 100m/s
Great little video, thanks for the info and doing the test, very helpful.
Thanks, hope it helps!
5:38 Simple logic, if speed >100 kill thruster set for one second, then reengage.
You can leave it on, and simply keep "up" pressed. Overburn prevention.
(mind high grav planets though. In 15+G's you can decel to negative in one second
fast enough to never reach orbit.)
I wonder how efficient event controllers with thrust overrides would be. I say less efficient than doing the overrides by hand but definitely much more efficient than using ai to get to space. Max out overrides, when you get to 99m/s turn thrusters off, when it goes down to 95m/s or whatever you set it to, thrusters on.
Ah, that would have been a great thing to test! I bet it would be pretty good, and it's super easy to set up.
I recently did this for one of my builds. I did 99m/s off 98m/s on and it worked well. I also turned off the downward thrusters for the accent. I would say it is just as efficient if not more so then doing a manual pulse.
@@ssislo84 Nice, I imagine it would be more efficient as long as it is accurate.
I was looking for this since I'm about to build my first orbital grid and was looking for automation methods.
Didn't know about the two scripts that you used, I tend to use them and before you say why ? I use PAM since I do a lot of asteroid mining while on the planet. I will try the two scripts you used.
725k meters to space
I'd like to see this same test run with the SAM script to orbit. Might give that a shot as I see the world is posted on the workshop.
Let me know how it goes.
@@ShiftyshadowTV 56,967L to orbit, using the space GPS coordinate as a target. I don't have accurate timing results but I would put it just under 8 minutes.
If your destination is a docking port on a space station, this script will dock better than the AI blocks for a fraction of the fuel cost. Most of the setup is in configuring the script, connector, and antenna on destinations and the ship. Though once this is done you pick where you want to go from a list on your ship, push start and it will fly there. It will navigate in space or gravity much better than the AI blocks by not spamming thrust in every direction at once.
@@TheReedsofEnki Cool, that's good efficiency. Nice that you can set it up to dock too.
Aerojets can get speed up at low altitudes, with auto return to base,
for a first stage, only needing hydrogen for the part where they become
non-functional, and with that only hydrogen enough to keep the speed upwards
positive, not max. Last part is ions.
10:34 Remote control only makes sense if the blocks like cockpit and logic are removed,
and reduce weight to orbit. But also it makes piloting multiple vessels easier,
for you can use the same groundstation for many vehicles.
Great vid Shifty ! Another way is to auto adjust override using an event controller block and timer to trigger for increase override at a minimum speed and another pair for decrease override at a maximum speed. net result is a rapid pulsating thrust that calms down as gravity diminishes
Thanks! Event controller sounds like a great method. Easy to set up and effective.
@@ShiftyshadowTV This is a console friendly way (no scripts) as I play SE on PS5. Should you try it, have the two timers call themselves to "trigger now"{loop} and also setup action to "Stop" the other timer. one timer will increase override until the other EC triggers its own timer. You can play with the EC blocks "Grid Speed Changed" thresholds to be closer or farther from each other. I usually set the Maximum EC to decrease thrust override => ~99ms and play with the Minimum EC threshold to increase thrust override =< 95-98ms. Try it out and let me know if you have any suggestions. Thanks again for your great vids!
@@CorbinDallas_Doc Nice, I use the self "trigger now" loop all the time. I'll give it a try next time I'm in survival. Good to know it works on console too.
You don't even need the timers, just use the event controller to turn the thrusters on and off with the override maxed out, I use two event controllers with 2-3 speed difference (I also tend to use a few others and timers to put the ship back in 'ready to fly mode' in space too).
I think that staying at 100 or 99+ms is crucial for saving fuel and time. also overide is the best way , but that was not an objective test in my opinion. The right way is to stay at 100ms and drop a few ticks every 15-40 seconds unless you start dropping speed. and overide is safe , as long as you can click on lower overide 10x before the ground.
This world file is on the workshop, download it and test your methods with the same setup. Then let me know what you get.
@@ShiftyshadowTV I mean just stick to 100ms , why just holding it around 95ms , this 5ms make a big difference for 2 reason , first the time that would get you to space and 2nd the less time you need to get to space the less fuel you consume , results were pretty closed and you did mention that you are not favoring override , seem a bit biaised to me , but thats just my opinion ..
@@franki99bum
If you use thruster override the way you described in your first comment you will get to space faster, but it will use more fuel than the way I used thruster override.
The time you're saving is very small, and you're over thrusting for the entire journey. The over thrusting will use way more fuel than then amount you save by getting there a few seconds faster.
If you don't believe this, for any reason, I gave you all the tools to test it yourself.
I never used any AI or scripts for escaping gravity, however, i do think that using the AI blocks are easier and more convenient for entry and landing the spacecraft.
Nice experiment and presentation, but two errors and one overlooked consideration:
1. Your ship design isn't capable of sitting level on the pad without being connected or having thrusters on, both of which handicapped the Thruster Override method. That's a ship design flaw, not an issue with Thrust Override. You probably wasted 1000+ L just faffing about thrusting against the connector and hovering over the pad, both unnecessary and unsafe.
2. Ascending slower equals wasted fuel, the opposite of efficiency. Always ascend at the maximum speed you're capable of. This is as true in a sim as it is in the real world, which is why IRL rockets subject astronauts to serious G forces. You can prove this to yourself by making the ascent at ~50 m/s, or installing a speed mod and ascending at 200 m/s or even higher. I get why you set the script to ascend at 99 instead of 100 m/s to avoid thrusting against the speed limiter, not arguing against that: just your false assertion that slower = efficiency.
3. A related issue that most players overlook is how long it takes you to get to your maximum speed. If a ship can only just get off the pad, hypothetically, and spends a minute or two before reaching top speed, that's a huge amount of fuel wasted. Ascent efficiency drops off rapidly when you get below ~110% thrust to weight ratio. I usually recommend 120-140% or better. This might be worth exploring in a follow-up video testing an overloaded ship that struggles to get off the pad, versus the same design with some extra thrusters (even atmospheric) to get up to max speed quickly. The results can be shocking: an underpowered ascent vehicle can use 2-3x the fuel. Google "Space Engineers thruster quick reference" (posted on Reddit and Imgur) for my handy reference to thrust values.
Otherwise a great video, cheers.
Surely I did not do a perfect job on any of the flights; however, I feel that the accuracy of data gathered is sufficient for the comparisons and conclusions I made.
Whenever I mentioned going slower it was specifically because the faster speeds tended to cap out against the speed limit occasionally (wasting more fuel than going slightly slower and not capping out ever). At 99 m/s, that specific script tended to over thrust occasionally. It was set to 95m/s ("slightly slower") by default, so I assumed that would be more efficient.
I did consider how long ships were taking to reach max speed. I purposely loaded my ship down to the point where it had to spend a noticeable chunk of time accelerating, so that we could factor efficient acceleration input into the test. That factor made a difference for the various methods (slightly for thruster override, a lot for the AI Blocks, and a little for the scripts). Perhaps I should have elaborated on this in the video.
Know what's even more efficient? Using atmospheric thrusters 1st, then hydrogens AFTER the atmos stop lifting!!!! Hydrogens don't work too well in atmosphere.
With hydrogen thrusters the best efficiency isn't full thrust 100% of the time.
Accelerate to max speed, then release the thrust, when it reaches half speed,
accelerate back to 100% again, and release again. Repeat.
Continuous thrust is only useful if you actually get the full acceleration from it,
which happens when using no speed limit mods.
Also, you said thruster override is dangerous and could destroy your ship, but said nothing about how that could happen. No idea what you are talking about.