Dunbaratu

January 21, 2021

I maintain the kOS mod. I recently installed Rocket Sound Enhancement and discovered that it dampens kOS's sounds just like it dampens rocket sounds. (If you're not familiar, the sounds in question are meant to be UI sounds on a text terminal, like beeps and raspberries. The "computer" is a PartModule inside a Part on the vessel, and Rocket Sound Enhancements appears to be using that to decide its sounds are a physical sound effect in need of dampening.)

Do you have any suggestions for what I can do to set up the kOS sounds differently so Rocket Sound Enhancement doesn't dampen them? I have them obey the UI volume slider in settings rather than the vessel sounds slider, but that doesn't seem to be enough. I think I "moved" the audio sources outside the kOS GameObject into a "parentless" GameObject (hoping this means they don't look like they're inside a Part) but that doesn't seem to have any effect either.

January 20, 2021

3 minutes ago, danielboro said:

can any one tell me what is the typical shirking by using compile?
today was the first time i tried it and it didn't shrink mach.
a 5100 got to 4950 and a 2024 to 1900
i was hoping for more space saving.
is this the expected shrink? (~5%)

Depends on the original program. if you have a long variable name and use it again and again, it can be crunched a lot. if you have short names, or if you don't indent much, or you do have long names but don't repeat them much, you don't see much help.

January 19, 2021

This is my official request to rename my forum account to "Dunbaratu".

Reason: I made my account in these forums long before I started doing things for the kOS mod including a youtube channel, twitch channel, guthub account, and discord server. For those other places I decided to go with a pseudonym so as not to directly "dox" myself (I mean, yes, you can do some digging around and figure it out but I didn't want it to be easy low-hanging fruit for zero effort). My chosen pseudonym for all of these other places has consistently been the name "dunbaratu", and that is the name people are more likely to search for when trying to find me for Kerbal-related reasons.

Ironically although "dunbaratu" began as a reason to avoid doxxing, now I want to use it for the opposite reason - to make it *easier* for people to find me by using the same username across platforms.

January 19, 2021

kOS v1.3.1.0 official announcement

(See First Post in this thread for links to download it.)

There's a lot of small changes over the last year that have added
up to a big release. This release supports KSP 1.10 and KSP 1.11.
It has no specific KSP 1.11 changes but it has been tested and it does
work with KSP 1.11.

(NOTE ABOUT KSP 1.11 - If you want to put a kOS part into one of
the new cargo inventory slots that came with KSP 1.11, you can do so
but remember to FIRST attach it to the vessel in the VAB/SPH so you can
adjust the disk space and boot file settings, then detach it from the
vessel and drag it into the cargo slot - that way it has the settings you
gave it. If you just drag it directly into the cargo slot from the parts
bin then it only has the default values.)

The most important changes are probably in steering and control.
Cooked steering shouldn't waste as much RCS as it used to, and if you
are using raw control you now have the ability to set the player's trim
settings for yaw, pitch, and roll so you can steer using those and
not completely lock the player out of control. There is also a
panic button for telling kOS to suppress all of its controls if the
player needs to take over the controls regardless of what the script
is doing.

As always, recompile KSM files with this release. Especially as there
was an important KSM bugfix.

BREAKING CHANGES

TimeSpan used to mean a fixed stamp in time (the name was not
really accurate). Now there are two types, TimeStamp and
TimeSpan, and the one that USED to be called TimeSpan
is now called TimeStamp, with TimeSpan now being a new
type that didn't exist before. This could affect scripts if
you ever did a check for :istype("TimeSpan") (because of
the rename) but shouldn't affect anything else.
Even more than usual it's important to recompile any KSM files.
A major bug in how KSM files were written was discovered that this
release fixes. There's a chance your existing KSM files may
already be wrong. If you have any bug reports about a KSM file
not working right, please try testing again with this release by
recreating the KSM file. There's a small chance you might have
had the bug this release fixes. (Look for "KSM" in the bug section
below.)
If you are using the output of SteeringManager:WRITECSVFILES,
be warned that output now has a new column in the second-to-last
position, the MinOutput column. That means the MaxOutput column
has shifted one position to the right. This should only affect
people who are analyzing that data with external software.
In order to support Kerbal Alarm Clock version 3.0.0.2 or higher
it was necessary to break compatibiltiy with versions of Kerbal
Alarm Clock that are older than that. The API wrapper changed
enough that backward compatibility is too messy to maintain.
The :LIST suffix of VOLUME said in the documentation
that it returns a LIST when in reality it always returned
a LEXICON. If you relied on this and wanted the lexicon
not the list, you need to now use the new suffix :LEXICON
because the old suffix :LIST has been changed to match the
documentation and be a real actual LIST now.
Temperature tolerance for the kOS parts was way too high, making
them effective heat shields when they shouldn't be. If you had been
taking advantage of this before that might not work anymore.
CREATEORBIT() used to take mean anomaly at epoch as a value in
radians, which didn't match how everything else in kOS works.
It is now expecting it in degrees as described in BUG FIXES
below.
If you ever happend to have a string literal with a backslash
followed by a quote mark (\") that has now become a special
escaped quote char and is no longer literally a backslash and
quote mark.

NEW FEATURES

Maneuver Nodes can now be constructed with either ETA time or
with UT time, and you can read their time either as UT (:TIME)
or as ETA (:ETA). They also can take in the new Timestamp
or TimeSpan types instead of just a Scalar number of seconds if
you like.
pull request
There's a new button, "Reread Boot Folder", on the kOS toolbar
window when you're in the VAB or the SPH. This button lets you
tell kOS to re-read the boot directory when you've just added
a new file to it, so you don't have to leave the VAB and come
back for it to show up in the list of boot files.
pull request
The old TimeSpan type has been renamed to TimeStamp and
a new TimeSpan type has been made in its place. This is to
fit the design pattern where a "stamp" is a fixed point in time (a
date and a time of day) and a "span" is a time offset. The main
difference in Kerbal is whether you count years and days
starting at 1 or at 0.
pull request
Suffixes :PARTSTAGGED, :PARTSNAMED, and :PARTSDUBBED
can now be used with parts instead of with entire vessels. Doing
so searches just the sub-branch of the ship starting from that
part, instead of the whole ship.
pull reqeust
Added a new Suffix to RCS parts, :DEADBAND that lets you
finally override the game's enforced 5% deadband on RCS
controls. It turns out the deadband isn't in the controls,
but rather it's in the RCS Parts themselves and doesn't apply
to other torque sources like reaction wheels. That's why
you notice it when translating (where only RCS works) and not
when rotating (where reaction wheels do something and take
up the slack left by the RCS thrusters not responding).
pull request
Big overhaul to SteeringManager's internals:
There's been some important refactoring in SteeringManager that
should reduce the control vibrations and consequently the
RCS fuel wastage especially in Realism Overhaul (which relies
more on RCS than stock does). Also, there's some
user-settable epsilon values - if you want to change the tuning
you can adjust SteeringManger:ROTATIONEPSILONMIN and
SteeringManager:ROTATIPONEPSILONMAX.
- Dynamic Epsilon logic to reduce control jitter: pull request 2810 pull request 2813
- The stock KSP's available torque calculations are random wrong values for RCS parts. kOS now replaces that with its own calculation instead: pull request 2820
The random number generator now can be fed a seed.
pull request
PIDLoop is now a serializable structure so you can save
your PID's settings and bring them back from a file. Also
PIDloop's CSV output now has a Minoutput column.
pull request
Enlarged max allowed terminal font size to 48, to benefit
people with tiny pixels (i.e. 4k monitors).
pull request
Uses the changes to Kerbal Alarm Clock's API that started
with Kerbal Alarm Clock v3.0.0.2. (This does break compatibility
with older versions of Kerbal Alarm Clock, though.)
pull reqeust
On-Screen warning when SAS is fighting kOS: The message
appears when both SAS and lock stering have been active for a
few seconds and goes away when one or the other is turned off.
pull request 2780
pull request 2783
Emergency Suppress Autopilot: You can now click an emergency
toggle button on the kOS toolbar dialog window that will
temporarily suppress all of kOS's locked steering so you have
manual control. If you use this, the script will still keep
running and think it's moving the controls, but the steering
manager will ignore the script's commands until you turn the
suppression toggle off. This can also be bound to an
action group for the kOS PartModule if you want a fast hotkey
for it.
pull request
Part suffixes that allow you to traverse the symmetrical
sets of parts. (i.e. if you place 4 fins in radial symmetry,
and have a reference to one of the fins, you can find the other
3 fins that it is symmetrical with.)in the same symmetry set)
pull request
The player's own TRIM controls are now settable by script.
(Example use case: You want an autopilot to control an
airplane by moving the trim but not the main controls so
the player is still free to push the main control stick at
any time).
pull request
ETA:NEXTNODE now an alias for NEXTNODE:ETA
pull request
Trajectories Addon updated to support Trajectories v2.4 changes.
(Thanks PiezPiedPy)
pull request
Kuniverse:launchcraftwithcrewfrom()
(Thanks JonnyOThan)
pull request
New suffixes for the special case where a Vessel is really an
asteroid. (Thanks JonnyOThan)
pull request
Ability to read the stock game's Delta-V readouts for the vessel.
(Thanks ThunderousEcho)
pull request
New subtype for Part - the RCS part type, with information
about how its nozzles are aimed, what fuel it uses, the ISP,
max thrust, etc. (Thanks RCrockford)
pull request 2678
pull request 2809
Can now use \" in string literals for embedded quote marks.
Also can prepend the string with @ to turn this off and keep
it literal. (thanks thexa4)
pull request
New Engine value suffix :CONSUMEDRESOURCES, and new
Type ConsumedResource it returns. These
give more information about fuels the engine uses. Mostly
relevant when RealFuels mod is installed so every engine is a
bit different. (Thanks RCrockford)
pull request
Can CreateOrbit() from position and velocity (before
it only worked with Keplerian parameters).
(Thanks ThunderousEcho)
pull request

BUG FIXES

Fixed: Kerbal Alarm Clock alarms had no ToString() so when you
printed them you saw nothing. Now they show the alarm info.
pull request
Fixed: The suffix Widget:HASPARENT was documented but didn't
actually exist. It exists now.
pull request
Fixed: Primitives like Scalars, Strings, and Booleans previously
were not serializable with WRITEJSON() on their own as bare
variables. They could only be written when inside containers like
LIST() or LEXICON(). Now they can be written directly.
pull request
Fixed: KSM files would corrupt one of the kRISC instruction
operands (leading to any number of random results when running the
program) if the size of the operand pack happened to be just barely
over 2^8, 2^16, or 2^24 bytes. (When calculating how many bytes
addresses need to be to access the enire operand pack, its count
of the size of the pack was off by 3. This could make the last
operand in the pack get garbled when it loaded into memory from
some random other part of the file instead of where it was supposed
to come from.)
(Thanks to newcomb-luke for discovering the problem and the cause)
pull request
Fixed how positions of packed vessels were off by one
physics frame from the positions of everything else. This
is apparently how things are reported b the KSP API and this
had to be adjusted for.
(Thanks marianoapp)
pull request
Fix Vecdraw labels no longer showing up in flight view
pull request 2799
pull request 2804
Remove strange blank setting on the difficulty options
screen.
pull request
OPENPATH() now returns false on file not found rather
than bombing out with an exception.
pull request
RangeValue now allows use of bigger ranges and for ranges
that increment by fractional amounts.
(Before, it couldn't do floating point and couldn't do
anything bigger than 2^31.)
pull request
Fix raw control :NEUTRALIZE never having quite done
what it said it did right.
pull request
EVA Kerbals no longer have duplicate KOSNameTags when
you have the Breaking Ground DLC installed. (The problem
came from how KSP mashes two kerbal templates together
into one kerbal to put the DLC science features into an
EVA Kerbal.)
pull request
VOLUME:LIST now actually returns a list like it says
in the documentation. Use VOLUME:LEXICON to get
the lexicon you used to get from VOLUME:LIST.
pull request
UNSET now fails silently on non-existant variables as the
documentation claims it should, instead of crashing with
a nullref error.
pull request
Fixed a mistake that made it possible to process lines of
input out of order if they flood into the terminal very fast.
It was noticed in JonnyOThan's TwichPlaysKSP, which pastes
entire scripts of input into the interpreter in one big chunk.
pull request
ADDONS:KAC:ALARM[n]:NOTES now returns the right thing.
(It used to just return the same thing as :NAME.
(Thanks JonnyOThan)
pull request
The ConnectionManager dialog box at the start of a career was
repositioned to where it is unlikely to appear secretly hidden
behind other mod's dialog boxes. (Other mods putting their)
dialogs in front of kOS's and not blocking clickthroughs made
some users accidentally pick a ConnectionManager and dismiss
the dialog before they ever saw it.)
pull request
UI sound effects from kOS (error beep, SKID sounds) no longer
have an origin point in 3-D space inside the part. They are
now "ambient". This is to get sound mods to stop dampening
the volume the same way they'd dampen sounds from engine
parts, etc.
pull request
Parts no longer have excessive temperature tolerance.
(Thanks robopitek)
pull request
CREATEORBIT() now takes mean anomaly at epoch as degrees. It
was in radians before which didn't match how other things worked.
(Thanks vzynev)
pull request
Better fuel stability (ullage in RealFuels) calculation.
(thanks RCrockford)
pull request
Documentation fixes. Too numerous to mention each. You can
click each of the links below to see them all:
pull request 2675
pull request 2680
pull request 2707
pull request 2712
pull request 2724
pull request 2751
pull request 2772
pull request 2775
pull request 2776
pull request 2777
pull request 2784
pull request 2788
pull request 2791
pull request 2800
pull request 2819
pull request 2833
kOS can now handle KSP's technique of having multiple KSPfields
of the same name that resolve the name clash by only having one
visible at a time. KSP started doing this on a few fields
about a year ago and caused bugs like "authority limiter"
not working. (#2666)
pull request
kOS no longer allows ModuleManager configs to give it negative mass.
(Antimatter summons the Kraken.)
pull reqeust
ETA:APOAPSIS no longer returns Infinity on hyperbolic
orbits (While infinity is a correct answer, kOS scripts
would crash when they get infinity on the stack. So now
it says zero instead).
pull request

January 19, 2021

5 hours ago, Steven Mading said:

The "soft" release yesterday has a bug related to using TimeSpan in a few places where it should be using TimeStamp. Expect another update today or tomorrow.

There is a new kOS 1.3.1.0 that fixes this on the Github page. I won't put it on Curse or SpaceDock until it's been on Github for a day or two, just to be sure people have tried it and not complained about a major problem before I do that.

(When I do that, I'll also update the first post of this thread and make it official. But until then you can try it and report any problems.)

January 18, 2021

The "soft" release yesterday has a bug related to using TimeSpan in a few places where it should be using TimeStamp. Expect another update today or tomorrow.

January 3, 2021

For the sake of modders, one thing I hope KSP changes about the UI/UX is to have a much stronger wall of separation between what is UI code and what is API code. So the UI's only job is to talk to the API that really enforces the rules, rather than the UI code itself doing it. I've run across frustrations in the past modding for KSP 1 where I've had to re-implement KSP's main rules again in my own code (which is an awful and not future-proofed at all way to do it) because when you talk to the API directly and don't click on UI windows, you are skipping parts of the rules that are done by the UI. Like fuel transfers. Those little windows that pop up with the "in" and "out" buttons control rules about whether you can transfer fuel between tanks and how fast the transfer is allowed to flow. So if I try to have a mod that triggers the fuel transfer a different way, not through the main UI, it lets players cheat and bypass the rules which isn't the intent. Another example is that it refuses to update the KSPFields that describe Breaking Ground's robot part servo positions (i.e "this hinge is at 45 degrees") if the UI window that would display them to a user is not open. If you're not a player trying to read that field but instead are a mod trying to read that field, there doesn't seem to be a way to tell the system to give you an updated calculation of that field other than forcing the window open for a moment to trigger the UI code that updates it. These are a couple of example, but that's the general idea. It's sometimes hard for a modder to sneak in under the UI code to accomplish the same thing the UI code does, when some of the main game's logic is inside the UI code itself.

Basically that wall I'm talking about is a design principle where you view the UI/UX code as "one of several mods". They are *one way* to talk TO the game, rather than BEING the game. Given that they say they plan to do multiplayer I have high opes that this might happen. Multiplayer probably needs the same principle in place so that the server decides what is physically doable rather than the UI code in each client being in charge of that.

January 3, 2021

12 minutes ago, paul_c said:

You're right in that respect, and thank you for pointing it out.

What makes this bug in the new contracts dangerous to players (and worth pointing it out here) is that it has a very large negative penalty for expiration, and none of the other contracts do this thing with a duration being too short for using the next Hohmann transfer window. People won't be in the habit of expecting to have to read the duration to see if an excpetional weird transfer is needed because literally none of the other contracts before now required doing that. It's the complacency of knowing up until now the durations have always "just worked" and never been a problem that causes the danger here.

Usually I don't look at the duration until after I failed my first attempt, and then I start worrying that I might not have the time for a *second* attempt with a normal transfer. I never expect there to not be enough time for the *first* attempt with a normal transfer, as is happening here.

It's also the fact that this contract does not vary at all - it's 2 years, fixed, no matter what - it's not even applying any minor variation with any RNG - that makes me assume this was not intended and there's something very wrong. The system that varies the duration of contracts by various circumstances doesn't seem to be activating for these at all. They're all getting the base hardcoded duration without variation.

January 3, 2021

13 minutes ago, paul_c said:

Its vaguely similar; in that with the "send science from", its MUCH more efficient to already have the kit there and do it with 5 clicks. You aren't going to send them to the far flung corner of the solar system with 1 repair kit are you? And if another contract comes up, send another rocket??

The difference is that when taking multiple contracts to accomplish in one mission I'm going to launch but haven't yet, as I usually do, one of them can be "send science from" along with the others. That is not true for these new ones. Which is exactly the situation here. I was going to Duna to do 3 things in one mission: Retrieve Duna Stone, Plant a Flag, and Add a solar panel to a satellite. The two normal contracts did not expire on the way there. The new satellite repair contract did (with a very large negative "fail" value that overwhelmed any gain from the other two and killed the career sending funds several hundred thousand into the red.). Had the three contracts been Retrieve Duna Stone, Plant a Flag, and Send Science From Duna, all 3 would have still been do-able when I got there.

January 3, 2021

1 hour ago, Rejected Spawn said:

My insanity aside though 2 years is of course a weird time limit, just wanted to be "that guy" and point out that it's not actually impossible to handle.

While technically correct, literally no other contracts in the game expect the player to look at the duration to check if it might not let you do a vanilla Hohmann transfer in time. Thus my post here warning people. If you don't realize ahead of time that these contracts have buggy durations, you won't be in the habit of even looking at the duration ahead of time. It becomes "impossible" because you didn't even see that the duration is abnormal until quite a bit of time later after you've been time warping too much now to do it. If you don't like savescumming, that really blows to have the contract surprise you by turning red halfway through your transfer to the target and say "expired", with you going, "wait... whaaat?"

January 3, 2021

1 hour ago, paul_c said:

You're missing the point, I feel. Of course there will be no contract once he arrives, but if another similar contract pops up, he is ideally positioned to respond and do it within the asked-for timeframe.

Its similar to "send science data from the surface of Mun" (and other places) contracts - you think ahead and put a thermometer/controller on the Mun, you can do these contracts in about 5 clicks.

It's not similar. With the "send science data from..." contracts, the duration is clearly designed to let you do them with a fresh launch waiting for the next Hohmann transfer. You *can* do them faster and cheaper if you already have something there, or if you spend extra deltaV on a faster but less efficient trajectory for a new launch, but those things are not *necessary* like they are with these 1.11.0 contracts. There's clearly a major bug here. And yes it is worth warning people of this since none of the other contracts work that way and this one is an odd exception to the rule. The fact that the new contracts have much shorter durations than the rest do is something you're not likely to notice when first taking the contract. And once you see that it's terminating early it's too late since you assumed it was like *every other* contract and gave you the time to do it the normal Hohmann transfer way. (If you don't see this problem coming, your first indication that these contracts are weirdly different from the rest is *after* the duration expires and you get the red-X and go, "wait, whaaaat?")

January 3, 2021

This post is to just let the other players know about this so they don't get burned by it in their career like I did. The only way the new repair/edit vessel contracts for distant destinations like Jool or Duna are do-able is if you saw the contract get offered while you coincidentally were already there for some other reason with a crew vessel that can do the contract. The new contracts don't seem to be varying their duration depending on destination like most contracts do. They're always exactly 2 years, fixed, no matter what. This is not enough time to launch a new vessel to go there for many interplanetary transfer situations.

This is not to report the bug. I already did that here: https://bugs.kerbalspaceprogram.com/issues/26958

This is just to warn other players. These contracts can sometimes have large failure penalties so that guaranteed duration fail can kill your career.

January 3, 2021

Hopefully this gets fixed in a KSP 1.11.1 patch soon. To any players playing career in KSP 1.11.0, I wanted to drop a warning in here.

The new contracts that were added with KSP 1.11.0 such as repairing rovers and satellites, and adding parts to satellites, have impossibly short durations for interplanetary missions. They seem fine for around the Mun or Minmus, but not for Duna, Jool, etc. You take the contract and get blamed for "failing" at it (sending money into the red if it's big) even though you were never even given the time it takes to make one single attempt at it.

The problem is that All the new contracts are exactly 2 years. Hardcoded. Period. Want to repair a satellite around the Mun? 2 years - easy. But want to repair a satellite around Duna? Still 2 years. Around Jool? Still 2 years. Whatever the game normally does to vary contract times depending on the destination body seems to be not working with these new contracts, making them impossible if you take them for a distant planet.

This is the issue in the tracker:

https://bugs.kerbalspaceprogram.com/issues/26958#change-158334

December 21, 2020

18 minutes ago, CheeseForkel said:

yeah I feel dumb now.

Was that it?

December 19, 2020

On 12/18/2020 at 3:14 PM, CheeseForkel said:

In the editor and flying a craft the camera spins uncontrollably. I tried switching the camera but it kept spinning. I tried closing and opening the game but that didn't change anything. I don't know what else to do. Anyone else have this problem?

This might be an obvious thing to check you already tried but ... do you have a controller plugged in and maybe during the upgrade did the game lose the nullzone settings for it (so it now thinks an analog stick is always slightly offcenter and that's making it rotate the camera?)

December 19, 2020

8 hours ago, MineTrain said:

I have the following problem:

Since the 1.11 update, the lamps no longer save their colors when I stand on the launch pad, or save and load!

I've tried everything.

-Reinstall

-Create a new save game

-Tried without mods, with a new save game and a new game installation

-All files created by Steam are deleted and then reinstalled

How can I solve the problem or do I have to wait for an update?

There are a few issues in the bug tracker where other players have reported the same problems since KSP 1.11 came out this week.

There's something wrong with how this new way of storing light color info works. Either it is not getting saved in files or it's not being loaded back from files. It also gets forgotten in craft files so if you spend time in the VAB fiddling with the light settings it's wasted time because it gets forgotten when you go from VAB to launchpad. Not sure what is wrong but anything that involves saving/loading to a file fails to preserve these settings.

November 25, 2020

Is this a bug or is it expected behavior? ClickThroughBlocker is in focus-follows-mouse mode, and I hover the mouse pointer in an area where two windows overlap. Instead of JUST the input lock of the window on top, it's activating the input lock of both the windows, including the one that's underneath.

In the screenshot, both the two windows are created using ClickThruBlocker, with this specific version of the many overloaded variants of the Window call:

ClickThruBlocker.GUILayoutWindow(int, Rect, GUI.WindowFunction, GUIContent);

This variant is one of the ones that uses the Window's unique id integer to form the lockName (some variants use the window's title, which is why I'm mentioning which variant is being used.) In this case the two integer ids were the numbers you see in the debug window: -375264 and -376740

The screenshot didn't capture the mouse pointer, so I had to draw it on afterward in Gimp to show you where it was.

If I move the mouse to the area where the windows don't overlap then I only have one or the other of the two locks active.

The reason this came up is that I was trying to experiment with using InputLockManager.IsLocked() as a roundabout way to query which window ClickThroughBlocker has given focus to. But when two different windows can have their input locks active at the same time that technique won't quite work.

October 21, 2020

The bug tracker, at https://bugs.kerbalspaceprogram.com/ has started getting spambots posting "issues" which are actually ads.

Some of which have stayed in there a while.

Is anyone on top of this and reading the issues? I'm wondering because the spambot issues aren't being removed or closed, making me wonder if anyone working for SQUAD or Take 2 is even looking at the tracker anymore.

August 7, 2020

1 minute ago, HebaruSan said:

The bot processes only one version, the latest version, at a time. So if you release a new version and then update the metanetkan soon afterwards, old versions will be unaffected, and the latest version will take the changes as the bot sees them. Does that help?

So if do it in the reverse order from that, such that I merge the .netkan change into the master branch a few hours *before* I've cut that release from master, will it end up making the previous release of kOS get a dependency on ClickThroughBlocker (because the newer release wasn't there yet when the Netkan bot crawled every half hour and saw the kOS.netkan change in master branch)?

If so, then I have to change how I'm doing my PR for this change and split it into two PRs - one for the C# code that calls ClickThroughBlocker's API and another for the kOS.netkan dependency on ClickThroughBlocker that code caused. (Right now they're the same PR which seems sensible at first unless it would cause the scenario I described in the previous paragraph).

It matters because my dependency requires a minimum ClickThroughBlocker version number to have the features LinuxGuruGamer just added a few months ago that I'm using. If the previous release of kOS ends up falsely claiming it has a hard dependency on this new version of ClickThroughBlocker, that could prevent CKAN from letting you install it on older versions of KSP that only allow older versions of ClickThroughBlocker. That's why I'm nervous about making sure I do this right.

August 7, 2020

31 minutes ago, HebaruSan said:

If you edit https://raw.githubusercontent.com/KSP-KOS/KOS/master/kOS.netkan, that would do it.

It does, though, because it's set up to crawl your .netkan file as what we call a "metanetkan":

https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/kOS.netkan#L4

Every 30 minutes,. CKAN's bot checks that file and attempts to generate new metadata from it.

... that can be done. Yes, if you put a .ckan file inside your ZIP file, it will be parsed for CKAN metadata. This has some unique advantages, insofar as it is guaranteed to always be associated with the correct download file (I do this with my own mods). But...

Yes, we would need to remove any properties you intend to set from the .netkan file and your metanetkan, since they will take precedence otherwise. The "internal .ckan file" is the lowest priority.

The easy path is to release the new release, then update the .netkan file as needed. Bleeding-edge users upgrading in the meantime might get incomplete metadata, but ultimately everything would work out.

Thanks for the quick reply.

Will it be smart enough to NOT apply the new dependancy to older versions of kOS if I just continue with the .netkan file technique as it is using now? Or do I need to switch to the .ckan file in the ZIP to get that kind of version-specific dependency?

August 7, 2020

I have a question about how the CKAN bot crawler works.

The kOS mod is already in CKAN, but I need to add a new dependency when I make the next release (The next release will depend on ClickThroughBlocker. It didn't need it before.)

I know what edits to make to the netkan file to describe the dependency, but I don't know how to get CKAN's bot to see the change. Currently the .netkan file isn't part of the ZIP at all (it's edited "one folder up" from where the ZIP is cut from) so I assume the bot can't possibly see that information. I'm guessing that previously the mod was manually added to CKAN with a pull request but I'm trying to figure out how to make it automate the updates by having the CKAN bot see the information somewhere inside the ZIP file, like it does for the .version file. (This is a mod I inherited from others. I was not the person who originally set it up in CKAN so I don't know what steps were taken at the time.)

So my question is this - if I just start using netkan.exe to convert the .netkan file into a .ckan file, and copy that .ckan file to GameData/kOS/whatevername.ckan, inside the ZIP will that automagically make the bot update kOS's CKAN info when I make a release with that ZIP next time? Or are there other manual steps I need to do first?

Up until now, we *have* been getting automatic updates in CKAN from the information in the ZIP's "kOS.version" file, but this is a thing the .version file doesn't have in it (dependency on another mod).

August 6, 2020

On 8/1/2020 at 10:23 AM, panarchist said:

Did you read the bug? There's a simple workaround. I appreciate that @dok_377 is irritated at it not being fixed, but the devs have limited resources, and when there's a simple workaround like timewarping a second, that makes it a pretty low severity issue. Whereas fairings were just plain broken in modded installs.

The timewarp workaround only fixes one third of the effects the change caused. The other two effects it does not fix are: {1} One-to-Many transfers involving 3 or more tanks don't work anymore, making fuel balancing impossible; {2} It broke the use of fuel hoses to route around blockages like heat shields, meaning you now must play with that difficulty option turned off, as its rules are broken.) These are problems in *stock* gameplay, not even modded.

Unlike dok_377, I don't mind that the fix didn't come out immediately. It's probably an issue with dirty cached data and those can be hard to trace without just throwing away the entire caching idea entirely. But I do want to quash this narrative that says it's low severity because of the workaround. The workaround doesn't really fix all the issues this change caused, so please don't move it to the backburner.

July 29, 2020

Ever since KSP 1.10.1 downloaded today I have gotten 6 crashes to desktop, all when trying to do the same thing (this is stock, no mods, but I do have both DLCs):

The crashes only ever happened when trying to drag one of the 6 'knobs' of a maneuver node. Usually (thought not 100% of the time) that maneuver node was made while currently in orbit of Sun, on the way to Jool, and trying to make a maneuver node on the Sun orbit patch that will adjust the future Tylo approach to do a gravity-assisted capture at Jool. This is making it unplayable (as my career is currently in the middle of trying to do stuff at Jool so this Tylo assist is a common task.) and I cannot back out to KSP 1.10 (the Steam "betas" tab does not show 1.10 as an option. I can either have 1.10.1 or 1.9.2 - nothing in between those two.)

This problem never happened before today's update.

As part of trying to clear out whatever the bug is, after each time, I used Steam's "Verify Integrity of Local Files" and it always finds a few that need re-downloading after the crash. The file "PartDatabase.cfg" is *always* reported as needing a reload. Sometimes it wants to reload other ones too, but that one is the consistent one that always differs. I don't know if this is just a normal side effect of having played the game (maybe it always writes that file out each time the game runs) or related to the crash.

Is anyone else experiencing this? Am I alone? I saved the last 4 Crash folders from Appdata/Squad/Kerbal Space Program if that would help.

July 1, 2020

1 hour ago, EpicSpaceTroll139 said:

So I might just be missing something, but I've run into an error that's left me scratching my head

It sounds like this problem, which is known but not in release yet:

https://github.com/KSP-KOS/KOS/issues/2666

Do you have the ability to compile the kOS Project? If so, using the latest Develop branch would probably fix it. Otherwise I think you'll have to wait for release.
With KSP 1.10 coming this week, I do plan to have a release of at least some sort within a week after it comes out - even if it's just a basic compatibility release.

June 28, 2020

3 hours ago, traisjames said:

I have noticed that with Mechjeb installed my probe cores all show as having two KOS systems installed instead of 1. When flying I have two terminal open, close, power toggle available. KOS bug, Mechjeb bug, neither?

Some people have made patches for ModuleManager that add the kOS PartModule to probe cores. This is fine, but if more than one mod has done this, and one of them wasn't set up right, it can install the partmodule in *addition to* some other mod that is also doing it. There is a means in ModuleManager's config files to add the condition "only if it's not already there" to the command to add a KOSProcessor. But somewhere you have a mod that's not doing that.

To figure out which of your mods are adding kOS via ModuleManager, search through all files under the GameData folder that are ending in .cfg, and scan them for the magic word "KOSProcessor".

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Dunbaratu

BREAKING CHANGES

NEW FEATURES

BUG FIXES