As an aside, I'm not sure how the scan resolution is useful to the player. For my first scanning mission I assumed it was the target altitude - somewhat scary skimming the surface of Mercury at 73m while in orbit (3km/s)..

It would also be really useful if the orbit planner could show some details of the orbit, such as aphelion and perihelion distances. Or even full orbital parameters, which could then tie into advanced scanning missions requiring the player to get into a particular orbit similar to KSP satellite missions (although that might be a bit technical for most players.. as-is according to some comments it's already too difficult if the scanning isn't in one of the "low"/"medium"/"high" autopilot orbits...) That said, personally I'd love to see the orbit planner to be closer to the KSP one, and once a bunch of manoeuvre burns are defined the autopilot would simply execute those.

I think your Previously and Now images are flipped.

Eh, I just copied the image links from the bug report instead of uploading the images again, and forgot that the first two images were to demonstrate the issue.. removed the incorrect image.

This is a reasonable change, although the one impact this has is that it can be much more difficult to see if the orbital scan progress is going up on very large bodies with an e.g. 20% coverage scan contract.

It took forever to go up a percentage point before as well.. but unless we increase the number of decimals I don't think there's any way to improve on this.

Also, given this is all floats there's some rounding issues - even with these changes, it can look as if the scan has completed, but it still has a little way to go.

For example:

Target: 0.43746  -> Display: 43.7%
Current: 0.43713 -> Display: 43.7%

One way to fix this would be to clamp the target distance/percentage to a single decimal point. Ideally I'd prefer to rework all of this to just use integers, but Lua is untyped (or rather, you can't specify a type, values have types as determined by Lua) as far as I've been able to work out.

As much as I personally think a 0...100% progress indicator is "clear", apparently it's unclear to users so I won't object.

It's clear enough for the surface scan, but it was (IMHO) very confusing for the orbit scan, and I had found an online discussion somewhere (despite lots of Googling and going back through browser history I was unable to find this again - there's a possibility I hallucinated it even though I am fairly certain I'm not an AI..) with a person raising exactly the same issue. I found it while trying to find an online guide on how to use the scanners..

The "MINIMUM ALTITUDE" was completely unclear to me.. I thought it meant I was still too high.

Perhaps instead of displaying the scanning status in the title, add additional icons to the scanner display? Altitude low/optimal/high/out-of-range? (With out-of-range used for both too low as well as too high).

Now that I've played with it more I've seen more information in-game such as the minimum altitude in the scanner description, so this may not be a big deal for most people, but I did struggle to intuit how to use the scanner.

As an aside, I'm not sure how the scan resolution is useful to the player.

I agree, though I was the one to originally implement it there's definitely some missing information for the player to be able to intuit "this affects how high I can fly". I don't have strong ideas for what to "do" with it at current though.

I think it would make it too simple to simply list minimum and maximum altitudes; it would be nice if there was a way for players to "learn" the optimal altitude for a scanner and the desired resolution. Or perhaps add the current resolution to the display and have it change based on the altitude, that way a player can home in on the optimal altitude.

Does the speed of scanning change based on altitude? Lower orbits are faster, but higher orbits can allow for a wider area to be scanned per orbit.. as well as being able to use higher time acceleration. But the debug display seems to indicate that the number of required orbits is fixed for a given body/scan resolution/completion percentage.

It would also be really useful if the orbit planner could[...]

These are all loosely planned.

Yayy :)

... re-reading (and a few coffees later), I now understand what you meant with it taking longer to show progress. Yes, that is a valid point.

Instead of showing a completion percentage as a number, how about having a bar fill up to show the completion? (This would require a bit more work).

Mockup:

I found it while trying to find an online guide on how to use the scanners

Ideally, the wiki should be the place. E.g. there's some on the FAQ or mission types page

It took forever to go up a percentage point before as well.. but unless we increase the number of decimals I don't think there's any way to improve on this.

From a game perspective, player would expect to see their action (flying within correct parameters) to have a visible effect in some way so they don't have to wonder if they're doing it right or not, so wold be nice if this was improved.

Got the progress bar working :

Yayy/nayy?

I guess it comes down to what the percentage should represent: surface scanned, or mission completion? What makes the player think the percentage would be anything other than total mission progress? Does the mission contractor say "scan X % of the planet"? I can't remember that (I think I wrote/edited those mission texts). If they did, I'd opt to change in that end.

Why is the Mars, Sol mission at 1384%?

I guess it comes down to what the percentage should represent: surface scanned, or mission completion? What makes the player think the percentage would be anything other than total mission progress? Does the mission contractor say "scan X % of the planet"? I can't remember that (I think I wrote/edited those mission texts). If they did, I'd opt to change in that end.

Yes, the mission-giver states that the mission requires, for example, "13.8%" of the target planet to be scanned. Which is also what the requirements show (bottom-left of the scan card).

Up to now, the completion indicator (top-right of the card) always went from 0..100% - which I found rather confusing when it went past the "13.8%" of the target.

Why is the Mars, Sol mission at 1384%?

Because I stuffed up creating a scan mission.. the debug screen was (I'm guessing) originally designed for surface scans, so it doesn't have a percentage slider, only a kilometers one, and 1km == 100%, not 1%..

Mission details screen:

Another idea:

Yes, the mission-giver states that the mission requires, for example, "13.8%" of the target planet to be scanned. Which is also what the requirements show (bottom-left of the scan card).

Up to now, the completion indicator (top-right of the card) always went from 0..100% - which I found rather confusing when it went past the "13.8%" of the target.

Have a thick line across the progress bar at 13.8% and/or change the color of the bar after 13.8%? Show a big tick in the top right after 13.8%?

Another idea:

Yes, the mission-giver states that the mission requires, for example, "13.8%" of the target planet to be scanned. Which is also what the requirements show (bottom-left of the scan card).

Up to now, the completion indicator (top-right of the card) always went from 0..100% - which I found rather confusing when it went past the "13.8%" of the target.

So there's the initial issue I had which was that the progress percentage (top-right) went from 0..100%, even though the mission requires only 13.8%. I found this very confusing. Which is why I changed it so the percentage only goes from 0..13.8%.

@Web-eWorks then pointed out that this means that the percentage display potentially ticks up much slower than before, which is why I added the progress bar. The progress bar "displays" 0..100%, but does so graphically, so there is no confusion between percentages. So the progress bar will (should) tick up as quickly as the original display did.

Note that this all only affects the orbital scan missions.

The surface scan missions (which I hadn't done and which, I think, came first) require a set distance (area?) to be covered, so in this case, the original percentage display 0..100% was fine - there was nothing to confuse anybody as the target progress was in km, not in %.

Have a thick line across the progress bar at 13.8% and/or change the color of the bar after 13.8%? Show a big tick in the top right after 13.8%?

... why? the progress bar goes from 0..100% of the 13.8%. Adding the 13.8% to the progress bar would reintroduce the original confusion. Why would the mission not complete once 13.8% is reached and instead require to continue scanning all the way to 100%?

why? the progress bar goes from 0..100% of the 13.8%. Adding the 13.8% to the progress bar would reintroduce the original confusion. Why would the mission not complete once 13.8% is reached and instead require to continue scanning all the way to 100%?

It's totally not clear to the player (who doesn't know the code and the backstory) that it's 0-100 of 13.8%. Hence my idea to keep 0-100% of the planet surface (which is simple and intuitively understandable) and add a line or a tick at the place the mission requires

Ok, we may be talking at cross-purposes (it's never easy with text).

My idea is to remove any sort of confusion caused by displaying multiple percentages, one being the target scan percentage, and the other the mission progress percentage. Having the former display 13.8%, but the latter display 0..100% was (for me at least) very confusing the first time I tried an orbital scan mission. It was so confusing that I spent several hours digging into the code to try to understand it.

Now, having changed the progress percentage to count from 0..13.8 instead of 0..100, to make it match the target scan percentage, worked fine. The problem with this is that it counts up slower than before, and players might think nothing is actually happening and the mission isn't triggering or what have you.

So following on from my initial "fix" I now propose to add a mission progress bar WITHOUT display any sort of percentage to avoid the initial confusion in order to provide faster feedback to the player that something is happening and that the scan is progressing.

Hence my idea to keep 0-100% of the planet surface

This has got nothing to do with planet surface scans. I am talking about planet orbital scans.

Surface scans don't require a percentage completion, they require a distance completion.. and for those the 0..100% display made sense and is intuitive and there are no arguments or quibbles with that.

If people think the original display is clearer and more intuitive I will close this PR. I now understand how the scanning missions work. I still think it is incredibly unintuitive for first timers which is why I proposed these changes.

It's totally not clear to the player (who doesn't know the code and the backstory) that it's 0-100 of 13.8%. Hence my idea to keep 0-100% of the planet surface (which is simple and intuitively understandable) and add a line or a tick at the place the mission requires

If your proposal is for the progress bar to render 0..100, but to complete at 13.8 (sorry, that's not how I read it - english is not my first language), then we have the same problem as simply displaying 0..13.8 as a percentage in the top-right : nothing actually happens for ages since it will potentially take a long time for the first bit of progress to start displaying.

I guess instead of "Scan Progress" the progress bar could instead say "Mission Progress". Would that improve it?

Forgive me for interfering with my 5 cents, maybe it’s possible to convert “surface percentage” into other units, into square kilometers, for example?

Forgive me for interfering with my 5 cents, maybe it’s possible to convert “surface percentage” into other units, into square kilometers, for example?

There is no "surface percentage" anywhere.. the surface scans are in kilometers (I wasn't sure if they should be square kilometers..)

Forgive me for interfering with my 5 cents, maybe it’s possible to convert “surface percentage” into other units, into square kilometers, for example?

There is no "surface percentage" anywhere.. the surface scans are in kilometers (I wasn't sure if they should be square kilometers..)

Hm, but what do you scan during an orbital scan? Orbit?

Hm, but what do you scan during an orbital scan? Orbit?

Ah.. I see what you mean. It's not what the game currently says for the orbital scans, but you're asking if the game could instead request a particular amount of area to scan from orbit instead of a percentage of the planet.

I'm fairly sure this could be implemented.. area of a sphere is easy enough to calculate. This would remove all the percentages except for the completion percentage. But this assumes the game can access the size of the target body when generating the mission, potentially in a system far far away..

I'm fairly sure this could be implemented.. area of a sphere is easy enough to calculate. This would remove all the percentages except for the completion percentage. But this assumes the game can access the size of the target body when generating the mission, potentially in a system far far away..

Oh well, this is the least of the problems, you are doing GetSystemBody, it's all there.

Oh well, this is the least of the problems, you are doing GetSystemBody, it's all there.

Ok no worries; based on some other code comments and tinkering with the System Map it appeared as if not all information was available when not in-system..

What do others think about this change?

What do others think about this change?

My headspace is more in fixing the "upstream" issue of why give / show the player the percentage of the body to scan in the first place. I assume orbit scan does the same as surface, in that it measures distance traveled along surface (but from high altitude). The information player might be interested in is if it's a large or small "scan job", but I also assume the difference is pretty negligible for orbit missions? For surface missions you have to do actual flying and constantly keep an eye on the altitude. For orbit scanner, I assume it's just smooth gliding for some time, so might not matter much to the player how many percent of the planet body is to be scanned?

Either way, I'm sure what ever solution you converge to will be an improvement over what we have now.

Changing to area might be a good idea (you no longer get the two % that mean different things), but I think it would be better left to a follow-up PR

For orbit scanner, I assume it's just smooth gliding for some time, so might not matter much to the player how many percent of the planet body is to be scanned?

It is, but it can take many in-game days which, given the low time acceleration near planets, can translate to hours of real-time. Not sure if the 1000x time acceleration kicks in within range of the scanner - but reducing the amount of real-time would increase the amount of time in-game (higher orbits take longer) and the potential to miss deadlines.

So a higher percentage means more time, but the actual amount of time required also depends on the size of the body. So it is probably a bit difficult for someone to gauge.

Converting the display to area instead of percentage might provide players with a better chance to estimate the amount of time required.. I'm assuming that scanning a particular amount of area should take roughly the same amount of time regardless of the size of the body. So it would be similar to the surface scan which also is a simple distance measure.

Alternatively the debug window provides the number of orbits required to achieve the desired coverage. This is currently not exposed to the player. This would probably also be fairly straightforward for a player to estimate to complete the contract as long as they check the size of the body - larger planets will take longer to orbit.

I'll see if I can come up with some implementations.. (lol, talk about feature-creep!)

So I've done some research and playing around.. changing the surface scans to km² is easily doable and probably should be done - doesn't make sense for it to be a distance. The calculations in the game are already in km², it's only the way they're being displayed that's distance rather than area for some reason. Adding Area units to the formatter was pretty trivial.

Orbital scans, on the other hand, are a different kettle of fish. Again, the progress is originally calculated in km², but then converted to a percentage of the area of the target body.. and that makes sense when you start realising the sizes involved. Earth's surface, for example, is 510 Mm² (5.1 * 10^14 m², or 510,000,000 km²).. Titan is 83 Mm². Phobos is 5695 km², so the range is also huge.

In an orbit at the minimum altitude (650km) on Earth, the XKM-650 scanner sweeps out an area of about 20,000 km² per second (according to the in-game calculations). This may seem a lot, but it would still take 12½ years just to scan Australia! (Of course, at higher altitudes it would go a lot quicker..)

But it seems that our in-game scanners aren't that great compared to real Earth Observation satellites which are around 500km altitude and can cover the entire Earth every couple of days.

Although I may have made some serious errors in my maths..

I think large areas should not scare us - we don’t know exactly what resolution there is. Obviously, the orbital scan is very survey and small-scale.

I think large areas should not scare us - we don’t know exactly what resolution there is. Obviously, the orbital scan is very survey and small-scale.

The Scout mission generator so far has mostly given me orbital survey missions which take a looong time to complete (surface scan missions are generally quick), requiring multiple orbits at least, and often many orbits. So the orbital scans are not so small-scale. But they are nifty because they force players to get into orbits.. (although I guess most will simply click on the autopilot buttons..)

The resolution of the scans are very much a thing and calculated internally, just not exposed to the Player. This is what effectively limits the maximum height above the terrain at which the scan is active.

Large areas don't scare me - but I don't know how to display them nicely in the rather limited amount of screen real estate available.

• 10,000 m² = 0.01 km²
• 1,000,000 m² = 1 km²
• 10,000 km² = 0.01 Mm²
• 1,000,000 km² = 1 Mm²

I guess we could switch between m² to km² and then to Mm² earlier? But most people have no concept of Mm².. (I didn't before looking into it yesterday - Wikipaedia gives a really good overview).

-> 0 - 100 m² display with decimals (0.12m², 99.37 m²)
-> 100 - 9,999 m² display as m² with no decimals (237 m², 8,312 m²)
-> 10,000m² to 100km² : display km² with decimals (0.02 km², 12.94 km²)
-> etc.

Ok, I've tried this and I think it works.. might still require tweaking the mission generator though. I already reduced it by a factor of 10, but it still generates pretty long missions. I don't think I really affected the generator apart from converting the percentage to area and didn't playtest the original implementation enough to see how it compares, but it did take a long time as well.

These range from 1.6Mm² to 8.1Mm2.

Info: Generated orbital scan mission, coverage=0.020064%, body_coverage=0.019422%, body_coverage_km2=1627868.236900km2
Info: Generated orbital scan mission, coverage=0.040726%, body_coverage=0.015963%, body_coverage_km2=8160559.381900km2
Info: Generated orbital scan mission, coverage=0.046700%, body_coverage=0.008052%, body_coverage_km2=44040562.392800km2
Info: Generated orbital scan mission, coverage=0.039873%, body_coverage=0.001236%, body_coverage_km2=101028920.272300km2
Info: Generated orbital scan mission, coverage=0.012820%, body_coverage=0.004096%, body_coverage_km2=4721460.098400km2

For reference, a 100% scan of Dione (3.97Mm²) in a "high orbit" (1.57Mm) took 8.5 days game-time and 12 minutes real-time at a time-acceleration of 1000x

I did not have enough time to perform the scan as well as fly to/from Mars to Dione to complete the mission in time, and that was with a full hold of fuel. That said, it was an "urgent" mission.

The display is nice though:

EDIT: Earth, 15.29Mm² took only 4.5 hours in-game (time acceleration 100x, ~3min real time) - medium orbit 3.97Mm. Increasing the orbit to 6.5Mm reduced the time to 4h in-game. Scan generated about 1060km²/s

will discuss in forums first in future.

Do note that the forums are ...quite asynchronous in nature. They're good for long-range discussion but discussion surrounding active implementation effort tends to happen here or on IRC (with the balance depending on the day). We normally consign feature requests there as an "idea repository".

... bug (feature)? Scan missions complete as soon as you dock (at least in the same system). But the mission description says the player needs to return to the mission-giver.

I think some missions are technically supposed to be able to complete if handed in at any station (i.e. you're speaking to a representative of an organization with offices on multiple planets). However, that definitely looks like a bug!

I thought this mission type required docking in the same faction space, but glancing at the code, seems like I'm wrong, thus my comment contributes nothing but noise, but since I've already typed it up....

As there were no further comments/suggestions/concerns, I have now cleaned up the PR, rebased on master, and marked it "Ready for Review". I've also updated the description to reflect the current solution.

Finally, this PR includes a fix to prevent Scout missions from completing at the first port a player docks at after finishing a scan, as well as improving (imho) the way missions are displayed after being accepted in the players' mission log. The full description is now always shown, as well as the return location (if known). It now also integrates with the "Set Return Location" navigation button from the mission manager.

Rebased on main; squashed commits; addressed most comments.

Please continue review at your leisure.

first test results:

• Getting the cash only when reached the station where the mission has been accepted now working.
• Surface scan works normally, percentage completion is shown correctly.
• New orbital scan missions sometimes have a very small area to cover and are completed in less than one second, a mission accepted in former master branch was also completed in two complete orbits, percentage completion did not work there.

Change suggestion: The symbols for scan missions from the bulletin board could/should also be used in the scan manager.

Change suggestion: The symbols for scan missions from the bulletin board could/should also be used in the scan manager.

This is non-trivial - the BBS icons are loaded from individual icon files as a PiImage, and then drawn by invoking the Draw method. The scan display is inherited from ItemCard which assumes the icon is in the ui.theme.icons and performs calculations to find the offset inside that file for the icon to be rendered before drawing it with ui.icon(). The ui.theme.icons currently does not include the BBS icon images.

ItemCard is also used in EquipCard so that would also need to be modified if we pass in a PiImage instead of a ui.theme.icons defined icon.

We should probably have a unified approach for icons in the game to avoid such discrepancies - either they should all be PiImages, or they should all be ui.theme.icons. Having individual icon files is probably better for modders..

I've not forgotten this, just been horribly busy over the weekend. If all goes well, will do final review in ~12hrs. Thank you again for your patience!

I've not forgotten this, just been horribly busy over the weekend. If all goes well, will do final review in ~12hrs. Thank you again for your patience!

No rush..

I'm glad I playtested this, as I noticed that a mission to Saturn wants me to scan all 41,000 Mm² of Saturn's surface - and a mission to scan all 7.2Mm² of Oberon's surface pays a measly $620, barely enough to cover fuel for the very long trip into deep space.

Stuff like this tends to slip through the cracks on long PRs sadly - other than this I think the PR is good to go.

Hmm, this is really odd - I playtested this quite a bit and the only time I got full coverage was for very tiny moons. I see the current code is wrong, as you point out, but due to all the squashing/rebasing, I've lost when it was working as intended.

.... ok, found it - I was multiplying the body_area by body_coverage, and at the same time reducing the number of decimals. The code was then refactored to use utils.round() and in that update I somehow dropped the multiplication. I guess I only briefly tested from that point onwards.

Well caught, thank you.

As for the reward amount, yes, I never adjusted it.

Thanks @mwerle for continuing to update the PR in a timely manner even when my own availability is quite spotty!

Not at all - I've been away myself. This is only a hobby after all :)

Rebased and squashed the final changes.