Issue with territory management

[Heresa]

Hello guys,

I have recently started to create a mod for 0ad in order to remove territory restrictions. The first attempt has been quickly achieved since I simply edited "simulation/data/territory_manager.xml" and some building templates to avoid decay.

Now, I would like to add an extra checkbox in the gameplay setting interface that would allow the user to disable/enable territories, before launching a game. That means getting rid of the xml overriding and, instead, relying on some dynamic logic (preferably JS).

Adding the checkbox in the gui was easy. However I'm a bit stuck with dynamically setting parameters such as "BorderThickness" and "BuildRestrictions\Territory". My first attempt was to access and update "IDD_TerritoryManager" from "simulation/helpers/Setup.js" but I couldn't find the right methods to invoke.

With the intention of being aware of the public variables and methods exposed by "IDD_TerritoryManager", I have consulted the description of its implementation class, i.e. "CCmpTerritoryManager" but I had the unpleasant surprise to note that no setters were provided and the instruction :

CParamNode::LoadXML(externalParamNode, L"simulation/data/territorymanager.xml", "territorymanager");

lets appear a hardcoded relative path which prevents me to select another XML file according to the checkbox value (ex "simulation/data/territorymanager_relaxed.xml".

Do you known how I can bring such an option without altering the c++ codebase ?

PS : This is an example of what I have tried in the "Setup.js" file :

if(!settings.EnableTerritory) {    var cmpTerritoryManager = Engine.QueryInterface(SYSTEM_ENTITY, IID_TerritoryManager);    if (cmpTerritoryManager)    {      cmpTerritoryManager.m_ImpassableCost = 0; //public in impl class but no setters in interface      cmpTerritoryManager.m_BorderThickness = 0.0;      cmpTerritoryManager.m_BorderSeparation = 0.0;     }}

Edited October 25, 2015 by Heresa

[niektb]

Have you tried modifying TerritoryDecay.js in simulation/components?

Seems to me like if you modify TerritoryDecay.prototype.IsConnected() with some if statement that returns true.

edit: probably you need to modify BuildRestrictions.js too.

Edited October 25, 2015 by niektb

[leper]

However I'm a bit stuck with dynamically setting parameters such as "BorderThickness" and "BuildRestrictions\Territory". My first attempt was to access and update "IDD_TerritoryManager" from "simulation/helpers/Setup.js" but I couldn't find the right methods to invoke.

That just changes the display of the territory, while I think you'd have less issues by not calculating territory at all.

You also shouldn't update interfaces (or rather the components implementing them dynamically. Interfaces are mostly there to allow multiple components to provide the same interface for other components to work with, not to dynamically switch between different implementations. Switching between implementations given that they provide the exact same interface and you only want one of them is however possible if you make that change in a mod where you just provide your modified version of the component and that is the only one used.

With the intention of being aware of the public variables and methods exposed by "IDD_TerritoryManager", I have consulted the description of its implementation class, i.e. "CCmpTerritoryManager" but I had the unpleasant surprise to note that no setters were provided and the instruction :

CParamNode::LoadXML(externalParamNode, L"simulation/data/territorymanager.xml", "territorymanager");

lets appear a hardcoded relative path which prevents me to select another XML file according to the checkbox value (ex "simulation/data/territorymanager_relaxed.xml".

Do you known how I can bring such an option without altering the c++ codebase ?

Could be possible, but a simple change to CCmpTerritoryManager to store whether it is enabled and should actually do something would make this a lot easier.

Doing so in a mod would be easy, but I guess this is meant for inclusion in the game at some point and thus using another way would be nicer.

Now for how to solve this nicely:

You should add a boolean to CCmpTerritoryManager whether or not to calculate territories at all, then return early in most functions, Or simply not subscribing to some messages. I'd suggest storing whether to use territories for a player (since that might be wanted by some) in cmpPlayer and using that and the enabled flag of cmpTerritoryManager in cmpBuildRestrictions to decide whether or not to check territories. IsConnected in cmpTerritoryDecay could need some small modification too.

This way we would also support some civs (where we can remove the territory related xml parts) without territory while others have it.

[Heresa]

Have you tried modifying TerritoryDecay.js in simulation/components?

Seems to me like if you modify TerritoryDecay.prototype.IsConnected() with some if statement that returns true.

edit: probably you need to modify BuildRestrictions.js too.

Yes, it's exactly what I need to do. As explained by "leper", some modifications regarding display are however required and may be performed at the terrority manager level (CCmpTerritoryManager)

.
Could be possible, but a simple change to CCmpTerritoryManager to store whether it is enabled and should actually do something would make this a lot easier.

Doing so in a mod would be easy, but I guess this is meant for inclusion in the game at some point and thus using another way would be nicer.

Now for how to solve this nicely:
You should add a boolean to CCmpTerritoryManager whether or not to calculate territories at all, then return early in most functions, Or simply not subscribing to some messages. I'd suggest storing whether to use territories for a player (since that might be wanted by some) in cmpPlayer and using that and the enabled flag of cmpTerritoryManager in cmpBuildRestrictions to decide whether or not to check territories. IsConnected in cmpTerritoryDecay could need some small modification too.

Thank you for the hints. When you say it's would be easy in a mod, does that mean I can modify CCmpTerritoryManager without adding the boolean variable in the C++ class ? It surprises me a bit but since I'm new, I may have missed some JS scripts focused on rendering.

[leper]

No, you can't modify the TerritoryManager in a mod. You can however supply your own territorymanager.xml file, and also provide your own versions of the related JS components.

[Heresa]

gosh, it's exactly what I was afraid of and since I cannot conditionally select a version of "territorymanager.xml", the borders will always be visible (or invisible according to the single living version of this file).

Edited October 25, 2015 by Heresa

[leper]

Yes, but that is still trying to work around territories by just hiding territories, not fixing the root cause. So some small modifications to CCmpTerritoryManager should be all of the C++ changes that are needed.

[Heresa]

Since I'm have some knowledges in C++, I may apply these changes in the SVN (Git ?) trunk but I guess it's not a priority for Alpha 19 and a beginner shouldn't dig into these core components, especially as a first task.

[Lion.Kanzen]

Try start you own repo with the changes, can be used as mod for now. Later can be a patch as option to have an arcade mode by vanilla or a mod.

[leper]

Well you seem to have found your way around quite well as your first post indicates, and in case you have questions you can also join #0ad-dev on QuakeNet. So I guess it might not be the smallest first task, but it still is somewhat self-contained.

[jx99]

I am very interested in a 0ad Mod to remove territory restrictions. Were you able to create this mod?