RizzoTheRat

Finally researched the parts to put be able to put up an LKO Kommunications network, so built a launcher and 4 satellites. It got to orbit with over 2500m/s remaining, bit of an overkill so I removed the entire third stage. ...and it still made it to orbit with nearly 1500 m/s. I clearly need to practice my builds, but with my new low TWR upper stage launch profile it's taking a bit of getting used to. Annoyingly I ended up with the solar panels clipping though the kOS module but couldn't be bothered to revert and change it. I do love a nice resonant orbit though

I only really use bases for drilling and refining fuel, but even then lugging the gear out to set up a base is probably more mass than the amount of fuel I ever use from that base. With a life support mod you need more stuff at your base to keep the crew alive. I use USI-LS and my bases have extra habitation space and the ability to grow food, but I could do that in orbit just as easily. To make bases worthwhile you really a much bigger mod. USI-Kolonisation for example adds in several more resources so you have a whole production cycle, but to make bases really useful you need something like Extra Planetary Launchpads so you can mine, refine and actually build stuff.

Today I am mostly waiting.... I keep my KSP install on my Dropbox so I can play it form different machines. My usual one is an i5-8600k, but I'm away for the next couple of weeks so any KSP time I get will be on my old Phenom X4. Quite a performance difference. Sent an early game mission to put 3 tourists in Mun orbit, and launch was running about 1/5 real time. Nice booster separation though To be fair though I am amazed how well KSP runs on older hardware. It might be a good idea to take SVE/EVE/Scatterer off though. Oh well, time to go and put another coat of paint on the hallway while I'm waiting for it to circularise

To be honest I've only ever heard of 2 of them, and one of those was because there were some posts on here about youtube changing the rights on the music he'd used. If I can't work out how to do something I'll occasionally have a look on youtube, which is where I've seen a few of Scott Manley's videos (I remember finding one really helped me do precision landings on the Mun), but the only other one I've ever remembered the name of is Cheers Kevin who did some good kOS videos that helped me out early on. If I'm sat at my PC I want to be playing KSP not watching other people play it. Twitch is the one that really amazes me though, I'm astounded that people will pay money to watch other people play games.

Thrust (N) = Fuel consumption (kg/s) x 9.81(m/s^2) x ISP (s). You can obviously convert in to fuel units as you know the weight in the tank. No idea how you get EC though.

As above practice is the only way really and it'll be different for each vehicle. For gliders airbrakes are your friend, come in long and use the brakes to steepen your approach (brakes to control descent rate, pitch to control speed). Personally I always try and keep some fuel spare though and come in short and fly to the runway under power.

Inertial Measurement Unit. Basically a set of gyroscopes that can be used to measure acceleration in different directions. https://airandspace.si.edu/collection-objects/inertial-measurement-unit-space-shuttle kOS can access the output of science instruments you put on your vessel, so you can use the accelerometer to work out your ships acceleration. I've done this before to estimate drag by comparing thrust, mass and acceleration, but you could use the acceleration to calculate your speed and some fancy maths to then work out your location. You could also use the inbuilt vector system to imitate direction radio navigation, put in some ground stations and then measure the angle between them. Apollo also used a telescope and sextant as a backup method to update the INS, but that would be a bit trickier in KSP as you only have the planets to take bearings on rather than stars. I personally see kOS as a higher level system and accept that other instruments/systems have already worked out my velocity and location and I'm just putting the control layer over the top, but it's a powerful system so you should be able to work out things like ship:velocity:orbit by other means.

Had another brief play with this at the weekend. My original ship was launching at a TWR of about 1.8, but with a fairly short burn first stage (a pair of slightly detuned hammers). Dropping the TWR to 1.5, and therefore not pitching as steeply in the initial turn, resulted in it hitting orbit with less dV than the 1.8 TWR launch. The trouble with this is the launch profile is very dependant on the craft design, I think a lower TWR at launch would need a longer burning first stage, or a more powerful second stage, which means it's hard to compare profiles, and it's near impossible to base it on pre-launch dV as the first stage ISP is going to change so much as you ascend.

Having figured out how to write menus in kOS, I decided the rest of my output logging was a mess, so I've now built a tidier display setup in kOS The top section shows mission and status info, the middle section is used for menus which are used to define the first 3 parameters of the Mission info, or for outputting instrument data, and the bottom section is a scrolling output log. Mission script determines the individual tasks required to achieve the mission, and the Mission Mode is update at the end of each sub task, with the first 4 lines of the display saved to the ship to allow a mission to be continued from a save. So in these pics the ship started at Prelaunch on Kerbin with no mission file (new ship on the pad), was given a mission to go to Kerbin and Dock with a ship called MunOrb1. In the second pic it's mid launch, throttling back to maintain 50s to Apoapsis, and it will then circularise, match planes with the target ship, do a Hohmann transfer to get close to the target, approach the target using RCS to control drift, and then dock with the target... ...or it will once I've transferred all those functions (plus the one where it waits until it can launch in to the targets plane) from my 1.7 game to the to the new 1.8 structure and updated all the print logs... ...all of which is waiting until I've got the Hohmann transfer for non circular orbits code working properly so I can do the rescue contract I have outstanding, plus I need to come up a some kind of calculation to determine the initial turn angle (probably based on TWR, stage 1 burn time remaining, and some kind of drag prediction), and do a Mun orbit mission with 3 tourists despite not yet having decent solar panels or batteries

Yes, remaining dV once it's circularised at 80km, although my circularisation script isn't perfect and on steeper ascents where a longer circularisation burn is needed it can end up a km or two low.

I'd not seen it before so found it an interesting read, in particular how low your launch TWR is. My test ship launched at about 2:1 but I reckon I should repeat my tests with the solid boosters limited a bit too to see how that works. I assume all your comparisons used Vacuum dV? I got a bit distracted by another kOS problem the last few days (rendezvous with a target in eccentric orbit) so not revisited it again yet. I'm thinking I might try an do a few launches on different profiles with each new ship I build and see how I can refine my designs. I think it's still more about the gravity losses, by reducing the throttle I'm making the burn last longer,, so it's increasing the horizontal component of the burn while reducing the vertical component.

Looks more Thunderbirds than NASA

Yeah but you should be able to throttle back a bit to maintain a temperature, and as the altitude increases the skin friction will reduce and you can speed up again. KER gives a nice read out of critical temperature, as a percentage, of the part closest to its maximum temperature, but I don't think kOS can access it.

I used to throttle to limit MaxQ in earlier versions of KSP, but my understanding now is that it doesn't matter all that much as the drag is much lower in more recent versions. I've not messed about with it recently although it can be useful for keeping really draggy payloads stable. Interesting point on pitching down, but on my current profile I'm only a few degrees off horizontal once I hit about 35-40km. I guess that would be pretty easy for me test the same way by pitching to horizontal once above a certain altitude, the deflection would be fairly small but could make a big difference to the burn time, thus reducing gravity losses a bit more. As for heat, I don't think kOS can monitor component temperatures so the only way to it automatically would be to have a thermometer somewhere near the nose. Although as it's related to skin friction and convective cooling presumably it's going to be related to dynamic pressure, but I have no idea how much heat it would shift through convection to the rest of the ship. I was starting to think that might be an idea too, however I'm not sure the best way to do it. Uploading a stock ship for people to try and get to orbit for the least fuel consumption would mean the ship is optimised for the profile I fly in terms of TWR and dV per stage, but easy to compare as you just measure the amount of fuel remaining. But defining a payload and having people build their own ship means people using different engines so much harder to compare, can't just go on dV as it's going to depend on the altitude the individual engine starts at.

Interesting, I'll have to look at what speed mine was at when the first stage burned out, and when it started throttling. I found it throttled back to about 1.4 TWR and on a version that didn't have enough fuel in the second stage, the third stage with only about 0.2TWR wasn't enough to keep the AP at away. I'd guess you're a bit higher or faster than me when you start throttling. I need to try the same experiment with a bigger first stage and lower thrust second stage, and I'm now wondering if I need to be logging a lot more parameters to see what else effects it.

Yeah, it's a relatively small difference, however this is for a pretty small rocket, the payload was probably not much over a tonne. I need to experiment with wider and heavier rockets when I have the parts. Bigger rockets tend to have less drag loss but I'm not sure about the gravity losses, and my gut feeling is the saving from throttling should be bigger the more overpowered the rocket is. I'm thinking launch at TWR of 2 for a first stage that runs long enough to get the Ap out to 50 seconds, and then a sustainer stage that starts at maybe 1.5, which does seem to tie in with a few comments on staging threads I've seen on here. Dunno if @GoSlash27 is still about but I seem to remember he had some pretty complex design spreadsheets to work out his optimum stage TWR and burn times. however the TWR is always going to increase so even an optimised 2 stage design might still benefit from throttling. Once I've unlocked the Clampotron Senior and Vector engine I tend to use VTLO SSTOs , which are obviously massively over powered in the later stage of launch so this could save me quite a bit of fuel.

I'd always assumed throttling back was inefficient too but it appears that isn't the case. Both approaches are still doing a gravity turn so the only steering losses are in the initial pitch over, done at 30m/s. After that it's flying at 0 AoA except for minor yaw course corrections to ensure its pointing East. Presumably throttling is reducing both the gravity and drag losses as it's moving some of the burn to later in the trajectory where it's more horizontal and the atmosphere is thinner. However a better optimised rocket is always going to be more efficient than carrying engine capability you're not using. This is a pretty basic design (only 4th flight in a career game) but I think this has shown me I need a longer burning first stage and a lower powered second stage. But even with a better optimised rocket it looks like throttling should still save a bit of fuel as you can never design it for a perfect trajectory.

My standard launch profile is to tip over a few degrees when I hit 30m/s, and then follow prograde until the Ap hits 80km. However deciding what the initial angle should be is something I've never quite got a handle on, and will presumably be a function of TWR and drag. However most guides recommend using the throttle to change the trajectory and try and keep the Ap a set time ahead of the ship. As I'm using kOS my launches are easily repeatable so I thought I'd have a play. This is all with the same ship, an early game 3 stage craft intended for a Mun flyby that is just starting to use it's 3rd stage as it circularises. I ran a range of turn angles and noted how much dV was left once it has circularised at 80km, then tried the same thing but controlling the throttle so it stayed a set time behind the Ap until the ship reached 40km, where it put the throttle to full until the Ap hit 80km. 9 degrees and 40 seconds overheated and exploded when it throttled up at 40km, and 9 degrees and 45 seconds got pretty hot, so I concentrated of 50s. 11 degrees and 45 seconds, but with the throttle up at 50km instead of 50km, gave the same result as 11 degrees and 50s so not much advantage of 45 over 50. My big takeaway from this is that throttling back achieves the same orbital dV as a much more aggressive turn angle, so can be used to give a safety factor. It's also interesting that it seemed to spend a lot of time at at TWR of about 1.4-1.5, suggesting that could be a sensible design TWR for a second stage, when the first stage has enough power to get the Ap far enough ahead. Now I just need to come up with a way of estimating a sensible initial turn angle, but initially I think I'm just going to launch everything at 10 degrees as a reasonable compromise.

I always stick it on top and put the dish in a service bay, although I usually launch a survey scanner as part of the same mission as a trio of kommsats, so the kommsats have a big dish to communicate with Kerbin, and the scanner only needs to be able to talk to the kommsats.

I found the controls for winglets gets it all wrong when flying backwards. In the end I mounted my winglets backwards and disabled them for takeoff, then enabled them for landing where they worked correctly. Mine are above the COM when descending though, not sure if that makes a difference.

Might be worth taking a look at the Kerbal Joint Reinforcement mod. Although there seem to be 2 different versions and maybe some kind of spat going on between the mod developers/fans.

I took an "illegal" loan of 5000 kredits! I nearly bankrupted myself in a new game and didn't have enough money for the mission I wanted to fly (mun flyby) after upgrading the tracking station. So I just Alt-F12'd stole 5k and gave it back after the mission.

You can adjust the funding settings in career so that you do have an incentive to design for reusability. I usually switch to SSTO's as soon as I have the Clampotron Senior and Vector engine. However some people find that a bit grind-ey so aren't so keen. Personally I like the challenge of the early game being restricted in parts, and like having contracts to give my game direction, but completely understand why others prefer sandbox. One of the mods in RO allows you to invest in "tooling" that brings the part cost down, so regularly used parts can be made more cheaply than stuff you only use occasionally. Might be worth a look if you've not played with it

Career only for me. I've occasionally dropped in to the sandbox to test something but generally my testing is in my career game and I just go back to a save once I've got whatever it is working. I also start a new career whenever I upgrade versions, so I tend to spend a lot more time in Kerbin SOI than other planets. In my 1.7 and 1.7 games I didn't even end up setting foot on Duna as I've been spending most of the time working on my kOS scripts.

I spent about 3 hours in KSP last night and didn't build any new ships or conduct any missions. Yet I am inordinately pleased with my achievements. I now have a kOS script that boots when the vessel loads and checks to see if a mission file is saved on the craft. If there is, it displays the data and asks if you want to use it or create a new file. If there's no file or you want a new one it runs through some menus to ask the destination (body), task (Orbit, Dock, LandAt or LandOn), then if you've selected Dock or LandOn it lets you pick a target to dock with around/on the target body. Tonight's task will be add in a lat/long for LandAt. Once the mission file is created it's stored on the vessel for future reusue on loading, along with a code for the current status of the mission, which gets updated as the mission progresses. Depending on the mission status when loading, it then runs through Launch and circularisation. Plan is it will then transition to the selected body and land or dock as per the status file, updating the mission status code and autosaving between each major step so when a vessel already in space loads it knows what it's supposed to be doing, with the option to change it's mission via the menus. This is more complex to write but hopefully simpler to operate (and debug thanks to the autosaves and mission status) than my old system from my 1.7 game that loaded a mission script based on the name of the ship, and had me renaming ships in space in order to get them to conduct different tasks. I'll still need enter a few more parameter's, but I'm hoping I can keep it to a minimum, the tricky one will be trying to derive a suitable initial turn angle based on TWR and anything else that looks sensible for the gravity turn launch, Sadly none of this makes for exciting screenshots for this thread though.