DMagic

No idea, haven't tried it yet. Probably not though...

Contract Reward Modifier 2.7 is out; get it on Space Dock. It has been updated to support KSP 1.8. .This has always been intentional so that the config file is visible to Module Manager. It also does not get written to all that much, it isn't storing things like window position, or activation status.

Contracts Window + version 9.4 is out; get it on Space Dock. It has been update to support KSP 1.8. Its dependencies Progress Parser and Contract Parser have also been updated and are included in the download package.

CapCom version 2.11 is out; get it on Space Dock. It has been update to support KSP 1.8. Its dependencies Progress Parser and Contract Parser have also been updated and are included in the download package.

Tracking Station Evolved version 5.0 is out; get it on Space Dock. It has been updated for KSP 1.8 and should be working fine now.

Basic Orbit version 9.0 is out; get it on Space Dock. It is updated for KSP 1.8. Basic DeltaV still needs more testing before it is ready.

I've updated most of these mods for KSP 1.8. Links can be found in the first post. Flexible Docking, and One Window have been rebuilt for KSP 1.8 and the Unity update. EVA Struts, EVA Transfer have been rebuilt and whitelist the stock strut and fuel line parts for Restock support. KerbNet Controller and Celestial Body Science Editor have been rebuilt and their in game settings menu page has been changed. Instead of being under one "folder" - "DMagic Mods" - they are under their own folder, as too many mods under the same folder could cause problems. These all seem to be working okay, though they weren't tested extensively. Let me know if there are any problems. The mods not listed here haven't been updated. Portrait Stats and Science Relay need more fixing. And I haven't gotten around to testing Making Less History. @horngeek It should work, but it won't be able to detect Remote Tech connections. You'll just be able to transfer science to any vessel with a container available. But not in KSP 1.8, because it doesn't work at all in 1.8...

Version 18.14 is out; get it on Space Dock. As mentioned above, this is a minor update to support KSP 1.8. It fixes the issue with the map control buttons, and fixes the shaders for the ground track display and the BTDT anomaly viewer display. It hasn't been extensively tested, but everything seems to be working okay in KSP 1.8. KSPedia has not been fixed for this release. It also has not been tested with RPM, so that probably doesn't work, either. A bigger update is in the works and will start to come out soon (after all of my other mods are updated - finished recompiling all of them, now just need to test them...), probably after we get the inevitable KSP 1.8.1. It will have some preview releases to make sure save data is all transferring correctly and maybe to work out some balance issues.

@Nils277 Thanks for that. I was running into the same problem but decided to push it off until I sorted my other mods. It would be nice if they could try to push all of the TMP stuff into a separate plugin so that we wouldn't have to deal with this nonsense.

No. DOTS and the ECS system would require a complete rewrite of how KSP works. Combining DOTS coding with standard Unity Game Objects is very tricky, the primary issue for KSP is that anything running on DOTS would be using either Havoc physics or Unity DOTS physics, which exist in different worlds from PhysX, so anything physics related would need to be on the same system (or require some really hacky workarounds). The coding itself is also entirely different, anyone familiar with standard Unity coding would have to learn a lot to use DOTS effectively. And, for now, there is the much bigger problem of DOTS not being anywhere near production ready. Things like animation and sound don't work with it. The coding syntax has been changing drastically between Unity updates. So nothing like KSP (or KSP2) would be released using such a system. And in any event, I don't think any of this gets around the basic problem with KSP, that vessels are constructed as a single chain of rigid bodies that can't be considered in isolation. That has nothing to do with Unity or PhysX, that is a design decision on the part of the KSP developers. DOTS isn't going to fix that.

Demanding updates wouldn't be helpful. But pointing out the errors with a new KSP release is helpful, though I already knew about them, in this case. I'll probably release a quick update to fix the errors, it seems like a simple recompile of the mod should be enough. For KSPedia I'll probably hold off, since a much more significant update is in the works, and it will required some new entries for KSPedia. On that note, do a lot of people who use SCANsat for resource scanning, and who use resource mods, only use the stock Narrow Band Scanner for all high resolution resource scans? Or do people use different scanners for different resources (ie one scanner for water, another for dirt, another for metal ore, etc...)? The MM patches that are included with SCANsat only add resource scanning functions to the stock parts, but other mods might be different (I know that DMagic Orbital Science includes some of these individual scanners, but the others that I know of just use the stock scanner). It would be much simpler, and have some performance improvements and reduce the amount of storage space used by SCANsat maps in the save file, if I could collapse all high resolution resources into a single scan type. Also, the number of scan types is limited and there are now tons of resources used by other mods.

Is there something about the 1.8 Part Tools that is preventing it from loading the KSPAssetCompiler.dll? I keep running into this error: Error: Could not load signature of KSPFontAsset:.ctor due to: Could not load file or assembly 'TextMeshPro-2017.1-1.0.56-Runtime, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. assembly:TextMeshPro-2017.1-1.0.56-Runtime, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) signature:<none> This is on a new project, with Unity 2019.2.2f1, and the newest version of Part Tools from here. It seems like it's running into a problem trying to read from the old version of the TextmeshPro plugin. I also tried removing the built in TMPro package, but that has no effect. This prevents the KSPedia functions from working in the Unity editor, and would prevent anyone from using the KSP asset bundler function.

It sort of works OK in 1.8, but will definitely need an update.

Is there some particular problem with Unity that you think makes it unsuitable for KSP (preferably something specific, not just the same vague issues everyone tries to point out)? Is there some alternative game engine that you think would work better?

@RedDragon91GoW Those dependencies should work fine in KSP 1.7, their version file just hasn't been updated to indicate as such.

Will there be any tools for porting part mods from KSP1 to KSP2? How will new part mods be handled? A new version of Part Tools, or something along the same lines? Are they using PBR for their shaders (based on some of the preview footage the answer seems to be yes)? Will they provide anything to help convert existing part mod textures for use in PBR shaders?

Contracts Window 9.3 is out; get it on Space Dock. This update includes French translations by don-vip. It also fixes a few bugs related to the mission list popup windows not accommodating more than 4 or 5 missions. It also fixes some weird behavior when you apply the stock game settings while Contracts Window + is closed, along with behaving better when switching between the two different UI styles.

SCANsat version 18.13 is out; get it on Space Dock. This update fixes some more errors related to Breaking Ground surface feature detection, particularly when running in Sandbox mode.

@hraban Is this in Sandbox mode? I think there might be an issue where it checks to see if the surface features have been scanned with the robot science arms.

SCANsat version 18.12 is out; get it on Space Dock. It fixes some bugs related to the Breaking Ground surface features and the zoom map auto refresh. It also adds the option to customize the color of the ground track indicators based on scanner type. The basic SCANsat types (low and high resolution altimetry, biome, anomaly, and the low resolution resources) are all defined in the settings file found in the SCANsat/PluginData folder. The other resource types can be defined in the SCANResource.cfg file found in SCANsat/Resources. The default color is used for all resources now, to change it you would need to add a 'color' field to a certain resource: SCANSAT_SENSOR { name = Ore SCANtype = 256 //2^8 color = 128,200,200,104 } All of the colors are in RGBA, 0-255 format. Colors are combined when a vessel has multiple different scanner types.

I like both of these ideas and am adding them to the GitHub tracker so I won't forget them. They should both be doable, just probably not right now. There are options for biome colors in the settings window. You can switch to use the stock color palettes, which are sometimes easier to read. Like a "here be dragons" type of map? That would be kind of neat. It would require loading a fairly large size texture. An option to change the background color would be simpler, maybe with some way to add a vignette style border. I'll add this to the tracker, too. Resources are always overlayed over other maps, there is no resource-only map. To turn off the resource overlay just toggle the resource icon on the left of the big map or the bottom of the big map. Not really, as there is the Zoom map for that purpose. The performance hit when rebuilding the big map is just how it works. It has to query KSP's PQS terrain system to get the actual terrain height at each position on the map, which is very slow. This data is cached, so that when you rebuild the map it should be much faster. Changing the map size, or changing to a new celestial body map resets the cache (storing the data for each planet would require way too much memory). Running it on a different thread isn't really an option, since it is working through Unity components, which don't play well with threading and tend to have unpredictable errors (threading is used in SCANsat when possible, generally for math-heavy operations involving map interpolation; the resource overlay, for instance, is mostly generated in a separate thread). You can change the map refresh speed in the settings window, it will adjust how many rows of the map are generated per frame, which can alleviate some of the performance impact.

@Atlas Gaming Do you have any mods running that affect the CommNet system? There are a few out there, CommNet Constellation is one, I think there are a few others. They have been known to interact badly with Science Relay in ways that hard to replicate and very strange. You can try turning off the connection requirement for Science Relay, so that you will basically be able to send science results to any active vessel. But there isn't much else to do about it.

@Dizor This is when running KSP with the Unity Debugger? I don't think that has any effect when running KSP normally, it's just something that Unity complains about. Something similar has been brought to my attention for some of my other mods and it never caused any issues (though I can't remember if I fixed them to avoid the warning or not ).

I think GPU Instancing is a DX11 thing, not really a Unity version thing. Of course, Unity 2018 drops support for DX9, which would force DX11, so it's sort of a semantic difference. Even so, it might take some effort to make the terrain work with GPU Instancing, as it isn't nearly as straightforward as simple duplicate-mesh-GPU instancing. In any event, GPU Instancing would really have a CPU-side effect, as it reduces draw calls (which would be great, as KSP's terrain generates a huge number of draw calls). Shader complexity would have a GPU-side impact.

High resolution textures are generally an either/or thing in terms of performance. Either your video card has enough vRAM to handle them and it makes little difference to performance, or it doesn't have enough vRAM and performance falls off a cliff.