Release EDDI 3.3 - Bring your cockpit to life

SemlerPDX

SemlerPDX
gpcustoms said:
A very good thread with long shelf life but for me if I said it once I will say it again. If there was an option,..oh lets say in outfitting to clean or customize the interior of the boats I would be all in. I understand that the bumps and scrapes make for a used interior feel but in combination with a new paint scheme and engineering it really would be nice to have that virtual bottle of armor all or clean up so the interior of your pride and joy is as nice on the inside as the exterior. Just saying that you spend a lot of time in there. Should be a pleasure and not give you the feel that you need a virtual tetanus shot getting in and out of the pilots position.
Click to expand...

Are you sure you have the correct thread, brother? These nice guys have nothing to do with the Elite: Dangerous code, models, or in-game appearance. These guys made a 3rd party tool called EDDI to add a layer of functionality over the game. Just FYI

Cheers!

P.S. I like your suggestion, if you find the correct place to suggest it to FD, I'd support it for sure!! My Python has some cables that look dangerous as hell just beside my captain's chair. Only a matter of time before I get electrocuted ;)
 
Last edited:

VerticalBlank

VerticalBlank
Darkcyde said:
The EDDI team have done great work adding the stuff I've made in the past into EDDI, like the monitors (cargo, mission, legal) and now the exploration stuff.
Click to expand...

To clarify for anyone else reading this, and to be fair to my teammates, I want to emphasise that they have done an awful lot more than merely migrating functionality from DC's scripts into the executable!

A vast amount of work has gone into the new monitors and they make things possible that simply weren't beforehand -- such as asking for the nearest Interstellar Factors or solving the "Travelling Salesman Problem" when you have multiple missions stacked.

As always, see the change log for full details.
 

T'kael

T'kael
We're please to announce that EDDI version 3.4.1-rc2 is now available. Full release notes are here. Highlights:
* Fixed a bug that could disable the cargo monitor with translated versions of EDDI.
* Fixed a bug that caused EDSM synchronization to slow to a crawl, and optimized database access. Resynchronizing with EDSM will speed database access and is recommended for all pilots.
* Fixed the character encoding in the French personality file.
* The Body mapped event now makes available all of the same body data as Body scanned.
* Added new event Ring mapped (the Body mapped event will no longer trigger when probing a ring).
* Reinstated ship export to EDShipyard, as its developer has returned.
 

amadeus1171

amadeus1171
T'kael said:
We're please to announce that EDDI version 3.4.1-rc2 is now available. Full release notes are here. Highlights:
* Fixed a bug that could disable the cargo monitor with translated versions of EDDI.
* Fixed a bug that caused EDSM synchronization to slow to a crawl, and optimized database access. Resynchronizing with EDSM will speed database access and is recommended for all pilots.
* Fixed the character encoding in the French personality file.
* The Body mapped event now makes available all of the same body data as Body scanned.
* Added new event Ring mapped (the Body mapped event will no longer trigger when probing a ring).
* Reinstated ship export to EDShipyard, as its developer has returned.
Click to expand...

Something ain't right...

EDDI v.3.4.1-rc2

I click login to Frontier API and the program closes.
 

VerticalBlank

VerticalBlank
We're pleased to announce that EDDI 3.4.1-rc3 is now available from the update server and Github.

This release corrects the misconfiguration of the Frontier API monitor in 3.4.1-rc2.
 

VerticalBlank

VerticalBlank
In future we will soft fail if EDDI is built without the Frontier API configured. (This can happen because FD require us to keep our client ID for it secret, so it can't be checked into GitHub. More details here.)
 

Micha

Micha
VerticalBlank said:
In future we will soft fail if EDDI is built without the Frontier API configured. (This can happen because FD require us to keep our client ID for it secret, so it can't be checked into GitHub. More details here.)
Click to expand...
Hmm, can't seem to comment on the Wiki page directly. A "better" way to do this is to #include your client secret and don't commit that file. Instead, commit a GPG-encrypted version of that file (which can be encrypted to all registered developers of the app). Prior to building, decrypt the file. Since the decrypted version isn't part of the repository, there's no way to accidentally commit it. Also, since the encrypted version -is- part of the repo, there's no way to lose it or use the wrong version if you ever need to change it.

ie:
ClientId.cs:
#include "client_id_eddi.hc"
....

Git commit:
....
ClientId.cs
client_id_eddi.hc.gpg
 

VerticalBlank

VerticalBlank
:pThanks Micha: we have discussed this among us.

We think the EDCD Discord would be a better place for further discussion, but just to conclude this:

Your proposal doesn't quite work for us because we have some open source commitments that require us to ensure that any clone of the repo by J Random Stranger can build and run "out of the box" sans FDev CAPI credentials. Adhering to that gives us free-of-charge use of services such as CrowdIn (for translation) and AppVeyor (for continuous integration).

Hence the approach that we took, which is shared by EDMC, of an error-free build "out of the box" with a null client ID.

Also we have our continuous integration server in AppVeyor to consider: it can't have access to the secret client ID either.

Suffice to say:
1. The vanilla build will in future "soft fail" if the client ID is null, with appropriate UI.
2. Devs will get a build-time warning if the client ID is null, via a unit test in a category that is excluded from AppVeyor.

We feel that this is a better approach than excessively complicating the build process with GPG etc.

Oh and there ain't no #include statement in C#, I'm very glad to say. The preprocessor was the purest possible manifestation of evil and I am glad to see all modern languages eschew it.
 
Last edited:

Technomancer

Technomancer
Phadebas said:
Hi Guys,

Absolutely love EDDI, so thank you for all the work the developers/contributors have put into it.

Can anyone else confirm that the ((EDDI docked)) event does not trigger when departing from a station then immediately making a docking request and returning to the same station (without entering supercruise)?

I am using the latest version of EDDI: 3.4.0.
Take off and landing via the automated docking computer.

Event appears to trigger correctly when docking at a station for the first time, or after entering supercruise and then returning.
Click to expand...

Late to the party here, since I haven't played ED in a couple of months, but, yeah, confirmed.
 

Hoodathunk

H
Technomancer said:
Late to the party here, since I haven't played ED in a couple of months, but, yeah, confirmed.
Click to expand...
This was intentional, due to requests to the original author by mission stackers not wanting to hear the 'Docked' notification each time they logged off and back on. You needed to jump/supercruise to reset the 'current station'.

Due to the new FDEV mission servers, it no longer made sense to keep this and it's been removed in 3.4.1. We're satisfied with the stability of the release candidates and the Final will likely be released today.
 

Hoodathunk

H
Please note that in 3.4.1, we've added Landed and Docked 'states' to the Cottle and VA environment variable, in addition to the previously existing Normal space, Supercruise and Witch space states. Also note that these states follow the ship, not the Commander. For example, when in your SRV and the ship has been dismissed, the environment state will change from Landed to Normal space. The Commander always follows the vehicle variable state.
 
Last edited:
You must log in or register to reply here.
Top Bottom