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

[Esvandiary]

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.

Things like latitude/longitude are indeed now being written, but not into the main journal files - they're written into a separate "status" file which is overwritten rather than added to, so it doesn't end up using tons of disk space. This makes sense for realtime data like that since it's a little less useful to know what you did historically at that level of granularity - and, as you say, would eat disk space like nobody's business!

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

This is definitely a philosophy I can respect.

 

[AnthorNet]

Just wanted to say hi

 

[Clifra Jones]

I think you're over thinking the requirement... Given a set of memory address with the game memory I could query whatever I liked. In fact I still can but the work of figuring them out and knowing they are correct is time consuming.

The queries are already there, they must be to be displaying on various HUDs in the game. All that's needed is to added an object that allows query'ing them, and publishing that object as an API.

There may be a bit of work, but done once, and then leave the userbase to code up whatever they want. The problem I think is the fear factor on the FDev side that maybe someone like me will code somethign they don't want. Be afraid.. be very afraid

As someone who has developed multiple interfaces between disparate business application from disparate vendors is can say, "No he is not overthinking the requirements".

Always remember, if you create it you have to support it!

 

[Clifra Jones]

I want an API that will send data from the ship sensors and stuff to create cockpit type events. The Journal is fine but lacks some functionality. I want real time of shield strength and hull damage as well as heat damage. Right now you just get heat at 100% and 150%. Shield is either up or down. Hull damage at certain %. Would also love the ability to have the target, comm, role, and system panels up on different screens, with ways to control them. Counts on different types of ammo remaining. Right now you only get numbers of ammo when loading the game. So for you to know how many heat sinks are left you have to keep track in your own programs logic and take into account the game logic to keep it accurate. (Yes I know its on the screen as part of the HUD but I want a count right by the switch that fires the heat sink.

Um, look down! Shields at 59%, hull at 79%, look right Shield Cell Banks (1/2). Sure its not "in your face" but it is there.

 

[Clifra Jones]

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.

And JSON logs are the right way to do this not a real time shared memory API. Far to complex! Also, this kind of API puts the console users are an even larger disadvantage. For us we cannot easily get our data into Inara, it has to be dine manually.

For me I would not mind if the logs were copied to one drive space on the XBox when exiting the game or on a times basis. Then I could copy them to a PC and run the tools. But ttat is probably not likely to happen due to MS rules.

 

[sollisb]

As someone who has developed multiple interfaces between disparate business application from disparate vendors is can say, "No he is not overthinking the requirements".

Always remember, if you create it you have to support it!

Well here's a thing, when we interfaced with FLight Sim, MS gave us one DLL, and from that we wrote hundreds of interfaces and control panels and whatever. And no. MS didn;t have to spend time supporting it. We got after each new release.

I really don't know where you're coming from. Disparate systems? FDev aren't expected to be supporting them. All they have to support is the queries which are already there, and publish them. The rest is done by people like me, who take those published queries, use them and disseminate the results in whatever manner we wish.

We as the author of those APIs or panels or whatever have to support them.

It's obvious at this stage that peeps just want to find faults or protect their own little domains. That's fine. I'll carry on, on my own

 

[AnthorNet]

You can't really compare the weight of an API twenty years ago and now.
Trust me as I cover all the cost to run EDDN and EDSM, it not that easy, and it takes a lot of resources to maintain.

Controlling a small JSON file on a desktop computer for a single user is far more easier, and it let the rest to be handled by others.
We have actually a lot covered, with EDDN being open and able to transmit the database to developers who wants.
EDDB has nightly dumps which cover the history, EDSM has dumps too.

EDSM has API for almost every part of the game along classes with all the game data available.

Everything exists already, may be not from Frontier itself, but the work done so far with us is far more than expected, and much appreciated.
And everything we put in place have always been open.

 

[wstephenson]

As someone who has developed multiple interfaces between disparate business application from disparate vendors is can say, "No he is not overthinking the requirements".

Thank you.

 

[Ulaidian]

You can't really compare the weight of an API twenty years ago and now.
Trust me as I cover all the cost to run EDDN and EDSM, it not that easy, and it takes a lot of resources to maintain.

Controlling a small JSON file on a desktop computer for a single user is far more easier, and it let the rest to be handled by others.
We have actually a lot covered, with EDDN being open and able to transmit the database to developers who wants.
EDDB has nightly dumps which cover the history, EDSM has dumps too.

EDSM has API for almost every part of the game along classes with all the game data available.

Everything exists already, may be not from Frontier itself, but the work done so far with us is far more than expected, and much appreciated.
And everything we put in place have always been open.

And it is a brilliant resource.. how to make it better? I use it piggybacking off the PC users info.

 

[ndrwc]

There are two aspects I can think of when discussing why Frontier "won't" provide a realtime API - potential for exploits or abuse, and cross-platform parity (see first point).

A realtime API (like with MS Flight Sim, or Kerbal Space Program), if providing realtime data on ship speed, shield health, weapon power, etc. starts to introduce the potential for automation and analysis of game state in ways that could (at best) provide people using those tools with an advantage over those who weren't, or even (at worst) allow cheating. It would also be yet another thing the PC players would have which the XB1 and PS4 players didn't. For those wanting to build home cockpits a la KSP, you need to remember that even if you only play Solo, Elite Dangerous is at the end of the day an MMO.

In terms of why they "haven't" it's a bit simpler - do they have the developer resources for it? At the current rate of bugs/exploits in 3.0, and the desire to keep producing new content, I'd argue probably not.

A non-realtime API - a web API which officially provided the data that PC players currently get from journals - would be great for the console players, as they're currently only able to access what's available via the companion API. Frontier are unlikely to provided official "character stats" pages at this point (something lots of other MMOs do), simply because the community have already done it.

 

[amadeus1171]

And we still need a proper API. Who cares if people create an autopilot?! Let FD adapt and make the game better. An API would do so much to boost this game.

 

[sollisb]

There are two aspects I can think of when discussing why Frontier "won't" provide a realtime API - potential for exploits or abuse, and cross-platform parity (see first point).

A realtime API (like with MS Flight Sim, or Kerbal Space Program), if providing realtime data on ship speed, shield health, weapon power, etc. starts to introduce the potential for automation and analysis of game state in ways that could (at best) provide people using those tools with an advantage over those who weren't, or even (at worst) allow cheating. It would also be yet another thing the PC players would have which the XB1 and PS4 players didn't. For those wanting to build home cockpits a la KSP, you need to remember that even if you only play Solo, Elite Dangerous is at the end of the day an MMO.

In terms of why they "haven't" it's a bit simpler - do they have the developer resources for it? At the current rate of bugs/exploits in 3.0, and the desire to keep producing new content, I'd argue probably not.

A non-realtime API - a web API which officially provided the data that PC players currently get from journals - would be great for the console players, as they're currently only able to access what's available via the companion API. Frontier are unlikely to provided official "character stats" pages at this point (something lots of other MMOs do), simply because the community have already done it.

Let's be very clear about something here. I can write a full working autopilot and FMS system, that doesn't need a new API. How-ever, it might be illegal. What I'm asking for is that FDev allow and give us the legal means to. Whether Xbox or PS have the ability is not my concern. Those players bought into the console market, that's their choice. I bought into the PC market way back when it was just beginning. That was my choice. I just also happen to have expertise to add to the sim.

 

[Clifra Jones]

Well here's a thing, when we interfaced with FLight Sim, MS gave us one DLL, and from that we wrote hundreds of interfaces and control panels and whatever. And no. MS didn;t have to spend time supporting it. We got after each new release.

I really don't know where you're coming from. Disparate systems? FDev aren't expected to be supporting them. All they have to support is the queries which are already there, and publish them. The rest is done by people like me, who take those published queries, use them and disseminate the results in whatever manner we wish.

We as the author of those APIs or panels or whatever have to support them.

It's obvious at this stage that peeps just want to find faults or protect their own little domains. That's fine. I'll carry on, on my own

You don't fight in MS flight sims. MS Combat Flight Simulator was never a true online game. I can tell you for certain the best WWII combat flight simulator Aces High would never allow this as it very much introduces advantages they would not allow.

RE: support, no the developer has to support the tool. And Open Source developers come and go. But FDEV would have to support the interface, they would have to build that interface. When they make change to the game then that have to update that interface and publish those changes for 3rd party tool devs to reference. THEY have to support you, not the end user of your tool.

And I'll say it again, this kind of thing puts the console users at a very large disadvantage

 

[amadeus1171]

You don't fight in MS flight sims. MS Combat Flight Simulator was never a true online game. I can tell you for certain the best WWII combat flight simulator Aces High would never allow this as it very much introduces advantages they would not allow.

RE: support, no the developer has to support the tool. And Open Source developers come and go. But FDEV would have to support the interface, they would have to build that interface. When they make change to the game then that have to update that interface and publish those changes for 3rd party tool devs to reference. THEY have to support you, not the end user of your tool.

And I'll say it again, this kind of thing puts the console users at a very large disadvantage

As was said, the console users made their bed when they bought the game in console. Further, the console galaxies are separate from the pc galaxy.

Microsoft flight sims are not futuristic space sims set in 3304. It is expected for us to have advanced technology .

FD just has to support the app. If a 3rd party tool breaks because the developer is no longer working on it, then it is up to the user to remove that tool.

If an error occurs in the game, the user would be required to first stop all 3rd party tools and recreate the error. If the error does not recur, then it is up to the user to figure out which 3rd party tool caused the crash.

Using 3rd party tools and support of them is the user's responsibility. Frontier would only be responsible for providing an api to expose a read only interface.

 

[Genar-Hofoen]

As was said, the console users made their bed when they bought the game in console. Further, the console galaxies are separate from the pc galaxy.

Incorrect. PC players, PS4 players, XBox players, and Mac players - all share the one galaxy.

Microsoft flight sims are not futuristic space sims set in 3304. It is expected for us to have advanced technology .

Irrelevant. MS Flight Sim, as was pointed out, is not a competitive multiplayer game. ED is a competitive multiplayer game. You did not address the point.

FD just has to support the app. If a 3rd party tool breaks because the developer is no longer working on it, then it is up to the user to remove that tool.

Frontier already go to great steps in supporting 3rd party apps by way of the player journal and now the new Status.json file. They are in regular contact with us at the EDCD Discord Discord server - why not visit it sometime if you don't already?

 

[jasonbirder]

I can tell you for certain the best WWII combat flight simulator Aces High

That just tells me you know very little about WWII Flight....I think it'd barely be described as a World War 2 Flight Sim at all...it certainly isn't in the same league as DCS WW2, IL2 BoM/BoS/BoK or even Team Fusion Iteration of CLoD...

 

[sollisb]

Irrelevant. MS Flight Sim, as was pointed out, is not a competitive multiplayer game. ED is a competitive multiplayer game. You did not address the point.

How is it irrelevant? Has anyone asked for the ability to automate combat in any way?

Frontier already go to great steps in supporting 3rd party apps by way of the player journal and now the new Status.json file.

Yes, the log files are great, but! Not realtime and in no way offer the same or even close to same as the abilities as a dedicated API would. Stop thinking that everyone is trying to ruin the game. For me personally? All I want is an API to allow me to query things. Never write.

 

[Genar-Hofoen]

How is it irrelevant? Has anyone asked for the ability to automate combat in any way?

You have, basically, and indirectly. It may not be your intention to code up some automated combat bot - you just want to link the game up to your stuff. Unfortunately, any such API you'd be desiring would enable others to code bots.

Yes, the log files are great, but! Not realtime and in no way offer the same or even close to same as the abilities as a dedicated API would.

The lat/lon/heading/altitude figures provided by Status.json when those are available are updated sufficiently enough for me to code a bearing & distance navigation system for my application.

Stop thinking that everyone is trying to ruin the game. For me personally? All I want is an API to allow me to query things. Never write.

Please don't put words into my mouth. It makes it tiresome to try to have some kind of dialogue with you.

It doesn't matter if your intentions for such an API are entirely above board. People who are not you would definitely use such a dream API to write more nefarious code.

 

[sollisb]

You have, basically, and indirectly. It may not be your intention to code up some automated combat bot - you just want to link the game up to your stuff. Unfortunately, any such API you'd be desiring would enable others to code bots.





The lat/lon/heading/altitude figures provided by Status.json when those are available are updated sufficiently enough for me to code a bearing & distance navigation system for my application.




Please don't put words into my mouth. It makes it tiresome to try to have some kind of dialogue with you.

It doesn't matter if your intentions for such an API are entirely above board. People who are not you would definitely use such a dream API to write more nefarious code.

Explain to me how. Give me one example? Asking for information that is already available on the screen, is hardly the end of the world. I agree it is probably difficult to debate with me. But that's because either I'm dense and stupid (likely) or your arguments are without examples to allow me to see the picture?

Just saying it would allow nefarious code is a sweeping statement. So I do, really need to hear an example of how being able to query information already on screen, about my ship only, would help my combat?

 

[Genar-Hofoen]

Explain to me how. Give me one example? Asking for information that is already available on the screen, is hardly the end of the world. I agree it is probably difficult to debate with me. But that's because either I'm dense and stupid (likely) or your arguments are without examples to allow me to see the picture?

Just saying it would allow nefarious code is a sweeping statement. So I do, really need to hear an example of how being able to query information already on screen, about my ship only, would help my combat?

With all due respect - do your own homework.