• Content count

  • Joined

  • Last visited

Community Reputation

2594 Excellent

Recent Profile Visitors

7458 profile views
  1. @Cetera SCANsat loads and unloads bodies once per game session when it's building its initial database. Each body takes about 10 seconds to load, so loading all of the planets can take some time (the loading is slow enough that it shouldn't have any effect). When Kopernicus is installed it has to force each body to load before it can read that body's terrain data, after it finishes it unloads the body. From the logs that's what seems to be happening, each Kopernicus unload message is followed a by a "Height map complete" message. After the database is built the only time SCANsat should force a body to load is if you open the big map and display a planet different from the current body. This block looks like it occurs in the SpaceCenter scene, nothing else seems to be going on, because processing this many planets would take a while: Another block from the flight scene I think: As long as this doesn't continue happening it is working as it should. The performance effect of this processing should be considerably less than 1/10th of what is required to build a reasonably sized SCANsat big map. So if you can use the other SCANsat functions then this is unlikely to be causing such a serious drop.
  2. @ioresult There are a few bugs with the SIGINT and soil moisture antennas in the current version. I'll update with fixes (and the ability to turn off the transmitter function) whenever 1.3 is released.
  3. @Aelfhe1m The differences in labels are intended since the zoom map has the potential to be much smaller and there are certain circumstances where the text might run over. The Orbital Science anomaly scanner doesn't work with the ground stations since they are technically not the same thing as the regular anomalies. It will need to be updated to fix that.
  4. @msnbcorp I'm not seeing the RT error in that log. The only thing of note I see is that you might have 2 copies of the Kopernicus.OnDemand plugin in your GameData/Kopernicus/plugins folder. That seems like it might be a bad thing, and the Kopernicus on demand loader is the only point where SCANsat and RT might overlap, since SCANsat forces planets to be loaded at certain points, and unloads them when it's finished. @tomf That might be a CC problem. @Dewar I'll see about adding those 2 resources for the next update.
  5. @davidpsummers It would appear that you don't have the EVA Transfer plugin in your KSP/GameData/EVATransfer folder. If you don't have the plugin it won't work, delete it and reinstall, making sure that the EVATransfer.dll file is present.
  6. @psamathe See the KSPedia entry or the SCANsat wiki (both are a little out of date, but are mostly still accurate). That is expected behavior dependent on your resource scan settings.
  7. @Yargnit Modifying them to make the base point movable might be possible, so that you could re-position either end. But allowing for the strut (or fuel pipe) start point to be placed on EVA is way outside the scope of this mod. I don't want to get into spawning new parts, setting joints, etc... And it would require some kind of inventory system, no matter how simple, otherwise you would just be able to infinitely place new struts. Both mods are compatible with KIS, so they can be placed on EVA using that. @davidpsummers It looks like some kind of bug when the fuel pipe is first initialized or clicked on. I can't say any more without seeing the full log files.
  8. I think the simplest solution, for now, would be to distribute your mod with all of the translated KSPedia assetbundles (with the language as a suffix on the file name), but only put the .ksp file extension on the primary language. Then you can instruct users to change the file extension if they want a different language. It's not ideal, but then I imagine there won't be more than a handful of mods that actually go to the trouble of making KSPedia translations. KSP's asset loader will ignore bundles without a file extension, so the others will just be ignored.
  9. @Gordon Dry The Toolbar error looks like the least of your problems (that error is common when something with a UI is displayed immediately upon a scene change; if it only happens once it is harmless). Your log file is absolutely filled with errors from Real Fuels, Tweak Scale, and RPM. It's possible that another maneuver editing mod might conflict with this, I'll have to check.
  10. @Voodoo8648 The change log is in the first post. It is very long.
  11. @Morse I think you just need to make different KSPedia entries for each language. They would probably have to be offered as a different or separate download package to avoid having all languages show up.
  12. The folders outside of the KSP/GameData folder (these are Kerbal Space Program/Parts, /Internals, etc..., they are all empty for a reason) are obsolete and no new mods should be placed in them. For some reason they have been left in place from the time, several years ago, when they were actually used. But they should never be used for mods today (if you can find a 3 year old mod that still works on the current version of KSP I would love to see it). Many mods are absolutely dependent on specific files being in specific locations, moving folders around is guaranteed to break those mods. Anecdotal evidence to the contrary doesn't mean anything other than that you have found a few mods that don't break when their folders or moved, or that some of them are broken, but you just aren't aware of it. Also, anyone looking for KSP mods would be better off searching through SpaceDock, it has considerably more mods, and more of them are up to date (SpaceDock only started about 1 year ago, so basically anything there is compatible with KSP 1.0 - 1.2.2, whereas Curse has had more time to acquire dead mods).
  13. One of the much alluded to changes has taken place in the Localization methods. The Class name has been changed from Localization to Localizer. So if you have been doing any pre-release work just do a find a replace for Localization.Format to Localizer.Format and it should work fine. There has a also been a bug fix to avoid NRE's if you do something silly like passing a null string into the Format method.
  14. But does it only happen when run immediately on x86? If you wait until Start, or the Main Menu does it work? If so then there is probably just some slight difference in the time it takes to load in some necessary asset (maybe the TMP Font Asset, I think that's one of the first things that gets loaded).
  15. If the problem only shows up when run immediately then it's probably just that some required assets haven't been loaded yet.