Chris97b

Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

16 Good

About Chris97b

  • Rank
    Just a guy who likes space

Profile Information

  • Location Array

Recent Profile Visitors

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

  1. It's a bit of a hack, but could you just set the mission deadline to something like 2 minutes? That way as soon as they accept the contract they have a limited time to roll out the aircraft and reach altitude. There's a certain amount of realism there too That wouldn't work for anyone using KCT, but it might do as a work around if there isn't any other way to do that.
  2. MM will tell you exactly why it didn't create a cache. In your case: Did you even bother to look at the log file?
  3. This is why I bought it on the KSP store and keep every stock version laying around just in case
  4. Hello All, I'm not sure if this is exactly an issue, but is the investor contract supposed to come up particularly frequently? I've already completed it twice and have active contracts for both the Hotel and the Casino, but the investor contract is still popping up fairly frequently. I would have expected that one to be once only, or at least wait until I've completed the Hotel/Casino before it shows up again. Not sure if this is intended, but I figured it was worth mentioning
  5. If you mean n-body gravitation, it's already being worked on: If you are talking about gravitation effects from ships, parts and the like, that will probably never happen as A: The effects are so small they would fall well below the margin of error of KSP's physics simulation and B: That would be *seriously* computationally expensive
  6. Ooh, shiny! I seem to be using the NFE reactors quite a bit lately. Would love to see that make it into AY
  7. Just FYI, MKS includes a patch that converts the MKS reactors to use the Near Future reactor modules if NFE is installed. Assuming you're running both mods the MKS reactors should work with AmpYear automagically if support gets added for the NFE reactors. Without NFE I want to say they just use the stock ModuleResourceConverter which means in theory they should already work with AY.
  8. Yeah to my knowledge the underscore thing is unique to the MODULE[ModuleName] syntax. In this case INPUT_RESOURCE and OUTPUT_RESOURCE are actually nodes. In other words, a node of type OUTPUT_RESOURCE (as opposed to say a node of type MODULE). From the stock ISRU config: In this case the :HAS conditions are actually nested, it's neither an OR nor an AND, we were trying to match a Module with the name ModuleResourceConverter which *contains* a node of type OUTPUT_RESOURCE which contains a variable with the key ResourceName. My understanding is that :HAS[@MODULE[ModuleResourceConverter],@OUTPUT_RESOURCE] would go back to the top level node when looking for the OUTPUT_RESOURCE as opposed to looking within the ModuleResourceConverter node. Take a look at the snip of the stock ISRU config above, that should make it more clear. Yep, exactly. What ended up working was: @PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT_RESOURCE:HAS[#ResourceName[MonoPropellant]]]]:FINAL The thing I got caught beating my head on was how to specify a node containing no name key at all. Apparently @OUTPUT_RESOURCE[*] just means a node of type OUTPUT_RESOURCE with any name, but still requiring that a name exist.
  9. Yep, exactly. That copies the monoprop module so anything not specified would have the same properties as the monoprop converter.
  10. The MonoPropellant resource is a subset variable of the OUTPUT_RESOURCE node, I would try this: @PART[*]:HAS[@MODULE[ModuleResourceConverter]:HAS[@OUTPUT?RESOURCE:HAS[#ResourceName[MonoPropellant]],@INPUT?RESOURCE:HAS[#ResourceName[Ore]]]]] (Note: I wasn't overly diligent in counting the brackets, I would double-check that) @nathan1 Many thanks for that, I was going crazy trying to specify a node with no name variable. I tried @OUTPUT_RESOURCE[] but that generated errors, didn't think to try it without the square brackets
  11. N/A usually (in my experience at least) means the craft doesn't have an antenna. Typically you would only see this on manned capsules, if that's the case it should say "Local Control" as opposed to Connected or Not Connected.
  12. Ok I have a strange issue, possibly related to 4.18 as this is the first time I have tried to pull up the [x] Science window since I updated it. The experiment window is completely empty, despite a number of experiments on the vessel, and I'm getting the following spammed in the logs: Any ideas?
  13. I've also had this issue happen with mods that store configuration files outside of a Plugindata/ folder. Remember that any changes to any config file that is not in a Plugindata folder will cause MM to invalidate the cache. If this is the case, check your KSP.log for which configuration files were considered to be out of date (MM will log which files have changed). *edit* My bad, just realized you said you aren't getting a cache file generated at all. Probably due to errors as Sigma88 mentioned
  14. Yep, some basic testing pretty much confirms the issue is just a matter of too many unloaded vessels. Interestingly enough, the perceived performance (IOW my "feel" for the frame rate) seemed to improve dramatically after removing only 2-3 vessels (out of ~115), and they weren't particularly more complicated than any others. I have an armada of 28 ships heading to Jool, mostly copies of each other headed to each moon. Removing 3 of them nearly doubled the performance. It's almost like there's a line that once crossed, everything goes downhill fast. That's sorta unfortunate actually. I was kinda hoping maybe there would be something I could do to make it playable at least. I guess I could remove Remote Tech and whack all of my comms setups, but that's the only thing I can think of that would still fit the goal of the save (colonize all 5 of Jool's moons). Interestingly enough, it doesn't really seem to be related to memory or GC. The memory usage was pretty constant across tests and the GC stutter is painful, but no more so than it has been the entire save lol. This would seem to agree with the idea that the issue is simply CPU related in terms of processing a number of unloaded vessels. I'm no expert coder by any means (not on your guys' level anyway), but it seems to me that if there's an interface that mods are implementing to change the mass of unloaded vessels, couldn't that interface have a mechanism to set a flag that the vessel mass needed to be recalculated?