Dunbaratu

I defintitely would want to be in on this. We're maintaining a mod and need to find out as soon as we can what changes we need to make to the mod, and how the new version works.

We have a feature that sort of does this: You can get the sensors of the vessel with: SHIP:SENSORS:ACC. Warning, when you do a `SHIP:SENSORS` you get a frozen snapshot picture of the sensor values at that time, so watch out for this trap: // This code snip prints the same number over and over, // ignoring what has changed: set s to ship:sensors. until false { print "ACC is " + s:acc. wait 1. } // This code snip prints differing numbers each time: until false { print "ACC is " + ship:sensors:acc. wait 1. } We'd like to fix that trap but it hasn't been a high priority compared to other things. We added this because the actual sensors have the problem discussed above. But, these still do require at least one instance of the necessary sensor to exist on the vessel somewhere. So for example, you can't read SHIP:SENSORS:TEMP if there's no thermometer part on the vessel. In fact, that very check is the reason we want to eventually fix the trap mentioned here. Right now it's a bit more slow and expensive to query SHIP:SENSORS:ACC than it should be, because it's walking the parts list each time you do SHIP:SENSORS, to find what instruments are present on the ship. But because doing SHIP:SENSORS ahead of time causes the values to be frozen, you can't really escape from that expense at the moment in any real practical way. I'm in danger of talking too much about my pet project in your thread about yours. I'll stop talking kOS here and let the thread be about your excellent space program reports.

One of the frustrations we have is that in stock KSP the sensor parts were never designed to be used programattically and therefore the only publically exposed fields on them are text for human reading, not actual numbers. When you click the acellerometer and it displays "9.8 m/s^2" it literally is that, as a string, not as the floating point number 9.8. add in that it sometimes changes scaling on things using a variety of nonstandard nomenclatures(i.e. adding a 'M' for million when the number gets too big in some cases, but using scientific notation in others) and it became too messy to try to pass that information on to programs in the form of a number rather than a string.

A real craft can "feel" how many "G"'s are acting on it with an accelerometer. In freefall it should read zero. If it's not zero, then that is either due to the thrust it's undergoing or an external force acting on it. The craft should also be able to know how much thrust it can expect from its engine and current throttle setting. If the "G"s it's feeling are close to the number of G's expected on the planet surface, with a bit of fudge tolerance for altitude, and that cannot be accounted for with engines, then those Gs are being provided either by the ground, or by air drag. If you're not currently moving very fast, then it can't be air drag and there's only one answer left - the ground is doing it. If your thrust is operating on a PID controller trying to maintain a constant descent for the last few seconds, then when you first touch the ground it will notice you're not descending anymore and throttle back..still not descending so throttle back more..... and eventually be throttled back enough to trigger the check mentioned above. I think that might work and even accommodate craft that tip over and thus don't trip a contact wire. If you're feeling an upward push that can't be accounted for by your engine or by air, then the ground is doing it.

It's not the same thing at all. Here's the important difference: If you activate an engine there will be a delay until it happens next tick, but it will happen. If you set sas on, then set sasmode to something, the set sasmode won't just be delayed until the next tick - it actually won't happen at all.

hmm. that sounds like it needs to be a github issue. Either we do some fiddling in the code to make it so SET SASMODE delays calling the KSP API until the next update when the SAS has changed, or we at least change the documentation so it mentions the wait.

Well, technically this is just *a* place. I wouldn't call it *the* place, because we tend to be more active over on reddit in /r/kos, and only pop in here once every few days to see if anyone commented. Nothing against the forums, but the fact that with a programming system you can end up with very complex user questions, and lots of them for totally different topics, makes it feel really limiting that here everything about kOS has to be in one single thread. I sometimes worry that that makes us look a lot less active than we really are, if people come here and see the traffic the thread has and don't realize there's way more going on over on reddit where people can talk in multiple threads.

Generally the same confession here. Once I became a primary developer on the kOS team, I stopped playing career mode out to the end. I usually spend way more time making the mod than playing, and so none of my career games get to the final tiers of tech anymore. By the time a new KSP version comes out, I haven't got that far in the career and I just start a new career over again. Case in point - I still haven't ever mined anything. Too high up the tech tree to get to it by the time I start over. It's just become a lot more fun to make a tool that other people use to do cool things than to do them myself. It's a sort of more efficient means of feeling pride that way. I get to feel a sliver of accomplishment every time someone else makes a successful script. My confession: I really enjoy that for entirely selfish reasons. It lets me get a little jolt of pride from of other people's work.

This paragraph is from the original kerbalstuff code with just a search-and-replace on the name. It was not written by the new devs for spacedock. It sounds a bit contentious and might be softened a bit:

It doesn't go out of its way to break RO, but RO does a thing that breaks kOS (sort of). RO throws away all the stock meanings of how much 1 electric charge can do (1 EC), and when mapping it to a real-world measurement they picked one that is a bit nerfed compared to the stock game. But then they compensate for this redefinition of what an EC is by editing all the configuration files of all the parts to use their new scaling meaning of 1 EC. But kOS's EC usage isn't in a configurable .cfg file, so RO can't make that adjustment for it, and thus it makes the kOS power drain prohibitive when RO redefined what 1 EC meant. There is a new feature in the pipeline that gives kOS CPU PartModules a configurable .cfg file setting for how many EC per instruction executed, which does two things: 1 - Power drain varies with CPU speed and CPU utilization percentage. If your program is stuck on a wait statement for days while you time warp, you will use very minimal power during that wait. 2 - By having the value in a config file, RO can then overwrite it with whatever they want via modulemanager. But right now that hasn't been released yet.

lock wheelthrottle to ship:control:pilotmainthrottle. Is it that?

So it's not remotetech that's installing those locations, then, which is what your earlier post was worded like. Sorry for the confusion. I'll leave the thread again and let you continue your co-op program.

Where is this feature? I use RemoteTech and I've always complained that only having a transmitter at the KSC and nowhere else is an unrealistic challenge because in the real world we have these things called copper wires and can relay between different antenna locations on the planet. RemoteTech does NOT install other locations around the globe as far as I can tell. Or if it does there's something I have to do to enable this and it's not well explained.

http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#tuning-cooked-steering Essentially the problem is that kOS's cooked steering knows nothing of areodynamic-only control like from fins and rudders. So when it calculates how much torque it *thinks* the ship is capable of outputting, it gets a very small nearly zero number. Then it gets way too conservative when it is deciding what is the max rotation it should allow itself. It rotates up to a rotational speed, holds that rotational speed, then slows down as it approaches the set point. It has an upper cap on how high it will allow that rotational speed to get, and that's based on it guessing how long it THINKS it would take for it to stop its rotation if it had to. Given that its calculations of how much torque it thinks it has is wrong when the torque is coming from flappy control surfaces and nothing else, it gets the false notion that it would take it an enormous amount of time to stop a rotation, and thus it gets very conservative with its rotations and refuses to allow itself to get much rotation started in the first place. One fix is to manually add a fudge factor that tells the steering manager that the available torque is a bit higher than it thought it was, to compensate for the fact that it doesn't try to add torque from areo controls to the calculation. You can do this by setting: steeringmanager:pitchtorqueadjust, steeringmanager:yawtorqueadjust, and steeringmanager:rolltorqueadjust. When requires a THEN keyword (I really should remove that. It's kinda dumb, but it was inherited from the language before I got my hands on it.) I don't know why it's showing a euro sign in the error message, though. It doesn't do that for me.

Then the answer to the question why the mod is marked as still working despite this feature not working is that it IS working for other people. There is some other reason it's not working on your install and I have no idea what that is. For me, Technique 2 is working just fine.

What you're describing is kRPC, not kOS. kOS runs on a simulated virtual computer that "lives" inside a part on the vessel. It's goal is to try staying on the "kerbal" side of the 4th wall and be an in-game programming system that's inside the Unity-simulated universe. kRPC is the protocol layer that punches through that 4th wall, and allows access to an abstraction of the game's methods from an external program that lives outside the game engine in a second OS process.

Can you show me the actual error message? Mine works just fine when I run it.

What's the design rationale for passing in v as a parameter when it never gets read by the function and it just calculates it anew? Why not just pass in t alone, calculate a local v, and return the v ? FUNCTION SIG { PARAMETER t. LOCAL v IS 1/(1+((constant:E)^(t))). RETURN v. } or even just eliminate the local altogether since it only lives long enough to be returned: FUNCTION SIG { PARAMETER t. RETURN 1/(1+((constant:E)^(t))). }

In Stock KSP, there are two user interfaces for how you transmit science data: (1) Rightclick an antenna and use the antenna's menu to transmit all pending science from the vessel from this one one button click. (2) Rightclick a stored experiment part (i.e experiment module that took it, or the capsule if a kerbal has moved the data into the capsule), and pick "Review Data". Then from the "Review Data" popup, click the blue antenna button to transmit just that ONE experiment only. Technique (1) is broken in RemoteTech, for some reason that was explained to me once but I don't remember it now. But technique (2) still works, and you can go through all the experiments and transmit them one by one.

I hate the new forum software. I typed a long reply with code samples and everything, and hit "submit" and the software refused to take it, and then said mysteriously "this field is required" at the bottom of the page without any indication which field its talking about, and all my work was wiped and I couldn't get it back with backarrow. Here's the short summary of what I typed: PID on a vector is messy. These PIDs are for scalars. So use several independent PID's - one for the longitude and one for the latitude, and one for the vertical hover, as they are orthogonal values, then use vector addition with the unit vectors for up, north, and east multiplied by the result of the 3 pids, and use that resulting vector to steer by. I have no idea about the Q/E thing - I've never seen it. Also, try searching on the documentation for "PIDloop" - there's now a much faster built-in PIDloop feature you can use in kOS instead of having to spend precious kerboscript cycles on it.

Is anyone else finding the seaplane contracts impossible due to not being able to switch active vessel while floating in the water without summoning the Kraken? My sea planes land in water just fine, and take off just fine, but if while they are floating in water, perfectly still, I do anything that makes them no longer the active vessel (like EVA the pilot so the kerbal now becomes the active vessel instead of the plane, or hitting the '[' to switch to a floating kerbal I'm meant to rescue), then the now no-longer-active-vessel comes apart in pieces, even though it was floating passively in the water just resting. The F3 report claims the problem began with a part colliding with its neighboring attached part, but it's a different culprit part each time it happens, and I haven't been able to find a pattern to it. I keep having it happen with more than one design, and it seems to make these contracts impossible, through no fault of my own (if I can't switch-to-kerbal while the plane is in water, then I can't rescue people.) Am I the only one having this happen or is it happening to others?

But it seems like maybe what was desired is something that removes the *time* it takes in front of the game to do it. Even if you script it, you still have to wait for the launch process to finish. The only difference is you can get up and walk away from the computer while it happens. Maybe a mod could exist that looks at the vessel design, works out its deltaV per stage, figures out how many stages it would use up and how much fuel it would use up to get to a given altitude orbit, and then just hyperedit's the ship to that orbit, minus the missing stages and missing fuel that it used up to get there, assuming optimal ascent profile.

I hit the refresh before issuing the report just to be sure. But, just now to be really sure I wiped CKAN entirely, re-installed it from scratch, and now it's showing up. Refresh wasn't working for some reason. Not your problem then. Never mind.

This may be answered upthread already but It's a lot of reading to slog through: AVC claims that ContractConfigurator is now up to version 1.9.5. But CKAN still only has it at 1.9.4.1 so in order to obtain it and make the AVC complaint go away I have to go outside of CKAN to do it. Is that deliberate? Is 1.9.5 just an alpha release that's being kept off CKAN deliberately or is this a mistake that it's not on there?

What doesn't take just a few seconds is accessing all that data to plug in to the formula in the first place when your ship is composed of more than one part, and more than one stage, as any non-trivial ship will be. If the game simply had a dumb summation of the relevant fields it would be nice, and not really be doing any thinking for you - just taking away the tedium of note-taking.