Tutorial Corrupted Sounds Solutions and Discussion

Tutorial Corrupted Sounds Solutions and Discussion

I went through the PFM thread and collected all relevant posts on the post-FotS sound issue.
Maybe it's the game looking up sounds for units by index rather than by their ID given in the database?

Here's some history:
sound problem in units table, where bow units sounds as cannons/muskets. I wasnt able to find what is causing it and how to fix it, but some bow (not all) sounds like that.

Its in rows, sound bug is in rows. it wrongly reads tables and getting infected by original files. For example if in original units.table in row 6 is some rifle/cannon unit and in yours 6.row is bow unit it will somehow get the rifle/canon sound. tested it like that and noticed some bow got cannon sounds and some rifle sounds when they are in same rows as original musket/cannon. Very very weird issue.

Some workaround solutions:
Removing superfluous original rows
I have managed to clear up all my sound problems by going through all my modded packs and removing all 'official clone' lines. By this I mean any line that is in your mods but is unmodded.
So if you have copied the whole of the units file but only changed some of them, then remove all entries that you HAVEN'T changed.
Worked like a charm for me. No more sound issues.

I had some cinematic and test units left overs and once I deleted them the problem was gone for the units I tried (even though I had made all the other adjustments the presence of these units provoked the bug). But needs more research.


Giving modded units unique IDs
It seems I have found how to fix this problem. I made some tests and it worked. I will make now an open beta of my mod so more test it (I have no time for that).
What I did
-Added the original unit_tables unmodded.
-modded it (or you add a working TSV).
-changed all index numbers of the units so to not use vanilla index numbers (the column unknown33), for example give +2000 to all.
-deleted "cinematic" and "test" units that are not used by the game.

I hope the above mentioned procedure works 100% and I share it so everybody is relieved from this enigmatic sound bug problem.
This is supported by the "Add to All" and "Renumber" functions in the Edit submenu of number columns' context menu in PFM.


Adding fake lines to move modded units into place
Issue with messed sounds is very problematic, i was able to bypass it completely in FotS by creating fake rows, but calculations for this are so damn complicated that if it gets wrong again i will probably hang myself. We must find easier and permanent solution or modding in Shogun will be severely harmed by this.

game somehow reads sounds from original units.table no matter what you do in yours. If you rifle/bow units are in same like as original cannons/muskets etc it may get totaly wrong as we know bow with cannons etc. To fix it you msut avoid placing units in the same line as those original and basicaly swap the positions. For that you need many fake rows and after that testing beggins since moving by 1 line can make a huge difference.

Every mod must have it in different way since every has using different units/rows and stuff like that so my build wont work on others. Took me and my friend about 2 days and about 40 testing attepmts before we managed to fix it. OR atlest nobody reproted yet on any bow/rifle unit wrong sounds in my RotS, SJ and FotS versions.

What we know for sure, issue is in units.table, not saying its PFM issue but game has problems with this table if its modded. As i said bypassing it with fake rows as i did is extremely time consuming, difficult and if they add new units or custom units it may get all wrong again.

So if there will be any easier fix for this, we mst find or as i said modding of shogun will be cripled.


If there are any other approaches and/or progress of research regarding this, please post here.
 
I am experiencing this problem with the Bow Ashigaru sounds after installing my unit mod.

So basically the only work around available right now is to copy the old unit.tables into a mod and renumber them from a ridiculously high number?

Also, someone else using my mod is having another strange sound bug - my unit uses the kisho ninja voice set, but for him it has a female "onna bushi", style voice... Works fine for me though with no problems - although he claims to have removed all other mods he insists it still happens. I cannot replicate it for the life in me...

Is this related to the same sound bug or is this a completely different ball park?

EDIT:

Is there anyway we could drum up support to petition CA to resolve this issue? The current work around is really inefficient - especially for simple unit mods. Then there is the possibility of mods clashing as they all have different unit_tables in them?
 
Last edited:
Maybe i found solution, try to switch mods where you have any units.table from movie format to mod format and add user.script. I think movie format is corrupted after laetst patch and have troubles dealing with sounds. I testted mod format on my Unit pack 3 and one unit which had cannons sounds in movie format got normal soudns back after i started it in mod format.
 
Maybe i found solution, try to switch mods where you have any units.table from movie format to mod format and add user.script. I think movie format is corrupted after laetst patch and have troubles dealing with sounds. I testted mod format on my Unit pack 3 and one unit which had cannons sounds in movie format got normal soudns back after i started it in mod format.

Post edited as fix did not work
 
Last edited:
Sound system is compeltely different after patch/fots release. I noticed it when my Sound mod stopped working and i was forced to switch it to mod format to make it work again. I got idea that this could be issue of the corrupted unit sounds aswell. So please test it properly if this is really solution since this problem is crazy.
 
Sound system is compeltely different after patch/fots release. I noticed it when my Sound mod stopped working and i was forced to switch it to mod format to make it work again. I got idea that this could be issue of the corrupted unit sounds aswell. So please test it properly if this is really solution since this problem is crazy.

Ok heres what I have found so far... I have made my unit pack a mod packfile and saved it. I have added a line into the user.script.txt - the game boots fine and it has recognised my mod.

However - the sound problem still exists for me. Bow Ashigaru still have the Artillery soundset. I have been carefull to ensure that all other mods have been removed from my data folder to prevent the bug being caused by another mod..

When I pair it with your V9 special mod however (with the script file, I just add the line for my packfile) - the fix works!

Quite strange - have I missed a step? have you added any custom sounds or changed the Unique ID numbers of the default units in your mod?

My mod adds only two new units only, it isn't as extensive as your unit pack.
 
Last edited:
A similar problem with the "wrong-sound-if-you-click-on-an-unit-in-battle" is known since ETW and never got fixed in NTW or S2. It's annoying and I posted this issue many times in various threads and on the official forums too. CA knows it and we couldn't find a solution yet.

Unfortunately this new problem in the units table with the "wrong-weapon-sounds" is really destroying the battle atmosphere.

Thanks to all who already shared their thoughts and test results about this issue. :thumbsup2
 
We cant expect fix from Ca since its not happening in original game, only if units.table is modded. recent big patch/fots released changed somehow completely the sound system of the game which is causing this, sadly i am unable to find solution for this and its driving me nuts.
 
This probably doesn't have anything to do with it, but since I'm probably about the only one who knows this:

One thing I noticed changed from original S2 to FotS is that there is more than one file tagged as "replaced" by files of type "patch"; previously we ssumed only one was valid.
The PFM can handle it now (it's what caused the problems with patch 16 shortly after release, it contains the entries "patch15.pack" and "patch_fots2.pack"), but it might have different effects regarding the loading of mod files...
Or possibly you even need to set this list for mods now too; right now you can't even access it from PFM because it never was thought to be data relevant to packs other than "patch"es, and it is very doubtful this is what's causing it, just throwing it out there.
The PFM will still save the original list when you open a patch file and save it, so you can remove all the original files and add yours to get to keep the list.
 
Well unit fire sounds are no more in patch1-18.packs, after fots released they were moved to patch-fots2.pack. If its any relevant? If you could somehow fix this it would be epic since i really dont know what to try now. I did everything what i could possibly think on and nothing, really nothing worked.

We know its caused by units.table. But we do not know why and what is ruining it when its modded.
 
Last edited:
No I've run out of ideas just as much as everybody else... been clutching at straws for some time now. Not to mention that I still haven't even reproduced the effect myself; most of my time goes into coding EditSF and PFM (I haven't even started the game for longer than two minute for some time now), and no one could put up a reproducable minimal way to produce it, so all I can do is give you guys ideas what to try.

The last thing I can think of is that I changed numbers encoding to have signs now (i.e. can become negative); but that only has an effect on numbers > 2,147,483,647, and I don't see any of those anyhwere. You can try if PFM 2.0.2 with a current schema.xml also causes the problem, if it doesn't I know how to fix it.

Something I forgot to bring over to this thread is that someone pointed out, that all the mp3s in patch_fots2.pack are 0 size; but since that doesn't have any effect on the vanilla game...
 
All the previous releases, starting with 2.0.2, are available in the Release folder in Sourceforge.


Ok, tested 2.0.2 with updated schema, opened my units.table, edited some stuff in there, saved and then tested in game - no luck and no change. Still same sadly.
 
For anyone who might have missed it, this guy has written a tool to unpack and pack the sounds of files, originally for ETW/NTW and now includes Shogun 2.

To be quite honest, nice as it may be that this gets it working, I find his approach somewhat less community-oriented that I'd have liked. Neither did he release his source, nor is he documenting what he's doing exactly; and he chose a license that does not allow others to "expand on this work". Well, his call to make I guess.
I'd really have liked to offer this in PFM to make the additional unpack/repack steps unneccessary, but the way it is, can't.
 
Daniu, I mentioned to the other thread about tables renaming. Maybe the table must not renamed at all, it must remain vanilla. The PFM currently renames all tables to version 1, version 2, version x. This is a helping new feature but it does not do good in all situations because some tables must use the same vanilla name in order to work/replace the values of the game and not make double entries.
 
A similar problem with the "wrong-sound-if-you-click-on-an-unit-in-battle" is known since ETW and never got fixed in NTW or S2. It's annoying and I posted this issue many times in various threads and on the official forums too. CA knows it and we couldn't find a solution yet.
This is not correct. The problem has been fixed with the Symphony tool for ETW/NTW, and now partially for S2.
In ETW/NTW, the sounds are defined in a "sound bank" XML file, where you have all the game events and units ID, and it reference sound event in a CSV file (like "If Unit1 or Unit3 is selected, play sound UnitSelected1"
The csv file list all the sound events, with information such as volume, pitch, repeatition, etc. And then a list of mp3 files.
The problem here is these XML files and csv files are "compiled".
If you mod the unit tables, you will modify the ID of the units, and then the sound will get mixed up, and use sounds for wrong units.

You have two levels of fix:
- First, you just uncompile (or unpack) the sounds from a non modding game. Just to get the default XML and csv files. Then, after you mod the game, you compile (pack) the sound again. Your new units will not have any specific sounds, but at least the ID will be correct in the packed sound files, and so the sounds for the vanilla unit will all be correct. It's easy to do, you have nothing special to edit, just pack again the sound everytime you add a new unit.
- Or you go a step further, and edit the XML/csv file to add entries for your new units as well.

Don't forget that it is necessary to repack the sound everytime you add or remove a unit in the unit table.

Also, there is a small bug in symphony: I strongly recommend using only one unit_table in your mod. At some point I splitted it in two (one table for new land units, one for naval units), but Symphony cannot detect it perfectly, and it didn't work.

In Masters of Europe mod for NTW, I now have every unit speaking in its own language. If you recruit KGL units as Britain, they will speak German. The Polish legion in the French army speaks Polish.
If you recruit Bavarian units in the Bavaria region, they will speak German, wether you play as the French Empire, Russia or Britain.
 
To be quite honest, nice as it may be that this gets it working, I find his approach somewhat less community-oriented that I'd have liked. Neither did he release his source, nor is he documenting what he's doing exactly; and he chose a license that does not allow others to "expand on this work". Well, his call to make I guess.
I'd really have liked to offer this in PFM to make the additional unpack/repack steps unneccessary, but the way it is, can't.
If you want to know how Symphony works, all you have to do is ask, although there are some details that I will not reveal due to the slightly legal grey area surrounding the methods I used to discover them. I shall post a description in the Symphony thread.

Release of source code is unlikely due to a number of issues - time to cleanup, ensuring I don't release anything I don't have the right to (i.e. third party code which is releasable in executable form but not in source form), the fact that I don't even know if anyone else here can work with dense modern c++ code, removing elements I don't want to release due to the aforementioned legal grey area.

Regarding the license, no-derivatives means you are not allowed to modify the work but you are still welcome to package it with another work (i.e. PFM) and have that work use it.
 
If you want to know how Symphony works, all you have to do is ask

Well, you were asked alreay. Your answer to
So what does this do exactly
was
It gives you much the same control over sound in Empire and Napoleon as CA have. It also allows you to generate compatible packed sound files for a mod which adds new units, resolving the "sound issue with wrong unit speeches".
Not exactly an "exact" description or something anyone can use for anything.

no-derivatives means you are not allowed to modify the work but you are still welcome to package it with another work (i.e. PFM) and have that work use it.
I'll hardly start calling external tools from an executable.
PFM is an application, not a script.

ensuring I don't release anything I don't have the right to (i.e. third party code which is releasable in executable form but not in source form), the fact that I don't even know if anyone else here can work with dense modern c++ code, removing elements I don't want to release due to the aforementioned legal grey area.
Sure, people are asking for the source code because they won't understand it. That statement itself is an insult to the intelligence of anyone knowing more than a single programming language. Heck, I've been going through taw's Ruby code and got along fine, and Ruby is much more fundamentally different from anything common like C or Java than C++. Maybe I'm special, but do you really think you'd have a hard time understanding how the PFM works? I doubt it because my assumption is that's where you looked to see how packs are assembled.

And none of the libraries you state you use is "releaseable in executable but not in source form", a licensing model I only have seen in commercial product, which I must express my doubt you use; and if you do, that does also fall under "not my idea of community effort" because I have a hard time believing you can't use an equivalent open source library to keep things open.
But this must all stay guesswork on my part because again you seem reluctant to give out any concrete information.

Not that it really matters because like I said, if people can live with using a multitude of tools to get their mods working, that's fine by me.
It's just that it conflicts with my idea of having a single tool providing as much integrated functionality as possible.
And the idea that someone might pick up on where you stop when you do, as I had to with the PFM.
 
If you want to know how Symphony works, all you have to do is ask, although there are some details that I will not reveal due to the slightly legal grey area surrounding the methods I used to discover them. I shall post a description in the Symphony thread.

Release of source code is unlikely due to a number of issues - time to cleanup, ensuring I don't release anything I don't have the right to (i.e. third party code which is releasable in executable form but not in source form), the fact that I don't even know if anyone else here can work with dense modern c++ code, removing elements I don't want to release due to the aforementioned legal grey area.

Regarding the license, no-derivatives means you are not allowed to modify the work but you are still welcome to package it with another work (i.e. PFM) and have that work use it.

Can I ask why you chose such a 'locked door' solution to an open community problem?

the fact that I don't even know if anyone else here can work with dense modern c++ code
By this logic no one should ever learn anything, because to begin with they dont know how to do whatever it is they want to learn, and so must be too stupid to even learn it because they dont already know it :laughter: this is the modding workshop forums if we are not here to learn and share what are we here for? Not for the cups of tea surely:)
 
I don't think crux3D's statement about the collective knowledge of the community here is meant as a judgment or an insult. More so, it's uncertainty whether he'd be liable if he publicly posted his source in it's present state and uncertainty whether absolutely everyone who touched it would be discrete with it when releasing derivative work. Using strictly open source libraries and methods in the first place is hindsight at this point. Who really knew, several years ago, that the propensity for these audio mismatches would grow instead of being fixed internally, causing the need for a more elegant community solution?

I imagine what daniu is envisioning in this case is PFM automatically generating corrected sound bank data alongside modified units tables. That and the ability to update the routine should crux3D not have the time for regular maintenance. Yes?

BTW, has anyone had any success getting this method to work reliably with S2? Haven't had time to get beyond looking at the syntax for Symphony and pulling my hair out before discovering I needed quotes around my source and destination pathnames :disgust:
 
I don't think crux3D's statement about the collective knowledge of the community here is meant as a judgment or an insult. More so, it's uncertainty whether he'd be liable if he publicly posted his source in it's present state and uncertainty whether absolutely everyone who touched it would be discrete with it when releasing derivative work. Using strictly open source libraries and methods in the first place is hindsight at this point. Who really knew, several years ago, that the propensity for these audio mismatches would grow instead of being fixed internally, causing the need for a more elegant community solution?

As mentioned by Dainu, if there is no source no one else can continue the work. This sound issue here is irrelevant for this point. As for liability...cant really see that as being an issue in a modding community like this. Egotistical maniacs complaining can be fairly safely ignored. What can they really do?
Only reason I can think of for not going open source is being too lazy to learn what is needed to do it, or you dont actually want people to have access to your source. This is not everyones view of course, and it does nothing to reduce my respect due to those who made the tool and what the tool does.

I imagine what daniu is envisioning in this case is PFM automatically generating corrected sound bank data alongside modified units tables. That and the ability to update the routine should crux3D not have the time for regular maintenance. Yes?

This is what i understand also :thumbsup2

BTW, has anyone had any success getting this method to work reliably with S2? Haven't had time to get beyond looking at the syntax for Symphony and pulling my hair out before discovering I needed quotes around my source and destination pathnames :disgust:

Am also interested in the answer to this.
 
Don't be so hard on the guy. I agree, it would be really nice to expand Symphony's functionality to new tools ASAP, but I don't think complaining is the correct approach. Nor do I think is saying "You wont understand dense code."
May I humbly suggest Crux and Daniu take the techniques to PM, and someone write a nice friendly use guide for the current tools? :-)
 
I don't know what I've said or done to upset you daniu, but you seem determined to assume the worst about me and interpret everything I say in the worst possible light.
Well, you were asked alreay.
That was clearly an enquiry into how Symphony could be used, not how it works. I answered accordingly and I assume the user was happy with my response since they did not request further clarification. To my knowledge nobody had enquired as to the technical details before you complained that I had not provided them. Furthermore, it is my experience that people generally do not care how a tool works, as long as it does indeed work. Consequently I don't usually take the time to format and present said details unless someone requests them.
I'll hardly start calling external tools from an executable.
If you don't wish to do so then that is, of course, your perogative. I merely pointed out that is was permissible.
PFM is an application, not a script.
Applications spawning additional processes in order to perform a section of work is nothing new. Your IDE does it, your internet browser almost certainly does it, even Shogun 2 does it. As I said, it's up to you how your application behaves, but please don't insinuate that my suggestion was in some way inappropriate or unrealistic. Since you do not want to invoke an external application from PFM, would you be happier if I provided a variant of Symphony as a dll?
Sure, people are asking for the source code because they won't understand it. That statement itself is an insult to the intelligence of anyone knowing more than a single programming language. Heck, I've been going through taw's Ruby code and got along fine, and Ruby is much more fundamentally different from anything common like C or Java than C++. Maybe I'm special, but do you really think you'd have a hard time understanding how the PFM works?
It certainly wasn't intended as an insult. I know professionals who aren't up to speed with the latest C++ features and would probably stuggle with elements of my code. However, if you believe you could cope with it then fine, I will accept that.
I doubt it because my assumption is that's where you looked to see how packs are assembled.
I did not use anybody else's tools in the development of Symphony. If I had I would have asked their permission and credited them. I figured out how pack files work by reverse-engineering the files and reading information posted publicly by The Creative Assembly.
And none of the libraries you state you use is "releaseable in executable but not in source form", a licensing model I only have seen in commercial product, which I must express my doubt you use; and if you do, that does also fall under "not my idea of community effort" because I have a hard time believing you can't use an equivalent open source library to keep things open.
You're probably right, there probably isn't anything in my source that would prevent me from releasing. But you'll note I didn't say that there was. I said I would have to check. I know everything in my various libaries and code snippets are releasable in executable form because I don't add anything to my respositories that does not meet this requirement. However, this is the only thing I check. I do not know the licensing requirements for a source code release of everything in my repositories, and I'm not about to open myself to liability without thorougly checking first. In fact, having just checked the Boost license I find this:
Excerpt from Boost Software License
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
If I had released and had not checked this license I would have been breaking the terms of the Boost license.
But this must all stay guesswork on my part because again you seem reluctant to give out any concrete information.
What concrete information would you like?
Not that it really matters because like I said, if people can live with using a multitude of tools to get their mods working, that's fine by me.
It's just that it conflicts with my idea of having a single tool providing as much integrated functionality as possible.
And the idea that someone might pick up on where you stop when you do, as I had to with the PFM.
Fair enough, but I have listed my reasons for not releasing my source and while you have addressed one, the other three still remain.



Can I ask why you chose such a 'locked door' solution to an open community problem?
I don't consider it a 'locked door' solution. It is a fairly standard software license and in fact much more open than most since it permits unlimited distribution. It's not an open-source license because I am not distributing my source - for the reasons explained previously.
 
Okay. I have cracked open symphony and got this:
symph.jpg
Don't mind my pointlessly writing the file path to "unpack_sounds". It was being a prick last night, but it seems fine now. In any case, it doesn't seem to like my custom pack ;). I did a quick check to see if it would work without using my custom pack, and the same thing happens.

Furthermore, how flexible is this fix? Will I have to re-do this every time I add a new unit, or even tamper with pre-existing ones in the "units" table? I read that there are annoyances with the movie pack type, which is rather depressing ;).
 
Last edited:
Okay. I have cracked open symphony and got this:
Due to lack of time I only added support for the most recent version of the Shogun 2 units table. I'm guessing your pack file was created with an earlier table version. You could try re-exporting your table in the newest format (I presume PFM or one of taw's tools will allow you to do that), or else point me at where I can get a copy of that packfile and I'll look at adding support for that version.
 
I just experienced this issue with my Miko No Yumi and it sounds like they have hand cannons instead of bows.

So I came across this:

"This is supported by the "Add to All" and "Renumber" functions in the Edit submenu of number columns' context menu in PFM."

Where is this? I right-clicked on unit ID and didn't see this in the context menu :(
 

Recent posts

Members Online Now

Site News

Thread Statistics

Created
daniu,
Last reply from
Steph,
Replies
122
Views
35,091

Site Polls

  • Axis & Allies

  • Battleship

  • Checkers

  • Chess

  • Clue

  • Go

  • Monopoly

  • Risk

  • Stratego

  • Other


Results are only viewable after voting.
Back
Top Bottom