alternerdtive / voiceattack-profiles Goto Github PK

related: #12, #18

Jumping with a carrier does not generate a Jumped event, but a Carrier jumped one.

Right now you have to re-run the profiles’ startup command after EDDI has been initialized (or make sure you switch to it afterwards). EDDI has a VA initialized event, so I should probably use that, right?

I will work on it based on the (also still missing :D #7) RatAttack profile once the seals have moved from using Discord to using IRC.

I can’t be arsed to build a profile / sanitise the stub I have for a temporary chat solution and unfinished SOP.

Silly me forgot some ~~ in a variable name :)

Delays and pauses you need to execute between e.g. key presses to navigate the game’s UI are highly specific to your personal PC’s specs and configuration, whether you are playing pancake or VR, etc.pp. So there should probably be a way to set them globally instead of having to fiddle with every single command if they don’t fit your needs.

That’s something I’ve been too lazy to do until now, but since IMO the profiles are pretty much feature-complete by now I might as well do it, right?

• how to import profiles
• how to include profiles
• how to change commands (e.g. to set configuration variables)
• how to install plugins
• how to install the scripts

… to find out if I “need” to FSS the system to get everything onto EDDN.

Will need another external script because I can’t be arsed to do .Net for VoiceAttack plugins. Probably should do a proper EDSM API wrapper first, too.

See alterNERDtive/elite-scripts.

How to:

• install the VoiceAttack plugins
• import the profiles
• work with an extra profile including the profiles
• install the python script(s)

EDDI gives an import link for coriolis which is … rather long.

I don’t know if I can find a sensible way to provide a short link, but I guess I’ll look into it when I find the time.

Title. Probably requires refactoring of the Jumped event to do properly. Also requires EDDI 3.5.3 beta to work, but shouldnn’t break anything on 3.5.2.

While I have already removed the HOTAS button stuff, there’s still some left. E.g. Fuel Rats IRC nick changing (might be worth generalising and integrating into RatAttack?).

Title. I can think of some cases that needs commands to be executed in order, but where I could move on to the rest of the running command before they are all done.

I’ll have to check all commands T.T

I should write some decent documentation at least for the most important features.

It’s also missing a notice about having to get the elite-scripts for certain features.

https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#cargodetails
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#humanise
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#jumpdetails
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#list
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#trafficdetails
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#oneof
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#occasionally
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#pause
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#startswithvowel
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#systemdetails
https://github.com/EDCD/EDDI/blob/beta/SpeechResponder/Help.md#transmit

Currently it’s basically hard coded into that. Pry it out, make it separate, have the scan event call it.

Should fix not being able to re-do the comparison when the first one errored out. Also makes it able to be run on demand.

Right now, 7j is announced. It’s not in the list, but 75 is; and since the test is for the current jump count to be a substring of the announceJumpsLeft variable, it triggers on 7.

Right now I’m using a modified version of the RatSqueak profile from the FRKB. It’s not in a state to be published or even usable for other people right now.

It’s next on the list.

From the 1.8.6 changelog:

 -  Added, 'Passed Values' feature to, 'Execute Another Command' and 'Enqueue Command' actions.  This allows
    for you to specify (via semicolon-delimited lists) sets of values to pass to commands.  The values that
    are passed to the commands are converted to a standard set of command-scoped variables that are accessible
    only to the executed command.  Think of this as being able to have parameters for commands o_O

Currently it’s a profile-wide setting to target Elite. A) that’s clunky, b) that’s not necessary for all commands and c) that doesn’t seem to be working properly, leading to things like “cruise” being triggered by me just typing furiously (and VA pressing lots of backspaces. Fun.).

Command-level this will hopefully both work better and be more granular.

Since the list of systems is limited, should be doable.

From the changelog:

 -  Added advanced/experimental command option, 'Do not execute this command if it is already
    running'.  This keeps the current command from executing if another instance is already
    in progress.
    
 -  Added option, 'Do not execute this command if it is already running' to the, 'Execute Another
    Command' screen.  This will prevent a command from executing if it's currently running.

Thinking about longer-running commands with little feedback and stuff that should literally only run as a single instance, like plot neutron route.

Sadly there’s currently no way to work around that. It’s a limitation of how EDDI passes variables over to VoiceAttack; it can’t properly translate the material object.

That also applies to various other areas. For example I was thinking about adding an alert for FSSing bodies with icy rings. The ring composition object runs into the exact same problem.

No ETA.

So EDDI can pronounce stuff like system names properly if they are enclosed in this {P <string>} literal. After I filed complaints about “Sagittarius A Asterisk” they were kind enough to add support for that if you pass stuff from VoiceAttack.

Now I only need to use it … which means going through every. Single. Invocation. Of the stuff :)

• manure madness™ helper thingy
• next system scoopable check

… which is going to be the recommended way to do anything going forward, for ease of customization.

While initially I had to adjust the output of the neutron plugin to 1 waypoint ahead, that seems to now be wrong … not sure what’s the problem right now, will have to check.

I’m currently passing the string directly as a text parameter to .talk. That means I have to enclose the entire string in ". That in turn means I have to quote the Cottle text in '. And that breaks again if the string enclosed in ' contains a ' character.

Fun.

Possible fix: pass as variables, use " for the Cottle thing, and double escape { and }. Not looking forward to that.

The other profiles are already doing that properly (because they have to check if EDDI is used or not), but there’s no real reason not to do it properly here, too. Just to make sure that the global SCRIPT variable is only fiddled with right before the plugin call.

This will involve fiddling with profile scoped variables and reading/writing them from/to the profile.

I will need to get clarification from the VA devs first because how those things work with included profiles is not touched in the VA documentation.

The Ship interdicted event handling has been buggy at best and not working at worst for now. I should probably debug that.

Could also implement the NPC interdiction commenced event.

Needs further investigation.

So I’ve been struggling with finding a better way to pass RATSIGNALs from IRC to VoiceAttack than using the Windows clipboard for ages now. Sadly you can’t pass strings to VA via command line parameter like you can with VoiceMacro.

I should investigate if using a file is feasible:

1. IRC client waits for $file to disappear
2. IRC client writes RATSIGNAL string to $file
3. IRC client invokes VA with the proper command
4. VA reads $file, parses the signal and removes $file

I have the voice attack profile installed, and have the scrip in AdiIRC.

The scrip looks like this:

on :TEXT:RATSIGNAL - CMDR(??_SIGNAL):#fuelrats:{
/mkdir C:\users\Parker\appdata\roaming\RatAttack
/handleratsignal $1-
}
alias handleratsignal {
if ( $exists(C:\users\Parker\appdata\roaming\RatAttack\ratsignal.pipe) ) {
/sleep 1 /handleratsignal $1-
}
else {
/write C:\users\Parker\appdata\roaming\RatAttack\ratsignal.pipe $1-
if ( $away ) {
/run -h "C:\Program Files (x86)\VoiceAttack\VoiceAttack.exe" -nofocus -command "RatAttack.getInfoFromRatSignal"
}
else {
/run -h "C:\Program Files (x86)\VoiceAttack\VoiceAttack.exe" -nofocus -command "RatAttack.announceCaseFromRatSignal"
}
}
}

I cannot figure out why it is not triggering the commands within voiceattack. The ratsignal.pipe file gets generated perfectly, and read when voiceattack first opens, but it will not trigger the commands for some reason.

Include some pretty pictures or something.

A Route details event with type update is triggered by EDDI automatically on handing in missions. With current logic that leads to a “no results found” TTS message.

There might be other triggers. It’s probably the best way forward to explicitly only process the types I have handling for and explicitly do nothing for everthing else.

Not entirely sure why that happens, needs investigation. Somewhere between EDDI clearing the variable and the command accessing it something goes wrong.

Triaging for now, no ETA.

So if the target is not in the router’s db, you need to find the nearest system by coordinates. Wouldn’t it be great if you didn’t have to input them by hand⁈

Unfortunately the FSDTarget journal entry does not have coordinates. EDDI has Next system x through z, but pulls that data from EDSM.

As a workaround I can use that for now, at least that can handle systems that have been sent through EDDN after the neutron routers index has been built (happens daily, so lagging behind up to ~24h).

In addition to current range, jumpdetails can also tell you how many jumps you have left on your current fuel; at least that’s how I read it :)

That might be a useful tidbit to include in low fuel warnings.

Calling it might also be useful in instances where the current jump range status variable hasn’t been set for some reason (e.g. sometimes when loading into the game, before the first instance change). Needs more investigation on that, though – might be limited by the same constraints.

Currently, both plotting (with new target) and re-plotting (with the same target) while on a neutron trip will reset the trip timer. Kind of not what it’s supposed to do.

I’d like to have some form of heads-up on when the pad lockdown will come into effect. Long-term I’d like to have some kind of timer and/or be able to ask “how long until pad lockdown?”, short-term I guess I’ll just have announcements every couple minutes.

Needs investigation.

Apparently importing a profile that already exists (now?) imports it as <name>-1 instead of overwriting commands. I’ll need to update the update instructions to reflect that:

1. delete profiles
2. import profiles
3. fix includes

:-/

see #47

Yes. I know. Use at your own risk.

Eventually it will be in a better state, but I wanted to get it out there for reference.