yes it is unfortunate the timing of this project. But if you do not feel interested in rerecording the german voices I can always just release the campaign in its current state. Still that is better than nothing.

So it seems we're all fine with doing AOI.
I'll review the campaign and create a list of possible roles to voice.
@forum moderator: Is it better for discussion of voiceover projects to happen inside the "Music and Sound Development" sub forum?

Also I would like to inquire if it is at all a possibility to write the voice acting code into the DiD scenarios?

Basically one line in each dialogue box which looks like 'voice=blah.ogg' so that we don't have to write an additional add-on.

I can't speak for all developers, but I would be happy to merge pull requests along these lines, that make it easier to write add-ons that extend the mainline content, provided they don't have downsides. For example, if adding these lines meant multiple warnings in the error log in playthroughs that don't have the addon, that would make it harder to maintain the campaign in mainline. In other words, I would prefer an implementation that doesn't cause error log spam.

if we work on An Orcish Incursion, the shortest campaign, i think there's a good chance we can finish that by the time a lot of work and consensus will have been done on DiD by the devs.
@any dev is this due for overhaul/revision?

Also, I would be wary of adding in code to mainline campaigns for voice acting. I'd really rather not get into a position where a campaign can't be improved further because the voice files can't be updated anymore.

99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code

How about if we make the engine automatically look for a file named after the md5 of the string? For example, if we have message = _ "female^Hello world", the engine would automatically look for a file called 9f8a2a8f5acb58df67cfdf625997e672.ogg (that being the md5 of female^Hello world).

We should probably provide a [remove_sound_source]id_is_the_md5_of=_ "Whatever the string is" for convenience.

Sure, seeing errors by opting in to them will be useful and therefore should be possible. It's just that people who work on mainline shouldn't see errors about missing voice files by default since that's expected and will make it harder to spot any other (unexpected) warnings.

Having to keep two copies of the message string around doesn't seem convenient though, especially seeing as the md5 will already need to be known for the user to be able to name the sound file correctly.

99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code

Having to have two copies of the string in the same file is trivially managable via a macro expanding to that string. It won't even break translations. Replacing one of the copies by an md5 doesn't remove the https://en.wikipedia.org/wiki/Don%27t_repeat_yourself problem, if anything, it makes it worse because it's easier to forget to update the md5 when its string changes.

If a macro isn't workable with some reason we could let the WML author give the message an id when it's placed so it can be removed by that id. Something like

I can't speak for all developers, but I would be happy to merge pull requests along these lines, that make it easier to write add-ons that extend the mainline content, provided they don't have downsides. For example, if adding these lines meant multiple warnings in the error log in playthroughs that don't have the addon, that would make it harder to maintain the campaign in mainline. In other words, I would prefer an implementation that doesn't cause error log spam.

Great! Yes this would be helpful because it would allow voice acting to be made without having to duplicate the entire campaign. That would save some considerable time and make it more practical.

However, as you point out I believe a direct search voice= would return an error if no voice file was found.

Also, I would be wary of adding in code to mainline campaigns for voice acting. I'd really rather not get into a position where a campaign can't be improved further because the voice files can't be updated anymore.

That is a good point. Because of the fact that the voice acting will remain a UMC project I don't believe this will be an issue for the mainline developers to worry about. However you are correct. For example if the campaign AToTB is updated and the UMC voiceover is dependent on the master than the add-on will be unusable.

After thinking about it further I do also recall having to make some changes to the actual campaign AToTB in order to implement the voiceover in the best manner. It was minor so I think we could do without editing the campaigns in future but an alternate idea came to my mind: could it be possible to implement an add-on which overrides the load of a mainline campaign? For example when you download the UMC add-on AToTB with voice acting can we either stop override the mainline campaign or alternatively call something to remove it from the campaign list? This would effectively achieve the same effect with more flexibility.

How about if we make the engine automatically look for a file named after the md5 of the string? For example, if we have message = _ "female^Hello world", the engine would automatically look for a file called 9f8a2a8f5acb58df67cfdf625997e672.ogg (that being the md5 of female^Hello world).

That would be a really good implementation for automatically calling voice files. As you illustrated this would also generate different files for female voices is that correct? (my current solution to female voices is to limit the speaker to a gender=male role haha )

Though that does make me wonder, in the case in which we are unable to record female voices because of limitations, such as in AToTB we just didn't have a female voice actor, it might be more ideal just to limit the speaker to male. Often it may not be practical to save many lines twice.

If a macro isn't workable with some reason we could let the WML author give the message an id when it's placed so it can be removed by that id. Something like

Yes this would be very practical for all future voice overs. Not having two add-ons in the campaign list is much clearer for the user and also this would save the extra add-on having to be created that duplicates the mainline campaign.

Also, I don't know much about the implementation of the voice= tag but would it be possible to instead implement the sound files through this tag. It already successfully works to remove the sound source after the message is removed so potentially if it were possible to ignore by default any missing voice files would this be a easier to implement alternate solution?

As I said I don't know much about its implementation so you can tell me what you think is best. Worth also noting is that some messages do not play a single sound file but multiple (for example voice=eat.ogg,$random|number.ogg,eggs.ogg).

That was alot of ideas I just spewed out... hopefully it is at least somewhat helpful. I am not trying to derail this idea with all my negative comments. Quite the opposite I want to ensure that all possibilities are considered, so that the implementation is able to be robust and flexible enough to be a long term solution. I really appreciate you taking the time to consider how we could implement this in the best way!

Also, I would be wary of adding in code to mainline campaigns for voice acting. I'd really rather not get into a position where a campaign can't be improved further because the voice files can't be updated anymore.

That is a good point. Because of the fact that the voice acting will remain a UMC project I don't believe this will be an issue for the mainline developers to worry about. However you are correct. For example if the campaign AToTB is updated and the UMC voiceover is dependent on the master than the add-on will be unusable.

After thinking about it further I do also recall having to make some changes to the actual campaign AToTB in order to implement the voiceover in the best manner. It was minor so I think we could do without editing the campaigns in future but an alternate idea came to my mind: could it be possible to implement an add-on which overrides the load of a mainline campaign? For example when you download the UMC add-on AToTB with voice acting can we either stop override the mainline campaign or alternatively call something to remove it from the campaign list? This would effectively achieve the same effect with more flexibility.

In general, if you have to edit the mainline campaign, I would recommend that you submit a pull request with your edits.

Why would you want to override the mainline campaign? Couldn't you just let the addon provide a campaign with the same rank as the mainline campaign, but a different name and id? You could probably let the addon refer to the mainline campaign's binary_path for images etc and it would mostly work (and if it doesn't you can just upload a new version of the addon that adds the needed image).

Yes this would be very practical for all future voice overs. Not having two add-ons in the campaign list is much clearer for the user and also this would save the extra add-on having to be created that duplicates the mainline campaign.

If you wish not to duplicate the campaign, you'll have to do the same thing translation maintainers do, and re-record the voice files during string freeze before every mainline release, otherwise, if mainline changes or removes a string, that string won't be spoken. Or you can duplicate the entire campaign so you're sure that the strings won't change under your feet. Whichever is easier to you.

I don't think having two entries for the campaign is a big problem, especially with the upcoming search function #3847.

How about if we make the engine automatically look for a file named after the md5 of the string? For example, if we have message = _ "female^Hello world", the engine would automatically look for a file called 9f8a2a8f5acb58df67cfdf625997e672.ogg (that being the md5 of female^Hello world).

That would be a really good implementation for automatically calling voice files. As you illustrated this would also generate different files for female voices is that correct? (my current solution to female voices is to limit the speaker to a gender=male role haha )

Though that does make me wonder, in the case in which we are unable to record female voices because of limitations, such as in AToTB we just didn't have a female voice actor, it might be more ideal just to limit the speaker to male. Often it may not be practical to save many lines twice.

The vast majority of lines are spoken by characters with a known gender (Malin, Dela, etc). However, when a line is spoken by a unit of unknown gender, it's possible to have different translations depending on the gender of the unit, see #3733 for example. That's implemented by having both "string" and "female^string" as strings to be translated. The engine chooses between them based on the gender of the unit that triggered the event. Just like one of those strings is used for looking up a translated string, that string can also be used for looking up an audio file, so in the rare case that a unit of unknown gender speaks a line, you'll have to provide two audio files. (They could be identical, of course, if you haven't a female voice actor.) This matters not only when the unit has different portraits based on gender (as the Mage line does), but for all unit types that come in two genders (not all do, for example, Saurian Skirmishers are all female), because in some languages the unit type in the sidebar is declined according to gender (the equivalent of "Elvish Fighter" / "Elvish Fighteress") for all units.

The "foo^String" syntax is a way to let String have different translations in different contexts (foo is the context, you'll generall have both "foo^String" and "bar^String" and they will be translated differently in some languages). I gave an example with a context to illustrate that the context and the ^ sign would be part of the text that the md5 is computed over. Contexts are not used unless needed, so Dela's lines won't have female^ prefixed to them, because her lines are unique anyway.

If a macro isn't workable with some reason we could let the WML author give the message an id when it's placed so it can be removed by that id. Something like

Also, I don't know much about the implementation of the voice= tag but would it be possible to instead implement the sound files through this tag. It already successfully works to remove the sound source after the message is removed so potentially if it were possible to ignore by default any missing voice files would this be a easier to implement alternate solution?

As to the md5 implementation idea, as well as to have a variation of the voice= attribute that ignores missing file errors by default, I think both of these idea are sensible but please let's discuss on them in a new thread here and/or on github. They can definitely be implemented for 1.15 but it might or might not be backportable to 1.14.

yes it is unfortunate the timing of this project. But if you do not feel interested in rerecording the german voices I can always just release the campaign in its current state. Still that is better than nothing.

Well, it was a lot of work, however it was only holiday I sacrificed for the "cause". We should just wait and see. We have a german version right now, just let's keep it and see what the changes are. The German translation was a little dull sometimes.