Modding Tips & Tricks

This is a compilation of useful **tips & tricks** that might not easily fit elsewhere.

## Startup.lua etc.

* Startup.lua: will be triggered when the game starts up. Must be placed in the ModName/Resources/Scripts-folder
* PostLoadInit.lua file: Any .lua file that ends in 'PostLoadInit' (e.g. TestModPostLoadInit.lua) will be executed when either a game is started or a save is loaded.
* PreLoadInit.lua: triggers earlier on in the loading sequence than PostLoadInit.lua. Like with PostLoadInit the filename can be prefixed with anything so long as it ends in PreLoadInit.

## Sleepuntil

You can include the sleepuntil command in a loop to check if certain conditions are met and if so proceed to process some code or check some condition e.g. for an objective. Triggers may be

* sleepuntil("capture") to check if an object (e.g. a city) is being captured
* sleepuntil("growcity") to check if a city increases in population
* sleepuntil("upgradepurchased") to check if an upgrade has been commissioned
* sleepuntil("upgradebuilt") to check if an upgrade has been built
* sleepuntil("addtocontainer") to check if a brigade has been added to e.g. a resouce building
* sleepuntil("removefromcontainer") to check if a brigade has been removed
* sleepuntil("createunit") to check if a brigade has been built
* sleepuntil("defeat") to check if units are killed/defeated
* sleepuntil("captureslaves") to check if units are enslaved
* sleepuntil("createtraderoute") to check if a trade route has been established
* sleepuntil("razepop") to check if a city has been razed
* sleepuntil("occupytarget")
* sleepuntil("raid")

Additionally, you also may use the sleepmany-command, e.g. sleepmany("occupytarget", "addtocontainer", "removefromcontainer")

## Hideattribute

There is a way to make recruitable brigades visible/invisible in the recruitment GUI depending on attributes available. You can e.g. add <hideattribute hideonhave="false">buildships</hideattribute> to any brigade definition; the hideonhave is "false" when you want the brigade to be hidden when the city doesn't have an attribute, and "true" when you want the brigade to be hidden when the city does. You'll be able to have as many hideattributes per brigade as you like and can use any attribute, including custom ones, in place of buildships for it, and it will be hidden if any of them match up.

## Setstate

The setstate() command comes in handy to dynamically modify an object that otherwise one would have to adjust its xml definition for. Most of these are only ever used on brigades.

* setstate(statenothungry, true) makes a brigade not consume or require any food.
* setstate(statepermakill, true) makes a brigade permanently destroyed upon defeat as if it were homeless.
* setstate(statecritical, true) makes it impossible to disband a brigade.
* setstate(statestayhappy, true) - to be confirmed (maybe it keeps a brigade's morale full?)
* setstate(statenofog, true) should cause a unit or building to be visible even through the fog of war

And obviously, calling the same command with 'false' disables the effect again.

## LUA code inside XML structures

There is an issue with the way Hegemony has the LUA code within XML structure for quests (within the <script></script> nodes). The "less than" symbol '<' is causing an issue as even though it is within the LUA code section, LUA is still interpreting it as the start of a new XML node. So the LUA content of the <script> node is not being read correctly after the occurence of a "less than" comparison in the LUA code. This will result in an error with a very cryptic error description.

To fix this use (without space in between letters):

* ***& l t ;*** instead of <
* ***& l t ; =*** instead of <=
* > will usually not trow an error but it can also be replaced by writing ***& g t ;***

Fix - open this wiki page in "source editor" mode to see the solution
 > | >

This is an "escaped" way of writing this character within an XML structure, meaning that XML won't mis-interpret it as trying to start a new XML node, so your code will be read correctly.
There are other possible solutions to prevent XML from seeing < as the start of an XML tag. Such as wrapping the code within CDATA.