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

[amadeus1171]

It's been promised. It was said that it was being worked on. What's the status of the API?

Writing to log files is a stop gap. But it's not an ideal solution; far from it. Not only is unnecessary wear and tear being done to hard drives (poor SSD's), but there is lag between writing to a log file and a 3'rd party app reading from it.

At minimum, what is being provided in log files should be provided through shared memory.

Can a dev (or Sammarco) respond to this, please?

What is the state of the API?

 

[Cmdr Eagleboy]

It's been promised. It was said that it was being worked on. What's the status of the API?

Writing to log files is a stop gap. But it's not an ideal solution; far from it. Not only is unnecessary wear and tear being done to hard drives (poor SSD's), but there is lag between writing to a log file and a 3'rd party app reading from it.

At minimum, what is being provided in log files should be provided through shared memory.

Can a dev (or Sammarco) respond to this, please?

What is the state of the API?

Not sure you are about, Status.json basically has no lag.

Also this is way best way to do this. If you are worried about your SSD, link it to HDD then.

 

[Dommarraa]

Log file a bit buggy, no problems
API thats a bit buggy, no end of problems

 

[amadeus1171]

Not sure you are about, Status.json basically has no lag.

Also this is way best way to do this. If you are worried about your SSD, link it to HDD then.

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.

Log file a bit buggy, no problems
API thats a bit buggy, no end of problems

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

 

[Cmdr Eagleboy]

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.

Shared memory is very specific, very big can of worms for network game like ED.

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.

Please let's not invent issue here. Load is very minimal.

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

bugs in logs are easier to mitigate with existing tool set.

 

[amadeus1171]

Shared memory that only exposes what you want it to expose is not a can of worms. And that's not the only way to provide an API. Ever heard of lua? It's easy to program and easier still to integrate.

Using log files to provide info for 3'rd party programs is lazy programming, period.

And load is load. Why create unnecessary load when it's easy enough to provide information in memory. It's just pure lazyness.

 

[Shadowdancer]

Or just drop the whole "API" nonsense altogether instead of wasting development resources on it.

 

[Watcher]

I personally think some sort of API would be a good thing and allow tighter coupling with external tools but I can absolutely see how that would take some dev time and potentially cause problems.
So, one day, maybe.. Perhaps we'll see some more improved in game tools too, that would be nice.

 

[Stygian]

Or just drop the whole "API" nonsense altogether instead of wasting development resources on it.

You know, that would be a great idea if the community at large didn't feel it needed to resort to all those third party sites and apps to fill in the logical information and interface gaps of the game. if it did, things like EDEngineer, EDDI, EDDB, INARA etc. wouldn't exist in their preset forms or at all.

 

[amadeus1171]

The developers are not children. They can handle both.

It's not difficult to expose a programmatic API. I have already suggested LUA. It's simple to program and simpler still to integrate.

At this point there are zero reasons not to implement a programmatic API. The only reason I can see why they don't is just pure laziness. Or maybe they just don't care about the game anymore.

 

[sollisb]

Not sure you are about, Status.json basically has no lag.

Also this is way best way to do this. If you are worried about your SSD, link it to HDD then.

Seriously! You know absolutely nothing about what is being discussed. And you seem to know even less about what is being asked for. How on God's green earth is reading and writing to a text file, whether it be json or whatever, better than doing a memory read/write?

Please, you're just showing plain ignorance now.

I challenge you to demonstrate a read to a log file being quicker than a memory read. Use any language you like.

 

[sollisb]

The developers are not children. They can handle both.

It's not difficult to expose a programmatic API. I have already suggested LUA. It's simple to program and simpler still to integrate.

At this point there are zero reasons not to implement a programmatic API. The only reason I can see why they don't is just pure laziness. Or maybe they just don't care about the game anymore.

No.. there is a very good reason not. Unless it is very very limited.

If they produced such a thing, we'd have external Auto-Pilots within a week.

 

[jasonbirder]

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...

 

[c00ky1970]

Its a pity that Elite cant create an ingame link thingy so that console players can also contribute and record data of their travels. That way all platforms have a similar investiture in 3rd party apps, or even Frontier have an equivalent respository that could then be data mined by 3rd parties...

 

[xondk]

Shared memory that only exposes what you want it to expose is not a can of worms. And that's not the only way to provide an API. Ever heard of lua? It's easy to program and easier still to integrate.

Using log files to provide info for 3'rd party programs is lazy programming, period.

And load is load. Why create unnecessary load when it's easy enough to provide information in memory. It's just pure lazyness.

Ok, and what would you use to read the api? which would also cause a load of one kind or another.

Using shared memory doesn't really solve the problem you've stated it just moves it, as for writing logs, it actually has benefits over using shared memory, you can read the logs to figure out if anything goes wrong, you can share the logs for other kinds of projects as people are already doing, and yes you can read and parse them with most any kind of program.

why drop the two other advantages logs give?

Rather then lazy it seems more useful in the long term?

Its a pity that Elite cant create an ingame link thingy so that console players can also contribute and record data of their travels. That way all platforms have a similar investiture in 3rd party apps, or even Frontier have an equivalent respository that could then be data mined by 3rd parties...

That's really the console creators limiting that, it would be cool if they basically let you designate a hdd /usb location, heck or network, and then if the game wanted to write a log or similar, it would write it there.

 

[sollisb]

An API would allow instant queries to the game engine. This information would/could, include any information available from all displays, current ship, modules, size etc, flight information; Current x,y,z in space, current bodies sharing space, their x,y,z etc etc

While all this would allow a great amount of cockpit building, I can see the down-sides.

I do know, if that information was available, I'd have an auto-pilot coded and operational within a week and be on the way to SAG*A unaided. Is that what we want ?

 

[bitstorm]

Give 'em an inch....

Nice thing about log files is they persist.

I don't think the load of using log files is that much of a concern to be honest.

What is so time sensitive that the speed of a memory read is needed over a log event read.

Folk get so angry nowadays.

 

[sollisb]

Give 'em an inch....

Nice thing about log files is they persist.

I don't think the load of using log files is that much of a concern to be honest.

What is so time sensitive that the speed of a memory read is needed over a log event read.

Folk get so angry nowadays.

Given memory address locations, queries to ship location in space, and lots of other information would allow for real-time updating of external systems, like displays and switches. Personalized graphical displays would be coded to reflect better situational sensitive information. GPS systems, Auto-Pilots, Flight Management Systems could all be written.

Using log files, does not indicate upto-date, real-time information. So, therefor it is of minimal use and more centric to data parsing with limited lifetime value.

 

[bitstorm]

Given memory address locations, queries to ship location in space, and lots of other information would allow for real-time updating of external systems, like displays and switches. Personalized graphical displays would be coded to reflect better situational sensitive information. GPS systems, Auto-Pilots, Flight Management Systems could all be written.

Using log files, does not indicate upto-date, real-time information. So, therefor it is of minimal use and more centric to data parsing with limited lifetime value.

Avoiding the discussion as to whether Frontier want the api used for flight management systems (aka autopilots).

I assume the idea was to have some sort of event based implementation, in which case apps would persist their own state. Not following what Frontier's plans are for the api though.

 

[sollisb]

Avoiding the discussion as to whether Frontier want the api used for flight management systems (aka autopilots).

I assume the idea was to have some sort of event based implementation, in which case apps would persist their own state. Not following what Frontier's plans are for the api though.

For sure an Event based model is the proper way to go. Data persistance can then be decided on a role specific requirement. Right now all we get is basic info. great for the like of logging and EDEngineer etc, but useless for cockpit and display building. In fact all Fdev have to do is tell us, the memeory address, the rest we can do ourselves.