In this part of the documentation, we examine the smallest module files in the system, files with the least overall impact on your module. However, these files can still be very useful in many ways. By the end of this chapter, you will know how to get the most out of each of them.
6.1 -- Module_Constants
module_constants.py is a very simple file. It is filled with constants -- you should already know how these work from reading Part 3 of this documentation. The constants in module_constants are exactly the same as constants defined anywhere else, but constants which are used in multiple module files should be defined in module_constants so that the module system always knows where to find them.
Module_constants also serves as an organised, easily-accessible list where you can change the value of a constant whenever you might need to. Any changes will immediately affect all operations using the constant, so that you don't need to do a manual find/replace.
For example, changing marnid_inn_entry = 2 to marnid_inn_entry = 4 would immediately change any operations using marnid_inn_entry, treating the constant as the value 4 instead of the value 2.
6.2 -- Module_Factions
module_factions.py contains all the factions used by the module system and by M&B's artificial intelligence. Though a small file, it governs several important settings which we will cover here.
The file immediately begins with a Python list: factions = [. As in most of the module files, the first few tuples are hardwired into the game and should not be edited.
Example of a faction:
("innocents","Innocents", 0, 0.5,[("outlaws",-0.05)]),
This is a short, simple tuple. It governs the "Innocents" faction, whose only major enemy is the "outlaws" faction. If a faction's relation with "innocents" is not defined anywhere in module_constants, it will automatically be set to 0, hence the two factions will be absolutely neutral to each other.
Breakdown of the tuple fields:
1 ) Faction id. Used for referencing factions in other files.
2 ) Faction name.
3 ) Faction flags.
4 ) Faction coherence. The relation between different members of this faction.
5 ) Inter-faction relations. Each relation record is a tuple that contains the following fields:
5.1 ) Faction. Which other faction this relation is referring to.
5.2 ) Relation. The state of relations between the two factions. Values range between -1 and 1.
Innocents tuple examination:
1 ) Faction id = "innocents"
2 ) Faction name = "Innocents"
3 ) Faction flags = 0
4 ) Faction coherence = 0.5
5 ) Inter-faction relations:
5.1 ) Faction = "outlaws"
5.2 ) Relation = 0.05
This faction has no flags, a neutral faction coherence, and no enemies other than "outlaws" defined in its tuple. However, if we look elsewhere, we can find that (for example) "dark_knights" have a relation of -0.9 with "innocents", as defined in the "dark_knights" tuple. This is because a relation works two ways -- it only needs to be set once, and the value will count for both factions.
Now, create a new faction tuple by copying "innocents" and pasting it to the bottom of the list. Change the faction id and name to "geoffrey", and then switch "outlaws" in the relations list to "player_faction".
Save your progress. Once you've done that, open module_party_templates.py and module_troops.py, and change the faction of the template "new_template" and the faction of the troop "Geoffrey" to "fac_geoffrey". Save, and close the files. Click on build_module.bat. If all went well, parties of "new_template" will now visibly have "Geoffrey" as their faction, and they will be hostile to the player.
6.3 -- Module_Strings
module_strings.py is arguably the simplest file in the module system. It contains strings -- blocks of text which can be displayed in various ways. Strings are used all throughout the module system, from module_dialogs to module_quests; whenever a block of text needs to be displayed on the screen. Module_strings, however, is a repository for independent strings, which aren't bound to any single file. Therefore they can be called by operations from anywhere in the module system.
You can see these strings used in various places in the game, as white scrolling messages at the lower left of your screen, or in a tutorial box, or even inserted into a game menu or dialogue sequence.
Much like module_factions, this file immediately begins with a Python list: strings = [. Again, the first few tuples are hardwired into the game and should not be edited.
Example of a string:
("door_locked","The door is locked."),
Tuple breakdown:
1 ) String id. Used for referencing strings in other files.
2 ) String text.
One notable feature of strings is the ability to put a register value or even another string inside of it. You can do this by adding, for example, {reg0} in the string. This will display the current value of reg(0). {reg10} would display the current value of reg(10), and so on.
For additional strings, you must use the string register instead of a normal register; this is because strings are stored separately from registers. For example, {s2} would display the contents of string register 2 -- not the contents of reg(2). You can freely use string register 2 and reg(2) at the same time for different things, they will not overlap or interfere with each other.
In dialogue, it is also possible to display parts (or all) of a string's contents differently depending on the gender of the person being addressed. For example, inserting {sir/madam} into a string will cause the word "sir" to be displayed when the addressed person is male, and "madam" if the person is female.
All of these options (except gender-based alternation) will work perfectly in any kind of string field. Gender-based alternation only works in dialogue.
For the purposes of the operation "display_message", it is possible to display a string in various colours, by appending a hexadecimal colour code to the operation. For example, (display_message,<string_id>,[hex_colour_code]),
Here is a list of useable hex codes for display_message:
blue = 0xFFAAAAFF
light blue = 0xFFAAD8FF
red = 0xFFFFAAAA
yellow = 0xFFFFFFAA
pink = 0xFFFFAAFF
purple = 0xFF6AAA89
black = 0xFFAAAAAA
white = 0xFFFFFFFF
green = 0xFFAAFFAA
brown = 0xFF7A4800
6.4 -- Module_Quests
module_quests.py is the last of our small, simple files. It contains quests, including all the text related to those quests. Putting new quests here allows them to be activated via the module system, so that operations can read the quest's current status and use that status as a condition operation.
Example of a quest:
("hunt_down_river_pirates", "hunt down river pirates", qf_show_progression,
"Constable Hareck asked you to hunt down the river pirates that plague the country around Zendar.\
He promised to pay you 5 denars for each river pirate party you eliminate."
),
This quest needs no introduction. We've all hunted down the river pirates at some point or another. Its interesting points are the flag qf_show_progression, and the fact that it uses a backslash -- \ -- to allow a line break in its string. Note, however, that using a backslash does not currently put a line break in the in-game text. It is used here only for neatness.
Tuple breakdown:
1 ) Quest id. Used for referencing quests in other files.
2 ) Quest Name. The name of the quest as displayed in the quest list on the left of the quest screen.
3 ) Quest flags.
4 ) Quest Description. The long description of the quest, as displayed in the large text box at the top right of the quest screen.
River pirates tuple examination:
1 ) Quest id = "hunt_down_river_pirates"
2 ) Quest Name = "hunt down river pirates"
3 ) Quest flags = qf_show_progression
4 ) Quest Description = "Constable Hareck asked you to hunt down the river pirates that plague the country around Zendar.\
He promised to pay you 5 denars for each river pirate party you eliminate."
qf_show_progression is what gives this quest its percentage of completion, seen on the right of the quest list. The quest list can be found at the left of your quest screen. This percentage does not increment automatically; you will have to set it via operations if you wish to make use of it.
If you wish to make a quest without any flags, simply put a 0 in the flags field.
At this point, we make the first step in creating our own little quest. Copy the following quest tuple and paste it to the bottom of the Python list:
("speak_with_troublemakers", "Parley with the troublemakers", 0,
"Constable Hareck asked you to deal with a bunch of young nobles making trouble around town. How you want to tackle the problem is up to you; Hareck has promised a purse of silver if you succeed."
),
Note the construction of this tuple. You can see, it takes only a few changes to make a new quest, but incorporating it into the game requires a lot more work. For that reason, our next target will be module_dialogs.py -- where we will be putting our new quest, troops and party templates to use.
Save your progress, close the file and click on build_module.bat. If all went well, you will be ready to move on to Part 7 of this documentation.
Changelog May 31, 20:11: Added string colour information.
Changelog May 31, 23:11: Clarified segment 6.3.
6.1 -- Module_Constants
module_constants.py is a very simple file. It is filled with constants -- you should already know how these work from reading Part 3 of this documentation. The constants in module_constants are exactly the same as constants defined anywhere else, but constants which are used in multiple module files should be defined in module_constants so that the module system always knows where to find them.
Module_constants also serves as an organised, easily-accessible list where you can change the value of a constant whenever you might need to. Any changes will immediately affect all operations using the constant, so that you don't need to do a manual find/replace.
For example, changing marnid_inn_entry = 2 to marnid_inn_entry = 4 would immediately change any operations using marnid_inn_entry, treating the constant as the value 4 instead of the value 2.
6.2 -- Module_Factions
module_factions.py contains all the factions used by the module system and by M&B's artificial intelligence. Though a small file, it governs several important settings which we will cover here.
The file immediately begins with a Python list: factions = [. As in most of the module files, the first few tuples are hardwired into the game and should not be edited.
Example of a faction:
("innocents","Innocents", 0, 0.5,[("outlaws",-0.05)]),
This is a short, simple tuple. It governs the "Innocents" faction, whose only major enemy is the "outlaws" faction. If a faction's relation with "innocents" is not defined anywhere in module_constants, it will automatically be set to 0, hence the two factions will be absolutely neutral to each other.
Breakdown of the tuple fields:
1 ) Faction id. Used for referencing factions in other files.
2 ) Faction name.
3 ) Faction flags.
4 ) Faction coherence. The relation between different members of this faction.
5 ) Inter-faction relations. Each relation record is a tuple that contains the following fields:
5.1 ) Faction. Which other faction this relation is referring to.
5.2 ) Relation. The state of relations between the two factions. Values range between -1 and 1.
Innocents tuple examination:
1 ) Faction id = "innocents"
2 ) Faction name = "Innocents"
3 ) Faction flags = 0
4 ) Faction coherence = 0.5
5 ) Inter-faction relations:
5.1 ) Faction = "outlaws"
5.2 ) Relation = 0.05
This faction has no flags, a neutral faction coherence, and no enemies other than "outlaws" defined in its tuple. However, if we look elsewhere, we can find that (for example) "dark_knights" have a relation of -0.9 with "innocents", as defined in the "dark_knights" tuple. This is because a relation works two ways -- it only needs to be set once, and the value will count for both factions.
Now, create a new faction tuple by copying "innocents" and pasting it to the bottom of the list. Change the faction id and name to "geoffrey", and then switch "outlaws" in the relations list to "player_faction".
Save your progress. Once you've done that, open module_party_templates.py and module_troops.py, and change the faction of the template "new_template" and the faction of the troop "Geoffrey" to "fac_geoffrey". Save, and close the files. Click on build_module.bat. If all went well, parties of "new_template" will now visibly have "Geoffrey" as their faction, and they will be hostile to the player.
6.3 -- Module_Strings
module_strings.py is arguably the simplest file in the module system. It contains strings -- blocks of text which can be displayed in various ways. Strings are used all throughout the module system, from module_dialogs to module_quests; whenever a block of text needs to be displayed on the screen. Module_strings, however, is a repository for independent strings, which aren't bound to any single file. Therefore they can be called by operations from anywhere in the module system.
You can see these strings used in various places in the game, as white scrolling messages at the lower left of your screen, or in a tutorial box, or even inserted into a game menu or dialogue sequence.
Much like module_factions, this file immediately begins with a Python list: strings = [. Again, the first few tuples are hardwired into the game and should not be edited.
Example of a string:
("door_locked","The door is locked."),
Tuple breakdown:
1 ) String id. Used for referencing strings in other files.
2 ) String text.
One notable feature of strings is the ability to put a register value or even another string inside of it. You can do this by adding, for example, {reg0} in the string. This will display the current value of reg(0). {reg10} would display the current value of reg(10), and so on.
For additional strings, you must use the string register instead of a normal register; this is because strings are stored separately from registers. For example, {s2} would display the contents of string register 2 -- not the contents of reg(2). You can freely use string register 2 and reg(2) at the same time for different things, they will not overlap or interfere with each other.
In dialogue, it is also possible to display parts (or all) of a string's contents differently depending on the gender of the person being addressed. For example, inserting {sir/madam} into a string will cause the word "sir" to be displayed when the addressed person is male, and "madam" if the person is female.
All of these options (except gender-based alternation) will work perfectly in any kind of string field. Gender-based alternation only works in dialogue.
For the purposes of the operation "display_message", it is possible to display a string in various colours, by appending a hexadecimal colour code to the operation. For example, (display_message,<string_id>,[hex_colour_code]),
Here is a list of useable hex codes for display_message:
blue = 0xFFAAAAFF
light blue = 0xFFAAD8FF
red = 0xFFFFAAAA
yellow = 0xFFFFFFAA
pink = 0xFFFFAAFF
purple = 0xFF6AAA89
black = 0xFFAAAAAA
white = 0xFFFFFFFF
green = 0xFFAAFFAA
brown = 0xFF7A4800
6.4 -- Module_Quests
module_quests.py is the last of our small, simple files. It contains quests, including all the text related to those quests. Putting new quests here allows them to be activated via the module system, so that operations can read the quest's current status and use that status as a condition operation.
Example of a quest:
("hunt_down_river_pirates", "hunt down river pirates", qf_show_progression,
"Constable Hareck asked you to hunt down the river pirates that plague the country around Zendar.\
He promised to pay you 5 denars for each river pirate party you eliminate."
),
This quest needs no introduction. We've all hunted down the river pirates at some point or another. Its interesting points are the flag qf_show_progression, and the fact that it uses a backslash -- \ -- to allow a line break in its string. Note, however, that using a backslash does not currently put a line break in the in-game text. It is used here only for neatness.
Tuple breakdown:
1 ) Quest id. Used for referencing quests in other files.
2 ) Quest Name. The name of the quest as displayed in the quest list on the left of the quest screen.
3 ) Quest flags.
4 ) Quest Description. The long description of the quest, as displayed in the large text box at the top right of the quest screen.
River pirates tuple examination:
1 ) Quest id = "hunt_down_river_pirates"
2 ) Quest Name = "hunt down river pirates"
3 ) Quest flags = qf_show_progression
4 ) Quest Description = "Constable Hareck asked you to hunt down the river pirates that plague the country around Zendar.\
He promised to pay you 5 denars for each river pirate party you eliminate."
qf_show_progression is what gives this quest its percentage of completion, seen on the right of the quest list. The quest list can be found at the left of your quest screen. This percentage does not increment automatically; you will have to set it via operations if you wish to make use of it.
If you wish to make a quest without any flags, simply put a 0 in the flags field.
At this point, we make the first step in creating our own little quest. Copy the following quest tuple and paste it to the bottom of the Python list:
("speak_with_troublemakers", "Parley with the troublemakers", 0,
"Constable Hareck asked you to deal with a bunch of young nobles making trouble around town. How you want to tackle the problem is up to you; Hareck has promised a purse of silver if you succeed."
),
Note the construction of this tuple. You can see, it takes only a few changes to make a new quest, but incorporating it into the game requires a lot more work. For that reason, our next target will be module_dialogs.py -- where we will be putting our new quest, troops and party templates to use.
Save your progress, close the file and click on build_module.bat. If all went well, you will be ready to move on to Part 7 of this documentation.
Changelog May 31, 20:11: Added string colour information.
Changelog May 31, 23:11: Clarified segment 6.3.
