To be honest I would imagine Frontier do not want that sort of thing, for pretty obvious reasons. I am not Frontier though.
Last edited:
When will we see a proper API implementation, and not this writing to log files nonsense?
- Thread starter amadeus1171
- Start date
To be honest I would imagine Frontier do not want that sort of thing, for pretty obvious reasons. I am not Frontier though.
I can think of one, the number of changes planned to the core game this year, which would surely lead to an overhead of maintaining the APIs during a period of substantial change.
They could leave it to the userbase to generate the API? Just like Microsoft did.
i beg a question if someone is so kind to answer. can this log activity be disabled in options? or maybe in the config files? how?
i've read about it logging some realtime info, like srv coordinates and such. i really don't want elite to be constantly thrashing my ssd with logs i won't use.
I don't. But on the other hand I also happen to enjoy the game, so don't mind me.
Firstly, can SSD owners please stop worrying about premature wear due to ED writing a few MB of log data during a gaming session? Current SSDs have endurances whereby you can write 50GB a day to them for a decade. Anything ED can do is a drop in the ocean, and you will have retired your drives and replaced them with larger/faster ones long before SSD wear becomes an issue.
Secondly, yes, an API would be nice, shared memory for avionics data would be even nicer, but it is a lot more work for FD to implement and maintain than just banging strings at a file, and yes, FD are resource bound. hchalkley has the player journal to do and seems to be the expert at the p2p networking, and we wouldn't want bugs in that to go unfixed because he was working on an API. Even file logging has some overhead because he has to filter out stuff we shouldn't see, and transform other stuff into values that make sense for us.
Secondly, yes, an API would be nice, shared memory for avionics data would be even nicer, but it is a lot more work for FD to implement and maintain than just banging strings at a file, and yes, FD are resource bound. hchalkley has the player journal to do and seems to be the expert at the p2p networking, and we wouldn't want bugs in that to go unfixed because he was working on an API. Even file logging has some overhead because he has to filter out stuff we shouldn't see, and transform other stuff into values that make sense for us.
That's quite demanding of you... ;-)
What about us poor sods that are stuck on XBoxs or PS4s? We don't even get a log file to share...
I would rather FDev fixed other platforms first rather than concentrate on giving even more perks to PC users.
Tomorrow, around 4.23pm.
All the data required is already there, all that's needed is to add an API to call the correct queries and return the values.
What about volatile data that arrives as events and is currently not stored in the client after whatever UI notifications are issued and the log written? Then you have to add some object to model those events, and add a buffer to keep recent events available for the API to query.
What about adding a HTTP stack to the client to handle the API requests, and some kind of transform layer to efficiently map the data to the json or whatever your API spits out (I have a feeling, from bugs we've seen, that the current player journal json is hand-generated...). And which game client thread do you assign to handle incoming API requests, and how do you handle performance issues because some punk client naively decides to fetch all the data every 500ms? There will be some i3-2100 4GB player out there with nothing left in their CPU budget. As the API developer, you don't want to have Support breathing down your neck because players are raising tickets for 'microstutter' due to a greedy API client. And then you have to add versioning, otherwise the kids will complain when your next beta comes out and the naively written clients for the production API choke and corrupt their precious databases.
'Adding an API' is work that shouldn't be underestimated. At least throwing bytes at the disk leaves the problem in the hands of the OS kernel.
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
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).
Just my two cents:
In comparison to the situation 3rd party developers were at few years ago, the current situation is much MUCH better! Frontier (Howard, Laurence and other guys possibly involved) are very helpful, listening to any reasonable requests and also implementing them when possible and when it doesn't compromise other stuff. I really cannot say any bad word about current Frontier's standing towards 3rd party developers.
Is there a space for the improvements? Yes, it is, as always even with any other product or company. Are there other approaches for the whole problematic how to provide game data to the 3rd party developers? Yes, they undoubtedly are. But I don't think criticizing work that has been done and that greatly improved access to the game information for the 3rd party developers without additional reasonable rationale is a way to go. I believe that politely and constructively written feedback/request about what will be nice to have, what some thing should provide, why it should be provided and how it will be used will be at least listened and evaluated, if nothing else.
In comparison to the situation 3rd party developers were at few years ago, the current situation is much MUCH better! Frontier (Howard, Laurence and other guys possibly involved) are very helpful, listening to any reasonable requests and also implementing them when possible and when it doesn't compromise other stuff. I really cannot say any bad word about current Frontier's standing towards 3rd party developers.
Is there a space for the improvements? Yes, it is, as always even with any other product or company. Are there other approaches for the whole problematic how to provide game data to the 3rd party developers? Yes, they undoubtedly are. But I don't think criticizing work that has been done and that greatly improved access to the game information for the 3rd party developers without additional reasonable rationale is a way to go. I believe that politely and constructively written feedback/request about what will be nice to have, what some thing should provide, why it should be provided and how it will be used will be at least listened and evaluated, if nothing else.
Just my two cents:
In comparison to the situation 3rd party developers were at few years ago, the current situation is much MUCH better! Frontier (Howard, Laurence and other guys possibly involved) are very helpful, listening to any reasonable requests and also implementing them when possible and when it doesn't compromise other stuff. I really cannot say any bad word about current Frontier's standing towards 3rd party developers.
Is there a space for the improvements? Yes, it is, as always even with any other product or company. Are there other approaches for the whole problematic how to provide game data to the 3rd party developers? Yes, they undoubtedly are. But I don't think criticizing work that has been done and that greatly improved access to the game information for the 3rd party developers without additional reasonable rationale is a way to go. I believe that politely and constructively written feedback/request about what will be nice to have, what some thing should provide, why it should be provided and how it will be used will be at least listened and evaluated, if nothing else.
No citisism from me at all. More a 'it would be nice' but I also understand the 'why they wouldn't'..
No one has mentioned the other problems that an API would create such as coupling. At the moment Elite writes to two files and that’s it. No bothering about applications having to register as listeners for the API event and the un-registering as well. There could be a hundred other app looking at the files and Elite just doesn’t care. One, ten, a thousand and it just doesn’t matter. No additional overhead for Elite either.
So, files is probably the least troublesome way do do this.
Just my opinion, of course.
So, files is probably the least troublesome way do do this.
Just my opinion, of course.
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.
It would be up to the userbase to create the intermediatery Event manager to bubble events to registered listeners.
Just my two cents:
In comparison to the situation 3rd party developers were at few years ago, the current situation is much MUCH better! Frontier (Howard, Laurence and other guys possibly involved) are very helpful, listening to any reasonable requests and also implementing them when possible and when it doesn't compromise other stuff. I really cannot say any bad word about current Frontier's standing towards 3rd party developers.
Is there a space for the improvements? Yes, it is, as always even with any other product or company. Are there other approaches for the whole problematic how to provide game data to the 3rd party developers? Yes, they undoubtedly are. But I don't think criticizing work that has been done and that greatly improved access to the game information for the 3rd party developers without additional reasonable rationale is a way to go. I believe that politely and constructively written feedback/request about what will be nice to have, what some thing should provide, why it should be provided and how it will be used will be at least listened and evaluated, if nothing else.
Hear hear!
A well-deserved +rep duly given.
... and also against the ToS, for pretty good reason.
Yes, quite a reasonable fear factor. Currently their position can be very clear and unambiguous: if you are scraping game memory you are breaking the ToS and could quite reasonably be punished for doing so. If FD were to explicitly allow external applications to read game memory: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
- It's essentially game over from an anti-cheat perspective, as it becomes massively more difficult for them to detect bad actors reading or modifying game memory when anything is allowed to map it in the first place
- Support queries related to third-party apps would become nightmarish as apps try to read memory wrongly, or just memory that's no longer valid, or ...
- It puts additional restrictions on memory locations of objects (since presumably they have to be predictable now...?) which could impact performance and, again, anti-cheat mechanisms
- It massively increases the barrier to entry for new developers wanting to try it out since you need to know how to map memory in another process, and the worst case goes from "I failed to read some JSON" to "I accidentally took out the game client"
I've made other suggestions before such as a local UDP stream, but the current file-based implementation is significantly simpler from an implementation and support perspective - as well as being easier for the casual end user - and Just Works.
Last edited: