Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variables {DEC:System X} {DEC:System Y} {DEC:System Z} for VA are not being populated on first entry into undiscovered system #1666

Closed
MalicT opened this issue Jan 3, 2020 · 1 comment · Fixed by #1668
Assignees
Labels
6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour.

Comments

@MalicT
Copy link

MalicT commented Jan 3, 2020

EDDI version in which issue is found

3.5.2

VoiceAttack version in which issue is found (as applicable)

1.8.3

Steps to reproduce

Create VA command that outputs {DEC:System X} {DEC:System Y} {DEC:System Z} to log
Enter system that has never been visited, by yourself or is on databases.

Expected

{DEC:System X} {DEC:System Y} {DEC:System Z} would return coordinates in system

Observed

{DEC:System X} {DEC:System Y} {DEC:System Z} returns as NOT SET NOT SET NOT SET

Investigation

{DEC:System X} {DEC:System Y} {DEC:System Z} is not populating on first entry into system, however
{DEC:Jumped X} {DEC:Jumped Y} {DEC:Jumped Z} are

https://github.com/EDCD/EDDI/wiki/Jumped-event lists system X, Y and Z to be populated on the jumped event, and everything else is, except those three. Am using premade scripts that had all the jumped variables listed to output everything in the jumped event.

The {DEC:System X} {DEC:System Y} {DEC:System Z} populate only after the first entry into the system, or if the system is in the databases (EDDB/EDSM)

@Tkael Tkael self-assigned this Jan 4, 2020
@Tkael Tkael added 6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour. PR submitted A PR has been submitted, but not accepted yet. labels Jan 4, 2020
@Tkael
Copy link
Member

Tkael commented Jan 4, 2020

Writing variables to VoiceAttack can be CPU expensive so we only want to re-write data that has changed. It looks like this comes down to the way that we've been evaluating data for equality prior to posting a variable update to VoiceAttack. PR submitted.

@richardbuckle richardbuckle removed the PR submitted A PR has been submitted, but not accepted yet. label Jan 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants