DMagic

@OctaviusGaius I don't think Engineer allows for that anymore. The toolbar button popup for Engineer uses a different UI system from the rest of the mod and so is likely to be a lot of trouble to work with Blizzy's toolbar.

I've always assumed that KSP just doesn't like having things be affixed to the surface of a planet. I've noticed the floating parts thing a few times, and I think it's new, or worse in KSP 1.4. I don't think there is anything preventing just attaching the parts to a regular vessel that is landed on the surface. I'm not sure if just plopping down a few structural panels would be any more secure than attaching the parts to the surface, but it might be worth a try.

The hammer and pods both run the same experiment, you can technically run it from only a pod, but you get very little science return. You can also run the experiment from the pods when a hammer is nearby and get the appropriate amount of science. Again, though, this is all the same experiment, there are just options for how it is run. There is some number of pods (5 I think) where, if you have enough deployed near the hammer you will always get the full science amount, regardless of any distance and angles. And it's all a bit of a mess on the technical side, which is why I've been reluctant to try to improve or change the system in any way. Also, yes it has biome support: Also, my thoughts on science balance: I definitely recommend Celestial Body Science Editor to lower the science gains from the Mun and Minmus. It forces you plan longer missions to other planets without feeling like too much of a grind. I find it works best with smaller, relatively simple probes to other planets so that you can quickly launch a lot of cheaper rockets.

I think this covers most of it. Also, yes the pods can be fragile. I need to see about just making them indestructible somehow.

@Elon Kerman Jr This works fine in 1.4. You probably want to use the version of Unity that matches KSP (2017.1) and the latest version of the part tools for the version of Unity. Otherwise everything works the same as before.

@Darks :v The science transfer function depends on your settings for Science Relay. You can use the stock settings menu to change the requirements for a science transfer to be possible.

I think they generally work about as you would expect: most of the time it's fine, until something changes and it isn't fine anymore. For Cities: Skyline I think the mods work in a way that's broadly similar to KSP, you have building mods, which are just new models and don't generally have problems with updates (though Cities bizarrely treats every single building as a separate mod, which can make managing and finding them a pain), and then there are plugin mods (Cities is also built on Unity, so I think the mod platform is somewhat similar to how KSP mods interact with the game), which go haywire when a new update is released. The major difference is that Cities has an in-game mod manager that allows you to disable certain mods, making mod-breaking updates somewhat less of a concern (some mods can't really be disabled or removed without breaking a saved city). The other major difference is that Cities has supported Steam Workshop right from the start, so the modding scene is centered around that, not like the fractured mess that is KSP modding.

I think the target heading has some way of gradually changing over time with SAS on, but tapping F immediately resets it. That's basically what I use it for. I think it might be more useful when making larger changes in heading, you can point at the new heading, hit F, then it won't wobble around or try to reset its heading.

@Omeran You don't need any kind of Kerbal to use those parts. Is the asteroid between the two receivers? Are they both attached to the asteroid, if not then you'll need to make sure that the other receiver is the target of your current vessel. It can be tricky to get everything lined up because of some recent changes to KSP that make it so that any other parts will block the signal between the two receivers. So you need a clear line of sight between both receivers with nothing but the asteroid between them.

Those values are probably null because the listener event is being fired in the Awake method. You could use Start instead, or start a coroutine and wait a few frames to allow for everything to be initialized.

Tracking Station Evolved has been updated to version 4.0 for KSP 1.4.4; get it on Space Dock. It fixes the KSP 1.4 related bug that was preventing vessels from being focused on when clicking on their tracking station button. Note that neither Space Dock nor Curse have been updated with the KSP 1.4.4 release tag, so despite what they say about supporting KSP 1.4.3 this version only supports KSP 1.4.4. If you want to use the mod with KSP 1.4.3 or earlier use version 3.0. I'm not sure what version CKAN will support, the .version file included in the release specifies KSP 1.4.4 as the minimum supported version.

Something like this: [KSPAddon(KSPAddon.Startup.Flight, true)] public class AddListener : MonoBehaviour { public static EventData<UIPartActionResourceTransfer> onTransferSpawn = new EventData<UIPartActionResourceTransfer>("onTransferSpawn"); private void Start() { onTransferSpawn.Add(OnTransferSpawned); //This probably only needs to be attached once, but using AddOrGetComponent insures that you don't //end up with multiple copies of your listener UIPartActionController.Instance.resourceTransferItemPrefab.gameObject.AddOrGetComponent<TransferListener>(); } private void OnTransferSpawned(UIPartActionResourceTransfer transfer) { //Check if part or resources are relevant, check for other parts, etc... Part p = transfer.Part; PartResource r = transfer.Resource; List<UIPartActionResourceTransfer> targets = transfer.Targets; //Add your own listeners to the in, out, and stop buttons transfer.flowOutBtn.onClick.AddListener(OnOutClick); //etc... } private void OnOutClick() { } } public class TransferListener : MonoBehaviour { private void Awake() { AddListener.onTransferSpawn.Fire(gameObject.GetComponentInParent<UIPartActionResourceTransfer>()); } } The listener MonoBehaviour gets attached to the prefab, so whenever KSP spawns a new resource transfer control element, it will make a copy of that prefab, with your listener alongside it. Then when your listener script starts it will go through its Awake, Start, etc... methods and you can use one of those to find the UIPartActionResourceTransfer component, which should be on the same game object, and fire an event with that component as an argument. Then your event listener can do something with that transfer component. Modifying prefabs in this way can be a fantastically useful tool when you are trying to do something with stock KSP mechanisms. The only problem is the inconsistent ways that KSP uses to handle prefabs, sometimes they are easy to find and public like this, other times you have to get them by name from AssetBase, and other times they are just really hard to find or private.

The simplest method might be to attach a listener MonoBehaviour to the UIPartActionResourceTransfer prefab (UIPartActionController.Instance.resourceTransferItemPrefab), when the listener script is awakened you can do whatever checks are necessary to accomplish what you want. All of the relevant information should be public: the part that the transfer control is attached to, the resource, all of the other parts that are currently part of the transfer. You could attach your own listeners to the In/Out/Stop buttons, they are also public, and that would be the simplest way of determining when they are clicked on.

My solution for this is to simply not worry about using every science part for every vessel. I like to think of it more like how real world probes work, where each has just a handful of experiments. So instead of strip-mining every biome with every experiment just put a few different science parts on each probe and collect however much science is needed. Unless you are the completionist type and have some intense need to collect everything available I think it works out pretty well. And you avoid having to resort to drastically reducing the science gain amount, which just makes things tedious. Another thing to consider is to use my science multiplier mod and reduce the science gains for Kerbin, the Mun and Minmus. That way you stretch out how long it takes to complete the tech tree while giving yourself more of an incentive to explore the other planets.

Yes, it looks like they made a slight change to how clicking on the tracking station vessel list works (I have no idea why). Since this mod relies on the stock vessel buttons as a sort of backstop to how it functions this change affects how the mod works. I'll need to update to make it so that the first single click focuses on the vessel, though I'll probably wait for the inevitable 1.4.5.

I don't think RedShell was ever the only data collection service used by KSP. As far as I know it also uses Unity Analytics, the plugin is still in the KSP_Data/Managed folder. I don't know what KSP uses it for, basically every mobile game uses it for ads and in-app purchases, but KSP doesn't have any of that. There could also be something talking directly to Squad, or some other T2-related service. And obviously, if you are playing on Steam there is probably some connection there, too. Of course, they could just spell out exactly which services are collecting data, where they are sending it, and why, but then I suppose that would be too much to ask for.

1.4.4 is up on the bug tracker now, and I logged the one about freezing when exiting the settings menu.

The Steam summer sale started at about the same time as the KSP update was released. So slow speeds are to be expected for a while. Also seeing this.

@TaxiService That's what I've seen, too. Every time I test it with CNC (or any other mod someone reports a conflict with) it works fine. I'm sure that there is something about the way Science Relay is calling some of the CommNet methods that causes errors somewhere. But people can always just turn off the connection check in the settings menu to bypass any vessel connection restrictions.

I think the comm connection requirement for the stock M700 scan is hard-coded, so there probably isn't much you can do about it. But if you are using SCANsat you can just turn off stock resource scanning (or just disable the Instant Scan function) and scan with the M700 the SCANsat way.

I've never been able to replicate any of the problems related to Science Relay crashing with other mods. It seems to be related to mods that do something with CommNet, but it always works fine when I try it, even when I've tried with all of the mods people who experience the bug are using. Since I can't get any replicatable group of mods or situation to cause the crashes I can't mark it as incompatible with certain mods. So my only suggestion is that if Science Relay is causing crashes then don't use it. And no, to my knowledge none of the science management mods are related (ForScience and Automated Science something, might have been related at one point, but I think they have diverged quite a bit). That isn't related to this problem anyway, which is about freezing and crashing, not momentary hiccups.

The layers may all be in use, but probably not all of the time. Maybe try to find a layer for VAB part icons, or something like that.

How are you generating the texture? And do you know if it is working correctly. If you want to quickly verify that the texture works you can draw it with OnGUI. GUI.DrawTexture, or something like that on the OnGUI method. (On phone, so I can't give a real example).

I gave it a D. I feel like the engine plates and a few of the Soyuz parts are well done, the engine plates especially as they fill a role that wasn't really accomplished with mods (I think there were one or two that made some kind of interstage fairing) and make engine clusters and mismatched engine sizes in the middle of a stack work much better than before. But overall the parts are mediocre at best. Squad seem to have continued their strategy of passing off parts to interns or people working on them on the side (is it too much to ask for a consistent color palette within parts of the same family, or something like stripes that match up...). I'll take others' word for it that the engines are unbalanced (the Saturn V replica engines seem like a particularly disappointing oversight), but there are many other issues that shouldn't have made it to release or seem like poor design decisions: drag issues with the variants (it's a shame they went for the most bare-bones version of variants), geometry errors on a fuel tank, fairing problems, service bays that are too small for any real use, the absurd RCS on the Mun lander, so many attachment nodes that the little structural panels are almost impossible to use (maybe use variants to cycle through different attachment nodes), and so on. And did anyone compare the preview versions of the parts with their final counterparts? I remember some UV unwrapping issues that were pointed out for the Mun lander that I immediately noticed in the final version. So I wonder how much of a "work-in-progress" those version really were. The mission builder is the real problem though. It makes no sense to me. Why would people go to the trouble or learning how to use the rather finicky and complex builder, only to shut out all console users and anyone who doesn't have the DLC from being able to play them. When you can just come up with a mission/challenge, write your own rules and restrictions, and post that on the forums it seems a little redundant. I understand that an in-game, formalized challenge system could be interesting, but this implementation, and as part of a DLC that instantly divides the player-base makes little sense to me. And given the dearth of community missions, and the complete lack of interest in the Squad missions (each one gets one or two replies compared to the old challenges that would get several pages), it seems like others think so, too. It's mostly just disappointing. This is the only time that I'm aware of where Squad has dedicated a very long time and a lot of development resources to a single, gameplay-based aspect of KSP (compared to something like upgrading Unity, replacing the UI, or just improving the code and performance of the game as in 1.2). The other gamey parts - science/tech tree, contracts, strategies, Kerbal professions - all seem like they work whipped up in a month or two with little concern for how well they actually fit in or work. For contracts they spent several versions progressively making them a little better (test launch clamps on the Mun ), but they are still fundamentally the same. And the Kerbal professions and science system have been haphazardly added to and changed over several versions, but I wouldn't call any of it much of an improvement, they are just a little different than they were at first. Strategies... So it's a shame that the mission builder is so boring. The problem is, is that I can't think of anything that would make for a worthwhile DLC. The presence of mods basically makes the obvious idea of selling more parts almost entirely pointless, and given the quality and attention paid to these parts, I would say insulting. Multiplayer never made sense to me for KSP, it just seems fundamentally not designed for it. I can't see anything really interesting that could be tacked onto the game as DLC.

I recently discovered a simple way to modify KSPedia entries to add custom effects. Since these are all standard Unity components you can simply add any script to a KSPedia component and have it do whatever you want. It requires coding, but not necessarily anything complicated. The example I have is of making a kind of simple GIF (I don't think actual GIFs are supported by Unity's image formats). I make a KSPedia page in the standard way, add an image, then add a custom script to it that cycles through multiple images in a given time frame. This is the total code required for this effect: using System.Collections; using UnityEngine; using UnityEngine.UI; namespace UniversalStorage.Unity { [RequireComponent(typeof(Image))] public class KSPediaImageCycler : MonoBehaviour { [SerializeField] private Sprite[] m_Images = null; [SerializeField] private float m_Delay = 3; private Image _image; private Coroutine _cycler; private int _counter; private void Awake() { _image = GetComponent<Image>(); } private void OnEnable() { if (_cycler != null) StopCoroutine(_cycler); _cycler = StartCoroutine(CycleImages()); } private void OnDisable() { if (_cycler != null) StopCoroutine(_cycler); _cycler = null; } private IEnumerator CycleImages() { WaitForSeconds wait = new WaitForSeconds(m_Delay); while (gameObject.activeInHierarchy) { yield return wait; _counter++; if (_counter >= m_Images.Length) _counter = 0; _image.sprite = m_Images[_counter]; } _cycler = null; } } } This script has to be compiled and the plugin added to your Unity Assets/Plugins folder. This means that anything you want to add to KSPedia has to be done in a separate .dll assembly than what you might already be using for KSP, since anything referencing the KSP plugins can't be imported into Unity. What you do is select the Image component that you want to use in your KSPedia page, then add this script to it, then add all of the files that you want to cycle through to the m_Images array. You can set the time between changes by setting a value for the m_Delay field: Then make sure to add the plugin to your mod folder in KSP's GameData folder (if you don't the KSPedia page will still work, it just wont use any custom scripts you've added and the log file will complain). The result is this: This could be expanded to do basically whatever you want within the limits of Unity. You could add things like buttons to make the page interactive, or even add a working copy of a UI if you really wanted to. I haven't done any testing. But I think this may be due to texture compression, or the lack of compression, and textures with dimensions in powers of 2. When you add a sprite to Unity with a size that does not conform to a power of 2, a full size page of 2048*1536, for instance, it won't get compressed, or at least not to the same degree as a 2048*2048 texture. So maybe the best way is use separate textures for each image element and just make sure they are all powers of 2, probably 512*512 or 256*256 in most cases, and set compression to Normal or Low. For this single test page I had four sprites of about 400*500 and I was getting a ~800kb .ksp file, when I changed them all to 512*512 the file size was reduced to ~200kb.