Jump to content

Maeyanie

Members
  • Posts

    106
  • Joined

  • Last visited

Everything posted by Maeyanie

  1. There is one: https://www.dropbox.com/s/u167tlqjvkus7fj/Screenshot 2018-06-05 12.02.04.png
  2. Apollo missions really don't need much shielding, they're only out for a few days. Even Minmus isn't THAT far away. Only time you start needing a ton of shielding is if you're going on interplanetary trips and expect to be out there for months, if not years. And even then, you could just have the re-entry capsule unshielded so it floats, the part of the vessel which doesn't have to land can be as heavy as it needs. Honestly, I'm fine with the capsule weight balance the way it is, it's never been a significant problem for me. Just have to design with it in mind.
  3. You shouldn't need max shielding for a short trip to the Mun and back, not sure if the weight savings there would affect things.
  4. Not sure whether "down" there is temporary or permanent, but if you should happen to need a new Jenkins host, I can set it up on mine.
  5. When updating my SSPX-MKS error-fix, I noticed the new Kerbalism-SSPX integration contains a number of lines like: @crewCapacity = #$MODULE[ModuleDeployableHabitat]/DeployedCrewCapacity$ But, the variable KSP uses for crew capacity is actually "CrewCapacity"... despite almost every other field being lowercase first word. Is this intentional? If so, you may want to switch line 109 to be % (like all the others) instead of @, since that field doesn't exist.
  6. If you uninstalled using CKAN, make sure there's no stray "Kerbalism" directory in your GameData. ModuleManager will use the presence of a directory (among other things) when testing for whether or not a mod is installed, so even if the directory is empty it will still pass a "REQUIRES[Kerbalism]" test.
  7. Replacing the similarly-named .dll which comes in the original package, "whitecatindustries/orbital decay/OrbitalDecay1.5.4.dll"
  8. A page late to the conversation, but my approach is using Kerbalism science to analyze samples remotely, plus MKS which gives a trickle of science just for having scientists in a "kolony" (which can be a station or ship), somewhat abstracting the near-infinite variety of small experiments a scientist can do in an orbital lab.
  9. The station keeping is pretty handy, for when you don't want your expensive LKO research station to accidentally deorbit. But I'm with you on being able to live without mass concentrations.
  10. The SSPX one is caused by Kerbalism replacing the inflatable things with its own, then SSPX tries to add MKS workspace for them and errors. I fixed this in my own copy (until 1.5.1 is available) by adding checks and using the values from Kerbalism's stuff if it's installed. If you want it, just replace the SSPX file (the location is in your screenshot) with this one: SSPXR-MKS-Extras.cfg The MKS one is caused by it trying to add Water as an output to the stock fuel cells. I just commented this one out, but again if you want it, same deal: StockTweaks.cfg
  11. Short version: It has been recompiled, but there are some bugs. I don't think there's any new bugs, though, if you've used this before. The latest "full" release is ZAJC3W's compile for 1.3 (which works in 1.4 perfectly fine), and I've compiled a .dll for 1.4.2 with a couple of extra bugfixes (you can ignore the .diff files). There may be more bugfixes coming.
  12. I was also thinking about the bugs I'd been running into, and most of them involved leaving station keeping on while something happened... so an easy work-around, add a few lines to turn off SK when the throttle is used. Not sure whether you'd like a Github PR for this or what, but I put together a couple of patches... one which does the check every OnUpdate(), and one which only does it during the once-per-second check of whether or not the engines have changed. Not sure how much of a performance penalty doing it every frame would have, vs. the chance of messing things up if it only takes a <1 second burn to hit a problem. Edit: Put a compiled .dll in that file too, if anyone wants to try it without going through compiling it... it also contains that = to == change.
  13. Easier-to-reproduce bugs are having station keeping on, and doing... pretty much any sort of situation change. Suborbital-Orbital, Orbital-Hyperbolic, etc. It tends to crash the game, NaN out the craft, and similarly-bad things.
  14. I did poke through the code a bit to see if there were any obvious things which could cause the LAN thing... but, I don't know much about KSP mods, and the math involved in all of this is way over my head, so didn't get too far. There are a few other coding oddities like that I did see, such as DecayManager.cs line 534, " if (vessel = FlightGlobals.ActiveVessel) "... technically this sets vessel to FlightGlobals.ActiveVessel, and then checks if vessel isn't null, in a single line. I'm guessing that's a typo and supposed to be a == (check if the two are equal) instead, but it could be intentional. As much as I love the idea of this mod, I've had to stop using it due to running into a wide variety of craft-breaking bugs, so I'm not all that motivated to try to learn enough to fix it.
  15. I'm not really familiar with KSP modding in general, but I've at least worked with C# and Mono enough to compile stuff, so gave it a shot. Unfortunately, the result is that change doesn't even compile: DecayManager.cs(547,31): error CS1061: Type `Orbit' does not contain a definition for `longitudeOfAscendingNode' and no extension method `longitudeOfAscendingNode' of type `Orbit' could be found. Are you missing an assembly reference? I'll poke around in the KSP documentation and edit this if I see any obvious fix. Edit: Nope, the Orbit class doesn't have anything even remotely resembling a "longitudeOfAscendingNode" member, aside from the "LAN" it was orignally. Searching the Orbit class reference for the word "longitude" shows nothing.
  16. There seems to be an issue with Kerbalism and the current CryoTanks version. When adding a CT-enabled tank to a vessel in the editor and trying to open the Kerbalism planner, whether or not the tank contains cryogenic fuel, it spams this error in the log: [EXC 05:23:43.189] NullReferenceException: Object reference not set to an instance of an object KERBALISM.Lib.ReflectionValue[String] (.PartModule m, System.String value_name) KERBALISM.resource_simulator.process_cryotank (.Part p, .PartModule m) KERBALISM.resource_simulator.analyze (System.Collections.Generic.List`1 parts, KERBALISM.environment_analyzer env, KERBALISM.vessel_analyzer va) KERBALISM.Planner.update () KERBALISM.Launcher.update () KERBALISM.UI.update (Boolean show_window) KERBALISM.Kerbalism.Update () Edit: Also still getting that same signal indicator debug spam when vanilla commnet is enabled which other people are reporting, even using Jenkins build #69, which is the latest as of writing this. As an aside, personally I quite liked Kerbalism's signal module. Connections getting slower with range makes far more sense than just suddenly cutting out. But, it's your decision to make.
  17. It looks from the control position that the SAS is giving some left roll in the second shot, which should give you higher lift on the right side. It's not all that far to the left, though, so not sure if that's enough to cause the difference to be that large. It's hard to see exactly how the aircraft is built in those shots, but I'm not seeing any sort of rudder or other yaw stabilization, which would lead to it being unstable. That could be at least some of your problem. None of that explains why it would be intermittent, though.
  18. You can see the control position in the screenshot, there is quite a bit of right rudder and aileron to keep it flying straight. A lot more than I'd expect from just some slight discrepancy in calculations. It was reasonably stable, actually. I flew it around in patterns both directions for a while before landing it, and once it was trimmed to fairly hard right rudder and aileron as the screenshot showed, it was completely flyable. Aside from not having enough control authority to do right turns very well. The rudder is above the CoM, so yes, likely some of the leftwards roll is from that. The discussion at that time was more based around whether or not the drag (and L/D ratio) on PWings was significantly worse than stock parts, so I was more testing for if it would yaw to one side. Which it did, but the opposite side of what would be expected if they had worse drag. Not saying this is necessarily related to the problems AngrybobH is having. It doesn't sound like it is, from his posts since then. This was also a while back, so the problem may have been fixed by now for all I know, I haven't re-tested it recently... I don't recall seeing CKAN offer me any new versions since then, but, that could be me failing on the "recall" part of that.
  19. Yeah, unfortunately I can't really help much with your specific problem, as it's beyond my limited understanding of these things. All I can say is that there is some compelling evidence that there is an aerodynamics bug somewhere with B9 PWings and FAR... which is a shame, because they're really nice wings.
  20. No, it's not. This is from the previous discussion: https://www.dropbox.com/s/bzyyos0q51p6dlm/Kerbal Space Program 2017.07.05 - 23.51.46.23.png CoM is pretty close to the middle, so the weight is (roughly) the same on both sides. But CoL is off to the left, which has the stock wings. Then in flight: https://www.dropbox.com/s/2stujdvyhfe2sio/Kerbal Space Program 2017.07.05 - 23.58.37.24.png It needs large input of right roll and yaw to keep straight. If the B9 wing was aerodynamically the same except heavier, it would need roll to the left to compensate.
  21. There could be a design issue as kcs123 said, but there's definitely a problem with B9 PWings and FAR somewhere. A few pages back we had a discussion about it, and I created an experiment with a plane which had one B9 wing and one stock wing, with as close to identical size as I could get. It took quite a lot of control input to get it to fly straight. No clue about which side has the bug, or if it's related to what you're seeing. I think the person who brought up the issue reported the issue on both sides, so hopefully they're at least aware.
  22. The difference is probably that with FAR, the airflow is going more or less straight through the body and out the jet, where in reality that design has the slight problem of a pilot and such being in the way.
  23. I've also noticed a crash bug if station keeping is turned on during circularization. I think it was when the state changed from suborbital to orbital, but it's been a while so I'm not entirely sure any more.
×
×
  • Create New...