Joined: 24 Jul 2005
|Posted: Tue Apr 13, 2021 5:59 am Post subject:
All the known information about PathMusic in RA3
|This post assumes you are familiar with modding RA3 (XML editing etc), with hexadecimal numbers and with C/C++ (including enums, structures and unions)
The attached zip contains various PathMusic related bits that I will reference later. You will also want to open up StaticStream.big from RA3 and extract a70bc1d6.9f12cf33.2d97c0ca.6d02956b.cdata as track.mus and a70bc1d6.9f12cf33.240021e2.dca9eaab.cdata as track-mem.mus
In Red Alert 3 there are 3 ways in which audio can be played. The first is when an AudioFile (or an AudioFileMP3Passthrough) is played directly. The second is when a specific PathEvent is triggered. And the third is when a PathMusicGameDynamicState is activated.
The following PathMusic related assets exist:
PathMusicMap (this points to the main PathMusic .mpf data file that gets loaded by the PathMusic system)
PathMusicTrack (this points to the PathMusic track .mus data files that hold the actual music)
PathMusicEvent (this matches the name of the event to the event ID)
PathMusicEventSet (this is used to create lists of PathMusicEvents including the list used for the "play event" script action)
PathMusicGameDynamicState (holds information about a path music dynamic state)
PathMusicGameDynamicStateSet (holds a list of PathMusicGameDynamicStates)
PathMusicGameDynamicTransition (is used to transition between PathMusic GameDynamicStates)
MusicScriptConditionNugget (there are a bunch of these and are used to determine when to transition between states)
The way that the PathMusicDynamicState system works is that when a state is activated, it triggers its EnterEvent. Then it checks each of its Transitions. If the transitions condition is matched, it transitions to the new state. When a state is deactivated, it triggers its ExitEvent.
The key to the whole system is the PathMusicEvent. As far as I have been able to tell, the only things the rest of the engine can do to the PathMusic system (the bit that handles the .mpf and .mus files) are to start an event playing, pause the currently playing event, stop the currently playing event and adjust the volume/gain/fade for the currently playing event (full details of that not yet known, need to track down the script action handler and find how all that works first)
In the zip file, RA3Music.h maps the name of a PathMusicEvent to its hash (e.g. BriefingTrack maps to 0x12671d4) and the name of a PathMusicTrack to its hash (e.g. Track maps to 0x11000001)
pc_pathmusicassets.xml contains definitions of the PathMusicMap and PathMusicTracks from RA3 (referencing the pc.mpf file, the track.mus file and the track-mem.mus file)
BasePathMusicEvent.xml and PathMusicEvents.xml contain definitions for the PathMusicEvents.
pathmusic.h contains definitions that will be referenced below when I talk about the format of the PathMusicMap file (pc.mpf) and the PathMusicTrack files (track.mus and track-mem.mus)
The .mpf file starts with a PATHFINDHEADER structure.
id will be 0x50464478, majorRev will be 5 and minorRev will be 3.
The nodeoffsets field of the PATHFINDHEADER structure points to a series of unsigned short values (with numnodes holding the count for this). Each value is multiplied by 4 to give an offset to a PATHFINDNODE structure.
The nodedata field of the PATHFINDHEADER structure points to the start of the area where all the PATHFINDNODE structures are.
Each PATHFINDNODE structure is followed by PATHFINDNODE.numbranches instances of a PATHFINDBRANCH structure.
The use of the other fields in the PATHFINDNODE structure (and all the fields in the PATHFINDBRANCH structure) is unknown at this time.
The eventoffsets field of the PATHFINDHEADER structure points to a series of unsigned short values (with numevents holding the count for this). Each value is multiplied by 4 to give an offset to a PATHEVENT structure.
The eventdata field of the PATHFINDHEADER structure points to the start of the area where all the PATHEVENT structures are.
Each PATHEVENT structure is followed by PATHEVENT.numactions instances of a PATHACTION structure.
The eventID field of the PATHEVENT structure represents the eventID. This will match to the IDs in ra3music.h except that the IDs in ra3music.h need to be ANDed with 0x00FFFFFF first (its unclear what the upper byte of the ra3music.h ID corresponds to)
The type field of the PATHACTION structure is an instance of the PATHACTIONTYPE enum and represents the action type.
The use of the other fields in the PATHFINDNODE and PATHACTION structures is unknown at this time.
The namedvars field of the PATHFINDHEADER points to a number of PATHNAMEDVAR structures (with numnamedvars holding the count for these). The use of the fields in the PATHNAMEDVAR structure is unknown at this time.
The noderouters field of the PATHFINDHEADER structure points to series of int values (with numrouters being the count for these). What these ints mean is unknown at this time.
The trackoffsets field of the PATHFINDHEADER structure points to a series of int values (with numtracks holding the count for this). Each value is multiplied by 4 to give an offset to a PATHTRACKINFO structure.
The trackinfos field of the PATHFINDHEADER structure points to the start of the area where all the PATHTRACKINFO structures are.
The muschecksum field in the PATHTRACKINFO structure matches with the checksum field in the PATHMUSHEADER structure. The use of the other fields in the PATHTRACKINFO structure is unknown at this time.
The sampleoffsets field in the PATHFINDHEADER structure points to a series of PATHFINDSAMPLE structures (the field that holds the count of these structures is unknown at this time).
The use of the fields in the PATHFINDSAMPLE structure is unknown at this time.
The use of the other fields in the PATHFINDHEADER structure is known at this time.
The .mus files start with a PATHMUSHEADER structure followed by PATHMUSHEADER.numsamples instances of a PATHNODEOFFSETS structure. The checksum field matches with the muschecksum field in the PATHTRACKINFO structure. The use of the other fields in the PATHMUSHEADER structure is unknown at this time.
The snroffset field in the PATHNODEOFFSETS structure (when multiplied by 16) points to data for a .snr file with the snrbytes field indicating how large it is. The snsoffset field in the PATHNODEOFFSETS structure (when multiplied by 128) points to data for a .sns file with the snsbytes field indicating how large it is.
The use of the other fields in the PATHNODEOFFSETS structure is unknown at this time.
You can find code that shows how to read and write snr and sns files at https://github.com/jonwil/snrtool and https://github.com/jonwil/lame-3.96
All the snr/sns files embedded in the PathMusic data of RA3 are version 0 SndPlayer files and all audio appears to be compressed with the ealayer3_int codec.
Forgot to attach the zip file
|| 30.09 KB
|| 14 Time(s)