I thought it might be a good idea to put the DMFI control book into the begining lobby area of my campaign, and let players choose settings they like.
For those that don't know, you can use it to set the module rest, death, and respawn system.
When I looked into it, I discovered that the whole thing is run through local integers, set on the module. But I want it to be for the campaign, not just a single .mod. I just need to save the integers to the campaign, right? So I proceeded to look up every script that is used in the system, and change the local ints into campaign int.
for example;
int deathchoice = GetLocalInt(GetModule(), "death_system");
int rspchoice = GetLocalInt(GetModule(), "respawn_system");
into
int deathchoice = GetCampaignInt("scourge_of_the_slavelords", "death_system");
int rspchoice = GetCampaignInt("scourge_of_the_slavelords", "respawn_system");
and if it set the int, for example;
object oTarg = GetModule();
SetLocalInt(oTarg, sVariable, nNewValue);
into
SetCampaignInt("scourge_of_the_slavelords", "sVariable", nNewValue, oPC);
it seemed logical to me, every thing compiled fine, but nothing happens in game.
Is there a reason this wont work, and I'm wasting my time, or am I barking up the right tree?
dmfi control book
Débuté par
bealzebub
, oct. 28 2011 02:45
#1
Posté 28 octobre 2011 - 02:45
#2
Posté 28 octobre 2011 - 05:42
In a different post, Shallina said;
"The thing is that global var or storing value in the PC is the way to go for event that need to be accessed from the whole campaign in a campaign wich has many different module."
I was under the inpression that "global" was only module wide.
Should I be attempting to set global ints instead of campaign ints to have it effect the whole campaign?
Or if I just leave it as a local int, will it transfer with the pc from mod to mod?
"The thing is that global var or storing value in the PC is the way to go for event that need to be accessed from the whole campaign in a campaign wich has many different module."
I was under the inpression that "global" was only module wide.
Should I be attempting to set global ints instead of campaign ints to have it effect the whole campaign?
Or if I just leave it as a local int, will it transfer with the pc from mod to mod?
Modifié par bealzebub, 28 octobre 2011 - 05:45 .
#3
Posté 28 octobre 2011 - 06:05
local int stored on object that travel accross your module are working everywhere in the campaign. typically the infamous GetFirstPC()
GlobalInt are working across the whole campaign as well.
CampaigInt aren't that good they are saved. You set a value, you reload the game from a previous state, the value stay at the last value set, it's not reloaded at the proper value.
GlobalInt are working across the whole campaign as well.
CampaigInt aren't that good they are saved. You set a value, you reload the game from a previous state, the value stay at the last value set, it's not reloaded at the proper value.
Modifié par Shallina, 28 octobre 2011 - 06:26 .
#4
Posté 28 octobre 2011 - 06:08
Something like that might work.
What i do is keep my preferences in a 2da file, and load these values into a object in the module. I do quite a few tricks ( keep a reference to this item in global scope, its an item, its got an index and the like, and i can just drop this item into the NWN DB so it only has to load once ). Although quite complex, this is designed to replace the item every DM has thrown into their inventory, and moves the work of assembling 2da data onto this object from a per player object, to a central object.
This allows the player to keep a file with what they prefer, and i can allow them to edit this in game.
The issue with the DMFI is its very hard to modify, i am hoping that my various bits of code result in features that work the same ( i am doing something i call the community script library which largely redoes the entire DMFI ), but are a lot easier to control and further modify. I imagine you'd have to recompile all the scripts involved to get your changes to take effect. Just adjusting a nss file which has not main won't affect any other file and generally to make things work there are lots of files involved.
I would think it would be better to store preferences on the player if they are DM specific ( ie as a DM i prefer x y and z ), but the other options should be put into on module load. By definition a DM is a MP thing, which means using NWNx and mysql becomes a much better option for this.
What i do is keep my preferences in a 2da file, and load these values into a object in the module. I do quite a few tricks ( keep a reference to this item in global scope, its an item, its got an index and the like, and i can just drop this item into the NWN DB so it only has to load once ). Although quite complex, this is designed to replace the item every DM has thrown into their inventory, and moves the work of assembling 2da data onto this object from a per player object, to a central object.
This allows the player to keep a file with what they prefer, and i can allow them to edit this in game.
The issue with the DMFI is its very hard to modify, i am hoping that my various bits of code result in features that work the same ( i am doing something i call the community script library which largely redoes the entire DMFI ), but are a lot easier to control and further modify. I imagine you'd have to recompile all the scripts involved to get your changes to take effect. Just adjusting a nss file which has not main won't affect any other file and generally to make things work there are lots of files involved.
I would think it would be better to store preferences on the player if they are DM specific ( ie as a DM i prefer x y and z ), but the other options should be put into on module load. By definition a DM is a MP thing, which means using NWNx and mysql becomes a much better option for this.
#5
Posté 28 octobre 2011 - 06:15
Got ya. So with the example above, I can just switch GetModule() with GetFirstPC(), and it should work for the whole campaign.
#6
Posté 28 octobre 2011 - 06:30
For your exemple i'd use global int. You need to access those info everywhere, global int are made for that.
Modifié par Shallina, 28 octobre 2011 - 06:34 .
#7
Posté 28 octobre 2011 - 08:47
thanks, I'll give it a try.
#8
Posté 15 novembre 2011 - 08:51
well, I used the global ints, and it worked great... or so I thought. I just realised that if you save game, log off, and restart, all settings revert to default. Are global ints not saved?
I think I'll try using a local int stored on the pc, if nobody has a better idea.
I think I'll try using a local int stored on the pc, if nobody has a better idea.
#9
Posté 15 novembre 2011 - 09:01
I use what i call dataobjects.
It is a local string, dropped on an object ( an item ), stored in campaign database after changes to ensure its persistent. I plan on making it transparently work with mysql and sqlite at some point, but this works well in single player and on persistent worlds. I have a special placeable i store these in, which all them to sit in inventory, as well as quite a few complex work arounds for technical issues to do with caching, and quickly accessing these objects after they are set up. All of this is abstracted so those coding it won't have to know how it works.
Sidesteps using the campaign database issues ( ie it can mangle data and is slow ) by combining the ability to store an object with storing data on that object. It also ensures the data is not lost on loading the module, or for other reasons. Generally a safe spot is in the characters inventory ( ie the DMFI tool ) but then that is not always safe enough, and it tends to drop out of inventory all the time.
You probably just want to put your values on the actual DMFI tool since it's an item the dm will have, and that would let each DM have different preferences.
The preferences i already discussed are initialized from values in a 2da file, which is an easy way for users to edit them, but it could easily be adjusted soas to allow users to edit them in game, and to only load them if the object was missing or corrupted. A UI to edit these values i intend on looking at implementing as well, which i think would handle most of what you are looking at putting in your book.
A module load script could easily set variables for the module based on what is in the preferences, usually a module is configured via variables put on the module object in the toolset.
It is a local string, dropped on an object ( an item ), stored in campaign database after changes to ensure its persistent. I plan on making it transparently work with mysql and sqlite at some point, but this works well in single player and on persistent worlds. I have a special placeable i store these in, which all them to sit in inventory, as well as quite a few complex work arounds for technical issues to do with caching, and quickly accessing these objects after they are set up. All of this is abstracted so those coding it won't have to know how it works.
Sidesteps using the campaign database issues ( ie it can mangle data and is slow ) by combining the ability to store an object with storing data on that object. It also ensures the data is not lost on loading the module, or for other reasons. Generally a safe spot is in the characters inventory ( ie the DMFI tool ) but then that is not always safe enough, and it tends to drop out of inventory all the time.
You probably just want to put your values on the actual DMFI tool since it's an item the dm will have, and that would let each DM have different preferences.
The preferences i already discussed are initialized from values in a 2da file, which is an easy way for users to edit them, but it could easily be adjusted soas to allow users to edit them in game, and to only load them if the object was missing or corrupted. A UI to edit these values i intend on looking at implementing as well, which i think would handle most of what you are looking at putting in your book.
A module load script could easily set variables for the module based on what is in the preferences, usually a module is configured via variables put on the module object in the toolset.
Modifié par painofdungeoneternal, 15 novembre 2011 - 09:08 .
#10
Posté 15 novembre 2011 - 09:33
Global variable values should be being saved across game loads. I suspect something, possibly the on module load script, is setting them to the default values.
#11
Posté 15 novembre 2011 - 09:42
does the on module loaded script fire even if it is a saved game loading? If it does, it could be resetting my variables.
I'm trying to wrap my mind around your dataobjects. I need to read more.
edit- thanks Kaldor
I'll add a "fire once" variable to the script so it only sets the ints on the first load.
I'm trying to wrap my mind around your dataobjects. I need to read more.
edit- thanks Kaldor
I'll add a "fire once" variable to the script so it only sets the ints on the first load.
Modifié par bealzebub, 15 novembre 2011 - 09:47 .





Retour en haut







