Hunt for trojans

Orbits can "wobble" slightly relative to each other and still qualify as "trojan". The key thing would be the precise orbital period, which we can't see without examining the raw journal files. And the distance discrepancy is caused by the moons being at different distances from the star, not the planet. Which is what you'd expect for trojan moons.

And I'm thinking this one actually is a trojan, because those orbits are linging up almost-perfectly. A "close but no banana" pair of almost-trojans would eventually collide, and the latest tweak to moon orbits in the Stellar Forge added a collision-detection algorithm, which moved potentially-colliding moons out of the way of each other. Given that these two moons are still on intersecting orbits, I'd assume then that they really are trojans.
 
Well, that is hard to say. All the relevant numbers are sligthly off (Argument of Periapsis, orbital inclination, orbital eccentricity). On the other hand are they close enough that I wouldn't rule it out. Than again, the involved masses are really small. So … probably not trojans in the traditional sense, but something interesting is going on here.
 
the latest tweak to moon orbits in the Stellar Forge added a collision-detection algorithm, which moved potentially-colliding moons out of the way of each other.

Do you have a source for this, because I'm not sure it's true. They definitely tweaked certain systems to (supposedly) stop collisions happening - but AFAIK they cannot alter SF to stop these without "other consequences" (happy to be proved wrong though).

Would love to see journal data for these 2 bodies, but they're possibly something we shouldn't shout about too much - lest they get "fixed".
 
Do you have a source for this, because I'm not sure it's true. They definitely tweaked certain systems to (supposedly) stop collisions happening - but AFAIK they cannot alter SF to stop these without "other consequences" (happy to be proved wrong though).
I think the fix was for co-binary planets around a common barycentre. I'm not sure it would necessarily apply to near-trojan pairs.

On the other hand, if this isn't a genuine trojan, the chance of them nevertheless being 60 degrees apart when spotted seems very low - there's a pair of moons in close but not identical orbits at a gas giant near me, and they definitely slowly change the angle between them.
 
Hi, I'm building various detection facilities into the EDMC-Canonn plugin and one of our team requested a Trojan detector.

The plugin downloads system body information from EDSM when you jump into a system. Example Data from EDSM

I rearrange the data a little converting it from an array of bodies to a dictionary keyed on the BodyId

Then as you use the FSS scanner, it parses the journal events and converts them to the same units as EDSM and inserts them into the same data structure.

Each time I add data I can parse the structure and check for interesting things which it displays on the front end

If you could give me a little help with the detection algorithm maybe I could help you out by adding any finds to a google sheet automatically.
 
This is what it shows when you hover over the information icon (or at least will when I release the new version with sheperd moons)

shep.png
 
If you could give me a little help with the detection algorithm maybe I could help you out by adding any finds to a google sheet automatically.
Start reading from here regarding how to detect a subgroup of trojans. A lot of the issues with the data is discussed. I can send you my code (it isn't published). But if you want to build on it, please be aware that I publish everything under the GPL v3.
 
Ok thanks. Not sure that I understand that, but it sounds to me that the problem is with the way you are getting the data from the bodies.json I'm starting with a single system and pretty much complete data or at least complete by the time all the fss are scanned.

Where I have gone with this is to have a function where I pass in the candidate body and the list of all bodies.
Then I loop through all bodies excluding self:
if the candidate body shares the first parent and the various attributes match then they are the on the same orbit.

So far its able to positively identify the systems that you have in your spreadheets I just need a selection of false positives to make sure I'm excluding them.

Do you have any false positives that I can use for testing?
 
OK, here's a false positive:
Col 359 Sector HB-X e1-33 planets 4 and 5
planet 4: period 31.1 days, arg of periapsis 76.94 degrees, eccentricity 0.0000, mass 0.0298 Earth masses
planet 5: period 31.4 days, arg of periapsis 193.93 degrees, eccentricity 0.0001, mass 0.0262 Earth masses
When I passed by this system on my way back to the Bubble recently these two planets stood out. Their orbit lines are very close but about 15 planetary radii apart (both planets are about 2300km radius) and the two planets were very much closer than 60 degrees - more like 3 or 4 degrees apart. I don't know if they had just had a close encounter or were approaching one.

P.S. checked the parent body for my trojan moons above, mass is 3.5100 Earth masses, radius 8733 km, orbital period with its binary companion is 551.6 days.
 
I don't know how old that sheet is you're using, but from the time I checked trojans for Schlowi these systems were false positives:

Phipoea BG-O e6-5896
Dryao Chrea UO-Z c13-4165
Lasou HW-W e1-2325
Phroi Pri SZ-O e6-1329
Eok Bluae PJ-B c16-3195
 
It's late. So just some comments.

If you scan the whole system and do your calculations with that, your data/results will be much better than the average EDSM data. But that is a different scope than what I did and I was very glad that I had the latter to work with.

Do I understand correctly that you want to find non-regular trojan configurations?
With regular trojan configuration I mean e.g. ONE heavy planet and a smaller planet in the same orbit 60 degrees apart. I guess you have figured out the latter.
Non-regular are trojans to a binary planetary system.

Well, there is basically just the distance to arrival you can use to identify the latter, because all the orbital paramters of the planets in the binary configuration belong to the binary system and you won't get any information about the barycenter.

However, the distance to arrival comes with a lot of disadvantages.
Planets around a far away secondary star will have the same value for the distance to arrival. I allowed just for distances below 11 kls to find trojans to binary plantes.
Trojan planets around a (close) secondary star have in general NOT the same distance to arrival since you are not in the center of the circle of their orbit.

For binary systems in which one of the partners is much heavier than the other, it seems to be that the distance to arrival to the heavier partner of the binary is equally large as the distance to the trojan. The distance to the smaller partner of the binary system is different. Basically that means that the larger body acts as the barycenter. BUT this is not exact and does NOT work if the second partner is getting heavier. Because in the latter case the barycenter will be different while the trojan stays a trojan to the barycenter.

I also allow just a very small different in distance to arrival (delta < 0.00001). Otherwise MANY false positives will pop up, due to planets orbiting close to the sun.

What I meant with "order of sequence" is the following. Planet 3 is heavy and in a binary configuration with planet 4. Planet 3 is the barycenter. Now planet 5 is trojan to the barycenter. They have the same distance to arrival. This works well.
Now another scenario: planet 3 and planet 4 are approx. equally heavy. So the distance to arrival to any of them is sligthly off compared to the distance of arrival to planet 5.
In my case I dismissed this case. Since literally thousands of bodies had by chance (du to their position in their respective orbits) almost the same distance to arrival as other planets.
But that is different for your case. You are still in the system after the scan and you can just give out a "warning" so that the user can check it at once.
The only drawback I see could be too many false positives due to moons. That's the reason why I included a check of the mass ratio for non-regular binaries (which moons usually fail).

I hope that helps.
 
Top Bottom