Dunbaratu

Thanks for the fast reply. Assuming I find a TTF fixed width font to use, and that the licensing permits its use in the mod, can I just include it in the mod's GameData folder and tell unity where to find it? Unity's documentation talks about having to put the font into your "assets folder" but I don't know where that is for a mod.

When I first started making some code for a plugin I had no idea what fonts KSP had already available without me installing my own with the plugin, and I picked "Arial" purely as an utter guess, figuring if it has anything it probably has at least that. It worked. But now I'd like to see what other fonts it may have before I start thinking about going out and installing one of my own. And I have no idea how to find out. I'm thinking of making a Unity GUI.TextArea widget for the purpose of editing code for kOS. Since it's for displaying program code a fixed-width font would be ideal. If I had to I could try coercing a proportional font to behave like a fixed width font by setting the GUIStyle's fixedWidth and fixedHeight fields and seeing if that will work. But I suspect the result will look quite bad, as it usually does when trying to do that with a proportional font. The kOS plugin uses a c-64 like font but it does it as raw bitmap textures it's pasting directly onto the screen. I doubt that would let me use it with GUI.TextArea widgets.

I was trying it using the "easy" file which was misnamed because it's harder. When the science station never enters Ike's SOI, it takes more fuel to rendezvous with it.

How on earth did you get the space station orbit to have a temporary capture by Ike? I got that to happen once with the old file and realized I was cheating because I was putting the ship under direct control before Bill was on it and that wasn't allowed, so I started over fresh wiping everything and re-getting the download (I say "the" download because at the time there weren't two of them) and the darn space station never did it again on subsequent tries. Getting that capture to happen would greatly help reduce fuel usage and I can't recreate it. Ironically you've named the version where the capture is designed to never happen as "easy" despite the fact that it takes more fuel that way.

set target to Mun:name. Trying to make docking scripts possible is current top priority, if I understand erendrake correctly. One problem is how TARGET needs to work seamlessly on three different types of object: Bodies, Vessels, and Docking Ports. Frustratingly, although all three of those things share a common C# Interface in the KSP API called ITargettable, not everything about them that they share in common is inside ITargettable.

Something seems broken about the scenario file and I'm not sure what it is: More than half the time when I try to load the game, Bill's feet are glued to the ground of Ike and he won't walk - he can only rotate in place. I have to keep killing KSP, deleting the scenario directory that was created, and re-run the game and restart the scenario. I have to do this about 2-3 times before getting a start condition that actually works and loads right.

You're not alone in that decision and I don't blame you. I used to make Minecraft server mods and getting them to transfer to Curse was a pain, especially as it was not well documented what you were supposed to do, and how long is normal to expect it to take to get approved, and so on. When you need to hotfix something, it's very annoying that there's a day's delay in putting it up on the download site.

Okay I don't have the solution, at least not for hard mode. I'm not 100% convinced it's possible. I'm trying to run the numbers but I think given the mass of the science station at its minimum size with everything undocked, and the total amount of fuel in orbit around Duna, there's not enough to achieve the DV for a duna-to-kerbin transfer.

Okay thanks. Then in that case I think I've got the solution. I just have to re-do it because of ... well.. a trap you put in there that I won't mention publicly because it's a spoiler, but it was a mean trap I fell into.

I need a rules clarification on this point (boldface mine): Presumably this means rules don't require Bill to stay in the lab all the way to Kerbin's ground, otherwise it's impossible for him to live without the lab surviving too. So when do the rules allow him to leave the lab again? Upon entering Kerbin's SOI? After a stable Kerbin Orbit? During atmospheric re-entry? What does "in the science lab back to Kerbin" exactly mean?

Well if it does go away I have to say it was a fun thing to use as a stopgap in the meantime and I liked it. Thanks for all the hard work on it. One thing MCE might continue to have that 0.24 might not is user-supplied content. But like you said, we have to wait and see what 0.24 turns out to be.

Question: What are you looking for as the method of proof that it happened? Screenshots along the way?

Any idea what will happen to this mod in the future when 0.24 comes out and (supposedly) has its own money game mechanic?

Whether or not Unity is threaded is irrelevant. What matters is whether or not KSP is threaded. KSP is calling the update and the flybywire, not Unity.

Thanks for all the help on this. I've got it done now, and here's the demo of what it looks like:

Does anyone know how to ask the KSP API to tell you what the user setting is on the main KSP settings screen for the minimum number of physics ticks per second? I'm wanting a way to make a mod behave "nice" by limiting how much work it allows itself to do per update before returning, and scaling the amount of work it chooses to do based on that user setting.

I want to make a coordinate system document. Months ago I wrote this up: http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP I'd like to put equivalent information on the more official KOS_DOC pages, but in the meantime since I wrote that I've discovered a few other weird things that make it even more complex than I realized at the time, so I have to redo sections of that information. I'd like to get user feedback on this: (1) When learning to write kOSscript, what did (or still do) you find most confusing about the coordinates and directions that you feel really would have helped to have been documented? (2) What support from kOS itself would have helped you, as a feature to add to the mod? For (2), I'm already thinking that I'd like to provide direct conversions into different reference frames - for example a function call to transform XYZ vectors into an East,North,Up vector system, and visa versa (mostly useful for landing). Right now the only way to do it is with a block of matrix transformation math that you have to carry out manually in kosscript code. Another thing I'd like to see is a way to transform any rotation into a unit vector, and visa versa, with a single function call. (Both of these are, essentially, cases of moving matrix math into the mod itself where it can use the Unity API to do it more quickly, and in some cases Unity will farm out the matrix math to the hardware GPU to do it even faster).

I am forever annoyed that KSP keeps altering the XYZ frame of reference during play. I've added a change (that I hope will make it into kOS soon) that lets you view the actual vectors drawn on the screen in 3D space to help make sense of it all. In so doing I discovered an annoying feature that was causing my attempts to make a simple inclination correction script (for the first step of doing a rendezvous for eventual docking) fail. What was making it fail is that I calculated the normal vector to my plane of orbit, and the normal vector to my target's plane of orbit, and stored them ahead of time and assumed that it doesn't change until you start thrusting. Because they aren't supposed to change. The normal vector should be the same direction no matter where in the orbit you are. But it was changing, becoming as much as 4-5 degrees off by the time I hit the ascending or descending node to make the burn. It was using the normal vectors to calculate the position of the node wrong and missing it. I wasted a lot of time trying to figure out what was wrong with my math, checking and rechecking and not finding a thing wrong with it. In the end, it turns out that what was wrong was this: Between the time when I calculated the normals and several minutes later when I used them, KSP had rotated the universe a few degrees around the Y axis, effectively changing the direction that any previously calculated XYZ tuple is pointing. The direction that V(1,0,0) was pointing a few minutes ago was a few degrees off from where V(1,0,0) was pointing now. Therefore I couldn't use the mathematically correct assumption that the normal to your plane of orbit doesn't change. It does change in KSP, effectively, because the axes won't stay in a fixed orientation. Therefore the fix was to continually recalculate the normal vectors in a lock so when the universal reference frame rotates, I get new normal vectors using the new orientation. I had the same problem when trying to draw vector arrows on the screen. I have to continually re-draw them because the damn universe keeps moving and rotating. And it's the underlying KSP system that does this, so you'd get the same problem with all languages, not just KOS. You just need to be aware that any XYZ vector is only stable for a half a minute or so after you calculate it. If you need to read the vector and do something with it over a period of several minutes while you are drifting in orbit, you'd better keep regenerating it just in case the universe has rotated a bit. I tend not to use R() rotations much but I suspect the same thing is true of them too, since they represent rotations from the Z axis direction, If you say this: SET DIR TO R(30,0,0). Then it's likely that a few minutes later DIR isn't pointing the same way it was before and it will be a few degrees different. Not enough to notice for crude operations but for precision operations (like trying to get the inclination down to less than 0.2 degrees) it matters and you need to make sure that DIR is a lock rather than a set. To test what I'm talking about, get your ship into a Kerbin orbit that goes from a periapsis of about 80km to an apopasis of about 120km. Then at the apopasis, issue the command LOCK STEERING to V(1,0,0). Make note of where that points to relative to the navball's orbital prograde marker. Then timewarp a bit, then come out of time warp for about 30 seconds, then timewarp a while, then come out of time warp for about 30 seconds, and so on until you've make 3-4 orbits. Then wait until you get to exactly the apopasis again and look at what your LOCK STEERING TO V(1,0,0) is now doing. It will be pointing a little bit off from where it was before because the X axis isn't pointing the same way.

Ahh. The fact that the pilot is supposed to be IVA the whole time is what I didn't get. I though the screens just duplicated what the pilot had anyway so ground control was entirely redundant.

There aren't locals of any other type either in kRISC. The .locals section of CIL has no analogy in kRSIC (yet?). And they still are in *a* stack, otherwise recursion wouldn't work right. (And technically peeking under the top of the stack is not stack manipulation as you're reading. not altering, the stack.).

The kRISC system isn't *entirely* open-ended and generic (yet?). There's things basic computers can do that it can't (like peek under the top of the stack to look at local variables stored there), which would make cross-compiling from other languages currently a bit hard to do. It's hypothetical pie-in-the-sky thinking on my part to have mentioned that. It's a nice longterm future idea - not anything to expect any time soon. But a more short-term idea would be that if the compiled code could be looked at as assembly opcodes it would help debugging greatly, and *hypothetically* one could actually write directly in kRISC assembly - not that I'd recommend it.

That would be so cool. Actually, what I'd really like to see is that if that's done, then the disk file should store the op codes in a human readable assembly-like ascii format (but one that's simple enough to be quick to parse back in), rather than as a binary dump. Not only is this just nice to let people see what's under the hood of their programs, but it also opens up the chance for other languages. Someone could make a different high-level language that isn't kosscript and parse the result into kRISC assembly opcodes for kos to run.

I think it's a KSP restriction. It doesn't let you target a body that is your SOI body or your SOI body's parent or grandparent.

I don't get it. What does this mod actually DO? The first page description is a list of changes, not a description of the mod's purpose from the ground up. So it displays things on other screens but how does that help make it a l LAN party tool if those screens are just read-only content and you still only have one player in control?

The balance works fine if you're playing career mode not sandbox, because you don't get access to those engines until the later part of the game. So there's plenty of reasons to use the other rockets for a while - because they're all you have.