I figured that, so I don't rely on it. If the torpedo room didn't "hear" me, I hit the "w" to make sure the command goes through. From the documentation you provided, I figured it was absoultely essential to do this or everything would get out of sync. And, of course, the few times I forgot, I went to "manual override" until I was out of the firefight, then "reset tubes" - after manually setting the tube to tube one, of course.

I hope that the delay thing will fix it. My theory is that when it starts to lag, the program starts loading the keyboard buffer more quickly than SH4 can read it; therefore, some of the "keystrokes" are overlooked. The other theory is that SH4 clears the keyboard buffer right before it reads it, instead of right after it reads it. While that seems to be just semantics, it comes into play when the game slows down significantly because the window of opportunity where the player can input a keyboard stroke and have it be cleared "accidentally on purpose" gets pretty big. A variant of that theory is that the computer slows down so much that the keyboard interrupt isn't serviced until it's too late and the SH4 dumps the keyboard input for the reason above. I dunno, timing gets hairy when the computer is under duress like that. The last theory would explain why, when deep in time compression, the mouse and keyboard become fairly unresponsive, and may be the reason why keyboard strokes are lost to me when the graphices slow the game down.

I hope this has given you some insight on how you might make this super mod accomodate slow rigs like mine. I say it's optional because there's nothing wrong with the mod; it's something wrong (read: slow) about some of the computers it's being run on.

Bill

Yeah I hear ya on the lag thing. That's why my first thought was to make a general multiplier that slows everything and is configurable. I've learned my lesson with other similar tools like this I have written - don't hardcode the delays. So I am using global variables at the top that are easy to adjust, no delays are hardcoded (though from y'all's perspective, it is, since it's currently not changable. So that'll get fixed.)

2.22 posted with delay multiplier, see changelog!

Off topic post: I have a poll/raging argument going on that I need everyone's input on. Link is here.

http://www.subsim.com/radioroom/showthread.php?t=122118

It is right up your guys' alley since it's about the physics of water pressure on an underwater object with chambers and seals, just like a sub.

hi, i've just installev v2.22 of the speech recognition program. I'm running it in Windows Vista. I have to say well done guys I've been looking for something like this ever since I played Sub Command with voice controls.

I have to say, it works perfectly...on my desktop. When I start it up, I get a little console page and a small microphone on my taskbar. All's good. I hold down "print screen" and talk and the order shows up in the console no preoblem, perfect accuracy every time.

HOWEVER, when I start the agme (leaving the console running in the backround) it's very hit and miss. Half the time it ignores me. The strange thing is... if I minimse the game and look at the console, it has recognised every single command perfectly and executed it... but the game hasn't registered!!!! There are also times when its opens internet explorer or dragged icons across my desktop, or something like that.

I am running Trigger Maru 1.6.2 but I didn't think this would be a problem because I am running "sh4speech-trigger maru.bat". It gets the stations right and remembers the Y key for the aft tubes, so im sure its mapped correctly.

Someone please help:cry: I want to give you all a massive pat on the back for this mod but I'd like it to work properly first, lol.

Unfortunately, I think that not much can be done at this point because the graphics are slowing the system down enough so that it starts missing keyboard (and mouse) interrupts. A variable was introduced in the latest version to try to slow down keyboard input from the mod to avoid sending keystrokes too quickly in succession, but that's only part of the problem. If you notice the way *you* use the keyboard when looking through the periscope or on the bridge, I bet one thing you do is hold the keys down longer. You hold them down until you see a response from the game. Unfortunately I don't think it would be an easy task to put a watchdog on the thread in the game used for keyboard and mouse input. One place I notice it misses for me is when selecting and opening/closing torpedo tubes while looking through the attack periscope. If you go to a more static screen such as the map or the torpedo management screen, you'll find that it executes flawlessly. I'd say that if you experience any significant frame rate drops in a view, you'll also experience "missed" commands. You just have to accept that your crew is hard of hearing - too many depth charges, I suppose. ;)

Bill

i guess that kinf of makes sense. I edited the delay variable to 1.2 and then to 1.5 but I didn't get much better. one thing i DID notice with a little further testing is that mouse inputs execute flawlessly in all views. It only misses keyboard inputs. But i have to say you're right about missing tube orders in periscope view. that's something to try I guess, going to map (but then, i can't shout "map" becuase it ignores me, lol)

in a way, it's not too bad becuase hitting a key is the easy part compared to clicking around, and its still a really cool mod. I'll test it a bit more.

just as a check, what value do you use on the delay setting?

And, no, screaming louder won't help, I tried that when I had FPS problems myself:oops:

LOL guys. But seriously, I've found that the delay thing doesn't help me much at all because I have a lower-end computer and I don't think anything short of a major upgrade will help.

When firing torpedoes from the attack persicope view, I find it more useful to say "next tube" bacause it almost always gets the first voice command. If it SH4 *doesn't* recognize the "next tube" command, but you verify that it was sent, *manually* cycle to the next tube so that the speech application doesn't lose synch with the game. Before getting in a firefight, if I need to do something like open tube doors, I go to the torpedo management screen and execute the commands there. And yes, I'm that lazy.

Bill

Not to change the subject, but.....
 

I've run into a little problem that I'm not sure whether it's just me or not. Is anyone having any difficulties with the rudder and bearing commands? I have just recently started using these commands and ran into a strange occurrence. When I give any bearing or rudder command (i.e. rudder port/starboard X degrees) the command is executed perfectly except that it always goes to the starboard side. I have checked in the command window for sh4speech and it is correctly recognizing the orders, just executing all to one side. I'm running 1280x1024 and have set that up in the batch file. Has anyone seen this behavior and/or know what causes it?

Regarding the missed keys, try setting a ridiculously high delay via the BAT file, like 5. If that solves it, it's a performance issue with your PC.

It could be a problem with the keycodes if you are using a foreign version of windows or have some international regional settings in the control panel. If that's the case, the hits will always hit and the misses will always miss, since it has to do with some codes being valid by chance and others not. But I'd guess it's a delay problem.

DigitalTrucker, I've never seen what you're talking about. That's a really bizarre problem. Check your CSVs to be sure they haven't been altered - there's information about the heading dial rotation and size and if they're messed up it might explain this. Try re-extracting those from the original zip. It's a long shot I know. Also please explain exactly what you see with the mouse when you do "heading right ninety degrees" and "heading left ninety degrees". When I say exactly, I mean for every mouse movement/click in the sequence, tell me exactly where it is landing for each command. It could be a resolution issue.. have you triple checked to ensure you really are in 1280x1024 mode? Have you edited that in both BATs? Does the resolution show up in the sh4speech debug window on startup?

I'm going on a few days camping trip to Mt. Whitney this weekend, back next week. Good luck until then :)

My bad
 

:oops: Shoulda looked a little closer at the original files. Evidently, when I used my spreadsheet program (OpenOffice) to edit the file once upon a time, it decided that the text fields in the CSV file needed quotation marks (") around them. I never noticed the change because all the other commands worked fine. The problem evidently only arises with those commands that can have a negative sign (hyphen,-) in front of their entries to designate direction. Everything should be hunky-dory after I strip out the quotes:damn:

Don't know if it's even worth thinking about, but if this could be a common problem with spreadsheet programs, maybe a mention in the readme would help some other poor slob (i.e. me) not make the same mistake.

As for the answers to all your above questions: the same exact thing,yes,no,yes.

Enjoy your camping trip (and if you see this afterwards, I hope you enjoyed it):rock:

Digital Trucker:

Apparently, OpenOffice is treating the negative number as text because, strictly speaking, the "minus" sign isn't a numeric character) and putting it in quotation marks. Putting text in quotes is standard CSV convention because the text itself may contain a comma, which would mess up the way the file was decoded. The quotation marks tell the CSV decoder to treat everything in between as one field. As for the reason *why* OpenOffice is treating a negative number as a string, well... I guess you gotta ask the authors of the project about that one...

Bill

Those comma-delimited bastards!

Oh, that doesn't surprise me in the least. The behavior of Excel with the negatives is bizarre as all hell. OpenOffice is probably doing it technically right!

The problem is that I wanted Excel to treat those fields as numeric so that I could do a series fill to easily type in the extra 360 numbers, to avoid keying them in by hand. So the fields just said 1 or -1. Then, I used the Format Cells feature to apply the following custom label:

"Heading" 0

I expected that to turn 1 into Heading 1 and -1 into Heading -1. But oh no. Excel puts the - symbol before the word Heading so you get -Heading 1! I was shocked and annoyed but due to laziness and wanting to keep those as numeric fields, I coded the script to recognize the - at the very start of the field and then pluck out the number and invert it. For positive ones (where it doesn't detect the - symbol) it just plucks the number and leaves it alone.

The quotes made it not detect the - symbol, and so it treated it as a positive number, which explains why all commands were starboard, and also explains why the voice command showed up correctly in the debug window (though if you were to look closer, you would have seen "heading right 90" with "Desired angle: 90 degrees" and on "heading left 90" you would have also seen that instead of -90 which is correct. I don't blame you since I'm currently spewing quite a bit of debug output there.

I guess another aspect of the problem was the default behavior of Excel is to not quote wrap CSV output while OpenOffice does. It's not treating a negative number as a string - it really is a string - the string is "- Heading 90". So it's really correct to put quotes, and I'm relying on the fact that Excel doesn't.

In the future just post the command window debug output I can probably spot the problem in the midst of all that junk better than y'all and get to the root of the problem right away. I really need to clean that stuff up the and boil it down to the essentials (balancing that is always hard though - too little and you risk not showing the critical info you need to solve it, too much and it's hard to find the key bit. I prefer the latter though, because otherwise I'd have to give you another release that shows more debug output or code in multiple verbosity levels which is a pain.) At some point I'll probably trim the visible output to the bare essentials and have it write a more verbose log file that you can examine or send me in the event of a problem.