View Full Version : Need pointers on modding monsters

Black Wolf
04-20-2016, 05:12 PM
I like this game. I really do. For the first 10-15 levels anyway. I like a challenge as much as anyone, but the sheer number of invincible boss monsters is making the game unplayable past the first ten levels or so. I got into the monsterenhancements.gdb file and toned down the boss buffs a bit, zipped it and put it in the assets folder. This hasn't made the bosses any easier and as a result don't see myself making anymore progress with this game unless I can figure out a way to tone down the insane buffs the monsters get. Can anyone experienced in modding offer any ideas as to what I can do about this?

04-21-2016, 01:36 AM
Perhaps you didn't zip it up properly. An easy thing to overlook is that your .gdb files need to be in a database folder and that folder needs to be zipped. Your file path would look something like this:


What you're looking to mod can be a bit difficult to test for. You may want to make a simple mod that changes something obvious so you at least know that you are correctly structuring the mod.

Here are two excerpts from the Drox Operative SDK that may help you (modding works the same for all of Soldak's games):

File Order
Any particular file can be in many places, but the game will only use one
of them. So when modding the game knowing how the game chooses which file
to use can be important.

Here's is the priority (highest to lowest):
1) Loose file (ex. systems.gdb)
2) In a zip file, last alphabetical (ex. systems.gdb inside of assets003.zip)
3) In a zip file, everything between last and first :)
4) In a zip file, first alphabetical (ex. systems.gdb inside of assets001.zip)

Also, note that for loose files and zip files the directory structure must be
preserved. For example the systems.gdb file is inside the Database directory.

So the loose file would be at:
C:\Program Files\Drox Operative\Assets\Database\systems.gdb

Inside a zip file it would be at:
where the zip file itself would be in the
C:\Program Files\Drox Operative\Assets\ directory.

Note: The C:\Program Files\Drox Operative\ part is the default install
directory in Windows and it is fine if you have it installed somewhere
else. The important part is after the Assets part of the directory.

All of the main database files are specified in database.dbl. In general you should not change
this file, since the game will automatically read in all gdb files in the Database directory after
parsing the database.dbl file.

Each database entry has a very simple format.

Type Chest

Base BaseName

Parm1 ParmValue1
Parm2 ParmValue2
Parm3 ParmValue3

EntryName - is just the name of the entry, this can be referenced by another entry or by code
Base - points to the parent entry for this entry
basically this means if a parm is not found in an entry it will look in the parent entry
so basically it can inherit all of the attributes of the parent but if the entry does have the
parm it ignores the parent parm
you can have as many entries in the parent chain as you want
ex. long sword -> sword -> one handed weapon -> base weapon -> base item
Type - is the type of the entry, the game uses this for some things like finding all of the items
available in the game. Most of the time type is only specified in the base entries.
Parm - simply a parameter name and value (this is pretty much how the entire database works)

WARNING: changing the order of entries or deleting entries can break save games.



NewEntryName overrides OldEntryName
Parm1 ParmValue1

This entry differs from a normal database entry. In general, nothing will reference this database
entry directory. What will happen is when something asks for the value of Parm1 from OldEntryName
it will use the value from NewEntryName instead. If the parm is not specified in NewEntryName then
it will use OldEntryName just like normal.

Using this method provides a few benefits:

1) You only have to add the few parms that you change, so your changes are much smaller and thus
easier to work with.
2) You can have multiple mods that overrides the same old entry, since you no longer have to
replace the entire entry (you can still have issues if they try to change the same parms of
3) Mods will work much better with patches especially on things that change often like GameSystem
4) It makes it easier for other people to see what you have changed

The overrides command will also work with list like parms. For example, in classes.gdb you can use
the parm StartingItem to start a new player of that class with whatever items you want. To do this
you use a separate StartingItem line for each item. Most of the time parameters like this will use
all of that parm type from that database entry and all of the entry's parents. However when one of
these parms is used in an overrides, it will not look at the parent at all for that parm.



NewEntryName addsTo OldEntryName
Parm1 ParmValue1

The addsTo command is used when there is a list type of command that you don't want to completely
override because you want the original commands to work, but you want to add to it. Back to our
StartingItem example. If you want the class to get all of the original items AND an extra one, you
would want to use an addsTo entry and then specific a StartingItem entry for the new item.

Black Wolf
04-21-2016, 03:53 AM
That's what I did wrong. I forgot to put it in a database folder. Thanks