Release EDDI 3.3 - Bring your cockpit to life

gazelle

gazelle
nepomuk said:
@T'kael and @VerticalBlank
I found out that the FIDs of FD on the user info page (https://user.frontierstore.net/user/info) and the FID in both log files (ELITE and EDDI) are different.
The FID in the log files of ELITE and EDDI is the same. Perhaps this is the problem. For whatever reason. I have informed FD support.
Click to expand...
The displayed Frontier ID of that site is something different. Search the source code of that site and look for customer_id (it's a hidden field).
 

nepomuk

nepomuk
gazelle said:
The displayed Frontier ID of that site is something different. Search the source code of that site and look for customer_id (it's a hidden field).
Click to expand...
Hallo @gazelle , vielen Dank für deine Hilfe. Der FD-Support hatte mir heute geantwortet und das gleiche gesagt. Naja man sucht halt nach möglichen Ursachen und wenn man von der Materie zu wenig versteht (wie ich), dann kommen eben solche falschen Schlussfolgerungen zustande. Es hilft nichts die beiden CMDR T'kael und VerticalBlank müssen sich das ansehen. Was mich eben nur wundert, bei mir hat sich nichts verändert und auf einmal geht das nicht mehr (ist ja jetzt auch nicht lebenswichtig, Spiel läuft ja).

Translation:
Hello Gazelle, thank you very much for your help. FD support replied to me today and said the same thing. Well, you just look for possible causes and if you don't understand enough about the matter (like me), then you come to such wrong conclusions. It doesn't help that both CMDR T'kael and VerticalBlank have to look into it. The only thing that surprises me is that nothing has changed for me and suddenly it doesn't work any more (it's not vital now, the game is running).

Translated with DeepL.com (free version)
 

T'kael

T'kael
nepomuk said:
I have a problem with the API.
How can I check whether the API connection to Frontier is really established or not? The value of "capi" is "false" but the authorization for the account is OK.
View attachment 387175
Click to expand...

The image in the spoiler seems to be reporting on the applications that have been granted permission to view your Frontier API data rather than on the current authorization state of those applications.

Authorization tokens can expire if not regularly renewed with the Frontier API server and I suspect that is what has happened in this case. A verbose log might show this (if you would like to share your verbose log, it would be preferable to message me the file rather than sharing it publicly).
 
Last edited:

nepomuk

nepomuk
Hi @T'kael, thanks for taking care of this. I'll send you the file via PN, no problem. Have you read everything? I have answered FD's authorisation request several times. Until 18 March (inclusive) it always worked. From 19 March onwards it no longer worked. Nothing had changed for me. You must have looked at the contents of both CompanionAPI.json files, right ? I have reinstalled EDDI 4.0.3 (EPIC account connected to FD) and I have tested it with my second CMDR (FD account). No API connection is established with either installation. I have also deauthorised with FD and reauthorised again. Did not help. PN to you is out. ...

Code: 
{
  "accessToken": null,
  "refreshToken": null,
  "tokenExpiry": "0001-01-01T00:00:00"
}

Translated with DeepL.com (free version)
 

Attachments

  • eddi.zip
    109.2 KB · Views: 102

T'kael

T'kael
nepomuk said:
Hi @T'kael, thanks for taking care of this. I'll send you the file via PN, no problem. Have you read everything? I have answered FD's authorisation request several times. Until 18 March (inclusive) it always worked. From 19 March onwards it no longer worked. Nothing had changed for me. You must have looked at the contents of both CompanionAPI.json files, right ? I have reinstalled EDDI 4.0.3 (EPIC account connected to FD) and I have tested it with my second CMDR (FD account). No API connection is established with either installation. I have also deauthorised with FD and reauthorised again. Did not help. PN to you is out. ...

Code: 
{
  "accessToken": null,
  "refreshToken": null,
  "tokenExpiry": "0001-01-01T00:00:00"
}

Translated with DeepL.com (free version)
Click to expand...
Thanks. From what I'm seeing so far EDDI is behaving as if the information is either not being saved or is being overwritten when it shouldn't. I've sent you a follow-up message privately to try to narrow in on the precise issue.
 

nepomuk

nepomuk
Pics for @T'kael:
1711270395428.png


1711270481423.png

Code: 
{
  "accessToken": null,
  "refreshToken": null,
  "tokenExpiry": "0001-01-01T00:00:00"
}
 
Last edited:

nepomuk

nepomuk
So, brief feedback on my problems with EDDI and VA. Everything is working again :giggle:. It was, in my opinion, all a rights problem.
Why this problem only came to light now, I have no idea. Nothing had changed in my installation. I uninstalled everything again
and installed everything in the user path. Now the API works immediately and the window position remains the same.
I would like to know what has changed. But well, I probably won't find out. :rolleyes:

Big thanks to @T'kael and @Darkcyde for your patience with me. 🍻

Translated with DeepL.com (free version)
 

Darkcyde

Darkcyde
T'kael said:
🎆 I am pleased to announce that EDDI version 4.0.4-b1 is now available. The changelog is available at https://github.com/EDCD/EDDI/releases/tag/Release/4.0.4-b1 and the installer is available from the app or from https://github.com/EDCD/EDDI/releases/download/Release/4.0.4-b1/EDDI-4.0.4-b1.exe. 🥂
Click to expand...
Thank you! 😊

I've been working on getting a new release of my personality out, but it's been delayed by some unexpected bugs I found. I'll have to look over the new change log and see what I can update my personality with. 👍
 

Darkcyde

Darkcyde
@T'kael I've been having a little trouble with the new Play() relative paths. Unfortunately, the help doesn't specify how to use them, but after some trial and error, I have figured it out now. Still, I'd like to ask if the below is intended behaviour...

I tried using %AppData%\\Roaming\\EDDI\\Sounds\\Kills\\God-like.wav to use the AppData variable as this is where my sounds are kept, and my first guess was that AppData could be used as a relative path. However, EDDI reports that it can't be found, and proceeds to give a long path that's just not right, like this:
C:\\Users\\%USERNAME%\\AppData\\Roaming\\EDDI\\%AppData%\\Roaming\\EDDI\\Sounds\\Kills\\God-like.wav
(See attached log for the full error)

If I just try \\Sounds\\Kills\\God-like.wav then EDDI tries to use C:\\Sounds\\Kills\\God-like.wav

Is this how it's supposed to work, or am I missing something?

After a bit more testing, I found that the 'relative path' seems to refer to the EDDI install folder. So to get it to work, I needed to just use Sounds\\Kills\\God-like.wav. Could the help be updated to clarify the relative path usage please?

I've only started to look over the changes, but what I've seen so far is pretty good. So thank you for another great release, even if it is beta! 👍 😊
 

Attachments

  • eddi.log
    6.9 KB · Views: 70

T'kael

T'kael
Darkcyde said:
@T'kael I've been having a little trouble with the new Play() relative paths. Unfortunately, the help doesn't specify how to use them, but after some trial and error, I have figured it out now. Still, I'd like to ask if the below is intended behaviour...

I tried using %AppData%\\Roaming\\EDDI\\Sounds\\Kills\\God-like.wav to use the AppData variable as this is where my sounds are kept, and my first guess was that AppData could be used as a relative path. However, EDDI reports that it can't be found, and proceeds to give a long path that's just not right, like this:
C:\\Users\\%USERNAME%\\AppData\\Roaming\\EDDI\\%AppData%\\Roaming\\EDDI\\Sounds\\Kills\\God-like.wav
(See attached log for the full error)

If I just try \\Sounds\\Kills\\God-like.wav then EDDI tries to use C:\\Sounds\\Kills\\God-like.wav

Is this how it's supposed to work, or am I missing something?

After a bit more testing, I found that the 'relative path' seems to refer to the EDDI install folder. So to get it to work, I needed to just use Sounds\\Kills\\God-like.wav. Could the help be updated to clarify the relative path usage please?

I've only started to look over the changes, but what I've seen so far is pretty good. So thank you for another great release, even if it is beta! 👍 😊
Click to expand...
Relative paths are relative to the %AppData%\EDDI working directory and do require a properly formed relative path.

Essentially:
  • A relative path starting with \ indicates to construct a path relative to the root (C:) of the current working directory.
  • A relative path starting with .\ indicates to construct a path relative to the current working directory` and is equivalent to a path without a leading .\
  • A relative path starting with ..\ indicates to construct a path relative to the parent of the current working directory
  • A relative path starting with ..\..\ indicates to construct a path relative to the grandparent of the current working directory
etc.

In your case, taking into account the need to escape \, either of the two paths below should be equally valid:
Code: 
{Play('.\\Sounds\\Kills\\God-like.wav', true, 100)}
{Play('Sounds\\Kills\\God-like.wav', true, 100)}

Please note that the behavior you are observing exactly matches the behavior you would see in the command prompt when using a relative path. If you type cd %appdata%\EDDI then either cd .\Sounds\Kills\ or cd Sounds\Kills\ then you'll open the %appdata%\EDDI\Sounds\Kills folder but if you instead type cd \Sounds\Kills then the system will probably indicate that no such path exists. If you create C:\Sounds\Kills\ then the command prompt will open to that location.
 
Last edited:

Darkcyde

Darkcyde
T'kael said:
Relative paths are relative to the %AppData%\EDDI working directory and do require a properly formed relative path.

Essentially:
  • A relative path starting with \ indicates to construct a path relative to the root (C:) of the current working directory.
  • A relative path starting with .\ indicates to construct a path relative to the current working directory` and is equivalent to a path without a leading .\
  • A relative path starting with ..\ indicates to construct a path relative to the parent of the current working directory
  • A relative path starting with ..\..\ indicates to construct a path relative to the grandparent of the current working directory
etc.

In your case, taking into account the need to escape \, either of the two paths below should be equally valid:
Code: 
{Play('.\\Sounds\\Kills\\God-like.wav', true, 100)}
{Play('Sounds\\Kills\\God-like.wav', true, 100)}

Please note that the behavior you are observing exactly matches the behavior you would see in the command prompt when using a relative path. If you type cd %appdata%\EDDI then either cd .\Sounds\Kills\ or cd Sounds\Kills\ then you'll open the %appdata%\EDDI\Sounds\Kills folder but if you instead type cd \Sounds\Kills then the system will probably indicate that no such path exists. If you create C:\Sounds\Kills\ then the command prompt will open to that location.
Click to expand...
Ahh, OK, I see. I kinda figured that was the case, I just got confused over the use of %AppData%. I thought I would be able to use that as a shortcut to files within the AppData folder, but I see now that it doesn't work like that.

Thank you for the full explanation! 👍 😊
 

Darkcyde

Darkcyde
@T'kael - Just a quick one. I've found a typo in the updated 'Ship targeted' script. For line:
{if environment = "Normal space" || hasInterdictor:
The S in space needs to be a capital letter to work, so
{if environment = "Normal Space" || hasInterdictor:

I know it used to be lower case, and the variable help still says it is, so I assume this is an undocumented/unintentional update in 4.0.4-b1. I didn't think this was big enough to warrant a GitHub report, but I can if you need me to. 🙂

EDIT: I found another. 'Entered normal space' line 14: {OneOf('entered', 'returned to', 'dropped to')} normal space")} has ")} at the end.
It causes this error:
There is a problem with the script "Entered normal space" at line 34. expected end of file, found closing curly bracket
Looks like it's left over from previous code, as my current (older) version looks like this:
{OneOf("left supercruise", "{OneOf('entered', 'returned to', 'dropped to')} normal space")}
 
Last edited:

GJ51

GJ51
Darkcyde said:
@T'kael - Just a quick one. I've found a typo in the updated 'Ship targeted' script. For line:
{if environment = "Normal space" || hasInterdictor:
The S in space needs to be a capital letter to work, so
{if environment = "Normal Space" || hasInterdictor:

I know it used to be lower case, and the variable help still says it is, so I assume this is an undocumented/unintentional update in 4.0.4-b1. I didn't think this was big enough to warrant a GitHub report, but I can if you need me to. 🙂

EDIT: I found another. 'Entered normal space' line 14: {OneOf('entered', 'returned to', 'dropped to')} normal space")} has ")} at the end.
It causes this error:
There is a problem with the script "Entered normal space" at line 34. expected end of file, found closing curly bracket
Looks like it's left over from previous code, as my current (older) version looks like this:
{OneOf("left supercruise", "{OneOf('entered', 'returned to', 'dropped to')} normal space")}
Click to expand...

From my log:

2024-06-11T22:39:45 [Warning] ScriptResolver:resolveFromValue Failed to resolve the script "Entered normal space" at line 34. Cottle.Exceptions.ParseException: expected 'end of file', found '}'

Also reported on Discord
 

T'kael

T'kael
Darkcyde said:
@T'kael - Just a quick one. I've found a typo in the updated 'Ship targeted' script. For line:
{if environment = "Normal space" || hasInterdictor:
The S in space needs to be a capital letter to work, so
{if environment = "Normal Space" || hasInterdictor:

I know it used to be lower case, and the variable help still says it is, so I assume this is an undocumented/unintentional update in 4.0.4-b1. I didn't think this was big enough to warrant a GitHub report, but I can if you need me to. 🙂

EDIT: I found another. 'Entered normal space' line 14: {OneOf('entered', 'returned to', 'dropped to')} normal space")} has ")} at the end.
It causes this error:
There is a problem with the script "Entered normal space" at line 34. expected end of file, found closing curly bracket
Looks like it's left over from previous code, as my current (older) version looks like this:
{OneOf("left supercruise", "{OneOf('entered', 'returned to', 'dropped to')} normal space")}
Click to expand...

GJ51 said:
From my log:

2024-06-11T22:39:45 [Warning] ScriptResolver:resolveFromValue Failed to resolve the script "Entered normal space" at line 34. Cottle.Exceptions.ParseException: expected 'end of file', found '}'

Also reported on Discord
Click to expand...
Noted. Thank you for the reports. :)
 

Saltyseadog

Saltyseadog
I bought one of the new Python MKII at Explorers Anchorage while reaching SAG* recently. Since installing EDDI v4.0.4-b2 on entering a new system EDDI is telling me various versions of Python MKII is low on or has no fuel. Of course I have plenty of fuel and my fuel scoop is working fine so obviously some sort of bug. At first I thought it was a bug in the Python but it is definitely EDDI as it doesn't happen when I use any of my other ships?. Not a big problem really, just thought I would let you know.
 
You must log in or register to reply here.
Back
Top Bottom