Qigon

I had a couple of runs at low altitude because I could test it after a 9s launch, ~10km altitude about Mach 1. But I get about the same results above 80km. I'm beggining to suspect the problem is that the decoupler staging itself makes that thing unstable. Then there's this other thing I noticed, that I once had an engine successfully ignited about 100km altitude, with fumes and TWR and stuff, and then 2 seconds after ignition it got vapor in the lines and shut down. I didn't try to reproduce it, and I'm sure it had TWR below 1, but that never happened to me before or after. I've been using low TWR engines for the last stages a lot in 1.0.5, taking for granted they worked without problems. Another thing I noticed is whenever fuel goes unstable the best way to make them stable is turn the ship retrograde. Works every time, I'm not sure if it's the centrifuge force when spinning or what. Dynamic pressure at this point is always very low, and we're talking centre of mass acceleration < 0.1 according to KER (70-100 km altitude usually). I still have a couple of things to check before finding the culprit.

I'm having issues with igniting engines, it's probably me not doing the right thing but now I can't get to orbit without having problems with fuel stability. How do I deal with it? I tried adding small rockets to help with ullage when going from flameout to next stage, I tried igniting the next stage when the previous was still burning, and other creative approaches but still no luck. I don't remember it being that hard on ksp 1.0.5 (now on 1.1.2 with RO), and it doesn't look like a bug.

Wow just the reason I needed to spend the free time that I don't have™

Very cool, never though of looking into body properties. I'll be honest, although I've been over this for quite some time I couldn't get more than 60 seconds without at least one person nagging me about something, so my mind couldn't possibly be more foggy. I can do the math for the present time and get altitude ok, but whenever I use the same formula for positionAt I get weird things. Shold I expect big displacements in bodt:position? Becaus e I can't get reasonable numbers. local dB to positionAt(ship:body,TIME+10) - ship:body:position. print db:mag.

Thanks guys, it worked like a charm. Now I'm looking for predictions, I'd like to know what will my altitude look like within a few seconds. Problem is, I can't find a way to call predictAt and convert its format (vector) into anything that can compute either altitude, alt:radar or terrain height, like geocoordinates do. For this problems sake I don't feel like cheating since it's totally reasonable to have GPS maps pre stored for any planet.

I've heard about it but never really knew what it was about, I'm gonna try when playing next time. It really doesn't matter if -1 or359 since I'll deal about targeting a desired heading. Another thing that occurred to me is having a Geo point at North Pole and using point:bearing, Although it's not as good because I'd like multiple ships loaded at a time.

I feel I'm overcomplicating something, How do I get the compass heading of an airplane as a scalar? I'm doing vang with facing and north, but this always gives me a "small" positive number. I'd like something that returns -1 when pointing to 359 degrees, or at least something equivalent.

I could successfully upgrade all my critical mods and make it to 1.0.5 today, and it worked like a charm as you predicted. Much smooth, very awe. I love this mod.

Hi, After upgrading the latest kOS from github (ksp 1.0.4) I started having the following error: Method not found: 'GameVariables.UnlockedActionGroupsCustom'. At fdrill on archive, line 18 D:DOACTION(deployDrill,true). This is the complete method that is failing: declare function deploy { print "drill " at(2,3). DECLARE DRILLS to SHIP:MODULESNAMED("ModuleAnimationGroup"). // MKS drills DECLARE deployDrill to "Deploy Drill". DECLARE drillCount to 0. FOR D IN DRILLS { if D:HASACTION(deployDrill) { D:DOACTION(deployDrill,true). set drillCount to drillCount+1. } } print ("Found " + drillCount + " " + "undeployed drills") at (12,5). } Any clues? Or this version simply cannot run on 1.0.4? BTW I would be surprised if I have any issues with control groups this deep into the career.

About the lag issues, what if you updated one vessels orbit per X seconds? You'd get a few frames dropped, but by avoiding batch operations you're mitigating lag. And same as with batch operations, you'd get all 200 vessels updated after the same time span. X could be set in some configuration file for so that we can change it for laggy computers.

Funny thing is that this science error started happening to me all of a sudden. I'll check for more details later but I guess it's only happening in my Mks academy which is like the stock lab. It's full of science and can't transmit anything. I'll try uninstalling science alert and getting the latest remote Tech. BTW I'm still in 1.0.4

Yep, but now it's maintained by Angel-125. Please have some patience so that he gets a chance to check your problem. Are you sure you got the latest version released by Angel-125? The OP on this thread may contain an obsolete link.

I'm glad to know it works like this, it just feels like any other internal behavior is asking for trouble.

What is it that you're trying to accomplish? Is it something that is doable by typing in kos commands every once in a while, or do you need to feed it constantly like a joystick? If it's the first choice I'd go with the telnet choice. You can probably find many telnet clients in github in your preferred language and rig it to a) connect to kos read serial port from atmel and C) issue commands to the kos through telnet. You'd probably pre write kos scripts that implement those commands. That is a way to avoid messing around with ksp linking and docs. I'd try to stay away from rewriting .ks files on the fly. Maybe it works but I'd never be comfortable with that. What if some part of the file is getting written while it's being read? You have to assume lots of things for it go smoothly.

What about a telnet client? Never heard of teensy but it looks like atmel or pic. One way to do it is rs-232 or equivalent -> customized telnet -> kos And you can write a c# gui to configure code -> script pairs to be read by telnet client. Did you actually buy/build a dsky? Send us some videos

Well this is where we're supposed to disagree, I don't find it trivial. But in the end it doesn't matter because I'm not a contributor, so I'm not calling the shots. But to be honest I understand and defend the point of view of those guys who continue to deliver amazing new features. I've paid the price of backwards compatibility too many times. May I suggest that instead of forking you release a separate plugin to go on top of kos? I don't have a clue as to how feasible that is, but it'd give you the freedom to do what you think is correct at the same time that erendrake and Steve also do what they think is correct.

I'll add my 2 cents Maybe you should see the typical use for cooked control as a less hardcore and more casual user. It may look as now we're having less quality because you are expecting an equal or better behavior for a craft that you invested time on, and you may have skills and time to make better, but that's not the point. I know some math because I learned pid in engineering school, I program for a living, and I have fun writing kos script eventually, but I'd rather have a robust and maintained core kos than anything else. Because more often than not I'm interested in using kos rather than working on it.

I guess that by function you mean as in in-game behaviour, not as in programming language's methods? There are these tutorials: http://ksp-kos.github.io/KOS_DOC/tutorials/quickstart.html There's also this twitch from dunbaratu http://www.twitch.tv/dunbaratu/v/8888071 where he writes an airplane autopilot from scratch, it's very cool AND useful. Do twitches expire? that would be sad. I can't get into this link right now, I'm not sure whether it's the twitch or my connection that went rogue. edit: oh, I see Steve beat me to it. By like, 2 days .

There are a couple of examples here http://ksp-kos.github.io/KOS_DOC/library.html

The general problem I'm dealing with is about TARGET. Sometimes I double click on some vessel, to which case TARGET is a vessel. But sometimes I right click on some docking port and in that case TARGET is a part. Here's some things I'm struggling with: 1- How can I tell whether TARGET is a vessel or a part? 2- I've been looking into the docs for some way of finding to which vessel a part belongs? I tried p:parent:parent:parent until I got nothing, and also p:rootPart. I tried an alternative self exploring way, but I couldn't use HASFIELD on a part to do some clever checkings, is there something similar to what we do on modules? 3- In case it's not possible to find a vessel starting with a pointer to one of its parts, how do I find its vessel's velocity? For docking procedures.

Sas is definitely turned offffff ... from several places around the code, just in case. Although this change definitely helped, there's something wrong with this particular ship. The code works just fine with another tiny vessel, but the one I need is still spinning a lot. Although when I unlock steering and turn sas on, it stops wiggling surprisingly close to the direction I wanted! So crazy, but it converges little by little. Although a bit dangerous since it's being used for docking. I'm completely wowed. By extending all gear, antennas, solar I was able to make it behave more or less properly. Also, if I target a vessel that is far away it goes better than a near one. Now the main problem is spin, any crazy ideas to reduce that? EDIT: Now, I could make THIS work perfectly. I'm stunned. sas off. LOCK STEERING to lookdirup(dir,ship:facing:topvector). when true then{ UNLOCK STEERING. sas on. } It's too good to be true. Is this something I can rely on, or may it become obsolete in a future kOS release?

I've been trying to lock steering to without much success. In fact I wanted it to point to a specific vector, but that didn't do either. Unless the vessel is almost "there" it starts wobbling more and more and in a few seconds it's rolling/yawning/pitching very fast. If I go from v(0,1,0) to v(1,1,0) it behaves automatically OK, but if I go from 0,1,0 to 0,-1,0 it will certainly not get there. Can it be something about resonances? The vessel is extremely light, and the torque generated is enough to turn the ship 180 degrees under 2 seconds with MJ. No rcs is available at all. Tomorrow I'll have a try with another vessel when I get to the laptop.

The Minmus Resort will crack some fireworks today to celebrate

I had been consistently trying and failing to create simple parts with blender. I didn't have any experience in modeling at all, and initially followed http://www.alternatewars.com/Games/KSP/Tut1/KSP_Tutorial_1-2.htm and then read through more than half this forum 's posts. Do I absolutely need to install unity for creating a simple 1x1x1 cube with crappy .png texture created in gimp? I created the cube, and created and saw it properly textured. Then I created a collider mesh with this plugin, both the box and others (can't remember the names, the only one I didn't try was the wheel). Then I tried calling the collided with different names according to the tutorial mentioned above and also the name/structure I tried to mimic from a couple remote tech/mks parts that I imported. That means in some cases everything was under a single root node, and on others they would be side by side. I'd usually start from scratch, just in case. Last step was selecting the root node, exporting the .Mu file, and copying it along its .Png and .CFg file into a new folder. The best I could get from all of those combinations (god forgive me if I skipped the right one, because I tried to slowly cover most of them) was seeing an ugly gray cube with a node that allowed it to be attached in the vab, but couldn't be grabbed / removed. And i swear I really tried that. In one occasion I guess I saw textures, I'm not sure if I did it and I couldn't do it again. I suppose that both means my collider is broken and my texture is broken. Also when I tried using more solids they would be out of place, but usually the right size/dimension or rotated - but not always right at all. I guess I can manage that, but the collider and textures are driving me crazy. edit: according to linux #file, this is the .png I've been trying lately - "lcrd.png: PNG image data, 1024 x 1024, 8-bit/color RGBA, non-interlaced" I'm not sure, but I think that I was still trying with .dae models when I saw textures. Is it possible to still use .dae files?

Neat trick, it sounds elegant. I'll suggest instead that you track all parts produced out of Ksc instead. If not, whatever is launched before the player installs this MOD will not be tracked by it, thus its recovery cost will be zero. However I don't know how it would behave if for some reason the player removes /reinstalls the MOD. I don't even know if there's a legitimate reason for doing that (maybe troubleshooting some ksp errors?)