Inconsistent Interface

[MarkAusten]

1) I was a bit put out (read bloody pissed off) when the latest update stopped my EDDI Voice Attack scripts from working. Without warning you have removed the 'Jumping' event and not replaced it with anything. Yes, I know that I can check for the environment being 'Witch space' in the 'FSD enabled' event but this is a pain especially when you have an 'Entered supercruise' event but not a corresponding 'Entered hyperspace' event.

Please add the 'Entered hyperspace' event to make your API consistent.

2) Additionally, you have, again without warning, removed a number of event variables so that they are not available in the VA scripts. I understand that you are trying to make EDDI a Voice Attack audio replacement, but since you do not know what your users do with the VA EDDI combination, this is a pain in the ass. I use the VA output screen to write data from EDDI so that it is still available after the audio has completed. Being partially deaf I sometime do not hear the audio correctly and the visual output on the VA log allows me to retain that.

But not if you keep on removing it!

Please make the entire event objects available to the events in VA, not just those variables that you think should be there. Within EDDI the 'FSD enabled' event can refer to any of the public properties of the system, target and event objects yet you restrict VA to the system name, the target name and the target stellar class. My scripts use more than these, therefore this latest updated is a breaking update and has reduced the functionality that I had previously.

Your code appears to be well written and refactored, therefore I do not expect it to be particularly difficult for you to replace the individual variable names in the VA variable parsing routine and the variable value extraction with a generalised object.property definition using reflection to populate the resulting variable and type references. Especially when you consider that that your 'language' parser already does this for the EDDI scripts. This would allow the 'FSD enabled' VA event to refer to all the properties of the system, target and event objects in the format of {XXX: object.variable} Where XXX is the appropriate type name. So {TXT: fsd enabled event.stellarclass} or {INT: fsd enabled system.visits} and so on.

As for this being a breaking change, well yes it is. So what? That did not seem to worry you when you released v2.3.0. If you are really clever, and I suspect that you are, then you could even add the new variable referencing and deprecate the old method. Deprecate, not remove.

Sorry, I'll get off my soapbox now.

Thanks.

[Darkcyde13]

I would never presume to speak on behalf of the author, however....

1. 'Jumping' event was depreciated, and replaced with 'FSD Engaged' and 'Jumped' which do exactly the same job. I believe this was due to FDev making changes to what 3rd party apps have access to. This has been the case for some time, and all the info has been available on this site since the change was first introduced into the betas months ago.

2. Several things are no longer available to 3rd party apps, EDDI included, so you should probably vent your frustration in the direction of FDev. As far as I can tell, nothing has been removed from EDDI that is still available to 3rd party apps. Again, this has been known for some time.

You are aware that there is a 'Repeat last speech' function in EDDI, right? This can be called at any time after speech has finished and will repeat the last block spoken. If this is not to your liking, you can easily set State variables for VA to use, that are available until you shut EDDI down. You can also use VA to save and load these to/from HDD if you need them to persist thorough EDDI restarts.

You should also know that the author has stepped away from EDDI for the time being, and may or may not return to it, save for major bug-fixes. You sound like you know C#, so you could always message Cmdr McDonald and offer your services to maintain EDDI (he has asked if anyone wants to take over). If I knew C#, I'd offer in a heart-beat. Check out the main EDDI forum thread at Frontier for more info.

[MarkAusten]

You would never presume to speak on behalf of the author, but you are going to anyway.

Okay so....

1) There was no indication at all for people updating using the EDDI interface that anything was going to be deprecated or removed. Nor was there an offer to 'read the update notes'. The update is pretty silent. So it may have been deprecated but for all intents and purposes it was not as far as the end users were concerned. End uses do not regularly visit the GitHub pages to see what is going on, they are too busy playing Elite.

1) FSD Engaged and Jumped do NOT replace the Jumping event. FSD engaged occurs when you are going to super cruise OR hyperspace. Jumped is the event the occurs when you re-enter super cruise from hyperspace. The old Jumping event occurred when you entered hyperspace and hence the call for an 'Entered hyperspace' event to match the 'Entered super cruise' event. This is certainly available, other 3rd party applications show it, EDDI should be able to so the same. As I mentioned you can 'simulate' the event by checking for Witch space in the FSD Enabled event.

2) The things that are not available to VA have been REMOVED or changed at the very least. They are available to the EDDI scripts in the same event but not to the VA scripts. Visit number for example. That used to show the visit number of the target system once the FSD was engaged, now it show the visit number of the current system.

The repeat last speech block is a) insufficient when two or more speech blocks have been output an b) requires time. Displaying the required information on the VA output screen is a far better solution for those of us who have hearing problems. It also only takes a glance to see the information and remains there for some time.

I was unaware that CMDR McDonald had stepped away from EDDI however I am not surprised. This normally happens when a good app is only supported by one person, the burden becomes to much to continue, and it is a great burden.

I make a living by programming in c# amongst other things but I would not take on this, or any other, project for the same reasons that the author no longer wishes to continue with EDDI.

I also do not wish to have to deal with people like me. There is a reason that my employers make sure that I'm kept well away from our clients.

I may however, fork the project for my own purposes.