Steven Mading

  • Content Count

  • Joined

  • Last visited

Community Reputation

796 Excellent


About Steven Mading

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Can you try ship:control:pilotpitch ? It represents the actual pilot's control rather than kOS's control. Maybe the Breaking Ground DLC can read that.
  2. That was in reference to my question about incorporating this code into RSS directly. The RSS license is CC, this mod's is MIT.
  3. Every time this post gets updated, I keep wondering: There are two links in the first post - an "official" link and a "doxygen" link. Given that both of them send me to "", why are there two different links?
  4. 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.]
  5. 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.
  6. 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.
  7. 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.
  8. 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.]
  9. 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.
  10. 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.
  11. 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.)
  12. 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.
  13. @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.
  14. 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.
  15. 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.