https://tw-modding.com/api.php?action=feedcontributions&feedformat=atom&user=Not+All+is+DustTotal War Modding - User contributions [en]2026-04-06T18:56:43ZUser contributionsMediaWiki 1.39.3https://tw-modding.com/index.php?title=UI:Build-a-Button_Workshop&diff=1043UI:Build-a-Button Workshop2023-10-17T10:30:32Z<p>Not All is Dust: changed SetImage to SetImagePath</p>
<hr />
<div>Lesson two! This time around, we build our button, select its text, give it some stuffing, and ship it off to our relatives for the holidays. We’re building a button!<br />
<br />
Before we get into the nitty-gritty, we have to back up into the nit-grit and talk about one more general concept – creating components.<br />
<br />
=== One More General Concept – Creating Components ===<br />
In the previous lecture hall, we discussed finding in-game components, the root component, parentage/childhood, and printing out info. All of this was done with stuff that was already there. We’ll be actually creating a new component object in the game, and to do that we need to understand a few things.<br />
<br />
Every UIC in the game is built off of what’s called a “layout file”. Note: this is not to be confused with the “layout” component we saw in the previous lesson. We’ll be seeing it a lot. We can find layout files by loading all CA packs, going into the ui/templates/ folder, and just scrolling on through. All of the files there have no file extension – they’re all hexidecimal files, which define a bunch of details about UIC’s ''created'' with these layout files. Each layout file can be called a bunch of times – there’s no limit to how many <code>panel_title</code> UICs there can be in the game, for instance.<br />
<br />
We won’t yet get into how to read these files and to see what each of them does – we’re going to use ye good ol’ guess-and-check method. Whenever you make a new UIC in-game, your only option is to create one off of these layout files that predefine the deets, which you can change later on.<br />
<br />
The command we use here is a method on UIC – it’s to create a direct child of a UIC. It goes like this:<br />
<br />
<code>UIComponent(uic:CreateComponent(id_of_child, layout_file_path))</code><br />
<br />
I’m going to now make-up a path-from-root UIC, but I’ll choose a real layout file path, so you get the idea:<br />
<code>local root = core:get_ui_root()<br />
local fake_uic = find_uicomponent(root, "fake_child", "this_isnt_real_cant_you_tell")<br />
<br />
local child_uic = UIComponent(fake_uic:CreateComponent("real_child", "ui/templates/round_small_button"))</code><br />
And what the above does is – it grabs the fake_uic, it creates a child UIC with the ID “real_child”, off the layout file “round_small_button”, and <code>child_uic</code> is now equivalent to that game object for the child. Pretty cool.<br />
<br />
Before we go on, we’re going to use our skillz to figure out how to make a button on some existing row of buttons. Typically this is pretty easy. Find the row of buttons you want to add onto – say, the top right row of buttons with info and stuff, or the row of buttons on the bottom of the army docker – and then click one of those buttons. You’ll get the path-from-root for the ''button'' output – you just need to find the button’s parent, one step higher up the path, and use that as the parent of this new button.<br />
<br />
With this, I advise using the DevTool Console. Have the mini-console setup while the UICs you’re messing with are ''on screen and active''. Don’t call any UICs when they’re not on screen, because they might not exist. We’ll get into that later.<br />
<br />
Try to find the template button layout file that matches the other buttons with the parent. I’ll give you a hint – the names of the layout files are pretty descriptive!<br />
<br />
Return to me when you have a perfectly valid button that does nothing and says nothing!<br />
<br />
=== Actual Usage ===<br />
At this point, you have a perfectly valid button that does nothing and says nothing. We’re going to first give it a tiny bit of spunk, and then we’ll make it actually do something upon being clicked. What it says and what it does is up to you, but I’m going to try and provide the tools needed to do both those things.<br />
<br />
First thing’s first, we want to change that image. We’re going to learn our second uic method here – SetImagePath(). It takes one arg (uh, for now) – the path to the image, INCLUDING the file extension. If we wanted to, say, give our <code>child_uic</code> the below file, we’d write the following:<br />
<code>local root = core:get_ui_root()<br />
local fake_uic = find_uicomponent(root, "fake_child", "this_isnt_real_cant_you_tell")<br />
<br />
local child_uic = UIComponent(fake_uic:CreateComponent("real_child", "ui/templates/round_small_button"))<br />
child_uic:SetImagePath("ui/skins/default/advisor_beastmen_2d.png")</code><br />
[[File:Ui button 01.png|none|thumb|160x160px|Isn't he handsome?]]<br />
You probably don’t want to use the above example. Find a pretty image to put on the button. Tip: find one with the prefix <code>icon_</code>, those are all typically made for effect icons/buttons.<br />
<br />
After that, let’s give it a tooltip. The method here is <code>uic:SetTooltipText(tooltip_text, true)</code>. For a quick example:<br />
<code>-- same code as above<br />
child_uic:SetTooltipText("I'm a very happy button", true)</code><br />
Again, I’m not gonna tell you how to live your life, be creative and do some stuff. I will give you one tip though: using the character <code>|</code> in this method allows you create a vanilla-like tooltip, that expands after hovering over the button for sometime. I recommend testing out that – as well as testing out some various loc tags. Test a UI tr, test UI tagged images, test colored text.<br />
<br />
And the last thing’s last – the ''actual usage''. (I just used the title of the movie in a scene, bonus points?)<br />
<br />
This part should remain relatively simple, though the actual nuts and bolts of usage will be left up to you. All we’re doing is establishing a listener for the button being clicked, and then we effect change.<br />
<code>-- same code as above pt.2<br />
core:add_listener(<br />
"MyButtonListener",<br />
"ComponentLClickUp",<br />
function(context)<br />
return child_uic == UIComponent(context.component)<br />
end,<br />
function(context)<br />
out("It Worked!")<br />
end,<br />
true<br />
)</code><br />
Every time the button is pressed, I would find a new line in my script log saying “It Worked!”. How quaint.<br />
<br />
I’ll take the time now to cover this. There are a few UIC listeners – we’ll probably cover most before long. All of them have the same two bits of data you can access – <code>context.component</code>, or <code>context.string</code>. The former can be used as in the listener to grab the UIC game object (I’m checking to see if the button pressed is the <code>child_uic</code> that we made above), while the latter can be used to check the ID of the UIC game object, quickly. In this instance, I could also write a conditional that looks like the following:<br />
<code>function(context)<br />
return context.string == "real_child"<br />
end,</code><br />
<br />
=== Your Turn ===<br />
At this point, you’re off to the wild. Attempt creating a brand new button, giving it a new image, giving it an expandable tooltip, and making the button do something when you press it. Keep the “thing it does” relatively simple – output text, pan the camera, move a character. Just make sure the thing it does isn’t anything UI related, just cause game change for now.<br />
<br />
Next up, we’re gonna get into a few more upgrades for our button – including giving that button varied tooltips and making it inactive, based on criteria!</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Shared_Unit_Caps&diff=727Tutorial:Shared Unit Caps2023-07-07T01:04:03Z<p>Not All is Dust: </p>
<hr />
<div>== Intro: ==<br />
This page is specifically on what shared unit caps are, how they are set up, what they are used for, and how they interact with normal unit caps.<br />
<br />
Shared unit caps where introduced with the Forge of the Chaos Dwarfs DLC. They make it so the player needs to choose between one unit when using caps. <br />
Example: Both the Infernal Guard and Infernal Guard (Great Weapons) share the same cap so after unlocking one additional cap the player must choose between recruiting one unit or the other.<br />
<br />
This mechanic allows for more diversity of units with different weapons without bloating a roster and still make the caps restrictive and not have undesirable available units.<br />
Example: The Beastmen have caps, but because they don't have shared caps, the way they are unlocked can either feel too restrictive or not enough. The three minotaur units cap has to be increased separately making them to restrictive and the three centigor units when increased are all increased by one making it likely there are undesirable centigors.<br />
<br />
== Tables Required: ==<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
#db/effects_tables<br />
#db/main_units_tables<br />
#db/unit_allowances_tables<br />
#db/unit_lists_tables<br />
#db/unit_to_unit_list_junctions_tables<br />
<br />
== Detailed Explanation: ==<br />
======db/unit_lists_tables======<br />
Create a unit list key, it is a unique key that will be used to represent all the units that will get the cap.<br />
<br />
======db/unit_to_unit_list_junctions_tables======<br />
Where you connect the or more than one main unit key to the unit list key.<br />
<br />
======db/unit_allowances_tables======<br />
This table has 3 fields:<br />
*'''Unit List''' is where the unit list key will be.<br />
*'''Point Cap''' the number that determines the starting cap amount, it can be "0".<br />
*'''Subculture''' serves to limit the capping of the unit to a specific subculture, if this field isn't filled all factions and cultures this unit is available will find that unit with a cap. <br />
<br />
======db/main_units_tables======<br />
In main units there are two relevant fields about shared unit caps:<br />
*'''Campaign Cap''' while normal caps have this field be "0" with shared caps this field must be "-1".<br />
*'''Point Allowance Weight''' this number determines how much does one unit weight in the cap. This is used for some of the chaos dwarf trains because they have two carriages but can be used for if you want the player to have to choose between having fewer higher tier units or lots of low tier units.<br />
<br />
======db/effects_tables======<br />
Interacting with the shared caps by adding or removing is done via effects. The most common way chaos dwarfs do this is by connecting the effect to a effect bundle and use scripting to change the cap of those units that bundle gives to the player. Because this uses effects it requires a localisation entry in a .loc file, usually the text is "Unit capacity: %+n\\nMinotaurs" with substituting minotaurs for the what represents all units in the cap.<br />
*'''Effect''' Create a effect key, it is a unique key that will be used to represent the process of adding and removing from the cap.<br />
*'''Icon''' and '''Icon Negative''' are usually "unit_capacity.png".<br />
*'''Priority''' is usually high 1 or 2 the lower the number the higher it will show up to the player when they look at the effect.<br />
*'''Category''' is "campaign".<br />
*'''Is Positive Value Good''' set to "true".<br />
<br />
======db/effect_bonus_value_unit_list_junctions_tables======<br />
This table connects the unit list key to the effect key. It has three fields:<br />
*'''Bonus Value Id''' is "unit_allowance_point_cap_mod".<br />
*'''Unit List''' is the unit list key. One Unit list can be referenced by several effects.<br />
*'''Effect''' is the effect key. One effect can have several unit lists.<br />
<br />
== Final Notes: ==<br />
Shared caps overwrite the normal caps. Tried to do shared caps for both types of tomb guard and it overwrites the caps of vanilla. A new effect is still needed to be given to the same building.</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Shared_Unit_Caps&diff=726Tutorial:Shared Unit Caps2023-07-07T00:58:55Z<p>Not All is Dust: </p>
<hr />
<div>== Intro: ==<br />
This page is specifically on what shared unit caps are, how they are set up, what they are used for, and how they interact with normal unit caps.<br />
<br />
Shared unit caps where introduced with the Forge of the Chaos Dwarfs DLC. They make it so the player needs to choose between one unit when using caps. <br />
Example: Both the Infernal Guard and Infernal Guard (Great Weapons) share the same cap so after unlocking one additional cap the player must choose between recruiting one unit or the other.<br />
<br />
This mechanic allows for more diversity of units with different weapons without bloating a roster and still make the caps restrictive and not have undesirable available units.<br />
Example: The Beastmen have caps, but because they don't have shared caps, the way they are unlocked can either feel too restrictive or not enough. The three minotaur units cap has to be increased separately making them to restrictive and the three centigor units when increased are all increased by one making it likely there are undesirable centigors.<br />
<br />
== Tables Required: ==<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
#db/effects_tables<br />
#db/main_units_tables<br />
#db/unit_allowances_tables<br />
#db/unit_lists_tables<br />
#db/unit_to_unit_list_junctions_tables<br />
<br />
== Detailed Explanation: ==<br />
======db/unit_lists_tables======<br />
Create a unit list key, it is a unique key that will be used to represent all the units that will get the cap<br />
<br />
======db/unit_to_unit_list_junctions_tables======<br />
Where you connect the or more than one main unit key to the unit list key.<br />
<br />
======db/unit_allowances_tables======<br />
This table has 3 fields<br />
*'''Unit List''' is where the unit list key will be.<br />
*'''Point Cap''' the number that determines the starting cap amount, it can be "0".<br />
*'''Subculture''' serves to limit the capping of the unit to a specific subculture, if this field isn't filled all factions and cultures this unit is available will find that unit with a cap. <br />
<br />
======db/main_units_tables======<br />
In main units there are two relevant fields about shared unit caps<br />
*'''Campaign Cap''' while normal caps have this field be "0" with shared caps this field must be "-1".<br />
*'''Point Allowance Weight''' this number determines how much does one unit weight in the cap. This is used for some of the chaos dwarf trains because they have two carriages but can be used for if you want the player to have to choose between having fewer higher tier units or lots of low tier units.<br />
<br />
======db/effects_tables======<br />
Interacting with the shared caps by adding or removing is done via effects. The most common way chaos dwarfs do this is by connecting the effect to a effect bundle and use scripting to change the cap of those units that bundle gives to the player. Because this uses effects it requires a localisation entry in a .loc file, usually the text is "Unit capacity: %+n\\nMinotaurs" with substituting minotaurs for the what represents all units in the cap.<br />
*'''Effect''' Create a effect key, it is a unique key that will be used to represent the process of adding and removing from the cap.<br />
*'''Icon''' and '''Icon Negative''' are usually "unit_capacity.png".<br />
*'''Priority''' is usually high 1 or 2 the lower the number the higher it will show up to the player when they look at the effect.<br />
*'''Category''' is "campaign".<br />
*'''Is Positive Value Good''' set to "true".<br />
<br />
======db/effect_bonus_value_unit_list_junctions_tables======<br />
This table connects the unit list key to the effect key. It has three fields<br />
*'''Bonus Value Id''' is "unit_allowance_point_cap_mod".<br />
*'''Unit List''' is the unit list key. One Unit list can be referenced by several effects.<br />
*'''Effect''' is the effect key. One effect can have several unit lists.<br />
<br />
== Final Notes: ==<br />
Shared caps overwrite the normal caps. Tried to do shared caps for both types of tomb guard and it overwrites the caps of vanilla. A new effect is still needed to be given to the same building.</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Shared_Unit_Caps&diff=725Tutorial:Shared Unit Caps2023-07-07T00:58:01Z<p>Not All is Dust: </p>
<hr />
<div>== Intro: ==<br />
This page is specifically on what shared unit caps are, how they are set up, what they are used for, and how they interact with normal unit caps.<br />
<br />
Shared unit caps where introduced with the Forge of the Chaos Dwarfs DLC. They make it so the player needs to choose between one unit when using caps. <br />
Example: Both the Infernal Guard and Infernal Guard (Great Weapons) share the same cap so after unlocking one additional cap the player must choose between recruiting one unit or the other.<br />
<br />
This mechanic allows for more diversity of units with different weapons without bloating a roster and still make the caps restrictive and not have undesirable available units.<br />
Example: The Beastmen have caps, but because they don't have shared caps, the way they are unlocked can either feel too restrictive or not enough. The three minotaur units cap has to be increased separately making them to restrictive and the three centigor units when increased are all increased by one making it likely there are undesirable centigors.<br />
<br />
== Tables Required: ==<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
#db/effects_tables<br />
#db/main_units_tables<br />
#db/unit_allowances_tables<br />
#db/unit_lists_tables<br />
#db/unit_to_unit_list_junctions_tables<br />
<br />
== Detailed Explanation: ==<br />
======db/unit_lists_tables======<br />
Create a unit list key, it is a unique key that will be used to represent all the units that will get the cap<br />
<br />
======db/unit_to_unit_list_junctions_tables======<br />
Where you connect the or more than one main unit key to the unit list key.<br />
<br />
======db/unit_allowances_tables======<br />
This table has 3 fields<br />
#*'''Unit List''' is where the unit list key will be.<br />
#*'''Point Cap''' the number that determines the starting cap amount, it can be "0".<br />
#*'''Subculture''' serves to limit the capping of the unit to a specific subculture, if this field isn't filled all factions and cultures this unit is available will find that unit with a cap. <br />
<br />
======db/main_units_tables======<br />
In main units there are two relevant fields about shared unit caps<br />
#*'''Campaign Cap''' while normal caps have this field be "0" with shared caps this field must be "-1".<br />
#*'''Point Allowance Weight''' this number determines how much does one unit weight in the cap. This is used for some of the chaos dwarf trains because they have two carriages but can be used for if you want the player to have to choose between having fewer higher tier units or lots of low tier units.<br />
<br />
======db/effects_tables======<br />
Interacting with the shared caps by adding or removing is done via effects. The most common way chaos dwarfs do this is by connecting the effect to a effect bundle and use scripting to change the cap of those units that bundle gives to the player. Because this uses effects it requires a localisation entry in a .loc file, usually the text is "Unit capacity: %+n\\nMinotaurs" with substituting minotaurs for the what represents all units in the cap.<br />
#*'''Effect''' Create a effect key, it is a unique key that will be used to represent the process of adding and removing from the cap.<br />
#*'''Icon''' and '''Icon Negative''' are usually "unit_capacity.png".<br />
#*'''Priority''' is usually high 1 or 2 the lower the number the higher it will show up to the player when they look at the effect.<br />
#*'''Category''' is "campaign".<br />
#*'''Is Positive Value Good''' set to "true".<br />
<br />
======db/effect_bonus_value_unit_list_junctions_tables======<br />
This table connects the unit list key to the effect key. It has three fields<br />
#*'''Bonus Value Id''' is "unit_allowance_point_cap_mod".<br />
#*'''Unit List''' is the unit list key. One Unit list can be referenced by several effects.<br />
#*'''Effect''' is the effect key. One effect can have several unit lists.<br />
<br />
== Final Notes: ==<br />
Shared caps overwrite the normal caps. Tried to do shared caps for both types of tomb guard and it overwrites the caps of vanilla. A new effect is still needed to be given to the same building.</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Shared_Unit_Caps&diff=723Tutorial:Shared Unit Caps2023-07-07T00:57:01Z<p>Not All is Dust: </p>
<hr />
<div>== Intro: ==<br />
This page is specifically on what shared unit caps are, how they are set up, what they are used for, and how they interact with normal unit caps.<br />
<br />
Shared unit caps where introduced with the Forge of the Chaos Dwarfs DLC. They make it so the player needs to choose between one unit when using caps. <br />
Example: Both the Infernal Guard and Infernal Guard (Great Weapons) share the same cap so after unlocking one additional cap the player must choose between recruiting one unit or the other.<br />
<br />
This mechanic allows for more diversity of units with different weapons without bloating a roster and still make the caps restrictive and not have undesirable available units.<br />
Example: The Beastmen have caps, but because they don't have shared caps, the way they are unlocked can either feel too restrictive or not enough. The three minotaur units cap has to be increased separately making them to restrictive and the three centigor units when increased are all increased by one making it likely there are undesirable centigors.<br />
<br />
== Tables Required: ==<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
#db/effects_tables<br />
#db/main_units_tables<br />
#db/unit_allowances_tables<br />
#db/unit_lists_tables<br />
#db/unit_to_unit_list_junctions_tables<br />
<br />
== Detailed Explanation: ==<br />
======db/unit_lists_tables======<br />
Create a unit list key, it is a unique key that will be used to represent all the units that will get the cap<br />
<br />
#db/unit_to_unit_list_junctions_tables<br />
Where you connect the or more than one main unit key to the unit list key.<br />
<br />
#db/unit_allowances_tables<br />
This table has 3 fields<br />
#*'''Unit List''' is where the unit list key will be.<br />
#*'''Point Cap''' the number that determines the starting cap amount, it can be "0".<br />
#*'''Subculture''' serves to limit the capping of the unit to a specific subculture, if this field isn't filled all factions and cultures this unit is available will find that unit with a cap. <br />
<br />
#db/main_units_tables<br />
In main units there are two relevant fields about shared unit caps<br />
#*'''Campaign Cap''' while normal caps have this field be "0" with shared caps this field must be "-1".<br />
#*'''Point Allowance Weight''' this number determines how much does one unit weight in the cap. This is used for some of the chaos dwarf trains because they have two carriages but can be used for if you want the player to have to choose between having fewer higher tier units or lots of low tier units.<br />
<br />
#db/effects_tables<br />
Interacting with the shared caps by adding or removing is done via effects. The most common way chaos dwarfs do this is by connecting the effect to a effect bundle and use scripting to change the cap of those units that bundle gives to the player. Because this uses effects it requires a localisation entry in a .loc file, usually the text is "Unit capacity: %+n\\nMinotaurs" with substituting minotaurs for the what represents all units in the cap.<br />
##'''Effect''' Create a effect key, it is a unique key that will be used to represent the process of adding and removing from the cap.<br />
##'''Icon''' and '''Icon Negative''' are usually "unit_capacity.png".<br />
##'''Priority''' is usually high 1 or 2 the lower the number the higher it will show up to the player when they look at the effect.<br />
##'''Category''' is "campaign".<br />
##'''Is Positive Value Good''' set to "true".<br />
<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
This table connects the unit list key to the effect key. It has three fields<br />
##'''Bonus Value Id''' is "unit_allowance_point_cap_mod".<br />
##'''Unit List''' is the unit list key. One Unit list can be referenced by several effects.<br />
##'''Effect''' is the effect key. One effect can have several unit lists.<br />
<br />
== Final Notes: ==<br />
Shared caps overwrite the normal caps. Tried to do shared caps for both types of tomb guard and it overwrites the caps of vanilla. A new effect is still needed to be given to the same building.</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Shared_Unit_Caps&diff=722Tutorial:Shared Unit Caps2023-07-07T00:56:17Z<p>Not All is Dust: Explanation on Shared unit caps introduced with the Chaos Dwarfs.</p>
<hr />
<div>== Intro: ==<br />
This page is specifically on what shared unit caps are, how they are set up, what they are used for, and how they interact with normal unit caps.<br />
<br />
Shared unit caps where introduced with the Forge of the Chaos Dwarfs DLC. They make it so the player needs to choose between one unit when using caps. <br />
Example: Both the Infernal Guard and Infernal Guard (Great Weapons) share the same cap so after unlocking one additional cap the player must choose between recruiting one unit or the other.<br />
<br />
This mechanic allows for more diversity of units with different weapons without bloating a roster and still make the caps restrictive and not have undesirable available units.<br />
Example: The Beastmen have caps, but because they don't have shared caps, the way they are unlocked can either feel too restrictive or not enough. The three minotaur units cap has to be increased separately making them to restrictive and the three centigor units when increased are all increased by one making it likely there are undesirable centigors.<br />
<br />
== Tables Required: ==<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
#db/effects_tables<br />
#db/main_units_tables<br />
#db/unit_allowances_tables<br />
#db/unit_lists_tables<br />
#db/unit_to_unit_list_junctions_tables<br />
<br />
== Detailed Explanation: ==<br />
#db/unit_lists_tables<br />
Create a unit list key, it is a unique key that will be used to represent all the units that will get the cap<br />
<br />
#db/unit_to_unit_list_junctions_tables<br />
Where you connect the or more than one main unit key to the unit list key.<br />
<br />
#db/unit_allowances_tables<br />
This table has 3 fields<br />
#*'''Unit List''' is where the unit list key will be.<br />
#*'''Point Cap''' the number that determines the starting cap amount, it can be "0".<br />
#*'''Subculture''' serves to limit the capping of the unit to a specific subculture, if this field isn't filled all factions and cultures this unit is available will find that unit with a cap. <br />
<br />
#db/main_units_tables<br />
In main units there are two relevant fields about shared unit caps<br />
#*'''Campaign Cap''' while normal caps have this field be "0" with shared caps this field must be "-1".<br />
#*'''Point Allowance Weight''' this number determines how much does one unit weight in the cap. This is used for some of the chaos dwarf trains because they have two carriages but can be used for if you want the player to have to choose between having fewer higher tier units or lots of low tier units.<br />
<br />
#db/effects_tables<br />
Interacting with the shared caps by adding or removing is done via effects. The most common way chaos dwarfs do this is by connecting the effect to a effect bundle and use scripting to change the cap of those units that bundle gives to the player. Because this uses effects it requires a localisation entry in a .loc file, usually the text is "Unit capacity: %+n\\nMinotaurs" with substituting minotaurs for the what represents all units in the cap.<br />
##'''Effect''' Create a effect key, it is a unique key that will be used to represent the process of adding and removing from the cap.<br />
##'''Icon''' and '''Icon Negative''' are usually "unit_capacity.png".<br />
##'''Priority''' is usually high 1 or 2 the lower the number the higher it will show up to the player when they look at the effect.<br />
##'''Category''' is "campaign".<br />
##'''Is Positive Value Good''' set to "true".<br />
<br />
#db/effect_bonus_value_unit_list_junctions_tables<br />
This table connects the unit list key to the effect key. It has three fields<br />
##'''Bonus Value Id''' is "unit_allowance_point_cap_mod".<br />
##'''Unit List''' is the unit list key. One Unit list can be referenced by several effects.<br />
##'''Effect''' is the effect key. One effect can have several unit lists.<br />
<br />
== Final Notes: ==<br />
Shared caps overwrite the normal caps. Tried to do shared caps for both types of tomb guard and it overwrites the caps of vanilla. A new effect is still needed to be given to the same building.</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Map_Making_for_WH3&diff=577Tutorial:Map Making for WH32023-03-03T15:33:52Z<p>Not All is Dust: </p>
<hr />
<div>=====Originally written by WakaWaka300 and posted by All is Dust=====<br />
<br />
===Map Making in WH3===<br />
CA said that and I quote "Terry is going to feel quite different. It's the full-fat version of the tools that we use in house. This should give you more power, but will also be more complicated with initial set ups."<br />
<br />
So thankfully WakaWaka300 gave us some tutorials. You can fidn the original tutorials and extra files like examples and templates [https://drive.google.com/drive/folders/1HfSee67Xq9VG67O39v7vt2fE7CgwNfDD HERE].<br />
<br />
The tutorials in question are:<br />
<br />
==WH3 Map Optimisation Guide==<br />
<br />
===File Size Optimization===<br />
As we continue to make more and more maps, I think one thing that will be critically important going forward is to manage file size. Looking at the file sizes of the working_data files that are generated by Terry, it quickly becomes apparent that the largest contributor to map file size is various procedural generation data. This consists of the trees, grass, pebbles, etc that are generated depending on the texture channel being used in a particular area. See below for an example of the file sizes present in my map “Road to Vaul’s Anvil”; files related to procedurally generated objects are highlighted.<br />
<br />
[[File:file5.png|thumb|link=Special:FilePath/File5.png]]<br />
<br />
One thing that jumps out is that grass in particular takes up a lot of space because each grass blade’s position, rotation, etc are stored individually instead of being generated at the start of each battle. At the same time, I noticed that CA omits grass generation outside of the playable area in many of their maps (see Arnheim below as an example where the grass stops generating shortly beyond the white line)<br />
<br />
[[File:battle4.png|thumb|link=Special:FilePath/Battle4.png]]<br />
<br />
From what I can tell, there is also an automatic system that deletes any small procedural objects, such as grass, from tiles in the outfield (outside the playable tile). However, for the space in between the playable area (white lines), and the outfield tiles, the grass here has to be removed manually. Don’t worry though, the process really isn’t that hard!<br />
<br />
To illustrate this process, I have made an example map:<br />
<br />
[[File:green3.png|thumb|link=Special:FilePath/Green3.png]]<br />
<br />
First, CA already has a pretty nifty tool for deleting any procedural objects in the form of procedural exclusion zones. These can be accessed via “entity creation > visual”. So just put them in such a way as to cover the whole tile area between the white lines and tile edge. It’s ok if you have multiple zones overlap. So here is an example of that:<br />
<br />
[[File:green2.png|thumb|link=Special:FilePath/Green2.png]]<br />
<br />
As you can see, while it has done a good job of deleting all the extra grass, it has also deleted the trees in the various forests outside the playable area. Those are procedural trees after all! In order to fix this, we need to recreate those forests using the vegetation paint tool rather than allowing them to be procedurally generated using the forest terrain type.<br />
<br />
To assist with this, it may be easier to temporarily change the forest01 texture channel to something like white or snow to make it easier to see. But that’s up to you obviously. Next, you have to set up a list of trees to make the painted forest blend in with the normal one. You will probably have to fool around with this for while to make it look right.<br />
See below for example of painted trees.<br />
<br />
[[File:green1.png|thumb|link=Special:FilePath/Green1.png]]<br />
<br />
Afterwards, I simply change the texture type back to forest01 to get the trees in the middle back.<br />
<br />
[[File:green.png|thumb|link=Special:FilePath/Green.png]]<br />
<br />
===FPS Optimization===<br />
So I suppose there isn’t really much to say here. CA’s engine can indeed handle a lot of objects at once, so you don’t really have to worry about that. What will really bog the game down is putting in lots of VFX, especially transparency effects. Why does this cause issues? Because of overdraw.<br />
<br />
[[File:Optimization.png|thumb|link=Special:FilePath/Optimization.png]]<br />
<br />
Overdraw (visualised here in red) is when the game engine gets bogged by essentially redrawing the same pixel multiple times due to transparency overlap. As a result, you can definitely use fog effects if you want to, but don’t spam them close together, and try not to scale them up in such a way that you could see one through another<br />
<br />
In case you’re wondering, this is (probably) why the cathay maps perform so badly in the base game.<br />
<br />
<br />
==WH3 Domination Map Making Guide==<br />
<br />
===INITIAL FILE SETUP===<br />
When you first open Terry, you will be greeted by the following screen:<br />
<br />
[[File:dmmg_1.png|thumb|link=Special:FilePath/dmmg_1.png]]<br />
<br />
Lets get some terminology straight first:<br />
1. A “tile” is a section of terrain (of any size) that can be loaded as the playable map or as part of the outfield or vista<br />
2. A “tile map” is the outfield (background outside the playable area) that gets loaded in game whenever you boot up a map. As the name implies, a tile map is an arrangement of multiple tiles.<br />
3. A “prefab” is a collection of objects that can be loaded in and selected as one entity. It’s useful for making maps quickly as you will likely find with the CA-made prefabs. This guide will not touch on prefabs<br />
<br />
As of the initial writing of this guide, we don’t have any tile maps made by the community (or by CA) for use in WH3, but we do have all the WH2 tile maps (and most of them seem to work!). As such, I have uploaded them here for use in your maps.<br />
<br />
For the best compatibility with the existing WH2 tile maps, you should use 8x8 as your tile size. This “size” refers to the grid size of the green squares when you load up your tile.<br />
<br />
For climate, this controls the texture set used for your tile, and it should be pretty self-explanatory. This does not control the environment (lighting and atmospherics)<br />
<br />
The first time, save your map using “save as…”, which will pull up a dialog asking you to save a tile set and name. The name is not the display name for the map, and for the tile set you use, please save it as domination. Be sure to leave the box checked at the bottom.<br />
<br />
[[File:dmmg_2.png|thumb|link=Special:FilePath/dmmg_2.png]]<br />
<br />
If you are importing a WH2 map, you need to change “ProjectTilewithVista” in the .terry file to “ProjectTile” by opening the file with notepad and changing it manually. In addition, when you load the map in, you will likely be greeted by a red hellscape. To get rid of this, you have to load a new environment file in “settings” at the bottom right.<br />
<br />
Whenever you reload a map, you may often be greeted by overly dark shadows. To fix this, regenerate light probes in settings (shown below).<br />
<br />
Insert the provided terry_buildings file into WH3’s data directory to add additional buildings into terry for your use.<br />
<br />
Finally, you should refrain from putting anything in your map below y=0 due to a water heights issue. If you do have stuff below y=0, then you will have to raise the tile map until no terrain is below y=0 in order to prevent floating unit icons.<br />
<br />
[[File:dmmg_3.png|thumb|link=Special:FilePath/dmmg_3.png]]<br />
<br />
===SETTING UP INITIAL DEPLOYMENT<br />
So we’ve skipped ahead a little since the act of texturing, placing objects, adjusting the height map, etc hasn’t changed much from previous iterations of terry and is very intuitive. This section will basically cover how to set up deployment zones. However, as best practice, you should also set up no-go zones around any impassable terrain and check the size of your map as you make it with the prop “ref_group_human”.<br />
<br />
For deployment zones, go to tools > entity creation (logical), and create one on each side. Next, go to the object tree on the left and click on each zone. In each, you will find an additive deployment zone region. This is the zone players will deploy in to start the game. Next change one of the zones to alliance ID 1 and it will turn red. Remember that blue is attackers and red is defenders (very intuitive, I know).<br />
<br />
With your initial deployment zones made, create another deployment zone region with tools > entity creation (logical). The option is only accessible if you have selected the corresponding deployment zone you want it to be associated with. This deployment zone region will be for vanguard deployment and will use the zone type “guerilla exclusion additive”.<br />
<br />
Basically, the way guerilla exclusion additive zones work in Terry is that it prevents the opposite alliance from deploying in that zone. In other words, the opposite team can vanguard deploy everywhere except for the enemy alliance’s guerilla exclusion zone. See below for an example of how my zones are set up. I have drawn over the zones to make them easier to see.<br />
<br />
[[File:dmmg_4.png|thumb|link=Special:FilePath/dmmg_4.png]]<br />
<br />
[[File:dmmg_5.png|thumb|link=Special:FilePath/dmmg_5.png]]<br />
<br />
As you can see, there will be some overlap between guerilla exclusion zones in the middle. As a final note, you must ensure that players cannot vanguard deploy onto the domination points since that would allow them to capture them before the match starts.<br />
<br />
Finally, you can make a playable area using tools > entity creation (logical). This defines what space in the tile that players can actually move around in (aka, the “white lines”). I think it should be between 2x2 and 3x3 or so, but it’s highly variable depending on how big or what shape you want the map to be. <br />
<br />
===SECTION 3: SETTING UP DOMINATION CAPTURE POINTS===<br />
To make capture points, go to tools > entity creation (logical) and create a capture point. You can make the point any shape, but I will use the rectangular shape as a reference. For type, use domination 1, 2, or 3 depending on which point you are making. For importance, you must use “score”. For size, I think anywhere between 80x80 to 180x180 can work depending on the map. See below for reference.<br />
<br />
[[File:dmmg_5_1.png|thumb|link=Special:FilePath/dmmg_5_1.png]]<br />
<br />
===SETTING UP TELEPORT POINTS===<br />
To make the points used to spawn units in, go to tools > entity creation (logical), and create an ai hint. Use the type “attacker (or defender) teleport reinforcement line” and create a single, short line with two points. Remember, attacker is the blue side and defender is the red side.<br />
<br />
The vanguard deployment lines are exactly the same, but make sure to check the box for vanguard deployment in the entity properties. See below as an example for one of the vanguard points.<br />
<br />
If you have issues with the teleport point not appearing in game, it is likely due to the line being too short. If it’s about 20 units long, that’s enough.<br />
<br />
[[File:dmmg_6.png|thumb|link=Special:FilePath/dmmg_6.png]]<br />
<br />
===SETTING UP THE TILE MAP===<br />
At this point, you have to understand two different file locations where map files are stored. In your assembly kit folder (located within WH3 wherever you have that stored), you will find two folders, raw_data and working_data. Raw data is the files that the modding tools will work with to make maps, while working data is the stuff that the mod tools export which you will need to compile to make the final map file. Everything we need will be located within the terrain folders of each.<br />
<br />
When you are more-or-less done with the map, go to “tools > create battle for tile…”. This will create a tile map file associated with this map in raw_data>terrain>battles>yourmap. You will only need to do this once. This has generated a tile map for your tile, but we need to change it because the climate isn’t set up and there’s no outfield.<br />
<br />
This is where you either create your own tile map or use one of the WH2 ones (I would suggest the latter for now). Use the vistas I have provided with this guide to pull the tile_map.png and climate_map.png files from whatever vista you want into the tile map folder that was generated. The tile map tells the game which tiles from the tile db to generate in the outfield, and the climate map tells the game which textures to use. Climate map colors are located in the settings file of terrain>tiles>battle>_tile_database. Tile map colors and sizes are located in the tile database found in terry. See below for an example of the files needed in the tile map folder. The extra terry user file is only generated when you open the tile map in Terry.<br />
<br />
[[File:dmmg_7.png|thumb|link=Special:FilePath/dmmg_7.png]]<br />
<br />
Next, you need to modify the explicit_tiles file to tell the game where the playable tile is located within the tile map. By default, it will probably be something like this:<br />
<br />
3,3,terrain/tiles/battle/lzd_hills_infield/chaqua_pit,0<br />
<br />
If you are using an 8x8 tile and one of the WH2 tile maps, your map will line up with the 8x8 black square in the middle. Open the tile map in a program like [https://www.gimp.org/ GIMP] to view the coordinates of the upper left corner of the black square. Change the first two numbers of the explicit_tiles file to these coordinates. See below for an example of the 28,28 coordinates for a 64x64 tile map.<br />
<br />
[[File:dmmg_8.png|thumb|link=Special:FilePath/dmmg_8.png]]<br />
<br />
Once you’re done with this open up the .terry file (the tile map) in Terry itself. This will initially load a tile map that is too small and isn’t using the right climate, but don’t panic! Changes to the tile map file will only show up in the editor once you have exported it, so do that now using file > process with BOB. To see if the tile map looks right, reload the tile map in Terry after you have exported it.<br />
<br />
===EXPORTING THE TILE===<br />
Always export the tile AFTER exporting the tile map. Do this by using file > process with BOB. If you make changes to your tile, you only need to re-export the tile, not the tile map. As stated before, you never need to do “tools > create battle for tile…” more than once.<br />
<br />
Before you export, also ensure that legacy vegetation generation is turned off the in the map properties (bottom right)<br />
<br />
===COMPILING THE MAP IN RPFM===<br />
Total war uses pack files to load mods into the user’s game. To make your pack file, you could use CA’s pack file manager, but most people think that the community-made [https://github.com/Frodo45127/rpfm/releases RPFM] is superior for this process. This tutorial will exclusively use RPFM.<br />
<br />
As an example for how this is set up, please download [https://steamcommunity.com/sharedfiles/filedetails/?id=2861441854 my map pack] and go to steamapps > workshop > content and then find the folder for WH3, then find my mod in that folder. There, you will find my mod’s pack file, which you can open in RPFM to see how to set this up.<br />
<br />
I will not describe in detail exactly how to use RPFM to do everything here, but I invite you to go to the modder’s den discord to ask questions about how the program works. Here is generally how a compiled map pack (with multiple maps) will look:<br />
<br />
[[File:dmmg_9.png|thumb|link=Special:FilePath/dmmg_9.png]]<br />
<br />
There are 4 main components:<br />
1. First add the map files by adding the entire working_data > terrain folder. Then delete the files for the assembly kit example map.<br />
2. Add a text db then add a line with “battles_localised_name_[map key]” followed by the display name. Tooltip is good.<br />
3. Add the folders for battle map images and add all of the in-game images that will display in the map selection screen. These images should be 3 times as wide as they are tall.<br />
4. Add a db with the battles_tables table. Most of it should be easy enough. For specification, use “copy path” to get the terrain > battles > yourmap folder for your map. You do need the extra slash at the end. Get the path for the environment file from the game files in the bottom left; it’s in the weathers folder.<br />
<br />
Finally, save your pack in WH3’s data folder located in the game’s base directory. Make a cover image to display in the workshop; it should be square, compressed, and should have the same name as the pack file.<br />
<br />
To assist in testing, you can use [https://steamcommunity.com/sharedfiles/filedetails/?id=2860443397 this] mod made by Klissan, which will allow you to load into domination maps without another player.<br />
<br />
GOOD LUCK, YOU’RE GONNA NEED IT<br />
<br />
<br />
==WH3 Map Making Beautification Guide==<br />
[https://docs.google.com/presentation/d/1f8SPKHqGtLz5jOZo-qoJshu_SP8gJ242UdOjbJBHrus/edit#slide=id.g1af5a2e59f5_0_50 powerpoint on beutification]<br />
<br />
==WH3 Battle Map Capture Points Guide==<br />
<br />
===INTRO===<br />
With the latest release of the Total Tavern map pack (Nov 2, 2022), we now have a rudimentary ability to add additional capturable objectives to domination maps other than the 3 main objectives. In particular, we are able to add points that give supplies as well as generic points that can be used for as a logical link to other capturable objectives.<br />
<br />
Assuming you already know how to make capture points, let’s look at all of the different parameters in a capture point:<br />
<br />
[[File:CP_1.png|thumb|link=Special:FilePath/CP_1.png]]<br />
<br />
The most important parameters are the type and the importance. The type controls the symbol given to the capture point on the UI as well as the tooltip that appears when you mouse over it. The importance controls how many tickets the capture points gives, what currencies the points gives, and the time it takes to capture it.<br />
<br />
As you can imagine, the importance of the capture point is its chief parameter. Unfortunately, due to database limitations, we cannot add new levels of importance for capture points, but we can add new capture point types. Therefore, when thinking about how to add different types of capture points, we can only work with 4 different levels of importance: Key Building A, Key Building, B, Major and Minor (these 4 were otherwise unused in domination).<br />
<br />
<br />
===HOW TO ADD SUPPLY POINTS===<br />
The biggest functionality that this map pack update provides is the ability to create points that generate supplies. This functionality is mainly controlled by the db/battle_secondary_currency_sources_links_tables (see pic below).<br />
<br />
[[File:CP_2.png|thumb|link=Special:FilePath/CP_2.png]]<br />
<br />
As you can see, each entry defines how a certain number of supplies are doled out as long as the “source type” condition is met. For example, for line 3, the game will give 3 supplies/second to a player as long as they control a major victory point, regardless of how many major victory points they control. Because of that, if you wanted to make two capture points in a map that each gave 1 supply/second, you would have to have them on two separate importance levels.<br />
<br />
As a result, this is how the importance levels shook out when I designed this mod:<br />
● Score - This was not changed at all since this is reserved for the domination points themselves<br />
● Minor - This will give neither supplies nor tickets. It is intended to be a point type used for side objectives like capturable towers or reinforcement points<br />
● Key Building A and B - I wanted the ability to make maps with two points that each give 1 supply/second, so both of these are reserved for that purpose<br />
● Major - Gives 3 supplies/second<br />
<br />
To communicate this to the player, I created 3 new capture point types. The picture below shows the .loc that generates the tooltips so you can see what they say:<br />
<br />
[[File:CP_3.png|thumb|link=Special:FilePath/CP_3.png]]<br />
<br />
Therefore, there are a limited number of available configurations for supply points, and certain point types should only be used with certain point importances. To sum up, these are the only available configurations of supply points you can use on your maps:<br />
<br />
Option A:<br />
1. Supply point 1 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply Point 2 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building B (generates 1 sup/sec)<br />
Option B:<br />
1. Supply Point 1 of 1<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
Option C:<br />
1. Supply point 1 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply Point 2 of 2<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
Option D:<br />
1. Supply point 1 of 3<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply point 2 of 3<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building B (generates 1 sup/sec)<br />
3. Supply Point 3 of 3<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
<br />
===HOW TO ADD REINFORCEMENT CAPTURE POINTS===<br />
Tower capture points are fairly self-explanatory in the sense that you can just add the required tower prefab and then link it to the CA-provided tower_only capture point zone. However, reinforcement zone capture points didn’t seem to be something that CA planned for, so it required the addition of another capture point zone type to communicate this functionality to the player.<br />
<br />
To be clear, when I’m talking about reinforcement zone capture points, I’m talking about stuff like my map, Crater of Decay, where you have an additional objective that, when captured, unlocks neutral zones where you can spawn units from.<br />
<br />
[[File:CP_4.png|thumb|link=Special:FilePath/CP_4.png]]<br />
<br />
Minor importance was reserved for this purpose since it will not give any supplies. As a result, all reinforcement zone capture points should look like this:<br />
<br />
[[File:CP_5.png|thumb|link=Special:FilePath/CP_5.png]]<br />
<br />
Of course, reinforcement capture points also require the extra step of linking them to the points they give control over. To do this, simply go to the entity properties of those reinforcement points, and select the tt_dom_reinf_zone_point from the capture location drop-down menu. See example below for a capturable vanguard point.<br />
<br />
[[File:CP_6.png|thumb|link=Special:FilePath/CP_6.png]]<br />
<br />
One important thing to note is that despite the fact that the reinforcement spawn points are now capturable, they aren’t “neutral” in the sense that they are still linked to attacker and defender. For example, if the attacker captures the tt_dom_reinf_zone_point, they will not gain control of this defender teleport reinforcement line. Only the defender can do that and vice versa.<br />
<br />
===REQUIRED FILES AND HOW TO TEST===<br />
Since modifications were made to the game to make all this stuff work, you will need to put these changes into your mod to do any testing. To facilitate this, I have created two pack files:<br />
[https://drive.google.com/file/d/1hA_psc5m5fAEYKqzyaQPyuhui8POl71O/view?usp=share_link link]<br />
[https://drive.google.com/file/d/1MFGgsxw9rFP2bVBWEjkbIOS4d78l0NVt/view?usp=share_link link]<br />
<br />
<br />
The first link is a pack file that you should put in your game’s data folder. All this does is it adds the new capture point types as table entries so that you can select them when making maps.<br />
<br />
The second pack file is something that you should merge into your map mod’s pack file to get all of the other database changes that affect gameplay. To do this, right click the root of your pack file in RPFM and go to add > from pack file. Then navigate to the file from the second download link that says “merge me”.<br />
<br />
[[File:CP_7.png|thumb|link=Special:FilePath/CP_7.png]]<br />
<br />
After that, just double click the root of the other pack file, and it will bring everything in.<br />
<br />
<br />
==How to Make Land Battle versions of Domination maps==<br />
This will use the catchment system so that you don’t have to make multiple copies of the same map.<br />
<br />
First, put everything related specifically to the domination game mode into a file layer or logical layer. The difference between the two is that file layer saves the selection to a different layer file whereas logical layer will save it as a selection within the same layer file. Either will work.<br />
<br />
Next, change the BMD export type of the layer to catchment_01 (or whichever you want to use).<br />
<br />
Example:<br />
<br />
[[File:lb_to_d_1.png|thumb|link=Special:FilePath/Lb_to_d_1.png]]<br />
<br />
Then export the tile and add it to your pack file as you normally would; exporting the tile map is not required if you have already done so before.<br />
<br />
In battles_tables in RPFM, you will have to make two separate rows for your map. I have copied the relevant columns from the two entries in my pack so you can see how it should be.<br />
<br />
KEY de_labor_camp_dom de_labor_camp_lb<br />
TYPE domination classic<br />
SPECIFICATION terrain/battles/test_domination_de_labor_camp/ terrain/battles/test_domination_de_labor_camp/ <br />
SCREENSHOT PATH ui/frontend ui/battle_map_images/bleakspire_wide.png ui/frontend ui/battle_map_images/bleakspire_wide.png <br />
CATCHMENT NAME catchment_01<br />
<br />
So basically, everything stays the same except you change the battle type, append something to the key to make it easy to recognize which is which (I chose “_dom” and “_lb”), and then load the appropriate catchment layer for dom.<br />
<br />
Once you’ve done that, you also need to update the text loc file which generates the display names since there are now two different keys.<br />
<br />
In this case, all I did was isolate the domination-specific features. However, this system is quite flexible. For example, you could have different initial deployment zones and white lines on the domination version of the map than the land battle version by having one set be on catchment_01 and the other on catchment_02.<br />
<br />
[[Category:Warhammer 3]]</div>Not All is Dusthttps://tw-modding.com/index.php?title=Tutorial:Map_Making_for_WH3&diff=569Tutorial:Map Making for WH32023-02-24T01:19:20Z<p>Not All is Dust: Created page with "=====Originally written by WakaWaka300 and posted by All is Dust===== ===Map Making in WH3 ==== CA said that and I quote "Terry is going to feel quite different. It's the ful..."</p>
<hr />
<div>=====Originally written by WakaWaka300 and posted by All is Dust=====<br />
<br />
===Map Making in WH3 ====<br />
CA said that and I quote "Terry is going to feel quite different. It's the full-fat version of the tools that we use in house. This should give you more power, but will also be more complicated with initial set ups."<br />
<br />
So thankfully WakaWaka300 gave us some tutorials. You can fidn the original tutorials and extra files like examples and templates [https://drive.google.com/drive/folders/1HfSee67Xq9VG67O39v7vt2fE7CgwNfDD HERE].<br />
<br />
The tutorials in question are:<br />
<br />
==WH3 Map Optimisation Guide==<br />
<br />
===File Size Optimization===<br />
As we continue to make more and more maps, I think one thing that will be critically important going forward is to manage file size. Looking at the file sizes of the working_data files that are generated by Terry, it quickly becomes apparent that the largest contributor to map file size is various procedural generation data. This consists of the trees, grass, pebbles, etc that are generated depending on the texture channel being used in a particular area. See below for an example of the file sizes present in my map “Road to Vaul’s Anvil”; files related to procedurally generated objects are highlighted.<br />
<br />
[[File:file5.png|thumb|link=Special:FilePath/File5.png]]<br />
<br />
One thing that jumps out is that grass in particular takes up a lot of space because each grass blade’s position, rotation, etc are stored individually instead of being generated at the start of each battle. At the same time, I noticed that CA omits grass generation outside of the playable area in many of their maps (see Arnheim below as an example where the grass stops generating shortly beyond the white line)<br />
<br />
[[File:battle4.png|thumb|link=Special:FilePath/Battle4.png]]<br />
<br />
From what I can tell, there is also an automatic system that deletes any small procedural objects, such as grass, from tiles in the outfield (outside the playable tile). However, for the space in between the playable area (white lines), and the outfield tiles, the grass here has to be removed manually. Don’t worry though, the process really isn’t that hard!<br />
<br />
To illustrate this process, I have made an example map:<br />
<br />
[[File:green3.png|thumb|link=Special:FilePath/Green3.png]]<br />
<br />
First, CA already has a pretty nifty tool for deleting any procedural objects in the form of procedural exclusion zones. These can be accessed via “entity creation > visual”. So just put them in such a way as to cover the whole tile area between the white lines and tile edge. It’s ok if you have multiple zones overlap. So here is an example of that:<br />
<br />
[[File:green2.png|thumb|link=Special:FilePath/Green2.png]]<br />
<br />
As you can see, while it has done a good job of deleting all the extra grass, it has also deleted the trees in the various forests outside the playable area. Those are procedural trees after all! In order to fix this, we need to recreate those forests using the vegetation paint tool rather than allowing them to be procedurally generated using the forest terrain type.<br />
<br />
To assist with this, it may be easier to temporarily change the forest01 texture channel to something like white or snow to make it easier to see. But that’s up to you obviously. Next, you have to set up a list of trees to make the painted forest blend in with the normal one. You will probably have to fool around with this for while to make it look right.<br />
See below for example of painted trees.<br />
<br />
[[File:green1.png|thumb|link=Special:FilePath/Green1.png]]<br />
<br />
Afterwards, I simply change the texture type back to forest01 to get the trees in the middle back.<br />
<br />
[[File:green.png|thumb|link=Special:FilePath/Green.png]]<br />
<br />
===FPS Optimization===<br />
So I suppose there isn’t really much to say here. CA’s engine can indeed handle a lot of objects at once, so you don’t really have to worry about that. What will really bog the game down is putting in lots of VFX, especially transparency effects. Why does this cause issues? Because of overdraw.<br />
<br />
[[File:Optimization.png|thumb|link=Special:FilePath/Optimization.png]]<br />
<br />
Overdraw (visualised here in red) is when the game engine gets bogged by essentially redrawing the same pixel multiple times due to transparency overlap. As a result, you can definitely use fog effects if you want to, but don’t spam them close together, and try not to scale them up in such a way that you could see one through another<br />
<br />
In case you’re wondering, this is (probably) why the cathay maps perform so badly in the base game.<br />
<br />
<br />
==WH3 Domination Map Making Guide==<br />
<br />
===INITIAL FILE SETUP===<br />
When you first open Terry, you will be greeted by the following screen:<br />
<br />
[[File:dmmg_1.png|thumb|link=Special:FilePath/dmmg_1.png]]<br />
<br />
Lets get some terminology straight first:<br />
1. A “tile” is a section of terrain (of any size) that can be loaded as the playable map or as part of the outfield or vista<br />
2. A “tile map” is the outfield (background outside the playable area) that gets loaded in game whenever you boot up a map. As the name implies, a tile map is an arrangement of multiple tiles.<br />
3. A “prefab” is a collection of objects that can be loaded in and selected as one entity. It’s useful for making maps quickly as you will likely find with the CA-made prefabs. This guide will not touch on prefabs<br />
<br />
As of the initial writing of this guide, we don’t have any tile maps made by the community (or by CA) for use in WH3, but we do have all the WH2 tile maps (and most of them seem to work!). As such, I have uploaded them here for use in your maps.<br />
<br />
For the best compatibility with the existing WH2 tile maps, you should use 8x8 as your tile size. This “size” refers to the grid size of the green squares when you load up your tile.<br />
<br />
For climate, this controls the texture set used for your tile, and it should be pretty self-explanatory. This does not control the environment (lighting and atmospherics)<br />
<br />
The first time, save your map using “save as…”, which will pull up a dialog asking you to save a tile set and name. The name is not the display name for the map, and for the tile set you use, please save it as domination. Be sure to leave the box checked at the bottom.<br />
<br />
[[File:dmmg_2.png|thumb|link=Special:FilePath/dmmg_2.png]]<br />
<br />
If you are importing a WH2 map, you need to change “ProjectTilewithVista” in the .terry file to “ProjectTile” by opening the file with notepad and changing it manually. In addition, when you load the map in, you will likely be greeted by a red hellscape. To get rid of this, you have to load a new environment file in “settings” at the bottom right.<br />
<br />
Whenever you reload a map, you may often be greeted by overly dark shadows. To fix this, regenerate light probes in settings (shown below).<br />
<br />
Insert the provided terry_buildings file into WH3’s data directory to add additional buildings into terry for your use.<br />
<br />
Finally, you should refrain from putting anything in your map below y=0 due to a water heights issue. If you do have stuff below y=0, then you will have to raise the tile map until no terrain is below y=0 in order to prevent floating unit icons.<br />
<br />
[[File:dmmg_3.png|thumb|link=Special:FilePath/dmmg_3.png]]<br />
<br />
===SETTING UP INITIAL DEPLOYMENT<br />
So we’ve skipped ahead a little since the act of texturing, placing objects, adjusting the height map, etc hasn’t changed much from previous iterations of terry and is very intuitive. This section will basically cover how to set up deployment zones. However, as best practice, you should also set up no-go zones around any impassable terrain and check the size of your map as you make it with the prop “ref_group_human”.<br />
<br />
For deployment zones, go to tools > entity creation (logical), and create one on each side. Next, go to the object tree on the left and click on each zone. In each, you will find an additive deployment zone region. This is the zone players will deploy in to start the game. Next change one of the zones to alliance ID 1 and it will turn red. Remember that blue is attackers and red is defenders (very intuitive, I know).<br />
<br />
With your initial deployment zones made, create another deployment zone region with tools > entity creation (logical). The option is only accessible if you have selected the corresponding deployment zone you want it to be associated with. This deployment zone region will be for vanguard deployment and will use the zone type “guerilla exclusion additive”.<br />
<br />
Basically, the way guerilla exclusion additive zones work in Terry is that it prevents the opposite alliance from deploying in that zone. In other words, the opposite team can vanguard deploy everywhere except for the enemy alliance’s guerilla exclusion zone. See below for an example of how my zones are set up. I have drawn over the zones to make them easier to see.<br />
<br />
[[File:dmmg_4.png|thumb|link=Special:FilePath/dmmg_4.png]]<br />
<br />
[[File:dmmg_5.png|thumb|link=Special:FilePath/dmmg_5.png]]<br />
<br />
As you can see, there will be some overlap between guerilla exclusion zones in the middle. As a final note, you must ensure that players cannot vanguard deploy onto the domination points since that would allow them to capture them before the match starts.<br />
<br />
Finally, you can make a playable area using tools > entity creation (logical). This defines what space in the tile that players can actually move around in (aka, the “white lines”). I think it should be between 2x2 and 3x3 or so, but it’s highly variable depending on how big or what shape you want the map to be. <br />
<br />
===SECTION 3: SETTING UP DOMINATION CAPTURE POINTS===<br />
To make capture points, go to tools > entity creation (logical) and create a capture point. You can make the point any shape, but I will use the rectangular shape as a reference. For type, use domination 1, 2, or 3 depending on which point you are making. For importance, you must use “score”. For size, I think anywhere between 80x80 to 180x180 can work depending on the map. See below for reference.<br />
<br />
[[File:dmmg_5_1.png|thumb|link=Special:FilePath/dmmg_5_1.png]]<br />
<br />
===SETTING UP TELEPORT POINTS===<br />
To make the points used to spawn units in, go to tools > entity creation (logical), and create an ai hint. Use the type “attacker (or defender) teleport reinforcement line” and create a single, short line with two points. Remember, attacker is the blue side and defender is the red side.<br />
<br />
The vanguard deployment lines are exactly the same, but make sure to check the box for vanguard deployment in the entity properties. See below as an example for one of the vanguard points.<br />
<br />
If you have issues with the teleport point not appearing in game, it is likely due to the line being too short. If it’s about 20 units long, that’s enough.<br />
<br />
[[File:dmmg_6.png|thumb|link=Special:FilePath/dmmg_6.png]]<br />
<br />
===SETTING UP THE TILE MAP===<br />
At this point, you have to understand two different file locations where map files are stored. In your assembly kit folder (located within WH3 wherever you have that stored), you will find two folders, raw_data and working_data. Raw data is the files that the modding tools will work with to make maps, while working data is the stuff that the mod tools export which you will need to compile to make the final map file. Everything we need will be located within the terrain folders of each.<br />
<br />
When you are more-or-less done with the map, go to “tools > create battle for tile…”. This will create a tile map file associated with this map in raw_data>terrain>battles>yourmap. You will only need to do this once. This has generated a tile map for your tile, but we need to change it because the climate isn’t set up and there’s no outfield.<br />
<br />
This is where you either create your own tile map or use one of the WH2 ones (I would suggest the latter for now). Use the vistas I have provided with this guide to pull the tile_map.png and climate_map.png files from whatever vista you want into the tile map folder that was generated. The tile map tells the game which tiles from the tile db to generate in the outfield, and the climate map tells the game which textures to use. Climate map colors are located in the settings file of terrain>tiles>battle>_tile_database. Tile map colors and sizes are located in the tile database found in terry. See below for an example of the files needed in the tile map folder. The extra terry user file is only generated when you open the tile map in Terry.<br />
<br />
[[File:dmmg_7.png|thumb|link=Special:FilePath/dmmg_7.png]]<br />
<br />
Next, you need to modify the explicit_tiles file to tell the game where the playable tile is located within the tile map. By default, it will probably be something like this:<br />
<br />
3,3,terrain/tiles/battle/lzd_hills_infield/chaqua_pit,0<br />
<br />
If you are using an 8x8 tile and one of the WH2 tile maps, your map will line up with the 8x8 black square in the middle. Open the tile map in a program like [https://www.gimp.org/ GIMP] to view the coordinates of the upper left corner of the black square. Change the first two numbers of the explicit_tiles file to these coordinates. See below for an example of the 28,28 coordinates for a 64x64 tile map.<br />
<br />
[[File:dmmg_8.png|thumb|link=Special:FilePath/dmmg_8.png]]<br />
<br />
Once you’re done with this open up the .terry file (the tile map) in Terry itself. This will initially load a tile map that is too small and isn’t using the right climate, but don’t panic! Changes to the tile map file will only show up in the editor once you have exported it, so do that now using file > process with BOB. To see if the tile map looks right, reload the tile map in Terry after you have exported it.<br />
<br />
===EXPORTING THE TILE===<br />
Always export the tile AFTER exporting the tile map. Do this by using file > process with BOB. If you make changes to your tile, you only need to re-export the tile, not the tile map. As stated before, you never need to do “tools > create battle for tile…” more than once.<br />
<br />
Before you export, also ensure that legacy vegetation generation is turned off the in the map properties (bottom right)<br />
<br />
===COMPILING THE MAP IN RPFM===<br />
Total war uses pack files to load mods into the user’s game. To make your pack file, you could use CA’s pack file manager, but most people think that the community-made [https://github.com/Frodo45127/rpfm/releases RPFM] is superior for this process. This tutorial will exclusively use RPFM.<br />
<br />
As an example for how this is set up, please download [https://steamcommunity.com/sharedfiles/filedetails/?id=2861441854 my map pack] and go to steamapps > workshop > content and then find the folder for WH3, then find my mod in that folder. There, you will find my mod’s pack file, which you can open in RPFM to see how to set this up.<br />
<br />
I will not describe in detail exactly how to use RPFM to do everything here, but I invite you to go to the modder’s den discord to ask questions about how the program works. Here is generally how a compiled map pack (with multiple maps) will look:<br />
<br />
[[File:dmmg_9.png|thumb|link=Special:FilePath/dmmg_9.png]]<br />
<br />
There are 4 main components:<br />
1. First add the map files by adding the entire working_data > terrain folder. Then delete the files for the assembly kit example map.<br />
2. Add a text db then add a line with “battles_localised_name_[map key]” followed by the display name. Tooltip is good.<br />
3. Add the folders for battle map images and add all of the in-game images that will display in the map selection screen. These images should be 3 times as wide as they are tall.<br />
4. Add a db with the battles_tables table. Most of it should be easy enough. For specification, use “copy path” to get the terrain > battles > yourmap folder for your map. You do need the extra slash at the end. Get the path for the environment file from the game files in the bottom left; it’s in the weathers folder.<br />
<br />
Finally, save your pack in WH3’s data folder located in the game’s base directory. Make a cover image to display in the workshop; it should be square, compressed, and should have the same name as the pack file.<br />
<br />
To assist in testing, you can use [https://steamcommunity.com/sharedfiles/filedetails/?id=2860443397 this] mod made by Klissan, which will allow you to load into domination maps without another player.<br />
<br />
GOOD LUCK, YOU’RE GONNA NEED IT<br />
<br />
<br />
==WH3 Map Making Beautification Guide==<br />
[https://docs.google.com/presentation/d/1f8SPKHqGtLz5jOZo-qoJshu_SP8gJ242UdOjbJBHrus/edit#slide=id.g1af5a2e59f5_0_50 powerpoint on beutification]<br />
<br />
==WH3 Battle Map Capture Points Guide==<br />
<br />
===INTRO===<br />
With the latest release of the Total Tavern map pack (Nov 2, 2022), we now have a rudimentary ability to add additional capturable objectives to domination maps other than the 3 main objectives. In particular, we are able to add points that give supplies as well as generic points that can be used for as a logical link to other capturable objectives.<br />
<br />
Assuming you already know how to make capture points, let’s look at all of the different parameters in a capture point:<br />
<br />
[[File:CP_1.png|thumb|link=Special:FilePath/CP_1.png]]<br />
<br />
The most important parameters are the type and the importance. The type controls the symbol given to the capture point on the UI as well as the tooltip that appears when you mouse over it. The importance controls how many tickets the capture points gives, what currencies the points gives, and the time it takes to capture it.<br />
<br />
As you can imagine, the importance of the capture point is its chief parameter. Unfortunately, due to database limitations, we cannot add new levels of importance for capture points, but we can add new capture point types. Therefore, when thinking about how to add different types of capture points, we can only work with 4 different levels of importance: Key Building A, Key Building, B, Major and Minor (these 4 were otherwise unused in domination).<br />
<br />
<br />
===HOW TO ADD SUPPLY POINTS===<br />
The biggest functionality that this map pack update provides is the ability to create points that generate supplies. This functionality is mainly controlled by the db/battle_secondary_currency_sources_links_tables (see pic below).<br />
<br />
[[File:CP_2.png|thumb|link=Special:FilePath/CP_2.png]]<br />
<br />
As you can see, each entry defines how a certain number of supplies are doled out as long as the “source type” condition is met. For example, for line 3, the game will give 3 supplies/second to a player as long as they control a major victory point, regardless of how many major victory points they control. Because of that, if you wanted to make two capture points in a map that each gave 1 supply/second, you would have to have them on two separate importance levels.<br />
<br />
As a result, this is how the importance levels shook out when I designed this mod:<br />
● Score - This was not changed at all since this is reserved for the domination points themselves<br />
● Minor - This will give neither supplies nor tickets. It is intended to be a point type used for side objectives like capturable towers or reinforcement points<br />
● Key Building A and B - I wanted the ability to make maps with two points that each give 1 supply/second, so both of these are reserved for that purpose<br />
● Major - Gives 3 supplies/second<br />
<br />
To communicate this to the player, I created 3 new capture point types. The picture below shows the .loc that generates the tooltips so you can see what they say:<br />
<br />
[[File:CP_3.png|thumb|link=Special:FilePath/CP_3.png]]<br />
<br />
Therefore, there are a limited number of available configurations for supply points, and certain point types should only be used with certain point importances. To sum up, these are the only available configurations of supply points you can use on your maps:<br />
<br />
Option A:<br />
1. Supply point 1 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply Point 2 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building B (generates 1 sup/sec)<br />
Option B:<br />
1. Supply Point 1 of 1<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
Option C:<br />
1. Supply point 1 of 2<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply Point 2 of 2<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
Option D:<br />
1. Supply point 1 of 3<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building A (generates 1 sup/sec)<br />
2. Supply point 2 of 3<br />
a. Type: tt_dom_supply_point_i<br />
b. Importance: Key Building B (generates 1 sup/sec)<br />
3. Supply Point 3 of 3<br />
a. Type: tt_dom_supply_point_ii<br />
b. Importance: Major (generates 3 sup/sec)<br />
<br />
<br />
===HOW TO ADD REINFORCEMENT CAPTURE POINTS===<br />
Tower capture points are fairly self-explanatory in the sense that you can just add the required tower prefab and then link it to the CA-provided tower_only capture point zone. However, reinforcement zone capture points didn’t seem to be something that CA planned for, so it required the addition of another capture point zone type to communicate this functionality to the player.<br />
<br />
To be clear, when I’m talking about reinforcement zone capture points, I’m talking about stuff like my map, Crater of Decay, where you have an additional objective that, when captured, unlocks neutral zones where you can spawn units from.<br />
<br />
[[File:CP_4.png|thumb|link=Special:FilePath/CP_4.png]]<br />
<br />
Minor importance was reserved for this purpose since it will not give any supplies. As a result, all reinforcement zone capture points should look like this:<br />
<br />
[[File:CP_5.png|thumb|link=Special:FilePath/CP_5.png]]<br />
<br />
Of course, reinforcement capture points also require the extra step of linking them to the points they give control over. To do this, simply go to the entity properties of those reinforcement points, and select the tt_dom_reinf_zone_point from the capture location drop-down menu. See example below for a capturable vanguard point.<br />
<br />
[[File:CP_6.png|thumb|link=Special:FilePath/CP_6.png]]<br />
<br />
One important thing to note is that despite the fact that the reinforcement spawn points are now capturable, they aren’t “neutral” in the sense that they are still linked to attacker and defender. For example, if the attacker captures the tt_dom_reinf_zone_point, they will not gain control of this defender teleport reinforcement line. Only the defender can do that and vice versa.<br />
<br />
===REQUIRED FILES AND HOW TO TEST===<br />
Since modifications were made to the game to make all this stuff work, you will need to put these changes into your mod to do any testing. To facilitate this, I have created two pack files:<br />
[https://drive.google.com/file/d/1hA_psc5m5fAEYKqzyaQPyuhui8POl71O/view?usp=share_link link]<br />
[https://drive.google.com/file/d/1MFGgsxw9rFP2bVBWEjkbIOS4d78l0NVt/view?usp=share_link link]<br />
<br />
<br />
The first link is a pack file that you should put in your game’s data folder. All this does is it adds the new capture point types as table entries so that you can select them when making maps.<br />
<br />
The second pack file is something that you should merge into your map mod’s pack file to get all of the other database changes that affect gameplay. To do this, right click the root of your pack file in RPFM and go to add > from pack file. Then navigate to the file from the second download link that says “merge me”.<br />
<br />
[[File:CP_7.png|thumb|link=Special:FilePath/CP_7.png]]<br />
<br />
After that, just double click the root of the other pack file, and it will bring everything in.<br />
<br />
<br />
==How to Make Land Battle versions of Domination maps==<br />
This will use the catchment system so that you don’t have to make multiple copies of the same map.<br />
<br />
First, put everything related specifically to the domination game mode into a file layer or logical layer. The difference between the two is that file layer saves the selection to a different layer file whereas logical layer will save it as a selection within the same layer file. Either will work.<br />
<br />
Next, change the BMD export type of the layer to catchment_01 (or whichever you want to use).<br />
<br />
Example:<br />
<br />
[[File:lb_to_d_1.png|thumb|link=Special:FilePath/Lb_to_d_1.png]]<br />
<br />
Then export the tile and add it to your pack file as you normally would; exporting the tile map is not required if you have already done so before.<br />
<br />
In battles_tables in RPFM, you will have to make two separate rows for your map. I have copied the relevant columns from the two entries in my pack so you can see how it should be.<br />
<br />
KEY de_labor_camp_dom de_labor_camp_lb<br />
TYPE domination classic<br />
SPECIFICATION terrain/battles/test_domination_de_labor_camp/ terrain/battles/test_domination_de_labor_camp/ <br />
SCREENSHOT PATH ui/frontend ui/battle_map_images/bleakspire_wide.png ui/frontend ui/battle_map_images/bleakspire_wide.png <br />
CATCHMENT NAME catchment_01<br />
<br />
So basically, everything stays the same except you change the battle type, append something to the key to make it easy to recognize which is which (I chose “_dom” and “_lb”), and then load the appropriate catchment layer for dom.<br />
<br />
Once you’ve done that, you also need to update the text loc file which generates the display names since there are now two different keys.<br />
<br />
In this case, all I did was isolate the domination-specific features. However, this system is quite flexible. For example, you could have different initial deployment zones and white lines on the domination version of the map than the land battle version by having one set be on catchment_01 and the other on catchment_02.<br />
<br />
[[Category:Warhammer 3]]</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Green3.png&diff=576File:Green3.png2023-02-24T00:23:10Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Battle4.png&diff=575File:Battle4.png2023-02-24T00:23:10Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:File5.png&diff=574File:File5.png2023-02-24T00:23:09Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Green.png&diff=573File:Green.png2023-02-24T00:23:09Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Green1.png&diff=572File:Green1.png2023-02-24T00:23:09Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Green2.png&diff=571File:Green2.png2023-02-24T00:23:08Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=File:Optimization.png&diff=570File:Optimization.png2023-02-24T00:23:08Z<p>Not All is Dust: File uploaded with MsUpload</p>
<hr />
<div>File uploaded with MsUpload</div>Not All is Dusthttps://tw-modding.com/index.php?title=Example_Scripts&diff=544Example Scripts2022-09-12T22:07:59Z<p>Not All is Dust: /* Example Scripts */</p>
<hr />
<div>A list of example scripts that can easily be copied, edited and then put into a [[Mods|mod]].<br />
<br />
== Using Example Scripts ==<br />
Unless otherwise stated these scripts go into a .pack file at `script/campaign/mod/?.lua`, replace ? with whatever your file name is.<br />
<br />
Each script listed is self-contained - so you can use multiple of the example scripts in a single .lua file.<br />
<br />
When using the scripts, please keep the credits at the top and don't remove comments. Comments are the text following -- or in a comment block denoted by --[ [ Text here ] ].<br />
<br />
Typically an example script will have a list of variables that should be changed to tailor the script to your particular mod, these will often have comments next to them explaining where you will find the keys or values from.<br />
<br />
Example in the Replace Starting General example script, you have a line that reads 'local faction_name = "wh_main_emp_empire";'<br />
<br />
This could instead be changed to 'local faction_name = "wh2_dlc11_vmp_the_barrow_legion";' to affect the Barrow Legion faction instead of The Empire.<br />
<br />
If there are out() calls within the example script, you are encouraged to insert a unique text identifier, so you can find your unique output in the [[Lua:Debugging|script logs]] using ctrl+f.<br />
<br />
Example in the Replacing Starting General Script, replace REPLAC: with your unique identifier, maybe the starting letters of your discord username, or the mod name or the name of your cat, or something else unique to you.<br />
<br />
== Contributing new scripts ==<br />
If you have some generic scripted functionality you think would be useful for the wider community, please consider adding it to the wiki here, or bring attention to it via Modding Discord in the channel for the wiki.<br />
<br />
Add a new Sub-Heading 1 within the Example Scripts section below, give it a meaningful title and a short description. Include what games it is valid for and any specific notes necessary, ie. has to go in this directory, has to be done this way etc.<br />
<br />
Avoid using global variables in the example scripts, use local variables and local functions to avoid incidents involving scripts that have overlapping names. Make sure to use comments explaining what the various parts of the script is doing or when referring to specific keys from the database, like where to find them. Context and explanation goes a long way towards helping make sense of the scripts for beginners.<br />
<br />
If your script runs through a single init function that's triggered through a first tick callback, give the local function a meaningful name and implement the first-tick-callback, and leave it at that. No need to have the modder replace the local function name in their own replication.<br />
<br />
Mind that plopping something in this page leaves it open for collaboration, so someone in the future may come in and add more comments, change anything necessary for an update, make an extra version for another game, or much else. If you're editing the original script, leave the credits the same, or add your name to the credits if you think the addition is meaningful. Don't remove the OG author for sure.<br />
<br />
== Example Scripts ==<br />
<br />
=== Replacing a Starting General ===<br />
<br />
<nowiki><br />
--[[<br />
Script by Aexrael Dex<br />
Replaces the starting general for a specific faction<br />
]]<br />
<br />
local function replace_starting_general()<br />
if cm:is_new_game() then<br />
-- The Empire<br />
local faction_name = "wh_main_emp_empire"; -- Faction key from Factions table<br />
local faction = cm:get_faction(faction_name);<br />
<br />
if faction:is_null_interface() == false and faction:is_dead() == false then<br />
<br />
-- Creating replacement for Karl Franz with a regular Empire General<br />
local general_details = {<br />
general_faction = faction_name,<br />
unit_list = "wh_main_emp_cav_reiksguard,wh_main_emp_cav_reiksguard,wh_main_emp_cav_reiksguard"; -- unit keys from main_units table<br />
region_key = faction:home_region():name(),<br />
type = "general", -- Agent type<br />
subtype = "emp_lord", -- Agent subtype<br />
forename = "names_name_1904032251", -- From local_en names table, Bernhoff the Butcher is now ruler of Reikland<br />
clanname = "", -- From local_en names table<br />
surname = "names_name_151217003", -- From local_en names table<br />
othername = "", -- From local_en names table<br />
is_faction_leader = true, -- Bool for whether the general being replaced is the new faction leader<br />
trait = "wh2_dlc09_trait_benevolence" -- The trait key you want to assign to the new General from character traits table<br />
};<br />
<br />
local general_x_pos, general_y_pos = cm:find_valid_spawn_location_for_character_from_settlement(general_details.general_faction, general_details.region_key, false, true, 8);<br />
out(faction_name .. " home region name is " .. general_details.region_key);<br />
<br />
cm:create_force_with_general(<br />
general_details.general_faction,<br />
general_details.unit_list,<br />
general_details.region_key,<br />
general_x_pos,<br />
general_y_pos,<br />
general_details.type,<br />
general_details.subtype,<br />
general_details.forename,<br />
general_details.clanname,<br />
general_details.surname,<br />
general_details.othername,<br />
general_details.is_faction_leader,<br />
<br />
-- Generals created this way does not come with a trait normally<br />
function(cqi)<br />
local char_str = cm:char_lookup_str(cqi);<br />
<br />
-- Adding a new trait to the above general<br />
cm:force_add_trait(char_str, general_details.trait, true);<br />
out("Adding Replacement General's trait");<br />
end<br />
);<br />
out("Created replacement Lord " .. general_details.forename .. " for " .. faction_name);<br />
<br />
-- Killing Karl Franz permanently<br />
local char_list = faction:character_list();<br />
local char_subtype = "emp_karl_franz"; -- Karl Franz's agent subtype<br />
local char_forename = "names_name_2147343849"; -- Karl Franz's forename<br />
<br />
for i = 0, char_list:num_items() - 1 do<br />
local current_char = char_list:item_at(i);<br />
local char_str = cm:char_lookup_str(current_char);<br />
<br />
if current_char:is_null_interface() == false and current_char:character_subtype_key() == char_subtype and current_char:get_forename() == char_forename and current_char:has_military_force() == true then<br />
cm:set_character_immortality(char_str, false);<br />
cm:disable_event_feed_events(true, "wh_event_category_character", "", "");<br />
cm:kill_character(current_char:command_queue_index(), true, true);<br />
cm:callback(function() cm:disable_event_feed_events(false, "wh_event_category_character", "", "") end, 0.5);<br />
out("Killing original " .. char_subtype .. " with forename " .. char_forename .. " for " .. faction_name .. " permanently");<br />
end;<br />
end;<br />
end;<br />
end;<br />
end;<br />
<br />
cm:add_first_tick_callback(function() replace_starting_general() end);</nowiki><br />
<br />
=== Adding RoRs to mercenary pool ===<br />
<br />
<nowiki>--[[<br />
Script by Aexrael Dex<br />
Adds custom Regiments of Reknown to specified factions<br />
]]<br />
<br />
local function add_custom_ror()<br />
<br />
-- Checking whether the script has already run for saved games and if it has then the script doesn't need to run again<br />
if cm:get_saved_value("custom_ror_enabled") == nil then<br />
<br />
-- Table for faction, unit key and parameters for add_unit_to_faction_mercenary_pool<br />
local cror_list = {<br />
{faction_key = "wh_main_vmp_schwartzhafen", unit = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0", count = 1, rcp = 100, munits = 1, murpt = 0.1, xplevel = 0, frr = "", srr = "", trr = "", replen = true},<br />
{faction_key = "wh_main_vmp_vampire_counts", unit = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0", count = 1, rcp = 100, munits = 1, murpt = 0.1, xplevel = 0, frr = "", srr = "", trr = "", replen = true}<br />
};<br />
<br />
-- Loop for the table above<br />
for i = 1, #cror_list do<br />
local faction_name = cror_list[i].faction_key; -- Faction whose pool the unit(s) should be added to<br />
local faction = cm:get_faction(faction_name); -- FACTION_SCRIPT_INTERFACE<br />
local unit_key = cror_list[i].unit; -- Key of unit to add to the mercenary pool, from the main_units table<br />
local unit_count = cror_list[i].count; -- Number of units to add to the mercenary pool<br />
local rcp = cror_list[i].rcp; -- Replenishment chance, as a percentage<br />
local munits = cror_list[i].munits; -- The maximum number of units of the supplied type that the pool is allowed to contain.<br />
local murpt = cror_list[i].murpt; -- The maximum number of units of the supplied type that may be added by replenishment per-turn<br />
local xplevel = cror_list[i].xplevel; -- The experience level of the units when recruited<br />
local frr = cror_list[i].frr; -- (may be empty) The key of the faction who can actually recruit the units, from the factions database table<br />
local srr = cror_list[i].srr; -- (may be empty) The key of the subculture who can actually recruit the units, from the cultures_subcultures database table<br />
local trr = cror_list[i].trr; -- (may be empty) The key of a technology that must be researched in order to recruit the units, from the technologies database table<br />
local replen = cror_list[i].replen; -- Allow replenishment of partial units<br />
<br />
-- Adding the listed unit to the listed faction in the above table<br />
cm:add_unit_to_faction_mercenary_pool(faction, unit_key, unit_count, rcp, munits, murpt, xplevel, frr, srr, trr, replen);<br />
<br />
-- Debug message for log<br />
out("CROR: adding the custom ror unit " .. unit_key .. " to " .. faction_name);<br />
end;<br />
<br />
-- Setting saved value, so that the script doesn't run again when reloaded from a saved game<br />
cm:set_saved_value("custom_ror_enabled", true);<br />
end;<br />
end;<br />
<br />
cm:add_first_tick_callback(function() add_custom_ror() end);</nowiki><br />
<br />
=== Replacing Starting Armies ===<br />
<br />
<nowiki>--[[<br />
Script by Aexrael Dex<br />
Replaces the starting units for specified starting Lords<br />
]]<br />
<br />
local function army_tweaks()<br />
<br />
-- Checking whether it's a new game, we don't want to replace armies in the middle of a campaign<br />
if cm:is_new_game() then<br />
<br />
-- Creating a table with entries for the various starting Lords, their Faction key from Factions table, subtype key from agent_subtypes, Forename from names table and Unit List with keys from Main Units<br />
local starting_army = {<br />
-- Vlad, Carsteins<br />
{faction_key = "wh_main_vmp_schwartzhafen", subtype = "dlc04_vmp_vlad_con_carstein", forename = "names_name_2147345130", units = {"wh_main_vmp_inf_skeleton_warriors_0", "wh_main_vmp_inf_skeleton_warriors_0", "wh_main_vmp_mon_fell_bats", "wh_main_vmp_mon_fell_bats", "wh_main_vmp_cav_black_knights_0", "wh_main_vmp_cav_black_knights_0"}},<br />
-- Isabella, Carsteins<br />
{faction_key = "wh_main_vmp_schwartzhafen", subtype = "pro02_vmp_isabella_von_carstein", forename = "names_name_2147345124", units = {"wh_main_vmp_inf_zombie", "wh_main_vmp_inf_zombie", "wh_main_vmp_mon_dire_wolves", "wh_main_vmp_mon_dire_wolves", "wh_main_vmp_mon_fell_bats", "wh_main_vmp_mon_vargheists"}}<br />
};<br />
<br />
for i = 1, #starting_army do<br />
local faction_name = starting_army[i].faction_key;<br />
local faction = cm:get_faction(faction_name);<br />
local char_list = faction:character_list();<br />
local general_subtype = starting_army[i].subtype;<br />
local general_forename = starting_army[i].forename;<br />
local unit_list = starting_army[i].units;<br />
<br />
for j = 0, char_list:num_items() - 1 do<br />
local current_char = char_list:item_at(j);<br />
local char_str = cm:char_lookup_str(current_char);<br />
<br />
if current_char:is_null_interface() == false and current_char:character_subtype_key() == general_subtype and current_char:get_forename() == general_forename and current_char:has_military_force() == true then<br />
<br />
-- Removing all existing units from the General<br />
cm:remove_all_units_from_general(current_char);<br />
out("ARMY: Removing starting units from " .. general_subtype .. " with forename " .. general_forename);<br />
<br />
for k = 1, #unit_list do<br />
local unit = unit_list[k];<br />
<br />
-- Granting new units to the General<br />
cm:grant_unit_to_character(char_str, unit);<br />
out("ARMY: Adding new starting units to " .. general_subtype .. " with forename " .. general_forename);<br />
end;<br />
end;<br />
end;<br />
end;<br />
end;<br />
end;<br />
<br />
cm:add_first_tick_callback(function() army_tweaks() end);</nowiki><br />
<br />
=== Changing CAI based on campaign difficulty ===<br />
<br />
<nowiki>--[[<br />
Script by Aexrael Dex<br />
Replaces the Campaign AI Personality for specific factions depending on the chosen campaign difficulty level<br />
]]<br />
<br />
local function replace_cai_difficulty()<br />
if cm:is_new_game() == true then<br />
local difficulty_str = cm:get_difficulty(true);<br />
local def_personality = "";<br />
local hef_personality = "";<br />
local wef_personality = "";<br />
<br />
-- CAI personality to use for easy difficulty<br />
if difficulty_str == "easy" then<br />
<br />
def_personality = "wh2_darkelf_early_easy";<br />
hef_personality = "wh2_highelf_early_easy";<br />
wef_personality = "wh_dlc05_wood_elves_default_main";<br />
<br />
-- CAI personality to use for normal difficulty<br />
elseif difficulty_str == "normal" then<br />
<br />
def_personality = "wh2_darkelf_early";<br />
hef_personality = "wh2_highelf_early";<br />
wef_personality = "wh_dlc05_wood_elves_default_main";<br />
<br />
-- CAI personality to use for hard difficulty<br />
elseif difficulty_str == "hard" then<br />
<br />
def_personality = "wh2_darkelf_early_hard";<br />
hef_personality = "wh2_highelf_early_hard";<br />
wef_personality = "wh_dlc05_wood_elves_default_main";<br />
<br />
-- CAI personality to use for very hard difficulty<br />
elseif difficulty_str == "very hard" then<br />
<br />
def_personality = "wh2_darkelf_early_hard";<br />
hef_personality = "wh2_highelf_early_hard";<br />
wef_personality = "wh_dlc05_wood_elves_default_main";<br />
<br />
-- CAI personality to use for legendary difficulty<br />
elseif difficulty_str == "legendary" then<br />
<br />
def_personality = "wh2_darkelf_early_hard";<br />
hef_personality = "wh2_highelf_early_hard";<br />
wef_personality = "wh_dlc05_wood_elves_default_main";<br />
end;<br />
<br />
local faction_list = cm:model():world():faction_list();<br />
<br />
for i = 0, faction_list:num_items() - 1 do<br />
local faction = faction_list:item_at(i);<br />
local faction_name = faction:name();<br />
local faction_culture = faction:culture();<br />
<br />
-- Checking whetether the faction exists and is alive<br />
if faction:is_null_interface() == false and faction:is_dead() == false and faction:is_human() == false then<br />
<br />
-- Dark Elves culture<br />
if faction_culture == "wh2_main_def_dark_elves" then<br />
<br />
-- Changing the CAI for all Dark Elf factions<br />
cm:force_change_cai_faction_personality(faction_name, def_personality);<br />
out("ELF: Changing CAI personality for " .. faction_name .. " to " .. def_personality .. " on " .. difficulty_str .. " difficulty");<br />
<br />
-- High Elves culture<br />
elseif faction_culture == "wh2_main_hef_high_elves" then<br />
<br />
-- Changing the CAI for all High Elf factions<br />
cm:force_change_cai_faction_personality(faction_name, hef_personality);<br />
out("ELF: Changing CAI personality for " .. faction_name .. " to " .. hef_personality .. " on " .. difficulty_str .. " difficulty");<br />
<br />
-- Wood Elves culture<br />
elseif faction_culture == "wh_dlc05_wef_wood_elves" then<br />
<br />
-- Changing the CAI for all Wood Elf factions<br />
cm:force_change_cai_faction_personality(faction_name, wef_personality);<br />
out("ELF: Changing CAI personality for " .. faction_name .. " to " .. wef_personality .. " on " .. difficulty_str .. " difficulty");<br />
end;<br />
end;<br />
end;<br />
end;<br />
end;<br />
<br />
cm:add_first_tick_callback(function() replace_cai_difficulty() end);</nowiki><br />
<br />
=== Spawning a Unique Agent ===<br />
<br />
<nowiki><br />
--[[<br />
Script by Aexrael Dex<br />
Spawns a Unique Agent next to the starting lord of a specified faction<br />
]]<br />
<br />
local function add_unique_agent()<br />
<br />
-- Checking whether the script has already run for saved games and if it has then the script doesn't need to run again<br />
if cm:get_saved_value("unique_agent_enabled") == nil then<br />
<br />
-- Starting agent setup<br />
unique_agent_setup();<br />
end;<br />
end;<br />
<br />
function unique_agent_setup()<br />
-- Agent Details<br />
local agent_details = {<br />
faction_str = "wh2_dlc13_emp_the_huntmarshals_expedition", -- faction_key from factions<br />
forename_key = "names_name_2147359013", -- forename_key from names<br />
family_name_key = "names_name_1535812850", -- family_name_key from names<br />
subtype_key = "wh2_dlc13_emp_hunter_jorek_grimm", -- agent subtype_key from agent_subtypes<br />
art_set_key = "wh2_dlc13_art_set_emp_hunter_jorek_grimm_0", -- agent art_set_id from campaign_character_arts<br />
unique_string = "wh2_dlc13_emp_hunter_jorek_grimm", -- unique agent string from unique_agents<br />
saved_value = "unique_agent_enabled", -- saved_value string<br />
trait = "wh2_dlc09_trait_benevolence" -- agent trait from character_traits<br />
};<br />
<br />
-- Monitor activated, listening for FactionTurnStart for The Huntmarshals Expedition<br />
core:add_listener(<br />
"unique_agent_setup",<br />
"FactionTurnStart",<br />
function(context)<br />
return context:faction():name() == agent_details.faction_str;<br />
end,<br />
function(context)<br />
-- Spawning Jorek as a unique agent next to Markus<br />
local faction = cm:get_faction(agent_details.faction_str);<br />
local faction_cqi = faction:command_queue_index();<br />
local faction_leader_cqi = faction:faction_leader():command_queue_index();<br />
<br />
cm:disable_event_feed_events(true, "wh_event_category_agent", "", "");<br />
cm:spawn_unique_agent_at_character(<br />
faction_cqi,<br />
agent_details.unique_string,<br />
faction_leader_cqi,<br />
true<br />
);<br />
cm:callback(function()<br />
cm:disable_event_feed_events(false, "wh_event_category_agent", "", "");<br />
CampaignUI.ClearSelection();<br />
end, 0.5);<br />
out("UNIQ: Spawned Jorek next to Markus");<br />
<br />
-- Looping through the character list for The Huntmarshals Expedition<br />
local char_list = faction:character_list();<br />
<br />
for i = 0, char_list:num_items() - 1 do<br />
local current_char = char_list:item_at(i);<br />
local char_str = cm:char_lookup_str(current_char);<br />
<br />
-- Adding Joreks trait, replenishing AP and overriding the art set<br />
if current_char:is_null_interface() == false and current_char:character_subtype_key() == agent_details.subtype_key then<br />
<br />
-- Adding trait<br />
cm:force_add_trait(char_str, agent_details.trait, false);<br />
out("UNIQ: Adding " .. agent_details.trait .. " to Jorek");<br />
<br />
-- Replenishing action points<br />
cm:replenish_action_points(char_str);<br />
out("UNIQ: Replenishing the action points of Jorek");<br />
<br />
-- Failsafe for the random chance that the art_set doesn't apply properly<br />
cm:add_unit_model_overrides(char_str, agent_details.art_set_key);<br />
out("UNIQ: Adding unit model override for Jorek");<br />
end;<br />
end;<br />
<br />
-- Setting saved value, so that the script doesn't run again when reloaded from a saved game<br />
cm:set_saved_value(agent_details.saved_value, true);<br />
out("UNIQ: Setting saved value " .. agent_details.saved_value);<br />
end,<br />
false<br />
);<br />
end;<br />
<br />
cm:add_first_tick_callback(function() add_unique_agent() end);</nowiki><br />
<br />
=== Adding RoRs to mercenary pool, Wh3 version ===<br />
<nowiki>--[[<br />
Script by Aexrael Dex<br />
Adds custom Regiments of Renown to specified factions<br />
]]<br />
--Edited to function with total war warhammer 3, by All is Dust<br />
<br />
local function add_custom_ror()<br />
<br />
-- Checking whether the script has already run for saved games and if it has then the script doesn't need to run again<br />
if cm:get_saved_value("custom_ror_enabled") == nil then<br />
<br />
-- Table for faction, unit key and parameters for add_unit_to_faction_mercenary_pool. Every entry must have a "," at the end except the last<br />
local cror_list = {<br />
{faction_key = "wh_main_vmp_schwartzhafen", unit = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0", merc_pool = "renown", count = 1, rcp = 100, munits = 1, murpt = 0.1, xplevel = 0, frr = "", srr = "", trr = "", replen = true, merc_group = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0"},<br />
{faction_key = "wh_main_vmp_vampire_counts", unit = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0", merc_pool = "renown", count = 1, rcp = 100, munits = 1, murpt = 0.1, xplevel = 0, frr = "", srr = "", trr = "", replen = true, merc_group = "wh2_dlc11_cst_inf_zombie_deckhands_mob_ror_0"}<br />
};<br />
<br />
-- Loop for the table above<br />
for i = 1, #cror_list do<br />
local faction_name = cror_list[i].faction_key; -- Faction whose pool the unit(s) should be added to<br />
local faction = cm:get_faction(faction_name); -- FACTION_SCRIPT_INTERFACE<br />
local unit_key = cror_list[i].unit; -- Key of unit to add to the mercenary pool, from the main_units table<br />
local pool = cror_list[i].merc_pool; --NEW, found in "ui_mercenary_recruitment_infos_tables" table, or in "mercenary_pools_tables" beneath UI recruitment info <br />
local unit_count = cror_list[i].count; -- Number of units to add to the mercenary pool<br />
local rcp = cror_list[i].rcp; -- Replenishment chance, as a percentage<br />
local munits = cror_list[i].munits; -- The maximum number of units of the supplied type that the pool is allowed to contain.<br />
local murpt = cror_list[i].murpt; -- The maximum number of units of the supplied type that may be added by replenishment per-turn<br />
local xplevel = cror_list[i].xplevel; -- The experience level of the units when recruited<br />
local frr = cror_list[i].frr; -- (may be empty) The key of the faction who can actually recruit the units, from the factions database table<br />
local srr = cror_list[i].srr; -- (may be empty) The key of the subculture who can actually recruit the units, from the cultures_subcultures database table<br />
local trr = cror_list[i].trr; -- (may be empty) The key of a technology that must be researched in order to recruit the units, from the technologies database table<br />
local replen = cror_list[i].replen; -- Allow replenishment of partial units<br />
local merc_grup_key = cror_list[i].merc_group; --NEW, key used in mercenary_unit_groups_tables can most of the time be the same has main_unit key<br />
<br />
-- Adding the listed unit to the listed faction in the above table<br />
cm:add_unit_to_faction_mercenary_pool(faction, unit_key, pool, unit_count, rcp, munits, murpt, frr, srr, trr, replen, merc_grup_key);<br />
<br />
-- Debug message for log<br />
out("CROR: adding the custom ror unit " .. unit_key .. " to " .. faction_name);<br />
end;<br />
<br />
-- Setting saved value, so that the script doesn't run again when reloaded from a saved game<br />
cm:set_saved_value("custom_ror_enabled", true);<br />
end;<br />
end;<br />
<br />
cm:add_first_tick_callback(function() add_custom_ror() end);</nowiki></div>Not All is Dust