When will we see a proper API implementation, and not this writing to log files nonsense?

While you're at it...what about a LUA allowing us to export the UI screens to separate Touchscreens/mini-monitors...
I'd guess a decent percentage of people with HOTAS set ups have Touchscreens/Lilliputs etc set up for their Flight Sim MFDs...

I know I do... I would love to transfer the RADAR or planetary surface map to one of my external displays.
804iGQE.jpg
 
Cheater's Paradise? Like how? All queries would be related to the current CMDRs data. No data about any other CMDR would be available.
Good job they couldn't change anything by writing to their own ship's current shield values, then... or perhaps the weapon damage values?

The current community of developers, while doing fantastic work, are limited to the data that is sent to them. I'm saying it [the available data] could be a whole lot better, leading to even more apps.
Indeed - and those sorts of apps might not be the type of thing that Frontier want to be possible in their game, especially given the downsides I've described of officially allowing direct memory access to the game client.

Can you see how having easily accessible API would reduce all that fluff?
I can, but I would still argue that the sort of system you are describing is (IMO of course) an edge case which is way on the wrong side of the cost/benefit scale given their limited time and resources.

I do also have to ask again - do you know of any other multiplayer games which officially support direct memory access to their game client in a manner similar to what you're proposing?
I don't know of any... and I'd be interested to know of any that do, if only to see what people did with such access.
 
i'm aware, my worry is not about ssd wear but about needless overhead. verbose logs for diagnostic are fine, constant realtime logging of lots of items which are only useful for third party apps i'm not using is not.

i would be even more concerned if i had elite on my hd, where all my other games are (although i'd say elite logs to the windows drive anyway).

The overhead is utterly miniscule compared to the game itself. The game is 1000 times more active than a tiny little log file.
 
The overhead is utterly miniscule compared to the game itself. The game is 1000 times more active than a tiny little log file.

Agreed... I think my journal logs all the way from 2.2 are a few MB combined; quite possibly less than one (not even 4x res!) screenshot.
 
I don't think this thread is going to get anywhere is it?

Obv. Frontier, having devoted one of their best programmers to the journal API ;-), and spending so much time and money doing it, and working with the community, are not going to drop it or replace it.

Whatever one feels about us 3rd party developers, a lot of people use our tools. EDSM for instance has millions of page hits per month. All of them rely on each other to feed data to each other. EDD has many thousands of users feeding the data network, as does EDMC, Captains Log etc etc etc. Most people have used Corolis or ED Shipyard to look at their loadout? All of these tools are being supported by Frontier now very well.

So they obv. want it to continue.

Can't rep you again so soon, RobbyP.

EDD is an absolute godsend... After the highly effective "Strike" the quality of EDD and indeed all 3rd party tools has just gone through the roof and the quality of the data on EDDN is getting better and better by the month...

I love the plethora of options available to me today and wouldn't have it any other way...

50,000 lines of history in EDD and climbing...
 
Well, as one of the so-called disgraceful developers I can say just this: It is incredible pain to maintain tools for such data-rich game as Elite is without any support and without any way how to get the data. Does anybody remember days, where all the stuff like market prices, star system information, etc. were written by hand or via OCRed screenshots? It was frustrating, tedious "job" and I doubt anybody wanted to do that for a long time. I dare to say that without any Frontier support and without any way how to get data and other stuff 3rd party tools simply cease to exist.

You may say - I don't care, I don't need it. It's a valid point. But, there are many players that simply won't be playing Elite anymore without the 3rd party tools (their words). Not because they want to "cheat", but simply because Elite is too complicated for them otherwise (and it may be caused just by the core game principles, not by the lack of some features in the game). Which, obviously, means less players in the game with all its consequences.

From that point of view it seems very reasonable to me that the game developer will dedicate some resources to support 3rd party developers that cares about the game, about the community and about the players, which may help the game to grow and keep the interest in it. In the end, it may be just beneficiary for everybody, even if they are not using any of the 3rd party tools provided. :)

Hi. On a personal note, thanks to all those peeps who do the external stuff. It's great :)
 

sollisb

Banned
Good job they couldn't change anything by writing to their own ship's current shield values, then... or perhaps the weapon damage values?


Indeed - and those sorts of apps might not be the type of thing that Frontier want to be possible in their game, especially given the downsides I've described of officially allowing direct memory access to the game client.


I can, but I would still argue that the sort of system you are describing is (IMO of course) an edge case which is way on the wrong side of the cost/benefit scale given their limited time and resources.

I do also have to ask again - do you know of any other multiplayer games which officially support direct memory access to their game client in a manner similar to what you're proposing?
I don't know of any... and I'd be interested to know of any that do, if only to see what people did with such access.

FLight Sim 1997 over 2 decades ago. We built our own hardware modules, I l earn basic eletronics, just so I could build an FMS system to interface with the API, and send the flight plan to online ATC. We could see every other online pilot on our screen, and their flight paths and delve deeper into their flight plan etc etc. We could see and watch realtime, weather patterns, airport take offs and landings.

Here we are 2 decades later, reading json files.......
 
FLight Sim 1997 over 2 decades ago. We built our own hardware modules, I l earn basic eletronics, just so I could build an FMS system to interface with the API, and send the flight plan to online ATC. We could see every other online pilot on our screen, and their flight paths and delve deeper into their flight plan etc etc. We could see and watch realtime, weather patterns, airport take offs and landings.

Here we are 2 decades later, reading json files.......

You do have a point there... It definitely feels like regression in some areas. (The Psion palm pc vs pretty much everything after it for example.)

The world is a lot more hostile today than it was back then... I remember when I still used PCs for daily work (and not just as a glorified "XBOX Pro") I never used a virus checker... Today, that would not be a Good Idea ™️.
 

Ozric

Volunteer Moderator
Yes, people did start reverse engineering the companion API without permission, which is somewhat unfortunate. They also asked Frontier at the same time whether use of the CAPI was something they considered acceptable. Frontier then said they were discussing it, and devs continued to ask over time without answer, before finally getting a reply 8 months later saying that use of it was permitted.
I wasn't really part of the developer community at that point, but I do believe that had Frontier ever officially stated its use was disallowed, that the developers would have respected such a request.

More to the point, though... when they removed the companion app from the store, why would they have left the companion API active at all, if not to enable the community to continue to access it?


Well, the developers of both of those tools were among those whose actions (I assume) you're referring to as disgraceful. You're of course welcome to hold that opinion though; it was never exactly going to be a universally popular course of action, and rightly so.


If you look back through this thread, you'll find that all of the established tool developers who have posted in it are generally supportive of the current state of affairs. The journal is excellent, and it continues to get better. In my experience the third-party developers are very respectful of Frontier's wishes regarding what they do and don't want us to do - this is much easier now that they communicate such things more regularly.
It's fair to say that Frontier have really turned a corner in the opinion of most third-party devs (and feel free to look out for a letter soon-ish from EDCD to that effect).

I agree with virtually everything you said there, with the exception of a couple bits of the first section :) I don't believe that EDDiscovery was involved. When I say I use them, they don't run automatically, I use EDDiscovery for my personal records and occasionally I'll upload my travel logs to EDSM. I do unfortunately hold that opinion and it has tainted my view of some, but that is just my opinion. As you say it was never going to be universally popular and I completely understand why then did it when they did it... But I digress, I don't want that to dominate.

It's also very obvious that Frontier were lax at the start but communication was back then, unfortunately you started replying before I added the bit agreeing with you about leaving the API up. But it is now, as you rightly say, so much better. Completely agree about the developers embracing the journal in the way they have, in fact the work that has been done over the last couple of releases by Frontier and them is great to see.

But I will, as you know, stand against APIs :)
 
FLight Sim 1997 over 2 decades ago. We built our own hardware modules, I l earn basic eletronics, just so I could build an FMS system to interface with the API, and send the flight plan to online ATC. We could see every other online pilot on our screen, and their flight paths and delve deeper into their flight plan etc etc. We could see and watch realtime, weather patterns, airport take offs and landings.

Here we are 2 decades later, reading json files.......

Well json wasn't around back then.
 
There are many players that simply won't be playing Elite anymore without the 3rd party tools (their words). Not because they want to "cheat", but simply because Elite is too complicated for them otherwise (and it may be caused just by the core game principles, not by the lack of some features in the game). Which, obviously, means less players in the game with all its consequences.

For me, it's not that the game is too complex, it's that the game is complex enough to make these tools interesting...

EDDN and EDSM are the backbone to an incredibly intricate, interwoven net of apps and services that prove that Elite has some of the BEST FANS IN THE WORLD.

I love the whole idea of searching for the best trade routes on EDDB and finding the richest sources of planetary materials.

I love EDDiscovery keeping tracks on my history and the absolutely EPIC 3D map with over 20 MILLION individually visited systems visible in real time with my course around the galaxy plotted therein.

I love http://inara.cz and seeing my history of mad credit scrambles and slumps. Keeping track of all my ships and their screenshots along with a history of when I unlocked each engineer.

EDEngineer keeps my materials listed and categorised along with my shopping list for engineering...

I love messing around with a current build in http://coriolis.io to see what a bit of engineering could do.

I feel that these tools add a lot of depth and immersion to the game and make me do things that I imagine my intrepid CMDR doing in the real universe.
Elite is richer for having these wonderfully, volunteer supported tools, which is why I have donated more than an entire AAA game's worth to various 3rd party devs over the last three years.

And all of this has been managed with a couple of JSON logs.... Incredible!
 
Last edited:

sollisb

Banned
For me, it's not that the game is too complex, it's that the game is complex enough to make these tools interesting...

EDDN and EDSM are the backbone to an incredibly intricate, interwoven net of apps and services that prove that Elite has some of the BEST FANS IN THE WORLD.

I love the whole idea of searching for the best trade routes on EDDB and finding the richest sources of planetary materials.

I love EDD keeping tracks on my history and the absolutely EPIC 3D map with over 20 MILLION individually visited systems visible in real time with my course around the galaxy plotted therein.

I love INARA and seeing my history of mad credit scrambles and slumps. Keeping track of all my ships and their screenshots along with a history of when I unlocked each engineer.
EDEngineer keeps my materials listed and categorised along with my shopping list for engineering...

I feel that these tools add a lot of depth and immersion to the game and make me do things that I imagine my intrepid CMDR doing in the real universe.
Elite is richer for having these wonderfully, volunteer supported tools, which is why I have donated more than an entire AAA game's worth to various 3rd party devs over the last three years.

And all of this has been managed with a couple of JSON logs.... Incredible!

I agree, and it's a testament to the coders who committed and dedicated their time to develop them.

But.. there is so much more that can be achieved.
 
It would be up to the userbase to create the intermediatery Event manager to bubble events to registered listeners.

Not much difference between that and log files, really. Timing is the only thing that people are concerned about mainly and there's no guarantee that an API would be any faster. In theory it should, I agree, but you don't know for certain until it's tried.

Whilst I would like a better system I'm happy to let FDev concentrate on other, more important things.
 
Best way to do this?! Are you kidding me? Are we back in 1984? This is the worst way to do this! All the information the log files provide should be provided through shared memory.

Writing to log files for 3'rd party apps is not only lazy programming, but incurs unnecessary load on the computer. If they wanted to stick to wring to log files, then at least create a ram disk, and periodically mirror the files to the HDD.



Not sure where you're going with this. Everything has bugs. Even a simple "Hello Word" application can have bugs.

Some people do still want it to be 1984, just read around the forums a while.

Creating RAM disks can be problematic as well, and I'd rather create my own and use it. Oh, wait, I do...

And yes, anything can be buggy. Just look at the current state of the game.

Can we worry about fixing everything that's broken first, then an API that, well, honestly, with the direction things have been moving so far, will probably only end up as redundant again.
 
I'm happy to let FDev concentrate on other, more important things.

This is always the excuse used to let FD twiddle their thumbs while working "on other, more important things." And these more important things never materialize, but more bugs and impotent game play do.

So, how about those wing missions? Multi-crew? CQC? And I love how they expanded the SLF crew roles and responsibilities! We now have a full compliment crew, don't we? And I'm not going to mention space legs. Nope, not going to do it. And atmospheric landings? And last, not least, people! Look at all those people running around stations and planets! Look at all those little guys! They're so busy doing very important things. It makes the game come alive, doesn't it?
 
Last edited:
The overhead is utterly miniscule compared to the game itself. The game is 1000 times more active than a tiny little log file.

beg to ... not differ, but be very skeptical and cautious with this.

for a log file to be of any use in realtime, it needs to be flushed to disk in realtime. it depends on the granularity of the events. if this (http://edcodex.info/?m=doc) info is current, then i see not much problem indeed. however, i've read somewhere (don't remember) about srv coordinates being logged at time intervals. that could get a lot messier.

then again i'm a bit oldschool and used to work in performance critical systems (and i would say a vr game is, to much extent), meaning: anything that isn't absolutely necessary is overhead, and should be optional, period :D
 
Back
Top Bottom