Jump to content

Wheffle

Members
  • Content Count

    263
  • Joined

  • Last visited

Everything posted by Wheffle

  1. @maculator The biome map is actually the same one you can access from the cheat menu. I don't know if the colors are associated with biomes anywhere in the system. I might look into it when I get to working on this mod again. Unfortunately sometimes having the biome map up on a not fully scanned planet can cause some narley lag in some cases, it's not always easy to predict when. I've resorted to using some pretty hack-ish methods to intercept KSP's overlay textures and modify them before they get deployed, and unfortunately ever since they cleaned up the biome map to give it more re
  2. This mod has never had any role to play with SCANsat whatsoever. They are generally mutually exclusive, and I'm not entirely sure what happens when you install both (it might not crash or anything, just be broken/weird/confusing/whatever). Some reasons to use SCANsat: You want maps besides the planet overlays that are interactive and allow you to place waypoints, you want different types of scanners for altitude maps, biome maps, resources, etc., you (possibly) want to skip the narrow band scanner or ground-truthing phases of resource scouting, and you generally crave more complexity and
  3. Pushed out an update Spacedock | Curse Mostly deals with the issues that have been brought to my attention that occur when you use OSP with RSS or other alternate solar system mods that scale planet sizes up. OSP will now take a look at the solar system and scale the data grids to stay at sane sizes so memory and save/load times won't skyrocket. Thanks @ZobrAA and @MusicMetalHead for the help! Most users won't be affected by the big changes, but everyone should enjoy a few optimizations and other small changes. Might have to wait a bit for curse to "approve" the file upload
  4. Yes. OSP isn't intended to be ultra realistic, just a step-up from stock. I figure die-hards have SCANsat.
  5. You can tweak the scan radius in the config files. GameData > OrbitalSurveyPlus > Patches > OrbitalSurveyPlus.cfg > ScanRadius = [whatever you want] Default is 8, so try shrinking it to get a value you like.
  6. If Kerbin is still the home world, its grid (and the scanner's radius) should look exactly the same as in stock. Since the Mun is smaller relative to Kerbin that picture makes sense. Kerbin's grid does look a bit small though, might need to do a bit more fiddling. Thank you for the feedback!
  7. Those scan cones do look a bit big. If the patch is working correctly scaling should be based off the home planet. If bodies are much smaller than the home planet then the grid will be a lot smaller, causing a larger scan cone, and the opposite is true. Are the pictures you are showing from stock or has the solar system been altered?
  8. @ZobrAA @MusicMetalHead I cooked up a quick dev patch that looks like it solves the issue. If y'all want to try it out and let me know if it helps, get it at this link: OSP 2.3.2 - dev 2 - patch for RSS You should either start a new save or use it on a save where no scanning has been done. If neither of those options appeal to you and you want to do it the hard way, you'll have to go into the persistence file and delete everything inside the "OSPScanData" node of the OSP Scenario section. Example Screenshot I'll continue testing and will release a full update hopefully
  9. Haha. You can start a sandbox save and cheat your way up if you need to. I'll be doing some tests of my own though if you can't get around to it.
  10. Well, the path isn't exactly "straight". When you project the path onto a 2D map, it is quite curvy (unless you are exactly equatorial). I can take another look at the code for retroactive scans, but to make sure can you see if you get the same problem when you turn retroactive scanning off in the options? The massive data grids getting created and put into memory as a result of RSS could be causing a memory-based crash as well.
  11. Ah, I see what you are saying. I thought you meant revealing one orbital strip at a time. Well, that *is* an option to cut down on memory and CPU, but I'd rather keep the dynamic scanning that we have right now. I suppose I can add it as an option for lower-end systems or RSS users. It can be a fallback if I can't come up with a good solution otherwise.
  12. I might look i to alternative methods like the one you described, but at first glance it seems a bit more complicated. The planet is rotating as the scanner orbits, so it won't be a simple belt. This is why high inclination orbits will eventually scan all/most of a planet even without switching inclinations.
  13. Yes, that setting helps to cut down on having 99% planets scanned hanging around. Any planet with 100% scan will stop taking up save space.
  14. Yeah, it might not be jiving well with RSS. I'll be looking into it this weekend.
  15. It actually should be doing something like that already. Does it not appear to be doing so? Are you getting lag even though all planets are either 0% or 100% scanned?
  16. Yes, the autosave will build the save node tree from scratch every time. It's just the way KSP is built. I will try to come up with a solution soon, maybe just by adding an option to scale the data grid for users with RSS. Thank you for reporting the problem!
  17. Well shoot. Let's see if we can figure this out. At first glance I suspect it might be RSS. Planet data grids are based on their size, so having much larger planets could inflate the data to ridiculous levels. @ZobrAA are you using any mods that make planets bigger? @MusicMetalHead have you scanned any planets in RSS yet? Did the problem by chance start during your RSS playthrough? If this is the case I'll try to get an update out that will scale down data size for RSS users.
  18. Hmm... I haven't thought about adding contracts. I might take a look.
  19. If you check out some of the images they have in the imgur album they have linked, they obscure the surface and it you slowly get more detail the more you research it. You're right, though, it's not exactly the same thing as what I was thinking about implementing. I'll continue looking into it.
  20. @Jarin It looks like the mod ResearchBodies has already implemented something very similar, so I'm not sure it's worth overlapping in that territory. I might do something a little bit different using planet overlays to mask detail instead. I'm not exactly sure yet.
  21. Unfortunately it might have been one of those "it's working, don't touch it!" moments. Thanks for the heads up, I'll take a look. Edit Yeah, it's coming back to me after taking a look. The experiment definition doesn't exist because the stock survey system doesn't use an experiment definition either, it's just a transmission that is thrown out there and caught by the callback. Yes, it's very strange Squad did it this way, and it probably would be cool to set up proper experiments for my add-on, but it is what it is. Currently I'm using the ScienceData subject to identify
  22. When I dug into it I found this to be odd as well. It seems to circumvent the science system altogether and save its state only in a separate scenario (ResourceScenario). Unfortunately I hacked OSP to do what I figured the stock system was doing anyway, probably very clumsily at that.
  23. If you want a deeper and more detailed scanning experience with different types of maps (like altitude maps and such), SCANsat will probably interest you. It adds a lot of stuff to KSP that simply wasn't there before and provides you with a lot of cool projections and different types of scanners. There are a lot of options available to keep the stock resource surveying in place while using SCANsat or let SCANsat replace it with its own system, to varying degrees. My goal for OSP was to simply augment the stock resource system. If you generally are satisfied with the stock system except fo
  24. Yeah, had to coax them out. They should be there now.
  25. @curiousepic @Enceos After a billion years I have started poking around with unexplored planet blur. Not sure if anyone is still interested, but there you have it. I've managed to find the normal and bump map textures for planets and set a 'mipMapBias' Unity setting to a large number, presumably causing Unity to choose a smaller mipmap even at close camera ranges. Here are some comparison examples: Moho: Eve: Duna: Dres: Gilly: As you can see, the results are mixed and sometimes kind of weird. It looks like planets
×
×
  • Create New...