Release EDDI 3.3 - Bring your cockpit to life

Indeed, busy working on how to get the target subsystem working in VA.
Oohh, saying that, I have just finished a target subsystem function that uses VA and EDDI. I've not made it work by voice (asking to target a particular system), but to automatically target a subsystem that you set as a variable in the EDDI script. When you target a wanted ship, it will auto scan through the subsystems until it reaches the one you've set.

I had considered making it work by voice, but in my setup in my house, voice isn't usually an option (too noisy, and I don't like barking orders when others can hear me).
 
EDDI 3.7.3 is now a mandatory update, meaning that all earlier versions will go into safe mode. This is to prevent accidental uploading of alpha data to live endpoints.
 
Hmm, OK, but then why did the OP say they have to disable many each time they upgrade? 🤔

By this, I had assumed that they were all being re-enabled each time they upgraded. 🤷‍♂️ If they're not, then please ignore my suggestion above. :confused:
Maybe I am confuserated about this ???

If I was to go to GITHUB and "Report an Issue", I was under the impression that I needed to test while running the default EDDI profile/personality, Yes / No ?

Therefore, upon each EDDI update, I would create a COPY of your NEW default profile/personality, save as (e.g.) "v373.json", then just disable all the events I did not want. And that way I would be sure that the profile/personality code running was in fact the very latest version.

Or am I wrong? Perhaps there is no need for me to do that each time a new EDDI version is released?
 
Last edited:
Maybe I am confuserated about this ???

If I was to go to GITHUB and "Report an Issue", I was under the impression that I needed to test while running the default EDDI profile/personality, Yes / No ?

Therefore, upon each EDDI update, I would create a COPY of your NEW default profile/personality, save as (e.g.) "v373.json", then just disable all the events I did not want. And that way I would be sure that the profile/personality code running was in fact the very latest version.

Or am I wrong? Perhaps there is no need for me to do that each time a new EDDI version is released?
Ahh, I see. Well, as far as I'm aware, if you make a copy of the default, each script will still be upgraded when you upgrade to a new version of EDDI, unless you make any changes to the code of a script. Any that are still 'default' will be upgraded, any you make changes to won't.

So, if you are not making any code changes to anything, and are ONLY disabling all those scripts, then no, you don't need to do that for each EDDI version.

If I'm mistaken about this, then I'll be happy to be corrected.
 
Maybe I am confuserated about this ???

If I was to go to GITHUB and "Report an Issue", I was under the impression that I needed to test while running the default EDDI profile/personality, Yes / No ?

Therefore, upon each EDDI update, I would create a COPY of your NEW default profile/personality, save as (e.g.) "v373.json", then just disable all the events I did not want. And that way I would be sure that the profile/personality code running was in fact the very latest version.

Or am I wrong? Perhaps there is no need for me to do that each time a new EDDI version is released?
All I did was ...

1. Install EDDI
2. Copy the Personality
3. Disable the scripts I didn't want (which is a PITA a untick all option would be nice) leaving the 3 or 4 I do want active
4. When ever an update comes along just install it and the personality is not touched as in nothing is re-enabled that I don't want.
 
Au contraire, it means that a faithful translation of the default personality will give that language's users the best possible starting point.
Sure! That was the first thing i've done.
I've also tried to build a "word by word" translation in italian to be put in github..... problem is keeping it alive (i mean, updated):

Ahh, I see. Well, as far as I'm aware, if you make a copy of the default, each script will still be upgraded when you upgrade to a new version of EDDI, unless you make any changes to the code of a script. Any that are still 'default' will be upgraded, any you make changes to won't.
This is one of the reasons: it's impossible to keep the original code. Just the way to build a plural requires to delete part of the original code (which often just add a "s") and writing whole new code.
The easiest way would be writing a subscript called (as example) "pluralize" and manage there (once) all the intricacy of my language (general rules based on how a word ends, and all the exceptions -limited to game words- as a lookup table) but i've read somewhere that new scripts will make personality updates harder, so are not encouraged (in the github .it personality).
Another helpful way could be a TAG in the script that encloses the "updatable" code and separates it from the "localization-specific" code, and do some automation that updates just what is inside it, but at the moment not all the original scripts are build with a strong separation between the "data logic" and the "spoken logic", which also has been told me that is what is desired, as it shows to the end user more than one style to write a script.

So, i absolutely agree with you about how the original personality encourage me to do my own personality (this is REALLY the first thing i've done), but i stand to my point saying that, once i've worked on it, i don't want to seek each script line by line to look at what changed in each new release.

DISCLAIMER:
as my english is what it is, i always fear how it sounds, so let me say that i'm not "bashing down" how EDDI it is - au contraire ;) i think it is a great program! - but just discussing its intricacies as a passionate user
 
If I was to go to GITHUB and "Report an Issue", I was under the impression that I needed to test while running the default EDDI profile/personality, Yes / No ?
No, but if the issue doesn't occur with the default personality then that may be useful information to help diagnose a scripting issue.
 
Sure! That was the first thing i've done.
I've also tried to build a "word by word" translation in italian to be put in github..... problem is keeping it alive (i mean, updated):


This is one of the reasons: it's impossible to keep the original code. Just the way to build a plural requires to delete part of the original code (which often just add a "s") and writing whole new code.
The easiest way would be writing a subscript called (as example) "pluralize" and manage there (once) all the intricacy of my language (general rules based on how a word ends, and all the exceptions -limited to game words- as a lookup table) but i've read somewhere that new scripts will make personality updates harder, so are not encouraged (in the github .it personality).
Another helpful way could be a TAG in the script that encloses the "updatable" code and separates it from the "localization-specific" code, and do some automation that updates just what is inside it, but at the moment not all the original scripts are build with a strong separation between the "data logic" and the "spoken logic", which also has been told me that is what is desired, as it shows to the end user more than one style to write a script.

So, i absolutely agree with you about how the original personality encourage me to do my own personality (this is REALLY the first thing i've done), but i stand to my point saying that, once i've worked on it, i don't want to seek each script line by line to look at what changed in each new release.

DISCLAIMER:
as my english is what it is, i always fear how it sounds, so let me say that i'm not "bashing down" how EDDI it is - au contraire ;) i think it is a great program! - but just discussing its intricacies as a passionate user
We can certainly acknowledge that keeping translated scripts up-to-date is a challenge. And while we'd prefer that translated scripts were 1:1 with the English scripts, we recognize that you may need to write a helper function or two. If that's the case then please do so. We'll simply have to find a way to handle that scenario more gracefully.

Smart automatic updating for translated scripts is a minefield where we'd be much more likely to get it wrong than to get it right. As nice as it would be I'm not sure that I see a path to making it work.
 
Smart automatic updating for translated scripts is a minefield where we'd be much more likely to get it wrong than to get it right. As nice as it would be I'm not sure that I see a path to making it work.
Very true. What I do still hope to do is re-work how EDDI stores script personalities on disk, so that each script is its own file. This will make it dramatically easier to track changes, and, if done right, will permit the scripts to reside on CrowdIn. <https://github.com/EDCD/EDDI/issues/523>
 
Sure! That was the first thing i've done.
I've also tried to build a "word by word" translation in italian to be put in github..... problem is keeping it alive (i mean, updated):


This is one of the reasons: it's impossible to keep the original code. Just the way to build a plural requires ...

As a student of French, German, Italian and lately Russian, I'm well aware of the issues:
<https://upload.wikimedia.org/wikipe...hoods_programmers_believe_about_languages.pdf> is a good summary.

I think that breaking up the personalities into one file per script will at least make change tracking much less painful. Perhaps I should prioritise that.
 
Last edited:
  1. There's any utility (either downloadable or online, even a patched-up-pre-alpha-for-my-eyes-only version used by a single EDDI's dev) that can export/import just the script part from the json files so i can save all the scripts in a single "text" file?
  2. I'm sure we've already talked about this, but i can't find that info: how we "pass" variables between scripts? If i remember well, it was by setting global variables members but can someone refresh my memory? :)
  3. What would be the easyest way to obtain all the keywords/functions to build a specific EDDI syntax highlighter? (in my case, for SublimeText)
 
  1. There's any utility (either downloadable or online, even a patched-up-pre-alpha-for-my-eyes-only version used by a single EDDI's dev) that can export/import just the script part from the json files so i can save all the scripts in a single "text" file?
  2. I'm sure we've already talked about this, but i can't find that info: how we "pass" variables between scripts? If i remember well, it was by setting global variables members but can someone refresh my memory? :)
  3. What would be the easyest way to obtain all the keywords/functions to build a specific EDDI syntax highlighter? (in my case, for SublimeText)
Not sure about number 1. If there is anything, I'm not aware of it.

As for number 2, yes it's SetState(). So for example {SetState('your_variable', "your data")}. This can then be accessed by any other script as {state.your_variable}.

For number 3, all the keywords and functions are listed in the 'help' and 'variables' sections (the buttons at the bottom of each script editing window). I also believe there are a couple of undocumented ones, but as far as I'm aware they are rarely used, if at all. There are help sections on Github too that could provide more in-depth descriptions. (Link to the EDDI Wiki: )

I'm sure someone can provide something better for my answers to 1 & 3, but I hope these help for the moment. :)
 
Not sure about number 1. If there is anything, I'm not aware of it.

As for number 2, yes it's SetState(). So for example {SetState('your_variable', "your data")}. This can then be accessed by any other script as {state.your_variable}.

For number 3, all the keywords and functions are listed in the 'help' and 'variables' sections (the buttons at the bottom of each script editing window). I also believe there are a couple of undocumented ones, but as far as I'm aware they are rarely used, if at all. There are help sections on Github too that could provide more in-depth descriptions. (Link to the EDDI Wiki: )

I'm sure someone can provide something better for my answers to 1 & 3, but I hope these help for the moment. :)
1 @VerticalBlank has been planning some changes in this direction, but right now the answer is no. The personality is saved to disk in an escaped Json format. If you were to re-save a modification that didn't conform to the expected escaped format then EDDI would fail to ready the file correctly.
2: As Darkcyde said.
3: The built-in syntax highligher is powered by <https://github.com/EDCD/EDDI/blob/develop/SpeechResponder/Cottle.xshd>.
 
Last edited:
1 @VerticalBlank has been planning some changes in this direction, but right now the answer is no. The personality is saved to disc in an escaped Json format. If you were to re-save a modification that didn't conform to the expected escaped format then EDDI would fail to ready the file correctly.
Yes I am coming to the view that this needs to be prioritised. I describe my plan in the comments to https://github.com/EDCD/EDDI/issues/523 -- thoughts welcomed.
 
he personality is saved to disc in an escaped Json format. If you were to re-save a modification that didn't conform to the expected escaped format then EDDI would fail to ready the file correctly
Yup. The idea was to have the all the scripts in a single, big "text" file, translate (and modify) the scripts (using some Regex to replace some common code) and put the translated scripts back "in" the json file.
 
Yup. The idea was to have the all the scripts in a single, big "text" file, translate (and modify) the scripts (using some Regex to replace some common code) and put the translated scripts back "in" the json file.
That could work. Make a back-up of the file first of course. :)
 
Top Bottom