Modding Q&A [For Quick Questions and Answers]

Users who are viewing this thread

Status
Not open for further replies.
Cozur said:
Which texture contains the loading bar?

As in, which .dds file has the loading bar thingie in it, been trying to find it, and either I'm blind, or it's cleverly hidden somewhere.
interface.dds
It is colored from the tan in the texture file by vertex coloration on the mesh, which is found in core_ui_meshes.brf as progressbar_handle

Cozur said:
Also, I'm looking for a way to change the loading screen text, so instead of saying "Loading Textures..." it says "Prepare for running out of memory..." or something like that.
This you'll find in the .csv language files, specifically ui.csv and the lines begin with ui_loading_*
 
I'm making new troop types and I was wondering about the faction field (fac_commoners, fac_neutral, fac_kingdom_# and the like). For non-hero troop types, that's mostly used to determine party morale effects, right? In my mod, I'm doing village and town recruitment where the unit types you can get from them are common to all factions, with recruits from castles the ones that are faction-specific. I just need to make sure it's "safe" to put recruitable units under fac_commoners and that nothing weird happens to them when I do so (like them somehow getting the increased wages of mercenaries, etc etc)
 
Alright, I read this under the intro to module system syntax and usage:

Local variables - ":variable" - variables declared with a : are local variables.  They only exist in the current code block--enclosed by brackets [ ] --and cannot be referenced in other code blocks unless passed as script parameters. One should initialize them (to 0 or another suitable value) before they are used as they main contain a value already. They are enclosed with quotations " ". Ex: ":agent_id"
Global variables - "$variable" - variables declared with a $ are global variables.  They are available to be referenced in any part of the code, from any module_*, once they are defined. Their default value is 0. They are enclosed in quotations " ". Ex: "$g_talk_troop"


global variables are by default assigned the value 0. So, are newly made local variables, by default, also assigned the value 0?



Edit:

I also have a couple of questions regarding the header operations file.

Lets look at this example (from the updated header operations file, posted on the forum):

store_faction_of_party                = 2204  # (store_faction_of_party, <destination>, <party_id>),
                                                          # Retrieves current faction allegiance of the party.

1)  Reading the header operations file: what does <destination> mean? What code can I write into that field? Is the code you put in the field retrieved from a module or header file?

Also

2)  Reading the header operation <party_id> . The code I am looking at  has “$current_town” as part_id. However ,there is no party_ id under module_parties that is name $current_town.

Thank you in advance for any answers.

 
Destinations are always variables or registers, so initialization may not be necessary. $current_town is a common global variable that is set whenever the player encounters a town party and enters its menu.
 
phlpp said:
I'm making new troop types and I was wondering about the faction field (fac_commoners, fac_neutral, fac_kingdom_# and the like). For non-hero troop types, that's mostly used to determine party morale effects, right? In my mod, I'm doing village and town recruitment where the unit types you can get from them are common to all factions, with recruits from castles the ones that are faction-specific. I just need to make sure it's "safe" to put recruitable units under fac_commoners and that nothing weird happens to them when I do so (like them somehow getting the increased wages of mercenaries, etc etc)
As far as I know, non-hero troop faction does not play any role in the game at all, it's there just for convenience. You can switch all your Rhodok troops to fac_commoners, and they will recruit, upgrade and fight just as fine. Might cause problems in MP though (unlikely, but possible, I didn't examine MP code thoroughly so cannot give any guarantees here).
 
I would like help on how to add a custom troop type to be a recruitable mercenary in the taverns (this is for WFAS). I know this has been asked dozens of times before, but somehow after a search through the forums I am still unable to get it working.

I tried editing the Troops.txt file to add all the code for my new soldier below the 'Watchman' (mercenary halberdier) in the section beginning with 'Farmer' and finishing with 'Mercenaries_End' (which I was told was where all the recruitable mercenary troops should go) but when I started up the game I found that it had completely screwed up all the troop types. Jaques de Clermont was some fellow with a robe and beard, there were Noble Guard looters, and the townsfolk were all random soldiers like pikemen and musketeers.

Is there anyone who could help me figure out how on earth to get this thing to work? I would really like to see this new troop type I created (outfitted with custom items I made) appear as hireable soldiers in various taverns.

Thanks!
 
You need to realize that the game engine is dumb and doesn't know what trp_watchman and trp_mercenaries end are. When the module system is compiled and the scripts to update the mercenary in each center is written to scripts.txt (update_mercenary_units_of_towns , update_mercen_units_of_castle), it takes the existing offset id of each entity (for example trp_watchman = 27 and trp_mercenaries_end = 33), which ends up being bit-shifted to avoid collision with other objects, and so you'll get 2136 3 1224979098644774913 360287970189639707 360287970189639713 where 2136 corresponds to store_random_in_range, the 3 is the number of parameters, the variable id immediately after that being the destination, and the last 2 are  the troop ranges (27 and 33 shifted).

When you inserted your new unit in between these numbers, it ends up shifting the id of each subsequent troop (trp_mercenaries_end  becomes #34), but the script still references the old offset. Since the entire game is wholly dependent on the offset system, the manual insertion of any troop except at the bottom will screw up all your savegames. What you can do is decrement the range in that script to get 360287970189639706, which will include the townsman troop (which isn't used by the AI in-game at all unless it upgrades from a rescued farmer); or increment 360287970189639714 to get the mercenaries_end placeholder troop itself included in the range and modify those troops accordingly. What you should do, however, is get the module system, which will do most of that for you.
 
Thanks for the answer to my previous questions. Now I have a few more.

Variables

Is there a list of global variables somewhere? Can I make my own global variables like local variables?

"$current_town" what does this global variable do exactly? I understand it is “set” when a play enters a town party and enters its menu. But, what is "$current_town" set to?

Is "$current_town" just a way to find the party_id of the town the player is currently at?
Then you can use slots to check information about that town; such as its relation with the player?

Slots

I am having trouble understanding slots. I read the intro to the module system syntax and usage tutorial and this is what I get. A slot is a way to look up or set a variable dealing with something such as an item, party, ect.

However where is the variable located? The example from the tutorial says:

(slot_item_base_price = 53).  This means that the engine looks at the 53rd slot-variable

associated with a given item to find that item's base price.

Where can I find the 53rd variable of an item? Or in other words where can I find the variable that is an items base price? I looked in the module_items , but I found nothing regarding an items base price.



 
Muffin Raider said:
Is there a list of global variables somewhere? Can I make my own global variables like local variables?
variables.txt. It's autocreated while compiling native module system.
You are free to create your own global variables.

Muffin Raider said:
"$current_town" what does this global variable do exactly? I understand it is “set” when a play enters a town party and enters its menu. But, what is "$current_town" set to?
Is "$current_town" just a way to find the party_id of the town the player is currently at?
Then you can use slots to check information about that town; such as its relation with the player?
While main party encounted towns or castles, "$current_town" is set to the encountered party.
Just look at some lines at module_game_menus.py :
  (assign, "$current_town","$g_encountered_party"),
If you are at the town menus, and you need to get the town's relation with player, yes you can get it from relation slot of "$current_town".


Muffin Raider said:
I am having trouble understanding slots. I read the intro to the module system syntax and usage tutorial and this is what I get. A slot is a way to look up or set a variable dealing with something such as an item, party, ect.

However where is the variable located? The example from the tutorial says:

(slot_item_base_price = 53).  This means that the engine looks at the 53rd slot-variable

associated with a given item to find that item's base price.

Where can I find the 53rd variable of an item? Or in other words where can I find the variable that is an items base price? I looked in the module_items , but I found nothing regarding an items base price.

parties, factions, troops, items, scenes, agents, quests, teams and scene_props have slots.
You can get beard base price and save it to local variable or registers :

(item_get_slot, ":base_price", "itm_beard", slot_item_base_price),  # save it to ":base_price" local variable
(item_get_slot, reg0, "itm_beard", slot_item_base_price),  # save it to register 0
 
What dunde said and:
- $current_town is a party id, just a number, and is used to get town properties, correct
- Slots are arrays of integers that belong to an item, party, troop etc. (each item, party etc. has their own separate integer array.) Their definitions are in module_constants.py, and you can add your own slots, and remove existing ones - each slot is just an index in an array. They are indispensable for advanced features. Once you understand slots, you are past the beginner phase.
- Get a nice editor like Notepad++, or any that can search for strings over multiple files.
- Write test code (typically placed in a Camp submenu) that prints variable values when you experiment with code. Also insert debug messages (display_message) to print variable values in the code that interests you.

Example.. let's say you are baffled by $g_encountered_party. What is it and what does it do? (I'm preempting your next question here lol):
1. Do a global search for $g_encountered_party. Many hits, but it's set only in one place (I think :smile:).
At the start of script_game_event_party_encounter:
(store_script_param_1, "$g_encountered_party"),
2. You read the description of script_game_event_party_encounter and deduce it is the party id of the encountered party.
3. You further see how it's used all over the module system. It can be a lone party, one of the parties in battle, or a location (which are parties too).
4. You get sidetracked by script_game_event_party_encounter and want to see how does it really work, so you insert temporary debug code:
      (store_script_param_1, "$g_encountered_party"),
      (store_script_param_2, "$g_encountered_party_2"),# encountered_party2 is set when we come across a battle or siege, otherwise it's a negative value
      (str_store_party_name, s5, "$g_encountered_party"),
      (display_message, "@{!}DEBUG: You encountered a party named {s5}!"),

You build the module system, run the game, and get interesting debug messages.
5. Profit :smile:
 
Somebody said:
You need to realize that the game engine is dumb and doesn't know what trp_watchman and trp_mercenaries end are. When the module system is compiled and the scripts to update the mercenary in each center is written to scripts.txt (update_mercenary_units_of_towns , update_mercen_units_of_castle), it takes the existing offset id of each entity (for example trp_watchman = 27 and trp_mercenaries_end = 33), which ends up being bit-shifted to avoid collision with other objects, and so you'll get 2136 3 1224979098644774913 360287970189639707 360287970189639713 where 2136 corresponds to store_random_in_range, the 3 is the number of parameters, the variable id immediately after that being the destination, and the last 2 are  the troop ranges (27 and 33 shifted).

When you inserted your new unit in between these numbers, it ends up shifting the id of each subsequent troop (trp_mercenaries_end  becomes #34), but the script still references the old offset. Since the entire game is wholly dependent on the offset system, the manual insertion of any troop except at the bottom will screw up all your savegames. What you can do is decrement the range in that script to get 360287970189639706, which will include the townsman troop (which isn't used by the AI in-game at all unless it upgrades from a rescued farmer); or increment 360287970189639714 to get the mercenaries_end placeholder troop itself included in the range and modify those troops accordingly. What you should do, however, is get the module system, which will do most of that for you.

Thanks a lot. I have tried to download the module system, but I'm still working out a few kinks in how to run the darn thing. I think I'm going to have to look around for a tutorial before I try any more scripting.

Many thanks again for the advice :smile:

By the way, I would also like to ask if anyone knows how the wages for troops in the game are determined. Is it based on their individuals skills, their overall level, their equipment, or what? The reason I'm asking is because I would like to be sure that, for example, a really elite troop that I create doesn't end up costing 3 thaler or something.
 
VN-Killah said:
By the way, I would also like to ask if anyone knows how the wages for troops in the game are determined. Is it based on their individuals skills, their overall level, their equipment, or what? The reason I'm asking is because I would like to be sure that, for example, a really elite troop that I create doesn't end up costing 3 thaler or something.
Check out the script "game_get_troop_wage"
 
Hello everyone,

I've some questions for my mod, I hope you can help me with those:

First, I want to edit the multiplayer mode in my mod, so, I've made new factions and I want to have a multiplayer mode with those factions. How can I do this?

Second, I want to chance the banners of some kings. How can i make this possible?

Third, I want to edit the costum battle mode. With different troops from troops.txt Is that possible? If it is, how?

I hope you can help me, this will make my mod completely finished... almost  :cool:
 
Thank you very much  MadVader and dunde for your help.

- Slots are arrays of integers that belong to an item, party, troop etc. (each item, party etc. has their own separate integer array.) Their definitions are in module_constants.py, and you can add your own slots, and remove existing ones - each slot is just an index in an array. They are indispensable for advanced features. Once you understand slots, you are past the beginner phase.

Yeah, I am still working on understanding slots. What I am trying to figure out is where exactly slot information comes from. Yes I know it comes from an array of integers that belong to the item, party, ect, BUT where is the so called “integer array” located? Are the arrays in some code we cannot see/access and the only way to get the info is to use slots to pull that information out of where ever it may be?

- Write test code (typically placed in a Camp submenu) that prints variable values when you experiment with code. Also insert debug messages (display_message) to print variable values in the code that interests you.

Awesome idea thanks for this bit of info, all newbies should hear this. along with your tutorial below.

Example.. let's say you are baffled by $g_encountered_party. What is it and what does it do? (I'm preempting your next question here lol):
1. Do a global search for $g_encountered_party. Many hits, but it's set only in one place (I think :smile:).

Yes, this is why I was confused with “$current_town”. I saw it had been assigned various values throughout the code.

I used notepad++ (thanks) did a search and found:

Line 66:      (assign, "$current_town", "p_town_6"),
Line 76:          (assign, "$current_town", "p_town_8"),
Line 86:          (assign, "$current_town", "p_town_10"),
Line 96:          (assign, "$current_town", "p_town_1"),
Line 106:          (assign, "$current_town", "p_town_5"),
Line 116:          (assign, "$current_town", "p_town_19"),
Line 5496:        (assign, "$current_town","$g_encountered_party"),
Line 7333:        (assign, "$current_town", "$g_encountered_party"),

Will these assignments create complications when using “$current_town” to get info about encountered parties?

4. You get sidetracked by script_game_event_party_encounter and want to see how does it really work, so you insert temporary debug code:
      (store_script_param_1, "$g_encountered_party"),
      (store_script_param_2, "$g_encountered_party_2"),# encountered_party2 is set when we come across a battle or siege, otherwise it's a negative value
      (set_show_messages, 1)
(str_store_party_name, s5, "$g_encountered_party"),
      (display_message, "@{!}DEBUG: You encountered a party named {s5}!"),

You build the module system, run the game, and get interesting debug messages.
5. Profit :smile:

Again debug stuff was awesome all newbies should hear it. Also thanks for making it into a small tutorial. However, for future reference I had to add in (set_show_messages, 1),  in order to get the message to display in game.


 
Muffin Raider said:
- Slots are arrays of integers that belong to an item, party, troop etc. (each item, party etc. has their own separate integer array.) Their definitions are in module_constants.py, and you can add your own slots, and remove existing ones - each slot is just an index in an array. They are indispensable for advanced features. Once you understand slots, you are past the beginner phase.

Yeah, I am still working on understanding slots. What I am trying to figure out is where exactly slot information comes from. Yes I know it comes from an array of integers that belong to the item, party, ect, BUT where is the so called “integer array” located? Are the arrays in some code we cannot see/access and the only way to get the info is to use slots to pull that information out of where ever it may be?
The low-level handling of integer arrays is hidden in the engine. They are accessed only through something_get_slot/set_slot/slot_eq/slot_ge operations, and that's all you really need. Don't worry about where they are and simply use them :smile:.

Example.. let's say you are baffled by $g_encountered_party. What is it and what does it do? (I'm preempting your next question here lol):
1. Do a global search for $g_encountered_party. Many hits, but it's set only in one place (I think :smile:).

Yes, this is why I was confused with “$current_town”. I saw it had been assigned various values throughout the code.

I used notepad++ (thanks) did a search and found:

Line 66:      (assign, "$current_town", "p_town_6"),
Line 76:          (assign, "$current_town", "p_town_8"),
Line 86:          (assign, "$current_town", "p_town_10"),
Line 96:          (assign, "$current_town", "p_town_1"),
Line 106:          (assign, "$current_town", "p_town_5"),
Line 116:          (assign, "$current_town", "p_town_19"),
Line 5496:        (assign, "$current_town","$g_encountered_party"),
Line 7333:        (assign, "$current_town", "$g_encountered_party"),

Will these assignments create complications when using “$current_town” to get info about encountered parties?
The first six assigns are hacks for the starting quests to work, so they are exceptions to the general use, and will be only assigned at most once in a game.
At the beginning of a game, your party is created close to a town, but you don't have a chance to move and really "encounter" that town (so $g_encountered_party and $current_town are not updated normally), and the easiest thing for Taleworlds was to assign them explicitly. Town menu code uses $current_town, so it needs to have a proper value. Don't lose sleep over it, unless you want to engage in similar hackery.
 
Status
Not open for further replies.
Back
Top Bottom