Payload

Then why is the pack size 100x bigger? Obviously that full 700MB has to be loaded into your system memory at some point before the game software can process it. Whatever small gains you are getting from loading faster isn't worth the 100x size on disk. If one has to lower texture detail to play KSP as it is, then one is in the minority of people who don't have a contemporary video card. I doubt that whatever gains you get through lowering texture detail will fix the fact that the computer isn't equipped to play video games. So, yes I keep not getting why this pack has to be 700MB now when the 70MB version I had, is working just fine.

No I think I understand. That is exactly what I said. So now your pack is 100x bigger to speed up loading times. I don't reduce the texture detail anyway because I have a video card that was made in the last ten years. I think most people have the spare 70MB of video memory. Seems like a lot more people will not have a spare 700MB of physical memory VS the measly 70MB of video memory. No offense intended, but if the old textures where 70MB on disk and 70MB in memory, then the new change is only affecting loading times. It also looks like the full 700MB of version 4.0 is getting loaded into memory briefly causing some people to actually have memory problems. So I have a hard time understanding the reason behind the change if the game software isn't going to handle it correctly until .23 anyway.

I am confused here. So I have version 3.3. It works just fine. Your new update is 100x the size for what reason? I don't understand. It seems to me like you said it was because of loading times. 3.3 loads with the same speed it did before. 700MB VS 70MB is not worth it no matter how fast 4.0 loads. Now keep in mind I haven't actually tried to use any B9 parts since the update. I have been messing around in career mode. Are they broken in anyway in the regular sandbox mode? For me the loading time isn't that bad. So if it is only the loading speed and the tech integration that is different, then I think I will wait until .23.

You can. Check the action groups for the antenna. There is one for transmit there. I don't know about stopping it, but it auto resumes when it has enough power already. The only issue being that you might need some power to maneuver your space craft. If that is the case then just don't transmit until the maneuver is done.

Yep, using it more, it seems the problem comes and goes with no real reasoning. I checked to make sure my issue wasn't that my pod was the wrong way round and I found that MJ should happily launch you from any start position. It does most of the time. Sometimes it acts as though I have force roll selected even though I don't. Seems like a scene loading problem. Or even a save file problem. I must say I am also not such a fan of the way SmartASS now overrides craft movement instead of it just being put into auto mode like it used to. Is that an artifact of the way the force roll was implemented?

I just use a Big Kethane tanker truck parked around back of the facility. I fill it up with the souls of Grey Shirt Kerbals. Trust me, with a name like Munvis, you are better off as Kethane. What do you think the "Wait No...STOP!" device is all about? I think it's the most entertaining method of getting kethane for testing.

Alright guys. I DLed the latest dev version. Problem, the ship tries to make a 180 deg roll right off the pad. Now that is using one of the stock command pods as the mech jeb unit but my old version never did that. It is rolling until the POD faces north. That is usually not a problem but if you have a ship that needs a little speed before it has control authority it will never make the roll. It causes the ship to wobble all over the sky. It's like it is trying to force roll even though I have that unchecked. You should not be forcing roll off the pad. People orient the ship how they want in the VAB. Stock VAB rotation is 180 degrees. MechJeb is trying to force roll 0 right off the pad. That needs to stop. It never did that before. Even the last version I had that had force roll didn't have that problem.

So far... Everything still works like it did with v 0.71. The only problem I have is that some the HUD elements disappear when you use it. So there is something going on with that. I haven't tried V.84 yet since the other day. I know it wont work with my scripts as it is. It has some weird white space issues. I am really eager for the new stuff though. Those new round and floor functions where nice when I tested them. The only outstanding issue that I know of that is a real issue is the fact that half of your space craft will get eaten by the Space Kraken if you leave it and come back to it with the com center. That was happening before .22 update so that isn't new.

No it isn't. Have a screwed something up? Yup I sure did. I'll fix it. Sorry about that sir. It should be correct now.

I often think about using the ION engines but I actually did use them once to put a satellite around the moon. That took so long I could have devised a fuel truck mission or 20. This idea inspired me to make a small space cycle for Jeb that uses an ion engine with 10 seperatrons as a turbo. Most of the time it puts along like one of those battery powered wheel chairs but Jeb knows that he can hit the boost at any time for a speedy get away.

New updates today. Check the front page for the change log.

You don't need to know your orbital velocity even though you can get it. clearscreen. set done to 0. set Gk to 3.5316000*10^12. set tAp to 100000. set tPe to 0. // For dV at Ap set Radius to AMSL-Kerbin + Ap. For Pe use AMSL-Kerbin + Pe. set Radius to 600000 + tAp. set sma to 600000 + ((tPe+tAp)/2). set V1 to (Gk/Radius)^.5. set V2 to (Gk*((2/Radius)-(1/sma)))^.5. set dV to abs(V1-V2). set acceleration to (maxthrust/mass). set burnTime to (dV/acceleration). set tTime to (burnTime/2). until done = 1 { if ag1 = "True" { set done to 1. toggle ag1. }. print "Semi-Major Axis " + sma at (0,1). print "Target Velocity " + V1 at (0,3). print "Velocity at Burn " + V2 at (0,5). print "Delta Velocity " + dV at (0,7). print "Max Acceleration " + acceleration at (0,9). print "Burn Time " + burnTime at (0,11). print "Target Time " + tTime at (0,13). }. That is Vis-a-Vis for circularization. Checked against here. http://files.arklyffe.com/orbcalc.html

I think you underestimate the amount of thorium we have laying around. The amount we have already extracted, could power our world through exponential growth for the foreseeable future. This isn't cooking oil we are talking about here. More and more is extracted everyday through the mining of all sorts of ore. I'm talking about orders of magnitude more stored energy than all of the fossil fuel stores we have used and are yet to use. We should already have these things. Too bad no Government wants a nuclear reactor that doesn't make fuel for atomic weapons.

I don't understand all of the draw to quack science when there is legitimate science that can and will get to the same place. Clean, Safe, Free/Nearly Free Energy is what you are after right? Thorium fueled breed reactors can already provide that. It is established science. I.E. works with our current understanding of physics. It's safe in the fact that it is a self moderating reaction and it doesn't require external powered cooling. It's Clean in the fact that it is nuclear that doesn't require storage of spent fuel. It would be cheap or nearly free because we throw away thorium. We actually pay people to haul it off. It is an environmental hazard apparently, once we dig it up from the ground in the environment. I.E. You are not allowed to put it back once you have dug it up unless you pay for a special permit. It's abundant. We aren't going to run out. The amount we have just laying around in piles already, could fuel the world for the next couple thousand years at least. Those piles get bigger everyday.

You already can. Example. Lets say we have vector notation V(x,y,z). You can decimate that vector and preform mathematical computation like so. Name the vector notation. In the case of those vectors that are provided by kOS, say velocity:surface, you would do something like this. set SurfVel to velocity:surface. Now you have access to those vector elements via. SurfVel:x SurfVel:y SurfVel:z Euler rotations can be decimated in a similar way. The only reason we renamed velocity:surface is because it's name by default already has a colon in it. If you are dealing with Euler rotation you can decimate in the same way. Prograde is.... Prograde:yaw Prograde:pitch Prograde:roll I think what you are asking for is to just be able to say: set SurfRetro to V(-1,-1,-1) * velocity:surface. The last time I tried, that didn't work. YMMV.

Kerbal engineer redux for TRO. http://kerbalspaceprogram.com/0-18-1-kerbal-engineer-redux-v0-5/ You will need a docking alignment indicator. You can either use laser docking cam. http://kerbalspaceprogram.com/lazor-docking-cam/ OR Docking port alignment indicator. http://kerbalspaceprogram.com/dock-align-indicator/ If you ask me, the second one is lighter and better. The laser cam is nice but it comes with a bunch of other things that may cause problems. The mods you listed are good. I have all of those but I took out the parts that I don't use. I would say you definitely want KSPX. http://forum.kerbalspaceprogram.com/threads/30472-0-21-x-KSPX-Kerbal-Stock-Part-eXpansion-mod-reposted-v0-2-3 Try to keep it light on the mods if you are a new player. Those few things I stated above are the essentials. I wouldn't go installing all of those parts heavy mods until you have a better understanding of the quirks of KSP. At some point, when you are familiar with all of the orbital maneuvers, they will start to get boring and time consuming. You will want some sort of flight computer. There is a mod that will let you program your own. kOS. http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-84 There is also as you know MechJeb which is excellent and it is already programmed for you. Then you can actually use all of those parts heavy mods to do things. Kethane mining without a flight computer of some kind is not as fun as it seems. I do agree that you will get greater enjoyment in the meantime by doing things yourself. Concentrate on the fundamentals and learn how to think like a rocket scientist. Learn to build proper rockets. Many people find that they can fly bricks into space manually but they cry foul when a computer can't fly that same brick. At some point you will know the mods you need based on your mission plans and ideas. It will probably be when you understand exactly how you want to use them. As your goals grow so will your needs. It's a great way to play if you ask me. MJ isn't a win button either. If you don't know space flight, you wont be able to use it properly. It's just a tool.

Ok guys Space computer's new overhaul is in. Front page updated. Have a look at the new video.

This is what you get when Jeb writes your landing computer.

Don't even get me started on this subject. IMO Challenger was just as great of an administration failure as was the Foam strike incident. Even damage done, those people were savable. Though I suppose if the shuttle had a pad abort procedure then the Challenger crew was saveable as well. I still remember that day. I was eight years old and I got to watch NASA murder seven people live in my classroom. No caliber of administration meeting is going to fix the fact that the O-rings won't work at that temperature. Nor will they fix giant holes in the leading edge of wings. Considering NASA had a problem with the tiles falling off on their own accord just sitting in the VAB, one would think they would have instituted some tile inspection procedures before this. Instead, they allowed them selves to be blinded by the fact that they had lost many tiles before and it never was an issue. Those sorts of failures tell you that you are headed toward the wrong side of the statistical probability scale. Not that everything is going to be fine. That is a logical fallacy that humans apply when they get lucky a few times. Ask any Casino how it works. If it didn't, they wouldn't be in business.

I'm going with electromagnetic anomaly as well. Seems like it makes the most sense. I know satellites sometimes use the planets magnetic field for reaction control. That is a much stronger force than that of gravity or ablation/gas ejection. Though because you said they are gaining instead of losing it makes the electromagnetic theory pretty shaky. It would be a much more believable theory if it slowed the object.

Hey check, thanks for looking into this. Periods at the end of { aren´t necessary anymore. So I neglected them. The Problem I wanted to refer to is that having the condition encounter="Mun" in the until command won´t work (1st code). A work around is the if command with break (2nd code). That seems to be a bug. cheers In my testing of ver .71, Until can't be used with AND/OR or "STRING" operators. If and When then both work with AND/OR. And If is the only thing that works with "STRING". Examples: If works with all of the above operators. This works. set Goflag to 0. Until Goflag = 1 { if status = "LANDED" { set Goflag to 1. }. }. This works. when x =1 AND/OR y = 1 then { do these things. }. Doesn't work. Until status = "LANDED" { do these things. }. Doesn't work. when status = "LANDED" then { do these things. }. Doesn't work. until x = 1 AND/OR y = 2 { do these things. }. In ver .84. Even with me masking the eta:apoapsis with a variable to get around that issue, it still errors on my scripts somewhere with no line error. It just shuts down. So I have stuck with .71 for now.

I have no idea what you are trying to do but an Arduino isn't a transmitter and the servo isn't a receiver. It is possible to make the arduino control the servo directly with a cable and the proper software. Do you have some sort of transmitting radio hooked up to the arduino? Do you have a radio receiver unit to plug the servo into?

v0.84 still doesn't work. Throws an error when you. print "ETA:Apoapsis" + eta:apoapsis. So I commented that line out. Fails shortly there after with generic Expression Error. No line number given. I think we are in special case hell.

I would still prefer to be able to declare them that way. At this point I will take what I can get.

Bizz have you tried it with math? Space computer uses eta:apoapsis in a math statement. when eta:apoapsis < 120 + tTime then { do something. }. Maybe try. when eta:apoapsis < (120 + tTime) then { do something. }. That might fix it. I also just noticed that I am using THEN I am not sure if that is still required in when statements. Honestly I am not sure why it ever was. If doesn't use it. Seems like it isn't required but I haven't tested it. I have enough trouble already without sabotaging my self. Good news. I wish to announce that Space Computer can now officially launch to orbit and then preform a transfer and then preform a powered landing on Kerbin... All from the menu! The recursive ON statements where what was breaking the whole lot. Once I fixed that, everything worked as it should have. I will probably switch to hosting the scripts on pastebin to clean up the front page. There will be a lot more coming. I am not so sure that I like the menu system now that it is working. I am looking at being able to setup mission packs that will execute based on settings in the mission pack file. You tell it to "run Mymission" and it will carry out your mission as described in the file. Probably a thousand different ways to do that. I shall have to think about it and try some things. I have still yet to remove a ton of constants to be replaced with variables based on SOI, set parameters, Etc. I see the mods for the mods have popped up to allow you to poll sensor information. I probably won't bother with that too much. I expect Kevin will add that functionality directly to kOS.