[REL] sh4speech - voice command for SH4

[billko]

Originally Posted by ferg

You're basically right, Billko. The problem does not affect "stock", but it does affect "trigger maru" (thus my own modified "trigger maru" also has the problem). However, I stand by my description of it as a bug since it occurs with an included data set. As far as I know, I haven't modified anything in the "trigger maru" set. I'm going to check that right now by snagging the file again and overwriting the "trigger maru" files to confirm it.

Edit: Confirmed. The problem exists in the provided "trigger maru" files. I'll see if I can figure it out. Thanks for the clue that it works with the stock data! With any luck I should be able to fix it.

Mucking around inside the changelog shows that the last version of TMO supported was 1.6. Also, the last version of SH4Speech seemed to have a different way of handling the TMO CSV files and warned of compatibility issues. (see first page, this topic)

Again, people here probably have updated CSV files that could save a lot of headache

I hope this helps.

Bill

[ferg]

Originally Posted by billko

Also, the last version of SH4Speech seemed to have a different way of handling the TMO CSV files and warned of compatibility issues. (see first page, this topic)

First page of this topic does not contain "TMO" or the phrase "trigger maru". I can't seem to find the reference. I'm not sure what you mean about a different way of handling the TMO CSV files.

There are slight differences between running sh4Speech in "stock" and "trigger maru" modes in the code, but nothing that looked like it would break anything. Looking at the source, I only noticed that torpedo tube handling is somehow different (probably to handle different tube cycling in TM). I've got tube cycling working well enough for me at this point, so that is not a concern.

Again, people here probably have updated CSV files that could save a lot of headache

Totally, but I'm not sure anyone has put up with the headache and done it. If they have, why is there nothing on minsc's download page or in this thread? A Google search for "sh4speech tmo 1.9" finds only my own post asking if anyone has done an update. I tried the more general "sh4speech tmo" too, but no dice. If I can get it working to my satisfaction, I'll happily make my updates available to others.

[billko]

Originally Posted by ferg

First page of this topic does not contain "TMO" or the phrase "trigger maru". I can't seem to find the reference. I'm not sure what you mean about a different way of handling the TMO CSV files.

There are slight differences between running sh4Speech in "stock" and "trigger maru" modes in the code, but nothing that looked like it would break anything. Looking at the source, I only noticed that torpedo tube handling is somehow different (probably to handle different tube cycling in TM). I've got tube cycling working well enough for me at this point, so that is not a concern.



Totally, but I'm not sure anyone has put up with the headache and done it. If they have, why is there nothing on minsc's download page or in this thread? A Google search for "sh4speech tmo 1.9" finds only my own post asking if anyone has done an update. I tried the more general "sh4speech tmo" too, but no dice. If I can get it working to my satisfaction, I'll happily make my updates available to others.

Darn it. If I had that mod I would do the same.

[Chromius]

Has anyone got some modded files that work with RFB 2.0 (1680x1050) just trying to save myself time.

[ferg]

OK, well, this "damage control team" problem is a strange one. It turns out it has nothing to do with the CSV files. I thought the problem wasn't appearing in stock until I remembered that I had left the stock batch file at 1024x768. When I changed it to 1440x900, it evidenced the exact same behaviour. There is a bug in the script itself for that resolution.

I don't know Perl and I don't have a runtime installed on my computer, so it's a bit hard for me to debug. Nevertheless, I have a powerful suspicion that the script is going awry in the MouseMoveAbsPix subroutine. It enters an until() loop on line 811, and I think the condition never evaluates true.

But why it's happening, why I've only seen it triggered with this one command, I have no idea. It's possible that it occurs with other commands as well. I probably haven't used every single command defined. Another command with the same co-ordinates ("Aim For Weapons", ID=543) works fine.

[billko]

Originally Posted by ferg

OK, well, this "damage control team" problem is a strange one. It turns out it has nothing to do with the CSV files. I thought the problem wasn't appearing in stock until I remembered that I had left the stock batch file at 1024x768. When I changed it to 1440x900, it evidenced the exact same behaviour. There is a bug in the script itself for that resolution.

I don't know Perl and I don't have a runtime installed on my computer, so it's a bit hard for me to debug. Nevertheless, I have a powerful suspicion that the script is going awry in the MouseMoveAbsPix subroutine. It enters an until() loop on line 811, and I think the condition never evaluates true.

But why it's happening, why I've only seen it triggered with this one command, I have no idea. It's possible that it occurs with other commands as well. I probably haven't used every single command defined. Another command with the same co-ordinates ("Aim For Weapons", ID=543) works fine.

wow, i'm not sure why it would be resolution-related because it's all just calculating ratios for mouse movement, but there's no denying there's something amiss! i'll have to think about that one. hopefully minsc will be by soon to bring to light the solution

[minsc_tdp]

Ok guys this seemed like the best place to post this.

If anyone is having trouble with the new voice command system for SH5, and used my shSpeech, and you want to try it with SH5, check out this webpage as it has updated files for SH5.

http://knepfler.com/shSpeech

These were created by 7Infanterie19 not me, so please no emails! Unfortunately I have no time to support this or do really anything further on it, but 2.54 is quite stable. I haven't tested these new CSVs, so, good luck everyone!

Now, what's all this about damage control... I promise to try to look when I get a chance!

[minsc_tdp]

Originally Posted by ferg

OK, well, this "damage control team" problem is a strange one. It turns out it has nothing to do with the CSV files. I thought the problem wasn't appearing in stock until I remembered that I had left the stock batch file at 1024x768. When I changed it to 1440x900, it evidenced the exact same behaviour. There is a bug in the script itself for that resolution.

I don't know Perl and I don't have a runtime installed on my computer, so it's a bit hard for me to debug. Nevertheless, I have a powerful suspicion that the script is going awry in the MouseMoveAbsPix subroutine. It enters an until() loop on line 811, and I think the condition never evaluates true.

But why it's happening, why I've only seen it triggered with this one command, I have no idea. It's possible that it occurs with other commands as well. I probably haven't used every single command defined. Another command with the same co-ordinates ("Aim For Weapons", ID=543) works fine.

It's very strange that it happens only for that one command. I don't recall there being anything special about damage control.

Taking a quick look, I see it has an ID of 55 in the Stock CSV set. I also see some trigger maru specific code that does a general text inspection at the CSV set name to determine if it has "trigger maru" in it, and if it does, it treats 55 special during the tube specific code, which is weird because in my set, trigger maru damage management is still 55, in other words, 55 wasn't repurposed to tubes or anything in tm. So there could be a problem there.

One fix might be to make sure your CSV set name as referenced in the launch bat file doesn't say "trigger maru" which would cause it to be treated as stock (of course if you're used to running in TM mode, that might cause a bit of a shock.) Another option might be to change all instances of ID 55 to some other obscure number as mentioned above. Whenever you suspect something weird about the ID, change it, and be sure to change it in every CSV it might be referenced in, in both the ID column and the PARENT column.

Generally speaking most testing was done in stock, and TM was kind of tacked on and was never really fully vetted as well as it could have been.

Hope that's clear enough and leads you to a solution... sorry I can't even test this as I don't have a working microphone at the moment. I do on my laptop, if I have time I will try tomorrow!

[ferg]

Sorry, I am just logging off and heading to bed or I'd write a proper reply, Erik. I'll get to that tomorrow or Thursday depending. Thanks for taking the time to post.

I just wanted to share that I installed ActivePerl and enabled the debug output you had in that until loop. This is what I found interesting:

Mouse clicking at 336,871 for Damage Control Team (id=572)
17476==15292&&59637==63423
17039==15292&&60394==63423
16602==15292&&61151==63423
16165==15292&&61909==63423
15728==15292&&62666==63423
15291==15292&&63423==63423
14855==15292&&64181==63423
...and off it goes into an endless loop...

The second to last line is where the until loop is intended to exit, but of course it doesn't because 15291 is not 15292. I only looked at it for a minute or so, but off the cuff it looks like a rounding error to me.

[billko]

Originally Posted by ferg

Sorry, I am just logging off and heading to bed or I'd write a proper reply, Erik. I'll get to that tomorrow or Thursday depending. Thanks for taking the time to post.

I just wanted to share that I installed ActivePerl and enabled the debug output you had in that until loop. This is what I found interesting:

Mouse clicking at 336,871 for Damage Control Team (id=572)
17476==15292&&59637==63423
17039==15292&&60394==63423
16602==15292&&61151==63423
16165==15292&&61909==63423
15728==15292&&62666==63423
15291==15292&&63423==63423
14855==15292&&64181==63423
...and off it goes into an endless loop...

The second to last line is where the until loop is intended to exit, but of course it doesn't because 15291 is not 15292. I only looked at it for a minute or so, but off the cuff it looks like a rounding error to me.

hey nice catch!

[minsc_tdp]

Originally Posted by ferg

Totally, but I'm not sure anyone has put up with the headache and done it. If they have, why is there nothing on minsc's download page or in this thread? A Google search for "sh4speech tmo 1.9" finds only my own post asking if anyone has done an update. I tried the more general "sh4speech tmo" too, but no dice. If I can get it working to my satisfaction, I'll happily make my updates available to others.

Nobody has ever bundled up an updated set of CSVs for versions of Trigger Maru past 1.6, hence there's nothing on the webpage about it. You might be the first to have bothered. PM me if you manage to get it working and have all your CSVs organized into a zip and I'm happy to post to the site.

That damage control bug is really scary. Seems like it is locking up - I'd bet voice.exe is running 100% CPU when this happens. Very ugly.