Payload

Oh no. It in no way sounded snooty. I was referring to other issues that aren't important. I didn't update once I heard of the parsing errors in .80. For now I hope you kept your .70. DL around. It is what we will have to use until this gets sorted. I really wish that the menu would work too. It seems that having programs run reliably when executed by another is not a top priority. I fixed the recursive ON statements here in my working copy and it had no effect on the stuttering so something tells me that isn't the whole issue. I also have a better way of locking TWR that is much faster and isn't loop controlled. I will roll those updates out once I have had a chance to test them some more. Probably tomorrow. Today is my birthday so I am going to take some time off video game things and spend some with my wife. I will update the first post to notify that we need kOS .70.

As far as I am concerned I am not using it wrong. There is no right or wrong way to use something that isn't documented. That is the issue with this mod. Always has been. Absolutely zero documentation. My error is thinking this is a scripting language. It is reported to be but it isn't. It is a super verbose lower level language that reinvents the wheel yet again. I would prefer a compiler if I am to be doing everything in such deep level. I would prefer consistent code base that works from one version to another. I should have gone with my first instinct of thinking that this would never really work correctly. It wont. It's too much work for the author to actually make it useable as a scripting language. I see what the issue is with the ON operator. It requires nothing more than a simple IF statement to halt until next input. Essentially making it a run once operation that is flagged when a new input poll is required. It wasn't added at the time because the speed of kOS was much lower. It didn't have time to stack up. It just wasn't an issue then and it only causes a bit of stutter for me even now. Only when I run in windowed mode. It doesn't have to be that way. It just so happens that it is. The fact that it stacks up on itself is not an error of it's usage in a script. It's an error of how it is parsed. It should not be up to the script writer to ensure that the command doesn't set duplicate triggers. If I wanted to be bothered with those sort of things I would use a much lower level API with proper documentation and a compiler. I haven't tried it. There is supposed to be v0.82 out according to Kevin. I haven't looked into it. I have been spending my time writing a landing script since no one else wants to help. Every one is a critic but no one wants to put rubber to pavement. To tell you the truth I am starting to lose interest in this project. I had hoped other people would join in but they seem more interested in mocking than actually doing anything. Apparently the peanut gallery is restless. I have been staying low key for a while and just trying to grind on with the work. But with the latest update jacking my programs up yet again on top of being insulted in a github bug report of all things, it is coming to a head. I just don't enjoy using kOS anymore. I still do feel like it is important to continue. Others want to turn this into yet another way to feel superior to fellow humans and are holding their cards close to their chest. It seems everyday they insist on making operations ever more complicated rather than ensuring that a larger number of people who enjoy KSP have a chance to enjoy this mod as well. Enough crybaby from me. I'll get to work on fixing the action group polling script. I can't see that taking more than a few minutes. Now that I know that there is a problem with it setting the trigger over and over it's a simple fix. I think I am currently using version 0.71. I will hold off on the update until the parsing issues calm down. Kevin seems to be in the process of changing how the parsing is done. It really needs it also. It was beginning to cause other problems. Once again I wish to say what I have said many times already in this thread and I'm sure I will have to say it again many more times. I do not claim that these examples are bug free in anyway. I make no claims other than It appears to work. For the time being. If you know of a better way of doing something, I would appreciate if you would make some attempt to contact me in this thread with a concise explanation. I prefer to get my bug reports here rather than having to read them on KOS guthub with nasty statements attached. I don't think that is too much to ask.

set atmP to 2.718^((0-altitude)/5000). set atmD to atmP * 1.2230948554874. Atmospheric pressure and density. http://wiki.kerbalspaceprogram.com/wiki/Atmosphere The formula below will give you the force of drag at velocity. You will have to do some additional computation if you want to include a deployed parachute. The cD will change then, it wont be just 0.2. Fd= 0.5 * atmDensity * (velocity)^2 * 0.2 * (mass*.008).

Yes I noticed the new update does make my KSP chug a lot. I can tell you one thing for sure, you need to get out of the habit of using until 0. In lots of computing languages, that is a way that programmers use to leave comments in code. It depends on the compiler, but it generally means ignore the following. Set a variable called Done or whatever to 0 and then..... until Done = 1 { Do these things. }.

HAHA I had no idea that is what FACING was for. I have just been inserting user input halts and prompting the user to select an action group when the correct attitude is achieved.

As I sit here in Pensacola, Florida, something tells me the answer is 100% yes.

You want to go West right? lock steering to heading 270 by 20. Usage: lock steering to heading [b]X[/b] by [b]pitch[/b]. Not sure what that is going to do with the roll. You may need to use the harder method. An example of that is in this post. http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-65?p=650207&viewfull=1#post650207 That example doesn't include roll but it isn't that hard to add.

I did add OR if splashed. I was also having trouble with my suicide timer being off because of drag. I added the drag calcs and now that is perfect. I've got it where it will land any rocket with a TWR of greater than 1.5 from an altitude of 500m or greater on Kerbin. I haven't tried bodies with out an atmosphere, as my current program assumes a lot of things. I am tracking radar alt by setting a terrain height. So one problem right off the bat will be landing angle. I think I might setup a low pass and then increase my pitch to keep my vertical speed at zero until my horizontal speed is 0. I also have a lot of constants to replace with variables so they can be set by a script that is run at the beginning of the program. I also haven't tried running my scripts from the menu yet in .65. It still didn't work in .61 though. I know it sounds like a silly request, but can we get a group setting to either de-focus the kOS window or can we get kOS fixed to not default to physical warp when the window is focused?

Well, I have a chicken and egg question. How the heck are we supposed to know the height of our ship? Don't tell me check before lift off. That is easy enough and it doesn't work if your launch clamps are tall or if your ship is taller at lift off than landing like almost all of them are. It also doesn't work if you are landing a ship form orbit. You can get your height over terrain if your steering is locked to up and you subtract radar alt from altitude. That only fixes the landing over water problem. It still doesn't tell you how tall your ship is. It tells you how far your kOS unit is from the ground. I have tried to check against status, but it doesn't seem to work either. Maybe I am doing it wrong? Not really any working examples of that anywhere. O.K. I got if status = "LANDED" to work. That must have been fixed since I last tried. That also opens up the door for a whole lot nice things.

It works just fine with 6.5 in my testing. I will update the front page.

I don't know that it's a bug causing it to use 3.4gb of memory since I caused it purposefully to see what it would take. I just loaded up my parts library to see what it would take. That was it, 3.4Gb of ram. I do know that the game SkyRim had no support for more than 4Gb of memory at first and peoples mods where way over that. So someone made an unofficial patch that allowed it to use more. So utilizing PAE in a user space program is done. If I am not mistaken, it was as simple as a compiler flag. The game developers subsequently compiled the newer patch with the flag and we didn't have to use the unofficial exe any more. I would like to express that even with the mods that I have, I have not had the game crash from using too much memory. I had to do that on purpose.

Speaking of cardboard. You don't need any fancy materials at all. You need fiberglass epoxy from the auto parts store and some cardboard, a bit of tape, maybe some glue. Build your prototype to fit the base that you have decided on. One you cut out of cardboard. You can then fit each piece to the hardware and make sure it's all even. When you have the holes all right and and it looks good, you soak the thing in the epoxy. I have built speaker boxes out of cardboard before. Look up SONOTUBE. It's a sub that is made from a concrete form.

I think you should. Some people don't really have a grasp of what the difference really is. The real difference is addressable memory space and increased precision speed. The level of precision doesn't change, the speed of it's calculation gets faster. Simply referring to programmable hardware, since that is what I have the most experience with. The 8 bit processors that I commonly use have no problems preforming 32 and 64 bit floating point. They would be invoked in any number of ways such as declaring the variables as a float32 or a float64. The problem is it takes more time to calculate because the processor is only 8bit. There is a minor speed boost to be had but it isn't huge and most programs don't require the use of quad floats. The main difference is the addressable bit space. IMO that wont be nearly as big of an issue once the game gets a little optimization. To be honest, the vanilla game isn't close to blowing the limit yet as far as I can tell. It's the fact that we all like mods and there are so many good ones. The main issue is texture compression. Or rather KSP's lack of it. Solve that before we worry about addressable space. EDIT: about PAE. I would assume that KSP uses that, but I have 8 gigs of memory and KSP crashes at 3.4 gigs every time.

If you are programming for each ship you fly you can take a lot of shortcuts. I don't know why you would want to get all of that into a single file anyway. I'd say that might be possible but not sane. If you want something more agnostic then you will quickly find that you wont be able to fit everything in to the 10k limit. Launch to orbit script from space computer is over 7k with comments. I really don't think the limit serves any purpose. Since comments count, nearly a third of the space is consumed by them alone. The language is also extremely verbose. That doesn't help. The limit needs to be more like 64k.

Excellent, that is why I have been using V() as it is. I noticed that you can use R(180,0,0) + velocity:surface to get the correct heading but I haven't been able to get pitch out of it. It seems now you cant use pure V() unless you have something that is rotation based first. I also wont let me add more than one vector and velocity surface is expressed as a vector. I think those are current issues that Kevin was talking about in his blog. However, if you are getting prograde by multiplying the vector to an empty R() set, do you think it is possible one could get retrograde by multiplying by R(180,0,0)?

Oh no he is right LOL. My craft was just wind veining. HAHA I guess it's good to know that works! It works too well at that. I must have done 100 plus diversion tests! EDIT: OK I'm pretty sure I have it working now. Just give me a second to make sure I'm not trippin.

Works just fine here. Been using it all day! I have diverted every direction under the sun too. You sure you don't have a control authority problem? I noticed when you do that, the control is really slow to respond compared to just setting the direction in a normal way. It does get there though. I guarantee it. Add some reaction wheels to your craft or maybe some RCS and try again. Hmm maybe my craft was just wind veining? I'll screw with it some more.

Hmm Not sure what is going on there. I was thinking about switching over but for now I've been using the V() system with R() to set roll. It's dead on every time. EDIT: Have you tried setting the rotations first? lock steering to R(0,0,180) + heading X by Y. On a side note, I've been doing diversion testing. So I have some info to share with you all. Setting your steering to the retrograde surface vector is dead easy. lock steering to velocity:surface + V(1,0,0). You can use just surface speed as a check for re-orientation. when surfacespeed < .001 then lock steering to heading 0 by 90. You will need some kind of accurate hover script. I guess you could wing it if you really wanted. When you setup your hover script, make sure you set a variable to mission time at the beginning of your loop and set another variable to mission time at the end. You will need to add the loop time into your TWR calc our you will always be over 1.

I don't believe what you are talking about is possible right now. I'm pretty sure that that is where we are headed. For now you need to have plenty of antenna on your ship and switch to it and copy code from the archive. Then you can run it locally. I would not be surprised to see what you are asking for eventually. The new remote link additions seem to be heading in that direction.

It's hitting the fail safe secondary MECO condition. Remove that and it will at least attempt to circularize. One of the issues is the calculation I am doing to set the injection burn is close but no cigar. It is an approximate value of how long it will take for you to make the burn. The more elliptical your orbit is, the more error it will incur. It isn't to hard to actually do the right equation. The variables are all there and correct. I am just short cutting the calc because the Law of Conservation of Angular Momentum ensures that as long as the orbits are not ostensibly oblique, the timing will be accurate to an extent that satisfies the purpose. Removing the fail safe MECO condition will get you a whole lot more circular though. You may have to adjust your primary MECO condition.

Couldn't tell ya what is wrong honestly. If I knew, we wouldn't have this problem. Also you don't need the "wait until orbit = 1." That section cannot run until orbit = 1. That is handled by the injection control. It already waits until then by default. You just simply run anything you want at the end.

I bet you called your program in the area that calls the Splash screen. That is the problem that code was written a long time ago and I haven't bothered to go over it and comment it because It wont work for now anyway. Set the splash to 0. Then the program wont try to run it. if index = 0 AND selection = 1 { [b]run a1.[/b] wait until ready = 1. }. Those sections are where you setup your program calls. The splash is specifically for running the splash screen.

I don't know if the terminator means what I think it does. If I remember Kevin right, he was going to add a way for people to set the terminator to something other than full stop. So TERMINATOR <;> would be a way to describe using a semicolon instead of the full stop. Call is a command that is to be used specifically with other MODs. There is a way they can register with kOS and then the terminal can interact with them through the CALL command. See the videos posted by Sirkut earlier in the thread.

I'm saying if you try to run the launch to orbit program form the menu like you would expect, the program fails to control Steering and throttle. You can try it for yourself but I am not the only person who has reported it. You can see there where I even put the menu on hold, I've tried exiting the main loop right after the run call... Everything. The first program running is the only one that can control steering and throttle. Until we get EXIT AND RUN or some kind of equivalent, or this steering and throttle control issue is solved, I am afraid the menu system is DOA.

You can't be focused on the kOS window or the action group triggers don't work. Click outside the terminal and they should work. Also the names don't really matter anyway. The menu system won't actually work until we get the command EXIT AND RUN. KSP wont close one old program that calls another even when that program has ended. It keeps any other programs from having steering control and throttle control. You just have to use run for now. I also haven't posted half of the things that are rolled into the menu because at this point they wont work. I keep forgetting to include the splash screen. Because it doesn't actually do anything but look pretty. HAHA Kalista, I can't believe you got that thing into space with FAR. Also I think you lost part of the launch escape system on stage one sep there. That's OK Jeb is too much of a man to use it anyway.