Dunbaratu

What is the definition of an "orbital period" for a hyperbolic trajectory? Is it "imaginary number" or is it "infinity"? If it's "infinity", then that's your answer. The highest possible orbital period is infinity. And speaking of floating-point problems. The IEEE standard for floats and doubles does in fact have a definition of how to store a value of "infinity", so it's possible to *actually* have that value in the game, depending on how they implemented it.

Most importantly, not only say what the EULA says that offends you, but specifically *what the difference is* between this version and the previous one, since your post hinges on the claim that its a new change that is the problem. It may be nothing more than the difference betweenTake 2's lawyers writing up standard boilerplate paragraphs the way they're used to instead of SQUAD's lawyers writing up standard boilerplate the way they're used to. Or it may be a big deal where actual rules have changed. But if you can't be bothered to mention what the important difference is that triggers your outrage you can't really expect others to follow suit.

Does CKAN get the version info by reading the kos.version file live from GitHub repo from the release tag, or does it get it by extracting the release's ZIP file and reading the kos.version file from inside the ZIP? It matters because if it reads it from the tag, then it's impossible to fix this without making a new release because I can't retroactively change what kos.version looked like back when the release tag was created. EDIT: Oh, I see - your PR was a PR to the CKAN repo, for manually editing CKAN's database, not a PR to the kOS repo. Thank you for doing that. EDIT: I ended up having no choice but to entirely delete the old release v1.1.0 (which was mis-labeled as v.1.1.0) from our github page. Now let's see what CKAN thinks of that and if it will *now* find the correct v1.3.3.1 release for KSP 1.2.2). I had to delete it because Github was lying in its user interface. When you click "edit release" there are several fields to edit. Most of them when you edit them they cause the release to edit in-place. But not the topmost field. The one that names the release (v.1.1.0), when you edit it, does NOT edit the release like Github claims. It then replaces the old tag with a brand new tag with the new name, and deletes the old release and replaces it with this new one, which would be fine, but then it claims the resulting release is now the "Latest Release" when it's not. That's not the same thing as "editing' a release at all. After that screwup, I had to remove v1.1.0 entirely otherwise the releases page contained the lie that v1.1.0 was the "Latest Release" when it wasn't. It was an edit of an earlier release but it got reported to the user like it was new. Leaving it there would have caused users to download a very old release instead of the more recent one because github was lying about which one was the "latest" release. Apparently github has no way to change the order of releases to make that "new" release look older like it really actually is. I'd rather remove it entirely than be telling people to download an obsolete release as if it was new.

Yeah that can be a problem and I sadly don't know if I can fix it. But I'm seeing neither 1.1.3.1 nor 1.3.3.1 in CKAN. CKAN shows 1.1.0 for KSP 1.2.2 installs, which is quite old. EDIT: I fixed the 1.3.3.1 just now to 1.1.3.1 but I doubt that will be enough to deal with it. EDIT: I also edited the MIN version as you suggested for all relevant branches that go with those tags, however the tags themselves can't be changed because they're a snapshot of what the branch used to look like at the time they were made. I'm not fluent enough in Git magic to know if I can engage in a bit of historical revisionism and change a tag's snapshot of what the branch looked like back when the tag was made. But even so, the problem that this would have caused would be (I assume) CKAN thinking the release applies to old versions when it doesn't. The problem I have is the opposite. CKAN is *refusing* to allow a release to show up for an old version that should allow it.

I'm having difficulty with getting CKAN to support the idea of a mod that has two active public releases on github, one for KSP 1.2.2 and one for KSP 1.3. Can someone help me by either: 1 - Helping figure out what I'm doing wrong. or 2 - Saying flat out that CKAN doesn't support this idea so I stop trying. The situation is this: We just released an update for kOS. I wanted it to be available both to people working in KSP 1.3 and to people still stuck on KSP 1.2.2 (realism overhaul people, mainly). I have two variants of the kOS project set up, one with KSP 1.3 DLLs and one with KSP 1.2.2 DLLs, so I can compile both ways. So the order in which we did things was this: Step 1: Make the KSP 1.3 variant, updating all the relevant version files and cutting a ZIP and making a release/tag on github. This ended up being release kOS-v1.1.3.0, at this URL (click here). Step 2: Make the KSP 1.2.2 variant as a "back port", in which we take the working kOS-v1.1.3.0 made in Step 1 and add a few edits on top to put it back into a state that will compile on KSP 1.2.2 (mostly KSP 1.3 added an additional argument to all dialog boxes that KSP required - I took those edits back out again so it would compile for KSP 1.2.2) These edits ALSO included changing all the version number mentions in the code (the AssemblyInfo stuff for C#, as well as the version files for AVC and CKAN), so this version is called kOS-v1.1.3.1 (as opposed to kOS-v1.1.3.0). This version was released the next morning at this URL (click here). It may seem a bit odd that the kOS release with the larger version number (1.1.3.1) is for the KSP with the lower version number, but this is because that more accurately reflects the chronological order the releases were done in. We did the KSP 1.3 one first, then added edits for KSP 1.2.2 on top because this was far ,far easier than selectively adding all PR's *other* than the ones for KSP 1.3 changes to the older version. Now, I checked, and the tag v1.1.3.1 on our github project (the one for the KSP 1.2.2 release that came out later) does have it's version of the GameData/kOS/kos.version file set up for KSP 1.2.2 and NOT for KSP 1.3. I also checked and this is the same as in the ZIP file we attached to release v1.1.3.1. The kos.version file definitely says this version is for KSP 1.2.2. But it looks like CKAN is still culling kOS-v1.1.3.1 from the list when viewing an install for KSP 1.2.2. It doesn't appear no matter how many times I refresh, and I assume that if I've waited more than 24 hours that means CKAN should have updated by now, so clearly it's not working (and yes I did refresh my local CKAN).) Is there something I've set up wrong here, or is this an idea that CKAN just doesn't really support?

The news is reporting a large earthquake in Mexico City. To the people working at SQUAD: I hope you and your families are alright.

I did that in the version file, but I can't test it without putting it out there live and just waiting to see if it worked. I have to wait for CKAN's regularly scheduled spidering to find it.

Backward version v1.1.3.1 for KSP 1.2.2 also exists now. Do NOT USE v1.1.3.1 on KSP 1.3. For KSP 1.3, stick with v1.1.3.0. Despite having a higher version number, v1.1.3.1 is actually a backward port for the older KSP version. I had a long debate with myself over the version numbering. Because the 1.2.2 port had to be developed *after* the KSP 1.3 modern version was ready, it should have a higher number. But because it's for an OLDER version of KSP it should have a smaller number. Which of these two needs wins?? In the end I went with the chronological order. It was made later, so it gets a higher number. But I still fear this may confuse some users It confused Spacedock for a while - it thought kOS was now an obsolete mod until I figured out how to coerce it into using the lower version number as the "official" download. If you need the backport, I recommend using Curse or Github to get it instead of SpaceDock. Spacedock is a bit less friendly to the idea of multiple current "correct" versions. It works but it's harder to find them. I hope CKAN understands the new versioning and doesn't get confused by it, but I won't know until about a day from now when CKAN updates itself.

Version 1.1.3.0 has just been released. I don't have the patience to fight with the KSP forum editor to turn this into nice pretty bullet points, so here's the raw ascii changelog: # v1.1.3.0 (for KSP 1.3) Bug Swatting Release For this release we instituted a rule partway through that only bug fixes should be allowed (some of the first few changes were enhancements rather than bug fixes, but after that, its all bug fixes). This was in a vain hope that doing so would get a release out faster than normal. ### BREAKING CHANGES (Can't think of any.) ### NEW FEATURES * Terminal input using any Unicode character, not just ASCII. (Technically not a new feature, but a bug fix to a feature from the previous version, but since the bug made the feature never work *at all* in the past, it feels like a new feature). [pull request](https://github.com/KSP-KOS/KOS/pull/2062) * New StartTracking suffix for "unknown objects" (asteroids). [pull request](https://github.com/KSP-KOS/KOS/pull/2077) ### BUG FIXES * A large refactor of how the various flight control methods track which vessel they control. This appears to have fixed a lot of bugs where kOS lost the ability to control the ship unless you reloaded the scene. (After a docking, undocking, staging, vessel switch, or scene switch, this would sometimes happen, but not consistently enough to be easy to debug). [pull request](https://github.com/KSP-KOS/KOS/pull/2100) [pull request](https://github.com/KSP-KOS/KOS/pull/2063) * Program aborts caused by external events such as poweroff, shutdown, or control-C no longer leave garbage behind in memory still hooked into parts of kOS. [pull request](https://github.com/KSP-KOS/KOS/pull/2019) * Documentation now more explicitly mentions how SAS and lock steering fight with each other. [pull request](https://github.com/KSP-KOS/KOS/pull/2111) * Documentation for GUIskin:add() was wrong. Fixed. [pull request](https://github.com/KSP-KOS/KOS/pull/2098) * The waypoint() constructor used to fail on waypoints which were *not* part of a cluster yet were named as if they were part of a cluster anyway ("my waypoint Alpha", "my waypoint Beta", "my waypoint Gamma", etc). This doesn't happen in stock, but does happen with several mods that use ContractConfigurator. kOS will now deal with such waypoints. [pull request](https://github.com/KSP-KOS/KOS/pull/2093) * Documentation that claimed obsoleted TERMVELOCITY still exists has been removed or edited. [pull request](https://github.com/KSP-KOS/KOS/pull/2067) * Trying to examine the NoDelegate object no longer causes nullref error. [pull request](https://github.com/KSP-KOS/KOS/pull/2082) * Equality operator ( == ) when comparing a Path to a Path now fires off correctly. [pull request](https://github.com/KSP-KOS/KOS/pull/2089) * GUI's ONRADIOCHANGE callback hook now no longer depends on the existence of an ONTOGGLE hook to fire off. [pull request](https://github.com/KSP-KOS/KOS/pull/2088) * Compiler no longer creates incorrect opcodes for indexed collections used as arguments to a function call that's on the lefthand side of an assignment statement. [pull request](https://github.com/KSP-KOS/KOS/pull/2079) * Font resizing in scripts no longer causes the terminal to mangle its size and width/height character count [pull request](https://github.com/KSP-KOS/KOS/pull/2081) * Signal delay progress bar (when using Remote Tech) will now resize properly when you have a nonstandard sized terminal window. [pull request](https://github.com/KSP-KOS/KOS/pull/2076) * Compile command now works properly when run from the interpreter. [pull request](https://github.com/KSP-KOS/KOS/pull/2071) * Vessel:isDead working properly now [pull request](https://github.com/KSP-KOS/KOS/pull/2070) * Stretching the terminal to a large size no longer causes the rounded corner to obscure text in the window. [pull request](https://github.com/KSP-KOS/KOS/pull/2060) * Full unicode keyboard and file save support was getting mangled by wiping out the high byte leaving only the 8-bit ASCII part left. Fixed. [pull request](https://github.com/KSP-KOS/KOS/pull/2062) * Toolbar Panel setting changes no longer require there to exist a kOS part loaded into the scene. [pull request](https://github.com/KSP-KOS/KOS/pull/2058)

Can I request a lock on a thread I don't own but the owner isn't participating on the site anymore? This is for the kOS mod, where the original thread owner is no longer involved in KSP, and I'm trying to move discussion over to a new thread where the current devs have permission to edit the first post (because the version number is quite out of date in the original thread and we can't edit it). Old thread: https://forum.kerbalspaceprogram.com/index.php?/topic/61827-122-kos-scriptable-autopilot-system-v103-20161207/ New thread: https://forum.kerbalspaceprogram.com/index.php?/topic/165628-13-kos-v1130-kos-scriptable-autopilot-system/

Opening a new thread. I will by trying to move this mod to a new thread here: This is because of the aforementioned problem that I can't edit the first post of this thread, and thus can't keep its version number up to date. I am hoping to have a release very soon now - but I had to make the new thread first because I need to know its URL so I can insert links to it into our documentation prior to release. As soon as I type this post, I will be requesting the site moderators to lock this thread, but I cannot guarantee they will actually do so because its owner is not around.

kOS Scriptable Autopilot System v1.4.0.0 for KSP 1.12.x (This is a continuation of the old thread about the kOS mod: ( 1.2.2 kOS scriptable autopilot system ).) kOS (Kerbal Operating System) is an autopilot you script yourself. kOS is to programming, what Kerbal Space Program itself is to rocket science. You don’t have to know what you’re doing to get started, but you may find yourself learning a lot by accident as you play with it. And if you already know a lot about programming, it will still be able to hold your interest. kOS is meant to scale with the skill level of the user. You can start off doing very small simple things with it, and get more and more into using its features as you go. Example: print "Launching". lock steering to heading(90,80). lock throttle to 1. stage. wait until altitude > 5000. lock steering to heading(90,60). wait until altitude > 15000. lock steering to heading(90,45). wait until altitude > 25000. lock steering to heading(90,30). until apoapsis > 80000 { print "apoapsis is " + round(apoapsis,0). wait 0. } lock throttle to 0. // ..etc... What it does kOS introduces a few new parts that each contain a simulated computer capable of running programs written in its own scripting langauge called kerboscript. The computer has powerful smarts built in to the hardware that allow it to do complex spacecraft operations in one command, thus making it possible to make complex programs with only a few lines of script text. The intent of kOS is to be a fully in-game item that lives inside the Kerbal’s universe. The program isn’t running on your own gaming computer, but rather it’s being run in a virtual machine that is simulated in the underlying Unity engine. History kOS was originally begun as a mod by a single author, Kevin Laity aka Nivekk. Although the project has undergone massive changes since then and now has a very different underlying archetecture and is under active development by a different set of people, none of that would have been possible without his original vision and work. Changelog Source Downloading: From Curse From SpaceDock Direct from the GitHub Project

One problem I have with trying to fly totally IVA is that there are places where the user interface prevents basic ship operations from being possible in IVA (that realistically would be do-able by people inside the ship, but in the game is only accessable from the right-click context menus on parts, which requires the camera to be outside the ship to use them). This includes things like pumping fuel around, adjusting engine trim (thrust limiters), and decoupling docking ports.

Okay, so when you said "funded by" a nation you meant "cost of components bought from" a nation? That would make a clearer explanation in the rules. "Funded" implies the money coming *into* your space agency (the money the contracts give you after completion) rather than the money going *out of* your space agency when you spend those funds buying parts.

Huh? Was there supposed to be some kind of required mission pack installed for the challenge that offers contracts by nation? I skimmed through trying to find one but didn't see it. How do I satisfy this bullet point in the rules when the game makes no mention of which nation is offering me funds? If I gain funding from, say, a flag planting contract, who's paying for that contract? The USA or USSR? I don't understand.

This space intentionally left blank.

Thank you - that's just what I needed. I can also put the module ec drain changes in there too to express it in wattage instead of stock's uhh.. whatever stock's is.

If I want to leave NoNonRP0 enforcement in place for all *except* one or two specific parts that I name, what modulemanager adjustments to those parts do I need to make to get them to show up? Specifically, I'd like to get the LaserDist parts enabled, as I use the distance measuring abilities of them in my rover driving scripts. (The script uses the distance readouts to figure out things like whether the rover is level with the terrain, or to read if there's a dropoff coming up ahead.) I know I'll have to adjust the electriccharge consumption to use wattage, but I can do that in the same MM config file that I use to enable it in RP0. What I don't know is what flag RP-0 uses to decide "this part is foreign to me" versus "this part is known to me".

kOS's stage command invokes the KSP API StageManager.ActivateNextStage() call. Which does fire off an onLaunch event provided an onLaunch event hasn't already been fired for this "scene" instance.

When the problem happens, is the lock steering statement in one file, while the unlock steering statement is in a different file? I'm trying to figure out how to make the problem happen.

Unlock steering should work. If it doesn't you may have some kind of a bug in your script or a bug in kOS. Are you re-locking it again somewhere else and not realizing it? Is there a misspelling like "unlock staring" or something like that?

If you do, you might want to first have a read through this github post in RP-0: https://github.com/KSP-RO/RP-0/issues/758 I made it to explain to the RP-0 people what all the settings in the kOS modue are and what the effects of tweaking them are, but it would be useful for you too if you want to use a modulemanager config to insert kOS into other parts.

Ah the relevant information missing from the original post was this then: The capsule we can see in the screenshot was unmanned. We can see there's a capsule there, but can't see that it's empty (the kerbal astronaut pictures would have been in the section of screen that was cropped out of the screenshot). All vessels need a control part that has command capabilities in order for moving the controls to have any effect (a stock KSP requirement, not a kOS requirement), but a capsule that requires crew to be a command part does not count as a command part when there's nobody in it. One solution done by the Realism Overhaul mod is to make a modulemanager config that adds kOS to the command parts rather than trying to do it the other way around (adding command modules to kOS parts).

No. Taking your question literally as "could you" rather than "would you". The person with permissions to alter the first post no longer works on the project and changing ownership of a thread is apparently something the forum moderators refuse to do.

I hope by you saying "already doing it for the new contracts" the "it" in question is merely giving a warning text, rather than entirely refusing to spawn the contract. I've done satellite specific orbit contracts many times without taking the time to place manuever nodes to plan them. (Which is why I don't agree that they belong in the same category as being unable to plant a flag. That's preventing the physical action entirely, not merely making the physical action harder to plan for.) But that's not the issue here. The step in question is not the step from lunar orbit to lunar landing. It's the step from lunar orbit *passing over* the step of mere lunar landing, and all the way to lunar flag planting. Because of how the game works and the building upgrades work, that's a much bigger step than the mere step from orbit to landing. I can do a lunar landing and return right now in the career, but I don't do it because there's no contract that rewards me for it unless I also plant a flag. As for the issue of giving a warning text, I still think just naming the contract itself "plant flag on moon" would be better. The phrase "plant flag on" includes the presumption that it involves a landing a person too the instant you read it in the list, before you even click on it to look at the details, whereas the other way around (the way it is now) isn't like that. You don't presume flag planting from the title "land on". This also would match how stock describes such contracts, which would help people moving to RP-0 from stock instantly understand what the contract is. As to the issue of wanting the AC upgrades to continue being a game gating feature, I think you could do that without the weird unrealistic flag-planting limit by just swapping which power goes with which upgrade level of the building (if you can do that). Like so: Current way: upgrade 1. surface samples upgrade 2. flags Better way: upgrade 1. flags upgrade 2. surface samples It would also make the contract in question a lot more sensible because the need to plant flags would be easier to attain. You wouldn't need to sink 1,500,000 funds into the AC upgrade just to plant a flag, but you'd still want to do so later to get the juicy science points from those surface samples. An incentive to upgrade it to the max level would still be there, but it would make a lot more sense now, and happen more spread out, rather than needing to do it before even the first landing. It makes more sense for gameplay because surface samples are a more powerful ability than flags. It also makes more sense historically because the later Apollo missions did a much better job of collecting rocks, good rocks, useful rocks, than the earlier ones did, specifically because astronauts were getting better geology training (something that makes sense to model via the astronaut complex).