Elite Observatory - Search your journal for potentially interesting objects, or notify you of new ones on the fly while exploring!
- Thread starter Vithigar
- Start date
Looking at what I've recorded so far, I've found 283 "Wide Rings", 262 of which are less than 13 planetary radii. There's a pretty sharp cutoff above 13.0 radii:
5-10 radii - 179 worlds
10-13 radii - 83 worlds
13-20 radii - 5 worlds
20-100 radii - 4 worlds
100-200 radii - 2 worlds
200-300 radii - 2 worlds
300-400 radii - 5 worlds
235035 radii - 1 (Neutron star)
All the ones above 13 radii (except for two worlds) were > 0.01 AU radius (5 ls).
From that I'd say 13 radii (or 5 ls) is a good cut-off for flagging Wide Rings (smaller ones are rarely interesting). I'd be curious to see if other folks' distributions are similar - do they get a similar cutoff at 13 radii?
I agree with you. Here is my data.The last column is the ratio of rings width and body radii.
001.ods
drive.google.com
Last edited:
I've apparently forgotten what my own application can and cannot do. Ring radius is not a value that's currently exposed for custom criteria, so apologies for that. The current check cannot be overridden after all.
I'm hoping to have a new release before the end of the year, so I'll get that in then, plus possibly an adjusted built-in check as well.
I'm hoping to have a new release before the end of the year, so I'll get that in then, plus possibly an adjusted built-in check as well.
But it gives us body radius, and you can work out what body radius * ring radius = ls, then ignore every body under a certain radius to give us only rings over a certain radius, or am I understanding the process incorrectly?
Yeah, that can also be done. When I said I was forgetting what couldn't be done I just meant that I forgot that custom criteria can't currently use any specific ring information.
Looks like that problem is happening while trying to read the custom criteria rules. If you disable custom criteria it should stop happening. Judging from the error it might be a regional number formatting issue in the criteria file, the sample rules are all written with "." as the decimal separator, replacing them with "," might also fix it.
If you can confirm that's what is happening I'll work on a fix for next release.
Still doesn't work, I get an error when the earthlike code is included. Might be what's causing Zieman their problems if they're including that.
Yes, that worked.
The 'custom criteria' box was ticked, I don't know why (was it me? probably?), took the tick off & it works now.
Again, you're on the spot!
Replaced the one decimal point in example xml with comma - no more error!
Which is strange, because all the decimal values in my journals have "." as the separator*. Must be some .NET thing reading general Windows regional setting & messing with the code execution?
*excerpt:
"MassEM":0.014207, "Radius":1665974.375000, "SurfaceGravity":2.040193, "SurfaceTemperature":804.936890, "SurfacePressure":0.000000, "Landable":true, "Materials":[
Last edited:
Alright, perfect. I've created an issue on github for this and should have it fixed in next release. Hopefully in time to save anyone else from getting snagged by it.
Will also improve custom criteria error reporting so that it's more obvious when something goes wrong with it.
As for how the box got ticked, on first run it should ask if you want to create a sample criteria file. Your answer to that question determines if custom criteria are enabled or not.
The earthlike check has an "add" operation with only one value. Was probably supposed to be "none".
XML:
<ObservatoryCriteria>
<Criteria Comparator="And">
<Criteria Comparator="Equal" Value="1">
<Operation Operator="None">
<FirstValue Type="EventData">PlanetClass:Earthlike Body</FirstValue>
</Operation>
</Criteria>
<Criteria Comparator="Equal" Value="0">
<Operation Operator="None">
<FirstValue Type="EventData">WasMapped</FirstValue>
</Operation>
</Criteria>
<Description>Unmapped Earthlike</Description>
<Detail>
<Item>DistanceFromArrivalLS</Item>
</Detail>
</Criteria>
</ObservatoryCriteria>@Baxder
I'd say 13 would be a good default, based on those numbers. That way it's looking for things that are fairly notable. I could try to get some more general statistics if that would help.
Oops. Fixed for real now. Sorry about that.
How's this look for detecting a ringed body's moon from which you can see the rings?
<Criteria Comparator="And">
<Criteria Comparator="Greater Than" Value="0">
<Operation Operator="None">
<FirstValue Type="EventData">Parent:Rings</FirstValue>
</Operation>
</Criteria>
<Criteria Comparator="Greater Than" Value="30">
<Operation Operator="None">
<FirstValue Type="EventData">OrbitalInclination</FirstValue>
</Operation>
</Criteria>
<Description>Offset Ring Orbit</Description>
<Detail>
<Item>DistanceFromArrivalLS</Item>
</Detail>
</Criteria>
<Criteria Comparator="Greater Than" Value="0">
<Operation Operator="None">
<FirstValue Type="EventData">Parent:Rings</FirstValue>
</Operation>
</Criteria>
<Criteria Comparator="Greater Than" Value="30">
<Operation Operator="None">
<FirstValue Type="EventData">OrbitalInclination</FirstValue>
</Operation>
</Criteria>
<Description>Offset Ring Orbit</Description>
<Detail>
<Item>DistanceFromArrivalLS</Item>
</Detail>
</Criteria>
You could obviously set the inclination to your taste. 30 is an arbitrary WIP ATM.
EDIT: Doesn't appear to work out of the gate for me, but I may have scanned the child first...
Last edited:
Wow here's a wobbly one, this game can throw some curve balls at you even after years of playing.
I just jumped into this system and got a "close ring proximity" warning for B 1.
I thought, that's really strange, it's not actually orbiting a ringed body, has Elite Observatory broken? Then I had an idea, lets look at the Orrery!
It's actually showing me a "close ring proximity" for the asteroid belt! Amazing.
I flew there to have a look of course. It's moving reasonably fast and has vulcanism so I mapped it but naturally I couldn't see the asteroid belt. Has anyone else encountered this?
This is the entry from EO;
2019-12-11 11:05:25 - Preae Aod JY-Y d1-0 B 1 - Landable - Close ring proximity - Orbit: 1,728,471km, Radius: 6238km, Distance from ring: 32,372km
I just jumped into this system and got a "close ring proximity" warning for B 1.
I thought, that's really strange, it's not actually orbiting a ringed body, has Elite Observatory broken? Then I had an idea, lets look at the Orrery!
It's actually showing me a "close ring proximity" for the asteroid belt! Amazing.
I flew there to have a look of course. It's moving reasonably fast and has vulcanism so I mapped it but naturally I couldn't see the asteroid belt. Has anyone else encountered this?
This is the entry from EO;
2019-12-11 11:05:25 - Preae Aod JY-Y d1-0 B 1 - Landable - Close ring proximity - Orbit: 1,728,471km, Radius: 6238km, Distance from ring: 32,372km
Last edited:
It had not even occurred to me that an asteroid belt would ever trigger a close ring proximity check, that's actually kind of incredible.
I'm not surprised that you can't see any asteroid clusters from the planet, but do you perhaps get a good view of the planet from any clusters?
I'm of two minds as to whether or not I should prevent that check from triggering on asteroid belts. It's probably not every going to be visually interesting, but it does seem noteworthy. Thoughts?
I'm not surprised that you can't see any asteroid clusters from the planet, but do you perhaps get a good view of the planet from any clusters?
I'm of two minds as to whether or not I should prevent that check from triggering on asteroid belts. It's probably not every going to be visually interesting, but it does seem noteworthy. Thoughts?
From my experience it's never going to be annoying because it probably isn't going to happen that often so that's not a reason to remove it, I think that's the first for me, and yes it is noteworthy, so I vote to keep it. Maybe one day we will have an asteroid cluster really close to a planet, that would be interesting and a pity to miss because asteroid belts have been disabled.
Nice idea.
Does not handle old log files very well, and blew up with errors on my 2017 logs (yes, I still have those).
Does not handle old log files very well, and blew up with errors on my 2017 logs (yes, I still have those).
Tool looks nice. I'd love to have the ability to write custom rule to highlight when a body is larger/smaller than a particular size/mass, by body type, as these are useful for finding new galactic limits. Also surface temperature, pressure, and other common characteristics.
I'm curious as to the nature of those errors. I have logs from 2017 as well which work fine. Anything older than April 2017 ("The Commanders" update), is actually ignored due to format differences I couldn't be bothered to support, but everything after that should be okay.
All of those values are available when creating custom criteria already.
https://github.com/Xjph/EliteObservatory/wiki/Custom-Criteria
Here you go:
