Audio Modding

I found the Audio Modding document, but it's blasted Word.doc -- so here it is as .txt
(sorry if this is posted or available elsewhere)


Modding Audio in Operation Flashpoint: Dragon Rising

Before we start make sure that you have Title Update 2, aka version 1.2, this unlocks a couple of internal functions, and adds a script command needed to make all the following work.
When I was writing up the guide to the playOneShotSound command document, it struck me that if only we could read outside the encrypted file system, I could allow for new audio be added into the game, after all, the audio system was designed that way

Luckly version 1.2 added in the Mod folder, and thus it became possible, a bit of work later and voila!
Oh, that project parameter in playOneShotSound? It’s about to become very very important. Audio Modding, what you can and cannot do...

With the following system, you can adding in your own sounds into the game.
These sounds can be called from the playOneShotSound() command.
You cannot change existing game sounds, or switch out sounds used by game objects such as guns, vehicles etc…(sorry)

A Quick Overview of the Process

Make your Sounds
Fire up your copy of FMOD Designer
http://www.fmod.org/index.php/download/find/designer

Make your project and export it
Copy the FEV and FSBs you exported from FMOD Designer into the Data_Win/Mods folder
Create a UserBanks.xml to describe the banks to be loaded
Fire up mission editor, create a mission which uses playOneShotSound().
Type in the first (PROJECT) parameter with the name of YOUR project

Run the game, and all things being equal, it will play your sounds…


Getting Started with FMOD Designer

First of all you will need some sound editing software to create your wavs, and or some source of wavs you intend to use
Using and creating wavs is beyond the scope of this document, but just be aware that feeding wavs into FMOD Designer is a pretty good thing.
FMOD Designer will compress them for you into ADPCM or MP3 anyway.
For some free/trial audio creation software these come recommended - Audacity - Wavosaur - Reaper - Goldwave

Next get a copy of FMOD Designer, OFP:DR finished using version 4.20.24 of FMOD, as a result we used FMOD Designer v4.25.8.
For best results I recommend using this version of Designer. Its available in Firelights archives here:
www.fmod.org Once that’s installed start up FMOD Designer.

Welcome to your new tool, FMOD Designer is a pretty complex tool, and it’d take me too long to go over all of its features an how to use it, besides it comes with a nifty manual inside the install folder ...install path\FMOD Designer\documentation... Fmod_designer.pdf
What I’m going to go over is the conventions we used on OFP:DR especially regarding bank setup

Making the first Project

Click File > New Project, and title your project, MyProject
When you click ok, a lot of panels in Designer will be filled in.. !
Click the Sound Definitions Tab
From a windows file window drag your wav file into the left most panel in the sound definitions tab (for this example I dragged in the drumloop.wav from the examples folder that comes with FMOD Designer)
Now click the Wave Banks tab
In the Bank panel, left click on the Bank (it should be red, and called something like, myproject_bank00
In OFP:DR its best to keep everything under 14 characters, so rename the bank by changing its name in the Name field in the properties window (Rename it to myBank)

We are going to stick with the properties window, as there are a couple of things here which are important
First of all is the Bank Type
Designer defaults to: Decompress into Memory
Change this to Load into Memory, it’s the only option that is supported Decompressing into memory is not a good idea, as the Audio system does not have a lot of spare memory.
Next Set the Compression Field
This defaults to: PCM
PCM is wasteful with memory, and OFP:DR only allows a couple of PCM channels to play at once anyway.
ADPCM or MP3 are good selections depending on your needs. MP3 has better compression, but requires more CPU time to decompress, while ADPCM uses less CPU but uses more memory

The last field we need to set is the Force Software field. This must always be set to Yes
FMOD’s software mixer is very powerful, flexible and fast, and to use FMOD’s digital signal processors we need to be in Software mode.
Ok, bank and sound definitions have been created, final step is to create the event you’ll use in your mission

Click the Event Tab
In the Left Hand pane, right click on untitled, and select add Event
In the pop up window enter the event as myEvent


This is the name of the event as you’ll refer to it in the third parameter in the playOneShotSound() command, so a descriptive name is a good idea (no longer than 14 characters)
Press Ok
In the properties pane of your event, bottom right window, half way down, there is a Mode field, this should be set to 3D
A whole bunch of parameters will become active.
All of these parameters are used by OFP:DR, giving you vast control over your sound

Warning: Careful about setting max playbacks to a high value, as this can be wasteful on memory, a max playbacks of 4-5 is generally best, even in the main project this rarely goes above 10 for even the most common sounds
The Oneshot Field should be set to true, as we are not adding in a loop.Note again that loops do not work well with the playOneShotSound() command as there is no way to stop a loop started by this command short of exiting the mission.

Next we need to attach a sound definition to the event.
Click the Event Editor Tab with the event you want to edit selected.
If FMOD Designer says “Select an Event by double clicking an event in the event hierarchy” then you came to this tab without selecting an Event.Go back to the Event tab and double click the myEvent event
If an event was selected it will look something like this:
We are nearly… there…
Right click on the grey bar to add a sound definition.
Select Add Sound from the pop up menu.
A list of sound definitions will be displayed, pick one, and press ok.
Your event should now look like


Press the play (>) button, and you should hear your sound playing
Note if the sound ends and the play button remains depressed, then something is wrong and the sound is still playing inside FMOD
Check you have set Oneshot to yes, and check any parameters you might have added to the sound playOneShotSound() does not work well with loops (as you have no way of stopping the loops)

Everything is pretty much ready to export into your mission
From the top menu bar, select Build > Build Project…
Make sure all your wave banks are selected by clicking the Select all button
There is no need to click any of the options (though if you do select the programmer report one, you’ll see how we created the appendix for the playOneShotSound document…)
Click the Build button, and wait for Designer to do its stuff (usually takes a couple of seconds)


We are (hopefully) done

Getting the Files into the Game
Once you’ve built your FMOD project, its time to copy them into the right place inside the OFP:DR directory structure.
Open the
\OF Dragon Rising\data_win\Mods
And open the folder where you built your FMod project to.
Copy the following files to the Mods directory --
MyProject.Fev
MyBank.fsb
Next, you need to create the XML file which will tell OFP:DR to load in your FSB bank(s).
The structure of the XML is: (EDIT: brackets and question-marks - best find an example, doesn't post well here)
--xml version="1.0" encoding="utf-8"-- --UserAudioBanks-- --property name="myBank.fsb"/-- --/UserAudioBanks--
And it must be called: audioBanks.xml

With all of these in place, OFP:DR should be able to play the audio you created…
Putting it all together (redux)
Referring back to the mission I edited in the playOneShotSound() command guide
Open up triggerzone2 from the help/missions folder in your copy of the Mission editor
In the Level.Lua

First of all we need to inform the level that it will be using your own sound project as well as the normal flashpoint project, insert the following line into the onMissionStart() function
function onMissionStart()
OFP:showLetterBoxOsd(false);
OFP:allowPlayerMovement(true);
OFP:allowPlayerFire(true);
OFP:loadAudioProject( "myproject" );
end

The (new) loadAudioProject() command will load your projects fev file (Note that the FEV file, unlike the FSB file is unloaded from memory when the mission ends, the FSB however remains persistent)
In the onEnter_triggerzone() function, comment out the tank destroy line, and add in the following line, as shown below
function onEnter_triggerzone(zoneName, unitName)
{
-- OFP:destroyVehicle("vu01m1a2")
OFP:playOneShotSound ( “myproject”, “untitled”, “myevent”, 20734.0, 3.1, -2470.0, 0.1, 0.0, 0.0 )
}

Export the mission and run it in the game
Cross your fingers, if everything is correct, then your brand new event will play as you enter the trigger zone…

Justin Andrews - Audio ‘Group Lead’ Programmer
Operation Flashpoint: Dragon Rising

I converted the DOC to a PDF file.

Did you have and luck with this, Regg?
I did record myself making a silly sound and get it to work... FMod was a bit of messing around though.
Very cool also.

I did have quite a bit of success using fmod. Like tj said, abit of messing around. I then went onto OWP. This proved to be more convenient and a quicker method.

Not sure how fmod works with mp, OWP works for mp if all players have the same files. Not got this working successfully yet though.

I'm still waiting for Templars new sound app but that wil only be usable for sp. it will also have 32 channels as opposed to owps 1 channel.

Each method has pros and cons.

ive tried to use the fmod but its just messing my mind up so i turned to owp. but if the fmod method can make speech effects (like, if u turn ur head the sound comes from another place) ill definitely try hard to get it working

FMOD does use omni-directional sound.

But! something I forgot to point out was the EDx does not support the OFP:playOneShotSound() command. Thats why Tvig applied the EDX:playOwpsound() command instead.

At the moment I'd suggest staying with the OWP sound app if you are using the EDX to create missions and use custom sounds.

Mdog! EDX does support the OFP:playOneShotSound() command.
Check out the placeableIEDmine module, it uses OFP:playOneShotSound() for the IED explosions and mines.

Oh I'm mistaken! I thought Tvig siad there was an issue with it.

Regg wrote:I converted the DOC to a PDF file.

Perfect! With images too. Thanks.
Only just starting (had the game in a drawer for the last 4 years).
Still getting to know the mods available, but I'll follow your lead on this and look into OWP, whatever that is (I'll just poke around for more info)

I haven't played with FMOD yet, but it looks interesting. And this method looks to support directional sounds, and probably allows for over-lapping sounds (not sure if OWP supports that, or each sound must play to the end before playing the next). I did notice one thing with OWP: I have DR installed on one PC in my network, share out the install folder, and two other PC's launch across the network. Keeps it real simple for XML mods and user missions. But, if I'm playing on a networked PC with OWP server running on that PC, sometimes DR will have an issue writing to 'soundToPlay.owp', causing DR to completely freeze for 5-10 seconds. Could be some issue with my network config, but from what I'm reading, the FMOD method loads the WAV's into memory and would prevent my issue.

OWP works best in sp tbh. Thing iss though it will play the sound but its plays external from the game. If you want overlapping sounds you need to mix it with audacity or something.

Fmod is different because it plays sounds via XML files in the directory, but will not work for clients when playing MP, only the host will be alble to hear the sounds. Thats why OWP was made because it has a client fix for it. OWP when fired plays until the sound stops. Or you choose to fire another sound. Bit of a pain but I like the simplistic nature of it when creating files. Like said pros and cons for each.

Thanks for the info, Mdog!

I was starting to look at code (VB & C++) to play sounds with DirectSound (DirectX). I like how simple OWP works, but it would be nice to add directional sounds. Of course, directional sounds would only be true to host player in MP. I thought you said Templar was working on something, so I haven't done any work yet. But it was something I was thinking about.

if you can then great, I haven't spoken to him this last week on skype, but he has almost finished it afaik. He's been toying around with his AI mod for the EDx at the moment.

https://www.youtube.com/watch?feature=player_detailpage&list=PL01B92B6BD0EE4124&v=dlhQ-m77b1M
I think some of these could be used more ingame, as a background ambient track.

Regg-

I have had a similar thought and was hard pressed to find a callable audio routine via LUA that didn't trigger some type of window focus event.

Take a look at AutoHotkey API - since it already is being used as part of EDx expansion, it can be leveraged without added resources. The API allows for graphics overlays, and what appears to be more WINAPI access than LUA itself.

Best of all, the communication logic can work exactly like we use AutoHotKey, only in reverse. Integrated with our existing HotKey script we can create a new HUD, bring up popup maps and play sound files.

It is worth looking into and provides an opportunity to generate a bevy of EDx style functionality under a complimentary API.

Feel free to PM/SKYPE me later next week if you are interested in discussing this a bit further.

JJ --

Sounds interesting! We'll have to discuss this a bit more, but I've been reading a bit about AutoHotkey; seems very flexible.

From what I can tell, the current ofpdr-hotkeys script only works when DR is the active window, and will write to 'hotkeys.data' whenever a monitored key (e.g. the numpad) is pressed. The EDX timing mechanism checks that file every half second and fires the appropriate function(s) as needed.

The OWP sound app works very similar, but in the opposite direction. The EDX function just writes the name of the sound to './owp/soundToPlay.owp' and the OWP server app monitors that file, plays back the sounds sequentially, and distributes playback events to any clients.

So the OWP and Hotkey apps are independent of each other. Though, by combining the two, it is possible to have a key-press trigger a sound. But the essence of both mods, and what makes it possible with DR, is filesystem I/O. Unfortunately, that appears to be the only bi-directional way for us to interact with the mission script.

As to your first comment, I don't think we need to worry about Lua code for sound playback, just mimic how OWP works.

Yes, file I/O and timers to check file updates is the only way to sync.

Skip the idea of a hotkey playing a sound - instead take the OWP approach in writing its own TXT file for AHK to timer loop/read with its own psuedo_routines like
ie: ahk_showgraphic("/path/somepicture.png", center)
or
ie: ahk_showHUDstats(playername, line1, line2, line3)

but use the Autohotkey API for graphics, audio and improved HUD

OR as I meant to include

ahk_playsound("/path/somesoundfile.mp3")

@Regg After looking at the code in the root script, it appears that the timer controlling the hotkeys is actually on a 100ms loop with an initial delay of 500ms. It also appears that the script actually deletes the keypress file and checks for its existence. It looks like once the hotkey program writes the file it detects it and then reads it. You can already link an OWP sound to a hotkey also if you use one of the Numpad events and just place a call to an owp sound in it.

Had a chat with TJDagger last night, and he pointed me to the Dragon Rising Open Programming Project (DROPP). He had been playing with the DirectX Overlay (DXO) module without any success. I was able able to get the example missions working, and I think I know how it's done.





Dschonny (I assume) wrote a new Direct3D library (d3d9.dll) which is a wrapper/pass-through for the standard D3D functions, but also has additional functions for the overlay. Here's an excerpt from a post I found:

I'm currently working on a code-injection project for OPFlashpoint: DragonRising using a proxy-dll-hook. Target is to make custom UI-Elements available to Mission-Designers, which works pretty well so far. The game uses an edited d3d9.dll placed in the game folder which does the custom drawings and hands over all d3d-functions to the original d3d9.dll in the win/sys32-folder.

Just like OWP, the DLL watches a text file for commands related to the overlay. The hotkey functionality is also in this DLL, so there is no need to launch a separate EXE for hotkeys! Of course, it looks like fewer keys are supported than with ofpdr-hotkeys.exe, and it relies on an external config file to specify which function to run, rather than being handled internally as with the EDX.

DROPP claims to be open-source, and while all the Lua code is available, I don't see any source code for Dschonny's d3d9.dll. If we had access to that code, I think this could be the answer to several modding wishes. Without the source, we may still be able to make some progress, but I fear conflicts between the two hotkey systems. Does anyone around here know Dschonny? There's an active Steam account with this name, but I don't have a Steam account myself!

I found another thread discussing DirectX proxy/wrapper DLL's, and there is even some real basic code available. Unfortunately, my C++ isn't what it used to be, nor do I feel like having to learn all the code needed to draw on the screen! So it would be really great if we could get Dschonny's code. I still have Visual Studio 2010 so we can compile code, and I wouldn't mind tinkering with an existing code base.

Nice work Regg! Can you please split that post up please, the topic is audio modding and although there is a bit of reference between the two the dxoverlay info really should be in a deprecate thread.

All it needs is a link in this thread to the dxoverlay thread in DR Mods cheers.

Regg I see you are on the path that few have followed - the DXOVERLY was the most promising simply because one could assume the DX drivers were install - when .NET came out MS dropped the traditional DLL linking that I enjoyed back in the day - when VISTA cam a long a really heavy hand in versioninf came about, and then WIN7, etc

The DROOP approach was the first incarnation to modular code but limited the user through its "build interface" and godcode that lost many users looking to re-engineer it. In many ways it was the precursor to EDx particularly if you look at the UTILS module. Either case, working on the EDx compatibility will give you better mileage - meanwhile, pour over DROOP and see if there is any functionality not being addressed.

Either case, it was the journey not the destination when I was doing it - it may be similar for you given your background

Mdog wrote:Nice work Regg! Can you please split that post up please, the topic is audio modding and although there is a bit of reference between the two the dxoverlay info really should be in a deprecate thread.

All it needs is a link in this thread to the dxoverlay thread in DR Mods cheers.

Sorry for getting off-topic! I don't have permission to split topics, so I started a new topic for the DXOverlay Mod.

John J. Stevens wrote:The DROOP approach was the first incarnation to modular code but limited the user through its "build interface" and godcode that lost many users looking to re-engineer it. In many ways it was the precursor to EDx particularly if you look at the UTILS module. Either case, working on the EDx compatibility will give you better mileage - meanwhile, pour over DROOP and see if there is any functionality not being addressed.

DROPP (not DROOP. LOL!) just looks complex to me. Maybe I'm biased to the EDX now, but it feels like a natural extension of the OFP: API. Getting the DXOverlay to work as a module for EDX seems rather plug-n-play with the DROPP module; just have to register the functions with EDX.

John J. Stevens wrote:Either case, it was the journey not the destination when I was doing it - it may be similar for you given your background

So very true. I've never been much more than a casual gamer, compared to some folks. But I've always liked playing around with code. Couldn't stand to do it for a living! Last time I did any MS VC++ was 1999! Scripting (VB, PHP, Batch, Lua) is child's play compared to that nightmare! And yet I still can't walk away.

I think I had Object Oriented the DROPP - you are right EDx is mission designers approach to what DROPP would have matured too and a better fit to making the DXOverlay approach an EDx module

Can we get back on topic now guys please!