So I've been playing around with EDDI and VA trying to tweak the relative...chattiness, and I was wondering if anyone else has given something like this a go.
I started out by just doing this to the FSD engaged script:
Code:
{if !system.visits || SecondsSince(system.lastvisit) > 14400:
{set times to 1}
|elif system.visits > 5:
{set times to 5}
|else:
{set times to system.visits}
}
{if !system.population:
{OneOf("This system is unpopulated","There is no human presence here", "Humans have yet to colonise this system")}.
|else:
{Occasionally(times,
F("System report"))
}
}
Basically, it uses the # of times I've visited a given system to adjust how likely EDDI is to give me a system report for a populated system, capping the number at 5 so that I've always got at least a 20% chance of hearing the report. It also checks to see if it's been more than 4 hours since I've visited a system; if it has been, I'm guaranteed a system report.
I think this works okay, but I haven't had a chance to really play with it much.
Thing is, it got me thinking about the potential to use VA to set a state variable with a value from 1-10 called something like global_verbosity, which could then be used by every report to control the level of detail given by EDDI. (You could also have individually set levels of detail for different reports, defaulting to global_verbosity if the individual verbosity level hasn't been set.)
I haven't really worked through it yet, as I've just now downloaded Darkcyde's EDDI kit to examine, but I was thinking that things like Body report, etc. could have their relative levels of detail adjusted on the fly this way.
Basically, you'd end up with something like this (I think):
Code:
{if !state.bodyreport_verbosity:
{set state bodyreport_verbosity to state.global_verbosity}
}
{if state.bodyreport_verbosity <= 1:
((bare minimum level of detail; say only the name, gravity, and landable values))
|elif state.bodyreport_verbosity <= 5:
((as above, but also terraformstate, volcanism, greatmaterials))
|elif state.bodyreport_verbosity <= 7:
((as above, but also goodmaterials))
|else:
((full report))
}
This is just spitballing, mind you, so there's probably a smarter way to do this. Maybe it would make more sense to set a verbosity threshold in the conditional for each section like this:
Code:
{if len(greatmaterials) > 0 && state.bodyreport_verbosity > 4:
....
}
Also, at the risk of this being way too long, instead of calling EDDI's speech function from each command in VA, which is how the first .vap I found works, I set up a silent VA command that gets passed the name of the command that called it and which then references different .txt files on my hard drive to respond based on who called it. Lets me keep all my responses stored in a single folder and just edit them from there, which makes life a lot simpler. (Editing in VA is not the most fun thing.)
Not sure how well this will work, but here's a go at what that command looks like in VA:
Code:
((set the path for VA to find the .txt files))
Set Text [TTSResponsePath] to 'C:\Users\ChrisL\Documents\VA Project\Responses\' (save value to profile),
Set small int (condition) [RND] value as random from 1 to 20,
Begin Boolean Compare : [MuteActive] Equals False,
((if not muted, check specificity))
Begin Small Integer Compare : [RND] Is Less Than Or Equals [AI_Specificity],
((if RND <= specificity then use specific/long responses))
Begin Boolean Compare : [Response_Success] Equals True,
Set Text [TTSResponseFile] to [Response_Caller],
Else If Boolean Compare : [Response_Success] Equals False,
Set Text [TTSResponseFile] to [Response_Caller] (Replace '.txt' with '_Failure.txt'),
End Condition,
Else,
((else if RND > specificity then use generic/terse responses))
Begin Boolean Compare : [Response_Success] Equals True,
Set Text [TTSResponseFile] to 'Generic_Success.txt',
Else If Boolean Compare : [Response_Success] Equals False,
Set Text [TTSResponseFile] to 'Generic_Failure.txt',
End Condition,
End Condition,
((build the path & filename into Script, then send Script to EDDI via Say,))
Set Text [Script] to [{TXTCONCAT:TTSResponsePath:TTSResponseFile}],
Execute external plugin, 'EDDI 2.3.1' ,
Else,
((if mute is active, respond with a sound rather than TTS))
Begin Boolean Compare : [Response_Success] Equals True,
Play random sound (from directory: C:\Users\ChrisL\Documents\VA Project\Responses\Affirmative Sounds),
Else,
Play random sound (from directory: C:\Users\ChrisL\Documents\VA Project\Responses\Negative Sounds),
End Condition,
End Condition,
Set Text [TTSResponseFile] to [Not Set],
Set Text [Response_Caller] to [Not Set],
Set Boolean [Response_Success] to [Not Set]
Response_Caller is set by the command that called this one...so, GalNet_HealthReport or LandingGear_Deploy. Response_Success is something I've been playing with...if I tell VA to extend my landing gear and they're already out, Response_Success would be false. It defaults to TRUE if it hasn't been set though, since there's no way for VA to know if something like the GalNet commands didn't work.
This adds variety to responses from EDDI/VA by allowing the system to randomly choose a generic response to a command (eg "Confirmed," "Acknowledged," etc.) or a specific one ("Accessing GalNet," "Deploying landing gear," etc.) without me having to set those responses up in every single VA command individually.
So...yeah. I guess I've been more focused on improving EDDI/VAs response variety than I have on core capabilities.
