Chris97b

Wow... I just... wow... I am somewhat disappointed that my fears the questions would be cherry picked to result in essentially a PR stunt turned out to be true; some part of me knew this would happen, but this... This is a slap in the face to every KSP fan out there. Champagne. To celebrate a release marked by "mixed" reviews on Steam, which are still hovering around 50% and massive amounts of refunds, if steam discussions are to be trusted. To celebrate a release which saw the number of concurrent players drop by an entire order of magnitude in 2 days. To celebrate a release which reviewers described as anywhere from "This is unplayable junk" to "It will be good eventually, I promise". Scott Manley basically put out a video saying, in so many words, "don't buy this" for christ's sake. Not yet anyway. And to this, we are drinking champagne. This is absolutely insulting. I had sincerely hoped this would be an opportunity for the developers to regain some faith from the community. All you needed to do was come out, answer the really tough questions honestly, and say "Look, we messed up, we get it." Instead, we get the image of the entire development team celebrating an abysmal failure of a release. If this is the case, you truly have lost touch with your playerbase. I for one hope that you misspoke. I sincerely hope the point of the champagne was not to celebrate, but to drown your sorrows following an abject failure of a product launch. Otherwise I fear I am losing what faith I have left in the future of this game.

It's worth mentioning that at this point KSP was a *free* demo

Spent 10 minutes trying to figure out how to pan the view in the VAB. Spent another 5 swearing about why the devs would change one of the most intuitive systems in KSP1. Tried to launch a rocket, game crashed Relaunched game, crashed loading career save Finally got my rocket on the pad. Staged off the boosters and destroyed my core engine. Spent 15 minutes trying to find the flight report to figure out what happened. Removed the boosters and relaunched. Spent 15 minutes trying to figure out how to add a maneuver node. Gave up and did it seat of the pants style. Returned from orbit and discovered the atmospheric physics are *way* off Splashed down and spent 10 minutes trying to figure out how to recover the craft. Recovered the craft and spent another 10 minutes trying to figure out whether it had actually recovered, and how to return to the VAB. Returned to VAB, game crashed. Wrote negative Steam review and started new KSP1 career.

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.

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?

This is why I bought it on the KSP store and keep every stock version laying around just in case

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

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

Ooh, shiny! I seem to be using the NFE reactors quite a bit lately. Would love to see that make it into AY

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.

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.

Yep, exactly. That copies the monoprop module so anything not specified would have the same properties as the monoprop converter.

Yep, looks perfect. @toric5 This should do what you need:

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

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.

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?

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

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?

Whoa... I shudder to think how many parts I probably have unloaded at the moment. That would certainly explain a few things. I guess I don't understand why that's necessary though, how could the mass of a vessel change if physics aren't being applied? I can't imagine a corner case where simply saving the total mass in the persistence file when a vessel goes on rails wouldn't be sufficient. Yep, I'll do some testing and see what I can come up with. Thanks very much for the tips!

Ok, so I've been having some issues of late, and I'm really at a loss as to where to look. I have a fairly heavily modded (~100 mods) install, and initially the performance wasn't perfect, but it was definitely manageable. It seems though that the further my career save goes, the worse the problem gets, to the point where the last couple of launches have been complete slide-shows, maybe 5 fps if I'm lucky. Just going around in Kerbin orbit with a decent sized ship (maybe 150 parts?) I'm seeing maybe 3 FPS at best. I don't have any reason to believe it's related to part count or a particular mod, as the modlist hasn't really changed since I started the save, and I have flown the same ship several times before with nowhere near this degree of issues. Loading the same vessel into a sandbox game gives me expected performance (not spectacular, but 25-30 FPS at least). I do have some visual mods (EVE, scatterer) installed, and my system isn't exactly bleeding edge (GTX 670, i7 4770, 32GB), but none of that would seem to explain how the performance would be fine initially, but severely degrade over time. Memory and CPU usage aren't terrible (around 12GB and hovering at about 20%, not maxing out any of the cores), and I'm at a loss to find the bottleneck. The only thing I can think of, is that perhaps it's somehow related to the number of vessels in the save? I have an admittedly large (~115) number of flights in progress, but I can't seem to understand how having many unloaded vessels on the other side of the solar system would effect the performance of the active vessel. There can't be *that* much processing going on with them, can there? I mean it's not like KSP does any kind of background processing, other than their orbits, which should be on rails anyway right? I'm mostly posting this in the hopes that someone might have some advice on whether there is any kind of profiling I can do, or other ways to help narrow down the issue. I'm stuck at this point feeling like I have no idea where to look, and no good way to narrow down the options. Thanks!

Hello all, I think I may have found an interesting bug, I was playing with some of the parts from MKS, and some of them are basically manned command pods that can double as probe cores when unmanned (ie: CrewCapacity >0; ModuleCommand and minimumCrew=0). With the latest Remote Tech, these parts always show up as "Local Control" and no signal delay, even when unmanned. I assume this is due to having a crew capacity, but I could be wrong about that. Not sure exactly what the issue is, but I figured it was worth mentioning

I've been playing with it in a test environment with just NFP installed (and NFP's config for the stock ISRU disabled). This one is the one that matches them all, but it is admittedly malformed. It was just one of the things I was testing. Note that it applies to the stock fuel cell as well as the ISRUs, which to me means that as soon as the :HAS[@MODULE[ModuleResourceConverter]] is met, then it matches. As I said though, this *shouldn't* work, I was just testing things.

Yeah, that should work, but I doubt you can do :HAS[@OUTPUT_RESOURCE[MonoPropellant]] as the key for that is actually ResourceName as opposed to just name. The way I understand it the @MODULE[modulename] is just shorthand for a module with key 'name' and value 'modulename'. Hence the @OUTPUT_RESOURCE[*]:HAS[#ResourceName[MonoPropellant]] I tested it several ways though and couldn't get it to work. It always matches either all parts with a ModuleResourceConverter (including non-monoprop ones), or no parts at all.

I'm no expert, but something like this is what I would have thought In testing though, I can't seem to get the nested :HAS conditions to work at all. Is this a bug perhaps?

Here's a quick one I threw together which makes it possible to deflate the inflatable heat shield before jettisoning it, which prevents the issues where the heat shield smacks the ship after decoupling