The second and third aren't possible from the normal FSS scan. Geological site data isn't written to the log. The rest can be done, and I think there already is an example of a high inclination check for moons in this thread somewhere.
I'm at work at the moment, but can help you with these later if you need it.
The second and third aren't possible from the normal FSS scan. Geological site data isn't written to the log. The rest can be done, and I think there already is an example of a high inclination check for moons in this thread somewhere.
I'm at work at the moment, but can help you with these later if you need it.
Again, bio and geo site data is not written to the log by the FSS scan event.
One question about adding custom criteria: I recently added some criteria from the conclusion post to the ObservatoryCriteria.xml. But when I started the Obervatory and it began scanning it closed by itself. What am I doing wrong? :/
One question about adding custom criteria: I recently added some criteria from the conclusion post to the ObservatoryCriteria.xml. But when I started the Obervatory and it began scanning it closed by itself. What am I doing wrong? :/
I would need to see your custom criteria file to say with any certainty, though crashing to desktop with no error is a new one on me. I haven't had any other reports of similar that I can recall.
I'm not sure of your purpose here, but I add the Arrival Distance to the "Detail" section of all the criteria I write so I can see at a glance whether or not it's reasonable to check a thing out. 200k ls is way past my personal limit, but you could do the same to any criteria you end up using.
There is already a criteria for this, indeed, under "Offset Ring Orbit" here. You can adjust the "10" and "-10" to suit.
EDIT: Sorry, I jumped the gun, there. If you're just looking for orbits that differ from ringed bodies equators, then that still applies. Otherwise, removing the check for rings should do the trick...
Edit: Redacted for massive failure and incorrectness.
I'm not sure of your purpose here, but I add the Arrival Distance to the "Detail" section of all the criteria I write so I can see at a glance whether or not it's reasonable to check a thing out. 200k ls is way past my personal limit, but you could do the same to any criteria you end up using.
There is already a criteria for this, indeed, under "Offset Ring Orbit" here. You can adjust the "10" and "-10" to suit.
EDIT: Sorry, I jumped the gun, there. If you're just looking for orbits that differ from ringed bodies equators, then that still applies. Otherwise, removing the check for rings should do the trick...
P.S. I don't know if anyone ever figured out a way to eliminate non-moon bodies from checks like this, so you'll get planetary results with this as well.
Thank you for your time. I still have to figure out why my Observatory closes itself when I put custom criteria into the ObservatoryCriteria.xml. Didn't have the time to test it since I moved back to the standard xml. Will try to do this at the latest in my Christmas holidays.
I did manage to eliminate bodies orbiting primary stars from the Offset Ring Orbit Criteria. That's the second time their "0" Arrival Distance has come in handy...Don't think there's a way to eliminate other stars without eliminating ringed ones as well. I'll try the same method with the High Inclination Orbits and check it against EDSM. I really don't get why that detected primary stars...
OK, this works for detecting High Inclination orbits of Moons of non-stellar bodies only, including nested moons up to 4 levels of nesting; e.g. Body 1 a a a a. I set the numbers to +/- 10 and didn't have any past an "N x a." Even so, that proved the logic. This version has your stated +/-40; adjust to suit.
I tried adding a check for "ReserveLevel" greater than zero to the Offset Ring Orbit, but of course, that eliminated all the stars, which I don't want to do due to things like example #2. I discovered this because I also added the parent body type to the "Detail" section of the criteria, and only planets were listed. I removed the check, and found that stars leave the "Parent" field blank, so it just reads "Parent Distance xxxxxls," instead of "Parent [body type] Distance xxxxxxls. So that's a little helpful, at least, since you can then see if the bodies those moons orbit have wide rings:
13 g (highlighted) has an offset ring orbit of an unnamed body, thus its parent is a star. Body 13 (top) has a wide ring. Bingo. If body 13 had no wide ring, it probably wouldn't have one at all, but a belt. Which made me wonder if there are any stars with actual rings that aren't "wide" per Observatory. I'm pretty sure I've never come across any. Then I wondered how Observatory evaluates "Wide Rings," and what makes it detect stars that have them while not detecting stars with belts. Because I bet that would be the ticket to detecting actual ringed stars; if a body is a star, and does not have a wide ring, it does not have a ring, but a belt. Conversely, only stars with wide rings have rings at all.
Is that really it? Or was it updated? 'Cuz that don't make a bit of sense when we're talking about how stars with "wide rings" are detected and belts aren't. There's no way belts don't meet that criteria.
Is that really it? Or was it updated? 'Cuz that don't make a bit of sense when we're talking about how stars with "wide rings" are detected and belts aren't. There's no way belts don't meet that criteria.
Well, in the two I cite above, the "Wide Ring" is actually over the threshold of 5, and the belt is not, so I'm gonna give it a go. Probably a bad idea.
Of course, we can't "filter out" belts in the XML...?
Running Observatory with the wide ring check resulted in 26 "primary" bodies in offset ring orbits, and the list of bodies orbiting stars took up all but 8 lines on my monitor with Observatory maximized
Running Observatory without the wide ring check resulted in 41 "primary" bodies in offset ring orbits on one page, and the list was another 52 items long, which is about the entire displayed list, meaning only 11 of the visible items weren't orbiting stars.
Seems promising to me. I'm gonna run with this a bit and see what happens. Can I run with both and check the one against the other?...
I tried adding a check for "ReserveLevel" greater than zero to the Offset Ring Orbit, but of course, that eliminated all the stars, which I don't want to do due to things like example #2. I discovered this because I also added the parent body type to the "Detail" section of the criteria, and only planets were listed. I removed the check, and found that stars leave the "Parent" field blank, so it just reads "Parent Distance xxxxxls," instead of "Parent [body type] Distance xxxxxxls. So that's a little helpful, at least, since you can then see if the bodies those moons orbit have wide rings:
13 g (highlighted) has an offset ring orbit of an unnamed body, thus its parent is a star. Body 13 (top) has a wide ring. Bingo. If body 13 had no wide ring, it probably wouldn't have one at all, but a belt. Which made me wonder if there are any stars with actual rings that aren't "wide" per Observatory. I'm pretty sure I've never come across any. Then I wondered how Observatory evaluates "Wide Rings," and what makes it detect stars that have them while not detecting stars with belts. Because I bet that would be the ticket to detecting actual ringed stars; if a body is a star, and does not have a wide ring, it does not have a ring, but a belt. Conversely, only stars with wide rings have rings at all.
What I see how one possibly could distinguish a belt from an actual ring is that under "Ring:[" it says ""Name":"Hyades Sector FB-X c1-18 9 A Ring"" or ""Name":"Hyades Sector ON-S b4-1 A A Belt"". Don't know if you can read this out, but maybe this would be a start.