Dunbaratu

January 1, 2020

LaserDist v1.3.0 out, for KSP 1.8.1.

No changes to Laserdist except API usage with KSP 1.8.

KSP 1.8 deprecated some API calls, replacing them with alternate versions.

In particular, the shader used with LineRenderer to draw the laser lines needed to be
built with a new kind of constructor.

I had some issues in the last couple months that kept me away from Kerbal modding for a while, but I'm getting back into it now. That's why this was so late in getting an update. It was still working for KSP 1.8 except the visual laser lines (if you have the "Visual" button enabled on the PAW) were drawing all wrong because the Shader wasn't being found and it was throwing exceptions midway through drawing it each update. (KSP 1.8 changed the way you access the built-in shaders.)

November 18, 2019

8 hours ago, CardboardGuy said:

This sounds really cool! And also, what language is kerboScript based off of?

It seems to be home-made and not "based on" anything pre-existing. Originally it was meant to sort of feel like the slow primitive BASIC interpreters that 1980's era home computers tended to have. In fact the original terminal was painted using a bitmap template taken from the Commodore 64 character set to give it that look. (I've since changed it to use a real system font from your computer OS, so it can support more Unicode glyphs for people printing things out in Russian, Polish, Japanese, or whatever. The C-64 font has a lot of nostalgia for me, but it only ever had glyphs for English letters. I didn't want the job of having to draw out little bitmap images of all the letters in all the languages to add them to the texture template it was using, so I made the change to a real OS font to offload that burden onto the font makers not me.) kOS has also passed through multiple hands of stewardship, with more than one person working on it so it currently looks very different from what the original person had in mind, probably. (For example, the original had only global variables, with no local variable scoping and no function calls, both of which I've added later. Since I added them later, I have no idea if their syntax is "in line with" what the original author had in mind.) I'm the current maintainer but not the original initial creator, and there's definitely stuff about it that I wouldn't have picked to be that way but I don't want to tear it to shreds and start over ruining everyone's existing scripts so I try to stick to the same "general" principles it appears to have started from, which are:

1 - Tends to use keywords more than punctuation. i.e. "SET X TO 5." rather than "X = 5;". Using a period (".") as a statement terminator instead of a semicolon or just an eoln like many other languages do.

2 - Reading it in English should sort of sound like what it does. as in: Set x to 5. lock throttle to 1. wait until altitude = 1000. When blah is true then print "blah". and so on. (This is one of those styles I'm not a huge fan of, for reasons too long to go into right now, but I kept trying to adhere to it with the many features I added, because I figure keeping the whole language in the same style is still better than switching to a new style halfway through for the new stuff, while keeping old stuff in the old style, creating a style clash.)

As an example of *trying* to make it English-ish, when I wanted to implement something like the 3-part for loop of C: (the one that looks like this: for (init; check; increment) {body}), I struggled to find a way to make that sound vaguely english-like, when there's no real English construct that looks like that. So I settled with FROM init. UNTIL check STEP increment DO body. to get the same general idea but kinda sorta make it look vaguely like english.

November 3, 2019

3 hours ago, JebIsDeadBaby said:
That's not it, I already do it.

But here is the thing - it always happens to me in Mun SOI, when I use my script that performs Mun orbit departure. The important part of code look like this:
until vang(KERBIN:POSITION, MUN:POSITION) > 160 
{
	print "Angle: " + round(vang(KERBIN:POSITION, MUN:POSITION),2) + "     " at (0,10).
}

RCS ON.

lock shipDptDir to ship:prograde + R(0,max(0, 2*(vang(ship:prograde:vector, kerbin:position)-90)),0).
lock steering to shipDptDir.

wait until vang(SHIP:FACING:VECTOR, shipDptDir:VECTOR) < 1.
So it basically waits until the ship finds itself almost directly between the Mun and Kerbin, then rotates the ship prograde (with a small correction in case prograde points away from Kerbin) and the at vang > 175 initiates the burn (code not shown above). So up to RCS ON everything works fine, then (if there is no connection) the ship just stays motionless. Those little indicators for pitch, yaw and roll in the bottom left corner of the screen do not move at all, so it's not like the script tries to rotate the ship but can't, it simply does not try. So it looks like steering command is not executed properly. If the connection returns at some point, then steering starts doing it's job.

I also pasted the code above to a test script and used it as a boot file for a ship I put in Mun's orbit via a cheat in sandbox mode. With no connection the code executed correctly, which puzzles me even more. There is literally nothing in my script before this code that could affect steering IMO - the boot file just chooses the right file to execute (the one that contains this code) and there is one trigger that checks for engine flameout. Then it's the code above.

I don't know what to say. I can't tell what's happening. I can only suggest trying one of these two things, as they have made a difference in the past:

1 - If it's a manned ship with no unmanned capability (only a crewed capsule, no probe core), try adding a probe core to it as sometimes the comms system doesn't bother doing work when the capsule is manned, under the assumption it doesn't need to bother checking for connection for control when the ship requires a person in it anyway to control it.

2 - If the antenna is of the "direct" type, try having a "relay" type antenna on it as well as (or instead of) the direct antenna. Some aspects of the comms system seem to only be loaded by KSP when the vessel is relay-capable, as some kind of way to save CPU cycles, again under the false assumption that commnet only has to check for human control ability and the subsystem that checks for distance and hops doesn't need to exist when nobody else could be piggybacked onto the connection to this ship.

November 3, 2019

1 hour ago, RizzoTheRat said:

Awesome work guys, love this mod.

Quick question, is this back compatible with 1.7.x or should I stick with the older version until I update to 1.8.x?

Because of the changes to Unity, I seriously doubt it will work right on 1.7.x, although I haven't tested to verify this.

On 10/20/2019 at 2:20 PM, Grigetio said:

@Steven Mading

I've created a pull request to fix the loading of the DDS textures for 1.8 (and all other versions I presume). At least that part will work .

P.S. Yes it was under my other pseudonym.

BTW, I never had the problem the PR allegedly fixed. The original code loaded textures in 1.8 just fine. But I trusted that there was some case where the change was needed but it was a case I didn't have.

Ironically, the PR actually *caused* textures to fail to load for many people. It hardcoded Windows-style backslashes instead of slashes into the pathname, so the PR caused the texture errors people on UNIX systems were getting. Anyway, it's all good now in kOS v1.2.1.0, where I took your PR but swapped the backslashes for slashes and it now works cross-platform.

November 3, 2019

I uploaded the wrong ZIP file for v1.2.1.0 to the three sites (curseforge, spacedock, github) and just uploaded a corrected version. If you obtained it within the last 2 hours, please download it again to get the new correct ZIP.

November 2, 2019

13 minutes ago, Steven Mading said:

kOS v1.2.0.0.zip is broken on UNIX platforms.

The DDS texture loading bug on UNIX platforms should be fixed in the hotfix I just released, called v1.2.1.0.

I do not have access to a Linux or Mac machine powerful enough to run KSP (mine are very old computers) so I cannot test this myself. I am *hoping* the change I made fixes it. Please try it and let me know.

10 minutes ago, JebIsDeadBaby said:

First, I must admit I'm not sure it's a kOS bug but anyway... The problem I have is that if a ship has no connection to the KSC when a script starts (e.g. via a boot file), then it can't control ship's attitude (at least via RCS and reaction wheels, a working gimballed engine will do the job AFAIR). I use CommNet, with PermitAll the problem does not occur. I saw someone's comment that that's CommNet's limitation and kOS can't do much about it, but the thing is everything works just fine if a script gets started with a working connection. Then, even if connection goes down during execution of the script, kOS retains control over ship's attitude. Anyone has the same problem?

Try to put a wait of a few seconds into the top of the boot script. It sometimes will load the ship and let its PartModules start operating (like kOS) before KSP has finished loading up and populating Comnet fully. Waiting 2 or 3 seconds should give commnet time to finish settting itself up.

November 2, 2019

kOS v1.2.0.0.zip is broken on UNIX platforms.

The PR contributed for DDS fixes had hardcoded backslashes in the filenames, which I thought .Net libraries would make cross-platform but they do not. It only makes it cross-platform in one direction but not the other. (The .Net file routines will convert Unix paths (with slashes) so they work on Windows, but won't map the other way. They don't convert Windows paths (backslashes) to work on UNIX.) I'm making a new ZIP which has the paths in the UNIX way so they'll work on all platforms.

November 2, 2019

Update for KSP 1.8.1 released.

Special thanks to @Thunderous Echo, who started contributing to the code with this release.

v1.2 Unity Update

This update is mostly to make kOS compatible with KSP 1.8.x, which started using a newer version of Unity, and a newer version of .Net, which have some consequent changes in the code and build process.

BREAKING CHANGES

None that are known about, other than the usual reminder that KSM files need a recompile after every version update of kOS.

NEW FEATURES

Now forces both the toolbar window and the telnet welcome menu to list the kOS CPUs in a consistent unchanging sort order. Previously, it was pretty much random what order you would see kOS CPU's listed in the menu, which made it hard for JonnyOThan's Twitch-Plays-KSP chatbot to know which CPU it was attaching to when it sent commands to kOS. This has been changed to a predictable sort order as follows: (1) Sort by which vessel the CPU is on, starting from the active vessel, and then for other vessels, sorting by distance from the active vessel, closest first. (2) When the same vessel has more than one CPU, break that tie by number of "hops" from the root part, such that CPU's attached closer to the root come first. This is by "number of parts to walk through to reach root" rather than by actual physical distance, since using physical distance might have led to inconsistent sort order given that some ship parts can hinge and extend, changing that distance. pull request
New suffixes Dockingport:PARTNER and Dockingport:HASPARTER will tell you which docking port this docking port is docked with. issue pull request
HEADING() Now allows optional 3rd argument, "roll". issue pull request
Let user-made GUIs toggle IMGUI's wordwrap flag with a new suffix: Style:WORDWRAP. This should let you fix that annoying problem where a GUI Label would insist on wrapping even when it could have fit by making the window wide enough. Setting wordwrap to false will force the GUI layout engine to keep the label's area wide enough to not wrap the text. issue pull request
Add BODYEXISTS test issue pull request
Allow FLOOR() and CEILING() to specify a decimal place other than the one's place, like ROUND() can do. issue pull request
Add a constructor, CREATEORBIT() that will make a new Orbit object for any hypothetical orbit given Keplerian parameters, without it coming from a vessel or a body that already exists. issue pull request
Added new suffix to waypoint: :ISSELECTED, which will tell you if the waypoint is the one the user has selected for their navball. issue pull request

BUG FIXES

Bound variables like SHIP, UP, VELOCITY, etc stopped existing in the KSP 1.8.x update. This was because kOS makes use of reflection techniques to store information about C# Attributes that help it find the bound variables in its code, and .Net 4.x changed the meaning of Attribute.Equals() in such a way that it broke what kOS was doing to store this reflection information. A Dictionary that kOS was using to track bound variables by Attributes started having key clashes because of that change to what it means for an Attribute to be Equal to another Attribute. ((No link to a github issue because this was part of the general KSP 1.8 update PR and didn't have an issue.))
Prevent waypoints with bogus body names. pull request
Fix a problem that made the GUI terminal sometimes get stuck refusing to repaint when resized to a size too small to hold all the text it previously had showing. issue pull request
Several minor doc typos pull request pull request
The startup message about default font and "if you want the old look" was quite obsolete by now and needed to be removed. issue pull request
Changed the technique used to load DDS icons used in the kOS GUI terminal and the kOS toolbars, to bypass KSP's strange API and go directly to Unity. This may or may not help people who had the purple square icon problem. ((No issue - SlimJimDodger contributed PR out of the blue.)) pull request

October 20, 2019

2 hours ago, Grigetio said:

@Steven Mading

I've created a pull request to fix the loading of the DDS textures for 1.8 (and all other versions I presume). At least that part will work .

P.S. Yes it was under my other pseudonym.

Can you elaborate on a specific scenario, hardware and OS, where it was failing before this PR, but working after it? I ask because I never saw the original texture problems other people reported so I'd like to know an exact thing to do to make it happen. I fear it may be graphics card dependent, as DDS decoding is sometimes done by the device driver.

October 19, 2019

3 hours ago, Matt Stryker said:

I have a very simple script for auto landing that is now giving me an error that says, "undefined variable name 'verticalspeed'"

Here's the line that breaks (and I assume all other lines that check verticalspeed)

until verticalspeed>=0

Like I said, this used to work perfectly. I don't know enough about programming in KOS to program around this.

You appear to be asking a question as a user of the kOS mod, which isn't what this thread is for. This thread is for people *developing* mods, not using mods.

I put the reply to your post over here instead:

October 19, 2019

@Matt Stryker posted this in a different thread - I'm replying to it here:

Quote

I have a very simple script for auto landing that is now giving me an error that says, "undefined variable name 'verticalspeed'"

Here's the line that breaks (and I assume all other lines that check verticalspeed)

until verticalspeed>=0

Like I said, this used to work perfectly. I don't know enough about programming in KOS to program around this.

Are you running this on KSP 1.8? If so, then kOS is almost completely broken on KSP 1.8 and that's the problem you're having. All of kOS's bound variables are missing in KSP 1.8 - verticalspeed, core, ship, velocity, apoapsis, etc. I know why and fixed it in the develop branch but there's other problems with the KSP 1.8 update I need to fix first before I release a kOS that's compatible with KSP 1.8.

(Without going into too much detail, the problem was apparently caused by a very subtle difference in how "Reflection" does things in the newer C#/.Net, causing some Types to be "Equal" which were not "Equal" before. kOS was storing information about these Types in a collection that requires unique keys and this change meant they weren't unique anymore.)

October 19, 2019

The screenshots show what I mean - Just started a career in KSP 1.8. When I transition up to the Mun, the moment it shifts into the Mun's sphere of influence, the Pe is drawn in the wrong spot - not even on the orbit line at all.

The problem tends to fix itself once I make my capture burn and the orbit becomes elliptical instead of hyperbolic. It might only be happening after transition when the orbit patch is still hyperbolic.

I can make a report in SQUAD's bugtracker, but first I wanted to ask here if anyone else is seeing the same thing.

My only mod is a preview version of kOS that I'm trying to test to see if I got it working on KSP 1.8 yet (I'm a kOS dev). I have no clue what kOS could be doing that would cause this.

October 18, 2019

Can we get a more specific description of the .Net version than just "4.x"? Because I don't know what is safe, I am only using 4.0, not 4.5. If I could use 4.5 it might be a good idea to do so, but I don't know so I'm avoiding it for now.

October 17, 2019

This sticky post has one small piece of information that just became wrong in KSP 1.8:

I noticed that Unity finally made all the platforms use a consistent name for the output log. It no longer makes Windows an exception where Windows uses output_log.txt while everyone else uses Player.log. Now all three platforms (Mac, Linux, Windows) use Player.log - if you still have an output_log.txt file after the KSP 1.8 update, it's a stale old copy leftover from the last time you ran a pre-1.8 version of KSP, and not the most recent run. I don't know if NathanKell is still around to edit that post, but somebody probably should (or stop making it sticky so it can be replaced with a new post) before modders start getting user reports using the stale output log file.

October 17, 2019

Okay it seems something went wrong when I copied over the dll's to the project, and I got older versions of the dlls from KSP 1.6, not the KSP 1.8 version. That's why the method was missing. I wiped KSP from steam entirely and redownloaded, then copied the DLLs over to the Visual Studio project folder and THEN it compiled. I don't know what I did but it was something on my end, clearly. It's resolved now.

October 17, 2019

EDIT: The following question appears to be moot now. I found the answer, I think. See next post for explanation.

~~Here is my first question to start the thread:~~

~~PartModule.Fields.TryGetFieldUIControl went away~~

When Breaking Ground came out, TriggerAU helped me with a problem in kOS, giving the advice that I should use this method when accessing the fields on PAW's for the servo partmodules of BreakingGround:

~~bool PartModule.Fields.TryGetFieldUIControl(string name, out UI_Control control)~~

This was a relatively new method I hadn't seen before KSP 1.7.x. But now In KSP 1.8, it looks like this method doesn't exist anymore, or maybe I need to include another new DLL reference or using statement to make it work.

As of KSP 1.8, It now gives this error when compiling:

"Error CS1061 'BaseFieldList' does not contain a definition for 'TryGetFieldUIControl' and no extension method 'TryGetFieldUIControl' accepting a first argument of type 'BaseFieldList' could be found (are you missing a using directive or an assembly reference?) kOS C:\Users\Steve\Documents\GitHub\KOS-1\src\kOS\Suffixed\PartModuleField\PartModuleFields.cs"

~~For reference, this is the snippet of kOS's code that it is complaining on:~~

            // Using TryGetFieldUIControl() to obtain the control that goes with this
            // field is from advice from TriggerAU, who gave that advice in
            // a forum post when I described the problems we were having with the servo
            // parts in Breaking Ground DLC.  (There is some kind of work being done here
            // that seems to allow one field's ranges to override another's as the servo
            // parts need to do.  This is work which doesn't seem to happen if you look at
            // the KSPField's control ranges directly):
            UI_Control control;
            if (!partModule.Fields.TryGetFieldUIControl(field.name, out control)) // <----- Worked in KSP 1.7.x, not in KSP 1.8
            {
                throw new KOSInvalidFieldValueException("Field appears to have no UI control attached so kOS refuses to let a script change it.");
            }

~~If this call went away or got renamed, what should I replace it with?~~

October 17, 2019

Before posting to this thread, first make sure you've read this post:

I decided to start this thread for any modders with a question about something that worked in KSP 1.7.3 but broke in KSP 1.8 and they don't know how to fix it. I'm starting it because I have my own question about that, but I figure it would be useful to have all these simple questions collected into one thread.

This is just for questions of the form, "Previously I did this in 1.7.3 and it worked. In KSP 1.8 it doesn't anymore and I'm not sure what the new way is supposed to be to do it. What should I replace this code with instead?" Because there is an official SQUAD post about this, but it's locked, I'm asking people to make sure they've read that one first in case their question is already answered (see link at the top). This thread is just for things not covered in that post.

October 10, 2019

On 10/9/2019 at 3:42 PM, Armisael said:

I'm interested in working out the average elevation above sea level for the equators of the airless bodies (ideally both mean and median). I can do this by putting a satellite in an equatorial orbit and using kerbnet, but then I have to manually log an altitude every 3.5s for like 40 minutes per body. I'm hoping there's a somewhat less labor-intensive approach. Is there are kOS script or a website that has already logged them?

In kOS, this code would store a list of altitudes around the equator:

local the_body is Mun. // or set to some other body to measure.
local alt_list is list().
local startlong is 0.
local stoplong is 360.
local steplong is 0.5. // samples 0.5 longitude degreees apart. Set smaller for more fine-grain measure.
for long in range(startlong, stoplong, steplong)
{
  // latitude = 0 to hardcode equator, longitude varies through the loop:
  alt_list:add( the_body:geopositionlatlng(0, long):terrainheight ).
}

// Now alt_list is a list of terrain heights around the equator.
// Do whatever statistical work on that list that you like in the lines below...
// for example - to get the mean:
local sum is 0.
for long in alt_list
  set sum to sum + long.
local mean is sum / alt_list:length.

Warning: the above code is not tested. I typed it in without trying to run it. It may have errors.

October 5, 2019

1 hour ago, Chabadarl said:
I'm testing to improve a trajectory by small step and it's seems that this does not work for whatever reason and it's getting me crazy.
  local index is 0.
  local candidates is list().

  until index =data:length {
    local candidate1 is data. //data is a list.
    local candidate2 is data.
		  PRINT "new".
          PRINT candidate1[index].
          PRINT step.
          PRINT candidate1[index] +step. //this works fine.
    set candidate1[index] to (candidate1[index]+step).  //this doesn't work
    set candidate2[index] to (candidate2[index]-step).  //this doesn't work
          PRINT candidate1[index]. //value has not change
          PRINT candidate2[index].
    candidates:add(candidate1).
    candidates:add(candidate2).
    set index to index +1.
  }
I'm posting here in desesperation. It's probably a syntax error but I don't understand why the set to doesn't work in this case....

I don't know what this code is *meant* to do, but what it *does* do is this:

candidate1[index] and candidate2[index] are the exact same object. So you are adding +step then in the very next line -step, putting it right back where it started, each time.

The reason they are the same exact object is this part here at the top:

local candidate1 is data. //data  is a list.
local candidate2 is data.

October 1, 2019

19 hours ago, HotVector said:

Any way to work around this using kOS or something similar?

i.e., making my own KAL-1000? Can kOS control Breaking Ground parts?

kOS has some difficulty controlling Breaking Ground's robotic parts for mainly this reason:

- One thing SQUAD did during KSP 1.7.x in support of Breaking Ground's Robot parts was to reduce wasted calculation time by sometimes having a values in Part Action Windows only get recalculated when the Part Action Window is actually open. If the window isn't open, nobody can see the number anyway, so why bother updating it? But these fields on the window are generic KSPFields, which is the usual way kOS allows you to access any generic module on any generic part. So when kOS tries to read, for example, a robotic piston's current extension position, the value it returns is whatever stale value it had the last time you had that Part Action Window open, not the value it has now. I do not know a means to "kick" the stock KSP into updating the number when the window is closed. It seems things only work if you leave all the PAWs open for all the servos you intend to work with.

But other than that (being unable to read the number that tells you where the servo's position is), it does let you move the servo's target position. It's just that after issuing the command, you can't when it finally gets there because you can't read its position.

September 16, 2019

The reason RT is a pain to maintain is because the signal delay is trying to do something via a MOD without good support for that thing from the base game. Namely, the thing that's hardest (from the mod maker's point of view, not from the player's point of view) about signal delay is that you need to insert a buffer in between the player inputs and the game seeing those inputs, and the KSP1 infrastructure wasn't really built to allow that buffer. So RT has to do some rather "rude" things to the base game to "yank" control away from all the other PartModules in the game and say "NO! I will not let you do what you were about to do! Instead let ME do that!". (That's why it tends to break symmetry in action windows, for example, is because of that rude insertion into the input flow interrupting the normal "do it to the left side and it happens to the right as well" logic in the base game.)

That's why having support for that from KSP2's modder API would be useful. When the base game doesn't provide the "hook" to allow signal delay, the mod has to be built in a very bug-prone way that's impossible to "future proof" because it's going in and ripping apart base assumptions the game made and falsifying them, and inserting itself rather rudely into things the base game is trying to do.

This isn't saying "make everyone have delay". Rather it's saying "make sure the API infrastructure is there to allow mods to intercept any and all player inputs before they do anything."

And that basically means a much stronger wall of separation between the user interface and the rest of the game than KSP1 has. But the good news is that if they're planning to do multiplayer, they're probably going to need that wall anyway, to handle the lag between different players. If it gets implemented like that, then a mod like RT could do signal delay like it was a "slow player" sending UI commands to the main game.

September 10, 2019

11 hours ago, MacLuky said:

Pretty amazing mod.

I'm trying to find out which of my parts is draining so much electricity, but there is not much to go on. I can find what makes electricity, has electricity, but draining is harder. In the KSP API docks I can find that e.g. a light has a usesResources method and variables that indicate how much is consumed. iResourceConsumers have a getConsumedResources method, but @JPLRepo was not using it in AmpYear so there is probably a good reason for that.

Anyway, any ideas on how I could tackle this using KOS?

Sadly, every mod has its own way to drain power. There's not a universal system for mods to tag their resource usage with ownership. There's no "I'm the one that consumed this resource". Each mod, during its Update, tells the KSP system, "I am in this part, and I am consuming X amount of resource foo. Please follow the connection and crossfeed rules to remove that much resource from wherever the rules find it starting the search here." But no record is kept of WHICH mod asked to do that, once it's been done. So kOS can't universally ask "who consumed electriccharge just now, and how much?" Some mods make an effort to show the user a number about it, but those mods are doing that with their own unique homemade systems. There's not a universal one for kOS to hook into. At least, I don't think there is. I'd love to be wrong about that.

September 4, 2019

8 hours ago, AdmFranzvonHippie said:

I'm curious to know what the opinions are between the two mods? Which one is better in your opinion, and why do you feel it's a better mod?

(Disclosure - kOS dev here so I can't be unbiased)

Mechjeb IS an autopilot. kOS is a toolkit for MAKING an autopilot.

It's like asking "is this kitchen table better than this carpentry workshop?" Depends on whether you want customization and enjoy the D.I.Y. process, versus if you'd rather skip all that and just have the finished product.

And you can't really even ask the question "well which is better at making orbit" or "which is better at docking", etc - because there's no such thing as "the" kOS program that launches to orbit, or "the" kOS program that docks, etc. Instead its more like "is Steve's kOS launching program better than Mechjeb's? Okay but what about Bob's kOS launching program?

With kOS, there's going to be waay to much variation between one user's script and another user's script to make any sort of blanket statements about whether it does the job better or worse than Mechjeb.

A more apt comparison might be to compare kOS to kRPC. They have more similar goals, but use very different approaches.

September 2, 2019

11 hours ago, Omnipius said:
I'm getting strange behavior from kOS on a simple sounding rocket script for use in RO/RP-1:
LOCK THROTTLE TO 1.0.
STAGE.
WAIT 1.0.
STAGE.
WAIT 0.7.
STAGE.
What's weird is that the throttle appears to unlock and drop back to zero every time the rocket stages. So, the rocket stops flying after the first stage. If I comment out the lock and set the throttle manually, everything works out just fine.

Any thoughts on what could be causing this and how to fix it? Could it be a bug?

If it's a sounding rocket (as in not good enough avionics to steer) then what's happening is that RP-1 locks out the gradient throttle, allowing only max/min throttle. But the gradient throttle is how kOS moves the control lever when you LOCK THROTTLE. kOS doesn't have a special exception to act differently when the value is 1.0 or 0.0. It still uses the gradient throttle lever for those. Until RP-1 added this strange behavior, it was never a problem.

To work around it - you can use these:

// Use these instead when RP-1's avionics denies control over
// varying throttle and all it allows is max/min throttle:

set ship:control:pilotmainthrottle to 1. // instead of lock throttle to 1.
set ship:control:pilotmainthrottle to 0. // instead of lock throttle to 0.

September 1, 2019

KCT claiming an edit is more expensive than it should be (and thus takes longer than it should) bug - I think I can recreate it.

Has anyone seen this bug besides me? I want to see if it's something others have experienced before I write it up as an issue:

To recreate it:

1 - Build a rather expensive rocket - something that will cost like 40,000 or more funds.

2 - Launch it through KCT and wait the required time for it to get to the launchpad and be usable.

3 - Launch it. Get partway through the launch process - at least far enough to have dropped your first stage and moved on to stage 2 so your rocket is smaller than it was at launch.

4 - Use the stock "revert to launch" feature from the stock "escape menu". (requires that you not be on the hardest difficulty settings that ban revert to launch).

5 - Now that you're back on the launchpad after the revert, use KCT's window to recover the rocket to the VAB for editing.

6 - Wait the required time to rollback the rocket to the VAB.

7 - Click KCT's "edit vessel' button to bring it into the VAB for edits.

8 - (the bug) Even a minor edit to insert one little part, that should only cost a tiny amount of funds end up costing like over 50% of the rocket cost and costing a large amount of time. Even making no edits at all and just hitting "save edits" still costs a long delay at least 50% as large as the original build time.

I suspect that something about steps 3&4 is confusing KCT into using an incorrect version of what the rocket's temp craft file was, so it sees a much bigger "diff" of funds in the VAB edit mode than it should. One suspicion I have is how it seems like step 3 is needed to cause the bug (that you have to have gotten far enough to stage before reverting). Maybe it's "diffing" versus the smaller leftover rocket you had after the staging, rather than what you had initially on the launchpad.

On another note:

Quote

Removed the window showing up when hovering over button

Thank You. This was always a minor quality of life issue that wasn't a game breaker but was just lightly annoying. The kOS button is adjacent to the KCT button in my toolbar so every time I moved the mouse down to the kOS button it would pass over the KCT button on the way and trigger this behaviour.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Dunbaratu