DMFI - ACR integration

AcadiusLost · Post by **AcadiusLost** » Tue Oct 30, 2007 6:22 pm

My main project last night was an install and testing of the DMFI 1.04 tools to an OAS2 test module- I can report success, after a fair bit of tinkering. I am confident we will be able to have the ACR, Heed's PC Tools, and the DMFI package in a happy cooexistentance on our Beta and Live servers- I think we can swing the DMFI for the OAS2 as well, though I'll have to test how it works if the players don't have DMFI installed.

First off, the DMFI tools are nothing short of amazing.
-Configurable and working scripted language system using a separate dialog box, parsing out and autoplaying emotes.
-players can dynamically rename their items, familiars, summons, and animal companions.
-players can autofollow other PCs (with a permission confirmation box)
-DMs can control music, sounds, change appearances, scale, effects, and more on areas, creatures, etc.
-loads more I don't remember off the top of my head.

By default, it also gives players the ability to change their PC's name - which wreaks havoc on the poor ACR database. It's disableable in a config file which can be hak'ed, though. If we want the functionality back at a later time, we can maybe consider how to keep the DB from making new records whenever a PC reappears with a different name.

I'm not sure if we can do the GUI for DMFI entirely in haks or not- currently it needs an alternate ingameguix1.xml file, which I'm not sure can be supplied from our alfa_gui.hak- may have to be in an override position. Hopefully will have time to test this tonight.

Currently, DMFI makes extensive use of the OE campaign database, to build lists of available music files, languages, etc- if left as-is, this will happen on a per-server basis and won't necessarily cross over well (might end up with a PC who can speak elven on MD, but Infernal on Moonsea). We can crawl in and start switching it's functions over to use the central DB, but then we loose upgradability when they version-update their code. Thoughts on this?

Also, DMFI 1.04 as available on the vault isn't MotB compatible. It was a simple merge to get the GUI to show again, but it means they've got an update in the wings what may change how some of the gui files are handled. In the meantime, it means we may have yet another troublesome and confusing manual install thing for players who want to get on the Beta servers (unless the hak trick works).

Also- should we be committing the DMFI scripts to SF? Packing some of them in alfa_acr.hak?

Rusty · Post by **Rusty** » Tue Oct 30, 2007 7:01 pm

Some excellent news.

Could we proceed on a server basis till such point as we actually have two Live servers to be fully integrated? Does that at least allow more time for the system to bed in and for early patch/MotB updates to be made?

We'll likely need to enable/disable various features after testing. I can envisage even player item renaming being problematic for DMs just in tracking inventories.

AcadiusLost · Post by **AcadiusLost** » Tue Oct 30, 2007 7:23 pm

Certainly, we can go single-server to start with- that would be my preference, gets us off the ground with these systems for now.

In terms of item renaming- it's generally just flavor adjustments- if there is a concern about inventory tracking, we can adjust the logs to show the resref alongside the name for aquire/unacquire events.

Curmudgeon · Post by **Curmudgeon** » Tue Oct 30, 2007 7:45 pm

Prior to installing MotB, I was using both the DMFI and Heed's PC Tools together on a non-ALFA server, and would love to see them both available for us. HPCT in particular adds a lot of really neat emote/animation and prop SFX to the game.

ç i p h é r · Post by **ç i p h é r** » Tue Oct 30, 2007 7:45 pm

I don't think we should commit DMFI into our code repository. It's its own package and maintained elsewhere. However, committing config files or customizations certainly seems wise so we don't lose them.

What about storing these in a DMFI folder under game systems?

AcadiusLost · Post by **AcadiusLost** » Tue Oct 30, 2007 8:37 pm

Well, we need to change a few of the DMFI files that get imported into modules, in order to have them run under the ACR:

1. They have a module onpcloaded event script that is supposed to go in that module event. I've merged the function call into our acr_mod_events_i script so it doesn't have to displace the acf_mod_onpcloaded() script, but that also means the ACR won't compile without the DMFI includes.

2. They use the i_(TagNameHere)_ac.nss format for their activate DMFI tool - in order to be activated under the ACR, it needs to be named same as the tag of the item. I've made a renamed copy, which I could commit in any case- once again, won't compile without the core DMFI scripts in the module

3. The configuration script bundled with the DMFI includes a default setting (to allow PC naming) that breaks ACR persistency hard- so we'll want to make sure the naming=FALSE version goes into our severs.

The question is, how should we be releasing this? Seems to me the ALFA-tized versions should go into an erf, like we've done with PC tools- which can be imported to the servers (also bundled in with the ACR initial installation packages). If we include them in an ACR release, it makes sense to include them in the sourceforge repository. Should we only be committing altered files? Seems to me it's an area where our needs and purposes are somewhat outside Sourceforge's standard proceedures.

ç i p h é r · Post by **ç i p h é r** » Tue Oct 30, 2007 10:47 pm

I think you should comment out the lines in the ACR with a note explaining the requirements for DMFI compatibility. That way a vanilla import of ACR will still compile w/o DMFI, if so desired. Otherwise, the DMFI package must be imported if integrated functionality is desired. As for the persistency issue, we'll have to introduce revised versions of those files in our ACR if we expect proper compatibility. We'll have to look through that code carefully to create a happy union of the two.

Generally speaking, I think all third party integration code is kept out of core releases, but if it's part of the core, then the dependencies are noted in the installation instructions (ie the specific version of the package required for things to run properly). We just need to approach it the same way. In either case, it does not necessitate storing the DMFI package in our sourceforge repository. We're not maintaining their code nor do we want to have to keep updating our repository with every DMFI release.