Suggestion: Maximum exploration value property

[Tkael]

Discussed in https://github.com/EDCD/EDDI/discussions/2283

^{Originally posted by **Transcan** November 2, 2021} Hello there, I use EDDI a lot for exploration purposes. I already tweaked the personality to my own needs but there is something that I miss in EDDI. Some context first. I tweaked "_body scanned_" script in order to inform me when a scanned body is worth for mapping, and also tells me the expected value of that mapping (aka, the maximum exploration value of that body). I used "**body.estimatedvalue**" for such value, because the manual says it takes in count the scan and the mapping... But it seems that EDDI only gave you the actual state of that particular body. In other words, if you didn't mapped it yet, you will only get the scan value. So that doesn't work for my script, at least not as I intended: Tell me the mapping value and decide if its worth enough to make the trip to the body and map it. Yes, I know its always a similar value for a particular body type, so the prize wouldn't be decisive... But I prefer to hear "Mapping this body will give you more than 2 millions", than "this body will give you 300 thousands". whatsoever... To the point. I wanted to see in a future release of EDDI a new body property that gave the maximum obtainable exploration value of a body. In other words, the same function, but instead of using actual "_alreadyMapped_" state, return the value making it always been "_true_". With this change, the resultant value is the maximum value the commander can get from that body, in its actual state (taking in count the first discovery and first mapping states). It could be named something like body.maxvalue (or body.maxscanvalue). Meanwhile I "fixed" it myself by cloning the built-in _estimateBodyValue()_ function into a cottle script, calling it whenever a scan event occurs, and storing the value in a new state variable named "_eddi_context_last_scan_max_value_", along with the usual "_eddi_context_last_scan_estimated_value_". The scripts uses those variables for their magic, instead the one gave by _body.estimatedvalue_ and all is fine and working as I intended... But I feel its redundant and I think this new property is quite easy to implement. What do you think?

[Tkael]

Should be possible. I imagine we'd also need to assume efficient mapping.

[Transcan]

Should be possible. I imagine we'd also need to assume efficient mapping.

Yes, and also if is mapped in Odyssey or not: For Odyssey, there is a new bonus for mapping - an extra 30% on the mapping bonus (or 555 credits, whichever is higher).

As MattG says here I know EDDI is using his formula, because I saw it in the code, but I didn't saw that Odyssey bonus been applied (and it could be easily implemented too).

There is also another bonus, applied per body, when the whole system is mapped. But I guess that is more difficult to handle in EDDI and the estimated value would be close enough to the real one, so that bonus could be negligible without any harm.

[Californ1a]

Same issue, I wanted to edit the "Bodies to map" script to only report a body as worth mapping if it was going to be >1m mapping value, before I took the time to go fly over to it and map it, but body.estimatedvalue seemingly only says the "current" value of the body (0 if it hasn't been scanned yet, and only the "base" scan value afterward; it won't say the potential scan value before FSS or the mapping value before mapping it). EDSM's dashboard is able to show estimated mapping values before mapping them, as soon as it knows your current system, but I'd prefer not needing to keep that dashboard page open all the time just to see which ones are "actually" worth mapping.

body.estimatedvalue should probably be changed to something like body.estimatedCurrentValue so it's more clear what it actually is, and there should be a few other added variables like body.potentialScanValue and body.potentialMapValue to tell you what it might be worth before scanning and before mapping, respectively. Ideally, it'd also take into account if that body has already been discovered/mapped and add in the first discovered/first mapped bonus.

[Tkael]

This has already been implemented - {body.maxestimatedvalue}