Hi Jay,
I'm hoping to pick your brain a little about the system behind the 'modifiableValue' property and modifier.rpdat.
In my Star Wars hacking, I simply removed all the uses of 'totalModifiers' for my present situation. At first I thought that this system was only involved with Skills, but after now looking closer at this, I see it is also modifying abilities and seems to have hooks to other stuff like the 'eagle's splender' modifier among other things.
So my basic question, and I realize, of course, that you have said IT is a work in progress, so this: Is this system meant to be a 'generic' component that can basically modify ANY property, based on a list of items and your in place logic (D&D rules, stacking, etc.), such that it can/will support in the future, the idea of Feats, Talents, Spells and other modifiers?
So with some tweaking, could I start with this framework and begin adding say, Feats modifiers?
Really what I'm asking, is can you give a general overview of this subsystem as it pertains to v1.1b2. That would be a great help to my level of understanding how things work.
Thanks again,
-David
The modifier.rpdat system logic
The modifiableValue & modifier.rpdat is a design pattern that you can use for any game. There is probably minor changes for each game, but the design is the same. I've used it in D&D, Savage Worlds, and Hero modifiers.
The way it works is that I create a modifier.rpdat file that contains a record that describes a single modifier to a single modifieableValue. These records are tailored to the game. For D&D they have the type (enhancement, insight, etc). These records can then be grouped together so that you can represent a condition or a magic item or feat or class feature or hindrance or anything else you might have as a set of modifiers to one or more properties. There are scripts that can apply and remove a set of modifiers. The modifiable value has a script that reads the modifiers and adds them together. This is usually a little different for each game. For instance the D&D modifiableValue script handles all of the stacking rules. You define the columns in the rpdat file so that this script has all that it needs to work properly.
None of this is actually handled by the IT code, it is all handled by scripts. So you don't have to do things this way, it is just the way I've always pictured things working.
The way it works is that I create a modifier.rpdat file that contains a record that describes a single modifier to a single modifieableValue. These records are tailored to the game. For D&D they have the type (enhancement, insight, etc). These records can then be grouped together so that you can represent a condition or a magic item or feat or class feature or hindrance or anything else you might have as a set of modifiers to one or more properties. There are scripts that can apply and remove a set of modifiers. The modifiable value has a script that reads the modifiers and adds them together. This is usually a little different for each game. For instance the D&D modifiableValue script handles all of the stacking rules. You define the columns in the rpdat file so that this script has all that it needs to work properly.
None of this is actually handled by the IT code, it is all handled by scripts. So you don't have to do things this way, it is just the way I've always pictured things working.
Thanks for the background Jay.
Hey I grew a lot of gray hair this past weekend and it wasn't just the Packers getting thumped by the NY Football Giants on home turf!
I was trying to put some work into my Star Wars settings and ran into an issue, probably due to my lack of understanding of how things work. I had removed all the (+ totalModifiers) properties in all the D&D formulas as I worked on my new formulas. Now I want to work the modifieableValue system back into the process.
When I added this back in and made a new version of modifiers.rpdat I could not get any of the modifiers properties to show up in the tree. Well, I won't admit to the amount of time I wasted trying all sorts of tests, but let's just say it wasn't pretty. I finally went back to the stock install files in the stock locations and starting testing things. The first thing I noticed was that if I made subtle changes to the modifiers.rpdat file the changes did not show up when I re-ran the program.
This lead me to the mysterious files in the database directory. Looking at the file INITTOOLDBG.data.db I could see that modifiers.rpdat was being compiled into this file at some point. I'm clueless as to the process or use of those database files in the overall system.
What I did discover was that in order to get the changes in modifiers.rpdat to "stick" I had to unload the current game settings and then reload them in the Tool|Game Settings dialog. Then re-start the program.
Is this the required procedure or have a missed something? By the way, I am on WinXP and Java 6.
I have also noticed a bit of gotcha when developing my game settings file. One which also had me chasing my tail a bit. If you add and delete properties as you go, the old, now deleted properties remain in the combatant files. You need to delete the old combatant and add a new one to clear out and clean up the combatant. It would be nice to have a way to clean-up/reset the properties of combatant from within the UI. I have been using a saved encounter with a set of stats input for testing. I guess when I finally get around to thinking about a new defaultMonsters.rpdat that it will be an easy way to get a stock combatant into the software.
I just thought I mention this condition.
Thanks again.
-David
Hey I grew a lot of gray hair this past weekend and it wasn't just the Packers getting thumped by the NY Football Giants on home turf!
I was trying to put some work into my Star Wars settings and ran into an issue, probably due to my lack of understanding of how things work. I had removed all the (+ totalModifiers) properties in all the D&D formulas as I worked on my new formulas. Now I want to work the modifieableValue system back into the process.
When I added this back in and made a new version of modifiers.rpdat I could not get any of the modifiers properties to show up in the tree. Well, I won't admit to the amount of time I wasted trying all sorts of tests, but let's just say it wasn't pretty. I finally went back to the stock install files in the stock locations and starting testing things. The first thing I noticed was that if I made subtle changes to the modifiers.rpdat file the changes did not show up when I re-ran the program.
This lead me to the mysterious files in the database directory. Looking at the file INITTOOLDBG.data.db I could see that modifiers.rpdat was being compiled into this file at some point. I'm clueless as to the process or use of those database files in the overall system.
What I did discover was that in order to get the changes in modifiers.rpdat to "stick" I had to unload the current game settings and then reload them in the Tool|Game Settings dialog. Then re-start the program.
Is this the required procedure or have a missed something? By the way, I am on WinXP and Java 6.
I have also noticed a bit of gotcha when developing my game settings file. One which also had me chasing my tail a bit. If you add and delete properties as you go, the old, now deleted properties remain in the combatant files. You need to delete the old combatant and add a new one to clear out and clean up the combatant. It would be nice to have a way to clean-up/reset the properties of combatant from within the UI. I have been using a saved encounter with a set of stats input for testing. I guess when I finally get around to thinking about a new defaultMonsters.rpdat that it will be an easy way to get a stock combatant into the software.
I just thought I mention this condition.
Thanks again.
-David
All of the rpdat files are copied into a database so that they can be accessed very quickly from IT. This copy is only done when you start IT or change games. So changing the rpdat files will not automatically update the database. I haven't had a chance to code the rpdat editor yet so there isn't away for you to update the databases while running IT. When I change the data files I stop IT, delete the .inittool directory and then restart it. The Help->Reset Init Tool menu option should do the same thing. When I finish the rpdat editor you will be able to use it inside the game file editor to update the tables.
You are correct, I don't remove properties from a combatant even if they have been removed from the settings files. This allows script writers to add properties for their own use without changing the base properties file. I can see where updating the file to match the properties might be useful in design though so I'll add a tracker for this.
You are correct, I don't remove properties from a combatant even if they have been removed from the settings files. This allows script writers to add properties for their own use without changing the base properties file. I can see where updating the file to match the properties might be useful in design though so I'll add a tracker for this.
Hi Jay, thanks for the update. I had not been deleting the files in the database dir and didn't see the reset menu option. Without deleting the files a simple restart doesn't do the trick, you have to re-load the game settings.
I'll try to write a .bat for DOS to kill the directory and launch the app. That will make the process a bit less work.
-David
I'll try to write a .bat for DOS to kill the directory and launch the app. That will make the process a bit less work.
-David