DMagic

Is this GUI stuff? Is it being run in OnGUI?

@NathanKell It's actually only used by Contracts Window +. I need a method that only prints two time values; years and days, days and hours, or hours and minutes. I think printtimedeltacompact does something similar, but not quite the same. Contracts Window + has very tight space constraints, so there isn't room for more than two values. There is a simple work around to ensure that I'm always using the stock formatter. But really, if those methods aren't included in the interface they should be moved back into KSPUtil.

@rsparkyc That's a known issue. @Svm420 From what I can tell that is caused by RSS Time Formatter. It doesn't seem to implement the three public GetTimeFromUT used by the default time formatter. I'm not sure why those methods aren't included as interface methods, but if someone is trying to tap into the date formatter and uses those methods then it will break things. I could probably fix Contract Parser so that it won't use that method, I'll have to look into it.

@pap1723 I plan on adding a KSPedia entry for this at some point. A similar table would make for a good page or two. @KocLobster Really? That shouldn't be happening. Do you have any other mods that change biome situations?

@the Monkeys Uncle Log files would help. As long as the parts are there, the buttons are there, and the maps work I can't see any reason why the scanners wouldn't deploy.

They haven't said anything definite about the next update, but I'm guessing we'll hear something in the next few weeks. The things that have been discussed so far are the rocket part overhaul and the satellite relay system. Several dev notes have mentioned PorkJet already working on the parts overhaul. I'm hoping this means both new models/textures, and a rebalance of mass, cost, and maybe tech tree position. The relay system was supposed to be in 1.1, but, as far as I understand, in depth testing of the system required a stable base, which clearly didn't exist. So real Q&A testing of the relay system would have had to wait until everything else was done (basically until the game was at the point it's at now), which would have meant more delays. The only other thing I'm expecting to be in 1.2 is Unity 5.4. It's in beta now and is supposed to released in June, so it makes sense that they would upgrade to that. Supposedly, many of the wheel and landing gear issues are the result of Unity bugs, and Unity 5.3 has other issues, so until 5.4 is out we're stuck with work-arounds likes we have now.

@MisterFister Yep, it's a dependency of Contracts Window + and CapCom; it doesn't do anything on the user side by itself.

I've never been a fan of all the nonsense required to dock things together on the surface; all of it is just a kludge to get around the lack of any kind of flexible docking port. So: Not going to work right? Much better. I still need to get the rotating part working, so that it can dock when you aren't coming in perfectly straight, but otherwise it looks good.

I don't think the Steam controller is really a good analogue for a console controller. For one, using the Steam controller's touchpad as a mouse stand-in is nothing like using a regular controller stick; the latter is generally terrible. With the Steam controller setup as a touchball it actually works pretty well. It also has the mode-switching paddle buttons on the back that are currently used for actions groups and some other controls during flight.

Version 0.14 is out; get it on GitHub. It is updated for KSP 1.1.2 (v0.13 should still work fine though) and includes a new API for external mod compatibility.

I'm not sure if you can get an animation's time when it isn't playing. If you want to change the speed or direction of an animation without worrying about it starting over, you can check if it's playing; if it is then only change the speed, if it isn't then set the time, too. You could also try setting the wrapmode to clamp forever, then it will keep playing the last frame over and over, and since it is still playing you should be able to get the time.

Both docking ports keep a reference to the matching node; otherNode. You can watch the status of both docking ports to decide when they are engaged and when they are actually docked.

When the module is within the acquisition range and is the dominant port the state will be "Acquire". But the other port (not necessarily on the other vessel) will be "Docked (dockee)", even though it hasn't docked yet; the inactive port also won't have its magnets engaged. The active port switches to "Docked (docker)" once you dock. When you undock, and haven't passed the reengage distance, it will be "Disengage", I think. When the docking port isn't doing anything it will be "Ready"; if it's a shielded port I thing it might be "Disabled".

@KocLobster I think TweakScale may have made a few changes. The next update will include the new science module feature, which makes smaller experiments more expensive. I'll also check on the fixed size scale modules used for the telescopes. @gamerscircle If you remove the OversizeScience folder you won't get any of the recon contracts. It checks for the existence of the required parts (which you can edit in the DMContracts.cfg file) before offering anything.

In other news, I found a sweet new color palette to use for Moho: Taken from the new Mercury maps from the USGS: I need two more color palettes now (they arranged in rows of three and now I have 10), if anyone has any ideas.

@nightingale What does the config consist of? The SIGINT scan and the two spy telescopes use only two biomes, northern and southern hemisphere (too much science and too many science results for full biomes ), and they work as InSpaceLow from 5X the normal altitude.

I dug out the code I was using and made some screenshots: This shows rescaling the visual map at several different resolutions and the affect of the bump map. On the left is with the bump map on, you can see that even at very low resolution visual textures there is still a lot of detail. About mip maps, that's a good idea, but I have no idea how to actually access mip map layers. The Texture classes don't seem to have anything related to manually activating a certain layer. This was all done using TextureScale, a Unity addon that Squad includes with KSP. I also added an example using the resource overlay map (don't ask why it's so white...), you can see the effect of the bump map and how both sides are fully lit.

Let me know if anyone runs into problems with the surface sampler, on the ground or on asteroids.

@Enceos Yes, but any map that you see in the map view or tracking station is using the scaled space renderer. There are generally three textures that might be applied here, the visible map, the bump map, and the resource map (which doesn't respect light sources). All of these are what you see when you look at a planet from flight view in a higher orbit. There is a fade in altitude for each planet where what you see switches from scaled space to PQS. Below that altitude, anything that you do to the scaled space textures won't have any effect.

Overwriting the CRP definitions would seem to defeat the purpose of CRP entirely, and would probably ensure that this remains marked as incompatible with CRP on CKAN. I wouldn't let save-breaking changes stop you from making fixes that should be made; that's the price you pay for supporting mod development.

@Enceos This isn't really a problem. At most orbital altitudes you are looking at the scaled space map of a planet, the same as what is shown in the map view. This is why you can see resource overlays in the flight view. At a certain altitude the PQS terrain starts to fade in and the scaled space map fades out. So anything in a very low orbit, or going in for a landing, would see the full terrain, but most vessels in orbit would only see the scaled space.

@Poodmund @jandcando and anyone else who is making KSPedia entries and who wasn't already pinged about this: I added a big red warning to the first post about making sure you don't have squadcore listed as a dependency in your asset project. If you use any files from the SquadCore asset bundle that was included with the Part Tools (this should be in your Unity Assets folder under SquadCore) then it will be listed as a dependency and will break KSP's asset loader when more than two such entries are installed. If you want to use background images from the SquadCore folder you should first copy them to a different location within the Unity Assets folder, and manually import them (using the same method as described above; use 2D sprites and disable Mip Maps). To check if squadcore is listed as a dependency you can go to the Unity Assets/XML folder and look for your *_kspedia.xml file (the prefix will be your asset bundle name). Open the file and look at the last section, if you see this line you will have problems: <Dependencies> <Dependency>squadcore</Dependency> </Dependencies> There should be nothing between the <Dependencies> brackets. Go back and make sure you aren't using any images or other files from the SquadCore folder.

@Mechtech If you look in the VAB info box there is a section on the ideal ranges and angles between seismic pods. These values can be changed in the DMSeismicSettings.cfg file in the Resources folder. Basically how it works is this: The hammer by itself will get only 40% of the total science available. A pod by itself will get only 20%. When you have the hammer and seismic pods you have to separate them from the same vessel (except for asteroids, where you will get 100% as long as you have the hammer and one pod on the same vessel). A minimum distance of 10m from the seismic hammer's vessel is required for a pod to be counted (make sure that the pod is turned on, this will happen automatically when decoupling). For each pod more than 10m away from the vessel you will get an additional 10% science, up to 20%. To get the max science you will need two seismic pods; one somewhere in the ideal "near" distance (500-2500m), which can usually be accomplished with the decoupler. And another in the ideal "far" distance (4 - 15km), which in most cases will require some other means of deployment. Anything below the ideal distances (10-500m and 2.5-4km) will give you less than full amount on a sliding scale. The two pods will also need to be placed at different angles in relation to where the seismic hammer is. Anything less than 20o won't count, anything above 90o will give the full amount, with a sliding scale between. Also, if you put down more that 5 pods you should get 100% science regardless of the distance and positioning (though I think they all have to be at least 10m away). This is something that I really want to put into a KSPedia entry, along with information about all of the other non-standard experiments.

@Poodmund Are you assigning the images to the Panel's background image, or to a separate Image UI object? I'm not sure if it makes any difference. Are all of the pages similar to what you posted in the OPM thread? What you can do is make a skybox image to use as the background, then cut out the planet images and leave the rest of the space transparent. If you have Texture Replacer you could try replacing the sky box with a flat black (or maybe green) texture. That would make it easier to crop out the background from the planet images, though it's not really that hard to remove the background from spherical planets using the regular skybox. That way the Asset Compiler would presumably be able to save space by only linking to the background once.

Yeah. Making the skybox the background image and leaving most of the main image blank would probably cut down on size a lot. It seems like there is either something wrong with how I am generating KSPedia asset bundles, or a bug with the asset loader, because any time three or more additional KSPedia entries are installed it breaks the system. So... I guess maybe we shouldn't make KSPedia entries. At least until someone can figure out if there is a way around this problem.