Dunbaratu

Yes. And to further describe it: SHIP:MAXTHRUST: Thrust you could have given the current list of active engines if you assume they are all fueled, and none of them are thrust limited, and you put the throttle at max. SHIP:AVAILABLETHRUST: Like MAXTHRUST, except it does take into account how you have the thrust limiters currently set. It's the amount of thrust you'd get at max throttle but leaving the thrust limiters engaged as they are. Current actual Thrust should be SHIP:AVAILABLETHRUST * THROTTLE.

Once upon a time kOS had its own homebrewed code for calculating the stage values. Then this was scrapped in favor of calling KSP's own API method for it, as it was assumed this would be more future-compatible with whatever SQUAD chooses to do later. But the problem? KSP's own API routine returns baffling results that make no sense in some cases. There's a chance we'll have to go back to doing it in homebrewed code.

The reason it's not possible is technical, not thematic. The math gets imprecise when the floating point numbers get large (when the location of, say, your fuel tank is no longer the xyz coords (6.2352, 603.23523, 10.4525) but is now (589340403.13, 69492914.63, 5902958.4), those bigger numbers are less precise than the smaller ones, because precision in floating point computer numbers doesn't scale linearly. That's where the space kraken comes from. Calculating the "forces" of parts interacting with each other gets screwy when the numbers keep getting rounded to the nearest possible value, and the nearest possible value is significantly different from the actual value it should be. Any request to have two vessels both be active at the same time despite being millions of meters apart from each other has to address this problem, as it's the primary reason there is such a thing as 'loading distance' in KSP.

Most floating point representations do in fact have a "magic" value that means infinity. http://en.wikipedia.org/wiki/IEEE_754-1985#Representation_of_non-numbers kOS doesn't support testing for any of them, even though some of its math functions do return Infinity in some cases - such as to represent holes in domain space for functions like TAN() and LN(). For infinity, I'd just check if it's bigger than a really big number. For checking isNaN, on the other hand... well that's a thing the language could use, in my opinion.

There has been recent work in 0.17.0 to fix the way the toolbar window gets spawned. There is a good chance this might get fixed when 0.17.0 is out.

As far as I know there are no special cases in the kOS code to deal with the places that FAR breaks the base game's API. This close to KSP 1.0 it may be a good idea to wait and see what changes FAR makes in reaction to KSP's new aerodynamics model. Chances are FAR will still exist, and will still end up invalidating parts of KSP's stock API, but it may do so in a way that differs from how it does it now.

I tried using openGL mode once just to see - sadly it prevents rendering shadows (yes, I know OpenGL itself doesn't prevent it, but something about how Unity is using it on an ATI card for some reason doesn't do shadows regardless of your video settings), and shadows are vital cues in KSP when manually flying a landing. I don't consider using opengl to be an acceptable way to deal with the memory limit, for that reason. Anyway, you asked which OS, not which version of KSP. The response never said anything about whether or not KSP was 32-bit, only that the Windows version was. You can be running 32-bit KSP on 64-bit Windows OS.

Does anyone have a valid use case for the following situation? * You do have Remotetech installed. but, * You do NOT want the behavior of the CONFIG:RT light enabled? We keep getting lots of posts by people saying kOS is broken and doesn't work with RT, and they're often spreading this misinformation in other places, based on not knowing about having to turn that option on. The original reason for making it an option is that there once were some buggy problems in that code and it was considered experimental "as-is" software. But I wonder about whether it's worth it to keep it an option given how leaving it turned off really breaks kOS in RT - maybe it should just always behave like it's on, when RT is detected installed and enabled, and always like it's off when RT is not present. Thus why I'm asking if there's valid use cases for it staying off when RT is present. There'd have to be in order for it to be a good idea for it to remain an option. - - - Updated - - - With the code snippet you posted it's impossible to tell what the problem is because it occurs prior to that point. The complaint is that when you do: SET MOD TO P:GETMODULE("ModuleRTAntenna")., there is no such thing as a variable "P" yet. P needs to have been set somewhere earlier than that line. If this was taken from a tutorial it may be referring to a "P" that earlier code above in the same page has set, and the tutorial is assuming you already ran that earlier code.

If you check the reddit /r/kos area, people have made some syntax highlighter config files for a few common editors. They don't help you to know what the suffixes are for bound things, or the magic special variables, but they help with the basic syntax.

Out of curiosity, what do you get if you keep giving it the same state over and over: cpuList[0]:doaction("toggle power",true). wait 1. cpuList[0]:doaction("toggle power",true). wait 1. cpuList[0]:doaction("toggle power",true). wait 1. or: cpuList[0]:doaction("toggle power",false). wait 1. cpuList[0]:doaction("toggle power",false). wait 1. cpuList[0]:doaction("toggle power",false). wait 1. I suspect it *needs* the state to change to notice anything happened, but that once the state changes the thing that happens is just a call to the toggle, which does a toggle, not an absolute set. I blame KSP itself. It implemented action groups first for stuff like Lights, Gear, and so on -things for which having two boolean states makes sense. But then it added the ability to make your own action groups for which you just fire-once, but piggybacked that on the same system as for things it makes logical sense to have two states - so you now have actions triggered by changing a state of the GROUP, which then trigger a method that itself changes a state with a toggle, making it possible for the two to become out of sync in what they mean.

The short answer is that kOS doesn't implement input streams from the user yet. You can only get sort of kludge solutions involving using the action groups. I'd like to fix it but fixing the annoying presumed global-ness of everything was higher on my list - and it's thorny because it looks like it inevitably results in breaking some backward compatibility because the original language design had some annoying presumptions hardcoded into its design.

Just wanted to saw I'm really happy all this is being done. When erendrake and ziw diverted their time from kOS over to "an IR rework", I stayed over in the kOS world, and hadn't been watching what they were doing. I just noticed this thread today. I really hope I can get the kOS function re-work fixed along the same time this goes out of pre-release. The two releases together would be a nice combination. (The biggest problem is that LOCKs are essentially callback functions and therefore they violate all the nice scoping rules, and therefore need closures implemented for them to not blow things up. That's the main reason why the release got delayed a bit.)

You have to click the "go advanced" button when editing, and there will be an option to disable smileys. Franky, I think that's utterly backward. Actually showing the text you *really did* type is what I'd call basic vanilla mode and invoking the option to do something fancy with it is what' I'd call "advanced". Not the other way around.

Hmm. It was reported on reddit, but the relevant info (that the range 0..1 gets interpreted as 1% not 100%) never made it to github where the issues get tracked, so it got lost. I'll go update the issue. EDIT: UPDATE: As far as I can tell, the problem was was already fixed a while back, according to this: https://github.com/KSP-KOS/KOS/pull/559#discussion-diff-24644269 Are you on an old version?

I don't see any connection between the problem of lists being printed tersely and the problem of REMOVE not working right. I don't get the description of the problem. Lists being printed tersely is a sort of problem. I'm not sure what the proper solution should be. I don't think it's right to always spew a wall of text at you whether you wanted it or not, so there would have to be some sort of optional way - effectively two different kinds of ToString() - one verbose and one terse. All vectors have a :MAG suffix that returns their magnitude as a singleton scalar. SHIP : VELOCITY : ORBIT : MAG.

"The SOI BODY" refers to the SOI body where *YOU* are at the moment, not the one the remote body is in. Duna isn't hardcoded to tell you its orbital velocity relative to Kerbin. It happens to be telling it relative to Kerbin because Kerbin is where your vessel is at the moment and therefore it's the temporary center of your universe. If you escaped Kerbin and went into interplanetary oribt around the sun, then duna would start reporting its orbital velocity relative to the sun. It's matching the weird behavior coming from Unity itself because that's how SQUAD made the universe work - the frame of reference moves with you. In general, any time you want to change the reference frame, just subtract the desired origin out. If you want duna's velocity relative to the sun, then just say: set duna_vel_vs_sun to duna:velocity:orbit - sun:velocity:orbit. That will be guaranteed to give you a sun-centric velocity whether the sun is your current SOI or not. Or to get the speed that would be indicated on the navball if it was in target mode, it's the same sort of principle - your speed relative to the frame of reference of the target:. set target_rel_vel to ship:velocity:orbit - target:velocity:orbit. set target_rel_speed to target_rel_vel:mag. You are right that there is a slight confusion over surface speed as it is documented. It's NOT the velocity relative to the body's SOI - it's the orbital velocity in the reference frame of your current ship's SOI body, PLUS the offset that occurs due to the rotation of the body's SOI body's rotation. The definition in the docs works when your ship is the the same SOI as the body in question (i.e. both you and the mun are orbiting kerbin right now), but isn't exactly right when that's not true.

All velocities are coerced into the reference frame of the current SOI body. You're seeing the velocity of the sun *relative to kerbin*. Which is why the velocity of kerbin is zero. It's showing how fast kerbin is moving relaive to.. itself.

User Functions Teaser vid: Wherein I demonstrate user functions by making a generic PID controller function and using it to form a small hover example script.

That is a very common symptom of a lot of different bugs. Basically, KSP is doing a LOT of work when switching scenes, and often when data is set up wrong, that's where it manifests as a problem. It's also where running out of memory can manifest itself and cause that effect. I get this a lot with different things and sometimesit's a very odd interaction between different mods that does it (each mod alone works fine, but install them together and it screws up). More useful than your code would probably be the output_log of the game when that occurs (although seeing the code would be useful too). It will contain the verbose logs of all the exceptions thrown by all the different installed mods as the scene was changing. Often that will help us diagnose which mod is "at fault".

ROUND requires two arguments: value to round, and decimal places to the right of the dot to round to. i.e. ROUND(100.11111 , 2) would return 100.11 while ROUND(100.11111, 0) would return 100. In the current incarnation of kOS, built-in functions like ROUND() are not really able to count the number of values pushed onto the argument stack to ensure they are correct, so it can't tell you that there's a mismatch. Instead ROUND() tries to unconditionally read two values even when you didn't pass two values, leading to very confusing errors as it gets the stack misaligned. By the way, that's fixed in the functions revamp that should be getting released "any day now". (We have the goal of wanting it released before KSP 1.0 drops. We're in the final stretch for release.) Now it will be able to bomb out with a proper error message when you didn't pass the number of arguments it was expecting. In principle the ability to detect a count of the number of args also means we could start supporting built-in functions with multiple varying number of arguments (i.e. maybe we could make ROUND detect when you only passed it one arg, and have it presume you meant to round to the one's place when it sees that). (For now we haven't done that, but the infrastructure is in place so we could go through all the built-in functions and start doing that sort of thing with them in the future.)

The actual problem is that the default orientation KSP puts your rocket into on the pad is (for some dumb reason I never understood) one in which the rocket is aimed north/south - so pitching down goes north, pitching up goes south, and you yaw right to go east. Given that most of the time you are launching to the east, this has NEVER made any sense to me. But that is how the game works. But the orientation that HEADING(90,pitch) is trying to use is one that's a bit more sensible and "airplane" like - with your top aimed up to the sky, as expected. This means that to go from your starting launchpad orientation to the heading involves doing a 90 degree roll as well to aim your roof at the sky. The problem is that LOCK STEERING is attempting to do both of these operations simultaneously, which is why you see it describe a weird arc as it pitches down. It's trying to roll into an orientation aligned with the horizon while at the same time trying to pitch down, and basically precessing. The best fix, I think is when still aiming straight up, right off the launchpad, to first roll your rocket to an orientation in which your bottom aims east, your top aims west, and your "wings" are east/west, and then after doing that, then start using HEADING to pitch down. What I usually do to make this work is to never LOCK STEERING TO UP in the first place. Instead of "UP", I do LOCK STEERING TO HEADING(90,89.5) when I first leave the launchpad. This will get me rolled into the same orientation as I'll be using once I start pitching down further. (The reason for HEADING(90,89.5) instead of HEADING(90,90) is because I'm avoiding gimbal lock. I assume it has no idea which way to roll you to align with the horizon when you are aimed literally straight up - all rolls are aligned with the horizon in that configuration.)

I have to apologise to all the people I was being incredulous toward about this. I have just confirmed that engine gimbals are not being used by kOS even in Stock. I have absolutely NO idea why. They used to work just fine back when I was writing kOS scripts regularly over a year ago on the old Nivekk version of the mod. I know this for a fact because I saw engine exhaust being deflected back and forth as the controls were madly slammed back and forth by the overzealous steering algorithm. I don't know what disabled them. I know it was *some* sort of edit because it definitely used to work. But I'm not the one that usually touches that end of the mod so I have no clue what happened. But you're right. Engine nozzles no longer get aimed by lock steering. They definitely DID at one point.

Well, looking at your screenshot it is definitely wrong, but I'm not sure what we can do about it. all we are doing is literally just asking KSP to tell us what resources are currently in the stage, with this call: var resource = shared.Vessel.GetActiveResources(); That GetActiveResources() is SQUAD's own call. It gives a list of all the resources that are (supposedly) currently "active" where "active" means you can currently "get to them". Resources that are on the ship but not reachable at the moment aren't supposed to appear in that API call. Obviously something about how the interstage adapter is working is allowing GetActiveResources() to count the fuel as active even though the part isn't allowing fuel flow to reach it. I have no clue how to fix this, save having to re-implement our own manual resource getter, which we deliberately took out because it was in danger of being forward-incompatible with whatever SQUAD changes next. - - - Updated - - - - - - Updated - - - As a temporary workaround, what would happen if you inserted a stock decoupler just under the interstage fairing, and set them to decouple together in the same stage step? I think the stock decoupler might break the fake crossfeeding connection that the fairing is reporting?

Hi, I've been trying to diagnose a problem in kOS that a user reported over in this post: http://forum.kerbalspaceprogram.com/threads/68089-0-90-kOS-Scriptable-Autopilot-System-v0-16-2-2015-2-23?p=1816722&viewfull=1#post1816722 The gist of it is that kOS is counting the liquidfuel of a tank from an upper stage as being part of the total fuel in the current stage when it's not. All we're doing in the kOS code is just calling SQUAD's own method for this: Vessel.GetActiveResources() - which gives you a list of all the resource amounts currently available for use. And yet this problem seems to only happen when the upper and lower stages are connected via a procedural Fairings' interstage fairing. It's as if it's reporting itself to KSP as currently allowing crossfeeding when it isn't, or something like that. KSP itself doesn't seem to be confused by this - it can tell that the engine can't reach that fuel, but its own API method Vessel.GetActiveResources() is claiming that fuel tank is currently usable. Is there any idea what's going on? Like I said, this works fine for stock parts. There's something about the interstage fairing that makes this complaint come up from time to time with it.

kOS used to use its own complex parts walk algorithm to find all the fuel. Now it just relies on KSP's own API for it. Is there a discrepancy between the fuel shown in the indicators on the side and what kOS says? I.e. when it says there's 100 units left, are the green indicators all empty, or do they also show fuel left? If they also show fuel left then there's not much we can do - that means KSP itself thinks there's fuel for some of the active engines. If it is showing zero fuel in the indicators when kOS says 100, can you show a screenshot of the game, showing where the 100 units of fuel are coming from (highlight the tank it is counting that it shouldn't be and show the popup for it if you can)? It's hard to diagnose from just the verbal description.