Jump to content

Dunbaratu

Members
  • Content Count

    3,845
  • Joined

  • Last visited

Everything posted by Dunbaratu

  1. 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, hen
  2. 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.1
  3. @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.
  4. 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
  5. 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. T
  6. 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.
  7. 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 prob
  8. 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.
  9. 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
  10. 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.)
  11. 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.
  12. 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."
  13. The feature I think would be nice would be if they could be harnessed for electricity. It would be handy on Laythe where solar panels aren't so good.
  14. @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
  15. 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
  16. 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
  17. 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:
  18. (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
  19. 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
  20. Okay I'll remember that for my next bug report whatever that might happen to be. I honestly never knew that's what it meant. I wonder how many bug reporting users know that? It might be a good idea to make it very clear in some kind of instructions. Although, in the case of my most recent bug report (Bug #22690), it is kind of impossible for me to confirm it is fixed. My bug was that a contract requiring EVA should never be offered when you can't EVA yet. Since offered contracts have an RNG aspect to them, it's impossible to prove the difference between "can't happen" and "just hasn'
  21. I just checked. It's back to normal. While you're here - can I ask this question about the bugtracker: When I submit a bug, and eventually it gets a fix in a release, the bug status changes to "ready to test". And then stays stuck like that forever. Was it SQUAD's intention that the person who reported the bug is supposed to test it and report back when that happens? If so that isn't clear at all. I thought it meant that someone at SQUAD needs to test it. @ManeTI - tagging so you notice - the forum merged my follow-up post into the above post so I thought you might not
  22. The Kerbal bugtracker site, here: https://bugs.kerbalspaceprogram.com/projects/ksp/issues?set_filter=1&tracker_id=1 Suddenly stopped showing me anything from after May 31. All the June content looks like it's missing.
  23. On further investigation, I've found the steps that trigger this one, and I would suspect kRPC users will have the same problem so I'll point out the cause and the workaround I had to use: It turns out that merely setting the "target extension" over and over is NOT sufficient to cause the bug. That actually works fine. I was doing more than just that step. I was ALSO setting the "Motor" boolean KSPField to True every update tick along with it, using code similar to this pseudocode: // // Psuedocode - not a real language // while true: { Set KSPField called "target extension"
  24. Have you gotten this to work without bugging out, even if the part action window is closed? I'm the current developer of kOS, which uses the same model as kRPC does for setting the Part Action Window float fields, and I'm trying to implement support for the new DLC robotics sliders and I keep running into a brick wall where the DLC PartModules only seem to work right when the Part Action Window is visible on screen. I came here to ask if kRPC users are having the same issue as kOS users are having. The two mods use almost identical techniques for scripted manipulation of PartModules, so
  25. Sigh - Nope. it keeps populating *for a while* with the PAW closed after it's opened. But after some time it goes back to being frozen again until you open the PAW.
×
×
  • Create New...