Dunbaratu

Yeah I had that idea as I was editing my previous response. I was reluctant because it means pointlessly doing the work of parsing the string to a number twice. (That's also one of my arguments for why nulls are superior to having all these HASwhatever suffixes all over... grumble grumble.... doing the work to find out *if* a value is obtainable usually means doing the work to attempt to obtain the value and then noticing it failed, so testing first with HASwhatever, followed by then getting the value, ends up repeating that work pointlessly). But it's now such a deeply embedded design decision that I'm reluctant to go back and change it. But at any rate, efficiency isn't exactly a big deal with kOS. We're so many layers removed from the raw hardware anyway that parsing a string to number twice instead of once is probably not that big a deal, so we can probably add ISNUMBER.

Possible?, Yes: Desirable? No. Right now such things only work because of the fact that everything can be secretly promoted to string when doing equality comparisons, so you can ask "is this thing (that might be a number or might be a string) equal to this string 'NaN'?" without a crash when it is a number. But it's a clunky workaround. I'm hard pressed to think of a scenario where you can't pick *some* actual numeric value that isn't a possible valid result, so you can use that as your test. That being said, I've always been of the opinion that the lack of nulls (and the lack of NaN's, which isn't quite the same thing, of course) was a bad decision. But introducing them now means having to go back and re-do a large amount of the manuals and the API which currently go out of their way not to teach the concept (remember the audience is supposed to include people who've never programmed before, so if we use nulls as a means of an API call saying "the thing you asked for doesn't exist", then we need to change everything in the docs to make sure it's using that paradigm all over the place and gives people plenty of introduction to it.). All the places in the API where there exists a "HAS...something" suffix are there specifically as an alternative because you can't test if a value is null. So at this point adding nulls in a way that isn't an ugly shoehorn'ed side feature means going back and removing all the HASwhatever suffixes because having both means of testing it sends mixed messages. You've got to go with one model or the other, not both, or the language gets very incoherent and ugly. I'm reluctant to add nulls now without a major version number shift that warns people that their older scripts will break (because adding them means I also want to REMOVE the HASWHATEVER suffixes to keep things consistent.) I suppose we could extend the HASwhatever model and introduce a means to query if the string *would* be translatable to a number without actually returning that number. String:ISNUMBER or something like that.

I've been letting this mod linger for a while and I just noticed it didn't work in KSP 1.2.1. So I just updated it (all it took was a re-compile) so it will work. It's on Spacedock and Curse and should appear in CKAN within a day or so (CKAN always takes a bit longer to update). New Version number: LaserDist 0.9.3

I never knew the string class didn't provide a conversion to numbers. (I didn't write that part). That definitely seems like something that needs to be fixed. I started an issue for it here: https://github.com/KSP-KOS/KOS/issues/1882

@Waz Well, even with GUI buttons I'd still use the TTY for readouts. GUI invokes things, but the things run on the TTY. That's the use case you're saying doesn't exist. You seem to be claiming that the TTY only exists for debugging during development. That once a script is debugged nobody would ever want to look at the TTY anymore. I don't agree. I guess it could be done both ways maybe. It's just that if I imagine multiple gui windows open, I'd like them glued together somehow and not all over the place separately. I wouldn't enjoy having them disconnected from which CPU it was (which right now is tied to which terminal it is) and having to drag them around separately one at a time.

FlightGlobals.ActiveVessel.orbit.timeToAp Would Kopernicus do anything that messes with this stock API call? I'm trying to trace a problem I got when I installed Galileo's Planet Pack (which includes Kopernicus as the main mod it uses) that broke the kOS mod's attempts to return the ETA to Apoapsis (which uses the C# call mentioned above). In a stock game, it returns the number of seconds until Apoapsis. But what I got with the mod returned a number in the range 10,000,000-ish numbers of seconds, which is hundreds of days and that's in an 80km orbit with a period that takes only about 20 minutes or so. I'm still trying to trace what caused it by going through all the mods that are inside Galileo's Planet Pack one mod at a time installing them piecemeal but I thought I'd ask just in case it's an already known thing so I don't have the spend the time doing that.

I just installed Kopernicus only with nothing else, playing in a stock universe, and didn't get the problem. But that doesn't prove it's not Kopernicus. Maybe it needs a planet pack to exist before it really does anything. Sigh. I guess I might have to start looking at what the ZIP installs and try installing things one at a time until the problem happens, to see which thing caused it.

Okay I'll try that. Because Galileo's planet pack is distributed all collected together in one giant ZIP it's a bit hard to "see" the edges of where Kopernicus ends and GPP begins. I think I'll just make a wholly new installation that just installs Kopernicus only rather than trying to figure out how to strip the not-Kopernicus stuff out of what the big ZIP installed.

Do you have any clue why this might be happening? It seems as if Installing Galileo Planet Pack has broken the following KSP API call: // Note "shared.Vessel" is a variable in kOS's C# code that currently // was set to FlightGlobals.ActiveVessel when this was being called. // You can duplicate this bug in your own test by just printing the value: // FlightGlobals.ActiveVessel.orbit.timeToAp // to the output log file on a vessel that's in low Gael Orbit: return shared.Vessel.orbit.timeToAp; (This is the C# code that's happening behind the scenes when a kOS kerboscript value queries ETA:APOAPSIS.) The proper value would be the ETA to arriving at Apoapsis, which should be somewhere between 0 and the current orbit's period, in seconds. But on a vessel that's in low Gael Orbit at 80km by 90km, I'm getting values back in the range of 8 digits or so of integer, like in the 10000000 ish range. That's hundreds of days until Apoapsis, which can't be right. The same effect happens with timeToPe (periapsis). At first I thought it might be something new in career about needing to upgrade the tracking center first, but I get the same effect in sandbox mode too. The same exact script in a new sandbox stock game does not have the problem, but one in a new stock Galileo game does. At first I tried looking for what kOS might be doing wrong, but I traced it down to this API call just returning a totally different weird result for some reason when Galileo is installed, but I don't know what that reason is.

That would be a problem we'd have to think about if we did that. What I was thinking of was letting the script pick which edge to glue it to (left, top, bottom, etc), but then do we hide the gui when the terminal hides, or keep the gui and collapse the window to just a small enough rectangle to "hold" the guil's glued to it?

How would you feel about having the kOS-Invoked GUI widgets somehow positionally attached to the terminal window's position (like how the (admittedly a bit cruddy) in-game text editor does it? What if the positions of the gui boxes were relative to the terminal edges? (i.e. instead of saying "put at screen pos 500,600" you could say "put at terminal right-edge, with 'top gravity'" ("gravity" being a concept used in some gui toolkits where you don't specify exact pixel position but instead allow it to "flow" where the position is relative to other things. "top gravity" would mean "position the widget as high up as it will go until it hits the edge of another widget." (as opposed to positioning it as low as it will go, or as far left as it will go, etc. You specify the gravity to tell the system how to position the widgets instead of specifying the exact position. This is also useful in being modular. If you run two different gui functions you developed separately they don't need to know about each other's positions - you just specify their layout flow and let the system position them so they don't get on top of each other.)) Then it would look like "these are some buttons and things on the control console". ========= [The following was supposed to be a separate post because it's replying to a separate topic, but the forum software auto-merged it in that annoying way we're all familiar with. Incidentally, this is why we prefer the subreddit for kOS to the KSP forums. It allows more than one thread about kOS. And there's enough variety of topics one might talk about with kOS that having to mash them all together into one is a bit unpleasant.] Hmm. The way this is done in the C# code is to just pick the "canonical" address of your computer that the API returns (which is presumably set to use the IPv6 address in your computer). We never bothered implementing the ability to pick which address to use in cases where you have more than one to choose from. Probably the solution would involve adding an interface to do so. Are you on Github and can you make an issue for this at https://github.com/KSP-KOS/KOS/issues ?

I also favor kOS making some sort of new "official" public API for other mods who want to "feed it some code". This is because even if you can make the reflection more efficient by caching it, and even if you can make things work relatively smoothly, you still have the basic problem that there's two different reasons a programmer can choose to make a member "public" and nothing in looking at the code differentiates which reason it is: Reason 1: It is public because it's part of the intended API for use by anyone in the world. As such I will dedicate a bit of effort to try to keep it working the same way on the surface even when I refactor the insides of the class and change everything about how it works under the hood. And if I do have to change it, I'll make sure to make it a big announcement that tells everyone what the change was. Reason 2: It is public only because some of my *own* other classes within my project have to access it, but I still consider it part of the internal implementation of my project instead of something I'm obligated to document for outsiders, or to make any effort to keep it working the same way in the future. If anyone does reverse engineer how it works and makes use of it, it could easily break right away in the next version. The "IsWaitingForCommand" member is only pubic because of Reason 2 here. We *just* added it recently to handle a different problem we were having and it's really just part of the ad-hoc solution to that problem. Thus who knows if it will stay that way or not?

But my question is - does the user have to in fact *disable* that feature of CommNet in order to get RT's flight computer to work? The word "ignored" could mean either "Using this stock setting breaks RT because RT ignores it and allows its stock behaviour to bleed through" or it could mean "RT works either way despite the setting, because RT found a way to ignore it (i.e. bypass its stock effect)." The setting in question appears to be blocking both manual pilots and autopilot pilots from being able to throttle up. (It should just block manual piloting only, but it doesn't seem to be doing it that way). I just got a claim from one of our users that mechjeb is having the same problem as kOS here. So I was wondering if RT's flight computer is having the same problem too. If so the three mods (well, 4 really - I almost forgot kRPC too) can work together on trying to find the cause and a workaround.

Is the RT flight computer in this new 1.2 release capable of throttling up (for executing a manuever node) when the signal is lost and you have the checkbox in this picture turned on; (Obviously I mean when you've issued the command while you still had a signal, but the burn is timed to go off later, after you expect to lose signal.) We're having trouble with this in kOS because it seems as if the stock game's lockout is affecting even our autopilot, not just the manual user. The autopilot moves the throttle to max, you can see it happening in the navball, but the engine refuses to actually do anything in reaction to it. Edit: Or are you expected to use RT 1.2 by simply setting stock comms to be fully permissive in every way, and thus only RT's rules are in effect and the stock game "thinks" its in easy mode with no comm effects?

The kOS Mod thread, here: Has been owned by user @erendrake for a long time, but over the last year his involvement in the mod has dropped to the point where we just pester him to update the thread's first post when a release happens, and then that's pretty much all the involvement he has. Until such a time as he gets more free time to come back to the mod, would it be possible to change ownership of the thread to myself for the sake of updating that all-important first post the describes the mod's version number? I have spoken with @erendrake and he is okay with the idea and you can ask him to verify that we have his permission to do this.

Is the target vessel more than 300 meters away but less than 2.5 km away? If so, then this is probably an effect of the weird fact that the stock game sets the loading distance to 2200m, but sets the unpack distance to 300m. There's a distance window between 300 and 2200 where a vessel is loaded but not unpacked. In this state you can *look* at the vessel, but can't actually control it. (It populates the parts of the vessel for visual appearance purposes, but doesn't fully activate them "all the way" in the physics engine, I believe.) In this state chances are the vessel can't rotate either thus the angularmomentum being zeroed out.

The "0:/" part belongs inside the quotes like so: COPYPATH("0:/Hellolaunch","").

The kOS CPU is only active when the ship is fully "loaded" into flying mode (not in the VAB). There's messy reasons for this, and it may be possible to change that in the future, but for now, just launch a dummy vessel that has power, rechargability to keep that power going, a probe core, antenna, and a kOS part. Then you should be able to make the terminal appear on the launchpad.

The mechjeb windows showing in the screenshot aren't part of this mod at all. They're just coincidentally in view when the screenshot was taken. The actual user interface, which is the kOS terminal, isn't in the screenshot, probably because there's not really much to show there. All the interesting stuff to look at is on the map screen - with the split apart nodes.

This looks pretty useful. But I think the fact that it needs kOS, and that it's *not* to be installed in the normal "extract the ZIP to your game folder and it ends up in GameData/" sort of way should probably get a bit more "top billing" in the description and not be buried so deep in the description. I'm not sure if it would violate the rules for hosted mods to do the following, but maybe it could also be packaged in such a way that if you did do so, it would still be in the "right place" (i.e. have it extract the files to Ships/Scripts/mechval/*.ks files, or something like that. (Definitely add that extra "mechval/" folder in the path if you do, just so you don't clobber over any scripts the user may have already written).)

SAS means "the AI is actively moving the controls" and trim means "when the controls are let go, they come to rest here." When SAS is on, the controls are never "let go". SAS prevents the condition in which trim would ever matter.

But there are contracts that are specifically easier with rovers - the ones that have you take readings while on the surface at about 3 or 4 waypoints that are within a few Km of each other. They're close enough to each other that rover driving to visit all of them isn't tedious, but just far enough away from each other that doing it by using a hopping lander is really wasteful and requires a much beefier launch with a lot more fuel weight in the upper lander stage than doing it by rover would.

What is the future plan for this mod post-KSP 1.2? Ideally I'd like to see an RT where its features are implemented *on top of* stock's system, rather than implemented "instead of" it. Especially as that will reduce the work for other mods (like kOS) trying to be compatible with RT. It would be pretty clunky to have to write 4-condition code that says "okay, if stock radio connectivity is disabled and RT isn't installed, do this, else if stock radio connectivity is enabled but RT isn't installed do this, else if stock radio connectivity is disabled but RT is installed do this else if both stock radio connectivity is enabled and RT is installed do this..." For example, rIght now RT provides an API call that other mods like kOS can call to ask "is this ship connected and controllable?". Presumably stock radios will have the same thing but a different API call. Having to write code in kOS to flip which version to call depending on what's been installed and enabled would be kind of messy and error-prone. Whereas if RT took the philosophy of saying "well, given that Stock now has its own "is it connected or not" system, we'll strip ours out and use its system instead, then layer our signal delay system (that stock does not have) on top of stock." -> that would make life a lot easier for the rest of us, although I understand it would be a heck of a lot of re-writing for RT (That and I like stock's attitude about antenna range better - you can have a weak antenna on one end of the connection provided you have a stronger one on the other end - which is generally not the case in RT where you need a super powerful antenna on both ends. In real world missions, the probes running on low power tend to have their weak transmissions compensated for by the fact that back on Earth there's a very sensitive receiver, and visa versa. You reduce the need to launch a very heavy and power-hungry probe by instead placing all that power on the Earth-side of the comm system.)

Is the basic problem that you just can't call a function from the interpreter? Yeah there's ... reasons for that (the quick and dirty version is that because global variables live on past the end of program death, that means functions would too if they were allowed to, and then there'd be no way to clear the functions left behind by programs you ran other than to NEVER wipe those programs from memory, ever, until a reboot.) So yeah, you end up having to run the function from a wrapper program. You can, however, pass parameters to a program too just like you can to a function (with a comma-separated list of args in parentheses).

Have you got a scenario where this is reliably repeatable? I tried making the problem happen from reading your description and I couldn't make it occur. I tried making sure I had Juno engines, and I tried settings as small as 1E-15 up to 1.0. I couldn't make it happen. (Note, going smaller than 1E-15 is pointless because the value returned when you try that is just plain zero.) I also tried scenarios where the throttle toggles from 1.0 to 0.0000000000001 back and forth very quickly (faster than 1 physics update), and I couldn't seem to trigger it that way either. (Not that I'd expect it to make any difference that way, given that kOS will only pass your new throttle setting on to KSP once per physics update anyway no matter how often you change it in your code.)