Wheffle
-
Posts
266 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Wheffle
-
-
I see it on the bar on the right side of your screenshot. The little satellite icon over the colored globe:
Edit:
Just thought of this, not sure if this is it but I figured I'd say this just in case. You might have gotten the ore map and the biome map confused. The button shown above is the biome map. To get the ore/resource overlay, you use the same button you use for stock. To get that button to appear, you have to focus the camera on the planet first, and then the button with the icon of a globe with a slice cut out of it will appear. OSP integrates with the stock system so it uses the same button.
-
New Update
I finally found time to track down and fix the slowdown that happens often when you have an overlay up for a planet. Hopefully it's fixed, at least mostly. Quick test results were good. Let me know if there are anymore problems.
Important Note:
Seeing as how KSP 1.3 just came out and a lot of mods aren't compatible yet, I actually deployed two updates. The first update fixes the slowdown issue and stays compatible with KSP 1.2. The second update is the same update but is compatible with KSP 1.3. If most of your mods are still on KSP 1.2, stick with the first update for now to still get the benefits of the patch and move on to the latest one later.
Quick Link for latest version compatible with KSP 1.2
Orbital Survey Plus 2.3.3 - Fixes the slowdown issue and stays compatible with KSP 1.2
Orbital Survey Plus 2.3.4 - Fixes the slowdown issue and is compatible with KSP 1.3
As always, let me know if there are any problems or questions.
-
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 resolution it has gained the potential to hog resources, again only sometimes. Fortunately this isn't a problem for the ore overlay. It's something I will address when I have time to work on OSP after finals, I sincerely apologize for it.
Edit: In the meantime, if the biome map lag is consistently wrecking your framerate, you can uncheck the "biome map requires scan" option which will alleviate the lag. Of course this means that, well, the biome map doesn't require scanning, so that kind of sucks, but the ore map still will.
-
51 minutes ago, Calvin_Maclure said:
Quick question: what sort of interaction with SCANSat will this mod have? I had this mod with KSP 1.1.2 but Im just wondering if with the changes applied to SCANSat for KSP 1.2.2, what role (if any) will this mod play?
ThanksThis 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 a more fleshed-out planet mapping and scanning experience.
Some reasons to use OSP: You generally like the stock resource system, you want to stay stock-alike, you don't crave much more complexity but the stock M700 Survey Scanner's instant reveal drives you insane. Or you like the stock system and simply want a biome overlay without using the cheat menu.
Hope that clears things up a bit.
-
Pushed out an update
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. Spacedock is usually a good bet.
-
55 minutes ago, ZobrAA said:
Oh! But than it means scanning area independent of orbit's height? Hm...
Yes. OSP isn't intended to be ultra realistic, just a step-up from stock. I figure die-hards have SCANsat.
-
3 minutes ago, ZobrAA said:
I'm okay with grid chunks size, it's scan cone angle bothers me. By logic and (semi-)realism purpose it have to be way smaller. Or planet will be fully scanned in a few orbits... Angle must be like 15-30 deg, IMO
May be it's worth to put the grid size slider to settings menu, so player can tweak it depending of planets sizes and lags?
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.
-
1 minute ago, ZobrAA said:
My solar system has variable scaling. Kerbin x3.2 stock, Mun x2.6 stock, some bodies scaled more, some less, some of them not scaled at all, like Minmus orbiting Eeloo, like Pluto-Charon...
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!
-
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?
-
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 along with a few other changes before long.
-
22 minutes ago, MusicMetalHead said:
Working on getting a relay network setup right now for a Moon mission, but I'll put survey back up and try it out again once I finish that. Might take awhile though. Everything is just soo hard in RSS, and shifting away from the "just add more boosters" mentality is hard.
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.
-
51 minutes ago, MusicMetalHead said:
I think a large part of the problem has to do with retroactive scanning taking up loads of memory and crashing it. I think some optimization in how that's processed might fix it. I'm not a mathematician, but if you described the parts to be retroactively scanned as a line of the path of the orbit traced over the map with the width of the line being a function of altitude (a lot of ass pulling going on here but it makes sense in my head), that would allow the calculation to be done as a (relatively) simple math problem, which computers are really really good at.
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.
-
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.
-
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.
-
1 minute ago, ZobrAA said:
Oh! Did not actually know that and not tested
So if I understand right it's that settings option called "Scan Autocomplete Threshold"?
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.
-
Just now, MusicMetalHead said:
I've tried scanning Earth a number of times, but it always led to a crash as soon as it tried to save. Never got very far.
Yeah, it might not be jiving well with RSS. I'll be looking into it this weekend.
-
2 minutes ago, ZobrAA said:
@Wheffle What if switch off planet grid data saving whet scan is 100% complete? I mean if planet is fully scanned - erase all its grid data and use stock resource overlay for that planet with no additional data saving?
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?
-
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!
-
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.
-
On 12/16/2016 at 10:03 AM, Rocket88 said:
Wheffle,
Was wandering what your thoughts were about adding contracts for scanning planets.
Awesome mod, Thanks for all your work
Hmm... I haven't thought about adding contracts. I might take a look.
-
Just now, Jarin said:
That's a rather different gameplay concept, having to pay to discover and track planets before they even show up on the map. No visual obscuring of the surface, just hiding the planet altogether, so you can't go there at all (unless you're exceptionally lucky). I was hoping for something without the time/money sink tied in.
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.
-
@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.
-
16 minutes ago, ShotgunNinja said:
Hi, this is a very interesting mod. I have a suggestion but didn't seem you have a repository so I'm posting it here.
You are currently (ab)using the subject id to store an unique id for your internal use, like '-184610'. What I suggest instead is to use a subject id like 'orbitalSurvey@-184610'. In that way you can extract back the id for your internal use, and other third-party mods that deal with science data have a chance of obtaining some short description for the data. Even if the associated experiment definition doesn't exist.
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 the module that sent it. In the next update I'll be sure to at least make the subject unique with your suggestion.
-
1 hour ago, ShotgunNinja said:
Found the issue with the 'orbital survey'. It just bypass the science dialog and send data to the comms...
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.
So if I understand right it's that settings option called "Scan Autocomplete Threshold"?
[1.12.X] Orbital Survey Plus v2.3.6
in KSP1 Mod Releases
Posted
@markal glad you got it figured out! toggling between views with that button is not a bad idea. i leave most of the stock stuff in-tact but i might look into that.