Guide: The Complete Guide to Plugins

[SigniferOne]

To me it is unconscionable that such an original discovery has gone unnoticed in the RTW subforum for so long. I am reposting it for MTW2 here:

From:

Click the Green arrow

Guide: The Complete Guide to Plugins

The plug-ins system is legacy from early in development. The code is still there to allow you to specify building plug-ins, but there is no display for them in the game anymore, which means that you cannot see wether any are built, build new ones through the UI, or look at any descriptions on the campaign map. Certainly the AI won't build them if you were to add some to the game... Best to just stick to buildings and upgrades, really

Up until now, this quote from Jerome was taken as gospel, plugins are legacy code and do not work. I didn't quite buy this because there's a lot about plugins that he doesn't say cannot be done. He says you can add the code to specify them, he doesn't say they can't be built, just you can't build them through the UI. It seems no one wanted to look into what actually could be done with the plugin system. The answer is lots.

I originally started figuring our what could be done with plugins while trying to figure out how I could tweak the core_building tree. This fell by the way side as other projects and priorities came up. Then Gotthard joined the RS team and he asked what appeared to be an innocent question about plugins as we were discussing what we were discovering by exploring the .exe files, and my previous work suddenly jumped out at me. Between the two of us the following is what we have so far discovered, and I'm pretty sure there will be more, how much who knows but we'll see.

Plugins in EDB

First if you are unfamiliar with the EDB (export_descr_buildings.txt), I suggest you read the Guide: The Completed Guide to EDB written by Dol Guldur.

To attach a plugin to a building you need to add the correct code to the plugin sections of the building you want the plugin associated with.

    plugins 
    {
    }

Code similar to this is what you find at the end of every building tree. The following code is what you'd add the enable a 1 level bowyer plugin.

    plugins bowyer
    {
        bowyer
        {
                levels bowyer
                {
                        bowyer requires factions { roman, }
                        {
                                building_min practice_field
                                construction  2 
                                cost  2500 
                                settlement_min village
                                upgrades
                                {
                                }
                        }
                }
        }
    }

On the plugins line is the list of plugins associated with the building tree. After that each plugin is specified like a building, with two key differences, there's no capability section, and there's the new building_min line. The building_min line specifies what level of the corresponding building is required to be able to build that level of the plugin.

Plugins in export_buildings.txt

Similar to buildings, it appears you need the same text extries for each plugin and plugin level. Each plugin needs a _name entry and each level needs its three entries. An errorless CTD results if any of these are missing.

{bowyer_name}
Bowyer

{bowyer}    Bowyer

{bowyer_desc}
WARNING! This baseline description should never appear on screen!

{bowyer_desc_short}
WARNING! This baseline short description should never appear on screen!

Plugins in descr_stat.txt

The key to being able to use plugins is getting them into the game, to add a plugin to a building you'll use code like the following:

    building
    {
        type missiles practice_field
        plugin bowyer bowyer
    }

Plugins and Scripts:

The create_building console command can be extended to place a plugin into a settlement using the following sytax:

console_command create_building practice_field bowyer

This will add a practice_field with a bowyer plugin to the settlement.

Plugins and Conditions:

GovernorPlugInExists works as expected
GovernorPlugInFinished hasn't been tested for functionality yet (I'm not sure if building with a console command would trigger this condition or not)

Known factors:

• Upgrading a building with a plugin does not destroy the plugin
• 9 plugins per building tree
• 9 levels per plugin

Uses:

• Can be used to store/pass additional information about settlements/regions to other files such as traits/ancillaries (e.g. every region with iron gets an iron plugin, etc to pass information about resources/hidden resources).
• Simplify tests to determine where on the map the character is (e.g. if you want to know if a character is in greece you create a greece plugin and add it to all settlements in greece in descr_stat)
• Dramatically increases the trait customization that can be done (use to add traits based on control, after x turns of control remove the original cultural plugin and replace with a new one for the new faction)
• Others I'm sure that will be though of

Unknowns:

• As yet unknown how to link building capabilities and/or construction to presence of a plugin, if this is discovered the number of uses drastically increases, even if building through the UI can't be enabled (e.g. extra virtually unlimited hidden_resources, used for reform type script events, etc)
• Can a building have more than one plugin

[Rorarii]

Thanks .. so many great new tools and tutorials, M2TW being opened up .. not enough time .. or brain cells to keep track!

R

[alhoon]

I don't quite understand what the plugins do. Could you give a better example on what can be done with them and how?
Not with the traits, with the plugins. For example, the iron plugin should be added by hand or the game puts one?

[SigniferOne]

The uses for this are pretty advanced, not a simple thing like an extra button that does something graphically pretty. You could store variables about each region, within its core_building. There are other uses listed in the opening post. I think the ideas is just really cool in general.

[gracul]

I cannot really think of many uses for plugins, except for the trait/ancilliary 'simplification'. Its not like they unlock something that was previously not accessible, since it seems you cannot control building options with plugins. Not only the core_building could be a good place to put the plugins. Roads or farms could be also used to store plugins without the possibility of them getting destroyed.
However if its possible to somehow control building/unit construction with plugins, then i can think of a lot of possibilities.

[SigniferOne]

You can control construction with plugins, as far as I know:

instead of "practice_field" as your requirement, you'd specify "practice_field bowyer"

[gracul]

It doesn't seem to work for me, atleast it doesn't work with building_present_min_level. Or with SettlementBuildingExists or FactionBuildingExists.

[SigniferOne]

No, you would use GovernorPluginExists (see opening post).

[il_duce_!]

great find.

+rep

[gracul]

However thats not something you could not have done with the use of hidden_resources.
That means that plugins have no real 'special' use, special meaning something which was previously inaccessible can be done with them.

Or maybe someone already thought of some nice way to use plugins.

[Squid]

You may want to re-read my guide a little closer.

Plugins are the only way for traits/ancillaries to have access to resource/hidden resource information about a region, as there is no other way through conditions to check for them, therefore for that reason alone, plugins have a special purpose. Aside from that is makes coding various trait/ancillary ideas significantly easier to code.

For example, say you wanted to code that characters acquire a particular trait in any of 10 regions, without plugins each region would need a trigger, and if you later decide to change which/how many regions the trait can be acquired in it takes a lot of changing of triggers. With plugins you need a single trigger and changing which regions can acquire the trait is a minor change in descr_strat.

[gracul]

Plugins can serve the same purpose as hidden_resources, but in no way they have any access to information about the hidden_resources, or resources of a settlement.
Earlier i agreed that yes plugins can simplify some trait/ancillary triggers, i am quite aware of this. Not only a plugin could be acquired in only 10 regions with just one trigger, you could also make dynamic changes to where you could acquire it with the use of the campaign script and console_command construct_building, without the need of tons of conditions on your trigger. However its not like i can code a priest to acquire a particular trait in any of 10 regions with the use of plugins... and i don't think re-reading your guide will give me any clue about how to do that.

Plugins are a very nice find, don't think im against them, but with the restriction to only GovernorPluginExists its hard to do much with them. Ive spent some time testing them with most of the campaign scripts conditions, and only that one worked. Plugins could be very powerful and make the life of a modder a lot easier if CA wouldn't just scrap them .

[alhoon]

Can city plugins be converted to castle plugins?

I.e if I put a plugin (i.e "Greek") in the Core building of a city, can I make a similar one (i.e "c_Greek") for castle core buildings and use the convert_to_castle in the plugin or building?

Plugins and Scripts:

The create_building console command can be extended to place a plugin into a settlement using the following sytax:

console_command construct_building practice_field bowyer

This will add a practice_field with a bowyer plugin to the settlement.

Does this work on existing buildings too, or you have to destroy the building first and construct it with the plugin later?

[SigniferOne]

If you convert the city Core to the castle one, then the castle one will be in effect.

[SigniferOne]

What new use have you found for plugins Alhoon? Please remember to always share with the community.

[Augustus Lucifer]

81 plug-ins per building tree, is that what I'm reading? With 128 trees that means over 10,000 plug-ins. Just seems like an unreasonably high amount for a hardcap in current iterations of CA games. Has Squid or anyone else used them extensively enough to see if they interfere with the building tree cap or anything else of that nature?

Have always been intrigued by the plug-in system, would love to see examples of in-game uses by others if there are any. I haven't had reason to store things in plug-ins at this juncture, but I certainly will with time I'm sure. I know at least that I've pondered before storing the region name in plug-ins, seems like a viable application at least.

[Squid]

Yes, 81 distinct plugin levels per building tree; however we never added in enough plugins to determine if there was some overall cap to the number of plugins/plugin levels that can be used.

[wudang_clown]

Okay, has anyone made some discoveries regarding plugins?

In particular: what is the purpose of #generic_plugin1.tga in vanilla\data\ui\generic? Is there any way to make a plugin to appear via UI?

[Squid]

Okay, has anyone made some discoveries regarding plugins?

In particular: what is the purpose of #generic_plugin1.tga in vanilla\data\ui\generic? Is there any way to make a plugin to appear via UI?

What you see here is what was discovered. There is no way to make plugins appear via the UI and the image is just the image that would have been used probably as a place holder, presumably like building pictures you'll run into problems if your plugin does not have the corresponding ui pictures present.

[wudang_clown]

Thank you for reply!