DMagic

While tinkering around with the vessel unload ranges I stumbled on a way to force this for any part. It has to do with how and when the vessel is unloaded in flight. In previous versions there were, I think, two values (landed and not landed) for when vessels were loaded/unloaded and packed/unpacked. In 1.0 there is a new system that better handles vessels in different situations. Check out the VesselRanges class for more details. What is supposed to happen is that when a vessel is either landed or in space it will be packed first, then unloaded. In flight the vessel will be unloaded before being packed; if a vessel is packed or unloaded in flight below the cutoff level it will just disappear. What is most important is that the vessel unload range must be higher than the vessel load range: the standard unload range is 2500m and the standard load range is 2250m. If the ranges are the other way around it will try to load the vessel after it is unloaded and all sorts of weirdness ensues. Forcing these wrong values will trigger the continuously repeating, falling part syndrome (with sometimes hilarious results). As you can see, there is also a lot of debug spam being generated while this happens. I'm not sure if the stock launch clamp bug generates similar log spam as there is a baffling lack of log files available despite multiple threads and an official bug report, am I missing something or are people really this bad at reporting bugs... My guess is that something related to this is happening to launch clamps, causing them to not be unloaded properly. Some of the debug spam being generated is shown below, and the full output_log is here. [EXC 12:51:24.676] NullReferenceException: Object reference not set to an instance of an object Part.ModulesOnStart () Part+.MoveNext () Which is repeated while the part is unloaded but within the loading range. [EXC 12:52:29.777] NullReferenceException UnityEngine.Component.get_gameObject () Vessel.recurseCoMs (.Part part) Vessel.recurseCoMs (.Part part) Vessel.findLocalCenterOfMass () ProtoVessel..ctor (.Vessel VesselRef) Vessel.Unload () Vessel.Update () Which seems to be continuously repeated after flying out of loading range.

A few things are worth keeping in mind about the stock overlay. The overlay isn't very useful; it tells you if ore is present or not, but doesn't really help in finding a good spot beyond that. Biome surface scans don't make much of a difference in how accurate the overlay is. For some reason, the horizontal line and blob overlays use a lower quality map than the dot overlay; the difference can be significant. As DeMatt said, the cutoff percentage isn't the same as the actual ore concentration, it's a percentage of the maximum ore concentration on that planet (which I think comes from the resource config file). Fortunately, someone made what I think is a better version which can be found a few lines down.

Playing with SETI? It changes all of the goo and mat bay experiments to be not collectible.

Seeing your memory tests inspired me. I did some quick checking on my latest build. Most of the improvements are in how the small map is handled and how the scanning data for each planet is initialized. There are some other improvements to the overlay maps, but I don't think those should show up in this quick test. Without the one weird 14.1 outlier the difference is 15MB in both the Space Center and the flight scene. Hopefully I can find some other significant memory savings.

Make the dots arrows; they don't need to be big, just obvious. There is still the issue of properly setting up your orbit to match the target orbit, but that is a gameplay challenge, not a UI problem.

What do you mean the timer hasn't started running? The contract title updates in Contracts Window + every 5 or so seconds (no idea about the stock app), it only updates in CapCom on scene changes. Once the title says "orbit for x more days" instead of just "orbit for x days" the timer has started. Any vessel with the proper parts will be checked for the orbit requirements; multiple vessels can be used to fulfill the contract, and as long as one remain in orbit within the limits you can move other vessels in and out of orbit without resetting the timer. I'm not entirely sure what will happen if you attach the parts after the vessel is already in orbit, but if the sub-parameters are showing as complete then the vessel checks out.

The changes made for better performance in 14.1 have no impact on RAM usage. The background loading of the small terrain height maps is more or less a wash. Small maps are loaded for each planet once, then stored, but those same maps were already loaded at startup before, they were just empty. I do actually need to fix a few things related to this, there are several things that shouldn't be initialized when scanning data and maps are being loaded, but this is relatively minor. Maybe 5MB for the entire set of stock planets. The biggest RAM difference from v12 to v14 is the planetary overlay maps. These can swallow up a bit of RAM. I have already started working on fixing some of this, but some increase in RAM usage is unavoidable when generating big textures. The single biggest RAM user is the big map. It can be a very large texture (it can be re-sized up to Unity's limit, I think around 10k pixels wide), and caches its data. If you are switching planets a lot, or re-sizing the map a lot it will use lots of RAM, it should get dumped eventually, but it can still be a problem.

Portrait Stats 4.0 is out; get it on Kerbal Stuff. This version has a few additional features. A settings file is included which can be used to enable or disable tooltips that show when mousing over each icon (they are on by default). Tooltips for the trait icon give info about the trait effects at the current level. Tooltips for the stars icon give info about the Kerbal's career log and the current flight, the number is the experience value for that entry. This is basically the same information found in the astronaut complex. If the stars icon tooltip (expToolTip in the settings file) is disabled this icon won't be displayed in sandbox or science sandbox mode. Edit: Tooltip pictures:

My parts don't have anything to do with how data is stored in command modules, or IScienceDataContainers. This is the bug that I think you reported; an NRE triggered by collecting or resetting a part that stores multiple experiments while on EVA. Because it's been there for a very long time; I'm not sure if there is any difference, it seems to link to the same page.

Version 1.0.8 is out; get it or don't on Kerbal Stuff. It includes moderately less interesting science reports and a minor bug fix for parts that store multiple experiments.

So learn how. It's not that difficult. Most people make mods because they want them for themselves, not because somebody asks for it. Don't expect anyone to jump at your request unless they have some interest in the idea for themselves.

Thanks, I had a lot of fun making that laser animation, even if it is horribly complicated. Excellent pictures again. I'll need more details for this. Is this a magnetic field survey contract? Those are the only contracts of mine that ask for any kind of specific orbit. Possibly. I have in mind adding a lot of boring-looking, but interesting science experiments (most space instruments seem to consist of basically a box ). Most of my parts have been made with one of the primary requirements being that they look interesting in some way. A while back there was a [thread=120748]thread about overhauling how science collection works[/thread]. Agathorn hasn't been around for over a month, and the GitHub repo hasn't been updated in over two months. I've been mulling over ideas for this kind of science system overhaul since about the time I started on Orbital Science. I haven't contacted Agathorn yet, but a lot of what's included in RealScience is similar to ideas that I have had. I've been poking around in it a bit, and thinking about to how to implement a working version of it (the existing release works, but not in a practical way; only really as a demonstration). Agathorn has some ideas written down in the project's wiki about how science instruments and experiments might work, but I'm not sure how practical some of it will be to implement. Some of the ideas about combining science data from multiple instruments might work better as contracts (and the way they are described is very similar to how the contract system is setup) than as a separate thing. The system primarily changes how science is collected. Instead of the click once-per situation/biome, it allows for a great deal of customization in setting collection conditions. It also provides an interface for controlling everything, rather than right-click menus. Most of all, it should remove some of the tediousness of how science collection currently works. Instead of getting into orbit and clicking every time you move over a new biome (or when something like Science Alert tells you to) you can setup experiments to just gradually collect data while in orbit (up to a defined limit), or while in flight, or near an asteroid. You can set requirements for physical conditions like g-force, orbital parameters, velocity, etc..., and there are many other types that can easily be added. If Agathorn isn't going to continue development then I hope to be able to release a working version of it at some point.

I'm not really concerned about people trying to measure the impacts of mods; that just complicates things. It would be nice if people ran it without mods, but I'm not overly optimistic about getting that many people to actually run things on a clean install. That vessel is very stable though. It's a bit too slow to have any real problems. The planes are stable after detaching, too.

Just to check how things look in 1.0.4 vs 0.90 I reverted the vessel unload/unpack ranges to their 0.90 values and ran the test again. They are surprisingly bad in 1.0.4. Results are lower across the board. And that dip starting around 150s is caused by the aero effects, which weren't so easily triggered before 1.0.

This is your first time loading KSP after installing SCANsat? It seems that way and is normal, it's trying to load something that isn't there; it would probably be better to handle this without causing an error message (there are a handful of other harmless error messages that could probably be removed), but it doesn't matter much unless it continues. Does the error repeat on subsequent loads (it doesn't repeat after scene changes)? It shouldn't happen after you load KSP once and change scenes once.

Yeah, the physics range changes really screw things up. I don't have any plans to fix this version. But never fear, changing the unload range is easy (it will require a plugin, but that will allow for some other nice things, like a built in frame rate monitor, and maybe some limited autopilot to help reduce user differences) and work is under way...

It's a possibility. I can look into some other map projections. I've never really cared about the ideal orbit stuff and don't really understand any of Technogeeky's code for it anyway, so I don't spend much time worrying about it. Yep, that's a bug with updating the vessel for the instruments UI. Nope, but maybe there will be in a future update. This is something that's been on the to-do list forever, but I've never really gotten around to it. It would be nice if can be done quickly, maybe for the small map, but the big map might be trickier. They should show up, but you'll have to change scenes/reload before new waypoints are visible, it's a limitation of how waypoints are detected.

This should be helpful. I hate dealing with BBCode, so I'll have to try that out. For CurseForge, while it might not like raw markdown, it is perfectly happy with parsed markdown. Take the KerbalStuff mod description, the standard info screen, the one that anyone else sees, not the editing screen, copy everything, and paste it into the Curse addon description. It should come out correctly formatted. I'm not sure if it handles GitHub markdown, but it seems fine with standard markdown, I use that method for nearly all of my addons.

It's not a problem, it's working as intended in version 14. I'm assuming you aren't using SCANsat resource scanning (that the instant scan option is toggled on in the resource settings window), or that you also scanned with the narrow-band scanner. In version 14, the M700 (when used with SCANsat resource scanning) provides only a low-detail scan for all resources. The values on the map and in the info readout below are rounded to the nearest whole number (most of this info can be found on the GitHub docs). To get accurate results you need the narrow-band scanner for ore (and whatever mod resource scanner is required for other resources). With the instant scan option toggled on this doesn't matter, you just do the stock resource scan with the M700 and you get the SCANsat resource map. As for the low resolution of the map overlay, that is also intended. It provides roughly the same quality map as the SCANsat (and the stock) planetary overlay map. It works this way for several reasons: It preserves the stock resource scanning mechanic whereby the orbital scan is only one step of locating areas of high resource abundance. It also makes some sense for the SCANsat map to match what you see on the planetary overlay map. And, just as importantly, the lower quality resource map can be generated very quickly, it is created almost instantaneously at the beginning of a big map refresh. There is almost no difference in rendering time whether the resource overlay is on or off. Compare that with previous versions where the resource overlay would have a huge impact on map rendering time (the changes made in 14.1 would have little effect on this slow down). For more-or-less fully accurate resource abundance maps you can use the zoom map. If you don't want to fool around with narrow-band scanner requirements you can disable those in the resource settings window and use all resource overlays freely on the zoom map. One thing that I might change at some point is for the big map resource overlay quality to use the same quality settings as the planetary overlay. Right now it uses the default quality levels, those can be changed for the planetary overlays (I usually set the interpolation at 4 and the map height to 512, it's fast enough and I think much more useful), but those settings don't affect the big map overlays.

Apparently we might get a bigger, UV/Vis/IR version of Webb. You know, as long as someone wants to pay for it... http://arstechnica.com/science/2015/07/whats-after-webb-maybe-a-12-meter-space-telescope/ http://www.hdstvision.org/

Somewhere a Unity dev is maniacally laughing at this. The "answer" is that the legacy Unity UI really isn't meant for rendering things in-game, it's more suited for pause menus and things like that which aren't displayed all of the time. There are a few elements of the UI that can really bog things down if not handled carefully. For one, every single UI element, each button, label, slider bar, text box, etc... produces multiple draw calls to the GPU. And depending on how careful you are, all of these elements are being drawn whether or not you can see them. Take a scroll window with 100 elements that only shows 10 at a time. This will still render all 100 of those elements, even though most aren't visible. A few windows with elements like that can slow things to a crawl. Another is that the system just lends itself to careless creation of new objects rather than reusing old ones. For instance, when the big map for SCANsat is drawing it takes one of the main texture and determines the color for each pixel, it stores these colors in a single array. It used to create and destroy this color array one every GUI frame, so you would have something that is potentially several kb (for a 1000 pixel wide map, that's a 1000 element color array, with each element using 16 bytes, that comes out to 16kb) being created and destroyed several hundred times whenever you refresh the map. I fixed that, and several other similar objects, so that it just initializes the array once then reuses it. Now just imagine a dozen other UI windows doing something similar on every GUI frame and it's easy to see where the waste comes from. The new UI uses separate Unity game objects for each element, which just lends itself to better object handling than the old system (though it's obviously still possible to be careless and wasteful).

What are using to convert textures? The only reliable method I've found is using Nvidia's texture tools through Photoshop. Everything else seems to ruin small textures, give compression artifacts in some cases, and for some reason breaks the small agency flag textures.

Version 5.3 is out; get it on Kerbal Stuff. It improves the mission selection/creator window; it can now be accessed from any mission list, not just the master list. A checkmark icon indicates which mission the current contract is already added to, and the red x box can be used to remove the contract from that mission. There are also a few minor performance improvements. Existing contract and mission list status will not be reset by this update, since no changes were made to the loading or storing of contract/missions states.

That's something that I don't think a lot of people consider. The most popular mods generate something like 30-50k downloads for any given version (the total download count is a more a reflection of how many versions of an addon exist, rather than just popularity), and how many of those downloaders actually use the addon is a different question. Given the numbers for KSP sales that have been thrown around this suggests that mods aren't nearly as popular as forum users like to think. So having a relatively user-friendly version of a popular addon incorporated into the stock game is a good thing. Complaining that it doesn't provide all of the features of a given addon, or isn't hard enough doesn't make much sense to me. Just continue using addons if you want those features.

A significant amount of it is probably coming from the UI. Without careful consideration of what your UI is using you can end up with lots of objects being created for every GUI frame. This is one of the things that I've been continually looking at in my addons because it's such an issue. It's one of those things that is totally independent of what else is going, how big your craft is, how many active vessels you have, etc..., it just always runs. But, of course, there are probably numerous instances of objects getting created and dumped while the universe continually updates.