Release EDDI 3.3 - Bring your cockpit to life

Hi T'kael,

Thanks for the new update. I've just started to look through the changes to this new version and I have a quick question regarding the variable terminology. In the new 'Bodies mapped' script (as this is the first I've looked at so far), there is the following at the beginning: {set reportSystem to SystemDetails(system.systemname)} . I was wondering if system.systemname was correct/ok as the 'variable' section in the help says that it should be system.name, there is no system.systemname listed. There is for 'body' (body.systemname), just not for 'system' (system.systemname). If it is ok to use in this way, then should the 'variables' help section be updated to reflect this?

Anyway, good work on the new update with all the fixes, and I'll let you know if I find anything else I'm not sure of. :)

DC.
Both are valid but systemname is the preferred usage. I'll update the docs for next time. :)
 
So, to get a grasp on how EDDI works, there's two sources of localization: one is crowdin, and one is the personality in use, am i right?
'cause i'm trying to get where the numbers are translated but i'm missing it...

my problem is that italian numbers have exceptions, so as example two-tousand is duemila, but one-thousand is mille and not unomila
Three or four sources really.
1. CrowdIn.
2. The personality in use.
3. The voice in use.
4.Our Humanise() function (if you're using that)

Are you having problems with numbers from the Humanise() function? Are you using an Italian voice?
 
Another question:
now that i've installed the update. is my italian EDDI "personality" missing something (new triggers, events, variables) being it copied from the older one?
Since the default Italian personality is untranslated from English, it is being kept current with the English translation. All script updates have been mirrored over. If the community provides a translation to Italian (either by submitting a revised eddi.json or by submitting a pull request against https://github.com/EDCD/EDDI/blob/develop/SpeechResponder/eddi.it.json) then we can incorporate it. The personality would become the Italian community's responsibility to support and maintain from that point.

Note: The submitted personality should ideally have the same scripts as the English version. Adding new scripts to the default in your language creates some complications that we'd rather avoid if possible.
 
yes, and yes (IVONA Carla, but the "wrong" numbers comes the same with the default italian win voice).
Ok, so some voices are better than others? With IVONA Carla (which I'm understanding to be better than the Microsoft voice), is 1000 correct without Humanise()? If so then our goal should be to return 1000 rather than 1 mille? Unfortunately, that would in some cases likely be more verbose and so we'd need to carefully consider.
 
Last edited:
Ok, so some voices are better than others? With IVONA Carla (which I'm understanding to be better than the Microsoft voice), is 1000 correct without Humanise()? If so then our goal should be to return 1000 rather than 1 mille? Unfortunately, that would in some cases likely be more verbose and so we'd need to carefully consider.
All the italian voices i own are the same, about these numbers, so the problem is in the Humanise function.

Yes, you should left 1000, 1000000 and 1000000000 untouched, or convert them in mille, un milione, un miliardo (note that "un" is not = "one" but is an article, like "a").
We also have "un migliaio, due ... migliaia" (= "a thousand, two ... thousands") and "un centinaio, due ... centinaia" (= "an hundred, two ... hundreds") when the quantity is not precise.... the same when you use "a dozen".

What kind of "humanisations" should i test to see if there's other things to address? i see how the function convert numbers in ... "colloquial quantities", but i don't know what to test.

PS
Why there's a "di" (= of ) after "milioni"? (milioni di = millions of)
 
Last edited:
All the italian voices i own are the same, about these numbers, so the problem is in the Humanise function.

Yes, you should left 1000, 1000000 and 1000000000 untouched, or convert them in mille, un milione, un miliardo (note that "un" is not = "one" but is an article, like "a").
We also have "un migliaio, due ... migliaia" (= "a thousand, two ... thousands") and "un centinaio, due ... centinaia" (= "an hundred, two ... hundreds") when the quantity is not precise.... the same when you use "a dozen".

What kind of "humanisations" should i test to see if there's other things to address? i see how the function convert numbers in ... "colloquial quantities", but i don't know what to test.

PS
Why there's a "di" (= of ) after "milioni"? (milioni di = millions of)
Ok, we can leave it to the voice to interpret 1000, 1000000 and 1000000000 on the next release. More complex numbers would still be rendered as they are.
"di" is from the CrowdIn translations.
 
Note: The submitted personality should ideally have the same scripts as the English version. Adding new scripts to the default in your language creates some complications that we'd rather avoid if possible.
While keeping the same scripts, how much "freedom" there's INSIDE the scripts?

Some options (OneOf functions) are not available in italian, or some phrase parts needs to be reverted, and then there's some subjective choices about how better is a phrase kept "closer" to the original english one or rewritten.

Also, some script shows a certain "style" (some scripts have the phrase parts stored in variables, and then queued, someone else uses ` around the spoken parts instead of ", some scripts are divided in "sections" using comments, etc.

What "style" should i follow, and how much i could "move" the various part of the script inside of it?
 
Also: there's a way to have a popup with the script error description?
listening to in with an italian voice is really really hard to understand what's the problem.
 
Last question for a while (sorry)

This is part of a script:
Code:
    {if materials = 1:
        {blueprint.materials[0].material}
    |elif materials = 2:
        {blueprint.materials[0].material} and {blueprint.materials[1].material}
    |else:
        {set cur to 0}
        {while cur < len(blueprint.materials):
            {if cur = 0:
                {blueprint.materials[cur].material}
            |elif cur < len(blueprint.materials) - 1:
                , {blueprint.materials[cur].material}
            |else:
                , and {blueprint.materials[cur].material}
            }
            {set cur to cur + 1}
        }
    }

There's a reason (resources, execution time, ... ) for the |elif materials = 2: branch? That case is already covered in the while loop below, so i don't get why it is there (and it adds translations to do -as little as it is- so it add maintaining efforts).
 
Also, some script shows a certain "style" (some scripts have the phrase parts stored in variables, and then queued, someone else uses ` around the spoken parts instead of ", some scripts are divided in "sections" using comments, etc.

What "style" should i follow, and how much i could "move" the various part of the script inside of it?
I think the problem with the 'style' is because the scripts have been written and amended by different people over time. Some parts come from the original author of EDDI, JGM, while the majority come from the current team, and it seems that each member has their own 'style'. This has always bugged my 'coding OCD' ;) and for my EDDI personality, I've spent a long time going over every script to give them all a standardisation to their code. For me at least, it makes it easier to understand what's going on; if I see a code block in one script, I know that will be in another script doing the exact same thing, rather then be coded in a different way to achieve the same result.

For mine, I've tried to standardise the code, variable names, the layout, and many other little things. It would be great if the default personality could be standardised too, but I feel this would be a big undertaking for the team, and their time would be better spent bug fixing and updating instead. It could still be done, I guess, if someone was willing to go through the whole personality, and standardise everything to a certain set of rules. But as you say, for different languages, the code would need to be re arranged and laid out differently, due to differences in language grammar.

There's a reason (resources, execution time, ... ) for the |elif materials = 2: branch? That case is already covered in the while loop below, so i don't get why it is there (and it adds translations to do -as little as it is- so it add maintaining efforts).
I think it's execution time (efficiency), but it's literally just microseconds. I must admit, for my personality, I removed the first couple of options, and have just left it all to an efficient, standardised WHILE loop. For me, less code to look at is tidier. :) This is one of the things I've standardised across all scripts throughout my personality.
EDIT: This is my version of that part of the code:
Code:
    {set cur to 0}
    {set length to len(blueprint.materials) - 1}
    {while cur < len(blueprint.materials):
        {blueprint.materials[cur].material}
        {set cur to cur + 1}
        {if cur = length: and
        |elif cur < length:,
        }
    }
 
Last edited:
While keeping the same scripts, how much "freedom" there's INSIDE the scripts?

Some options (OneOf functions) are not available in italian, or some phrase parts needs to be reverted, and then there's some subjective choices about how better is a phrase kept "closer" to the original english one or rewritten.

Also, some script shows a certain "style" (some scripts have the phrase parts stored in variables, and then queued, someone else uses ` around the spoken parts instead of ", some scripts are divided in "sections" using comments, etc.

What "style" should i follow, and how much i could "move" the various part of the script inside of it?
OneOf() should work in Italian. What do you mean when you say it isn't available?

As far as translation freedom within the scripts is concerned, we recognize that flexibility is needed to provide the best translation and trust the judgement of our translators. I agree that the scripts don't all have the same style, and we actually prefer this. Part of our goal with our default scripts is to demonstrate various methods for writing scripts so that commanders can learn how to use the Cottle scripting language and to provide examples which commanders can modify to their liking.

The Cottle scripting language prefers to see " and ' alternate when nesting one function inside another.
 
Also: there's a way to have a popup with the script error description?
listening to in with an italian voice is really really hard to understand what's the problem.
We'd rather not pop up a message box as that could be quite disruptive while you're in game, but the error details should be recorded in EDDI's .log files located at %APPDATA%/EDDI.
 
Hi Parduz, one thing to understand. The character EDDI is the original character and it is in English.
You have to copy and rename EDDI once and then you can translate, shorten or extend the scripts to your liking.
You can do that without any problems. This also means you can adapt the pronunciation to the Italian pronunciation.
A few CMDR from Germany have been doing this for quite a long time.
Your copy of the character does not bother the makers of EDDI at all.

Greetings from nepomuk :)

Translated with www.DeepL.com/Translator (free version)
 
OneOf() should work in Italian. What do you mean when you say it isn't available?
Oh, sorry for have not been clear: i means that sometimes english can use different words (hence the OneOf) while in italian we have just one, so i have to remove the OneOf function.
Anyway, i got the reasoning behind the scripting styles and freedom about them.

The Cottle scripting language prefers to see " and ' alternate when nesting one function inside another.
Yup, i was surprised about ` (which is ALT+96 on my keyboard).

We'd rather not pop up a message box as that could be quite disruptive while you're in game, but the error details should be recorded in EDDI's .log files located at %APPDATA%/EDDI.
Understood. I was thinking at the popoup only when the editing form is shown, but i get that it is not so useful.

The character EDDI is the original character and it is in English.
You have to copy and rename EDDI once and then you can translate...
Yup :)
My own WIP personality is a different file, and she uses "we" and "us" instead of "you" :p
 
looking at the "Message Received" script: from where "Squadron mate", "commander" (and i don't know if there's other titles) comes?
'cause they're not translated, and i can't find them on Crowdin.
-edit-
found it: {event.source}. Now, why the words in it aren't translated?
 
Last edited:
looking at the "Message Received" script: from where "Squadron mate", "commander" (and i don't know if there's other titles) comes?
'cause they're not translated, and i can't find them on Crowdin.
-edit-
found it: {event.source}. Now, why the words in it aren't translated?
Likely something that got missed when we implemented internationalization. Please open a ticket. o7
 
Ok, we can leave it to the voice to interpret 1000, 1000000 and 1000000000 on the next release. More complex numbers would still be rendered as they are.
Problem is that, while now that numbers are ok, it is'nt the spoken umanization.
From english "more than two thousands and half light years" (i'm guessing, here, as i don't hear it in english) it translates to "più di due e mezzo mila anni luce" but it is wrong, as it should say (staying literal) "due migliaia e mezzo di anni luce". I see how that Humanise function is beatiful, but also how hard it is to be localized: (perhaps?) it should pick from a a table of localized phrases, not just translating words...? I really dunno, i'm just saying that it is hard to make it works for all languages but i love the idea of the Humanise function.
 
Top Bottom