Why include constants in a mod? Should they be in a separate script or included in a particular script of the mod, such as area or module scripts?
Can someone define constants
Débuté par
Sonmeister
, mai 03 2010 11:23
Retour en haut
#2
Posté 04 mai 2010 - 12:37
DavidSims
-
- BioWare Employees
-
- 196 messages
constants can be defined anywhere, really. Normaly they are defined at the top of a script, beneath the include files but above any function implementation. Or they are defined in an include file, also above any function implementation.
The reason for constants is to avoid typos, to make it easier to track down which tags/resources are used in scripts and to allow changes to be made quickly. Putting the constants in include files allows them to be used in multiple different scripts, and to change all of those scripts by making just one change, so I recomend doing so. You can declare constants in the script that contains the main/startingconditonal function, but if you ever find yourself using that same constant somewhere else I advise moving it to an include file rather than duplicating the definition.
As an example, say you are making a quest for the player to bring the magic gem to the mystic mountain. When the player talks to the quest giver, he gives them the gem. You could use the resource literal in the script, but then you're going to have to potentialy use it again when you take away the gem. That's two places you could make a typo, and it's also two places you have to remember to change if you ever change the resource name. Who knows, maybe you change your mind and make it a magic ring instead, and don't like working with the out of date resource names. With a constant declared in an include file, you can type out the literal only once, and use the constant everywhere else.
Constants can also be used for more mathmatical purposes with integers or floats. Perhaps you have a heartbeat system that sends events every 1.0 seconds, and does so from mutliple places in multiple scripts. If you make it a constant, you can easly increase or decrease the delay time across all scripts by changing it in the one place. Or maybe you have a system that spawns new oppontents into a fight, to maintain 10. If you use a constant, you can change it to 12 more easily.
I also like to use constants to provide more descriptive names. Strings are resources are limited in length, and sometimes are named based on conventions that don't include the player facing name. The various equipable items the player gets in origins have particularly unhelpful names.
The reason for constants is to avoid typos, to make it easier to track down which tags/resources are used in scripts and to allow changes to be made quickly. Putting the constants in include files allows them to be used in multiple different scripts, and to change all of those scripts by making just one change, so I recomend doing so. You can declare constants in the script that contains the main/startingconditonal function, but if you ever find yourself using that same constant somewhere else I advise moving it to an include file rather than duplicating the definition.
As an example, say you are making a quest for the player to bring the magic gem to the mystic mountain. When the player talks to the quest giver, he gives them the gem. You could use the resource literal in the script, but then you're going to have to potentialy use it again when you take away the gem. That's two places you could make a typo, and it's also two places you have to remember to change if you ever change the resource name. Who knows, maybe you change your mind and make it a magic ring instead, and don't like working with the out of date resource names. With a constant declared in an include file, you can type out the literal only once, and use the constant everywhere else.
Constants can also be used for more mathmatical purposes with integers or floats. Perhaps you have a heartbeat system that sends events every 1.0 seconds, and does so from mutliple places in multiple scripts. If you make it a constant, you can easly increase or decrease the delay time across all scripts by changing it in the one place. Or maybe you have a system that spawns new oppontents into a fight, to maintain 10. If you use a constant, you can change it to 12 more easily.
I also like to use constants to provide more descriptive names. Strings are resources are limited in length, and sometimes are named based on conventions that don't include the player facing name. The various equipable items the player gets in origins have particularly unhelpful names.
#3
Posté 05 mai 2010 - 08:21
DavidSims
-
- BioWare Employees
-
- 196 messages
I'm not clear what you're doing exactly, Recklezz. A constant isn't set or cleared. Constants are declared in a script, and used anywhere in that script bellow where they are declared. That's the full extent of their scope.
My best guess as to what is happening to you is that the exported version of something is being put in a global override directory and effecting modules you don't intend it to.
A more concrete example of what you are doing would help.
My best guess as to what is happening to you is that the exported version of something is being put in a global override directory and effecting modules you don't intend it to.
A more concrete example of what you are doing would help.
#4
Posté 05 mai 2010 - 11:09
DavidSims
-
- BioWare Employees
-
- 196 messages
A constant is not a variable stored on the module. const int DMO001_EVENTS_OVERRIDE = 0; and SetLocalInt(oModule, "DMO001_EVENTS_OVERRIDE",1);are two totally unrelated things. You're question really seems to be about exports, intercepted events and override directories, not about constants at all. Unfortunately, override folders and intercepted events are not really my strong point. I haven't made anything in the end use toolset, and haven't had to deal with compatibility issues.
Here’s what I can tell you. If you're intercepting an event and running GetLocalInt(oModule, "DMO001_EVENTS_OVERRIDE") and that's returning something other than 0, then one of three things is happening. One is that the variable has a default value that isn't 0. Two is that the module variable table has been changed to have a starting value that isn't 0. Three is that in some script, somewhere, SetLocalInt(oModule, "DMO001_EVENTS_OVERRIDE",1); is being run.
Most likely we're looking at the last option. Are you modifying module_core, or are you making a new script and setting it as your module script? If you're modifying module_core, that may be exported into an override directory that's effecting all campaigns. Instead of modifying module_core, make a new script, and pass the event to module_core at the end. Assign the new script as your module's script.
For this however, you don't even need a custom script. Instead of assigning the variable through script, open your module, go to manage modules, select your module, hit properties and find the variables table. Click on that, find your variable, and set the value to 1 instead of 0. Only your module will have that variable set, so you shouldn't have any problems in other modules.
edit: to be clear, have you tried running single player with restarting DA? Are you sure that the problem only surfaces when you run your module first?
Here’s what I can tell you. If you're intercepting an event and running GetLocalInt(oModule, "DMO001_EVENTS_OVERRIDE") and that's returning something other than 0, then one of three things is happening. One is that the variable has a default value that isn't 0. Two is that the module variable table has been changed to have a starting value that isn't 0. Three is that in some script, somewhere, SetLocalInt(oModule, "DMO001_EVENTS_OVERRIDE",1); is being run.
Most likely we're looking at the last option. Are you modifying module_core, or are you making a new script and setting it as your module script? If you're modifying module_core, that may be exported into an override directory that's effecting all campaigns. Instead of modifying module_core, make a new script, and pass the event to module_core at the end. Assign the new script as your module's script.
For this however, you don't even need a custom script. Instead of assigning the variable through script, open your module, go to manage modules, select your module, hit properties and find the variables table. Click on that, find your variable, and set the value to 1 instead of 0. Only your module will have that variable set, so you shouldn't have any problems in other modules.
edit: to be clear, have you tried running single player with restarting DA? Are you sure that the problem only surfaces when you run your module first?
Modifié par DavidSims, 05 mai 2010 - 11:12 .
