Orbital Survey [v0.9.4 for KSP2 v0.2.1]

[DimiBD]

On 1/12/2024 at 10:21 PM, Falki said:

v0.6.0 "There and Back Again"

• Added vessel markers, vessel names and geographic coordinates to the mapping UI
• Vessel markers are colored:
  • gray: inactive/disabled
  • red: invalid state
  • yellow: suboptimal altitude
  • green: ideal altitude
  • white: complete
• Added UI toggles for vessel names, geo coords and overlay
• Overhauled visual styles of the controls to be more in line with the stock UI
• Added UI sounds for toggle and dropdown controls

 

Great !

 

Is it possible to have, once the body is fully scan, the geo on mouse over ?

[zande]

I have encountered a bug. I have fully visual scanned Kerbin (the map has no black spaces) but the counter is stuck on 92% and will not proced further. I tried disabling and renabling again the scan but nothin changes. Every other scan on minmus, mun and kerbin completed without problem.

screenshot:  https://steamcommunity.com/id/lozande/screenshot/2307598439220664260/

Edited January 14 by zande
added screenshot

[simmy2109]

Loving this mod - it's a fantastic addition to the game, and I can't wait to see what you do with it.

The performance impact of the scans, especially on small bodies, is no joke.  I just started scanning Kerbin, Mun, and Minmus, and I'm getting pretty intense FPS drops at higher time warp settings.  After each planet is finished scanning, should I return to the vessels and disable scanning, or does the mod stop doing all the scan processing once a celestial body reaches 100%?

[Falki]

4 hours ago, zande said:

I have encountered a bug. I have fully visual scanned Kerbin (the map has no black spaces) but the counter is stuck on 92% and will not proced further. I tried disabling and renabling again the scan but nothin changes. Every other scan on minmus, mun and kerbin completed without problem.

screenshot:  https://steamcommunity.com/id/lozande/screenshot/2307598439220664260/

You're missing the top and bottom of the texture - see the light gray area just north and south of the mapped area. That happens when you're not at 90° inclination. You're somewhere between 80 - 85°. Adjust it and you should get to 95% which is needed to unlock the full 100%.

 

4 minutes ago, simmy2109 said:

Loving this mod - it's a fantastic addition to the game, and I can't wait to see what you do with it.

The performance impact of the scans, especially on small bodies, is no joke.  I just started scanning Kerbin, Mun, and Minmus, and I'm getting pretty intense FPS drops at higher time warp settings.  After each planet is finished scanning, should I return to the vessels and disable scanning, or does the mod stop doing all the scan processing once a celestial body reaches 100%?

No need to disable if you're at 100%, scans stop then.

FPS optimization is planned in a future release. Small bodies are the problem. They have the same sized texture, but a larger area is processed on each scan because a larger part of the body is encompasing the scanning cone. Larger area = more CPU intensive.

[Gorby1]

On 1/4/2024 at 5:00 PM, Falki said:

That's on my TODO list. BTW this is my TODO list if anyone's interested: https://github.com/Falki-git/OrbitalSurvey/blob/dev/src/OrbitalSurvey/Notes/TODO.cs

I see under long-term plans it says "scanning parts by -StanWildin" - that means the mod will eventually have new/unique parts, learned via the tech tree, that will do the scanning? Either way this is looking great so far!

Edited January 14 by Gorby1

[Falki]

30 minutes ago, Gorby1 said:

I see under long-term plans it says "scanning parts by -StanWildin" - that means the mod will eventually have new/unique parts, learned via the tech tree, that will do the scanning? Either way this is looking great so far!

It's a possibility for the long-term plan, yes.

[zande]

13 hours ago, Falki said:

You're missing the top and bottom of the texture - see the light gray area just north and south of the mapped area. That happens when you're not at 90° inclination. You're somewhere between 80 - 85°. Adjust it and you should get to 95% which is needed to unlock the full 100%.

Ops, sorry. Ireally didn't noticed the gray areas. Thank youy for your mod.

[Klock]

Falki, great mod.  This will undoubtedly be a must-have install for me.

I've been running a survey for Visual and I'm at the optimum altitude, pretty much circular orbit, around Kerbin.

I got the prompt for an experiment at 25% and that successfully ran.  However, I'm at 54% and either missed the prompt or it's bugged somehow.  I am not getting any science for the 50% milestone when I start an experiment.  The beaker icon goes into the long green flash (like for anything that's not an instant experiment, such as a surface sample) then resets to "ready to collect science" mode when I move over another region/biome.

I can confirm that Science Arkive is showing the Visual Mapping at 25% complete but not the 50%.

Any suggestions to try to fix, or need any more info to diagnose?

[Falki]

2 hours ago, Klock said:

I got the prompt for an experiment at 25% and that successfully ran.  However, I'm at 54% and either missed the prompt or it's bugged somehow.  I am not getting any science for the 50% milestone when I start an experiment. 

I can confirm that Science Arkive is showing the Visual Mapping at 25% complete but not the 50%.

Did you only have a single vessel in orbit with a Visual scan active? If you have multiple vessels scanning at the same time it can happen that another vessel triggers the 50% and the experiment ends up on that vessel.

If you have only 1 vessel, could you send your save file so I could check what parameters got saved? It's located here: "C:\Users\<yourusername>\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\YourCampaignName" (sort by last modified)

[Klock]

20 minutes ago, Falki said:

Did you only have a single vessel in orbit with a Visual scan active? If you have multiple vessels scanning at the same time it can happen that another vessel triggers the 50% and the experiment ends up on that vessel.

If you have only 1 vessel, could you send your save file so I could check what parameters got saved? It's located here: "C:\Users\<yourusername>\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\YourCampaignName" (sort by last modified)

Yes, I have only a Mun and a Kerbin satellite doing scanning...both are doing region and visual.  I was planning on moving them to region optimal altitude after visual was done. 

I sent you a DM with a link to the save.

[Falki]

45 minutes ago, Klock said:

Yes, I have only a Mun and a Kerbin satellite doing scanning...both are doing region and visual.  I was planning on moving them to region optimal altitude after visual was done. 

I sent you a DM with a link to the save.

Yes, save game data from Orbital Survey shows that the experiment triggered, but the same experiment isn't registered as sent or isn't onboard any vessel. I'm assuming that when it triggered there was some kind of an exception, either in Orbital Survey code or somewhere inside the game, that prevented the experiment from properly being created. It's hard to troubleshoot now without the entire history.

In any case, in the save file you sent, you can change Kerbin's "ExperimentLevel" from "Half" to "Quarter" and when you load that save the experiment will trigger again, hopefully successfully this time (I tested it, it did trigger successfully). At the top of the save file you'll see this, that's where you change it

"Bodies": {
  "Kerbin": {
    "Visual": {
      "DiscoveredPixels": "<omitted>",
      "IsFullyScanned": false,
      "ExperimentLevel": "Half"
    },
..

 

[Klock]

2 hours ago, Falki said:

Yes, save game data from Orbital Survey shows that the experiment triggered, but the same experiment isn't registered as sent or isn't onboard any vessel. I'm assuming that when it triggered there was some kind of an exception, either in Orbital Survey code or somewhere inside the game, that prevented the experiment from properly being created. It's hard to troubleshoot now without the entire history.

In any case, in the save file you sent, you can change Kerbin's "ExperimentLevel" from "Half" to "Quarter" and when you load that save the experiment will trigger again, hopefully successfully this time (I tested it, it did trigger successfully). At the top of the save file you'll see this, that's where you change it

"Bodies": {
  "Kerbin": {
    "Visual": {
      "DiscoveredPixels": "<omitted>",
      "IsFullyScanned": false,
      "ExperimentLevel": "Half"
    },
..

 

Thanks for digging into that...I appreciate ya...I'll do your suggested edit and keep an eye out on the next couple of milestones.  If I can be of any help to figure out the cause, I'll pass it along.

[Spacecat2000]

Falki, amazing work!  And you demonstrated with style and cool music to boot!

It is my wish to help you hash out a solution to varying the effective height so one isn't too high on Gilly or too low on Jool, say... So let's summarize the design goals: 
1-Make sense with the body size (high altitude on gas giants, low altitude on small moons, doesn't need to be precise, just roughly sensical)
2-Don't be so low we hit an atmosphere
3-Don't be so high we hit a SOI (like Gilly's) or a lower moon. (Jool vs Laythe, Duna vs Ike)
4-Make it forward-compatible with any future solar systems, such as planet packs or wherever we'll meet our alien cousins.
5-Give a hint to the proper altitude in the part specs, so we can plan interplanetary probes.

Using pure math would result in weird numbers, would likely solve 1-4, 5 would be messed up.
I had once suggested 'maybe classify worlds in 'Small bodies' 'Mid-sized bodies' 'Big ones' and give the values for all three in the parts, that would help with #5, but makes things tricky with #4 as you can't just make a list of Kerbol's worlds and put them in a table.

...Or can we?  How about we look at a table with kerbol's bodiess, in order of body width, showing low moon's altitude/SOI limit, and atmospheric depth for the hell of it.  I'm hoping this chart can help you figure out some good limiters for 'Small body' 'Mid Body' and 'Big ones'. Then we can pray those limiters would work with any future solar system.

Body name	Equatorial radius (m)	Atmosphere depth (m)	Maximum safe altitude (m) SOI limit or nearest moon's SOI	SOI limit	Nearest moon Pe minus moon SOI Radius (approx)
Gilly	13 000	0	126 123	126 123
Pol	44 000	0	1 042 138	1 042 138
Minmus	60 000	0	2 247 428	2 247 428
Bop	65 000	0	1 221 060	1 221 060
Ike	130 000	0	1 049 598	1 049 598
Dres	138 000	0	32 832 840	32 832 840
Mun	200 000	0	2 429 559	2 429 559
Eeloo	210 000	0	119 082 941	119 082 941
Moho	250 000	0	9 646 663	9 646 663
Vall	300 000	0	2 406 400	2 406 400
Duna	320 000	50 000	2 000 000		Ike: 2 000 000
Laythe	500 000	50 000	3 723 645	3 723 645
Kerbin	600 000	70 000	9 500 000		Mun: 9 500 000
Tylo	600 000	0	10 856 518	10 856 518
Eve	700 000	90 000	14 000 000		Gilly: 14 000 000
Jool	6 000 000	200 000	23 000 000		Laythe: 23 000 000
Kerbol	261 600 000	600 000	4.2 Gigameters		Moho: 4.2 Gm

 

Looking at this, Gilly's a clear outlier, Duna and Jool are touchy, every other SOI is all over the place but easy to work with.   Maybe you can get away with something like 
'Small bodies - below 100 km radius' (Gilly, POl, Minmus, Bop)         Maybe orbital survey  20km - 40km - 80 max?
'Medium bodies - 100 to 1000 km radius' (Ike to Eve)                             Current Orbital survey heights we know work well.
'Large bodies - above 1000 km radius'  (Jool and Kerbol)                      Orbital survey needs testing...

Anyway, hope that little chart helps you out. (I got the values from KSP1's wiki)

[Falki]

5 hours ago, Spacecat2000 said:

Falki, amazing work!  And you demonstrated with style and cool music to boot!
It is my wish to help you hash out a solution to varying the effective height so one isn't too high on Gilly or too low on Jool, say... So let's summarize the design goals: 
1-Make sense with the body size (high altitude on gas giants, low altitude on small moons, doesn't need to be precise, just roughly sensical)
2-Don't be so low we hit an atmosphere
3-Don't be so high we hit a SOI (like Gilly's) or a lower moon. (Jool vs Laythe, Duna vs Ike)
4-Make it forward-compatible with any future solar systems, such as planet packs or wherever we'll meet our alien cousins.
5-Give a hint to the proper altitude in the part specs, so we can plan interplanetary probes.

Thank you for your kind words! You summarized the issues pretty good. There's also one more design goal, performance optimization. Due to the nature of scanners having a certain Field Of View, a higher altitude on a small body can result in a large area of the body being processed for each scan, which causes performance issues. That's very apparent with Minmus for example. So the area that gets scanned must be roughly the same (or similar) for all bodies. I'm hoping that will work itself out when we define reasonable categories and values for them. For now, the 3 categories you stated might be enough. For the future, probably not. In RSS, for example Earth has a 6371 km radius, roughly the same as Jool in stock, and it's a relatively small body (when you compare it to gas giants). So perhaps "Giant bodies" could also be a category, and I could omit that category from the base game (go through the list of bodies at runtime and omit categories that are not present in the game).

[Deadly_Laser]

Not sure if this is a know issue or not, but it seems like the scanning sometimes stops being registered when using very high time warp. So far I've only seen this over Minmus (on a roughly 600km orbit) on the highest available warp, so might be related to the low framerate due to the FOV thing? I'll see if I can reliably reproduce it.

[Falki]

2 minutes ago, Deadly_Laser said:

Not sure if this is a know issue or not, but it seems like the scanning sometimes stops being registered when using very high time warp. 

You're probably having an issue with EC consumption that the stock game has. If timewarp is set to 100,000x, the game decides that the vessel doesn't have enough electricity, so scanning stops. Not really something Orbital Survey can solve, except as a fix to the resource consumption that the game uses. But that would be a better fit for Community Fixes IMO.

[Deadly_Laser]

2 minutes ago, Falki said:

You're probably having an issue with EC consumption that the stock game has. If timewarp is set to 100,000x, the game decides that the vessel doesn't have enough electricity, so scanning stops. Not really something Orbital Survey can solve, except as a fix to the resource consumption that the game uses. But that would be a better fit for Community Fixes IMO.

Ah, yes, that's probably it

[Spacecat2000]

17 hours ago, Falki said:

Thank you for your kind words! You summarized the issues pretty good. There's also one more design goal, performance optimization. Due to the nature of scanners having a certain Field Of View, a higher altitude on a small body can result in a large area of the body being processed for each scan, which causes performance issues. That's very apparent with Minmus for example. So the area that gets scanned must be roughly the same (or similar) for all bodies. I'm hoping that will work itself out when we define reasonable categories and values for them. For now, the 3 categories you stated might be enough. For the future, probably not. In RSS, for example Earth has a 6371 km radius, roughly the same as Jool in stock, and it's a relatively small body (when you compare it to gas giants). So perhaps "Giant bodies" could also be a category, and I could omit that category from the base game (go through the list of bodies at runtime and omit categories that are not present in the game).

Agreed, we could rephrase goal 1 to 'Make sense with the body size, and keep system performance in mind'...

RSS has a completely different scale than stock... So here's a random idea for forward-compatibility:
We're not sure what future solar systems will be like, but if you balance thing well for the Kerbolar system, there's a high likelyhood it'll work for future systems to the same scale.
Let's say you balance everything for 'stock size' but keep a sort of... multiplier in your code that in the future will be easy to adjust if someone plays the game with non-stock scale.  Say 2.5X scale, or the 10x scale for the solar system...

Think that'd work?

[Spacecat2000]

Hey Falki, I just had a crazy idea...

Right now you want to make it so the survey doesn't scan too wide when they're at optimal altitude...  It's tricky because the scanner has a fixed aperture angle.
What if it wasn't a fixed angle?    Let's say someone comes up with the math formula that takes the stellar body's radius, and gives the needed aperture for '7 map pixels wide being scanned', and then the orbital scanner adjusts its aperture to match (like a zoom on a camera), depending what body it's orbiting.

If the sat is at ideal altitude, set to correct angle, if it's less or more, mess with the aperture to get less pixels wide.

Then you could have your ideal altitudes be according to the simple table, and our rugged orbital scanner would adjust as necessary.  

[Zimbaa]

On 1/16/2024 at 12:39 AM, Falki said:

Yes, save game data from Orbital Survey shows that the experiment triggered, but the same experiment isn't registered as sent or isn't onboard any vessel. I'm assuming that when it triggered there was some kind of an exception, either in Orbital Survey code or somewhere inside the game, that prevented the experiment from properly being created. It's hard to troubleshoot now without the entire history.

In any case, in the save file you sent, you can change Kerbin's "ExperimentLevel" from "Half" to "Quarter" and when you load that save the experiment will trigger again, hopefully successfully this time (I tested it, it did trigger successfully). At the top of the save file you'll see this, that's where you change it

"Bodies": {
  "Kerbin": {
    "Visual": {
      "DiscoveredPixels": "<omitted>",
      "IsFullyScanned": false,
      "ExperimentLevel": "Half"
    },
..

 

FYI I experienced this same problem but with a probe on Duna. Did another mission to Dres and during that time the error occured. So could be some timewarp-issue.

Looked in the savegame and the experiment was not to be found. The problem was fixed by setting the "ExperimentLevel" to a lower level. 

I'm playing with a couple of other mods so I don't know if any of these interact weirdly with each other.

[Falki]

11 hours ago, Spacecat2000 said:

Let's say you balance everything for 'stock size' but keep a sort of... multiplier in your code that in the future will be easy to adjust if someone plays the game with non-stock scale.  Say 2.5X scale, or the 10x scale for the solar system...

A scaling multiplier is easy to set up, or better yet other planet packs could override default settings to set their own values. Something like this already exists in the form of Patch Manager patches that can be overriden from another mod, similar to how Module Manager in KSP1 handled patching: https://github.com/Falki-git/OrbitalSurvey/blob/master/plugin_template/patches/configs/_constants.patch. It isn't fully working at the moment, but should be easy to adjust later when there'll be a need.

11 hours ago, Spacecat2000 said:

What if it wasn't a fixed angle?    Let's say someone comes up with the math formula that takes the stellar body's radius, and gives the needed aperture for '7 map pixels wide being scanned', and then the orbital scanner adjusts its aperture to match (like a zoom on a camera), depending what body it's orbiting.
If the sat is at ideal altitude, set to correct angle, if it's less or more, mess with the aperture to get less pixels wide.
Then you could have your ideal altitudes be according to the simple table, and our rugged orbital scanner would adjust as necessary.  

I don't know. Having a fixed viewing cone seems more realistic to me, and I already did a bunch of trigonometry in code to make that a reality . While having fixed mapping radius would be easier to code and more consistent for players, I like that there's a difference in scanning small and large bodies, i.e. it takes a lot longer to scan an Eve or Jool sized planet. But performance needs to be a lot better for smaller bodies.

[Spacecat2000]

12 hours ago, Falki said:

A scaling multiplier is easy to set up,  (...)

(...) Having a fixed viewing cone seems more realistic to me, and I already did a bunch of trigonometry in code to make that a reality . While having fixed mapping radius would be easier to code and more consistent for players, I like that there's a difference in scanning small and large bodies, i.e. it takes a lot longer to scan an Eve or Jool sized planet. But performance needs to be a lot better for smaller bodies.

Glad one of my ideas (scaling variable) will be helpful.

'Realistic' is arguable as orbital scanners rely more on resolution than aperture (I think), buuut I totally getcha about it being 'fun' to have variance for bigger/smaller worlds!  By all means, let's stick to that method, haha.  So hopefully lower altitudes will do the trick, I gave you the crazy chart. Bonus points if this new altitude is for 'sub-100 km radius bodies' as that's easy to remember.
And if you find a 'big worlds' setting that works for both Jool and Kerbol, you'll have your big bodies all set too!  Hahaha.

'fraid I can't help with testing those altitudes by tweaking the mod, so i'll just wish you well.

[Falki]

v0.7.0 "Who needs glasses anyway?"

Features:

• Canvas can now be resized

              

• Zooming is now possible, up to x10

              

• Active vessel can be tracked when zoomed in

              

•  Mouse-overing vessel markers now shows vessel names and geo coordinates - requested by @DimiBD

Other:

• After mapping 100% of the body's surface, a higher resolution texture (2048x2048) is loaded to give a much clearer picture when zooming
•  Added Italian translations - by @leonardfactory

Fixes:

•  Updated Eve's Olympus region color to black so it's easier to differentiate from other regions - reported by @dolphin263
•  Fixed Chinese fonts not displaying properly in some cases - reported by @fengyuan0529
•  Fixed vessel marking coloring for vessels that have more than one antenna with the same scanning mode - reported by @schlosrat
• Replaced region names with the localized version (e.g. Biggest Crater -> Rayed Crater)

[hex3desu]

The constant improvements on this mod are great. I reckon this'l have a place on all the "must have KSP 2 mods" lists

[geoz]

A huge thanks for doing this.  It was great in KSP 1 also - how it is not in the core game by default is beyond me.  Latest update makes the scan a thing of beauty.

Does the game capture the co-ordinates of  flag plantings?  I'm wondering whether these could show up on the scan maps as markers also.