Dunbaratu

Yeah. basically the definition of "current stage" that it's using is "everything connected to the currently active engines".

CKAN is great if you already know about the available mods and what they do, but it's not so great for browsing mods because you can only really search based on the mod's name. Are there any plans to improve the ability to *find* a mod you like, either by adding 'tags' fields that authors can populate, or by just making a sort of 'dumb grep' on the mods' description fields? I would actually prefer a dumb grep, with the expectation that authors can add a keyword list to the end of their description to help searching, than searching ONLY on keywords the author picked and not on their description text.

Now that I fixed the problem mention above, I'll be able to start my unmanned-before-manned career play (using kOS) on Twitch tonight: https://www.twitch.tv/dunbaratu I'll be starting in a few hours (7pm in UTC-6 timezone) if anyone is interested.

I'll be starting a new career from scratch tonight using the UnmannedBeforeManned mod to make it interesting with kOS. I figured as long as I'm doing that I may as well broadcast it on Twitch as I do it. Even if I don't get many viewers at all, I'm basically just broadcasting what I was going to do on my own anyway. Come on in and join the peanut gallery and offer up "advice" if you like. https://www.twitch.tv/dunbaratu Start time is 7:00pm tonight in Central US timezone, which is UTC-6 timezone (so, 1am UTC). I don't know how long I'll play for yet, because that kind of depends on viewership. I'll be going at least a couple of hours for my own purposes, and could keep going for a long marathon session if there's enough of an audience to talk to. Fuller description here: https://www.reddit.com/r/Kos/comments/4a0q0m/going_to_try_a_live_kosdriven_career_from_scratch/

kOS version 0.19.0 and up has changed the name in the "name = " field of the Part.cfg file for the small diameter computer from "kOSMachine0m" to "KR-2042". The old name "kOSMachine0m" only ships with the mod as a legacy fallback so you can load old saved games without the game doing a forced deletion of existing vessels due to them containing a now-missing part. This rename has had the effect of effectively breaking that part in the tech tree in UnmannedBeforeManned. UnmannedBeforeManned, from the look of it, is meant to give you that part right away at the bottom of the tech tree at the start of the career, but it's trying to give you the old named part, which has been disabled in the VAB/SPH in favor of the new version. The new version is identical in functionality to the old, but the old one had some messy mesh and attachment points on it that have been refined. Sorry for the 'breaking' of the config to this mod, but the new version had to be given a new name in order to prevent old vessels already in people's saved games from trying to be rebuilt using the new part's dimensions and attachment points. I think it can be made compatable with kOS v0.19.0 and up by changing this line in UnmannedBeforeManned.TechTree.cfg from this: @PART[kOSMachine0m]:NEEDS[kOS,!SETIctt,!ETT,!OpenTree,!RP-0]:AFTER[kOS] { @TechRequired = start } to this: @PART[KR-2042]:NEEDS[kOS,!SETIctt,!ETT,!OpenTree,!RP-0]:AFTER[kOS] { @TechRequired = start } I *think* - I haven't tested to prove it. I only just started playing around with UnmannedBeforeManned today and only just now realized what the reason may have been for that part not working right. The effect I was seeing is that the R&D center said I had the part unlocked and could use it, but in the VAB the part wasn't there. EDIT: I just verified that the edit did fix the problem, although I'd leave both versions in there for legacy support.

There's a part of me that wants to replace the outline-smiley-face and filled-smiley-face images at chr(1) and chr(2) with little kerbal icons. Just because in kOS at the moment, the underline cursor is using chr(1) (which is wrong, I know) and when used with the codepage437 font that turns the cursor into a little happy face. I'm tempted to not fix it at all, and leave it like that.

The cause of the problem with blocks for letters was found and fixed. We released a new version just to fix it. Are you on kOS version 0.19.1 ? if so then update to 0.19.2 and it should make the problem go away. If you are already on version 0.19.2 and still have the problem, then please tell us because that would be a different, new bug then.

It looks like you hit the exact same issue I did in v0.19.1 of kOS. To prove whether or not this is the case, try changing your graphics texture settings in KSP (the value that has choices "full", "half", "quarter", and "eighth".). If it only looks right at "full" and looks wrong at all other settings, then you have the same problem I had. The fix for me was this: when calling the constructor for the Texture2D objects that hold the letter images, set the "mipmap" argument to false.

That looks like it could literally be used directly in kOS as-is with the only change being to change the black pixels to transparency pixels. The layout of the letters in the grid is already exactly correct. Edit: yes I just tried it and it works as-is with the only edit to the file being to bring it into GIMP and tell GIMP to turn all black pixels transparent. It did notice that the font doesn't scale *down* very well, so at the default terminal size of 8x8 it looks patchy and some of the lines in the letters are missing, but when the terminal font is resized to 10x10 or higher, it looks good.

The terminal text being solid blocks is a bug in version v0.19.1 that just got fixed and a release is out tonight called v0.19.2, that you can find at the links mentioned in the first post in this thread (but the one on the Curse site might take a few hours to show up - they usually don't update immediately when I upload it. I don't know what you mean by "reformat as usual". I don't recognize that statement.

kOS inherits the coordinate system from the base KSP game, which does some strange things. Vectors and positions use a reference frame in which the x, y, and z axes usually have nothing to do with which way your ship is pointed. They're the way the universe itself is oriented, and even that isn't fixed in place because of some of the tricks KSP does to switch reference frames around. More explanation is here : http://ksp-kos.github.io/KOS_DOC/math/ref_frame.html#ref-frame Directions are represented as rotations around these axes, which (and this is the part I do not like and it pre-dates my involvement in the mod) were named for some inexplicable reason, "pitch", "yaw", and "roll" despite having nothing to do with what those words mean in your ship-centric thinking. All they really mean is rotation around x, rotation around y, and rotation around z. Since the x,y, and z axes don't align with your ship, calling these things "pitch", "yaw", and "roll" is a bit confusing. This old video walks through some of how the rotation system works, although you have to listen to me ramble on a bit. It may help make things make more sense.

The first post of this thread contains links pointing to the locations to download the ZIP file from. Once downloaded, you can "explode" the ZIP and copy its contents into your Kerbal Space Program folder, where it will create a GameData/kOS folder for you with the contents inside. Allegedly CKAN will let you click a button to auto-update if you have an old version of the mod, but sometimes CKAN gets a bit flaky. Your mileage may vary.

New Release : I can see clearly now. It's not terminal. v0.19.2 From the usual download sites - see first post in the thread for the locations to obtain it from. This release is here primarily to fix a problem that made the new v0.19.1 terminal unusable for users who have to use low resolution texture settings in the Unity graphics configuration panel. BREAKING Nothing new breaking in this version is known about. NEW FEATURES New alias KUNIVERSE:FORCEACTIVE() can be used instead of the longer name KUNIVERSE:FORCESETACTIVEVESSEL(). More robust use of the font_sml.png file allows for replacement of font_sml.png by the end-user. (However this may only be useful for a limited time, as Unity5 might make us implement the font differently anyway.) BUG FIXES New terminal now works again at low texture resolution settings (https://github.com/KSP-KOS/KOS/issues/1513). New terminal shows grey color on power-off again (https://github.com/KSP-KOS/KOS/issues/1525). Terminal now shows a boot message that mentions the documentation URL (https://github.com/KSP-KOS/KOS/issues/1527). Fixed a situation that could make KSP itself crash if a script attempted to perform an equality comparison on types that hadn't had a meaningful implementation of equality defined. (Instead of a proper error message about it from kOS, kOS got stuck in recursion.)

I noticed your github page doesn't contain the font image PNG file you're using to get the codepage437 symbols. I was wondering about permission to use it for a test I'm trying to carry out on kOS itself. I just made a change to support making a drop-in replacement for the font_sml.png file that kOS ships with that would (in principle) let you replace it with any other font image of your choosing provided that you adhered to the following pattern: - The file must contain exactly 16 letter pictures across the width. So for example if the image file is 128 px wide, then that means each letter image is 8 px wide. If it was 192 px wide, then each letter would be assumed to be 12px wide. - Each letter picture must be square (pixel width = pixel height). It can get stretched when displaying, but the texture file needs it to be square. - The ascii codes ascend starting at zero in the upper-left of the image and counting width-wise first then row-wise (e.g since it is 16 letter images wide, that would mean that, ascii code 65, for example, is on row 4, column 1 of the image (counting from zero, that is) - The height can be anything as long as it is an exact integer multiple of the letter cell size (image width / 16). How big it is will determine which ascii or unicode chars you can print. Hypothetically you could support all of unicode if you made an image file that was really REALLY tall. Anyway what I'd like to try is taking your font image and manipulating it into the format mentioned above and seeing if kOS will work with it, to prove that the system is working. I toyed with adding codepage 437 support, but have been balking at doing it "officially" because we'd like to go to a full Unicode support some day once Unity starts letting us include proper font files. That would then break backward compatibility with scripts written to assume codepage 437 is in use, because Unicode uses those codes for Latin-1 instead and puts the box-drawing chars in a higher block. But if we let users put in their OWN font file, then that potential future-compatibility problem is their own fault so to speak and we don't have to worry about supporting it. Here's an example I cooked up today: http://i.imgur.com/vsqfssv.png

@Autochton - Here's something to get you started for making a kOS script query that field: Caveat: I have NOT tested this at all - this is thrown together from examining ModuleFuelSystem's github page for a brief few minutes. I haven't used ModuleFuelSystem myself so can't really quickly test if this is right: // a bit of kOS code example: // This assumes you already have a variable called 'thePart' // which has been assigned to the part you're interested in // querying for. local propStat is thePart:GetModule("ModuleEnginesRF"):GetField("propellantStatus"). if propStat = "Very Stable" { print "do something here.". } else if propStat = "Stable" { print "do something here.". } // .. etc for checking the values NathanKell mentioned in the post above.

Thanks to all who replied with the further details on the terminal font problem. Once TDW reported to me that the problem only happens when the graphics texture settings are less than max (i.e. half, quarter, or eighth), it was fairly quick to find the cause and fix it. But now I need to wait for another kOS dev to review my (very very small) fix and approve it and we should be able to get the fix out soon.

kOS has a generic system for getting its hands on the data that is displayed in the right-click menus of parts, under the principle that if somebody wrote a mod and allowed the user to witness the values on the part menu, then that probably means they don't mind a script getting its hands on the values too. But things that are not displayed there are, by default, not exposed to kOS scripts because we can't exactly go around asking hundreds of mod developers which things they'd like to expose to kOS scripts and which they wouldn't. (Just because it's "public" in C# terms doesn't mean a mod developer meant for the end-user to bypass the intended user interface to just change the value under the hood directly, or so went our rationale here.) So we just use that as our generic design principle: If the mod exposed the value to the user on the menu, we'll take that as permission to let the kOS users read it via the KSPField, and if the mod let that KSPField be settable, and it is currently enabled, then that also means the kOS script can edit the value (but only within the rules of that KSPField widget - i.e. if it's a float field, kOS enforces that a script trying to change it gets the value clamped and rounded off in the same exact way the user interface slider would enforce.) However, that generic system, due to its generic-ness, can be a bit wordy for a script to use (first get the part in question, then get the PartModule within the part, then get the field within the PartModule.) Some other mod developers have gone out of their way to add AddOn modules to kOS to help it support their mod in a way that can bypass the generic partmodule methods, but it's not strictly necessary just to expose a few fields to kOS. If all you want is to expose some fields, making them a visible KSPField on the rightclick menu should be enough.

Well, that kind of sucks. It's weird that the 3d texture settings are applied to purely 2D gui widgets, *and* that it's applying to cases where the size is exactly the same as it was before when it worked (8x8). I told Unity to "please stretch to fit", but when the size is 8x8 that stretch is a ratio of 1:1 and not really a stretch and hypothetically *should* have come out the same as before. Okay well I'll do some googling about Unity and see if I can fix it easily, and if not I'll come up with a different way to do it. One possibility is for me to "trick" your settings into doing the same thing even when at low texture settings by just using an enlarged variant of the font texture that's much bigger than it needs to be and just draws each "pixel" in a 8x8 pixel big block. (Thus when sampling only some of the pixels the full information is still there.)

Can all of you mention the OS you are installed on, whether KSP is from Steam or not, and Where you obtained your ZIP for kOS from (i.e. curse, spacedock, CKAN, or github.) Also, if you are running 32bit or 64bit, and if it's Directx10, 11, or openGl, and the graphics card it's on? This looks for all the world like the font image file didn't get installed right. But the reason for asking for all that information is that if it is not, then there may be a specific platform or graphics configuration that refuses to load the textures properly.

I doubt there's a legal issue with the name, but I'm not *technically* the project owner. Erendrake is, although he's been so busy lately most of the work on 0.19.0 was done by the rest of us and he just posts the final announcements. Right now kOS doesn't expose that much to other mods, but it totally could if there was a good reason, and this sounds like a good reason to me. Right now when we open the editor we just launch an entirely new instance of `kOS.Screen.KOSTextEditPopup` and give it the filename and it pulls that into one big string and works with it from there. The rest of the mod ignores it until it is done and says to save the file. So that could totally be shunted off into someone else's code instead. Archetecturally it is doable.

Hmm. Many people have made syntax highlighters for other editors, and one person is trying to make an editor from scratch, but making it be an in-game editor opens up some interesting possibilities. Because the editor and the kOS mod would live in the same process in memory, it may be possible to have your editor query the kOS mod to ask it things about syntax and the like. This is intriguing.

So what is the means of getting on the list of people in the steam beta? I missed the window of time to get in on the Experimentals group. I'd really like to get as much of a headstart as possible on making the kOS mod become KSP 1.1 compatible.

Oh, THAT. Predicting *how long* it takes to get to a particular point (which is really the same thing as predicting what point you will be at at a given time, just in the inverse) is a mathematically famously messy thing. (NOTE: It's not messy for a perfectly circular orbit. It only becomes messy when dealing with an orbit that has some eccentricity to it.) It's one of those cases where intuition is telling you it *should* be a simple formula but it just isn't. It's one of those that requires using a numerical approximation method that asymptotically *approaches* the right answer after looping several times. This is what's happening inside the PositionAt function (which is why we provided it as a function. It's an ugly one to do in kerboscript itself because fast loop iteration is important when doing numerical methods like that.) What you might be able to do is use the built-in PositionAt(), and then once you have an XYZ position from that, it use it to work out the angle from there to the periapsis point (which is the definition of trueanomaly, of course). I'd come up with some wacky vector angle calculation based on that, but that's because I like vectors. There's probably other ways too. (The vector solution involves getting the angle described by the 3 points: positionat(eta:periapsis), body:position, positionat(futuretime), which you can do with a VANG(), and then figuring out if it's in the latter half of the orbit (so you'd need to subtract it from 360 to get the real trueanomaly since VANG can only report the 'nearest' angle, that is the one that's <= 180).)

Each moving object has an `:orbit` suffix with that kind of information on it. For example: ship:orbit:trueanomaly. There's more of them here: http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbit.html The documentation 'search' bar works pretty well for stuff like this. I jumped to this page literally by just typing 'true anomaly' into the search box on the upper left of the docs page.

It occurs to me that we *could* include the html tree of directories in the ZIP file in future releases. All the URLs are relative and do work in a `file:///` context. In the meantime you can clone the github repository and then on your local copy do `git checkout gh-pages` to see the html docs. A while back someone was working on a LaTEX output for our docs but I don't know if that ever got done.