Dunbaratu

I just tested using this mod and it works great so far. Thank you very much for fixing this longstanding frustration I've had with RO/RP-1 games - the runway being totally unusable. When you reach the point where this would leave Beta and become "official" are there any plans to simply integrate this code into the official RSS releases down the road? [Although, I'm not enough of a legal guru to understand if there's any legal hurdles to mixing MIT license code with CC-BY-NC-SA license code.]

I'm not the one who wrote the PID steering - that dev isn't active anymore. So I don't know how to read that log, but I can look into it and try to decipher it from the source code.

It's possible it has nothing to do with the control surface and is just PID integral windup. There is meant to be a protection against that (so it doesn't "think" it's successfully deflecting at 400% just because that's what it told the control to do, and instead records the fact that it only successfully deflected at 100%.) But that protection might not be working perhaps.

That sentence reveals more than you might realize. It implies your *entire* control authority is coming from areodynamics with control surfaces, none from RCS or reaction wheels or engine gimbal. That might have a lot more to do with this than it seems. It's much harder for kOS to get accurate torque info about the areodynamics of fins than other sources of torque - especially if FAR is in use which changes everything about that information. This may have a lot more to do with that than with anything else.

Is it correct that at the start of an RP-1 career it takes 249 days to build the smallest simplest sounding rocket composed of 1 arobeee core, 1 tiny tim booster, 1 procedural nose code, and 3 fins? That seems awful. I remember in the last time I played RP-0, you were given some basic starting points to spend on the build points but now you get zero and have to live with a VAB build rate of 0.05 until you get some contracts finished and have some cash to spend on it. I know it's supposed to be slow but that's immensely slow to only launch 2 starting sounding rockets per year. I think there has to be something wrong here. [edit: to make it clear - why this worries me is that if it takes 20,000 funds to even get one little upgrade point to speed this up, it's going to be a while before I can change this rate, and if it takes 249 days to do the smallest toy rocket, then at that rate it feels like it would take decades to do one basic satellite launch rocket later, assuming it scales up like that.]

The problem was that I thought the avionics limits were part of the core RO mod when they're not. They're implemented by RP-1 as it turns out, which is confusing since those are a core game mechanic about the parts, rather than a thing about "progression". (i.e. it's about how the part itself works, not about the tech tree or the contracts, and therefore is needed even in a sandbox game, and thus feels out of place in the mod that's there for the progression instead of for the sandbox mode.

It's not moot if the descriptive text doesn't prove what's going on. The graph is not proof on its own that the PID is wrong. But the graph, *In combination with* with the knowledge of where it's actually pulling those numbers from could be, if I could tell where it was pulling those numbers from. That's why trying to find out where it actually dumps those numbers out was relevant. The most helpful thing to do if you suspect you know something is wrong is to create a simpler example that JUST shows that one thing, with as much removed as possible. As it stands, this is too complex an example for me to spend any time trying to diagnose it. It doesn't trim things down to just the one relevant thing.

My Realism Overhaul has no Avionics Tonnage Limits. Is that wrong? [Edit - most of post removed] I finally figured out by searching the github source code that RO doesn't have the avionics tonnage limit, it's RP that controls that. I had previously played with both installed before I fired up the game so I misunderstood which mod caused which feature. (I had assumed RP was limited to just the career aspects of the game like contracts and tech tree, and that RO did all the actual physical rules like avionics limitations. In other words, I thought that RP was about progression, hence the name, and therefore was irrelevant if you are playing sandbox mode. I didn't realize I needed it to get some of the base code that runs actual realism rules like avionics tonnage.)

Your launch script is complex and while I like diagnosing problems in kOS, I'm not a fan of having to first study someone else's very complex script and teach myself how it works before I can then begin to start diagnosing the kOS problem. That's a huge time sink without a guarantee that it will even turn out to be a kOS problem in the end. For example, I tried to find where in your code on github you might be possibly logging the data that goes into that red line in your graph, and all I can find is this maybe? set getter("addlLogData")["Pitch Target"] to { return 1.14452E-8 * ship:altitude ^ 2 - 0.00181906 * ship:altitude + 88.6057. }. But that doesn't match the actual formula in your lock pitch, which is this: lock pitch to 2.95304E-8 * ship:altitude^2 - 0.00218678 * ship:altitude + 88.8414. So I'm back to having no clue what your graph is really showing me. I don't see where you're dumping those values from. Finding the kOS problem means first proving where it's doing something wrong. If this is a kOS steering bug along the lines of "I told it to do X but it's doing Y instead", then logging what that X actually is you're passing into it, and the resulting Y it's doing instead, at as close a place as possible to where you directly feed it into the steering manager, is how you show it. I can't tell what you're logging in this script because I don't see anywhere that the `pitch` from `lock steering to heading(hdgHold,pitch) is getting logged in that script. Maybe you are, but I am having a heck of a hard time finding it, and I need to budget my time here.

@Drew KermanThere just isn't enough background information to figure out what on earth you're talking about, sorry. I feel like I'm stepping into the tail end of a conversation. There's nothing in that post about what you mean by "planned" - is that a steering command by a script that you are changing over time in the fashion the curve describes? What is commanding the change? I just don't understand what you're saying.

There's a new version of kOS - v1.1.9.0. You can get it from Curse or from kOS's Github. WARNING SPACEDOCK IS BROKEN AS I WRITE THIS AND NOT UPDATED YET - YOU HAVE TO USE ONE OF THE OTHER SITES AT THE MOMENT. (I have tried for about an hour to get it uploaded to Spacedock but their upload progress bar keeps hanging forever and I can't wait for them to get fixed so I'm publishing without Spacedock for now. I'll update Spacedock later if I get a response from my support e-mail about it.) v1.1.9.0 Breaking Bounds This update is a mix of new features, mostly BREAKING CHANGES NEW FEATURES Bounding box information for parts and for the vessel as a whole is now exposed for scripts to read. pull request 1. pull request 2. The above bounding box feature also came with some new suffixes for Vecdraw so you can now draw plain lines (suppress the arrowhead, suppress the opacity fade) with them. Lexicons can now use the suffix syntax. i.e. where you say mylex["key1"] you can now say mylex:key1, provided the key is something that works as a valid identifier string (no spaces, etc). pull request. Can now set the default terminal Width and Height for all newly spawned terminals. pull request 1. A ternary conditional operator exists in kerboscript now, using the syntax CHOOSE expr1 IF bool_expr ELSE expr2. If bool_expr is true, it returns expr1. If it's false, it returns expr2. pull request. Added support to read more atmospheric values from KSP. pull request. BUG FIXES TimeSpan now peeks at the KSP game to learn its notion of how long a day is, and how long a year is, rather than hardcoding the values. pull request. Fix cooked control triggers not working during a WHEN/ON trigger. pull request. Fix mangled state if kOS is out of electricity when scenes switch or the game is saved. pull request. Obsolete list command documentation removed. pull request. Allow part modules'd fields to work even when no GUI name is defined. It seems that the main game allows the GUI name to be left out and if so it inherits from the base name under tne hood. Now kOS follows this behaviour. pull request. Prevent using UNSET on built-in variable names like SHIP, ALTITUDE, and so on. pull request. RP-1 used a different technique to lock out controls due to insufficient avionics that kOS didn't know about. kOS bypassed this lockout and still controlled the vessel anyway. This is no longer the case. pull request. PartModule:SETFIELD now works properly with the new type of slider widget that robotic parts use in KSP 1.7.x. KSP introduced a new type of slider widget that presents false information when kOS tried to obey its min, max, and detent values, those being only dummy placeholders for these types of sliders, not actually populated with the real values. For these sliders, the real limit values come from another field, requiring a more indirect method call to get the information. pull request. GUI windows no longer use the KSP control lock system to emulate keyboard focus, instead relying on the built-in Unity IMGUI focus rules for widgets, thus they won't 'steal focus' as much. pull request.

Remember the "it" I was talking about when you posted the reply saying "It can be done" was the player having to point the antenna, as contrasted with RT pointing it for you. What you describe here still fits under RT pointing it for you, with the phrase, "they just pointed to what ever you set has target". The only thing that was changed was NOT whether you merely had to pick a target off the menu, but rather it was whether the mod also added the physical effect of rotating the probe to aim it. But that still wasn't the player having to aim it. The player just had to select the target. The player having to do the aiming still seems impossible to me without a script or mod to turn it for you, since you lose manual control when it goes out of alignment so you can't fix the alignment yourself as a player.

How? When the satellite is out of contact because its aim became wrong over time (Kerbin moved), how do you control it again to turn the antenna? It seems like a catch-22 - you can't turn the antenna without control. You have no control without first turning the antenna. It would seem like this approach would require something to autopilot it when you're not able to control, like a kOS script or something like that, that is set to a default program that does nothing more than aim the antenna when it wakes up and starts running.

There are places where the desire for physical realism comes up against the brick wall of the game's inborn limitations, and this is one of them. The problem is that the game cannot have a vessel actively performing motions when it's not within the tight "physics bubble". Therefore 'station keeping' and 'antenna pointing' isn't something a probe can do when you're not looking at it. The game is modeled on "one ship at a time does stuff. The rest are stuck" and this is pretty deeply embedded in the system. Thus it's unfair to introduce certain kinds of realism like this one. Yes real probes have to physically point their antenna, but real probes aren't physically *prevented* from doing so like the ones in KSP are, where a probe cannot be rotating itself when you're flying another rocket somewhere else. In the real world, multiple probes are doing multiple things at the same time, with multiple teams of ground controllers talking to them. I suspect that's why RT didn't make you physically point the antenna but instead abstracted it with a menu option to "point" at a thing. If you had to physically point it, then it would break contact after a bit of time warping in which the vessel cannot move itself or change anything because the game has locked in place due to the time warp. Even a scripted system like kOS still cannot force that to change. (The only thing it could do is re-aim the antenna after a time warp is over, but it can't aim the antenna during the months of sitting there under warp, while a real probe could do that because waiting doesn't freeze the universe in the real world.) Also consider the case of the relay antenna. If your rover is relaying through a satellite in orbit, both the rover and the satellite would need to aim their antennas at the same time, and they can't because of the physics bubble problem. You'd have to be constantly switching focus back and forth between them, reloading the scene again and again to keep both pointed the right way.

I think this line in the Readme.md could use a re-phrasing: This just didn't make much sense to me at all. I was pretty sure KSP takes a lot more than "five sixths" of a GB and Windows takes more than "one half" of a GB. It took a while to realize the slash meant "or". The "fraction" meaning of slash is the first thing you'd naturally think of when it's being used in the context of digits like that.

This has been a problem before with CurseForge and I was wondering if them, or Squad, or Take 2, might have some idea how to get on top of this problem and keep it from happening again and again: I just tried to update LaserDist to a new version, which I compiled for KSP 1.7.3. CurseForge's interface when you upload a file refuses to let you type in your own free-form number for the KSP version - you must pick from the list. But the list they give you is often out of date and wrong and prevents you from telling the truth. Right now, the list they presented me doesn't go higher than KSP 1.7.1. I compiled against KSP 1.7.3's DLL so I don't want to make the claim that it's for version 1.7.1 when it's not. But I have to. I am forced to "lie" by claiming it's for KSP 1.7.1 instead of 1.7.3 by the interface, or I cannot finish uploading the file. This has happened before with patch releases not showing up in the list on CurseForge, several times, until weeks later.

Version 1.2.0 out (compiled for KSP 1.7.3). This fixes an issue that cropped up in KSP 1.7.x where if you edited the part.cfg file (or used ModuleManager) to change the min/max values for bending the laser aim, LaserDist didn't use those values properly and kept using the default, ignoring your edit. (This was because previous to KSP 1.7.x, it was sufficient to alter those values for the Editor (VAB) and that change would get inherited by the Flight scene too, but as of KSP 1.7.x, the Editor and Flight scene need two different API calls to apply the override to both of them.)

Way to miss the point. What I was describing is somebody who only opened the Memgraph window long enough to use it to pad the heap space and for no other reason, and then never looked at it again. The whole point of this mod is to effectively do that without the window at all and without the overhead of tracking that graph data, like you just said.

This makes good sense. I suspect that the majority of people using memgraph are just going: "Okay, let's set this up: alt-*, alt-end, alt-end, alt-end, alt-end, alt-end, alt-end, okay I hope that is enough padding. Now to close the window and never open it again."

@TriggerAu - I have tried your advice for "Problem 2", and as far as I can tell, switching to using TryGetFieldUIControl() fixed that problem perfectly. I don't know if it was a timing issue or not, since all I had to do was replace my call in the same place in the code with that one instead to make it work. Thanks again for this. As for "Problem 1" - I made an issue in the KSP bug tracker for that one, as requested. Here's the link: https://bugs.kerbalspaceprogram.com/issues/23003

We get the range values *at the moment* each time the script is trying to alter the value during flight, not ahead of time. Perhaps there's a timing issue with the fact that this is happening in FixedUpdate instead of during the GUI pass? At any rate, I'll re-write it to use this TryGetFieldUIControl and see if that fixes it. I'd prefer to use whatever KSP is using so that if KSP changes again like this in future versions, if I use the API they're using then I'm more likely to automatically get the right behaviour without making changes. After I try this today, I'll make sure to put an issue in the tracker about "problem 1". First I'll need to try it for each kind of servo part, to ensure I know which BaseServo's have the problem. I only know for sure about Pistons, and have been using that as my sole test case so far. I haven't tried the other servos yet.

Thank you for the reply. Exposing the value as a float (not a string that we in turn have to decode back into a float again) would be ideal. The reason we use the KSPField, KSPEvent, and KSPAction systems to expose PartModules to kOS scripts is that these are universally a system all PartModules use (so we don't have to write hundreds of different wrapper classes around the hundreds of different kinds of PartModules in the game). And they let the players' scripts use names they can learn by just looking at the game UI. Exposing a KSPfield value on the PAW that is readable as a float (not as a string) would be the easiest from our view, as it fits in with what we already do. Also, if it's a KSPField, BUT it is marked as being hidden from the gui, then what will happen (unless we code a special exception case just for this one instance) is that kOS will still deny a script from seeing it, again under the design principle that any method or field that isn't explicitly exposed to the player is one kOS assumes it wasn't given permission to show to the player by the author of the PartModule. Here's an example of what is done with the mod LaserDist - a mod that was designed specifically with kOS in mind. It exposes a "distance" KSPField on the PAW for kOS to be able to read with its generic PartModule KSPField scraping code. The field *does* have some string formatting to the display, *but* that formatting is done by the guiFormat attribute value instead of the field being an *actual* string. i.e. it is defined like this: /// <summary>Distance the laser is showing to the first collision:</summary> [KSPField(isPersistant=true, guiName = "Distance", guiActive = true, guiActiveEditor = true, guiUnits = "m", guiFormat = "N2")] public float Distance = 0.0f; Doing something like that (where the field is really a float, but just displays a string via formatting) means that while the player sees the string with the "m" attached to the end, rounded to the nearest 1/100th, the actual float value of the field is what a kOS script sees. I have no idea if this is do-able without hassle in the servo modules, or if the string assumption is buried "too deep" in how it works. Well, we do use UI_FloatRange already, but not with that specific code. I didn't know about the call TryGetFieldUIControl - instead we do it in two steps: Step 1 - Get the field. Step 2 - After getting the field, then use the UI_FloatControl that is attached to that field. It appears that the logic to bypass the range limits of the current field and instead take the range limits from a different field are buried inside this TryGetFieldUIControl call, if I understand what you're saying. If that is the case then we should be able to fix the problem by using that technique instead. It will require some refactor of what we're doing, but it if it works in a more universal way then it's worth it. Thank you for the help, and I'll be able to try it tomorrow or the day after.

Thank you for asking! (Seriously I never expected a SQUAD staff member to care about the problems of a small-audience mod like kOS). Given that this is more about kOS than Graphotron, I decided to answer your question in the kOS thread instead of here. The response is here:

(This is a continuation of something that started in another thread over here:) I'll try to explain it tersely, since I figure you don't want to go down the rabbit-hole of getting deep into the kOS code. Problem 1 - reading values that don't always update if the PAW isn't showing: An example of a "read" value that seems to only be reliable if the PAW is open is this: On a ModuleRoboticServoPiston, the KSPField "Current Extension", we get the BaseField from the gui name on the panel with this code (this code is generic for all PartModules, but so far has only exhibited this problem on the new servo PartModules): /// <summary> /// Return the field itself that goes with the name (the BaseField, not the value). /// </summary> /// <param name="cookedGuiName">The case-insensitive guiName (or name if guiname is empty) of the field.</param> /// <returns>a BaseField - a KSP type that can be used to get the value, or its GUI name or its reflection info.</returns> protected BaseField GetField(string cookedGuiName) { return partModule.Fields.Cast<BaseField>(). FirstOrDefault(field => string.Equals(GetFieldName(field), cookedGuiName, StringComparison.CurrentCultureIgnoreCase)); } Then once that BaseField is found, then we retrieve its value with this: field.GetValue(partModule) This *almost* works all the time. If the PAW is open, it works. If the PAW *was* recently open it works *for a short while*, but eventually the value freezes and stops being updated if the PAW was closed maybe 30 seconds or so ago. (Maybe the amount of time it takes for something inside SQUAD's code to get garbage collected? I don't know, but if *feels* about that long.) Problem 2 - Setting a KSPField that has a UIFloatRange control on it (sliders in the PAW that are tied to floats) that has range values that describe restrictions the UI seems to be ignoring or getting from somewhere else. Example: There is a KSPField called "Target Extension", on the ModuleRoboticServoPiston. The actual behaviour the game has when a player manually uses the mouse on that field in the PAW appears to be this: The allowed range of values is [0.0 .. 2.4], without enforcing a stepIncrement (i.e. it allows the slider to land on any un-rounded value like 0.342010301 or whatever. It may round the display using a string formatter, but the actual value isn't rounded.) But the behaviour the game appears to be "advertising" with its UIFloatRange control attached to that KSPField is totally unlike that. The UIFloatRange is claiming the following which just isn't true at all: The allowed range of values is [0.0 to 100.0], with rounding to the nearest 1.0. (UIFloatRange.minValue = 0f, UIFloatRange.maxValue =100f, UIFloatRange.stepIncrement = 1f). The effect this is having on kOS is that because kOS has to enforce these UIFloatRange rules in all *other* PartModules to prevent scripts from "cheating" (see below), any script attempting to set a ModuleRoboticServoPiston's extension to something like 0.342 will end up setting it to 0 instead. If it tries to set it to 0.51, it will become 1.0. Because kOS is enforcing what UIFloatRange.stepIncrement is claiming, and in this case it's claiming Target Extension has to be rounded to the nearest 1.0, that means a kOS script can only set the piston to exactly 0 meters, or 1 meter, or 2 meters, with no other in-between values allowed. I have the beginnings of a special derived class of the PartModule wrapper in kOS to try to discover when the PartModule is of type BaseServo and when it is, to suppress its normal enforcement of these ranges and instead look for the values from elsewhere (I've worked out what I think is the path to get from the field to its actual ranges in these cases (which are taken from one of the other fields set in the VAB) , but that's not an optimal solution as it requires treating BaseServo PartModules differently from all the rest. Instead of a test that says "if type is BaseServo then look for the range value here instead", I'd prefer something that is class-agnostic about it, if there is a data field or property that tells me "this UIFloatRange's values should be taken from over Here instead". (An Explanation of why kOS has to enforce the UIFloatRange min, max, and stepIncrement values for all the other PartModules): Many of KSP's PartModules (both in stock parts and in modded parts) appear to have no protection against a mod like KSP setting KSPFields to values a user wouldn't be allowed to in the UI. kOS has those range enforcements because otherwise a kerboscript could simply do something like set an engine's Thrust Limiter to 5000%, cheating the engine to be 50 times stronger than it should be, or set a Reaction Wheel's "Wheel Authority" to 400% and cheat the wheel to be 4 times stronger than it should be. kOS takes the strategy of not allowing a script to do anything a player isn't allowed to do, so we check what the PAW's controls are allowing and enforce that. (Not just float ranges, but also not letting a script set a value when it's marked as hidden from the PAW right now, or press a KSPEvent button when the PartModule has decided that it shouldn be masked from view on the PAW right now (thus a script can't for example, Decouple an already decoupled docking port).) One problem with what kOS is doing is that I know it's not proper form to try to make an API out of a user interface, but we do it because it's the only reliable way to ensure we aren't letting a kerboscript do something the player isn't allowed to, or that would confuse other PartModules' code. (Just because a class made a KSPFIeld or a KSPEvent public doesn't mean they expected any random user to be able to alter the value at will - so we only alter the values when the UI would normally allow it - under the assumption that a PartModule would be written to expect the value to change unexpectedly if it has opened it up for players to mess with it via the PAW. So far this technique has worked well as a generic way to work on all PartModules without having to write hundreds of special case kOS wrapper classes to access the hundreds of different kinds of PartModules. But the servos in Breaking Ground seem to have broken some of our assumptions about how to detect what PartModules allow and don't allow.)

There is a similar problem with kOS and the new DLC's robotic parts. Many of their status fields don't update if the part action window is not open, and setting their fields often has very buggy behavior if the part action window is not open when it was set. It seems in this latest DLC SQUAD took some shortcuts to save on CPU time by bypassing some code if the window isn't open (perhaps on the assumption that if the user can't see it, then the value can't possibly be changed (for settable fields) and if the user can't see it, then the value doesn't need updating (for info fields)). This has been making it a PITA to try to support the new DLC in kOS. You may be getting a similar problem with fields in general.