May be my imagination... seems to take a lot longer to download systems than it used to.
Release EDDiscovery 17.X is now out! New Spansh intergrations - 3dMap from spansh data, Station panel
- Thread starter robbyp
- Start date
That depends on the state of EDSM and the speed of your drive.
Nothing has changed in the code regarding this, so either you're making it up in your mind or EDSM and/or your drive are having a bad day.
Last edited:
I came across an issue where the projected values shown in EDD for a mapped body are calculated incorrectly. Specifically EDD was reporting the "first mapped" value on a body that was previously mapped. I only noticed it when I had gone out to visit Pratchett's Disc in HIP 74290 - I mapped the whole system and EDD showed a value of 6.5MCr but carto only paid 1.6MCr for the system. I checked with FD support and they confirmed the carto reward was correct. Anyway, tonight I remembered to gather evidence of this for consideration by the authors. So here is a picture showing the relevant part of EDD scan panel pasted over the left side of the image of the cartographic sell page - you can clearly see that the values for body 4 are vastly different. So, I am not sure how prevalent this is or if it is just some weird glitch that mapping some previously mapped bodies erroneously indicates the "first mapped" value.
There's no indicator that the body in question was previously mapped, So it would get the first mapped bonus.
The screen you took from UC doesn't show what you really get, bonus credits (such as first discoverer and first mapper) are only shown after selling in their bonus pop up (which itself is buggy and can carry over previously awarded bonuses to other sales -.- ).
HIP 74290 is in the bubble, there are bodies in the bubble that have a first mapper tag, but no first discoverer tag. Those are impossible to calculate.
We mentioned that in the patch notes:
If you provide your journals I could check if something is obviously wrong.
€: The only way to get really correct UC values is to sell a system on its own as this produces a journal entry containing the needed values. Selling a whole page only gives the values for the whole page.
The screen you took from UC doesn't show what you really get, bonus credits (such as first discoverer and first mapper) are only shown after selling in their bonus pop up (which itself is buggy and can carry over previously awarded bonuses to other sales -.- ).
HIP 74290 is in the bubble, there are bodies in the bubble that have a first mapper tag, but no first discoverer tag. Those are impossible to calculate.
We mentioned that in the patch notes:
So it might be that your initial incidence was caused by a combination of that and you only looking at the "non-bonus" screen of UC.
If you provide your journals I could check if something is obviously wrong.
€: The only way to get really correct UC values is to sell a system on its own as this produces a journal entry containing the needed values. Selling a whole page only gives the values for the whole page.
Last edited:
OK - I'll try to investigate in the hope of figuring this out for my own OCD if for nothing else. I can't remember when I sold the HIP 74290 data but it would have been before my C drive SSD gave up the ghost last week so any journals from then were lost as I didn't have a recent backup (thankfully EDD database is on a different drive). In the meantime though, here is a screenshot of the scan window of HIP 74290 - you can see the system projected value is over 6.5MCr - I have left the mouse-over for one body which shows the mapped value as rather high for an already-mapped body. You can compare the overall system value (and the highlighted body) with the figures given on the system's EDSM page. I don't know if that is of any use for now, I will try to find time to get better data.
P.S. I don't know why the EDD image I posted of Musca Dark Region GM-V c2-20 (post #1243) didn't show the body as already mapped, I know it had been so I just checked on the system map in-game and it shows as already mapped (by AGRAFFE - which isn't me) here is an image from the game showing that:
P.S. I don't know why the EDD image I posted of Musca Dark Region GM-V c2-20 (post #1243) didn't show the body as already mapped, I know it had been so I just checked on the system map in-game and it shows as already mapped (by AGRAFFE - which isn't me) here is an image from the game showing that:
Last edited:
It's always possible that another commander just sold that mapping between the time you mapped and sold.
If your DB isn't that big (or you have lots of free online space) you could upload your DB so I can check these things
It's always possible that another commander just sold that mapping between the time you mapped and sold.
If your DB isn't that big (or you have lots of free online space) you could upload your DB so I can check these things
Yeah, no it was literally two jumps and I am positive that I picked that body to scan because the system map showed it already had a scanned by tag. PM sent btw.
So I just remembered a bug that we discovered on the Canonn Discord a few months back.
The first scan of a body reports all flags the correct way, but if you map a body a second scan event is generated that wrongly says that the body wasn't mapped.
This leads to the following behaviour: If you first FSS the system all values are displayed correctly, but as soon as you map a body the flags are updated due to the new scan event in the journal files which triggers a new calculation that has way too high values.
Might it be that you tend to map already mapped bodies?
There's nothing EDD can do about this, bodies are always updated with the newest scan events as they might contain newly added infos.
The first scan of a body reports all flags the correct way, but if you map a body a second scan event is generated that wrongly says that the body wasn't mapped.
This leads to the following behaviour: If you first FSS the system all values are displayed correctly, but as soon as you map a body the flags are updated due to the new scan event in the journal files which triggers a new calculation that has way too high values.
Might it be that you tend to map already mapped bodies?
JSON:
{ "timestamp":"2021-07-02T22:13:51Z", "event":"Scan", "ScanType":"AutoScan", "BodyName":"Synuefe QX-C c15-6 1", "BodyID":2, "Parents":[ {"Null":1}, {"Star":0} ], "StarSystem":"Synuefe QX-C c15-6", "SystemAddress":1733455352450, "DistanceFromArrivalLS":370.225845, "TidalLock":true, "TerraformState":"Terraformable", "PlanetClass":"Water world", "Atmosphere":"carbon dioxide rich atmosphere", "AtmosphereType":"CarbonDioxideRich", "AtmosphereComposition":[ { "Name":"Oxygen", "Percent":94.454102 }, { "Name":"CarbonDioxide", "Percent":5.448382 }, { "Name":"SulphurDioxide", "Percent":0.097520 } ], "Volcanism":"", "MassEM":0.135877, "Radius":3282948.250000, "SurfaceGravity":5.024894, "SurfaceTemperature":252.533798, "SurfacePressure":10776.457031, "Landable":false, "Composition":{ "Ice":0.000000, "Rock":0.671145, "Metal":0.328855 }, "SemiMajorAxis":96424145.698547, "Eccentricity":0.096051, "OrbitalInclination":-8.099336, "Periapsis":346.348552, "OrbitalPeriod":1911817.431450, "RotationPeriod":2821789.176132, "AxialTilt":0.432928, "WasDiscovered":true, "WasMapped":true }
JSON:
{ "timestamp":"2021-07-02T22:15:23Z", "event":"Scan", "ScanType":"Detailed", "BodyName":"Synuefe QX-C c15-6 1", "BodyID":2, "Parents":[ {"Null":1}, {"Star":0} ], "StarSystem":"Synuefe QX-C c15-6", "SystemAddress":1733455352450, "DistanceFromArrivalLS":370.225770, "TidalLock":true, "TerraformState":"Terraformable", "PlanetClass":"Water world", "Atmosphere":"carbon dioxide rich atmosphere", "AtmosphereType":"CarbonDioxideRich", "AtmosphereComposition":[ { "Name":"Oxygen", "Percent":94.454102 }, { "Name":"CarbonDioxide", "Percent":5.448382 }, { "Name":"SulphurDioxide", "Percent":0.097520 } ], "Volcanism":"", "MassEM":0.135877, "Radius":3282948.250000, "SurfaceGravity":5.024894, "SurfaceTemperature":252.533798, "SurfacePressure":10776.457031, "Landable":false, "Composition":{ "Ice":0.000000, "Rock":0.671145, "Metal":0.328855 }, "SemiMajorAxis":96424145.698547, "Eccentricity":0.096051, "OrbitalInclination":-8.099336, "Periapsis":346.348552, "OrbitalPeriod":1911817.431450, "RotationPeriod":2821789.176132, "AxialTilt":0.432928, "WasDiscovered":true, "WasMapped":false }There's nothing EDD can do about this, bodies are always updated with the newest scan events as they might contain newly added infos.
OK ... So if for example someone does the road-to-riches "thing" (my examples were not from that) then all forecasted values in their EDD scan panel and scan tab of their statistics panel will bear no relation to actual rewards? i.e. if they FSS then Map then you say EDD takes that mapping as a "first mapped" event?
Sorry if I am a bit confused.
If this specific bug strikes...
Yes then all values after mapping are wrong.
Note that I didn't test how common this bug is, back when someone mentioned in Canonn's exploration channel that one body appeared to be wrong in EDD I went out took a look myself. Until now no one has investigated further, so it might be that this bug is rare, but it also might be a "all the time" bug.
You can always make an issue on the tracker about this, but I think we all know how likely it is that such an obscure thing even gets enough votes.
Yes then all values after mapping are wrong.
Note that I didn't test how common this bug is, back when someone mentioned in Canonn's exploration channel that one body appeared to be wrong in EDD I went out took a look myself. Until now no one has investigated further, so it might be that this bug is rare, but it also might be a "all the time" bug.
You can always make an issue on the tracker about this, but I think we all know how likely it is that such an obscure thing even gets enough votes.
Okey dokey - so it is not a consistent behaviour, just an irritating bug. So best leave it at that, I'll keep an eye out for it striking again.
I didn't say that it's not consistent, I said no one knowsOkey dokey - so it is not a consistent behaviour, just an irritating bug. So best leave it at that, I'll keep an eye out for it striking again.
But if you keep an eye on it you soon might know how consistent it is. Just remember to keep an eye on bodies you want to map prior to mapping in EDD to see if the "was mapped" flag is set and after mapping to see if this flag has changed.
15.0.3 fixes:
github.com
- A crash occurring on some video cards due to use of a debug buffer binding above 16. Occurred on a nvidia 2070.
- Fix issue that error dialog is not produced but program asserts if user gives a non accessible/writeable/creatable data location during install
- Suit upgrades now work correctly and change the suit identifier and name to the next level up
- Suit weapons panel now works more smoothly during updates
Release EDDiscovery Release 15.0.3 New 3dmap, Organics panel, updated UI, fixes to 15.0.2 · EDDiscovery/EDDiscovery
See a video on this version here : https://youtu.be/QxViI2t6ryM Pack updates: Voice Pack 18 has been updated - Added more events, made it more robust to strange Frontier data Free voice control ma...
github.com
@Brimston EDDLite tracks the core EDD functionality at the time its released. I'm not doing detailed deltas on it, i do that with EDD and am not doing it twice.
There is an EDDLite thread here to use here: https://forums.frontier.co.uk/threa...spansh-eddb-updater-and-screenshotter.549810/
There is an EDDLite thread here to use here: https://forums.frontier.co.uk/threa...spansh-eddb-updater-and-screenshotter.549810/
Not quite sure what is going on but after the last 2 updates EDD will not download EDSM data. It says it's "Performing full download of System Data from EDSM" but I let it run for 27hrs and it never completed. Any suggestions on where I should look? Thanx.
-Rick
-Rick