Elite Observatory - Search your journal for potentially interesting objects, or notify you of new ones on the fly while exploring!

If it already is in this wonderful tool, then I apologize, but I was not able to find it:

Would any helpful soul be able to write for me a script for Observatory to alert me after Honk, that there are Notable Stellar phenomena found in the system? I know I should study and do it myself, it's just this is not exactly my cup of tea and I don't understand this language... Thank you very much, whoever will be willing to help!

Here is how they should appear in the journal after initial honk (Thanks marx!):

Code:
{ "timestamp":"2019-09-09T00:03:06Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":2, "NonBodyCount":7, "SystemName":"Ovomly HR-D d12-10", "SystemAddress":349997681771 }
{ "timestamp":"2019-09-09T00:03:14Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
{ "timestamp":"2019-09-09T00:03:21Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
 
If it already is in this wonderful tool, then I apologize, but I was not able to find it:

Would any helpful soul be able to write for me a script for Observatory to alert me after Honk, that there are Notable Stellar phenomena found in the system? I know I should study and do it myself, it's just this is not exactly my cup of tea and I don't understand this language... Thank you very much, whoever will be willing to help!

Here is how they should appear in the journal after initial honk (Thanks marx!):

Code:
{ "timestamp":"2019-09-09T00:03:06Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":2, "NonBodyCount":7, "SystemName":"Ovomly HR-D d12-10", "SystemAddress":349997681771 }
{ "timestamp":"2019-09-09T00:03:14Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
{ "timestamp":"2019-09-09T00:03:21Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }

The Elite Observatory works by grabbing the data from the FSS, so when you FSS a NSP then sure the Obervatory could grab it and say it's in the system, but you already know that because you already saw it in the FSS, so it seems pretty pointless to say the least, telling you something you have already seen is there.
 
The Elite Observatory works by grabbing the data from the FSS, so when you FSS a NSP then sure the Obervatory could grab it and say it's in the system, but you already know that because you already saw it in the FSS, so it seems pretty pointless to say the least, telling you something you have already seen is there.

With all due respect, commander, just because it seems pointless for you, does not mean it is pointless for everyone... If you find it pointless, you can just ignore my polite request. I did not twist anyone's arm, I just asked some good soul to help me with that...

But just to explain why I ask this: sometimes I am not exactly exploring, but rather traversing... In this mode, i do not always look into the FSS. I just honk and when there are just couple of bodies and I see on my radar, that most of them are stars, I ignore FSS... And continue towards my destination as quickly as possible...

For these special occasions, I would love Observatory to alert me, that there are NSPs in this system, without me even looking in the FSS... Or it could happen, that I look in the FSS and just do not see it... I sometimes ignore systems, where all I can see is couple of GG and rock bodies and clusters... I could easily miss NSP, just because Im in a hurry to some distant place and don't want to do a detailed scan of every system on my route...

EDIT: And it is my understanding, that Observatory grabs data from Journal, therefore even results of honk should be visible to Observatory, not just data from FSS..
 
But just to explain why I ask this: sometimes I am not exactly exploring, but rather traversing... In this mode, i do not always look into the FSS. I just honk and when there are just couple of bodies and I see on my radar, that most of them are stars, I ignore FSS... And continue towards my destination as quickly as possible...

EDIT: And it is my understanding, that Observatory grabs data from Journal, therefore even results of honk should be visible to Observatory, not just data from FSS..

No, you have to scan with the FSS to get the results, if you ignore the FSS then you will never get a report of NSP's in the system. The honk doesn't show NSP's as what they are, you need to focus on them to actually reveal that, just like you need to focus on a ringed planet to find out if it has wide rings or high gravity. of course if the body is close enough to the star to make it into the passive scan range then you will get details, the same with ringed stars, details of stars are automatically included in the honk, but not NSP's, surface features and other details, so you need to use the FSS to find them, once you have found them and already know they are there the Observatory, if it's set up that way, will tell you they are there, but that's after you already know they are there.
 
No, you have to scan with the FSS to get the results, if you ignore the FSS then you will never get a report of NSP's in the system. The honk doesn't show NSP's as what they are, you need to focus on them to actually reveal that, just like you need to focus on a ringed planet to find out if it has wide rings or high gravity. of course if the body is close enough to the star to make it into the passive scan range then you will get details, the same with ringed stars, details of stars are automatically included in the honk, but not NSP's, surface features and other details, so you need to use the FSS to find them, once you have found them and already know they are there the Observatory, if it's set up that way, will tell you they are there, but that's after you already know they are there.

Well, I admit I'm a newbie with very limited experience... You might be correct and my idea might be pointless and not realistic... But...

I believe marx is not and according to his post, the initial honk puts the necessary info into journal:

{ "timestamp":"2019-09-09T00:03:06Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":2, "NonBodyCount":7, "SystemName":"Ovomly HR-D d12-10", "SystemAddress":349997681771 } { "timestamp":"2019-09-09T00:03:14Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" } { "timestamp":"2019-09-09T00:03:21Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
 
If it already is in this wonderful tool, then I apologize, but I was not able to find it:

Would any helpful soul be able to write for me a script for Observatory to alert me after Honk, that there are Notable Stellar phenomena found in the system? I know I should study and do it myself, it's just this is not exactly my cup of tea and I don't understand this language... Thank you very much, whoever will be willing to help!

Here is how they should appear in the journal after initial honk (Thanks marx!):

Code:
{ "timestamp":"2019-09-09T00:03:06Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":2, "NonBodyCount":7, "SystemName":"Ovomly HR-D d12-10", "SystemAddress":349997681771 }
{ "timestamp":"2019-09-09T00:03:14Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
{ "timestamp":"2019-09-09T00:03:21Z", "event":"FSSSignalDiscovered", "SystemAddress":349997681771, "SignalName":"$Fixed_Event_Life_Cloud;", "SignalName_Localised":"Notable stellar phenomena" }
Unfortunately it's not possible as you describe. While yes, there is NSP data in the journal, it doesn't come from the honk, just look at your timestamps. The NSP events are eight and fifteen seconds after your honk, respectively. Written after you've entered the FSS and found them.

It will absolutely be possible to add a check to Observatory for NSPs, and a pretty simple thing to add while doing the rewrite so I probably will as I can see it being useful as a reminder when doing full journal scans, so you will get a check for those events as requested, but it will not work the way you're hoping.
 
I believe marx is not and according to his post, the initial honk puts the necessary info into journal:
First off, thanks! Second, you might have missed an important detail that was in the post of mine which you quoted from: only NSPs where the containers are Lagrange clouds are written into the journal automatically, NSPs in Rings are only committed there after you've scanned their parent bodies. You can see that the example you quoted is from such: as @Vithigar just wrote, look at the timestamps.
So I suppose you could script Observatory to alert you if NSPs are logged, but you'd only be alerted to the ones in rings after you scanned the parent body in the FSS anyway.

However, if you want a quick and sure way of finding NSPs, as opposed to just the blip on the barcode which can be easy to miss, it's quite simple: look at the left panel. Any NSPs in the system are listed there, at any range, so you can tell how many there are without having to call up the FSS.
 
First off, thanks! Second, you might have missed an important detail that was in the post of mine which you quoted from: only NSPs where the containers are Lagrange clouds are written into the journal automatically, NSPs in Rings are only committed there after you've scanned their parent bodies. You can see that the example you quoted is from such: as @Vithigar just wrote, look at the timestamps.
So I suppose you could script Observatory to alert you if NSPs are logged, but you'd only be alerted to the ones in rings after you scanned the parent body in the FSS anyway.

However, if you want a quick and sure way of finding NSPs, as opposed to just the blip on the barcode which can be easy to miss, it's quite simple: look at the left panel. Any NSPs in the system are listed there, at any range, so you can tell how many there are without having to call up the FSS.

I did not miss it, I was very well aware of that, I read your post several times, i also read @Vithigar response, about it being a good news and definitely doable... Which is why I requested this code from someone more capable than me...

So, if anyone would be willing to write that piece of a code for me, I would be more than grateful... ;)
 
So, if anyone would be willing to write that piece of a code for me, I would be more than grateful... ;)
Just as an FYI, the existing version of Observatory is not going to see any more updates, so that "piece of code" is going to get bundled into the rewrite which is still some time away.
 
Just as an FYI, the existing version of Observatory is not going to see any more updates, so that "piece of code" is going to get bundled into the rewrite which is still some time away.

I guess I was not precisely clear in my request: I was talking about custom criteria. I already collected al I could find in this great thread and placed in my own xml file... I did not ask you to rewrite the program... ;)

As you can see, even writing those custom criteria is quite difficult task for me, as I don't understand the syntax and the operations involved...

But maybe instead of explaining myself here, I should have at least tried...

I guess I can start by using similar criteria that announces an undiscovered system... That also works without having to enter FSS first... I will try to figure it out somehow...
 
Well, it looks like there's another problem: NSPs that spawned in asteroid belt clusters (an extremely rare scenario) aren't logged. At all. Nor do they appear on the FSS barcode, so they are quite bugged. The only way you can tell from journal events that they were there is if you comp. scan their contents, which would appear anyway.
 
I guess I was not precisely clear in my request: I was talking about custom criteria. I already collected al I could find in this great thread and placed in my own xml file... I did not ask you to rewrite the program... ;)

As you can see, even writing those custom criteria is quite difficult task for me, as I don't understand the syntax and the operations involved...

But maybe instead of explaining myself here, I should have at least tried...

I guess I can start by using similar criteria that announces an undiscovered system... That also works without having to enter FSS first... I will try to figure it out somehow...
Oh, that's a simpler answer then. Custom criteria only operate on scan events, there is no way to write one that checks for NSPs.
 
No, you have to scan with the FSS to get the results, if you ignore the FSS then you will never get a report of NSP's in the system. The honk doesn't show NSP's as what they are, you need to focus on them to actually reveal that, just like you need to focus on a ringed planet to find out if it has wide rings or high gravity.
We had this feature back in the day, but fdev decided to ruin it. Now we have to scan the thing to see any kind of detail (other than what type of body it is) . As someone who likes weird and visually interesting stuff, it still p!sses me off that they broke the honker.


Elite Observatory can now use EDMCOverlay to display notifications!
Do i need EDMC running with it too, or the overlay works if i run only Observatory?
 
We had this feature back in the day, but fdev decided to ruin it. Now we have to scan the thing to see any kind of detail (other than what type of body it is) . As someone who likes weird and visually interesting stuff, it still p!sses me off that they broke the honker.
There were no NSPs "back in the day", so I'm not sure you're following the conversation you're replying to. In response to your point though, I'll take the new system (FSS/Probes) any day over the old (ADS/DSS).

Do i need EDMC running with it too, or the overlay works if i run only Observatory?
It's possible to use it without EDMC, but you'll have to manually launch the overlay exe after starting Elite Dangerous I believe.
 
There were no NSPs "back in the day", so I'm not sure you're following the conversation you're replying to. In response to your point though, I'll take the new system (FSS/Probes) any day over the old (ADS/DSS).
yeah, misread a bit. i would switch back to old honker right away if i could. i dont care that scanning planet is faster than flying to it. to me and many other explorers (who are interested in cool stuff, not in money) old system was a godsend - honk, and see the big details (who has what kind of rings and their size, distances, surface, etc) in system map right away. any doubts - click on object and check its holo image. the times you find really cool things, old honker heavily outweighs the time wasted in new system to scan all objects to see if its anything even remotely interesting.
now we have to scan every damn object to even see anything about it. offtopic rant.

It's possible to use it without EDMC, but you'll have to manually launch the overlay exe after starting Elite Dangerous I believe.
Thanks.
 
Last edited:
the times you find really cool things, old honker heavily outweighs the time wasted in new system to scan all objects to see if its anything even remotely interesting.
now we have to scan every damn object to even see anything about it. offtopic rant.

You mean except for that period of time where a number of us spent days on a single planet to find a few volcanic sites and bio sites, the old honker sucked for actually finding stuff, now I am not saying the new system is perfect, there are a few ways I could change it but they would be almost universally hated apart from by me so as was said recently, it is what it is!
 
Bit late to the party here, I know - but just wanted to say how amazing this tool is. Been playing Elite for a while now, but only just discovered this.

Excited to see that a rewrite is under way. This tool has already transformed the exploration experience, I hope that the new version will take it another step further. I am not a programmer, alas, but I do have a logical mind and I am taking CMDR @Heavy Johnson (excellent) custom criteria xml for galactic records and adjusting them to my own personal records (obtained via a csv export from EDDiscovery then sorting the data). I am much more interested in showing I have broken my own records (as that is much more likely than me breaking a galactic record!). I am hoping that it will make doing a FSS scan of every single body in a new system an exciting experience. I hope that this sort of functionality - potentially with CMDRs being able to compare records against each other(?) - might be easier with the new version?

Thank you all for making Elite an even more enjoyable experience than it already was!
 
Last edited:
Bit late to the party here, I know - but just wanted to say how amazing this tool is. Been playing Elite for a while now, but only just discovered this.

Excited to see that a rewrite is under way. This tool has already transformed the exploration experience, I hope that the new version will take it another step further. I am not a programmer, alas, but I do have a logical mind and I am taking CMDR @Heavy Johnson (excellent) custom criteria xml for galactic records and adjusting them to my own personal records (obtained via a csv export from EDDiscovery then sorting the data). I am much more interested in showing I have broken my own records (as that is much more likely than me breaking a galactic record!). I am hoping that it will make doing a FSS scan of every single body in a new system an exciting experience. I hope that this sort of functionality - potentially with CMDRs being able to compare records against each other(?) - might be easier with the new version?

Thank you all for making Elite an even more enjoyable experience than it already was!
Very happy to have your feedback!

For the casual end-user I hope that the new version will, at the very least, make it significantly easier to create custom criteria. Most of the rest of the changes are of greater interest to power users or plugin developers, but ideally that will also spill over to end user utility as well, with plugins to expand the functionality being easy to obtain and install.

Comparing results with other CMDRs is not something I had considered (nor does Observatory currently have any really convenient way to pull out your "record setting" discoveries), but it might be something worth considering. At the moment Observatory is very much an independent utility that pulls no data at all from outside sources and sends very little — in fact it sends nothing at all unless you enable IGAU reporting — so I don't know if implementing a "leaderboard" is something I really want to do in the interest of maintaining that "disconnected" aspect, but who knows? If it's something people want I'm willing to consider it.

For everyone else who happens to be around, an update on the rewrite!

I'll be frank, progress is slow. Though there has been progress! Mid-August as a release window now looks like a ridiculous pipe dream, unfortunately. It's looking like I'm going to have to revise that to end-of-year in order to have any hope at all of meeting it. And yes, that revised window is farther from now than my initial window was from mid-august when I had less work done. My pace is far, far, slower than I initially hoped. Part of this is my own struggling with the current "working from home" situation and the lack of separation between my work life and home life. The last thing I want to do after eight hours of dev work is more dev work without even getting up out of my seat.

Part of it is just me being lazy.

For a more objective idea of progress, the core framework, which is the part which consumes the journal and converts it into .NET objects for consumption by various plugins, is nearing completion. This is the lion's share of the work in some respects, and is by far the most tedious part of the rewrite. Yes, there are tools to automatically convert any given JSON sample into a .NET class. No, they are not suitable for this task as the journal has some... let's call them "data peculiarities", and additionally has undergone a number of changes over the years, so the consumption of historical records requires bespoke conversion methods.
Once the framework is done the biggest task is getting the UI working sensibly. Most of Observatory's logic for what is and isn't interesting can be lifted "whole cloth" from the existing Observatory codebase and should need only minor adjustments to work within the new framework.

On the upside, people seem generally happy with the current version of Elite Observatory and I've received very few bug reports since the last release. (Off the top of my head I think there's been one?) So the current version appears quite stable and is in a good position for "long term support", as it were.

Thanks again everyone for your support!
 
So, this observatory is very nice - is there a list of custom criteria somewhere? I'm assuming people have written there own, is there a list I could perhaps browse through and select the ones I like? I started reading this thread, but - there's 41 pages of it

I have no idea what I'd like to include - just started using it - but I presume there's stuff the author has not included that other people have written up, or is it comprehensive and does not need any amendments?

I just zipped across from the bubble to Beagle Point, and it was extremely useful to have a little voice say "hey! You might want to scan this system!" instead of just ... scanning everything .... and ... hoping.

So, yeah, big fan.
 
Back
Top Bottom