Padishar

It was mentioned in a recent devnote. Basically, RequestResource is horribly inefficient, especially for the all vessel and stage priority flow modes, some large vessels can easily spend more than 50% of the CPU time in that function which effectively halves the frame rate. There are various optimisations that are planned but it was considered to be too much of a change to include in 1.1 what with all the other Unity5 changes so it got pushed back.

Just because something is public doesn't mean that you shouldn't care about how the API is intended to work and, instead, do what you like with it when there is a perfectly good function to do what you want (TransferResource in this case). There is no if about it, the addition of these events (and the opening up of some other resource related bits) is the first step in the overhaul, intended to allow certain people to experiment with various ways of optimising the resource handling.

I suspect very little will get upset about the event firing. Someone was asking about how to detect when the user toggled the flowState on a part the other day but I doubt you would upset whatever they were doing. However, TransferResource definitely shouldn't take any notice of flowState. E.g. data.from.TransferResource("EVA Propellant".GetHashCode(), amount); ...should definitely work in this case though you should probably only get the id of the resource once and store it. Please don't even consider doing this. TransferResource (that RequestResource and various other bits of KSP code calls to actually add or remove resources) now fires some very important events when parts change from full<->non-full and empty<->non-empty and you doing it yourself will skip this which will break stock and mod code (perhaps not immediately, but certainly when the resource overhaul happens in 1.2). No, all TransferResource cares about is flowMode (in, out, both, none). RequestResource also honours the flowState and the ResourceFlowMode (stack, all vessel etc.).

Cool, that explains it then. I can't think of any obvious issue from forcing it true just before you call RequestResource. I'd be interested in knowing what changed from 1.0.5 though. Presumably, the flowState used to be true because RequestResource did used to check it. flowState was a plain bool in 1.0.5 but is now a property (so changing it can fire an event) but I can't see how that would cause this without some other change elsewhere. I'm not sure how the Kerbal part and vessel are built when you EVA but I suspect it builds a ConfigNode and Loads it so presumably the setup of that must have changed.

No, if they did that then solid rockets wouldn't work anymore because the ModuleEngines just does a requestResource on the part. I think it unlikely but it's possible. "EVA Propellant".GetHashCode() should equal from.Resources[0].info.id. If it doesn't then RequestResource will fail to find it on the part. If spaces are a problem then you may find the "correct" id is actually "EVA".GetHashCode(). Also, have you checked the flowState property of the PartResource? If that's false then RequestResource wouldn't work even if it managed to find it. If that is the case then you should be able to use TransferResource instead which ignores that and also ignores all fuel flow mode stuff to just take it from the part itself. You would have to call from.Resources.Get() with the id of the resource (name.GetHashCode()) to pass to it.

Yes, that does look a bit odd. About the only thing I can think of is that the Kerbal part has already been removed from the "vessel" it is in. Can you print the value of data.from.vessel.parts.Count?

I would suggest you loop through data.from.Resources and print out what is in the part...

It looks like the fix for the disabled button state in career mode isn't allowing for the fact that the Update function is being called before the AppLauncher has become ready. It should just need a null check adding... Edit: I have just submitted a pull request with this fix. Can you describe your issue in more detail, perhaps a screenshot (with the KER window in "All stages" mode) or upload an example craft file? I suspect this is the usual issue with it not simulating stages "above" the root part of the vessel. This is a complex issue to fix as the general case requires the simulation to split the vessel into multiple vessels on staging and continue simulating all those that still have potential deltaV. A slightly less general, but still fairly complex, method would be to decide at staging time which sub-vessel should be considered the primary one and simulate that rather than always doing the one containing the root part. If it isn't that issue then the craft file and screenshot will allow us to see exactly what you are seeing...

Unfortunately, this is almost certainly due to the fact that all the stock UI now uses the new Unity5 UI mechanisms while lots of mods still use the older OnGUI based system which is rendered after the new UI stuff. Hopefully, some cunning modder will be able to find a way around this but I certainly won't be holding my breath. The mods will probably be updated to use the new UI mechanisms before that happens...

Nice work... Total part (and vessel) count?

The signature is the bit that appears at the bottom of all of his posts... You can set you own signature up in your Account Settings page.

Indeed, though the link for the 1.1 version is to curse.com rather than curseforge.com so people will have to suffer the somewhat ad-heavy, main curse site rather than one with no ads...

It is also possible that the extra stress on the integrated video could be causing the CPU to overheat after a while and thermal throttle. Or it could be the issue seen during the pre-release where an 8 core CPU suddenly starts using all 8 cores for no apparent reason. Or it could, like you imply, be something that might actually show up in the logs...

You could have done one in the time it took to write that post and then you'd find out...

Though it sounds most likely to be the common "my laptop isn't using the dedicated GPU for the 64bit version of KSP 1.1" issue. If this is the case then the logs should show it using an integrated GPU (e.g. an Intel HD) instead of your NVidia one. You should be able to change your video card configuration to always use the NVidia card for KSP_x64.exe. There are links to more info in the following thread:

Every time the game runs it writes a log file called output_log.txt into the KSP_Data (for 32bit) or KSP_x64_Data (for 64bit) folder. This is the most important log file for diagnosing what is going wrong. You should upload the file to a file sharing service and post a link here. You should also include a DxDiag report (there are instructions for generating this in one of the sticky threads in this sub-forum).

Version 1.1 of KSP requires that virtually all mod plugins need to be rebuilt for it. You should check the forum thread of the mod concerned and see if there is a 1.1 compatible version available yet. If there isn't then you will either need to remove the mod for the time being or roll back your KSP to the "previous stable release".

This sounds more like the garbage collection stutter to me. This has been present in every version of KSP but there are a large number of factors that can affect how badly noticeable they are. To confirm it is the GC you can install the GCMonitor mod and switch it to showing the Mono memory and reduce the scale to 0.125s. This should show a sawtooth pattern in the graph with the pauses corresponding with the drops. KSP 1.1 has not significantly reduced the amount of garbage being created in general compared to 1.0.5 though it does appear that Unity5 makes the collection pauses (slightly) less noticeable for some people. A few issues with specific bits of code in KSP have been fixed which does greatly improve it in some (fairly obscure) cases.

If it is a memory problem then removing all of RO will almost certainly fix it but it isn't the fault of any specific mod in RO, just that using lots of part and visual enhancement mods uses a lot of memory. As I said above, check the commit size during the load and I suspect you will see it go over 3.4GB before it crashes...

Welcome to the forum. Please read the sticky "How to get support" thread in this sub-forum and either follow the troubleshooting instructions in there or provide the information needed for anyone to diagnose your problem (logs, mod list etc.)

That new log has a big chunk missing from the middle. It would be better to upload the whole file to a file sharing site rather than using pastebin. The only thing I can see that is (a little) concerning is that CloudsManager is doing an awful lot of stuff on scene changes (and various other -Manager objects to a lesser extent). I presume these are all part of StockVisualEnhancements so you could try removing that and see if the behaviour changes...

Well, it's hard to say for sure. Most of them appear to be there, at least the ones that I remember starting... Using that method of finding it works fine for me to, it is just the "Activity/My Activity Streams/Threads I Started" from the top bar that goes wrong... Edit: Just counted and your link shows 20 threads and the other way shows 19 so it does look like only that one...

I suspect you weren't looking in the correct place. The default settings of the Windows task manager shows the amount of physical memory used by each process, not how much address space they have committed. You should be able to change what is shown by right-clicking on the column headings and doing "Select columns". Enable the display of "Commit Size" and keep an eye on that all the way through the loading process...

No, for most people the x64 version of KSP 1.1 is more stable than the 32bit version because the gradual increase in memory doesn't cause it to hit the 3.5GB (or so) memory limit... Please read this sticky thread in this sub-forum for details of how to post a useful support request: Pay particular attention to the bits that talk about DxDiag and the output_log.txt file. If the game is crashing before the output_log.txt file gets created then there is something seriously wrong either with your install or with the setup of your machine. I would recommend getting steam to verify the game files. When providing the log file, please do not include them in your post (even in a spoiler tag), instead upload the file (preferably zipped if it is huge but it probably isn't if it's crashing that early) to some sort of file sharing site (dropbox and google drive are better than random sites with loads of ads) and post a link to it here. Edit: Also, the crash log in the OP would appear to show it dying very early. The most likely cause of this is some problem with your graphic card drivers and/or directx, so I would recommend you check for an updated video driver.

Welcome to the forum... I find it hard to believe this could be anything to do with KER but it really is impossible to tell without more information. Please see the "How to get support" sticky thread in the Support sub-forum for modded installs for instructions on what you can do yourself and what you need to provide for others to be able to help (e.g. logs, save file etc.).