You can mod the infotips this way:
https://github.com/jakobharder/anno1800-mod-loader/blob/main/doc/modloader11.md#patching-infotip-exportbin
You can extract the vanilla “data\infotips\export.bin” file with the FileDBReader (https://github.com/anno-mods/FileDBReader/releases) and the FileFormat “infotip.xml”: .\FileDBReader.exe decompress -i "FileFormats/infotip.xml" -f "tounpack/export.bin" -y
Alternatively I attached the extracted file in the modding discord channel here: https://discord.com/channels/578443209940926465/1146098268850376816/1149910673678159964
For valid text-embed commands (I mean these [Selection Object …] things you find in the file and texts), see the textsourcelist.json file from the game (unfortunately a bit outdated though..) or this huge list of textsource commands lua ENUMs while you can not directly use the wording from the link since it is lua form, see also textembeds )
Because of the structure of infotips code the ModOp Path we use to change something at a specific location needs to contain huge parts of the content of the InfoElement we want to mod. If another mod now changes the content (eg. Condition or Text) from an InfoElement, our ModOp may fail. It is still better to not use Conditions/AllowNoMatch to prevent the error in the logfile, because we want to get notified of incompatibilities this way in the logfile!
Using “add/AddNextSibling/AddPrevSibling” is usually not a compatibility problem, since the Path to vanilla code is not changed this way. But when you use merge/replace/remove for vanilla code, it is extremly likely to cause incompatibility with mods changing the same infotip (even if the change is for a different part of the infotip).
Most of the time infotip adjustments are made to support new mod-objects to be displayed in infotips. It is recommended to find a general solution for this, instead of hardcoding your own GUIDs into the infotips. For such general adjustments you should create a shared mod, so also other modders can use it. And to keep an overview about all existing general infotip adjustments, please also add your shared mod to the Community Patch mod: https://github.com/anno-mods/BugFixes/tree/main .
If your change is very specific to your mod and no other mod could need such a change or a general solution is not possible, then still do your infotip change in a seperate folder with its on modinfo.json. This way other modders can more easily disable your change later in case they do find a general solution for the problem.
Example for general solution: https://github.com/Serpens66/Anno-1800-SharedMods-for-Modders-/blob/main/shared_TT_ModPalaceMinistryHacienda/data/infotips/export.bin.xml
To write more general tooltips, you sometimes have to check if the object has a specific property or not.
The game itself indeed uses sth. like <Condition>[Selection Object Shipyard]</Condition>
to check if the object is a shipyard.
Unfortunately it is not that easy, because:
So that makes it quite difficult to create a condition “show X if it has the property and show Y if it does not have the property”.
Only workaround to this is to find other things to check. Eg. if you want to know if sth. is a ship you can check for Walking property. And an alternative to the check “has not Walking” might be “has Culture
property” (unfortunately we can not check for Building property, see textsourcelist.xml in CAsset what is available).
Beware: For things like Selection
this <Condition>[Selection Object Walking]</Condition>
works fine. But it does not work for <Condition>[MetaObjects SessionGameObject([RefOid]) Walking]</Condition>
unfortunately! This check will ALWAYS fail for ALL objects even if they have the Walking property! A solution for this is to check deeper values like BaseSpeedWithUpgrades
:<Condition>[MetaObjects SessionGameObject([RefOid]) Walking BaseSpeedWithUpgrades]</Condition>
which will properly work for objects which have the Walking property.
Infotips are called InfoTipData in the code and are adressed as usual by Guids. Infotips use a lot of numbers to express operations. By default all non-defined integer values are 0. We have to test and find out the meaning ourself. Here what we already found out (no guarantee that it is correct):
<Text>[AssetData(12345) Text]</Text>
the text from GUID 12345 can NOT use the Variables (eg. {ItemGuid}).[ItemAssetData([RefGuid]) InputAmountUpgradeProduct(#index0#)]
Text
is bold and uses bright color, uses wordwraps; Icon
is centered along the y axisText
is bold and uses bright color, uses wordwraps; Icon
is centered along the y axis; in addition to 1
there´s some empty space added below the text. Can use SubText, which can result in a bigger icon on the left and two lines of different text next to it.Text
+ (if needed) Value
both in bright color; uses wordwraps; does not display iconsIcon
, Text
and Value
; both in bright color; writes text in one line only, no matter how long it is. –> most universal type to useText
in dark-grey “background” text (can´t display Icon
and Value
)<Source>
on same level<Source>
only on sub-levelsText
is bold and written in one line only (no wordwraps); used for UI-buttons e.g. in the construction menu and within buildings. Can’t display icons.<ElementType>11</>
only (does not show anything on it self). Has <Source>
and <Columns>
on same level (Columns seems to be bugged, it always shows 2).Text
in medium-grey color (can´t display Icon
and Value
); used for action-descriptions (e.g. click on … to jump to …); does not adapt infotip size to text length!<Headline>
to show text.Text
in dark-grey “background” text (can´t display Icon
and Value
); does not adapt infotip size to text length!TemplateGUID
to display sth)To add a separator line (but they are as buggy as the vanilla lines below headers. Sometimes they are visible, sometimes not..)
<InfoElement>
<ElementType>6</ElementType>
<VisibilityElement>
<ElementType>
<ElementType>2</ElementType>
</ElementType>
<OperatorType />
</VisibilityElement>
<Text>
<Style />
</Text>
</InfoElement>