Jump to content

Battle music with irenicus in hell bug


Guest Loz

Recommended Posts

Hi,

I have tried several times with a save just outside the final battle with jon, both with no mods at all installed and with just the fixpack core fixes. Sure enough, as soon as the fixes are implemented the battle music no longer plays. A real shame since this battle music is among the best in the game and the whole thing seems fairly anticlimactic without it. I am running TOB with the latest patch.

Link to comment

I should also note that the 'Know Alignment' spell seems to be using the 'Minor Globe of Invulverability' spell description after the fixpack is installed. Again this is with only the core fixes installed and this bug is not present without them.

Link to comment

IIRC, the battle song issue is WeiDU spitting out the MUS file with Unix (LF) linebreaks. :(

We could probably switch to REPLACE_TEXTUALLY or such so it doesn't try rebuilding the file (as with S2E), although it might be worth bugging bigg to get these to spit out CR/LF (is there any case where you'd want LF instead of CRLF with IE?). Apologies for the inconvenience.

 

The second is noted and will be fixed in a forthcoming update, thanks.

Link to comment

I believe SET_2DA_ENTRY_LATER (and SET_2DA_ENTRY if there are processing errors which cause it to revert to the ancient code). It's part of the reformatting that's done (the file is broken down into a list of entries and new whitespace chucked out when the file is written).

 

2DA handling doesn't care, but the engine doesn't like LF-only newlines in MUS files.

Link to comment

You know the WeiDU code quite well. :suspect:

Did some investigation and it seems that the engine doesn't care about LF versus CRLF. But in some places it is sensitive to trailing whitespace. In this case it's the first line of the MUS file where the subfolder is specified. My guess is, that the engine looks for a folder called "BJR    " and since most OSs support spaces in folder names this is different from "BJR".

Link to comment

I've submitted patches and trolled through the WeiDU source in my day. Luckily, I have no memory of OCaml, so I get to claim ignorance and just ask bigg to do stuff.

 

But in some places it is sensitive to trailing whitespace.
Yuck. Very well could be (they just keep reading up to the linebreak instead of stopping at whitespace), although it's utterly retarded. (I have an auto-cleanup script that parses through all the 2DAs and MUS and IDS files and formats them to be super pretty which is why I never investigated LF vs. CR/LF.)

 

The code will likely change in the fixpack, but I think your patch should find its way into WeiDU. You should submit it on the WeiDU board with a link back here (I can't think of any cases where the trailing whitespace would be necessary, so not emitting it shouldn't cause any problems).

Link to comment

The PM was actually sent to the_bigg with you in CC. So our WeiDU master already knows about this. :suspect:

 

@Loz: Thanks for reporting this. The issue will be fixed in a future version of WeiDU/BG2Fixpack. As a temporary workaround you can open up the file "music\bjr.mus" (relative to your BG2 installation) in your favorite editor and delete any trailing withspace on the first line.

Link to comment

Huh, yeah. REPLACE_TEXTUALLY ~BJR ~ ~BJR~ fixed it right up.

 

I'm a little concerned with the SET_2DA_ENTRIES_LATER format where the number of columns changes during patching, though - it used to (rarely) run patches out of order and turn the last line into

H2 BJR B1 B1 Z ZA
. I never did figure out why, and I think bigg fixed that outstanding bit of vexation, but I'm not sure.

 

Skipping the A1 sequence on repeats never really sat right (minor seconds on trumpet FTW!) so I'm not using this one in either case :suspect:

Link to comment
I'm a little concerned with the SET_2DA_ENTRIES_LATER format where the number of columns changes during patching, though - it used to (rarely) run patches out of order and turn the last line into
You were probably doing something wrong (or something so totally arcane that it couldn't help but to break)? There was an off-by-one bug or something bad with handling the first row, but I've been using this since the day Wes coded it and don't remember seeing anything similar.

 

Skipping the A1 sequence on repeats never really sat right
Sit however you want; "looping" back to A1 sucks in every case! :p

 

Anyway, this patch is totally funkificatored. The following can replace the current after being made "safe":

COPY "MUSIC/BJR.MUS" MUSIC
REPLACE_TEXTUALLY "H2 +B1" "H2 BJR B1"
REPLACE_TEXTUALLY ZA Z
SET_2DA_ENTRY 11 2 3 ZB

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...