DMagic

Maybe if you are creating your UI in the editor and exporting it as an asset. Creating a UI from script is not fun at all, and there is essentially no documentation for how to do anything complex. And it's not Unity 5 that brings the new UI, it's already present in Unity 4.6, the version used currently by KSP. You can create a UI right now if you don't mind a bit of hassle (meaning a lot of hassle ).

One of the nice things about space science is that it affords a huge amount of data collection methods that arise naturally, rather than as some kind of contrived, game-based design. Some instruments can just work whenever they are in the right conditions, slowly generating science. Others can require some specific interaction, like taking surface samples. It seems reasonable to have some science collection methods require some type of input, while others can be just a turn it on and let it run type of thing. Other instruments could work well with some very specific requirements. The seismometer like you described is one good example. I think my asteroid scanner is another good example. Require two instruments that have to be placed on opposite sides of the asteroid. This experiment is actually one that might work well as some type of mini-game. Instead of just placing the instruments on each side and getting science like it works now there could be some type of maximizing the signal-type thing, where you scan individual parts of the asteroid. Thinking about it more, this might actually be a good way to handle asteroid resource scanning. Rather than just knowing how much resources an asteroid has, and being able to instantly acquire those resources at the maximum rate, it could be interesting to require some type of manual scanning to find the best regions of the asteroid for drilling. Maybe there could also be an option to automate the process, it could either take longer or be less effective. SCANsat also has a great way of generating science; it provides useful information, uses intuitive and realistic methods that make sense within the game, and it encourages interesting mission designs (multiple sensors, different orbits, polar orbits vs the more common equatorial orbits). I don't really see that as being useful for other types of science though. The data provided by SCANsat is real and useful for the game. Something like magnetic field readings, temperature scans, or gravity scans don't reveal anything that provides any real value, or that shouldn't already be known (at least known well enough to matter, gravity scans might be interesting, but they probably wouldn't provide information that would actually affect anything on the scale of a spacecraft). So I'm not sure how useful SCANsat is as an example of how to generate science in an interesting way. One of the great things about KSP is that it provides so many options for different ways of playing the game. If you don't want to do anything tedious or time-consuming to gather science, then there should be options to allow that; there should also be plenty of options for people who want a more involved system for data collection. This is one of the main reasons why I don't really care all that much about balancing science points for Orbital Science, if you don't want to get science points too easily, just don't use every available instrument all of the time. And if you want to use all of the instruments you can always just turn the science returns down to absurdly low levels. There is no reason to require that all possible science must be gained to progress within the game, or to put it another way, I don't think that collecting science points should be seen as the primary method of adding difficulty to the game, just as a means of progression.

No, but someone else can. Now might not be the best time for it though, since Universal Storage is undergoing a major redesign of how the cores work.

How are you undocking the first time? It doesn't fire when you use the decouple option from the docking port. Or, it might be as you said, that it doesn't count for parts "docked" together in the VAB. You can use onVesselCreate if you want something that works every time. Of course, it also gets called for lots of other things. But any undock or decouple event triggers it; you would just have to do lots of checking to make sure that the event is triggered by the vessel you are looking for.

That's not too surprising, I'm guessing that it isn't correctly assigning the main vessel when attaching the part on EVA. Looking at the code I'm not even sure why I have it set up in a way that would cause that problem, there isn't really any reason to do so. It should be easy to fix it so that a reload isn't necessary. I'll try to test it and get it working properly with KIS after 1.0.5 is released.

I updated this for KSP 1.0.4. Details in the first post. This is the same version currently in use by CobaltWolf's [thread=135535]Bluedog Design Bureau[/thread].

Yeah, delete all of the other parts. The same is not true of the other Universal Storage parts, they share textures with the basic parts and won't load if you delete the other parts.

Is that your complete mod list, or the list without CapCom? Because CapCom isn't on the list. If it is installed what do you mean by not starting? There is no toolbar button? Do you have log files? Did you switch to Blizzy's toolbar and not add the toolbar button there?

It depends on how you play. Stock isn't really balanced for science at all, it is very easy to generate a lot of science points, but it relies heavily on using Kerbals and/or always carrying every available science instrument. This is more about giving you options. For stock science you basically have to do manned missions, going through the tedious collect and store science data process, all the while getting huge amounts of science for crew reports, EVA reports, and surface samples. For unmanned missions you either have to accept the huge transmission losses or make sample return missions with loads of each instrument. I really hate both methods. Orbital Science makes probes a more viable science gathering mechanism. It also gives you lots of options for which instruments to use, and there isn't really a need to revisit planets just to gather the science you missed on the first few trips. There is still too much science, the last time I played was with 60% science returns. But that really depends on how you play; if you use science labs a lot, if you methodically extract science from every biome, if you rely on manned missions and surface samples, etc... That doesn't really mean anything though. Getting every scrap of science, from every biome, with each instrument (multiple times for most experiments) isn't really any fun (unless you like that sort of thing ). So it's reasonable that the total amount of available science grossly outweighs the amount needed to unlock the tech tree. But you also have to account for asteroid samples, which give a huge amount for each sample and are unlimited, and the science lab, which also generates an unlimited amount of science, if you are patient enough. So I wouldn't worry about how much science is available, just about how you play, and how much you want to have to accomplish before you can fully unlock the tech tree.

I haven't actually tried it, but it's something that I've been planning to add. You can see what happens if you add the KIS module to the part and attach it.

I suspect Kopernicus, since the problem manifests while looking at the resource list for each planet. I suppose an error in a resource config from USI might also be a problem, but that seems unlikely. I do.

Yeah, stock science experiment animations are very limited. I haven't looked at my plugin for a long time, I don't think it has been updated for 1.0. There are only a few things that are broken by that, so it shouldn't be too much trouble to fix. I'll see about releasing an update this weekend.

You can draw a UI using either MBE or MBW (MBW inherits from MBE). The difference is that MBE should really on be used if you are using OnGUI directly. Most KSP mods add their window to the KSP RenderManager, which handles things like hiding the window (so don't use it if you want, for example, to draw something on top of the R&D or Mission Control UI) and I think some drawing order functions. MBW uses the RenderManager and has some helper methods for drawing complex UIs, making sure everything is run in the correct order, tooltips, clamping the window to the screen edges, etc... But only use MBW for a class that actually draws the window.

I think so, just make a backup.

I've seen this before with the same error. [EXC 01:37:05.011] NullReferenceException UnityEngine.Component.get_gameObject () KnowledgeBase.DisposeResourceList () KnowledgeBase.CreateResourceList () KnowledgeBase.OnMapFocusChange (.MapObject target) EventData`1[MapObject].Fire (.MapObject data) PlanetariumCamera.SetTarget (.MapObject tgt) PlanetariumCamera.OnVesselDestroy (.Vessel vessel) EventData`1[Vessel].Fire (.Vessel data) Vessel.OnDestroy () I have no idea why it's happening, but it screws up all sorts of things later on; from that point on your log file is full of errors. The SCANsat error comes a bit later, and is indeed very bad, but everything else is screwed up by that point. Since it's related to the stock resource system I would try scanning several planets with stock resource scanners and not doing any SCANsat scanning (or uninstall it) and see if the same thing happens. I'm just using the stock method (technically this method should be moved into the physics frame update instead of the regular unity update cycle, but I'm not sure how that would lead to this problem) for finding EC on the vessel and giving it to the SCANsat instrument. If that method is coming back with not enough EC then there is either a problem with too much EC, or with overheated parts.

SCANsat parts' functionality is not affected by heat. The only way to get the static on the map and for the scanners to stop functioning is to run out of power.

For maximum confusion the percentage used for the cutoff isn't the same as the actual resource concentration. I'm not entirely sure if the cutoff scale just uses the maximum resource concentration value from the config file, or if there is some variation, but given the relative uselessness of the stock overlay it doesn't really make a difference. The cutoff percentage is best used as a way to ignore the areas with very low resource concentrations, set it to 30-50% or so and only pay attention to areas above that cutoff level. The SCANsat wiki has a section on stock scanning, it covers stock mechanics as used without SCANsat. It also has sections on everything you can do for resource scanning with SCANsat (much more than stock ). Those interpolation values determine how much of the may is based on actual resource readings and how much is based on interpolations between those readings. Setting it lower makes the map more accurate, but slower to generate (the game just pauses for a second or so when generating the map at low interpolation values). You can also increase the map size to increase the accuracy and quality of the overlay, but this also makes it slower. Setting it to 1 will probably make the overlay very slow to use; I wouldn't go below 3. SCANsat has similar settings for its overlay maps, by default they use the same map size (512*256 textures) but a lower interpolation value (calculates every 8th pixel, instead of every 16th as stock does when the value is set to 4). Since SCANsat has a more efficient map generation method I always switch them to 1024*512 textures and an interpolation level of every 4th pixel, this makes the overlay far more useful without being too accurate; these values can easily be changed in-game to see the difference.

It used to be called EVA Fuel transfer, or something like that, but I thought that might be selling it short so I changed it to Resource transfer. I just put something in the description about fuel transfer though, so maybe it will come up better on search results.

No, like I said, the problem is coming from somewhere else; it affects both this and SCANsat, for more-or-less the same reason, but the original error has nothing to do with either. I can't help with the original error. I've never seen it before so I'm guessing it comes from some other mod, but I have no idea which.

I believe the problem is this, which occurs when switching back from your vessel in orbit to the space center (the last time you switch back): NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at KnowledgeBase.DisposeResourceList () [0x00000] in <filename unknown>:0 at KnowledgeBase.CreateResourceList () [0x00000] in <filename unknown>:0 at KnowledgeBase.OnMapFocusChange (.MapObject target) [0x00000] in <filename unknown>:0 at EventData`1[MapObject].Fire (.MapObject data) [0x00000] in <filename unknown>:0 at PlanetariumCamera.SetTarget (.MapObject tgt) [0x00000] in <filename unknown>:0 at PlanetariumCamera.OnVesselDestroy (.Vessel vessel) [0x00000] in <filename unknown>:0 at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 at Vessel.OnDestroy () [0x00000] in <filename unknown>:0 I have no idea what is causing this or why (the DisposeResourceList method is related to the list of resources in the knowledge base resource overlay window), but it is a major problem and errors in Orbital Science contracts are probably the least of your concerns. It also causes a nasty problem while loading SCANsat which needs to be fixed. Orbital Science is doing what it's supposed to do and gracefully handling the problem by resetting the contract rather than letting the error propagate to other areas.

I'm not seeing it, the contract is unaffected by reverting to launch/VAB for me. I need log files to find out more.

Don't forget to watch out for latitude values outside of the normal range too. I have occasionally seen values like -97oS x 10oE pop up. In non-stupid terms that would be -83oS x -170oW.

It's not necessary to use the scenario attribute, you can add your Scenario Module to the list manually, but using the attribute is the simplest way. And even if using OnAwake fixes the problem you should still make sure that absolutely any exceptions in the loading process be handled. Blowing up the Scenario Module loading process is about the worst thing a mod can do since it cascades down to all subsequent Scenario Modules.

More details would be nice for these.

This sounds like something for a separate mod, some kind of notes that can be attached to each vessel. It would be nice to have explicit support for contracts (and science experiments, crew, etc...) to help in organizing notes for each vessel. But this isn't something I would want to add here. There is already a lot of information packed into each contract element in the window, trying to stuff in more, or make each element take up more space isn't something I want to do. And if you just want to assign contracts to a specific vessel, just make a mission list named after the vessel.