Kass

Ahhh. It's like a whole new world, thanks Did I miss the link for v1.01?

Every time I try to call another program from within a program, KSP stops responding on me. Quite annoying really as I was trying to use the same subroutine multiple times to save on program complexity. Anyone else experience this?

There's a GUI on the city and clouds mod?

So, I've installed these textures and all I can say is, "wow". Textures look much, much, much better. Especially on my game using Real Solar System where the textures looked horrible being as they were, 10x larger than the original. Thanks a lot papics. I've made a few pics so that people can see just how gorgeous the clouds look now. Please note these are using the Real Solar System mod so Kerbin has a diameter of 6,000km, not 600km so in theory anyone using stock sized Kerbin will see this quality of clouds at 10 times lower altitude.

Am I meant to replace the original cloudlayers.cfg with this new one or just add it in the same place so it supplements what's already there? Edit: I just replaced it and it seems to be working.

Just a FYI but this pack is not compatible with PartCatalog. While PartCatalog correctly reads and creates a new sub category for this pack, it only populates your whole mod with 4 parts meaning I have to now manually sort through thousands of parts for me to find out what I have just installed. Sad face: not being entered into the techtree for career mode makes baby Jesus cry!

Wicked! Going to install and report back

That should not be a problem at all. Look at my post about 2 pages back where I basically have every single mod running out there and run at less than 2.5GB without a problem.

Thank you in advance papics. They do look amazing

Are you running 5-3 pingopete?

@KyleofKerbin There is no conflict between this mod and KSPX. None that I've seen in weeks of playing and literally 100's of missions. Checking memory should be your first concern if you're crashing like that. I would also agree about the half res-thing. It comes down to a choice between playing the game with lots of mods or playing at full-res. Also, as suggested earlier by rbray the memory reduction mod is an excellent tool for freeing up memory. Another essential thing for people that don't play vanilla KSP is installing the texture reduction packs for B9, KW Rockets, Squad and any other reduction pack out there. I run with millions of mods, play with texture replacer and city and clouds and am playing on Nathankells excellent Real Solar System mod Shameless plug for an excellent mod so I am regularly building huge 5m rockets and thanks to those measures I have loads and loads of memory left as you can see.

I generally try to make my breaks my exit clause, thus cutting down on the complexity of the programs and making them easy to understand and modify. If I want an infinite loop to continue, say because I'm still working on my uber hover program I do it this way so I have an easy manual break: set deactivateFlag to 0. on AG9 set deactivateFlag to 1. until deactivateFlag=1 { some script }.

I generally find that the craft turns with the same force as would be available normally. So small agile craft turn really quickly and large craft turn like whales. Have you tried doing the manoeuvre manually and seeing how the craft responds and how it relates to kOS' behaviour? Yeah, I've only had kOS a week or so and never coded before that so I propably have no idea whatsoever what I'm doing.

Looks like you understand it, just not sure of the right commands. Exactly. Rotate on the direction of travel set by the previous part of the command. Yep, spot on. Edit: South at 10 degrees from the horizon yes. South at 10 degrees from vertical is up + R(10,0,180). Right again. Exactly. I always use the lock command. The wiki specifically says to use lock with steering and throtle so that's what I do. There other ways of doing it but because I have no idea what I'm doing either, I stick to the foolproof methods. So I would use lock steering to up + R(0,10,180). Only time I've found it doesn't work is when the aerodynamic forces exceed the crafts ability to turn, I use FAR exclusively so performing a 45 degree turn at mach 3 just isn't going to happen Not sure what you're trying to do here. So you're waiting until 0 something? You don't really need to put in an if and break as that is what an until does automatically. You can also word it differently to save on complexity. lock throttle to 1. lock steering to up + R(0,0,180). stage. print "launch". wait until alt:radar >7999. Print "8000". If for example you wanted to check the program was running and cycling, the way I do it is get it to count for me. Handy with multiple If statements and you want to see how the program is working. lock throttle to 1. lock steering to up + R(0,0,180). set count to 1. stage. print "launch". clearscreen. until alt:radar >7999 { print "program check" + count at (5,5). set count to count +1. }. Print "8000". This will count up each time the program cycles through that statement until the altitude is greater than 7999. The "at" part means it will count up on the same part of the screen instead of filling the screen up with numbers. The set count to count + 1 means each time it cycles, it will add 1 to the number there previously. Just looks better and is the first stage of programming consoles for debugging or whatever. See my videos in previous posts for examples of what I mean on the console thing. When the craft gets to > 7999 it will print "8000" and away you go to the next part of the program. Hope this helps

What sort of script are you looking for?

Sorry, not been in, I'll work through your post now.

The up + R system makes sense when you understand how it's working. Basically the centre point of the navball, ie. when the craft is pointing straight up is 0 (zero). The trick is to know that even though that's your centrepoint, mathematically using this you need to work from 90 which at first seems very counter-intuitive. So if you were to input a command that tells kOs to go 90 degrees from straight up, the result is to go along the horizon, along the heading you've set, the opposite from how it works in a plane which obviously sets the horizon as zero and everything else is plus or minus that horizon zero point. So the first number up + R(this one, 0, 0). controls the pitch along the line on the navball that reads 0-180. The second number up + R (0,this one,0) controls the heading along the line that runs 90-270 and finally the third number up + R (0,0,this one) controls the rotation of the craft. They work independently so changing the roll using the third number does not change the way the craft pitches using the other 2 numbers. Angel desired is A. Centre point is 90. So 90-A* either 1 or -1 to make it positive or negative is the number you input. (0,30,180) East at 60 degrees inclination. (-30,0,180) North at 60 degrees inclination. (-30,0,0) Also North at 60 degrees but craft rotated 180 degrees about it's axis. Dunno if that makes any sense.

Ahh, that explains why it only happens the very first time I run the script. Not sure how to correct that though. Edit: no they aren't confused in the script. I've only written the P part so far. I only uploaded half res videos, just to show what was happening. The numbers I'm generating are probably redundant to someone who knows what they are doing. Lots are just debugging points to indicate what part of the script is being used at any time. Am I right in thinking that a properly tuned P controller functions as in my second video? Probably presumptuous of me but I'll pm you my script unless it'd be better to post it here? Thanks for all your help so far Camacha

Because I'm a doughnut. I simply wrote the wrong letter in there. Edit: I've changed the "i" to a "p as it should be, thanks.

I second the using kOS IDE idea. It's a great tool and allows things like copy and paste as well as colouring different bits of your script making it much more readable. I generally do all my programming in the archive in stead of the local volume using kOS IDE. As soon as you hit save in kOS IDE that modified script is available in game. So for example you change a parameter in kOS IDE and hit save. If you're already in the archive you simply type "run <progname> and kOS will run the new code.

Hey Camacha, thanks for replying again. I'm trying to write a full PID just to learn them. However I am doing it one step at a time, so first a P, then adding in the I and finally the D. I'm trying to get each stage to work properly before moving onto the next. That way I can make sure I fully understand what I'm doing and then I'll be able to write them for whatever I wish (in theory). I've wrote, what I think is the p section of the PID. I have an if statement for above my setpoint and an if statement for below. The algorithm only works when I set Ki to a negative number. It seems to be slightly tempermental though. I can run the program and it'll work in one way, then run the exact same program again and it'll work slightly differently. I've made some little videos that I've posted below to show exactly what I mean. That's the same program. I ran it. Broke into it, then just ran it again.

Method B is by using a PID controller type algorithm. This is a considerably more difficult and I haven't yet figured it out. Unlike method A it allows an analogue input on the throttle that scales to the speed required as opposed to the digital input of method A, ie, instead of the throttle simply being on or off it will increase or decrease the throttle by the exact amount required (when tuned) to achieve whatever variable you set in the program. Now I've started writing on of my own but I need a couple of pointers from those who know what they're doing (please ) Basically I've wrote a program with a section that basically says lock throttle to P. until ship:liquidfuel > 15 if setpoint < alt:radar + verticalspeed { set error to (setpoint - alt:radar)*1. }. if setpoint > alt:radar + verticalspeed { set error to (setpoint - alt:radar)*-1. }. set P to error*TWR. }. Now my problem is I think I only half understand what I'm trying to do here and if someone could explain this to me I'd be very grateful. Basically I'm doing P = Setpoint - error*gain. Through trial and error and debugging I realised that one of the gains needs to be a negative number to turn it back into a positive for input to the throttle while the other needs to remain as a negative as I don't need the input as it would be above the setpoint. My problems are I don't understand what the rest is trying to achieve. The gain I've set at 1 just because I don't understand it and therefore I change the input to a positive from a negative without affecting the output of setpoint - error.. I also put a gain on the other half of the algorithm just to keep things equal. What is this number doing please and why? Now where I've set P to error *TWR I've only done that so it scales with the vehicles mass, but I know it isn't right. What this is doing is applying way to much thrust and my debugging console is giving my a result of infinity. in the picture below you can see that the P number is infinity. Where am I going wrong here please and most importantly, why? What am I trying to achieve here? I really want to understand this and I feel I'm almost there (otherwise I'd just use mechjeb or copy and paste someone else's script). Thank you in advance Edit to explain values. vertical speed = verticalspeed hover timer =1 cycle of the until statement +1 to a value I set to make sure it's cycling current error = setpoint - alt:radar*1 or setpoint - alt:radar*-1 depending if if above or below the setpoint. previous error is the error previous to this that is set to perror at the end of each cycle error difference = error - perror Proportional = error*TWR Throttle = throttle Height offset = setpoint - alt:radar Edit 2: wtf is wrong with me? Writing scripts is fun!!

I've found that constant velocity can be achieved on of two ways. Method A is quite simple and is simply based on reading a variable as being true or not then assigning an output. For example: (Please comment if this is wrong at all. I'm literally learning coding as I go along just to play with this mod so any input will be gratefully and gracefully received) set g to 9.81. //gravity in m/s// set TWR to (g*mass)/maxthrust. //this should set up the throttle so that it achieves just enough force to counter gravity and scales as fuel is burnt// until ship:liquidfuel > 15 // The stage:liquid fuel doesn't seem to work for me, don't know why. Tried testing it with print and everything lol.// { if vertical speed < 130 { lock throttle to 2*TWR. //for a 2g burn. change the (changing the multiplication factor should change the g at which the burn is performed)// }. if vertical speed > 150 { lock throttle to 0. }. stage. If I'm right this means the throttle will bounce up and down within the selected speeds. It doesn't account for drag but on streamlined rockets vertical drag should be minimal anyway. There will be some overshoot but it's quick and easy to program. Should work for almost anything and takes 2 seconds to change for all ship types. However it's not good enough for what I'm trying to do so I've moved onto method B.

Thanks Camacha for the great answer, + rep for you . I'd seen the raised to the power stuff in other scripts but never realised these were one and the same. Hopefully some of these equations will make more sense to me now. I'd never realised how maths heavy coding could be. Definitely looking at the whole area of computer coding with a new found level of respect.

Sorry if this has already been asked but what does the "^" symbol mean? I've seen it in a few example scripts and have no idea. Please be gentle in your explanations, I've never coded anything before, although I'm currently trying to write a PID script for my skycrane (and failing). Thanks in advance I totally love this mod. My install with KOS, RT, RSS, FAR, ScanSat and a few other mods takes everything to a whole new level.