Dunbaratu

No, but now that we have worked on making suffixes that behave like methods (you can pass them arguments) it should now be possible to open up wrappers around the standard string manipulators soon.

I could get the performance more speedy if I could query KSP's API somewhere to find out what the maximum and minimm terrain height are for a planet. That would give me some bounding values to use to cut off the search to within just that narrow band. I could tell where the ray first enters this band and where it first leaves this band and narrow the search down to just that line segment. Right now it has to assume a mountain might exist somewhere that extends millions of miles into space and thus still gives a hit even though the ray is aimed nowhere near close to the planet's sea level. Being able to cut that search down would mean the difference between "Update age 20" and "Update age 3" or so.

Not already working with kOS, but I just was working kOS this morning, with the KSPFields update that would make it work. The current state is that I got it to *Read* the fields (is it enabled, is it visible, what is the current distance?) but the ability to set them (i.e. turn the laser off by setting its Enabled field to false) doesn't work yet. This is all happening at the same time as some other overhauls to the core system by erendrake so getting it all merged together won't be that quick. But it is progressing. The reason the performance is a LOT better when up close is that when close I can use Unity's raycast to solve "does this ray hit any polygons and if so which one?", which is actually implemented in hardware if the video card understands it. However, KSP only really fully loads the polygons that are within 10km or so of the ship. Any polygons farther away aren't really there for real, and I have to fall back on a numeric iteration algorithm that query's KSP's propietary altitude calculation algorithm at various sample points along the ray, finds the one that was underground, and then plays "binary search" from there to narrow down where the first point where the ray goes underground is. When you're not even aimed at a planet at all, it takes a while to exhaust all possible solutions before deciding there is no hit.

Wrong location. kOS currently violates the "put everything in gamedata" rule for reasons I don't really agree with, and instead puts them here: Plugins/PluginData/Archive/ NOT HERE: GameData/kOS/Plugins/PluginData/Archive.

Whatever solution happens *MUST* deal with the fact that scripts can crash unexpectedly in the middle from a runtime error. Thus why I'm talking about the idea of being able to set the exit throttle - which has no current effect but tells the system where to put the throttle upon program crash or exit. Reading throttle is useful but doesn't do anything if you are helpless to tell the script where to put the throttle when it's done. Annoyingly, it seems the way KSP deals with mods fiddling with controls is that you put a control override on TOP of the user's controls, rather than adjusting the user's own controls themselves, which makes the things you're talking about hard to do. I agree that it would be better that way, but I'm not sure yet how it could be implemented.

I found out what's been causing the problem that causes fuel to not burn all the way to zero some of the time. The problem is that KSP itself *tries* to burn oxidizer and liquidfuel in the right amounts causing both to reach zero together. But it's doing this using floating point numbers registering very tiny incremental changes each lasting only a fraction of a second. That sort of operation causes the tiny floating point precision errors to compound on top of themselves thousands of times over. What this means is that some of the time the ratio of liquidfuel to oxidizer consumption isn't exactly 9 to 11 like it's meant to be, and therefore one runs out a little bit before the other does. When you see the liquidfuel in the resource bar still sitting at 0.01 and it won't burn down to zero, it's because the oxidizer is at 0.0 but you're not seeing the oxidizer bar to notice this. So all the places where people have been doing this check: if stage:liquidfuel < 0.01 to try to catch not-quite-zero fuel, you can probably get the effect you want by checking BOTH liquid and oxidizer like so: if stage:liquidfuel = 0 OR stage:oxidizer = 0 To catch the case where one ran out before the other did.

Yeah the way kOS works was perfect before SQUAD made their annoying decision to default the throttle to 50% instead of the sane and sensible 0% it used to be. The logic is "when the software quits, leave the throttle back the way it was when the program was first begun." That handled both the case where you want a script that controls the rocket from the start or when you want a script that just does one small thing then returns to full manual control afterward. The change squad made screwed us and no matter what solution we pick it will be wrong for some cases that it previously worked for. The solution I'd prefer is to be able to override the controls with a setting to put them back to when the program quits, and have this be a setting you manually create at the start of the script, something like this: Set EXIT_CONTROL:THROTTLE to 0.0. Set EXIT_CONTROL:BRAKES to True. SET EXIT_CONTROL:... etc.... .. DO rest of program here... Then whenever the program exits, whether from intentional exit or from premature error, it uses those settings as it quits. That would be my preferred solution as it allows the greatest flexiblity. But at the moment it's not there yet. One consequence of this is that if you run a program automatically as soon as it is on the launchpad, using the boot feature, you never had the chance to set the throttle to zero before the program started ,so the program is incapable of leaving it at zero when it stops. The boot system is sort of unusable at this point as a result of the fact that the only way to make the program able to put the throttle at zero when it's over is to manually zero the throttle before you start the launch program.

Is it possible to give the parse error message if a mod's .version file has syntax errors (isn't proper JSON)? Right now it just says this: NAME: NULL (required) URL: NULL DOWNLOAD: NULL GITHUB: NULL VERSION: NULL (required) KSP_VERSION: 0.25 KSP_VERSION_MIN: NULL KSP_VERSION_MAX: NULL CompatibleKspVersion: True CompatibleKspVersionMin: True CompatibleKspVersionMax: True CompatibleGitHubVersion: True Which is basically the default values prior to trying to read the version file. It took me a while when I was trying to add AVC suport to a small mod I made to realize that the actual problem was a syntax error in the version file making it unable to fill these values.

If you're talking about the editor window, then that's normal. It was easier to use the textedit widget built in to Unity than it was to keep the old in-terminal one working.

This is going to be very hard for me to work with personally if it does turn out to be a real provable problem because I never get anywhere near 60 FPS in the first place when running stock, not even close, so a problem that's only noticable on a faster computer is going to be one I can't reproduce in front of my own eyes to debug it. I don't know if erendrake can.

Your output seems to indicate that the only problem case is when the SCS parts exist and are actually running kOS code, which is what I'd have expected and wouldn't consider a bug but just normal behavior. Adding them but leaving them powered off seems to have no effect, (which differs from what you reported earlier that had left me baffled.) The only real condition remaining that may be a real problem is if leaving them turned on but not running code also gives you a similar dip as leaving them powered on AND running code. That data which isn't shown yet, is the clincher.

The idea that it causes lag even without ANY SCS parts instanced is really strange. The code kOS executes is all inside the Update routine that is called per PART that has the kOS Module on it. Without any such parts, there shouldn't be any code from kOS being run after the initial loading screen.

Okay, next question - does the lag happen without any actual kOS code running? Just from having the part on the ship? Or does it have to be running simultaneous code in them to lag?

Given the way the RUN command is implemented under the hood, it's currently very bad at dealing with sending the wrong number of arguments (it basically cannot detect that this was done, and it causes null exceptions when using the undefined parameter). Remember that one consequence of defaulted parameters is that they must necessarily all come at the end, like so: // legal declare parameter bar. declare parameter foo=0. //This order around would be illegal: declare parameter bar=0 declare parameter foo. (If only some of the parameters are defaultable, they have to come at the end). But this does seem like a good idea to try to implement.

Do you get the same effect if you make sure to enter the tracking center first and clear off *everything* from the vicinity of the Kerbal space center first before launching this? I've seen in the past an effect I can't find the cause of, where if I launch a rover, run some KOS code on it, and then launch another while the first is within 2.5km of the space center, the second one lags BIG time - not just the amount you'd expect from one extra CPU running, but it turns the FPS down to about 1 frame a second. This is mostly from garbage spamming the output_log.txt, and the system Unity uses to write to the log seems to cause a lot of lag if done too much.

The goal descriptions for all the part testing contracts make the claim that the way you test the part is to activate it via the staging list when all the conditions are met when in fact that's actually the *hardest* way to do it. It's a lot easier to activate it via the part's right-click menu when all the conditions are met, and the descriptions never mention anywhere to the new player that this is even a possibility. The contract descriptions make things harder for new players then they need to be because the new players won't realize that you can also use the rightclick menu. Doing things via the staging list, which requires precision made launch rockets that run stages out exactly when you expect them to, at the expected altitude and expected speed, isn't really the only way to do it. To a new player, seeing that experimental parts have a "test" option on their rightclick menus is like finding a secret easter egg, and as a basic user interface element integral to the game, that shouldn't be how you have to discover it.

Then Probe Control Room must be doing something wrong, because that same problem does NOT happen with the "C" key in Stock, where it is also the key for going to the cockpit, and yet kOS lets you type 'c' into the window in stock without going to the cockpit. The Probe Control Room mod must be mapping the 'c' key in some way that is rudely overriding the usual input processing order of things. The difficulty of trying to stop that the way we stopped the "X" and "Z" keys is that we *didn't* stop the X and Z keys explicitly. We stopped the input action "THROTTLE_CUTOFF" and "THROTTLE_FULL", without ever mentioning the actual keypress they are mapped to. To do this for Probe Control Room's "C" key the same way, Probe Control Room would need a similar input event name like THROTTLE_CUTOFF that we could hook into.

Can you include a screenshot image of what that vecdraw is looking like when you run this code?

It works by suppressing the control called "THROTTLE_FULL" (look in your KSP settings.cfg file), regardless of what the keypress it's assigned to actually is. The default is 'z' but if you change it in the settings panel, then whatever you set it to will be affected by what kOS did. We didn't like having to implement the lockout of the throttle cutoff (default 'x') and throttle full (default 'z') keys in this very crude, rude way, but SQUAD annoyingly left those controls out of the control lockout system they expected mods to use. Even if you tell KSP to lock out ALL controls entirely, the throttle cutoff still leaks through (and we assumed the new 'z' was the same way).

This is one of the Coolest things I've seen in a long time. I would have never expected the stock aerodynamics model to be anywhere near good enough to deal with the idea that pushing a wing against air causes a pushback force more when it's flat than when it's edgewise (a necessary feature for this style of wing movement to work.) If we ever make a "here's cool stuff people have done with this mod" promo vid for kOS, this would be one of the best examples to put on it (and for promoting IR as well, I'd imagine).

Release 0.4: Added support for KSP-AVC mod (version checker) and KSP 0.25 https://github.com/Dunbaratu/LaserDist/releases

Has anyone else had extreme difficulty with Asteroids in DMP? In a recent game, I got myself attached to one, hooked up several smaller probes with RCS on them around the asteroid to help it turn, then in the main vessel tried rotating the asteroid to make the burn and something very wrong and artificial was making the asteroid "spring" back every time I tried to rotate it. I know asteroids are large and hard to turn, but this was different from the usual behavior. Pushing more and more just caused the oscillations to get bigger, rather than actually making any real progress toward rotation. it was as if something was holding the asteroid in place and turning it only caused the spring back when I let go to be stronger. I never had this outside of DMP.

I think the better solution is to get SQUAD to stop spawning the airplanes with a 2 meter drop to the ground. It's that drop that's causing the impact to be too much. During an actual landing it comes down more gently than that.

If you're interested, here is where I've got the model I do have, and the readme describes where the "hotspots" in it are (where it attaches, and where the code expects to draw the laserbeam from): https://github.com/Dunbaratu/LaserDist/tree/master/UnityModel

Maybe someday. At the moment it would be a bit of a break of game balance because right now the laser is infinite distance. Also, for the really far objects it will start running into the problem that Unity is doing everything in single-precision floats and not doubles. I suspect that it will get to the point where you just don't have enough finite control to keep the laser aimed on the tiny fraction of a degree arc where there's a hit.