Release EDDI 3.3 - Bring your cockpit to life

Guys, i have problems with my Landingpad report script:

Code:
{_ Fetch from context _}
{set landingpad to state.eddi_context_landing_pad_pad}

{_ DEBUG _}
{set landingpad to 0}

{set PositionCode to:
    {if   landingpad = 1:    106
    |elif landingpad = 2:    106
    |elif landingpad = 3:    306
    |elif landingpad = 4:    306
    |elif landingpad = 5:    107
    |elif landingpad = 6:    107
    |elif landingpad = 7:    307
    |elif landingpad = 8:    307
    |elif landingpad = 9:    108
    |elif landingpad = 10:    308
    |elif landingpad = 11:    109
    |elif landingpad = 12:    109
    |elif landingpad = 13:    209
    |elif landingpad = 14:    309
    |elif landingpad = 15:    309
    |elif landingpad = 16:    110
    |elif landingpad = 17:    110
    |elif landingpad = 18:    310
    |elif landingpad = 19:    310
    |elif landingpad = 20:    111
    |elif landingpad = 21:    111
    |elif landingpad = 22:    311
    |elif landingpad = 23:    311
    |elif landingpad = 24:    112
    |elif landingpad = 25:    312
    |elif landingpad = 26:    101
    |elif landingpad = 27:    101
    |elif landingpad = 28:    201
    |elif landingpad = 29:    301
    |elif landingpad = 30:    301
    |elif landingpad = 31:    102
    |elif landingpad = 32:    102
    |elif landingpad = 33:    302
    |elif landingpad = 34:    302
    |elif landingpad = 35:    103
    |elif landingpad = 36:    103
    |elif landingpad = 37:    203
    |elif landingpad = 38:    303
    |elif landingpad = 39:    104
    |elif landingpad = 40:    304
    |elif landingpad = 41:    105
    |elif landingpad = 42:    105
    |elif landingpad = 43:    205
    |elif landingpad = 44:    305
    |elif landingpad = 45:    305
    |else                :    999
    }
}

Debuggin Position code: {PositionCode}.
{if PositionCode = 999:
    THIS TEST ALWAYS FAILS!
|else:
    {set DistanceCode to floor(PositionCode/100) }
    {set DirectionCode to mod(PositionCode/100) }
    Debuggin Direction code: {DirectionCode}.
    Why the mod function did'nt work?
    {set DirectionCode to PositionCode - (DistanceCode*100) } {_ mod(PositionCode/100) did'nt work? }
    Debuggin Direction code again: {DirectionCode}.
    {if DirectionCode = 99:
        Pad {landingpad} does not exist.
    |else:
        Pad {landingpad} is
        {if   DistanceCode = 1: near
        |elif DistanceCode = 2: in the middle
        |elif DistanceCode = 3: far away}
        , at {DirectionCode} o clock, with the green light to the right.
    }
}
If you run it should be clear what does'nt go.

Why the {if PositionCode = 999: test fails?
Why mod(PositionCode/100) does'nt works?
 
Because you set landingpad to zero.
So this instruction |else : 999 always set PositionCode to 999.
Then, why testing {if PositionCode = 999: should fail?
Read up on Cottle syntax.
What exactly?

mod(x, y)​

Return the value of x modulo y, or an undefined value if y was equal to zero.
Position code is 999, as the script says in the "Debug speach", and 100 is ... well, 100, so what are you trying to tell me?
 
So this instruction |else : 999 always set PositionCode to 999.
Then, why testing {if PositionCode = 999: should fail?

What exactly?


Position code is 999, as the script says in the "Debug speach", and 100 is ... well, 100, so what are you trying to tell me?
Setting PositionCode like that is making it into a string variable, so " 999 " doesn't equal 999. Try Debuggin Position code: {type(PositionCode)}. to see what I mean.

Add this code to convert it into a number: {set PositionCode to cast(PositionCode, "n")}

Edit: I assume you'r trying to be efficient with the code, but in this case, I think best practice would be to set PositionCode separately in each part of the IF. That way it should remain as a number. 😊
 
Last edited:
Sorry if I'm misunderstanding something, but I think you're also using the mod statement incorrectly.
Try line 62: {set DirectionCode to mod(PositionCode,100) }
gives the same value as {set DirectionCode to PositionCode - (DistanceCode*100) }
 
Sorry if I'm misunderstanding something, but I think you're also using the mod statement incorrectly.
Try line 62: {set DirectionCode to mod(PositionCode,100) }
gives the same value as {set DirectionCode to PositionCode - (DistanceCode*100) }
With this fix, and converting to a number, the script works as I would expect. Using landingpad = 4, I get this:
"Pad 4 is far away, at 6 o clock, with the green light to the right."

Code:
{_ Fetch from context _}
{set landingpad to state.eddi_context_landing_pad_pad}

{_ DEBUG _}
{set landingpad to 4}

{set PositionCode to:
    {if   landingpad = 1:    106
    |elif landingpad = 2:    106
    |elif landingpad = 3:    306
    |elif landingpad = 4:    306
    |elif landingpad = 5:    107
    |elif landingpad = 6:    107
    |elif landingpad = 7:    307
    |elif landingpad = 8:    307
    |elif landingpad = 9:    108
    |elif landingpad = 10:    308
    |elif landingpad = 11:    109
    |elif landingpad = 12:    109
    |elif landingpad = 13:    209
    |elif landingpad = 14:    309
    |elif landingpad = 15:    309
    |elif landingpad = 16:    110
    |elif landingpad = 17:    110
    |elif landingpad = 18:    310
    |elif landingpad = 19:    310
    |elif landingpad = 20:    111
    |elif landingpad = 21:    111
    |elif landingpad = 22:    311
    |elif landingpad = 23:    311
    |elif landingpad = 24:    112
    |elif landingpad = 25:    312
    |elif landingpad = 26:    101
    |elif landingpad = 27:    101
    |elif landingpad = 28:    201
    |elif landingpad = 29:    301
    |elif landingpad = 30:    301
    |elif landingpad = 31:    102
    |elif landingpad = 32:    102
    |elif landingpad = 33:    302
    |elif landingpad = 34:    302
    |elif landingpad = 35:    103
    |elif landingpad = 36:    103
    |elif landingpad = 37:    203
    |elif landingpad = 38:    303
    |elif landingpad = 39:    104
    |elif landingpad = 40:    304
    |elif landingpad = 41:    105
    |elif landingpad = 42:    105
    |elif landingpad = 43:    205
    |elif landingpad = 44:    305
    |elif landingpad = 45:    305
    |else                :    999
    }
}

{set PositionCode to cast(PositionCode, "n")}

{set DistanceCode to floor(PositionCode / 100)}
{set DirectionCode to mod(PositionCode, 100)}

{if DirectionCode = 99:
    Pad {landingpad} does not exist.
|else:
    Pad {landingpad} is
    {if   DistanceCode = 1: near
    |elif DistanceCode = 2: in the middle
    |elif DistanceCode = 3: far away}
    , at {DirectionCode} o clock, with the green light to the right.
}
 
Last edited:
you're also using the mod statement incorrectly

mod() takes two arguments
well, well, well, this should teach me not to go in these kind of stuffs at 3 A.M. while playing :sleep:
Sorry for have being dumb 😔

Setting PositionCode like that is making it into a string variable, so " 999 " doesn't equal 999. Try Debuggin Position code: {type(PositionCode)}. to see what I mean.
You know? i thought at that, so i tried to do {if PositionCode = "999": but it failed, and i was lost.

Now i've found this:
1642242243701.png

In the upper part you can see that I wrote the script using TABS. Below there's the SpeechResponderOut file: while Cottle trims spaces, it leaves the TAB character, so that string was not "999" but "tab999". That fooled me (and i'm unsure if this should be considered normal or a bug).

Edit: I assume you'r trying to be efficient with the code, but in this case, I think best practice would be to set PositionCode separately in each part of the IF. That way it should remain as a number.
I'll keep it in mind... it is hard to understand what types you're dealing with.


THANKS GUYS.
 
well, well, well, this should teach me not to go in these kind of stuffs at 3 A.M. while playing :sleep:
Sorry for have being dumb 😔

THANKS GUYS.
No problem, that's what a community is for. In the German-speaking world, there is a saying:
"It goes to the people like the people! (I hope that is translated correctly now).
It's the same for everyone; everyone has the same experiences. ;)
 
Shouldn't 7 and 22 also have a 2 in the front? the pattern repeats for every 15 pads.

I am of the same opinion. First digit is the ring, third digit is the direction on the dial of a watch.
The second digit I can not interpret, so I am also surprised by the positions 20 to 25 with a 1 at position 2.

1642246981535.png
 
I am of the same opinion. First digit is the ring, third digit is the direction on the dial of a watch.
The second digit I can not interpret, so I am also surprised by the positions 20 to 25 with a 1 at position 2.
A (analog) clock goes from 01 to 12, you know.
 
1642412687412.png

Shouldn't 7 and 22 also have a 2 in the front? the pattern repeats for every 15 pads.
Actually, my unintentional mistake was to put 37 in the "center", 'cause other layout images are made like this one, so it seems that the only "central" pads are the ones in the rows of 5 pads....

(Figure of speech: Sometimes you can't see the forest for the trees !)
....then (speaking of this)....

I am of the same opinion. First digit is the ring....
....it never occurred to me that there's 3 rings, even in game! To me they were just "closer, far, or around the center"! LOL.

So thank you, guys. I'll make my script talking about "first, second and third ring" instead of distances: it will sounds much more professional :)
 
Asking to @T'kael and any other EDDI developer/expert.

I've already proved that i'm dumb, so please pardon me, but i feel very hard to find what are the "non localized" properties of the various EDDI objects just by seeking the code in Github. I usually get lost and can't find what i'm looking for, until i learn i was searching for the wrong word.
I mean properties like invariantName, invariantTags , EDName etc.

There's a compiled and updated list (sort of tree-view) of the EDDI objects?
OR
could someone write me a list of all the objects which owns "non-localized" properties?


(this is 'cause some test on my italian EDDI fails 'cause i'd need to rewrite all the localized tests, and instead i want to translate just what is spoken)

Thanks.
 
Hi Parduz, thanks for asking. I know that you're not dumb -- in my experience only smart people make that statement about themselves ;)

Let's start by clarifying why we have set things up as they are. Our core goal has been to completely decouple translation (on the CrowdIn site) from code development (on the GitHub site), by embracing the resource manangement facilities of the .NET framework re internationalization.

The huge benefit here, which has paid off handsomely, is that translators and developers can work in parallel and without "stepping on each other's toes", to use an English idiom. Provided that developers abide by some straightforward guidelines, everything is peachy and the automatic two-way feed between CrowdIn and GitHub works flawlessly.

Therefore, if you as a translator are finding a need to deal with GitHub then that indicates that translation isn't as decoupled as it ought to be.

It sounds like you are building EDDI locally using Visual Studio, is that correct?

Are you saying that you are seeing unit test failures because your own local Windows localization is not an English one?

If so, then that is a bug in the source code and probably something that TK or could speedily fix. An issue report would be great.

If I have misunderstood then please clarify.
 
It sounds like you are building EDDI locally using Visual Studio, is that correct?
:eek:
Nonononono! 😅

I'm not doing anything other than (re)writing scripts :)

Let me try to explain myself better with a small story :D :

The "Market Information Update" script uses {if ship.role = "Multi-purpose" || ship.role = "Trading": to determine what to say.
Those tests always fails on my italian EDDI (i mean that EDDI uses all the italian translation) 'cause "Multi-purpose", "Trading" etc. has been localized.
So i thought to change it in {if ship.role.invariantName = "Multi-purpose" || ship.role.invariantName = "Trading": ('cause i learned that there's the "invariantName" property which provide the non-localized string), and i want to do it in any other occourrence: i opened the json file in my editor, searched for "ship.role" and found that there is ship.Role.edname for this purpose.
Now i have two "non-localized properties" to check: .invariantName and .EDName, and i have to learn what's the difference and what object own which property, right?
I searched the json for "edname" to see and learn where it should be used and stumbled in report.crimeEDName....
So now i have more than 2 and, perhaps, more than 3 non-localized stuffs to look for when i need to test a string...
Open Github, search in the Wiki, then seek for the objects, try to find which one have which property, realize that i don't know how to use Github enough and i don't want to download the whole source to do a multi-file string search, gave up and asked to @Darkcyde , which suggested to ask here. :)

So, my difficulties are not related to coding (or building EDDI), but to knowledge:
in general, how do i know (at a glance, in a fast/easy way) what properties an object own (to me, objects are ship, event, module, etc.) ?
My specific case: what are the non-localized properties (like invariantName and EDName) or the non-localized ... stuffs (like crimeEDName)? when are they available? who owns them? how should i use them?
 
Last edited:
To add to what @Parduz has explained above (quite well, I think), after a quick conversation with him last week, we realised that there doesn't appear to be anywhere that details any of the non-localized versions of variables. As he explains, there seem to be at least a couple of places in the default scripts that have tests based on the English localized variables, but I assume these should be converted as part of any general translation, maybe?

We know of some .invariant versions throughout the default personality, but then there are things like the edname and crimeEdName variables that appear to perform the same function as invariant versions. It's like some are called one thing, and others another, with partial consistency throughout the personality.

Would it be possible to provide a list of all invariant/edname versions of variables (or point us to where we can find these), and also maybe bring the various different names inline with each other, maybe renaming them all to invariant<name>? I think this would help greatly with those wanting to translate EDDI's scripts, although I do understand this might be a bit of a large undertaking to do. 😊
 
Top Bottom