Bah, the old Cosmo off screen bug...easiest solution is to run Cosmo then hit Alt-Space to bring up the system menu (don't worry if you can't see it), and hit 'M' for 'move', then use arrow keys & mouse to bring it back on screen.
Third one, I was hoping to have a theory to suggest here but since I couldn't take a look at the files as I would have liked I don't really have much to say. How would you guys think we could identify which dialog line is being called (basically ID it). I mean, we can show the text right now, but can we uniquely identify which text is shown so we can associate that identifier with a file to play it ? My guess from what I know would be that we'd need to identify the right field file in use but apart from that how could we tell which dialog is being called up by the game ?
Two possibilities.
Firstly, identify the dialogue by ID - as dzuigo's app does. So every time a dialogue is displayed the tool knows, 'this is file NVL_W, dialogue #4". You'd then have used some sort of a field file viewer to go through and see what dialogue it contained, and recorded a file (e.g. NVL_W_04.wav) with the dialogue for whatever dialogue #4 said.
Secondly, identify the dialogue by text - more like my test app. So when the dialogue is displayed the tool knows, 'Cloud is saying "The black-caped man?"'. It then looks to see if you've recorded a file linked to that text and if so plays it. (It could also take into account the location you were in, of course.) You'd probably strip out a certain amount of formatting/punctuation to make matching it up easier.
The first approach is arguably more 'correct', but there are advantages and disadvantages to both approaches;
-If the text changes the first method will still play the audio, the second won't (say somebody has edited the field files). It's hard to say which is better! If all that's happened is that somebody has corrected a spelling error in the field file, you probably still want the audio to play. On the other hand, if somebody has changed the text totally you probably
don't want the original audio to play! The second method would let you play a different file (if you knew what the new dialogue was), so you could in theory distribute a single voice pack that still worked (and actually played something different) when certain patches to the dialogue were installed.
-In a similar way, the first method would still work if you were running a foreign version of the game (provided the dialogue IDs matched up). Of course, would you want English dialogue on a French language game?
(That raises another issue; I know in the UK release they at least renamed 'Aerith' to 'Aeris' [thank goodness]; does anyone know if they actually changed any other dialogue? I'd assume not, but clearly it wasn't just a direct unaltered release...)
-The second method has the possibility that standard lines of text, or any lines of text said in more than one place, could be recorded just once and the tool could 'automatically' reuse them between different field locations.
The disadvantage of that would be you might not
want it to do that...
MP3 probably won't get a good compression ratio when put into LGP files, so it might as well be put into a custom container. New modified version of window opcode could be implemented, that would take an extra argument of the MP3 to be played - that would require modifying the flevel files, but once it's done you don't have to peek any process for changes + you'd get a better responsivness.