Need pointers on modding monsters

[Black Wolf]

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?

[joku]

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:

...\[mod].zip\database\[mod].gdb

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:
  Database\systems.gdb
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.

EntryName
{
	Type		Chest

	Base		BaseName

	Parm1		ParmValue1
	Parm2		ParmValue2
	Parm3		ParmValue3
}

where
  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.


Overrides
---------

format:

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 
  course)
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.


Additions
---------

format:

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]

That's what I did wrong. I forgot to put it in a database folder. Thanks