Sound replacement possible?

[wghost81]

It was a very polite way to say, that I posted incorrect patch text. :smile:

 

Here's the good one:

 

UPK_FILE=XComGame.upk

OBJECT=UIDialogueBox.Realize
FIND_HEX=07 78 01 77 35 FD 08 00 00 06 09 00 00 00 00 00 26 09 00 00 2A 16
MODDED_HEX=06

 

[Zyxpsilon]

Re_Thank'a'yo! :D

[tracktwo]

WGhost: The code in UIScreen.UnlockBox.DrawDBox makes a call to play the fanfare sound at the end of the function. This is in addition to the call in Realize(). Maybe this one is also contributing to the overlapping sounds? I tried modding it out with just a plain hex editor, replacing the start of the call with either a jump to the return or just a "return none" right there, but it always crashes the game. The log is reporting logs about hashing the packages, but I thought package hash verification was disabled in EW? It crashes with an assertion failure just before it would print the hash log info for xcomgame.upk in the unpatched version.

[wghost81]

I already tried to disable it, but with no result: fanfare sound was still there and still loud.

 

Can't say anything about hash problem, had nothing similar myself. Are you sure, your modifications are correct? CTD can be caused by wrong virtual size, for example.

 

Here's the version I used:

 

 

UPK_FILE=XComGame.upk

OBJECT=UIScreen.UnlockBox.DrawDBox:AUTO
[BEFORE_CODE]
//PlaySound(m_arrUnlocks[0].sndFanfare)
1C <Engine.Actor.PlaySound> 35 <XGNarrative.TItemUnlock.sndFanfare> <XGNarrative.TItemUnlock> 00 00 10 25 01 <UIScreen.m_arrUnlocks> 4A 4A 4A 4A 4A 16
//return
04 0B
[AFTER_CODE]
//return
04 0B

 

Edited October 16, 2014 by wghost81

[tracktwo]

The patch will actually clone the function, so that appears to be why it doesn't crash: the original is unmodified. But, weirdly enough, if I do this and then also modify the original function, it doesn't crash. Very odd.

 

I have a fix for the overlapping sounds. The fix is to only call Realize() from AddDialog() if the dialog just added is the only element in the array. Adding additional dialogs will add them to the list, but not Realize(). Realize() is called again when the dialogs are dismissed, and this will pop up the next dialog in the list and play the sound.

UPK_FILE=XComGame.upk
AUTHOR=Tracktwo
DESCRIPTION=Fixes the extremely loud overlapping SFX when research unlocks many items/projects/facilities.
Version: 1.0
Compatible with XCOM Enemy Within versions:
- all
OBJECT=UIDialogueBox.AddDialog:AUTO

[BEFORE_CODE]
//Realize();
// return;
1C <UIDialogueBox.Realize> 16 04 0B

[AFTER_CODE]
// if (m_arrData.Length == 1) {
07 01 01 9A 36 01 <@m_arrData> 26 16
// Realize()
1C <UIDialogueBox.Realize> 16
// }
// return;
04 0B

[wghost81]

tracktwo, use INPL, if you don't like "cloning". :smile: The "original" function is never used, because ExportTable points to a new one. So there's no need to change anything there. Edited October 17, 2014 by wghost81

[tracktwo]

Yeah, I was just trying to figure out what was causing the crash by seeing if it was still hashing the original part of the file, if that's what it was actually doing. Still not sure, but that function doesn't seem to be relevant to the sound anyway.

[LiQuiD911]

Thank you for the patches :smile: Now I can start importing the combat music ripped from deus ex human revolution

 

wghost, what should the RESIZE value hold? the OGG size in bytes? or the whole upk file size?

 

UPDATE_REL=TRUE
OBJECT=SoundMissionControlMusic.MemorialScreen3:INPL
RESIZE=12345 // new object size here (a size of entire object serial data)
REL_OFFSET=4 // never rewrite PrevObjRef, it's an internal linker info!

Edited October 17, 2014 by LiQuiD911

[wghost81]

that function doesn't seem to be relevant to the sound anyway

I concur. Altering this one did nothing in my experiments.

 

The only thing that concerns me with not calling Realize() is that some other dialogs might not work properly. We can try to add a check to Realize() directly.

[tracktwo]

All Realize() seems to do is actually display the dialog box, from what I can tell. There isn't any good reason to display all the dialog boxes when multiple items are unlocked: only one needs to be shown, the others just need to be in the array so the next one will be shown when the first is dismissed. It looks to me like the way it originally worked is if you unlock three items with a research, it'll "display" all 3, playing three sounds. Only one dialog can actually be on the screen at a time, so the only one the player actually sees is the last one in the array. Each time a dialog is dismissed with RemoveDialog(), it removes it from the list and calls Realize() again, showing the next one and playing the one sound for the one realized dialog.

 

One interesting thing: Look at UIDialogueBox.AddDialog(), at the top it has code that checks if there is already a dialog being displayed or not, checking if the size of the array is > 0 and if the last element on the list has the isShowing flag set. This flag is set by Realize() when the dialog is displayed. If these conditions are met, it uses m_arrData.InsertItem(m_arrData.Length-1, kData) to insert the new dialog into the list. If they aren't met, it uses m_arrData.AddData(kData) to insert the new dialog into the list. I think this was supposed to be the logic that handled dialog stacking, but it has two bugs. To me, it looks like this was actually supposed to be:

if ((m_arrData.Length > 0) && m_arrData[m_arrData.Length-1].isShowing)
{
    m_arrData.InsertItem(0, kData); // insert at beginning, this maintains ordering.
    return; // return, no reason to Realize() because there's already an item displaying
}
else
{
    m_arrData.AddItem(kData);
}

(EDIT: This doesn't actually work, it looks like the management calls below insertion but before Realize() may be needed, so the first mod or a combination of the two to insert in the right order but avoid excess realizing might be best)

 

As originally written, why use the if check at all? Inserting at the end of the list is exactly what AddItem does anyway, no need to use InsertItem to do that. If you look at the order in which the unlocked items appear in the report, and the order in which they show up when you close the report and get the unlock dialogs, you see the first one first, and then all the rest in reverse order. I.e. if you unlock 5 things, you see 1, 5, 4, 3, 2. That's because of the way the extra dialogs are stacked onto the end of the list with InsertItem (or AddItem would've done the same, with the exception that it'd be in completely the reverse order instead of the weird first-then-reverse order). If they were inserted at the beginning of the list, you'd see them in the natural order: 1, 2, 3, 4, 5, because RemoveDialog always displays the dialog that's last on the list. I think that's perhaps what the if check was trying to do in the first place, but it's bugged. And also it would just return after inserting the item, because there is no reason to display it when there is another one already present.

Edited October 18, 2014 by tracktwo