Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Dunbaratu

  1. Can we get a more specific description of the .Net version than just "4.x"? Because I don't know what is safe, I am only using 4.0, not 4.5. If I could use 4.5 it might be a good idea to do so, but I don't know so I'm avoiding it for now.
  2. This sticky post has one small piece of information that just became wrong in KSP 1.8: I noticed that Unity finally made all the platforms use a consistent name for the output log. It no longer makes Windows an exception where Windows uses output_log.txt while everyone else uses Player.log. Now all three platforms (Mac, Linux, Windows) use Player.log - if you still have an output_log.txt file after the KSP 1.8 update, it's a stale old copy leftover from the last time you ran a pre-1.8 version of KSP, and not the most recent run. I don't know if NathanKell is still around to edit that
  3. Okay it seems something went wrong when I copied over the dll's to the project, and I got older versions of the dlls from KSP 1.6, not the KSP 1.8 version. That's why the method was missing. I wiped KSP from steam entirely and redownloaded, then copied the DLLs over to the Visual Studio project folder and THEN it compiled. I don't know what I did but it was something on my end, clearly. It's resolved now.
  4. EDIT: The following question appears to be moot now. I found the answer, I think. See next post for explanation. Here is my first question to start the thread: PartModule.Fields.TryGetFieldUIControl went away When Breaking Ground came out, TriggerAU helped me with a problem in kOS, giving the advice that I should use this method when accessing the fields on PAW's for the servo partmodules of BreakingGround: bool PartModule.Fields.TryGetFieldUIControl(string name, out UI_Control control) This was a relatively new method I hadn't seen before KSP 1.7.x. But now
  5. Before posting to this thread, first make sure you've read this post: I decided to start this thread for any modders with a question about something that worked in KSP 1.7.3 but broke in KSP 1.8 and they don't know how to fix it. I'm starting it because I have my own question about that, but I figure it would be useful to have all these simple questions collected into one thread. This is just for questions of the form, "Previously I did this in 1.7.3 and it worked. In KSP 1.8 it doesn't anymore and I'm not sure what the new way is supposed to be to do it. What should I replace th
  6. In kOS, this code would store a list of altitudes around the equator: local the_body is Mun. // or set to some other body to measure. local alt_list is list(). local startlong is 0. local stoplong is 360. local steplong is 0.5. // samples 0.5 longitude degreees apart. Set smaller for more fine-grain measure. for long in range(startlong, stoplong, steplong) { // latitude = 0 to hardcode equator, longitude varies through the loop: alt_list:add( the_body:geopositionlatlng(0, long):terrainheight ). } // Now alt_list is a list of terrain heights around the equator. // Do whatever statistic
  7. I don't know what this code is *meant* to do, but what it *does* do is this: candidate1[index] and candidate2[index] are the exact same object. So you are adding +step then in the very next line -step, putting it right back where it started, each time. The reason they are the same exact object is this part here at the top: local candidate1 is data. //data is a list. local candidate2 is data.
  8. kOS has some difficulty controlling Breaking Ground's robotic parts for mainly this reason: - One thing SQUAD did during KSP 1.7.x in support of Breaking Ground's Robot parts was to reduce wasted calculation time by sometimes having a values in Part Action Windows only get recalculated when the Part Action Window is actually open. If the window isn't open, nobody can see the number anyway, so why bother updating it? But these fields on the window are generic KSPFields, which is the usual way kOS allows you to access any generic module on any generic part. So when kOS tries to read, fo
  9. The reason RT is a pain to maintain is because the signal delay is trying to do something via a MOD without good support for that thing from the base game. Namely, the thing that's hardest (from the mod maker's point of view, not from the player's point of view) about signal delay is that you need to insert a buffer in between the player inputs and the game seeing those inputs, and the KSP1 infrastructure wasn't really built to allow that buffer. So RT has to do some rather "rude" things to the base game to "yank" control away from all the other PartModules in the game and say "NO! I will n
  10. Sadly, every mod has its own way to drain power. There's not a universal system for mods to tag their resource usage with ownership. There's no "I'm the one that consumed this resource". Each mod, during its Update, tells the KSP system, "I am in this part, and I am consuming X amount of resource foo. Please follow the connection and crossfeed rules to remove that much resource from wherever the rules find it starting the search here." But no record is kept of WHICH mod asked to do that, once it's been done. So kOS can't universally ask "who consumed electriccharge just now, and how much
  11. (Disclosure - kOS dev here so I can't be unbiased) Mechjeb IS an autopilot. kOS is a toolkit for MAKING an autopilot. It's like asking "is this kitchen table better than this carpentry workshop?" Depends on whether you want customization and enjoy the D.I.Y. process, versus if you'd rather skip all that and just have the finished product. And you can't really even ask the question "well which is better at making orbit" or "which is better at docking", etc - because there's no such thing as "the" kOS program that launches to orbit, or "the" kOS program that docks, etc. Instead
  12. If it's a sounding rocket (as in not good enough avionics to steer) then what's happening is that RP-1 locks out the gradient throttle, allowing only max/min throttle. But the gradient throttle is how kOS moves the control lever when you LOCK THROTTLE. kOS doesn't have a special exception to act differently when the value is 1.0 or 0.0. It still uses the gradient throttle lever for those. Until RP-1 added this strange behavior, it was never a problem. To work around it - you can use these: // Use these instead when RP-1's avionics denies control over // varying throttle and all i
  13. KCT claiming an edit is more expensive than it should be (and thus takes longer than it should) bug - I think I can recreate it. Has anyone seen this bug besides me? I want to see if it's something others have experienced before I write it up as an issue: To recreate it: 1 - Build a rather expensive rocket - something that will cost like 40,000 or more funds. 2 - Launch it through KCT and wait the required time for it to get to the launchpad and be usable. 3 - Launch it. Get partway through the launch process - at least far enough to have dropped your first stage and
  14. @linuxgurugamer - https://github.com/KSP-KOS/KOS/issues/2606 You are right that this is annoying, but it doesn't seem to happen consistently. I can't get it to recur when I try. But at any rate the dialog box shouldn't even exist anymore anyway, which is the solution I'm going to go with.
  15. You're right, you shouldn't have to. Because it's not supposed to happen like that. It is supposed to be dismiss-able as soon as it appears. I went through the long output log and couldn't find kOS throwing any exceptions, although it was hard to tell for sure because kOS is mentioned a zillion times because of module manager, and there's hundreds of other exceptions from TweakScale, so I may have missed it - but I couldn't find kOS making any complaints. (The message is supposed to go away after you dismiss it, and the record of the fact that you've dismissed it once is saved in kOS's
  16. 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.
  17. That was in reference to my question about incorporating this code into RSS directly. The RSS license is CC, this mod's is MIT.
  18. 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 "https://kerbalspaceprogram.com/api/index.html", why are there two different links?
  19. 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.]
  20. 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.
  21. 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.
  22. 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.
  23. 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 ther
  24. 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.
  25. 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 ex
  • Create New...