Dunbaratu

Correct. My main goal in posting was not "please help me solve this", although finding out about the debug menu to solve it was nice. My main goal was "tell SQUAD the bug exists". And I thought the support forum *was* the right place to report a bug.

Problem 1: Funds are scaled on a totally different order of magnitude from science and reputation (i.e. 300 science unlocks several early tech nodes, but 300 Funds only buys you one smallish part of a single rocket), but it seems that the devs forgot that when they designed the admin building trades. Funds gets traded with Science or Rep as if it was even remotely on the same order of magnitude when it so isn't, making any strategy to trade away Science or Rep for Funds utterly ridiculous and crippling. Take this for example: Patents licensing: If I slide it all the way up to the max level, it's taking 100% science and transforming those science points into 10 Funds per 1 science point it "stole" away. If I read that right, that would mean that losing out on, say, 2000 science would gain me a mere 20,000 Funds. Funds is a LOT more scaled up from Science than in a mere 10:1 ratio. It would need to be more like at least 100:1 or even 500:1 or 1000:1 to even be worth thinking about activating this strategy. That seems waaaay out of whack. 2000 science is a waay bigger deal than a mere 20,000 Funds. 20,000 Funds is the return on investment from one single early contract in the beginning of the game (even in Hard mode that nerfs Funds). That's just one example, but it seems that the other funding strategies have the same problem. It's as if the devs forgot that Funds are on a totally different order of magnitude from Science and Reputation. They shouldn't be traded at a mere 1:1 ratio, or even 10:1. When the entire science return of an early Mun mission is traded in for the mere cost of one medium sized fuel tank, something is really off about that. The Recovery Transponder Fitting results in nothing but a loss of money for no benefit. Let's say you set the Recovery Transponder Fitting strategy commitment slider to 30%. Then launching costs you +8.8%, while recovery gains you +8%. They're about the same. (At less commitment, it's a bit more launch than recover, and at more commitment it's a bit more for recover than launch, but in general it's never a lot of difference between the two). Unless you recover 100% of what you launch, and never use stages at all, and never burn fuel at all, and never leave items in orbit (i.e. satellites and probes), how can that possibly do anything other than just lose money? Your recovered vessels will always have less overall value than your launched ones, so when the launching surcharge is the same percentage as the recovery bonus, that's a net loss.

I think at least some of the game's music is actually from some online music library that's been publicly licensed as free-to-use for whatever, and SQUAD didn't actually develop it. I know for a fact I've heard the "you are in space" music on several youtube videos before that have nothing to do with KSP, and I think it's one of the options you can add to your own youtube videos from youtube's free library of music effects. If that suspicion is true, it would mean that changing the music to something developed FOR the game would mean embarking on a new expense that SQUAD had previously avoided - paying a musician. I don't know for sure if my suspicion is true, but I think it is because I've heard that exact same music elsewhere.

ship:parts[19]:modules is not a list of actual partmodule objects. It's just a list of string NAMES of modules and that's all. This was deliberate because I wanted a means of getting a terse dump of the modules' names to come out. If each item in the :modules list was the whole module, then dumping that list to the screen would produce the full information of each module (it's list of KSPfields, KSPevents, and KSPactions), and thus not show you a terse list. The only regret I have is in the naming of it. It should have been called modulenames rather than modules, to make this fact clearer.

Okay thanks for the advice. I'll try the debug menu to get out of it. I also may fire up the C# development environment and try querying the API to find out exactly what it has defined as the "in space high above" altitude for Gilly, to confirm whether this is truly impossible. If it is, then this should be a bug report for SQUAD. I think it is because I've tried twice to take the scan, once as low as a mere 6250m and it still said "temperature scan can't be done right now". As a secondary bug report, once you DO get the "temperature scan can't be done right now" message, it removes the "log temperature" button from the RMB menu for the thermometer. IF you then lower your altitude to the point where it can be done, even to the point of actually landing entirely, the "log temperature" button is still missing when you bring up the RMB menu, so you can't. The only way to get the button to appear again is to switch to a different vessel far away (unloading the current one) and then come back to this one again (reloading the vessel) to make the button re-appear.

I accepted a contract for temperature scans on Gilly. I didn't expect the game to give me a literally impossible contract (well, I knew about the launch stabalizers on the mun problem with some of the test contracts, but this is different. It's not a part test contract.) The problem: The contract requires a temperature scan ABOVE 6200m on Gilly, but that's higher than the maximum altitude the game will allow temperature scans on a body without an atmosphere like Gilly. Am I correct that the game created an impossible contract here? And if so, is there a way I can massage the data to undo it without being penalized for "my" failure?

That's what this was for: ship:north gives you this Direction frame, for example: Z-axis=north where your ship is. Y-Axis=Up where your ship is. X-Axis=East where your ship is. ship:north:inverse * someRawVector Gives you a new vector in which its X,Y, and Z axes now mean the east,up,north components of the original raw vector. Alternatively you can use the dot product rule to transform any vector into a different rotational frame, like so: If xbase, ybase, and zbase are 3 UNIT vectors in the current reference frame representing the basis vectors of a new rotated reference frame, you can obtain what the coordinates of a vector in that new frame would be by dot-producting it with them, assuming the new frame has the same handedness as the old (i.e. going from left-handed to right-handed requires more than just a rotation, but going from one left-handed system to another left-handed system, this works for). vector's X coord in new frame = VDOT( xbase, rawVec ). vector's Y coord in new frame = VDOT( ybase, rawVec ). vector's Z coord in new frame = VDOT( zbase, rawVec ). If you really need it as a degrees heading by the compass, then once you have those, use the new X and Z components with ATAN2 to derive the angle. It might be nice to also have the navball data directly, but it doesn't exist yet, as this workaround functions for the time being, and there's bigger problems the 0.90 update caused that I'm looking at. It is on the plan though to provide a better way, which I outlined in this github issue several days ago that I intend to get around to eventually implementing: https://github.com/KSP-KOS/KOS/issues/440 (Warning, that's still in the 'talk about it' design phase - there's no guarantee it would really look like that in the end).

Currently there is no support for querying the staging list.

There is no such suffix as STAGE:AMOUNT, and sadly the stage values are written in a way where any suffix you use that is not recognized returns zero. STAGE:thingy is supposed to tell you how much of resource thingy is available to the current stage.

Ah so the null reference was just the fact that Target was null. it was correct, not an error. KSP refuses to let you set a target tp the currec SOI body. when you try it refuses and nulls it out. kOS still needs a check versus null though.

Well, then maybe it's still the same problem as I mentioned earlier. You're comparing two different wrappers around the same object - the object is the same but the wrapper objects around it differ. kOS needs better equality checkers for these cases.

No - that looks like the right syntax. Here's a test about a suspicion I have. BEFORE you run the script, select your target, then run the script and see how it behaves. The target should get de-selected by "set target to body("Duna").", and then you can re-select it. If THAT works, while it doesn't work when you didn't have a target selected beforehand, then I know the problem, and it's an ugly problem with how the target variable works which I never liked. But before I try to explain it, just check and see if that makes a difference. I could be making the wrong guess.

Which "newest version of kOS" do you mean? The pre-release from Github or the publically official ones from curse or kerbalstuff? Currently the official ones aren't working with 0.90 yet, but there's a pre-release on github that is but has some other issues with 0.90 (mostly, not issues where it's broken, but issues where it is thematically clashing with 0.90's career restrictions and allowing you to bypass them - for example setting a maneuver node via kOS, or getting the next predicted encounter with kOS, both do not first check to see if your tracking center upgrade level supports it.) Edit: just saw your last post show up. Yes, if you're getting complaints about part.uid then you are definitely not running the version that's compatible with 0.90. Part.uid is one of the things SQUAD changed between version 0.25 and 0.90.

The period on line 12 terminates the IF, causing ELSE to not be attached to anything. I'm surprised this doesn't end up as a syntax error. I may have to fix that.

A Tutorial Video describing some features of Directions and how they work Note: some of what this video uses is only in pre-release 0.15.4 from github right now and is NOT in the full release yet. These are the features used in the video that are only in the pre-release at the moment, and are not in the documentation yet: * ANGLEAXIS(degrees,axisVector) - creates a Direction that rotates degrees around axisVector * LOOKDIRUP(lookatVector,lookupVector) - creates a Direction that points the nose at lookatVector, and points the vessel's top at lookupVector. It's equivalent to a rotation that rotates the Z axis to the nose and the Y axis to the roof (the X axis then points to the right of the YZ plane as you look down the Z axis). * ROTATEFROMTO(vector1,vector2) - creates one of the infinite many directions that could rotate a vector from vector1 to vector2 * direction:FOREVECTOR - alias for the old :VECTOR suffix - the nose direction of the craft - If you were to apply the rotation to the universe, it's the Z axis after the universe grid was rotated to the new direction. * direction:TOPVECTOR - the roof direction of the craft if it was to be oriented in this direction - If you were to apply the rotation to the universe, it's the Y axis after the universe grid was rotated to the new direction. * direction:STARVECTOR - the right-wing direction of the craft if it was to be oriented in this direction - If you were to apply the rotation to the universe, it's the X axis after the universe grid was rotated to the new direction. * direction:INVERSE - the Direction that has the opposite effect that this direction has. Often you have to use this when flipping between thinking of rotating the axes of the universe to rotating the object in the universe instead. * multiplication of direction * direction works correctly now - dir1*dir2 starts from dir2 and rotates it by dir1 - useful for things like ANGLEAXIS, as in ANGLEAXIS(deg,vector)*SHIP:FACING to get a new direction from rotating the current facing around an axis. I'm about to head out for Christmas to visit the folk's house for a few days so I wanted to get this out there before I left. I decided that it would take too long to wait for the docs of these features to become public because that won't happen until the pre-release becomes a full-release, and people were having questions about this topic now. I recorded this video about a month ago but was holding off on making it public.

That should be doable. In the underlying KSP API, a Part has both a mass value (The dry mass) and a GetResourceMass() method (which returns the sum of the masses of all the resource levels currently contained in the part, i.e. oxidizer+liquidfuel).

First: a clarification about the "parts fall off" - what's actually happening is that ONE part is affected. It's not fallen off, but in fact is vanished entirely - the SCS part fails to be created at all. Then all the parts that are meant to be attached to the vessel via the SCS part are now attached to nothing, and that's what makes them "fall off". I noticed this once and took a mental note of it. It's really just the SCS part - everything else is a consequence of it being missing. I'll be willing to bet it's because of the code that makes an attempt to restore the varaible state. It was written totally wrongly and I'd like to see it entirely removed until a replacement can be found. It's a thousand times less bad for the program state to be forgotten when you switch scenes than for parts to fall off. As for thrust limiting - I think it's wrong for it to be used to actually *increase* an engine's output past its maximum. That seems like a massive bug. It may be useful, but don't depend on it - it should be fixed. As for locking the pilot out - you can read the pilot's inputs even while they are being locked out and ineffective (as I understand it), and thus use them as a suggestion your script can decide what to do with - sort of the Airbus style of control where the pilot's joystick has no hydrolic , mechanical, or electrical connection whatsoever to the control surfaces. It's just a digital input to the autopilot software and the software decides what it feels like doing with that information. (A method with both good and bad consequences. The good is that the autopilot can prevent the pilot from doing something wrong, but the downside being that the pilot is helpless to prevent the autopilot from doing something wrong.)

Sadly, these were incorrectly named from day 1, leaving those of us who took over kOS after Kevin abandoned it with a backward compatibility problem. They are in fact NOT pitch, yaw, and roll. Not even in the slightest. What they actually are is rotation around X, rotation around Y, and rotation around Z - the the XYZ axes of the Unity Worldspace that KSP uses under the hood. These are of course, completely unrelated to the vessel's own local transform space. They are NOT the vessel's own pitch, yaw, and roll.

It's coming. Actually, it's already there but it's undocumented because the docs are in a temporary freeze while they get moved from one markdown system to another. That looks almost ready, and once it is I'll be able to make a post about it here.

The runway problem is largely the grasses' fault, not the runway's fault. Grass is smoother than level 1 runway because grass is lacking the bumpiness it should have. All grass should default to bumpy everywhere on the KSC and then only be smooth at exception locations.

I think the take-away from this thread should be that SQUAD needs to show more significant digits in the tonnage display.

Hmm. I hovered over the description, but not over the upgrade button. I'll try that.

I think I can guess what's happening. When you PRINT an object in kOS, it "stringifies" it. (People who program in C# or Java will be familiar with the concept of all objects having a toString() method that is activated when you try using it in a string context.) What you see when you print it is a plain string, even if it is NOT REALLY a string. So when you try the comparator "<>", it's not using it like a string and it's detecting that they are not equal because they are two different wrappers around the same body object. TARGET is returning a wrapper object AROUND the body, and so is Body("Kerbin"). They are wrappers around the same body object, but the equality checker is only comparing the wrapper, not the body itself. There are ways to fix this, and one of my future goals is to do a better job of making our kOS wrappers around the C# objects behave more *like* they were really the native object in the first place, in checking for equality and other similar things. (And, NO, this would not be fixed by using a different scripting language. The problem is in the way kOS wraps KSP C# objects inside its own C# objects, which is at a layer underneath the layer where they start being exposed to the scripting language.) In the meantime, you can force them to be treated like strings instead by using this ugly trick: Append them to a nullstring - it's a cheap way to get a "cast" without really doing a cast. So try this: if ( (""+target) <> (""+body("Kerbin")) ) { That will force both to spit out their stringified values, and then it's comparing the strings they spit out, not the objects. We really should expose the ToString() to the higher level system and just let people call ToString themselves in scripts.

When you hover over a building, you can see the effect of its CURRENT upgrade level, but it's just as important, perhaps even MORE important, to know what the effect of sinking your money into upgrading it would give you. If I have enough funds to upgrade one of 3 or 4 different buildings, but only enough to do one of them, then I'm basically just picking one randomly if I don't have the data to tell me what the effect of each choice of upgrade would be. The only one I really know for sure what it does is the science building, because I've seen the whole tech tree before. But if I'm trying to decide between, say, upgrading the VAB versus upgrading the tracking center, then knowing just how many more parts and dimensions the VAB upgrade will give me, versus knowing what new features the tracking center upgrade will give me, is vital information to make that decision. At the moment, as far as I can tell, that information exists only *outside* the game, in a post announcing the new 0.90 beta. It needs to exist in the user interface *inside* the game too.

The difference is that a survey contract has an "end" goal at which lots of bonuses are handed out (or penalties if you don't finish in time). What the OP was referring to would be too long-term for that to really be an appropriate way to model it. What would be nice would be an *ongoing* program that has no endpoint - you go into the admin center and pick a 'mission strategy' and it would have the effect of biasing the contracts offered in favor of a particular type of mission. If you like spaceplanes, set a spaceplane program and watch more airplane contracts arrive. If you really love the planet Duna, set a Duna strategy and watch more Duna contracts arrive. Set a "Mun" program and see more mun crash, mun probe, and mun landing contracts than usual appear. It would be the equivalent of Kennedy's "We choose to go to the moon" speech - it sets the overarching push of the space agency for the next several years.