Tig

I'm assuming the crash fix came from this change to the code (Support lost texture event): https://github.com/ihsoft/KIS/commit/aec6da26f218311695bafe5b193709382967d691#diff-9fd2acd34859195030978517c3414ef4 If you don't mind me asking, is this an issue with c# in general or just unity's interaction with it. I've been trying to make a mod of my own (will have to see if that actually continues) and coming from a c/c++ background sometimes managed code is a bit tough. I just don't "trust" it, lol. I read the comments in the code... I guess what I'm saying is that I don't get it... I thought all of those issues just got handled and don't understand why your changes were even necessary in the first place. Specifically, this comment in the code: /// This method <i>must</i> be called if an icon becomes unusable. Otherwise, all the cached Unity /// objects will live and take memory till the scene is reloaded. Some of the internal counters /// will also not get updated as expected. With my background that scares the crap out of me. I thought that was part of the whole it-just-works-managed-code-magic. If I'm asking more than I realize, feel free to tell me be an adult and look it up myself. I don't mind. But if you or someone else that knows could point me in the direction of "its a c# thing" or "its a unity thing" I'd appreciate it.

Thank you for letting me know. Sometimes its hard to tell with kerbal's errors whether or not they are truly an issue.. especially with more complex mods.

I've heard about a bug in Unity on some systems with the log file. You can use the command line -logFile <pathname> to put it wherever you want. Some use it just for the convenience of not having to dig through the appdata folder after one of the updates. I did some more testing.. I'm very suspicious that the crash is happening when the garbage collector runs after having removed a container or two. I don't think its the number of containers so much as it is the timing of when the GC runs after having removed them. Even with padding the heap the game will crash for me if I add and remove a few containers and then just do nothing, waiting for a GC. The game is crashing for me (after having deleted containers) shortly after the current heap size exceeds the prior maximum by 30-40ish MB which in my experience is when the GC gets run.

Hey @IgorZ maybe this will help a little? Steps: Loaded up KSP, I got the IMC-22K on and 10 times before I crashed. Reloaded, Using MemGraph, linked below, and padding the heap with 1GB I got the IMC-22K on and off 39 times. Then crashed. Reloaded, did not pad using MemGraph. 11 times. Crashed. Changed MemGraph's settings in padheap.cfg from total of 1024 to 2048, so now adding 2GB. Reloaded, padded, 69 times (lol, sorry, its true ). Crashed. Now, maybe I got a little faster with my clicking... but I don't think enough for that. I should note this is on my work-in-progress modded 1.6. But I've been playing and modding for long time. No errors in my logs except for a few type mismatches from IFS/KSPIE. As for MemGraph, Sarbian and Padishar and now Linuxgamer did all the hard work, but I volunteered as lead guinea pig, lol. Hope it helps. Thanks much for KAS and KIS, I don't play without them. Edited: Also should note, nothing of any value in the crash log or the KSP.log or output_log except the following from output_log.txt (which I'm sure you're getting as well, but for the sake of completeness): ========== OUTPUTING STACK TRACE ================== ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E501C93) 0x00007FF79E501C93 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E2E1D03) 0x00007FF79E2E1D03 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E2B5F68) 0x00007FF79E2B5F68 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E5EC382) 0x00007FF79E5EC382 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E5ED235) 0x00007FF79E5ED235 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E5FD611) 0x00007FF79E5FD611 (KSP_x64) ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF79E7A431C) 0x00007FF79E7A431C (KSP_x64) 0x0000000041B54FC2 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.Object:DestroyImmediate (UnityEngine.Object,bool) 0x0000000041B54F1F (Mono JIT Code) UnityEngine.Object:DestroyImmediate (UnityEngine.Object) 0x0000000059B967E5 (Mono JIT Code) KIS.KIS_IconViewer:Dispose () 0x0000000059BD4464 (Mono JIT Code) KIS.KIS_IconViewer:Finalize () 0x00000000055384B9 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) 0x00007FFAF97282F1 (mono) mono_gc_is_finalizer_thread 0x00007FFAF984BD7E (mono) mono_unity_class_get 0x00007FFAF9728625 (mono) mono_gc_is_finalizer_thread 0x00007FFAF9793B87 (mono) mono_thread_interruption_request_flag 0x00007FFAF9848E77 (mono) mono_unity_class_get 0x00007FFB3BCB3DC4 (KERNEL32) BaseThreadInitThunk 0x00007FFB3D573691 (ntdll) RtlUserThreadStart ========== END OF STACKTRACE =========== **** Crash! ****

1

Go into CKAN, at the top it says File Settings Help. Click Settings, go down to "Compatible KSP versions" Click the box next to 1.3 so it has a checkmark if there isn't one already. Remove checkmarks from all other versions (1.4, 1.5, etc) Click Accept. ----- CKAN should now only load mods or the versions of mods that are 1.3 compatible. As a note some mods that stopped being updated before 1.3, like 1.2 for example, might still work with 1.3 but no promises. Also some mod authors don't specifically change the minimum version, so if a mod is failing try rolling it back to a time when its max version was in 1.3. This can be accomplished by clicking on the mod in question, then in the right hand frame click on versions. Find the prior version you want and double click, a dialogue box will ask you to confirm installing the earlier version. Hope that helps.

Hi @FreeThinker I'm getting a number of errors in the KSP.log from type mismatches. In a number of the MM patches the moduleID field has a string like moduleID = IFSCCmeshSwitcher. In the error log it says it is expecting an integer. Quick check of the code shows that moduleID is defined sometimes as a string and sometimes as an integer, but I could easily be misunderstanding what's going on. I hope that's helpful. Thank you for the mods. snippet from the KSP.log (no errors in the output_log): [LOG 00:05:24.217] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/CT2502/CT2502' has no database record. Creating. [LOG 00:05:24.222] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/CT2503/CT2503' [ERR 00:05:24.246] Invalid integer value! Field moduleID, value IFSCTmeshSwitcher on object of type InterstellarFuelSwitch.InterstellarMeshSwitch [LOG 00:05:24.374] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/CT2503/CT2503' has no database record. Creating. [LOG 00:05:24.379] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/CT2504/CT2504' [ERR 00:05:24.404] Invalid integer value! Field moduleID, value IFSCTmeshSwitcher on object of type InterstellarFuelSwitch.InterstellarMeshSwitch [LOG 00:05:24.487] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/CT2504/CT2504' has no database record. Creating. [LOG 00:05:24.492] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2501/EC2501' [LOG 00:05:24.516] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2501/EC2501' has no database record. Creating. [LOG 00:05:24.520] DragCubeSystem: Creating drag cubes for part 'EC2501' [LOG 00:05:24.546] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2502/EC2502' [LOG 00:05:24.567] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2502/EC2502' has no database record. Creating. [LOG 00:05:24.572] DragCubeSystem: Creating drag cubes for part 'EC2502' [LOG 00:05:24.598] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2503/EC2503' [LOG 00:05:24.618] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/EC2503/EC2503' has no database record. Creating. [LOG 00:05:24.623] DragCubeSystem: Creating drag cubes for part 'EC2503' [LOG 00:05:24.645] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/IST2501gas/IST2501gas' [ERR 00:05:24.653] Invalid integer value! Field moduleID, value IFSISTGmeshSwitcher on object of type InterstellarFuelSwitch.InterstellarMeshSwitch [LOG 00:05:24.670] PartLoader: Part 'InterstellarFuelSwitch/Parts/TankRevamp/IST2501gas/IST2501gas' has no database record. Creating. [LOG 00:05:24.678] DragCubeSystem: Creating drag cubes for part 'IST2501gas' [LOG 00:05:24.708] PartLoader: Compiling Part 'InterstellarFuelSwitch/Parts/TankRevamp/IST2501lqd/IST2501lqd' [ERR 00:05:24.716] Invalid integer value! Field moduleID, value IFSISTLmeshSwitcher on object of type InterstellarFuelSwitch.InterstellarMeshSwitch

Well I do appreciate that, like I said I intended no personal offense. I just didn't want to see people buy low priced cpus that are bad for KSP, and also didn't want people to waste money on a $500+ cpu. I can believe that with 1866 ram. I think that you'll find that with increased ram speeds you get diminishing returns. Downclocking from 3600 to 3000 I lost *maybe* 1 fps. If you don't mind I'll throw 2 cents in here. I think maybe a current price point chart would be most helpful. I mean the reason most people don't buy a 2080 TI gpu isn't because the don't want one... I'll list one from AMD and one form Intel where I can and bold the one of the two I would suggest. Usual caveat applies: this is for KSP only, it in no way suggests that the bolded cpu is better in all circumstances. CPU price Intel AMD Special Note Absolute cheapest ($60) None Athlon 200G Save $35/50 and buy the R3/i3 if possible Approx $100 i3-8100 Ryzen 3 2200G iGPU in the R3 is vastly superior to the i3's if that matters to you. 60-70% of a RX550 Under $200 i3-8350K i5-9400F Ryzen 5 2600x The R5 is better at almost any multi threaded use over the i3. Just not KSP. Under $310 i5-9600K Ryzen 7 2700x i5 is faster and ~$50 less. Over $310? I truly don't recommend anything. But if you want to spend more than $400 go with the i7-9700K, i9-9900K or the i7-8086K. Once overclocked the i7-8086K should give you the best performance since they were selectively binned. AMD over $310? Nothing. When 3rd Gen Ryzen hits the market that may change. It should be noted that you might easily find 4th through 8th gen i5s and i7s for good prices... but that fluctuates very quickly. Again to ward off any fanboy claims, every intel cpu I've suggested beats its AMD rival out of the box on single thread performance. Also, if its a K they typically overclock more on a percentage basis. One additional note, if you really need to spend as little as possible right now, skip the discrete graphics card, buy the R3 2200G and use the integrated Vega 8 GPU. It's shockingly impressive for an iGPU and demolishes the UHD 630 iGPU in most modern intels.

I'll try to be as nice as I can, but the hardware "advice" in the tutorial is terrible. Astonishingly bad. Sorry. I'll try to give some good advice. KSP is still heavily limited by one major thread. From a practical standpoint you can treat it as a single-threaded game. It also is not very graphically demanding; stock KSP will work fine with any mediocre discrete gpu. ---------- As such the only thing you really need to worry about is the cpu, specifically IPC (instruction per clock) and clock speed. It is positively ridiculous to suggest 6+ core cpus in order to play KSP. Period. Hyperthreading? Again, simply ludicrous. So then, what cpus are the best for KSP? Any modern intel K processor or a 2nd generation Ryzen (also 3rd gen Ryzen when it releases). The best is still any intel K processor that is overclocked. You do NOT need an i7. You do NOT need more than 4 cores. 3rd gen Ryzen might be better when released... no one knows for sure yet. But a K intel is better than 2nd gen Ryzen. If you have to go cheap with intel go with a non-K, an i3 or even a Pentium G series... Suggesting Bulldozer and Piledriver AMD cpus? They have GARBAGE IPC. This isn't even up for debate. IPC ~40% less than intel core proc, ~30% less than Ryzen. The fastest was the FX-9590, 200+ watt TDP and it gets wrecked by sub 30 watt U-series laptop cpus. A FX-6300 as a suggestion? really? A FX-8350? really? Threadripper, sigh. Please, please delete those suggestions. The cheap list for AMD cpus is Ryzen 3 and Athlon 200GE. ---------- I'm not trying to offend anyone. If you've got what you've got and money is an issue you do the best you can. But suggesting that people invest in an AM3+ system from 2012 is pouring money in the toilet. There are cheaper, faster and more future proof platforms readily available. ------- On ram, I'm not aware of any testing showing that ram speed makes any significant difference in KSP. But please don't do this: Please don't overclock your ram unless you really really know what you're doing. If you need DDR4 3000 ram, don't get 2400 ram and OC it. Errors from OC memory are not fun to deal with. Just spend the extra $10 and get 3000 ram. And even then only for some other game - KSP doesn't care. No offense, but anyone on a 7/8 year old FX-6300 doesn't have the qualifications to tell other people what they should do with their modern cpu. To anyone interested, Ryzen in general doesn't overclock as well as Intel core. Yes, you can overclock it, but you'll typically run into thermal/voltage limits faster than you will with an intel K. Good cooling is always necessary. The rest is Silicon lottery... ------ What I would suggest: - An 4 core intel i5 cpu (or i3 8th gen), with a strong preference for a K if you're comfortable with overclocking... it doesn't need to be the latest generation, the difference between a 4th gen and 7th gen i5/i7 at equal clock speeds is tiny. - 8GB of ram, 16 if you're modding - A good but not ridiculous motherboard socket. Not AM3+. Not LGA2066. AM4 good. LGA1151 good. If you're overclocking make sure the chipset supports it. - A decent discrete gpu, suggestions as of the date of this post under $100 would be a gtx 1030 or rx 550. If you're modding, for under $200 I'd go with an rx 570 or 580. ----- Caveats: 1) My advice applies to KSP performance. If you're playing other games then you may want a different processor. If you're encoding video/playing with large databases/etc. you might want a different processor. 2) KSP doesn't need a powerful gpu, that said some mods can quickly increase the demands placed upon your gpu. Stock KSP at its slowest will almost always be due to cpu limitations. Typically occurring during launches as you approach the speed of sound around 300m/s. 3) I'm not an intel/amd/nvidia fanboy. Over the last several years its simply true that intel has had better IPCs and higher clocks. Ryzen closed the gap significantly. I'm very hopeful 3rd gen Ryzen will be a game changer, better pricing for everyone if intel has high end gaming competition no matter what you choose. I suggested mostly amd gpus because as of today's date they have the best price/performance... that can change quickly and can be very different between countries. 4) There is a big difference between Ryzen 3 and 3rd gen Ryzen. Its going to confuse people.

Assuming you want to accomplish this with a small amount of delta-v one of the better ways to do it is by using Jool/Jupiter. This gives you two advantages: 1) The gravity assist from Jupiter will lower the delta-v needed to increase your orbit out to Pluto 2) You can use the large planet for a really cheap inclination change (as you approach Jupiter use a small normal/anti-normal, depending on the direction of the inclination change, burn so that you encounter Jupiter above/below its equator) As a side note, although in theory it would be possible to intercept a large inclination planet without matching its inclination, its darn difficult... like trying to shoot a moving car, except the car is traveling 500mph.

I know that Tweakscale is a dependency for Interstellar. But, are any of the patches in the Tweakscale directory necessary/strongly recommended for Interstellar? Put another way, does Interstellar rely on the patches in the Tweakscale directory in order to function and/or balance with other mods? To be clear I'm talking about the MM patches in GameData\TweakScale\patches, not GameData\WarpPlugin\Patches, the latter I'm keeping of course. Thank you for all your work on the mod.

Hey @DMagic thank you for all the mods. ScanSat 18.3 is causing microstutters approximately every second in game. In any location, even just driving a 15ish part rover around KSC causes the stutters. Its not gpu related, fps is unaffected. Its definitely CPU, you can see the counter flash yellow very briefly approx once every second.. There is zippo in the logs other than a lot of CurrencyConverter spam...is that part of ScanSat? Its not related to GC either, I've done a lot of testing for MemGraph (and GrumpyCollector before it), the GCs for me are around 2 minutes with padding. This is definitely every second and is not correlated at all with GC spikes. Reinstalling 18.2 and the stutter disappears. No other changes other than the rollback. Nothing at all in the logs. Sorry this isn't more helpful; I didn't save my logs from 18.3. I can certainly go back and reinstall them if you'd like but there's nothing there (other than CC spam)... I promise Thank you again, let me know if there's anything I can do.

Indeed I did. I tried to write it in a way that a newer player might understand. The irony of quite a bit of rocket/orbital science is that if you understand how to properly state a question with all proper terminology then you're likely capable of answering the question yourself. But see I find that inclination is the hardest part for newer players to deal with. Differences in inclination can greatly increase the needed delta v budget, and is more difficult/unexpected for beginners. Moho probably is the best example. This was my intuitive sense, I wasn't sure how to prove it... I mean, that the worst time to transfer would typically occur at the greatest inclination difference. Not to say that eccentric orbits don't change dv (your PE vs AP discussion demonstrates that) but just a few degrees of inclination can substantially increase dv.

I think this is a little lost in translation and I think the word that is throwing everyone off, including me, is "maximum" I hate to put words in the OP's mouth, but I think he is asking the following: In the set of all future optimum hohmann transfers between Planet A and Planet B what is the worst case scenario for the delta v required? In other words his question inherently involves non-circular orbits/orbits with inclination changes. (For circular orbits without inclination changes the set of delta v required for all future hohmann transfers between A and B would all be equal, of course) For instance, each year there is some optimal minimum delta v required to go from low orbit Kerbin to low orbit Eeloo. Create an array with the index representing the year and the value equaling the optimal minimum delta v that year to transfer from low orbit Kerbin to low orbit Eeloo. The theoretical array has an index from 1 to infinity. What is the "maximum" number in said array? I think that's what the OP is asking. If its not, well, I still think my version is somewhat interesting... (at least its solvable, lol) PS. I know the optimal transfer window from Kerbin to Eeloo is not exactly one year apart. But dammit, its close enough to make my point.

Short answer: No. Sorry. Longer answer: The command line arguments are actually for Unity, not KSP per se. They direct some aspects of the Unity player but are not visible to the game... I know there was some discussion in the Unity community about creating some sort of API to pass custom command line arguments along but I don't think the feature has been implemented. Squad has zippo control over that.