Payload

Time warp is really simple. You just don't allow it. Why would you in a multiplayer game anyway? If there is a dedicated server running it, you can just leave and it will put you on rails like a time warp but at normal speed. You come back when you need to do a maneuver. And you now have control of your entity again. Or you could go back to the VAB to build another. Or you could make a car and go to Kerbtown.... See what I'm getting at? There is no need for time warp. People get really creative about ways why something can't work. They need to put that energy into thinking up ways that it can.

Not if you wait until the right time to launch. You just never circularize and head directly there. Like he said, if you time it right, it's not that hard. The timing isn't super critical either. We do need keyboard input. Even the Apollo guys had to enter in parameters for correction burns. The correction burn for free return is going to have unknown parameters. from 100k orbit, it takes roughly 837m/s of dV to reach the moon. For free return it will take slightly more since you will want to leave slightly earlier than normal. I guess if we are hand setting the node it should have no problem doing the burn with the data we have available. We can lock steering to node and burn until we have the required orbital velocity. We do have access to time and mission time. I can see no real obstacle in the way of making it happen. May not have as much info as you would like, but you have enough. I have had problems getting things to trigger on = and I'll tell you why. Polling time. It just misses the 0 crossing. I have had much more success with "> target" expressions.

Everyday this isn't released I die a little more on the inside. This thing is awesome. I absolutely cannot wait. This shuttle has a date with a hands off orbit injection courtesy of kOS programmable flight computer. Great work.

I don't know. I have just been sticking with the up nomenclature for now. It certainly isn't initialized to R(0,0,0) though. I know that much. It's R(0,0,180) unless you flip the ship in the VAB to have the side that normally faces you in the VAB pointing North on the pad. My current project is at the point were I need to use an external editor. I need to cut the fat and move direct figures out into variables so I can manipulate them. I have already removed 90% of the waits and wait until in favor of when then and until loops. Some small waits will be required for specific tasks but overall, I've gotten most of the CPU halts out. I have big plans for this baby and I can't have waits eating up my processing power. I suppose I could use a timer instead of the waits and cut even those out. But they are in time critical areas and none of them are in the main loop. The longest one is a half second I think anyway.

Guys you can force copy to the archive file! copy program to Archive. As a matter of fact. All of my scripts so far copy to the Archive automatically when they are run just by adding the line above first in the script. That way you can just edit it. Save it and then run it. If it doesn't work or you want to make changes you just need to revert flight and copy it over from the archive. copy program from Archive. It works great. I really do want to be able to use an editor though. It would be so much faster and easier when I need to move blocks around or copy them.

Woot! Also I managed a very mechjeb like apoapsis hold and Circ burn in my latest rocket script prototype. when apoapsis > 99999 then { lock throttle to 0. print "Waiting For Apoapsis". until altitude > 69500 { if apoapsis < 99995 { lock throttle to .05. }. if apoapsis > 99999 { lock throttle to 0. }. }. }. when eta:apoapsis < 1 then { lock throttle to 1. print "Orbit Injection Burn!". }. when periapsis > 80000 then { lock throttle to .1. }. when periapsis > 99000 then { lock throttle to 0. wait .5. sas on. toggle ag1. set orbit to 1. print "You Are Now In Orbit!". }.

I think maybe you were reading more into it than was there. I clearly stated that it was unqualified scrutiny for the sake of ease of use. It in no way will affect the use or performance of the software itself on any kind of level. It's just a preference. That is the problem with text. Also I don't think you read my post where I said I love this thing. About the angle preference, that is just a peeve of mine personally. FYI. I once wrote a letter to the Discovery Network asking them to at least educate their Narrators on the difference between an Internal combustion Engine and "Motor". I don't mind if the Igmos on the shows call everything a motor, but the show narrator should know the difference. Certainly for a show on the Science Channel. In the end the same thing is happening anyway. How about being able to initialize a preference such as vector absolute. or vector relative.? Just for clarity. My criticism wasn't anger. It's just criticism. As I said already, I enjoy this mod a lot and hope it continues to develop and become more friendly to use.

Radam, did you have corrective steering enabled?

I agree with this assessment. This is the correct action as I see it. If your ship is fast/agile enough, then the old way is fine. If it isn't, then you are SOL. Currently getting the very best out of the auto pilot requires supervision. It is also very difficult/impossible to do hands off space plane orbiting. The problem is the constant best fit angle and single acceleration target. Consider the following as a crude example. If we could click on the picture and add POIs at determined altitudes, we could then set a target angle and target acceleration and an action group or groups to be executed when we reach that target altitude. Different systems have different flight parameters as can be seen through the differences in High TWR Rockets and low ones or Rockets VS Spaceplanes. With a system similar to this we could literally fly anything, hands off, into space.

I really enjoy it. So far, it works quite well. I don't think it will be the thing for casual players. For me it's exactly the thing my rocket OCD needs to make every last thing perfect. I hope to setup a mission using it. I wonder if it might be possible to do a fully autonomous mission with it and kerbal alarm clock somehow. Please keep going. However unconventional, it works. When we get support for the rest of the resources I think a lot more could be done. It is possible to orbit a space plane with it as it stands. Once you have done a manual flight you pretty much know the mission parameters and not having access to intake air wasn't really that hard to overcome. Is there a possibility that there will be some way that we can store to plain text files in the future? I did a little editing in the arc file just to see what would happen. It mostly worked. Mostly. something like makefile name. It would be so much easier to use with external edit capability. My simple spaceplane orbiter. clearscreen. lock steering to up + R(0,0,-90). lock throttle to 1. print "Throttle Up". print "Begin Countdown". wait 1. print "3". wait 1. print "2". wait 1. print "1". wait 1. print "0". stage. wait 10. stage. wait until altitude > 9999. lock steering to up + R(0,-55,-90). print "G-Turn Begin". wait until altitude > 14999. lock steering to up + R(0,-65,-90). wait until altitude > 20000. lock steering to up + R(0,-80,-90). wait until altitude > 28000. toggle ag1. toggle ag2. lock steering to up + R(0,-75,-90). wait until apoapsis > 99999. lock throttle to 0. Print "Waiting For Apoapsis". wait until eta:apoapsis < 5. lock steering to up + R(0,-90,-90). wait 3. sas on. lock throttle to 1. print "Orbit Injection Burn!". wait until periapsis > 96000. lock throttle to 0. print "You Are Now In Orbit!". The plane is launched like a conventional rocket. You will see in the script the time is allotted for engine spool up before staging the clamp. I wouldn't be too much harder to make it take off of the runway like a conventional aircraft.

The whole ascent autopilot needs a revamp anyway. It's only just descriptive enough that the operation can be carried out in a repeatable way. It is far from optimal. Here is to hoping that one day we can actually use that nice graph to plot our ascent. What would be really nice would be to be able to click and add points on the graph and to be able to plot our course if you will. Currently we have to give up gravity losses to gain aerodynamic efficiency. That of course will always be true but there is much more DV to be had on both ends. The current system only allows us a best fit to the middle of the efficiency range.

This is not a human. It is a computer calculating vector sum! The term Horizon is meaningless. I could care less what sort of convention is used by the pilot or the informational display. The actual math uses 0-359deg. We are talking about programming a computer here. Not relaying information to a human. Negative numbers being used to describe vectors to a mathematical calculation machine is not correct. And "the rest of the world" is certainly not the truth of the matter as any mathematician will tell you. Those are values made up in your head. They do not exist in reality. The flight computer in that plane you fly has no understanding of the terms you use. So because you are a pilot we are expected to believe that you know and understand how to program the flight computer?

Ugghh that is to keep people from having to do head math when they are flying equipment. It's there because humans are not computers and there are much better things for ones mind to be occupied with when flying or navigating a vehicle. For a computer doing math, 0-359 is the correct and intuitive term. Furthermore, you would say that you where in a 80deg attitude. Your reference, is in the towards gravity direction.

There is no negative. What about that do you not understand? A circle has no negative degree. Values between 0 and 359 are acceptable. Furthermore the term "downward" is absolutely meaningless as it describes nothing. -45 downwards is just 45deg. -80 downwards is just 10deg.

No that is 0 or 360. There is no such thing as -90. If I want to go 90deg opposite vector I would subtract 90. Having negative values as a default is a problem and is counter intuitive to how the system actually works.

The first thing is easy to do. If you can't add it yourself to the part config on the control modules then you will never be able to write the script anyway. As for wanting it integrated with remote tech.. As you say "seemlessly" or rather seamlessly integrated into another mod is a lot to ask. This is pretty far from that at this point.

I played around a bit last night and successfully programed the computer to autonomously orbit a simple rocket and a space plane. It does work quite well. That is the good bits. Now for the over arching critique. 1. Can't write programs seamlessly using float values. There are reasons that certain conventions are used. Refrain from doing things "Your Way". As much as you might think it's cool, using full stop for EOL EOS is a tragedy. 2. No access to conventional statements and loops is another big issue. Again, just because you want to make an "Until" loop and not a "while" loop does not make your system cool or eclectic. It makes it hard to use. 3. No conventional ASCI text based editing. Forcing me to write code in a little window inside of a game is not what I would consider conducive to learning nor does it exude time frugality. It is also causing problems with data retention. 4. There is no such thing as -90 in a vector based world. It doesn't exist. I would like you to show me where on the navball it says -90. Values from 0-359 are what we should be using. 5. PID is terrible. No doubt about it. The PID drifts something fierce. When I tell it to lock a vector I want it to stay there. Not drift wildly away after some seconds. It needs to be checking if it is actually at the point on the navball you have set it too. Not just going there and locking the controls up. Those are huge things. They have to be fixed for this to be usable by anyone without hardcore programming experience. Finally, I have to ask for what reason have you considered writing your own scripting language in the first place? There are many examples of these like LUA that expose most of the useful environment and solves most, if not all, of these problems. I understand doing things for your own educational betterment. I just don't want to be subjected to it. If you expect others to use it, it has to follow convention. As it is, I could write code in C faster that I can use this scripting language.

HAHAHA. Best Movie Emilio ever made.

They work that way on purpose for balance reasons. Make your turn earlier and get more horizontal speed. I actually try to keep about 100ms vertical acceleration as I get close to orbital velocity and try to postpone the switch as long as possible. What your fighting is drag at that point. Try to maximize your speed just as the engines run out of air.

Dumbest thing I have heard in a week.

Because it was analog. You might get a pop or a hiss but you won't lose everything. With computer data you really can't lose anything. The longer that tape is in space, the worse the data rot will get. I'm not really sure what relevance the size of tape makes in this comparison. Tape media is a poor choice for space travel. Reprogramming your flight computer in space is also a terrible idea for numerous reasons. I wouldn't like to die a quick but violent death because Bob went mucking about with the landing routine and left out a zero somewhere.

Nope there are two kinds of rope memory. ROM and RAM. What you see the ladies making in this film is non-volatile. The volatile types used a few more wires to control the magnetic field. That requires electricity to store memory. BTW, ROM is non-volatile storage. RAM is volatile. The programs and mathematical constants were hand woven into this storage medium. Temporary info was stored in rope RAM and most notably, actual notebooks to be re-entered in-case of a main computer power down. That only happened one time to Apollo 13. There is no need for any real writable storage on a guidance computer. It's nice but most certainly not required. In many cases it wouldn't even be desirable. A tape, as it were, would serve no purpose besides adding weight. In space, the magnetic region on the tape would be corrupted in short order.

They aren't damaged. You have one of them the wrong way around. That is why we ask for pictures. You will need to flip the one on the lower portion of the ship around.

You have to have a forward facing control unit. The pod it self needs to be aligned on the horizon or you can just slap a docking port on the front and then click control from here. It has never worked with the control aligned on Z axis.

What? No braided memory? How dare you sir! I am thinking we don't need so much non-volatile memory as a tape drive. Lets just say that the programs and global values are hand woven by juvenile kerbals in vast factories called "Fun Zones" that most certainly don't resemble anything like a sweatshop. You can have a peg board looking thing. The old tape drive is played out and not as cool as woven memory. BEHOLD!