Release EDDI Scripts and EDDI enabled VA Commands Thread

Nice work man. You're right, I meant System Alliance not System Faction! Will post a video when my solution is up and working as I fully imagine. Thanks again for your input!
 
Hi everyone!

After several days of programming I have finally finished my Mission System for EDDI (with VA save and loading across sessions). With this, you can be reminded of what missions you currently have in the Galaxy, the local system, or local station. It can also tell you where your closest mission is located, and what system you have the most missions in. While it stores many of the mission variables, most are not used yet. But they are there so that you can make your own scripts for information, e.g. 'Where's my closest delivery mission?'.

I have also included a basic VoiceAttack profile that includes the functionality to allow loading and saving of your mission data. This allows the system to remember what missions you have over different play sessions. However, if you don't want to use VoiceAttack, then the Mission System will work fine without it, it will just lose all mission data when EDDI is closed.

I'd like to thank Brigetiol1 for the whole idea of a mission system, and for encouraging me during the process. ;)

Here is a link to the ZIP file with everything you need. As per my previous releases, this ZIP contains both an EDDI profile file, and text files of all the functions and updated events within that profile. You can either use my profile directly, or pick and choose from the text files to add to your own. For this, and future releases, I am including the VA profile that adds loading and saving functionality for the Mission System.
https://www.dropbox.com/s/4iqec1v9mxmmq5x/Darkcyde's Defaults 11-06-17.zip?dl=0

There are many, many other fixes and functions in my EDDI profile. Please read the included Change Log for more details.

Of course, if you find any bugs, or have any suggestions for me to consider adding, please feel free to let me know.

All the best, and fly safe Commanders! [up]

-=] Darkcyde [=-

EDIT: It may be worth noting that this is my very first try doing something with VoiceAttack. Until a couple of days ago, I had no idea how to do anything with VA, so if the scripts can be done better and more efficiently, please excuse my noobness with it. :)
 
Last edited:
Darkcyde,
So far I am enjoying your personality you have created. I have one question though... The fueling script, is it broken in the script? Or is this another example of the API being screwed up since 2.3? Mine attempts to tell me about my fueling but has no values to go off of.
 
Darkcyde,
So far I am enjoying your personality you have created. I have one question though... The fueling script, is it broken in the script? Or is this another example of the API being screwed up since 2.3? Mine attempts to tell me about my fueling but has no values to go off of.

Greetings Cmdr Dahill,

Thank you for giving my personality a try! I've tried to keep it the same as the default (as much as possible) with it mannerisms and way of speaking. I like to think of it as more of an extension of the default, with greatly expanded functionality, and slightly more variation in the way things are reported.

Well, you are not the first to mention that the fuelling script doesn't work for them. Apparently even the default no longer works, in the same manner as you describe. Now, personally, I've not had a problem with it in the way you have. Both the default, and my (pre 2.3) version have always reported how much fuel I have scooped, or refuelled by at a station. The problem I have had since 2.3 is the short reporting intervals. The journal now reports once roughly every 5 tonnes** scooped, so EDDI was reporting multiple times during a scoop, once for every ~5 tonnes. My new script simply postpones that reporting until the ship is either full, or scooping has stopped.

**5 tonnes is the amount my FSD uses for a jump in both ships I've been testing with (Asp Ex. & Python) so this value may be different for other ships. My script is hard-coded for this amount, however it shouldn't matter how much fuel your FSD uses, my script should still work. Although, I've just had an idea that could make this amount a variable dependant on your FSD class & size. I'll look into it.

Ok, so it works perfectly on mine, but clearly not on yours, or with a couple of other commanders (those that have mentioned it anyway). This has got me thinking. So, first the obvious question, are you using the latest v2.3.0-b8 (beta 8) version of EDDI? I've always been making sure I have the very latest version. VoiceAttack doesn't matter, as I've only just started using it, and the fuel reporting has been working fine in the standalone EDDI before that.

Next, when you fuel scoop, does the journal have those ~5 tonne reports in it? If it's saying zero, or just an empty variable, then this would be the cause. Without being able to check, this would seem the most likely if you are at least getting the EDDI script to trigger, as I believe it's the journal report that triggers the event in EDDI. Of course, I could be wrong about that, it could be getting it from the companion app, so...

If you do have these reports of ~5 tonnes, and you are using the latest beta version of EDDI, then it would be a mystery to me. The only other thing I can think of, is highly unlikely, but... people have trouble with the companion app if they purchased Horizons as a standalone add-on. I say unlikely because as far as I am aware, EDDI gets it's fuel info from the journal, not the app, so this would be irrelevant.

So, TL;DR Are you using EDDI v2.3.0-b8? Are you getting the ~5 tonne reports in the journal? (default location C:\Users\<user>\Saved Games\Frontier Developments\Elite Dangerous) Did you buy Horizons (if you have it) as a separate add-on? Oh, and one last thing (also highly unlikely) are you using any other scripts which *may* interfere with the Fuelling event script?

Let me know, because I'd like to get to the bottom of the problem. I hate not knowing things like this, it bugs me when it works fine for me and not others. I just need to find out what's different between our setups. :)

EDIT: Just a thought... check how much fuel your FSD uses per jump, and change that 5.0000 in the Ship Refuelled script to match and see if that has any effect.

----------------------------------------------------------------

Also, while I'm on here, I found a dumb mistake in my MissionStoreCheckGalaxy script. I put this line in the wrong place when testing something: {set mission_system_array to split(state.eddi_context_mission_destinationsystem, "+=")}. This is the full, corrected, version of the script:-
Code:
{_ MissionStoreCheckGalaxy}
{_ Check what systems you have missions in}

{if state.eddi_context_missions_initialised != "yes":
    {F("MissionStoreInitialise")}
}

{_ For VoiceAttack, convert TXT token into number value, as EDDI plugin can't export DEC to State variables}
{set missionstotal to cast(state.eddi_context_missions_accepted, "n")}

{if missionstotal > 0 && missionstotal != null:
   {set mission_system_array to split(state.eddi_context_mission_destinationsystem, "+=")}

   You have {missionstotal} mission{if missionstotal > 1:s} to complete.

   {if missionstotal = 1:
      It is {Occasionally(2,"located")} in
      {if mission_system_array[0] = "":
         an unknown
      |else:
         the {mission_system_array[0]}
      }
      {Occasionally(2,"star")} system.

   |else:
      {set systems to []}
      {set systems_count to []}
      {for system in mission_system_array:
         {if system != "":
            {if find(systems, system) > -1:
               {set here to find(systems, system)}
               {set number to systems_count[here] + 1}
               {set systems_count to cat(slice(systems_count,0,here), [number], slice(systems_count,here+1))}
            |else:
               {set systems to cat(systems, [system])}
               {set systems_count to cat(systems_count, [1])}
            }
         }
      }

      {if len(systems) = 1:
         They are all {Occasionally(2,"located")} in
         {if systems[0] = "":
            an unknown
         |else:
            the {systems[0]}
         }
         {Occasionally(2,"star")} system.

      |else:
         There
         {if systems[0] = 1: is
         |else: are
         }

         {set cur to 0}
         {while cur < len(systems):
            {systems_count[cur]}
            {if systems[cur] = "":
               in an unknown system
            |else:
               {OneOf("at","in")} {systems[cur]}
            }
            {Pause(500)}
            {set cur to cur + 1}
            {if cur = len(systems)-1: and
            |elif cur < len(systems):,
            }
         }
      }.
   }
|else:
   You {Occasionally(2,"currently")} have no missions at {OneOf("the moment","this time")}.
}
Just copy the whole thing, and replace the entire script (or just move that one line, it's obvious where I moved it to, a few lines above where it was).

Fly safe!

-=] Darkcyde [=-
 
I have been using your scripts for a while now Darkcyde and they really add to the experience.
Thank you for your work and sharing it with us.
 
Starting to wonder if jgm is on holidays or somesuch...
;)
Can't play without EDDI anymore, and i'm lounging for next update.

edit: just realized silly me posted in the scripting thread.:eek:
so, sorry for OT, commanders!
 
Last edited:
Darkcyde, I took a look at your personality and really liked the mission system you created. My own profile is very customized as well. Our styles are similar, but I'm a information junkie, I have EDDI telling me everything that is available.

I'd like to keep my profile, but integrate your mission stuff into mine. Looking through your profile I see lots of calls and such. What is needed from your profile to add to my profile to get the mission info working?

Thank you for the awesome work. I like to tinker, but I don't have the mind of a programmer and I always get lost in the code. Coddle/C is like speaking a foreign language to me LOL. In my opinion, voice attack programming is much easier.
 
Darkcyde, I took a look at your personality and really liked the mission system you created. My own profile is very customized as well. Our styles are similar, but I'm a information junkie, I have EDDI telling me everything that is available.

I'd like to keep my profile, but integrate your mission stuff into mine. Looking through your profile I see lots of calls and such. What is needed from your profile to add to my profile to get the mission info working?

Thank you for the awesome work. I like to tinker, but I don't have the mind of a programmer and I always get lost in the code. Coddle/C is like speaking a foreign language to me LOL. In my opinion, voice attack programming is much easier.

Hi JRohrer,

Glad you're enjoying my work! :)

I take it you're using VA, so you'll be able to save your missions between sessions. So, for the best experience from my missions system you'll need the following scripts:-

Commander Continued - runs the store check on game load
Commander Started - wipes the mission store on new game
Entered Normal Space - runs the store check when exiting at a station
Jumped - runs the store checks on completing a jump
MisFacState - Faction states for Accepted/Completed
Mission Abandoned - runs the store delete
Mission Accepted - runs the store add
Mission Completed - runs the store delete
MissionStoreAdd
MissionStoreCheckGalaxy
MissionStoreCheckNearMost
MissionStoreCheckStation
MissionStoreCheckSystem
MissionStoreDelete
MissionStoreInitialise
MissionType - gets a humanised version of the mission type for Accepted/Completed
VAStartup - setup some variables for VA, if VA started after EDDI

I don't think I've missed any. I've just gone through my personality and I believe that's all. OK, it looks a lot, but for some of those, all I've done is add a couple of lines to call the other functions, so they should be easy to integrate in your own if you have those already modified. Please note my previous post (a couple above this) where I mention a mistake I made in MissionStoreCheckGalaxy, and the fix for it. It's not a game-breaking error, it just won't say the right thing if you only have one mission when it's called, that's all.

You'll also need to add my VA profile to enable the loading and saving. As I'm new to VA, I've not done much in the profile, I've put in the functions necessary for the mission system to operate. Oh, it also has the 'Quote of the Day' function, called by 'Commander Continued' triggering in VA. You can delete those two from it if you wish.

Let me know if you have any problems. :)

Fly safe!

-=] Darkcyde [=-

EDIT: I forgot to mention, in Commander Continued, it also sets up three State variables for the mission system to use immediately, before the check gets called, so they are needed too.
 
Last edited:
I made a script for "Star scanned".
I tells you the habbitable zone around the scanned star. I used the values from https://www.reddit.com/r/eliteexplo...bitable_zone_spreadsheet_find_terraformables/ and calculated the quadratic function for min and max habbitable zone in ls, depending on the type and luminosity of the scanned star.

{if event.stellarclass = "O":
{set aLow to 16880}
{set bLow to 3.56}
{set cLow to -0.0000562}
{set aHigh to 26940}
{set bHigh to 5.68}
{set cHigh to -0.0000897}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "B":
{set aLow to 3760}
{set bLow to 12.98}
{set cLow to -0.0019}
{set aHigh to 6000}
{set bHigh to 20.7}
{set cHigh to -0.00303}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "A":
{set aLow to 768}
{set bLow to 76.8}
{set cLow to -0.539}
{set aHigh to 1226}
{set bHigh to 122.5}
{set cHigh to -0.86}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "F":
{set aLow to 323.5}
{set bLow to 186.1}
{set cLow to -8.02}
{set aHigh to 516}
{set bHigh to 296.9}
{set cHigh to -12.79}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "G":
{set aLow to 165.2}
{set bLow to 369.3}
{set cLow to -65.2}
{set aHigh to 263.6}
{set bHigh to 589.5}
{set cHigh to -104.2}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "K":
{set aLow to 71.9}
{set bLow to 830}
{set cLow to -701}
{set aHigh to 114.8}
{set bHigh to 1324}
{set cHigh to -1119}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
|elif event.stellarclass = "M":
{set aLow to 13.7}
{set bLow to 2.88}
{set cLow to -0.0185}
{set aHigh to 21.8}
{set bHigh to 4.59}
{set cHigh to -0.029}
Habittable from {Humanise(aLow+(bLow*event.luminosity)+(cLow*event.luminosity*event.luminosity))} to {Humanise(aHigh+(bHigh*event.luminosity)+(cHigh*event.luminosity*event.luminosity))} lightseconds.
}
 
I made a script for "Star scanned".
I tells you the habbitable zone around the scanned star. I used the values from https://www.reddit.com/r/eliteexplo...bitable_zone_spreadsheet_find_terraformables/ and calculated the quadratic function for min and max habbitable zone in ls, depending on the type and luminosity of the scanned star.

That's pretty cool. While there is nothing essentially wrong with it, you don't need to assign values to the variables if you are going to use them immediately, like you have in your script. You could improve it in one of two ways:-

1. Leave the variable assignments as they are, but move the "Habitable from..." line to the very end, outside of the IF statement. This way you only need that line once. This would be the faster way to edit the script.

2. Forget about assigning them as variables altogether, and just input the values directly into the "Habitable from..." line for each star class. This would take longer to change, but result in much shorter code.

As I say, there's nothing particularly wrong with how you have done it. I just like to make code as short and efficient as possible. That's just me! ;)

Keep up the good work though. Things like this make for a richer experience for those players that want information like this.

-=] Darkcyde [=-
 
Hey Darkcyde,

I saw the comment in your 'Mission' scripts (and the Github issue you posted) about VA not being able to pass decimal variables to EDDI, and I've been scratching my head on it because this hasn't been my experience.

Just for a sanity check, I tested it with a simple 'test script' & VA command,and it works fine...

Voice Attack 'Test' command:

Code:
Set decimal [test_dec] value to 3.14159
Set Text [State variable] to 'test_dec'
Execute external plugin, 'EDDI 2.3.0-b8'        --> Plugin Context = "setstate" & Text Variables = "State variable"
Set Text [Script] to 'Test'
Execute external plugin, 'EDDI 2.3.0-b8'        --> Plugin Context = "speech"   & Text Variables = "Script"


Speech Responder 'Test' script:

Code:
The test variable is {state.test_dec}.


Please note that only text variables are passed to EDDI external plugin calls, whether it's the name of a Voice Attack variable or the name of a speech responder script (for example).
 
Last edited:
Darkcyde,

Been perusing your Mission Code... very fine work!

Something you may find of interest, jgm has an 'undocumented' distance calculation function.


I use it in a generic 'Get distance' script I've written...

Code:
{set dist to -1}
{if state.from_system && state.to_system:
    {if state.from_system = "":
        Origin system not designated.
    |elif state.to_system = "":
        Destination system not designated.
    |else:
        {set fs to SystemDetails(state.from_system)}
        {set ts to SystemDetails(state.to_system)}

        {if !fs.name:
            Your origin is not in the Pilot's Federation star charts.
        |elif !ts.name:
            Your destination is not in the Pilot's Federation star charts.
        |else:
            {set dist to round(Distance(fs.x, fs.y, fs.z, ts.x, ts.y, ts.z),1)}
        }
    }
}
{SetState('distance', dist)}

If the returned value is <0, then the script failed.
 
Last edited:
Please note that only text variables are passed to EDDI external plugin calls, whether it's the name of a Voice Attack variable or the name of a speech responder script (for example).

Hi Hoodathunk,

Yeah, this is exactly what I meant. The numbers get sent to EDDI as a text variable, not a number value. Sorry if I didn't explain myself properly.

I found that EDDI wouldn't use them properly as a number until I converted them back from a string, into a number. So 3.14 instead of "3.14". EDDI handles these differently, and that's where I was having problems until I realised what was happening. I've just put type conversions in my scripts where necessary now and it's all working as expected.


As for the undocumented Distance function, thanks for that. While it's almost exactly the same as what I had already, it does allow me to remove the preceding three lines of code that sets up the calculation.

Removed:
Code:
         {set pow_x to pow(dest.x - curr.x, 2)}
         {set pow_y to pow(dest.y - curr.y, 2)}
         {set pow_z to pow(dest.z - curr.z, 2)}

         {set distance to round(pow((pow_x + pow_y + pow_z), 0.5), 2)}

Added:
Code:
         {set distance to round(Distance(curr.x, curr.y, curr.z, dest.x, dest.y, dest.z), 2)}

Considering how similar these lines are, I would guess that the function is probably doing those exact same calculations anyway.


My next project is to write a similar system for Fines & Bounties. I've already realised it will be significantly harder than the mission system, considering Bounties can be issued by more than one faction for the same kill, and I don't think there is any information available to say who you just paid a fine to. But I like the challenge! ;)

-=] Darkcyde [=-
 
Last edited:
Hi Hoodathunk,

Yeah, this is exactly what I meant. The numbers get sent to EDDI as a text variable, not a number value. Sorry if I didn't explain myself properly.

I found that EDDI wouldn't use them properly as a number until I converted them back from a string, into a number. So 3.14 instead of "3.14". EDDI handles these differently, and that's where I was having problems until I realised what was happening. I've just put type conversions in my scripts where necessary now and it's all working as expected.


No doubt the methodology you're using of 'casting' text to numbers works fine for your application and may even be preferable but, I've used VA to pass booleans, integers, decimals and text values to EDDI scripts using 'setstate' and have never had an issue. The only caveat is that all number variables from EDDI back to VA are interpreted as decimals.

In a 'setstate' plugin function call, you're passing a text variable that contains just the name of the VA variable, not the variable value itself. The variable name can be for a boolean, integer, decimal, etc.

Using my previous example, you can modify it as such and see 'test_dec' is indeed being treated as a decimal value.

Code:
The test variable is {state.test_dec}.
The test variable squared is {state.test_dec * state.test_dec}.


Agreed, Fines & Bounties will be a particularly complex problem. Looking forward to seeing your solution!
 
Last edited:
Using my previous example, you can modify it as such and see 'test_dec' is indeed being treated as a decimal value.

Code:
The test variable is {state.test_dec}.
The test variable squared is {state.test_dec * state.test_dec}.

What you have to realise it that EDDI uses those variables differently in different conditions. Your calculation is valid only because EDDI auto-converts the text string to a number when using it for a calculation. I used this exact method originally to get the decimal value before I found the cast() method. I simply did {set variable to variable+0}.

You can see what I mean by trying this test code:
Code:
{set textnum to "2"}
{set decnum to 2}

Multiplied: {textnum * decnum}. This results in 4 because a mathmatical function has been performed and EDDI auto-converts textnum to a number.

{if textnum > 3:
   Textnum shouldn't do anything here, but it does because textnum is not a decimal number, it's a string with a null decimal value.
}

However, the above test WILL work if you put the number 3 in quotes to also make it a string, "3". This is why I was having a problem to begin with. You can't do a compare on the variable as a decimal number, only as a string or convert it first.

I've even tried it with 'if textnum > 3000000000000' (that's 3 trillion) and it still speaks that line. Also, during my testing, I've found that using 10 or 1000000000 as numbers to check against, or "10" or "100000000000" as a string to check with, they all make EDDI speak that line.

Try using '= 2' (as a number) and that will not speak the line, because textnum does not have a decimal value of 2. Also, try "-2" for textnum (multiplied = -4) and check {if textnum < "-1": again it will not speak the line. While numerically -2 is less than -1, as a string it is greater.

The number being passed to EDDi via the plug-in is always as a character or string and is treated as such within EDDI under most conditions. EDDI will auto-convert it for mathematical functions, but not for comparing. In these cases 3.14 is not the same as the "3.14" that the plugin passes to EDDI. This is most noteable for compares because the character/string has a null decimal value.

As a final double-check of what I have tested, and have said above, I tested the number variable of 'eddi_context_missions_accepted' that had been loaded from my mission system into EDDI using the plugin. I used {type(state.eddi_context_missions_accepted)} which reports the variable type, and exactly as predicted, EDDI returns "string" as the variable type, not "number", even though it was "7".

------------------------------------------------------------------------

EDIT: Please accept my apologies. Having done all the testing above, and running your suggestion to test decimal numbers again (this time with the type check), I think I may have found the reason why our coding is giving different results.

It appears that the problem actually comes from the saving and/or loading of the decimal number to/from the file, rather than the passing to EDDI. I'm going to believe this is down to my total lack of VA knowledge. Maybe you can look it over and see if & where I may have made a mistake?

As far as my limited VA knowledge is, I believe I have tried to save the decimal value to the file 'EDDI_Missions_Accepted.txt' as a number (using my Update Mission Store function in VA), but it looks like it's just the number as an ASCII character (so "7" as ASCII 55) rather than a decimal 7. When I've loaded this back up (using the System Startup function in VA), I load it as a text variable into 'eddi_context_missions_accepted', and then set a DEC version of 'eddi_context_missions_accepted' to be a conversion of the TXT token. This then seems to be sent to EDDI via the plugin as a string, so I'm guessing that it's actually passing the first TXT version and not the second DEC version. Would this be correct? And if so, how do I fix that? Can I delete the TXT version? Or is there a way to load it directly into the DEC version of the variable?

EDIT 2: After a bit of messing around in VA, I seem to have fixed it by setting the TXT version of eddi_context_missions_accepted to 'Not Set', after converting it to DEC. If there is a better way around this, please let me know.
 
Last edited:
What you have to realise it that EDDI uses those variables differently in different conditions. Your calculation is valid only because EDDI auto-converts the text string to a number when using it for a calculation. I used this exact method originally to get the decimal value before I found the cast() method. I simply did {set variable to variable+0}.

You can see what I mean by trying this test code:
Code:
{set textnum to "2"}
{set decnum to 2}

Multiplied: {textnum * decnum}. This results in 4 because a mathmatical function has been performed and EDDI auto-converts textnum to a number.

{if textnum > 3:
   Textnum shouldn't do anything here, but it does because textnum is not a decimal number, it's a string with a null decimal value.
}

However, the above test WILL work if you put the number 3 in quotes to also make it a string, "3". This is why I was having a problem to begin with. You can't do a compare on the variable as a decimal number, only as a string or convert it first.

I've even tried it with 'if textnum > 3000000000000' (that's 3 trillion) and it still speaks that line. Also, during my testing, I've found that using 10 or 1000000000 as numbers to check against, or "10" or "100000000000" as a string to check with, they all make EDDI speak that line.

Try using '= 2' (as a number) and that will not speak the line, because textnum does not have a decimal value of 2. Also, try "-2" for textnum (multiplied = -4) and check {if textnum < "-1": again it will not speak the line. While numerically -2 is less than -1, as a string it is greater.

The number being passed to EDDi via the plug-in is always as a character or string and is treated as such within EDDI under most conditions. EDDI will auto-convert it for mathematical functions, but not for comparing. In these cases 3.14 is not the same as the "3.14" that the plugin passes to EDDI. This is most noteable for compares because the character/string has a null decimal value.

As a final double-check of what I have tested, and have said above, I tested the number variable of 'eddi_context_missions_accepted' that had been loaded from my mission system into EDDI using the plugin. I used {type(state.eddi_context_missions_accepted)} which reports the variable type, and exactly as predicted, EDDI returns "string" as the variable type, not "number", even though it was "7".

------------------------------------------------------------------------

EDIT: Please accept my apologies. Having done all the testing above, and running your suggestion to test decimal numbers again (this time with the type check), I think I may have found the reason why our coding is giving different results.

It appears that the problem actually comes from the saving and/or loading of the decimal number to/from the file, rather than the passing to EDDI. I'm going to believe this is down to my total lack of VA knowledge. Maybe you can look it over and see if & where I may have made a mistake?

As far as my limited VA knowledge is, I believe I have tried to save the decimal value to the file 'EDDI_Missions_Accepted.txt' as a number (using my Update Mission Store function in VA), but it looks like it's just the number as an ASCII character (so "7" as ASCII 55) rather than a decimal 7. When I've loaded this back up (using the System Startup function in VA), I load it as a text variable into 'eddi_context_missions_accepted', and then set a DEC version of 'eddi_context_missions_accepted' to be a conversion of the TXT token. This then seems to be sent to EDDI via the plugin as a string, so I'm guessing that it's actually passing the first TXT version and not the second DEC version. Would this be correct? And if so, how do I fix that? Can I delete the TXT version? Or is there a way to load it directly into the DEC version of the variable?

EDIT 2: After a bit of messing around in VA, I seem to have fixed it by setting the TXT version of eddi_context_missions_accepted to 'Not Set', after converting it to DEC. If there is a better way around this, please let me know.

So, Darkcyde... When is your next update that I can get my greedy little fingers on? This proxy-coding you are doing makes my brain hurt...
 
So, Darkcyde... When is your next update that I can get my greedy little fingers on? This proxy-coding you are doing makes my brain hurt...

Probably when I get my head around this Fines and Bounties thing. It's making my brain hurt too! I have so many ideas as how to approach certain aspects though, like how to handle bounties on you becoming legacy fines.

So far, I've got the adding to store of fines, bonds and bounties incurred in one script and I'm working on the adding of bounties earned in another script because it needs to be handled a bit differently, and it's easier to work on when it's separate. All of this is just written in Notepad at the moment, so not even tested, but I trust my logic (until it breaks! lol!).

When I've got adding done, I'll work on deleting from the store, which has it's own problems. Once that is working properly, I'll start on the reporting side, and then the loading and saving. After that, it's bug hunting and fixing.

So, maybe 2-3 weeks, depending on how much time I get to spend on it and how well my ideas play out. I have a nasty feeling that some things won't be possible to do, which would make the system only partially useful, but we'll see how it goes.
 
EDIT: Please accept my apologies. Having done all the testing above, and running your suggestion to test decimal numbers again (this time with the type check), I think I may have found the reason why our coding is giving different results.

It appears that the problem actually comes from the saving and/or loading of the decimal number to/from the file, rather than the passing to EDDI. I'm going to believe this is down to my total lack of VA knowledge. Maybe you can look it over and see if & where I may have made a mistake?

As far as my limited VA knowledge is, I believe I have tried to save the decimal value to the file 'EDDI_Missions_Accepted.txt' as a number (using my Update Mission Store function in VA), but it looks like it's just the number as an ASCII character (so "7" as ASCII 55) rather than a decimal 7. When I've loaded this back up (using the System Startup function in VA), I load it as a text variable into 'eddi_context_missions_accepted', and then set a DEC version of 'eddi_context_missions_accepted' to be a conversion of the TXT token. This then seems to be sent to EDDI via the plugin as a string, so I'm guessing that it's actually passing the first TXT version and not the second DEC version. Would this be correct? And if so, how do I fix that? Can I delete the TXT version? Or is there a way to load it directly into the DEC version of the variable?

EDIT 2: After a bit of messing around in VA, I seem to have fixed it by setting the TXT version of eddi_context_missions_accepted to 'Not Set', after converting it to DEC. If there is a better way around this, please let me know.

No worries, mate. We're all figuring this out together.

Your 'EDIT 2' comment gets to the core of what's going on. Voice Attack allows multiple data types for any given variable name, so you can have a Boolean, integer, decimal, text, etc variables with distinct values and the same name. EDDI's 'setstate' doesn't know how to resolve this since you just pass it a name and apparently it just goes with the TXT data type. You setting the the TXT version of 'eddi_context_missions_accepted' to 'Not Set', allows 'setstate' to pick the DEC version that you actually want. If you're intent on maintaining your variable naming convention, I personally don't think there's any cleaner version than what you're doing, so just roll with it :)

Been studying your scripts in detail. You're using Cottle to its very limits... very good stuff.

Incidentally, what does the variable 'roundtrip' do? I see you 'adding' and 'deleting' it, but I don't see it defined or being used.:S

Thanks!
 
Last edited:
No worries, mate. We're all figuring this out together.

Your 'EDIT 2' comment gets to the core of what's going on. Voice Attack allows multiple data types for any given variable name, so you can have a Boolean, integer, decimal, text, etc variables with distinct values and the same name. EDDI's 'setstate' doesn't know how to resolve this since you just pass it a name and apparently it just goes with the TXT data type. You setting the the TXT version of 'eddi_context_missions_accepted' to 'Not Set', allows 'setstate' to pick the DEC version that you actually want. If you're intent on maintaining your variable naming convention, I personally don't think there's any cleaner version than what you're doing, so just roll with it

Been studying your scripts in detail. You're using Cottle to its very limits... very good stuff.

Incidentally, what does the variable 'roundtrip' do? I see you 'adding' and 'deleting' it, but I don't see it defined or being used.

Thanks!

Thanks Hoodathunk! :) I love programming, and particularly like to try making software do things it may not be supposed to do! ;) Smooth pixel based scrolling Marquee in Rainmeter for example. The author says it's not possible and they won't add it, but I managed it with a little bit of LUA script and a 'feature' (read: bug) in Rainmeter. :D

Are my programming methods normal or unconventional? I generally start in Notepad, writing what I want to do (so basic pseudo-code) then expand that with what functions I think I need to achieve the task, and then start to write proper code from memory, but all in Notepad still. Once I'm happy with what I have, I'll transfer it to EDDI and test it out, fixing bugs or typos in the process. It's usually more typos than bugs though thankfully! :)

The 'roundtrip' variable was kind of a placeholder (like some of the others) for an idea I had about missions that are round-trip types. Find X commodity and bring it back to this station, for example. It was going to be a Boolean so I can do something about what missions required me to come back, but that's as far as I've got with that idea at the moment, as I'm not really sure what I want to do with it exactly.

Some of the other variables I don't use either, but I thought if I added them now, then maybe other people could make use of them for their own editions of my mission store, and I can always make use of them at a later date too.

For those who are interested in my Fines & Bounties system, I've finished all of the adding and some basic reporting (for testing purposes). Next up is deleting from the store and converting bounties incurred to fines on H-jump after their timer has expired. So, only the hard stuff left! ;) I should probably try actually entering it into EDDI too, as it's all in Notepad still! [wacko]

Best regards, and fly safe!

-=] Darkcyde [=-
 
Hey Darkcyde!

I've been casually researching to code a mission route plotting script using the 'Traveling Salesman Problem' for some time and your work has inspired me into action.

No point reinventing the wheel, so I started from your code base and fleshed out a script that will build a route based on the 'Nearest Neighbor Algorithm'...


Code:
{_ MissionStoreFindRoute}
{_ Plot a NNA route for the defined systems in the mission store}

{if state.eddi_context_missions_initialised != "yes":
    {F("MissionStoreInitialise")}
}

{_ For VoiceAttack, convert TXT token into number value, as EDDI plugin can't export DEC to State variables}
{set missionstotal to cast(state.eddi_context_missions_accepted, "n")}

{if missionstotal > 0 && missionstotal != null:
    {set mission_system_array to split(state.eddi_context_mission_destinationsystem, "+=")}

    You have {missionstotal} mission{if missionstotal > 1:s} to complete.

    {_ Get all systems that have a destination}
    {set systems to []}
    {set system_count to 0}
    {for system in mission_system_array:
        {if system != "":
            {if find(systems, system) = -1:
                {set systems to cat(systems, [system])}
                {set system_count to system_count + 1}
            }
        }
    }

    {set starting_system to state.eddi_context_system_system}
    {set curr to SystemDetails(starting_system)}
    {set route_systems to []}
    {set route_count to 0}
    {set total_distance to 0}

    {if len(systems) = 0:
        No missions with a designated system.

    |elif len(systems) = 1:
        {set dest to SystemDetails(systems[0])}
        {set total_distance to round(Distance(curr.x, curr.y, curr.z, dest.x, dest.y, dest.z),2)}

    |else:
        {set cur to 0}
        {set nearest_distance to 10000}

        {_ Repeat until all systems have been visited}
        {while route_count < system_count:

            {_ Find nearest, skip if system already visited}
            {if find(route_systems, systems[cur]) = -1:
                {set dest to SystemDetails(systems[cur])}
                {set distance to round(Distance(curr.x, curr.y, curr.z, dest.x, dest.y, dest.z),2)}

                {if distance < nearest_distance:
                    {set nearest_distance to distance}
                    {set nearest_name to dest.name}
                }
            }
            {set cur to cur + 1}

            {_ Once nearest found, 'visit it' and then find the next nearest}
            {if cur = system_count:
                {set route_systems to cat(route_systems, [nearest_name])}
                {set curr to SystemDetails(nearest_name)}
                {set route_count to route_count + 1}
                {set total_distance to total_distance + nearest_distance}
                {set nearest_distance to 10000}
                {set cur to 0}
            }

        }

        {_ Add 'starting system' to complete route list & total distance traveled, then save it}
        {set dest to SystemDetails(starting_system)}
        {set distance to round(Distance(curr.x, curr.y, curr.z, dest.x, dest.y, dest.z),2)}
        {set total_distance to total_distance + distance}
        {set route_systems to cat(route_systems, [starting_system])}
        {set mission_route to join(route_systems, "+=")}
        {SetState('eddi_context_mission_route', mission_route)}
    }

|else:
    You {Occasionally(2, "currently")} have no missions at {OneOf("the moment","this time")}.
}


'Nearest Neighbor' is the simplest but doesn't produce the most efficient route, so I will continue by modifying to utilize the 'Repetitive Nearest Neighbor' Algorithm. RNNA is actually not too bad for our limitation of 20 missions.

More work to do but wanted to share with you and folks in the community. Obviously, VA commands 'Update Mission Initialise' & 'Update Mission Store' would have to be modified and scenarios where missions are abandoned would need to be addressed.

I'll also need to build VA commands and support scripts to do automated plotting. I already have a VA command that will take a 'clipboarded' system name and plot it via the Galaxy Map, so that won't be too much of a feat. Can get fancy and auto-plot the next system as soon as you undock from the previous. :)
 
Last edited:
Back
Top Bottom