linuxgurugamer

The Mk4 is effectively Thunderbird IV from the 60's animated series The Thunderbirds

What you could do is take the Mk 2.5 Spaceplane Parts mod and tweakscale it one size larger to 3.75, which would be the same size as Mk3. It has some really nice parts including a loading ramp, Beluga cargo parts and more

No, that would be Kronal Vessel Viewer, and it's not updated for 1.8 yet

Well, a crew report is a kerbal making a report and storing the report in his pocket. So that the next crew report won't overwrite it. A thermometer does need to be collected, since it is external. But, once collected, you don't have to do the "take all, store all" Most likely

I'll go over the files later on. I put some additional debug statements in, so hopefully they will show me what's going on

Originally made by @cybutek, it hasn't been updated for a few years. Original thread is here: https://forum.kerbalspaceprogram.com/index.php?/topic/163826-13-store-my-reports-11-12017-07-31/ I've updated and optimized it for 1.8 since I desperately wanted it (ok, not desperately, but still wanted it) The primary job of this mod is to fix the inability for Kerbals to find glove-boxes within their vessel or pockets on their EVA suits. You can now make crew reports and have them stored without the need to exit the vessel, take all of the reports out, then put them all back in again. It also allows Kerbals on EVA to store science data within pockets on their EVA suits. Although this mod's primary goal is to alleviate the ridiculousness of crew report storage, it will also work with any other science experiments that have their own separate science containers within the same part. Experiment data will be automatically stored within these containers making room for further experiments. Availability Download: https://spacedock.info/mod/2289/Store My Reports Source Code: https://github.com/linuxgurugamer/StoreMyReports License: GPLv3 Installation Place the `StoreMyReports` folder found within the downloaded zip file into `GameData` found within the game's installation directory. Configuration To change these settings you can open the stock settings page Automatically Discard Duplicates When enabled this feature will automatically discard any duplicate science data if it already exists within the container (i.e capsule for crew reports and kerbal for eva reports). Save Experiments Result Dialog Position When enabled this feature will save the position of the Experiments Result Dialog Changes Added InstallChecker Added AssemblyVersion.tt Added stock settings page Removed old config support files (button, config window, config class) Changed Update to LateUpdate Added Events to catch when science is stored, removed an if from the Update (now LateUpdate) Moved 2 lines of code from OnExperimentsResultDialogOpened to LateUpdate for optimization Removed OnExperimentsResultDialogOpened method

What is it?

New release, 3.4.0.3 Removed LineDrawer.cs since it was unused. Moved "enabled = false" from cctor to Awake methods() This is an important update

Sorry https://www.dropbox.com/s/ocnvdkzxac5o73v/QuickStart-beta.zip?dl=0

Try this, please and let me know how it goes. I've changed the initialization a bit Hmmm. The only thing different is that you are running it from the Steam directory while I use a unique install location. I'll have to set up a test with Steam

@JadeOfMaar Any change you could add support for this mod: ???

I'll need a full log file, pls. It's working for me, so I'm not sure what's going on

@Galileo Are there any specific instructions for installing the supplemental mods? I usually install everything via CKAN, but when installing JNSQ 0.8.6, the following mods are suggested: Scatterer Environmental Visual Enhancements 2 Distant Object Enhancement Continued PlanetShine Rational Resources Strategia TextureReplacer (???) JX2Antenna CommNet Antennas Info Kopernicus So I select all of these and then CKAN suggests the following config for DistantObject-config: Distant Object Enhancement RSS 1.9.1.1 Distant Object Enhancement Continued default config JNSQ 0.8.5 I've already downloaded JNSQ 0.8.6, so why is it suggesting a config from 0.8.5? Then for PlanetShine-Config, I see the following: JNSQ 0.8.5 PlanetShine Default Config Spectra v1.2.3 I'm very puzzled about this, looking for some guidance And is TextureReplacer v3.7 needed?

There may be, but I'm not going to do that. This mod does not do anything with the Axis groups, and if I did that replacement, then you would lose the ability to edit the axis groups in-flight

New release, Quickhide 3.3.0.7 Fixed nullref when only on Blizzy toolbar Fixed typos in english cfg Fixed entry of time to only allow valid numbers and not show exceptions if an error Made right-click work on the Blizzy toolbar same as stock

Probably a result of the .version file not being updated

I think you meant “slipped” you can try the grip pads in one of the DLCs, or there is another mod with a ground anchor

Post a list of your mods, if you have a .ckan file that would be better

I've been trying to replicate this issue, and can't. Can you either post a video or a series of pics showing what's happening? Also, see my post right above, if there is a symmetry issue that might be the cause

I've been working my way through all my mods, and was pretty happy with the way things were going. I had actually finished updating all the code-based mods and was proceeding on the Part-only mods, when a bug report made me aware of a significant issue with a few mods. So I went ahead and built a full debugging environment, loaded up my new career game and took a look at the log file. Initially I thought it was just a bug, but then I found the same problem in 4 mods which were not mine, and 3 of mine, so I knew there was something pervasive and started to look. Then I started realizing that there had been various reports of KSP just hanging, just before it got to the main menu. As I started looking into this, I found that my new career install was hanging about 3/4 of the time before the main menu, but when I removed the bad mods (at the time, a total of 7 in a 150 mod install), the hangs disappeared. I realized I was onto something rather big. These were errors which weren't showing up in the regular log file, I needed to be running a debug version to see the errors; the debug version is much more verbose in logging. What I found was that as a result of the Unity upgrade, a lot of what used to be acceptable coding was no longer acceptable. Actually, in one sense the coding never should have been considered acceptable, but it worked, so was never an issue until now. I broke the issues down into the following categories: UnityException: get_dataPath is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. A somewhat misleading description, most often caused by trying to reference KSPUtil.ApplicationRootPath in either a constructor or as a property in a MonoBehaviour class UnityException: RandomRangeInt is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. This happened a few times, RandomRangeInt was being called in either a constructor or as a property in a MonoBehaviour class UnityException: SupportsTextureFormatNative is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. Very obscure, took a while to track down. A Texture2D or Texture3D was being initialized in either a constructor or as a property in a MonoBehaviour class Exception loading ScenarioModule *********** System.TypeInitializationException: The type initializer for *********.********* threw an exception. ---> UnityEngine.UnityException: get_dataPath is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. Called from MonoBehaviour ********** on game object 'ScenarioLogic'. A very obscure message. Turned out that the original mod was written as a ScenarioModule and worked well, but in the updated game it seems that things which were being done inside the ScenarioModule which should have been in a MonoBehaviour were causing problems. The symptom of this was getting null refs when attempting to enter some or all of the buildings at the KSC Unity not being thread safe This was a problem with the KSP-AVC and MiniAVC mods. I had seen a couple of messages about MiniAVC not working, and was planning on getting to it when finished with all the updates. Tracking these issues down in over 160 mods, written by at a guess of over 100 authors, turned out to be a major timesink. As of now I'm pretty sure I've caught most if not all of these issues in my mods. In total about 30 of my mods, both adopted and ones that I write, were affected. I also did some work on other author's mods to fix the issues and have submitted PRs (fixes) to all of those authors. Please note that while I listed the majority of the issues above, I think there were a few which I fixed which were mostly one-offs. The main reason this happened now was as a result of the Unity upgrade. The new version of Unity fixed a lot of bugs as well as adding significant performance improvements. Many of the issues I found and corrected were actually poor coding practice, but was accepted because Unity allowed it. There were times in the previous version of Unity that KSP used that these issues arose, but that was in some very limited and specific instances. For myself, everytime I adopt a new mod moving forward, I'll be testing it in a debug install to catch any issues before it gets released.

Make sure all dependencies are installed If that doesn't work, then post a log file (Player.log if KSP 1.8.x, otherwise output_log.txt)

That Output_log.txt is from KSP 1.3.1: [KSP Version]: 1.3.1.1891 (WindowsPlayer x64) (x64) en-us ============================== I have an indication that you may have two copies of the ToolbarControl installed: [LOG 09:04:55.633] ADDON BINDER: Create binding redirect: ToolbarControl, Version=0.1.7.0, Culture=neutral, PublicKeyToken=null => ToolbarControl, Version=0.1.8.2, Culture=neutral, PublicKeyToken=null [LOG 09:04:55.698] ADDON BINDER: Create binding redirect: ToolbarControl, Version=0.1.6.17, Culture=neutral, PublicKeyToken=null => ToolbarControl, Version=0.1.8.2, Culture=neutral, PublicKeyToken=null Or something else, I'm not sure. I really need the correct output_log.txt Edit: From what I can tell, you have ToolbarController 0.1.8.2 installed, which is the last version for anything prior to 1.8 You have version 1.7.19 installed of the Blizzy toolbar, you need to install 1.7.22.2, you can get it here: https://spacedock.info/mod/2090/Toolbar/download/1.7.22.2 or here: https://github.com/linuxgurugamer/ksp_toolbar/releases/tag/1.7.22.2

Check your recycle bin

Log file, please. I'll have to check to see what's going on with CKAN, and then maybe get out an update for the toolbarcontroller for KSP 1.7.3 and earlier

Nice catch, that was the problem line. Fixing it now New release, 2.2.0.8 Quickstart Fixed initialization of path to config file