search

EDCD / EDDI

Companion application for Elite Dangerous
Other
444 stars 81 forks source link

VoiceAttack events delayed #1155

Closed nepomuk16321 closed 5 years ago

nepomuk16321 commented 5 years ago

EDDI version in which issue found

EDDI v 3.3.4-rc3 VA v 1.7.3

Steps to reproduce

  1. [give the fullest and most reproducible steps you can]
  2. [the more reproducible, the better our chances of fixing it]

Expected

Okay, what do I mean? When a hyper-jump ends, you land right in front of the sun. In earlier versions the event ((EDDI jumped)) was now executed immediately or connected to VA to the other. Now the whole system description is passed on. And only when this is finished VA recognizes the event. That's not wrong now but you can't use the event so well anymore, e.g. for the command STOP >> Exploration Scan.

Translated with www.DeepL.com/Translator

Observed

First pass the event ((EDDI jumped)) to VA and then output the system description.

Investigation

[any investigation you have done, regression tests against earlier versions, etc]

Thank you for your help, nepomuk16321

Tkael commented 5 years ago

We've noticed the jumped event can occasionally be delayed, but I'm not sure I understand what you are trying to say completely. Can you give a more specific example?

nepomuk16321 commented 5 years ago

Ok, I'll try. Unfortunately my english isn't very good. I hope deepl can do better. :-)

When you jump into a new system, you land directly in front of the sun. If you don't slow down now, you fly into the sun. Braking can be automated with the EDDI Event ((EDDI jumped)) and VA. Now the event ((EDDI jumped)) arrives much later at VA. First the system is described via EDDI and then the event ((EDDI jumped)) is transferred to VA. You cannot take the event ((EDDI jumped)) to stop after the jump. This is how it looks to me now.

Translated with www.DeepL.com/Translator

I hope you understood what I mean. Thank you very much for your effort.

Greetings nepomuk16321

Tkael commented 5 years ago

I suspect the primary cause here is the high number of variables that we set in VoiceAttack before we generate ((EDDI jumped)). Standalone seems to be much snappier in responding to this event and this event changes a lot of variables that need to be re-set in VoiceAttack. I'll have to do more testing to confirm and think about ways to make this process more efficient.

Tkael commented 5 years ago

I just tested again this evening with the latest release. Response time appears to be very much improved. Please re-test using the latest release and provide feedback? Edit: Still getting delays while speech is queued. Response time is good when speech is not queued.

nepomuk16321 commented 5 years ago

Yes, that's exactly it! :-) Before describing the system, the jump (with transfer of the variables) should be finished. This could help.

Darkcyde13 commented 5 years ago

I'm getting this problem when loading up my game.

Using EDDI standalone (V3.3.6), when I load my save, the Commander Continued event triggers as soon as I see my spinning ship, and all works normally.

Using VA, when I load my save, I fully load into game and am sitting in my cockpit for about ~23 seconds before the Commander Continued event triggers.

After that, everything works normally. For me it's just the loading into game that is hugely delayed.

When I start VA. I make sure it's fully ready, having shown these messages, before I load my ED game:-

15:05:39 - Plugin 'EDDI 3.3.6' initialized. 15:05:26 - The EDDI plugin is fully operational. 15:05:24 - Profile startup : 'System Startup' 15:05:23 - Plugin support enabled.

Going back to v3.3.4 and I don't get the delay in VA anymore, it's only with V3.3.6. I also noticed that with V3.3.6, the 'Plugin Initialized' message takes longer to appear.