Jump to content

MaxRebo

Members
  • Posts

    203
  • Joined

  • Last visited

Reputation

80 Excellent

Recent Profile Visitors

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

  1. But that's what he did: Since 1.1.2 runs with no crashes whatsoever for me (although far, far, far from being the largely bug-free experience it was in KSP1.1), I can only assume downgrading messed something up. I'm sure this goes without saying, but did you also fix the files after downgrading @Pesterenan? If you did, then I have no idea what might be happening to you. Your safest bet is reinstalling KSP completely. kOS v1.1.2 definitely doesn't crash KSP1.3.
  2. Ok, I managed to track down the issue to no mod in particular, but rather every solar panel (including stock ones). No solar panels = no phantom drain at all, even under high timewarp. The relative amount of phantom drain appears to be roughly proportional to the panels' combined maximum power output, and it's not like the drain doesn't happen without timewarp, it just starts at a very low level. Each timewarp then makes the drain worse (I managed to get what should be ~0.05 to ~25 by timewarping at 50x for a minute or so). Only quicksaving/quickloading will revert the drain back to its "normal" low starting amount. Unloading the vessel so that Kerbalism's background simulation kicks in will make the drain disappear - until the vessel is loaded again. Removing Kerbalism eliminates the drain completely, so I'm almost convinced at this point that the issue is with Kerbalism, and likely with Kerbalism alone, i.e. no mod conflict. I don't know how methodical @ShotgunNinja's testing procedures are, but considering the drain is almost unnoticeable at first without timewarp and even smaller the less power generation the vessel has, the bug might have gone unnoticed until now - especially if it's a recent regression.
  3. Generally yes. In a nutshell, the vessel's boot script first runs the framework file. Then all plugins it wants to use. They register their states with the framework via function pointers. Finally, the boot script invokes the framework's "master function" which then takes over control. One very common use case that exhibits the problem is first using a state defined by the SAS plugin (implemented in its own file) to hold some attitude (-> LOCK STEERING TO...), then switching to the "Manual Control" state (one of the very few states the framework ships in its main file) to do some manual stuff (-> UNLOCK STEERING). In general, locking and unlocking will happen in different files more often than not. This is probably a tough one, so good luck
  4. I'm absolutely certain I don't. Unlocking really didn't work. It's been like that since KSP 1.2, never experienced anything like it with basically the same code back in 1.1 and prior. However, while looking at my code long and hard, I found a workaround. Immediately before unlocking anything, I first have to lock it to something. Then unlocking works. The lock can be created in many different sub routines that even may originate from another file, dynamically loaded into the autopilot framework (it has a plugin-based architecture). It's under these complicated context-juggling conditions (which I can't be bothered to find minimal reproduction steps for, sorry) that unlocking failed. If I first lock in the same execution context in which I want to unlock then it works. It's a few bytes more that I'll have to shave off somewhere else, but oh well.
  5. So what is the correct way to unlock controls from cooked steering while the program is still running? I'm writing a MechJeb-like autopilot implemented as a state machine, and some states are supposed to leave certain controls on manual. Like a "hold orbital attitude" state should allow for manual throttling, and a "manual control" state should leave everything unlocked. However, neither UNLOCK STEERING nor UNLOCK THROTTLE do anything at all. I'd rather not re-implement everything in raw control - kOS diskspace is already limited as is.
  6. I'm experiencing a rather massive phantom drain of electric charge. For example, my ComSat has 3670 EC worth of battery, and it won't even last through half the night side in Keostationary orbit at a drain of about 3~5 EC/s (it's different every time) with everything but the probe core disabled. Flight planner tells me I should have 0.02 EC/s drain in this configuration, and last well over 8 days in shadow. But then again, Kerbalism won't allow me to include basically anything in the planning simulation. I only remember having seen the option a handful of times, and don't even recall what parts they were on (probably ScanSat). The only mods I have installed which could conceivably interfere with Kerbalism are RemoteTech and the WildBlueIndustries suite (MOLE, DSEV, Pathfinder, etc.). Does Kerbalism have a way of getting a breakdown of EC consumption? I don't want to complicate the setup further by installing additional mods like AmpYear for this purpose, since that would be another interference for sure. Maybe Kerbalism isn't even involved in the conflict (if it indeed is one), but it's the main suspect for obvious reasons. Any ideas or pointers would be greatly appreciated... /edit additional info: the phantom drain appears to only happen when the vessel is active, and only if it has been time-warped at least once while active (5x appears to be sufficient to trigger).
  7. What a very Jenkins thing to happen Thanks for the quick effort!
  8. It would appear http://magico13.net:8080 is currently unreachable. Server down?
  9. @Kobymaru @Terwin @DStaal @Gilph @jd284 Thanks all for the insight. Even with the ability to do disconnected bases (which truly is a godsend, and the most awesome thing about MKS for sure), I sometimes still want a few modules connected this way for reasons of aesthetics and immersion alone. Pretty sure at least their cfg's will need a rework for KAS 1.0, but the effort should be comparatively minor and IMO worth it.
  10. @Kobymaru: ^ I'd still like some clarification of the above... I'd hate to see them go, especially with the much more flexible and robust KAS 1.0 on the horizon.
  11. Small bug report regarding the port welding... with CLS installed, welding results in the two living spaces connected by the docking ports in question being permanently separated. Also, if there are passable parts that can't hold any crew between the docking port and the first crewable part on the "mother"ship side, then those get wrongly assigned to the "child" living space (see pictures below). In addition, when "Keep docking ports after welding" is enabled, there's a single exception being thrown during the welding: Here's the images: aaand the save, made on a minimal install (MOLE + Ship Manifest + Connected Living Spaces): MOLEWeldingTest.zip Just go to the tracking center and select the single station-type vessel in orbit (it's the above station), or just load the Quicksave. By the way, several MOLE parts that are supposed to be, are in fact not CLS-passable (like the Solar Battery Module in the above station, but from the top of my head also the larger of the two Interstage Service Compartments). I applied a custom MM patch adding the CLS module to the Solar Battery Module in order to get the results in the pictures above. I hope this helps. The port welding feature is just way too handy to pass up, and I'd rather not play without CLS...
  12. I had no idea, lol Oh well, I'm actually kind of glad I didn't find it back then, because recompiling Science Funding paved the way for me to be able to patch up other mods that I want updated. I have no regrets
  13. I'm not kidding myself into thinking I can be a maintainer at this point, so I won't make a new topic. But I do intent to keep using this mod, so I'll keep posting my updates here as new KSP versions come along (and compile PRs for @Ippo when appropriate - this time there simply were no code changes necessary).
  14. I'm getting really bad log spam from AY on the Bigby Orbital Workshop part from @Angel-125's MOLE in VAB/SPH (in flight seems to be okay): /edit Looking at it again more closely, I think this is probably due to how MOLE does things as opposed to being a bug in AY. Should I take this there instead?
  15. That makes perfect sense. I didn't really think about the not-implemented aspect of it, but now that I do, I fully agree.
×
×
  • Create New...