DMagic

Not paying enough attention, basically, . The next update will change the name of the assembly to UniversalStorage2.dll (along with support for the updated Orbital Science parts), so that MM won't get the two confused. Maybe next week, as everyone is a little busy this week. You mean that you want to create a new part that points to the WaterWedge mu file? Locking it to the single height variant would take some specific setup with the modules, I would have to look into it, but I think you might be able to get away with only adding a USMeshSwitch module that specifies the single height variant: MODEL { model = UniversalStorage2/Parts/Lifesupport/WaterWedge scale = 1, 1, 1 } NODE { name = attach transform = attach size = 0 method = HINGE_JOINT } DRAG_CUBE { cube = A0, 0.3431,0.7578,0.6327, 0.3432,0.8309,0.4578, 0.2848,0.9538,0.4575, 0.2848,0.9559,0.4198, 0.242,0.6476,0.4997, 0.2427,0.6366,0.5973, 0.01869,0.188,0, 0.5435,0.4862,0.7954 } MODULE { name = USMeshSwitch SwitchID = 0 MeshTransforms = WaterWedgeSingle AffectColliders = True DeleteUnused = True } The MODEL node points to the .mu file, and the drag cube is needed so that it has the right drag values for only the single height variant. Without any other US modules that should make the part start out in the single height variant and not allow any changes (USMeshSwitch doesn't contain any user-end functions by itself; SwitchID won't do anything in this case, but it has to be included in the config or the module wont work right). Then you can setup the rest of the part config like any other part.

That tutorial is in need of updating, or really just replacing with a purpose-built project, this and the several very long PM chains I've had trying to help people through the UI process have convinced me of that. It used to sort-of be in sync with the mod Basic Orbit, but the UI for that has changed fairly significantly, so the tutorial is really incomplete now. I pretty paranoid about saving the scene data. Whenever I make any changes I always try to save the scene. Even if all of the prefabs vanish, or the project gets screwed up somehow, as long as the scene file still exists somewhere you should still be able to load the scene and have everything where you left off. But yeah, saving everything you can and backing everything up is a always a good idea. It's KSPedia files mostly that use that extension (deleting all or most of those .ksp files is a great way to speed up the loading process). I assume that you can let KSP load the asset bundle and still be able to use it just. But I've never bothered figuring out how. Loading the asset bundle yourself is so simple, and you can do it whenever you want to, so it's easier to just change the extension and never have to worry about it.

Nice write-up. It is a lot simpler when you stick to just one plugin and avoid the whole moving information back-and-forth problem. A few things I noticed: You don't actually have to delete the prefab file every time you want to change it. When you drag an object from the scene hierarchy menu to the file menu to create a prefab you'll notice that the item in the scene hierarchy turns blue. This means that the item in the scene is tied to the prefab file on disk. When you select the item in the scene hierarchy menu you'll get an additional row at the top of the Inspector tab: Here this is a prefab for a KSPedia page, but the idea is the same for UI elements, parts, or anything else you can make in Unity. For KSPedia specifically deleting the prefabs each time you make changes is a real pain (I know because I also used to do that) because it resets the KSPedia entry setup in Unity. When you make a change to the object that you want to apply to the prefab, for instance, you add a new toggle to your UI panel, you just select the object in the hierarchy menu (or select any direct child of the object) and click the Apply button at the top of the Inspector tab. That will update the prefab file on disk. Then you can go to the Asset Compiler tab, update the bundle and build again. The Select button will select the file in the folder menu, and Revert will remove any changes since the last time you applied update to the prefab file. Sometimes you'll notice that Unity warns you about breaking the prefab link, for instance when you delete a child object, or remove a component from an object. When that happens the item in the scene hierarchy menu will turn black again, indicating that it is no longer in sync with the prefab. You can still click the Apply button in the Inspector tab and it will update the prefab file on disk and turn the item blue again. The KSP Part Tools Asset Compiler adds that .ksp file extension onto the end of all Asset Bundles it builds, but there is no inherent reason for it. KSP uses that extension to load all asset bundles during loading (for KSPedia pages and I think some expansion stuff). But if you are going to load the bundle manually you should either change or remove that extension. Sometimes you might have a reason to wait until after KSP loads to load your UI, in that case you will run into problems. If KSP gets to it first, then KSP will load the bundle into memory, then when you try to load the bundle again through your own code it will complain that an asset bundle with that name has already been loaded and it will fail. If you load it first then the worst that will happen is probably a log entry during loading. But there is no real reason to leave the .ksp file extension. I always either add my own, or just leave off the file extension entirely.

Those examples are hand-crafted designs, but there is no inherent reason why you couldn't improve KSP's terrain system to generate something in the same ballpark. There are all kinds of tools and methods that allow for procedural texture mapping and placement of decorations (trees, rocks, etc...). Things like terrain slope, height, smoothness and others can be used to produce moderately realistic looking terrain without the need for lots of hand-placing of textures or assets. And you could conceivably come up with multiple sets of textures and assets to be used on a planet that could be specified by biome, or some other method. I agree that it's never going to happen. But it's mostly time and the effort required that are preventing that, not anything inherent about how KSP works. It's also worth pointing out that performance isn't necessarily a problem. This kind of thing presents a ton of options for reduced settings: vary the number and quality of trees, vary the distance where a tree is replaced by a 2D billboard, shadow quality, lighting effects quality, texture quality, etc... All of that kind of stuff can be turned up or down to allow potato GPU's to run without getting baked (), and since most of KSP's performance problems are related to CPU-based physics there isn't too much of a trade off.

Have you tried waiting for FlightGlobals.ready? Or waiting for OnStart or OnStartFinished (if this is a Part Module). I guess you could also just ignore/wait out impossible temperatures like that.

Science Relay should still work fine with Remote Tech, but it won't have any knowledge about which vessel is connected to which, so you should be able to transmit to any vessel with a stock lab or science container.

Yes, I think it's supposed to be (the @ before MODULE has been removed): @PART[*]:HAS[MODULE[USDecouple]]:NEEDS[StageRecovery] { MODULE { name = RecoveryIDModule } } That means, check every part, then for each part with the MODULE USDecouple add the MODULE RecoveryIDModule, only if Stage Recovery is installed.

The screenshot in the post below yours shows the waypoint UI. You just click the little waypoint button in the lower-right corner of the map, then click on the map to select the location. With MJ support on there should be an additional button on the UI just to the right of the "Set" and "Cancel" buttons, called "MJ", I think. After selecting the location, click on the MJ button instead of Set and it will set the MechJeb landing location. @TheAngryHulk You have to scan the planet with something first, the Multispectral scanner for biomes.

They work fine for me. If they are still causing you problems you will need to provide much more detail: log files, mod version, KSP version, other mods related to CommNet, etc... Yep, they don't work with US 2, which is why I said they don't work a few posts up.

@SnailsAttack You are using Unity 2018, you must use the version of Unity that matches the Part Tools, 2017.1 for KSP 1.4.

@scottadges Yep. KSP will go through every folder and subfolder in GameData looking for certain file types (.mu for parts, .cfg for config files, any texture type, and a few more). The only place it won't load files from is any folder called PluginData. People use those folders to store files they don't want loaded by KSP (like SCANsat's exported map images), or so that they can manually save and load data, like for settings files. @Cooper42 I thought the KIS parts already had the cck tags. They are supposed to be in the localization files, so it's possible they got lost in the shuffle at some point. It might also be worth adding a custom US category, too. I've also been thinking about the science pod. It would definitely make sense along with the other science parts.

KSP just loads every file with the .cfg file extension in your GameData folder. It processes them and loads them as config nodes so that it can do whatever it needs with then, in this case MM uses them to modify other configs.

This is the relevant section covering what I think is the problem. Your KSP Assembly needs to have a reference to your Unity Assembly. Then your KSP Assembly can call any method and use any interface defined in the Unity Assembly. The reverse isn't true because you wouldn't be able to import your Unity Assembly into Unity if it had a reference to any KSP code.

Just add USDecouple to the MM file: @PART[*]:HAS[@MODULE[USDecouple]]:NEEDS[StageRecovery] { MODULE { name = RecoveryIDModule } }

KSP looks the way it does because it started life as a Unity 3 game from 2011 (here is a good version history video). And for the most part the game's looks haven't really changed that much. The earliest versions of the parts have been replaced, and lots of the effects (reentry, particle trails, etc...) have improved, but the basic look of the parts and the terrain remains mostly unchanged (the earliest terrain was pretty bad, but from about 2012 it has been about the same). The biggest updates in terms of visuals has been the space center and VAB/SPH interior (and UI, but that's a different matter). A lot of that comes down to the very basic shaders KSP uses. Unity provides far more advanced shaders that could improve the look of the parts significantly (don't let the ultra-shiny/reflective look of some of the Textures Unlimited parts fool you, the purpose of PBR is to provide a single workflow and shader that allows for materials that look the way they are supposed to look in all different lighting conditions). I don't expect KSP to ever use that as it would require a complete redo of all the parts. Another thing worth considering for people advocating a different engine is mod support. With Unity all you really need is for the game to load custom plugins and to provide some jumping off point to run code (like Part Modules, Scenario Modules, or KSPAddon). Once you have custom code running you can do a tremendous amount with modding. Games using custom engines, or more closed off engines, can be much more restrictive for modding. And even when they allow for it, it can be in a much more limited capacity, or require a whole lot more work to get going (unpacking game files in weird formats, use some uncommon/poorly document scripting system, require some kind of mod compilation to combine different mods, etc...). Using a different engine for physics is another matter, but I think that's a hard problem to get around.

What is it that those mods do with decouplers and what doesn't work correctly?

The part name? It will probably have to stay wrong since changing that internal name would break any existing crafts.

As far as I know that's how stock scanning data is saved. All SCANsat does is call the method: ResourceMap.Instance.UnlockPlanet(body.flightGlobalsIndex); The log file will only reflect this when the scan is actually done, this only occurs on scene load and when you change the scanning threshold. As the name for the setting implies, it disables basically everything to do with stock scanning from the parts themselves.

@Victor3 Scan data is stored in the save file. It's located in the top section (before the vessel list): SCENARIO { name = SCANcontroller scene = 7, 5, 8 ... } The data for each body is stored in Progress nodes: Progress { Body { Name = Kerbin Disabled = False MinHeightRange = -1500 MaxHeightRange = 6500 ClampHeight = 0 PaletteName = Default PaletteSize = 7 PaletteReverse = False PaletteDiscrete = False Map = CAABAAAA---... } } The actual data is a compressed string, so you won't really be able to make any sense of it. If a planet has no data at all then there simply won't be an entry for it. If the data has been wiped somehow then there could be an entry, but the data in the "Map" line should be something uniform, like a long list of AAAAAA. @Johould To add to the last post, the only way to find the scanning percentage for an individual scanner type is to go that vessel, open the small map, disable all scanners except the one you are interested in, then look at the percentage line under the map (displayed after the scanning status indicators: LO, HI,...). You can also collect science data if that is available. No science will be given at less than a 30% scan, and full science will be given for a 97.5% scan, but in between the amount will reflect the scanning percentage. This probably won't help if you've already collected the science, though. You can also just change the stock scanning threshold value to force a check, if the threshold is met and a stock scan is performed then a message will be written to the log file, "SCANsat resource scanning for <body name> meets threshold value [threshold%] Conducting stock orbital resource scan..."

@Wyzard That's fine, there is no interaction. @Brigadier All of the US science parts are mine (you can tell by the generally mediocre quality ), they just take the outer science bay section of the part from the empty US science bay wedge (the two part models get combined during loading). By themselves the US science parts would just sort of float in space and have hollow backs.

The two versions of US are completely separate. All of the parts are different and the installation folder is different. So you can install both at the same time and there shouldn't be problems. But if you install US 2 and delete US 1 then all of your existing vessels that use parts from that will be deleted.

Note that DMagic Orbital Science doesn't support this version of US yet. It will need to be updated with new versions of the US science parts before they can be used with this mod. Also, make sure to ping me if anyone runs into bugs, errors, or any questions about how the Universal Storage (they all start with US) part modules are setup in the configs.

Universal Storage 2 is out now. The Universal Storage science parts from DMagic Orbital Science do not support this version yet. All other science parts are unaffected. Only the original version of US is supported. New versions of all of the US parts from this mod will be needed to support the new version of Universal Storage.

@paranoider.ninja You can send the KSP.log file, found in the main KSP folder, next to the KSP.exe files. Upload to some file sharing site, don't try to paste the whole thing somewhere. I was going to link to the How To Get Support thread, but now realize all of its information is outdated and useless.

@paranoider.ninja There is no requirement to scan with the Narrow Band Scanner, they are two different things. What do you mean by its color on the big map? There is no scanning altitude indication on the big map. In the right click menu, after deploying the M700 you click Start Resource Scan, then there will be an indicator in that menu telling you if it is at the right altitude. If that doesn't happen then something else is wrong and I will need log files to say more. In the small map the indicators in the lower left will also indicate if it is at the correct altitude (grey means the scanner is off, orange means too high or too low, blinking green/orange means below the ideal altitude, solid green means at or above the ideal altitude).