Discussion Journal Documentation for v3.0

[mLine]

They would be extremely unwise to allow untrusted third party apps access to shared memory.

Devs dont have to share the whole memory used by ED. They also can specify readonly shared memory for a couple of data.
This is also used by some other games.

Here a example on my github account for Assetto Corsa:
https://github.com/scrodev/acTelemetry
You can find the class for shared memory reading in the files actelemetry.h and actelemetry.cpp

 

[hchalkley]

[bump] Top post updated to v16, for v3.0.2

 

[Robert Maynard]

[bump] Top post updated to v16, for v3.0.2

Many thanks, Howard!

 

[ansi4713]

Hello,

is it possible to get the influence points (+, ++ ... or low, med and so on) in the MissionComplete event for each involved faction (and if possible the same for some other events like MissionFailed, selling something, redeem something, ...)?
This would be a big help for all who are interessted in BGS work.

Yes, I saw the Trend Value in the MissionComplete event, but it was every time the same value for +, ++ or +++++.

With 2.4 I extracted them from the Mission Accepted event, but with 3.0 this is absolut senseless because the values can change. And it is set to med (++) for all Missions.

Best regards,
ansi4713

 

[Robert Maynard]

While the reduction of the threshold in delta (lat./long.) to trigger republication of status.json when in the SRV is very much welcomed (thanks!), the doubly variable nature of this threshold, in terms of disparity in absolute positional change at any latitude other than 0° and in terms of variation in magnitude of positional change depending on body diameter, is still a bit frustrating.

We know that the game can calculate absolute distance, i.e. distance to selected target, whether or not latitude / longitude / heading / altitude are displayed.

This being the case, it would be preferable if the re-publication of status.json could be triggered by a defined positional change, say SRV = 50m (0.005° delta latitude on an Earth sized body = 55.6m) and for Ships / SLFs, 2km (0.02° delta latitude on an earth sized body = 2,224m).

This would mean that the required distance travelled to trigger re-publication of status.json would be constant (for each vehicle type), regardless of:

1) the size of the body in question, i.e. 1 Arc° of travel on an Earth sized body is 111.2km whereas it is 538.6km on the water giant Outotch DB-O d6-1 AB 4;
2) heading, i.e. the Ship can currently travel, from the equator, at 45°, 135°, 225° or 315° for about 0.028 Arc° before triggering re-publication (0.0007 Arc° for the SRV);
3) the current latitude on that body, i.e. travelling parallel to the equator at higher latitudes currently results in reduced required distance travelled to trigger re-publication; 75% of that at the equator at ±41.41° latitude; 50% of that at the equator at ±60° latitude; 25% of that at the equator at ±75.52° latitude; etc..

Even on Outotch DB-O d6-1 AB 4, the minimum discernible change in position, i.e. 0.000001° of latitude, is 53.9cm so a 50m SRV position change would be at around 0.000093° and a 2km ship position change would be around 0.003714° - both well below the current 0.0005° / 0.02°.

I'd appreciate it if the measurement unit relating to triggering republication of status.json could be reconsidered - due to the inconsistencies raised above regarding the use of dimensionless degrees in setting the threshold for republication of position.

---

Regarding possible additions to status.json, when the vehicle has position, the radius of the body to which the position relates would be a very nice addition to the positional information already supplied.

 

[Toumal]

Alongside the speed, I think having exported the translational and rotational acceleration would help for sim cockpits a lot, kind of FFB, but I'm afraid we are running into having a constant modified file which renders the 'output file' format extremely dangerous for the disk or OS because of the file system constantly smashed.

XPlane shows how this can be done. They offer the option to have the game send UDP packets to a defined IP and port, or write events to a file, or both. So normal players don't suffer from ANY performance issues, and players who want to do physical cockpits can activate whatever they need since they know how to deal with the requirements anyway:

 

[ansi4713]

I start a Featuerequest : https://forums.frontier.co.uk/showt...ormation-for-MissionComplete-and-other-Events

for getting some additional Values in the Player Journal like Influencepoints (+, ++, ...) for the Event MissionComplete (and other).

Please support.

Best regards,
ansi4713

 

[Neotropic]

Is there some sort of data comparison somewhere? A list saying that, for example:
Crimescanner == Kill Warrant Scanner
typex == Chieftan
Cutter == Imperial Cutter
asp = ASP Explorer

Some people, like myself, like to build our own importers for data. Would be nice to have a list if name values to match up to to get their real names. Nice you have it now for Minerals.

 

[gazelle]

I know of two:

• https://github.com/EDSM-NET/Alias
• https://github.com/EDCD/FDevIDs

 

[AnthorNet]

I know of two:

• https://github.com/EDSM-NET/Alias
• https://github.com/EDCD/FDevIDs

I was Indeed linking our repo. It should be complete and working for all version as it is actually one of our used submodules directly on EDSM.

 

[dAlexis]

Please, inform about the latest patches. Changes in 3.0.3\4 requires new document, or v16 is still active? By the way: Waiting for full influence data in MissionCompleted event, because new ++++/+++++ influence is not recorded in log.

 

[hchalkley]

I have updated the top post in the thread with v18 docs for 3.0.4

 

[discocat]

I have updated the top post in the thread with v18 docs for 3.0.4

Thank you sir !

 

[dAlexis]

THANKS!!!

 

[Becky]

Thanks Howard!!

 

[PegasusRider]

I very much thank you for maintaining the .doc. Nevertheless, I have a small request.

When/if time permits:

Would you mind clarifying MassMT (Section 6.2)? Currently it says "ie in megatons" which, in context, I would presume means millions of tons. Still, this can be somewhat ambiguous due to the international variations on the definition of a ton.

If you could specify:

Millions of - "Metric Tons", "Short Tons" or "Long Tons"; or simply numerically define the mass (in kg) of a megaton in the entry description.

I would appreciate the improved accuracy.

 

[Robert Maynard]

Given that the game uses metric units, I strongly suspect that the answer will be that mass is measured in multiples of the metric ton, i.e. the Tonne.

 

[PegasusRider]

Given that the game uses metric units, I strongly suspect that the answer will be that mass is measured in multiples of the metric ton, i.e. the Tonne.

Indeed, but assuming and knowing often miss each other by wide and dissatisfying margin. I'm in no hurry, and if a definitive answer is not forthcoming, I can live with it. I didn't think it would hurt to ask.

 

[VerticalBlank]

I'm pretty sure that's in SI units, like the rest of the game.

 

[LeKeno]

Would it be possible to clarify which values the LegalStatus of the ShipTargeted event can take?

So far I've observed:
- Wanted: player is wanted in this system?
- Clean: player is not wanted in this system?
- WantedEnemy: pledged to an enemy power, power bounty detected??
- Enemy: pledged to an enemy power but no power bounty and no regular bounty detected
- Unknown: seems to be a bug, the player was pledged to an enemy faction and wanted in-game but the player journal entry had "Unknown"

Dissociating between "just a power bounty" vs. "just a regular bounty" or "both" would be quite useful for ED Recon because surfacing a Power Wanted scan is only useful to players pledged to the opposite power, whereas regular bounties are interesting for everybody.

Anyone has other examples? Which value does it take after a KWS scan resulting in a Warrant display in-game? In 3.0.3, It was simply Wanted.


Thanks!