An open letter from the Kingdoms of Arda team, and the total-conversion mod community

[Dejan]

I have one question that will you release tools for edit data in xml files?
It is better to use an official tool to edit data with GUI.

Hello, could you please clarify which edit data/XML's you would like to edit in such fashion?

Hi Dejan & TaleWorlds, thanks for the meeting and the detailed plan.
In the meantime, is the [melee(forgeable) weapon import tool] on the modding tool's plan list?
We are asking this because it could take a lot of time to manually adjust the relative position of each weapon piece throguh related XML files, especially when we are handling hundreds of forgeable weapons.

There are currently no plans for such a tool but I'll bring it up as a suggestion.

 

[PekoBG]

It's great to see Taleworlds answering the open letter. It restores my faith in the game. Let us, fans, modders and developers work together to make Bannerlord the best game it can be. The potential is there, we just have to grab it and realize it.

 

[Dejan]

Hi Dejan & TaleWorlds, thanks for the meeting and the detailed plan.
In the meantime, is the [melee(forgeable) weapon import tool] on the modding tool's plan list?
We are asking this because it could take a lot of time to manually adjust the relative position of each weapon piece throguh related XML files, especially when we are handling hundreds of forgeable weapons.

Hey, could you please clarify whether your inquiry is related to making crafted weapons faster or importing new pieces to the game faster?

 

[La Grandmaster]

@Dejan, any information if modders will ever have access to shader files (the ability to edit existing ones and add new ones)? Currently this is not possible. This was possible in warband so interested if it would be in bannerlord. These allows modders to make their mods look completely unique, and attract more interest in the game

 

[Bakura]

Hey, could you please clarify whether your inquiry is related to making crafted weapons faster or importing new pieces to the game faster?

Hi Dejan, thank you for the follow-up. Sorry for the late reply, had a discussion with the team members to avoid any redundant questions.

The main obstacle for us currently is low efficiency when adjusting the position of each weapon in the game:

• 
• Related XML file: crafting_pieces.XML
  • Related data fields: item_holster_pos_shift under the CraftingPiece node.
  • Related data fields: piece_offset under the BuildData node.
• What we are doing now for the position calibration of weapons in the game (when equipped by a character) is:
  • Modify the position data above in the XML file.
  • Then we launch the game, load a save and check the position of the weapon in the game.
    • If the position of the weapon does not fit our target position, we quit the game, then:
      • re-modify the position data in the XML file.
      • Then we re-launch the game and do the check.
      • Loop this process until we finally get the wanted visual result for the position of the weapon.

Things are becoming really time-consuming when the total amount of weapons increases.
So we are wondering is there any suggestion or a better workflow that could make [adjust weapon position in the game] faster? Or an official weapon import tool is already there and only wait for a public release?

 

[bonerstorm]

I just want to bump this thread because I just got back after nearly a year since this game first disappointed me and... I'm somehow even more disappointed.

Not only has practically none of the stuff I care about been addressed by the devs, most of the mods that made this game playable have been abandoned by their original modders and only some of those have had volunteers come up to take their place updating the lapsed mods.

The fact alone that the Community Patch, in particular is dead in the water bodes extremely ill for MB2's future.

This whole game feels like a sinking ship and the devs have basically communicated that they DGAF what fans think about anything they've done. This whole EA cycle has been a miserable failure.

 

[svelok]

The fact alone that the Community Patch, in particular is dead in the water bodes extremely ill for MB2's future.

Community patch is dead because all the perks it patched got overhauled and fixed properly, though.

 

[bonerstorm]

Community patch is dead because all the perks it patched got overhauled and fixed properly, though.

*doubt*

I am severely skeptical that a game so as bug-infested as MB2 couldn't benefit from a Community Patch in general.

 

[Eärendil Ardamírë]

I am severely skeptical that a game so as bug-infested as MB2 couldn't benefit from a Community Patch in general.

Feel free to work on one then.

 

[bonerstorm]

Feel free to work on one then.

Isn't the entire point of this thread the fact that at no point in the past year have TW given a thought to mod support, despite it being the key to WB's sucess?

How do you patch bugs with the "internal" flag shotgunned haphazardly throughout the offending code?

You might as well be saying "Go make your own Bannerlord". Nope. That's what giving my money to TW was supposed to do.

 

[Eärendil Ardamírë]

Isn't the entire point of this thread the fact that at no point in the past year have TW given a thought to mod support, despite it being the key to WB's sucess?

If they wouldn't have given any thought about mod support, there would be no mod tools out at all.

No matter how much mod support TW would have given, some mods would have died within the first year. They are dying due to their developer having less time than when starting due to other priorities, they are dying to updates breaking the mod compatibility. And updates would have broken nearly all mods, no matter how big the mod support of TW would have gone.

And as guys pointed out at both threads at which you copy pasted your comment, the initial goal of that mod was fullfilled by being fixed by TW. There are other community patches around, they are just not called "Community Patch". You need to go out and find the ones which fill your needs or go and work yourself at one.

 

[Shun]

How are developments in the mod-support realms? Did anything come of this letter? I loved WB's mods, would love to see BL's scene flourish to its fullest potential.

 

[CrazyElf]

If they wouldn't have given any thought about mod support, there would be no mod tools out at all.

No matter how much mod support TW would have given, some mods would have died within the first year. They are dying due to their developer having less time than when starting due to other priorities, they are dying to updates breaking the mod compatibility. And updates would have broken nearly all mods, no matter how big the mod support of TW would have gone.

And as guys pointed out at both threads at which you copy pasted your comment, the initial goal of that mod was fullfilled by being fixed by TW. There are other community patches around, they are just not called "Community Patch". You need to go out and find the ones which fill your needs or go and work yourself at one.

I agree on this, but with one caveat - large mods like Kingdoms of Arda which wrote the letter are likely to remain.

 

[Eärendil Ardamírë]

I agree on this, but with one caveat - large mods like Kingdoms of Arda which wrote the letter are likely to remain.

Large mods have a higher likelihood to remain, yes. Working at a large mod is however no guarantee to remain, but we all hope that they will manage it.

 

[Jance]

Hello creators! First of all, thank you for writing this open letter and bringing it to our attention.

Last week, we went ahead with a meeting to discuss the concerns raised in the open letter, along with a collection of other pressing modding-related issues that we gathered via feedback.

As you might imagine, some of these topics are pretty big and in many cases, it is going to take some time to implement solutions, but we have already started taking steps towards resolving the issues and wanted to share this with you.

To start, we have decided to hold regular modding meetings to discuss feedback and other modding-related topics from the forums and Discord to ensure that issues like these aren’t allowed to fester.

In addition to this, we think that providing clearer warnings and assertions for the tools should help to point you in the right direction when trying to diagnose an issue, or at the very least, provide you with useful information to include when requesting support from us. We’ll be adding them within the next few patches.

So, with the more general things out of the way, let’s move on to the core topics we discussed at the meeting:

• Custom Campaign Maps

We have identified a number of bugs with modifying and creating new campaign maps and will be looking into fixing them. We have also discussed a couple of potential solutions that we will be exploring to enable modifying of the MapWidth and MapHeight for the walkable area and camera. Ultimately, the message we want to convey here is that this certainly isn’t intended and that you will be able to add custom campaign maps when we have decided which path to take and implemented that solution.

• Custom Skeletons & Body Meshes

We’ll be adding a system in the future to allow you to change faces, hand meshes, and body meshes, as well as, a system to add new skeletons to the game. Please bear in mind that you will likely have certain limitations when adding new skeletons for agents capable of combat in order for the native combat system to work properly.

• Code-related documentation

We hope to start providing a reference for the API. In addition to this, we will be reaching out to collect specific requests for documentation to be brought to our developers for review and extend our efforts to make more documentation, similar to this explanation regarding Sealed Class Extension. We encourage you to request specific documentation in our updated forum section for Official Tools & Modding Feedback.

• Hard-coded behaviour

In this case, we feel that the best approach would be for us to know specifically what you are trying to achieve so that we can find an appropriate solution. Please let us know which specific problems you’re facing here. With that being said, we will be doing a review of our code to see if there are places where we might have used “internal”, or any other modifiers, unnecessarily.

In addition to the topics from the open letter, we identified the following points that we will be going over in the dedicated modding meetings to find solutions.

• Total conversion mod load order
• Enable Cloth Physics on CraftedItems
• Allow attributes on Items to determine weapon damage
• Extrude function for AI meshing
• Subdivide function for AI meshing (into quads not tris)
• Allow single axis scaling of assets before placement
• Ability to name a new paint layer upon creation
• Mesh keyframes documentation
• Documentation for skeletons for reins/horse harness and their implementation
• Documentation on implementation of custom quivers
• Add a duplicate mesh option
• Add attribute to hide head (xml)
• Ability to disable the usage of generated widget code

As we have said previously and will say again, modding is a huge part of Mount & Blade and we will do what we can to work alongside modders to help you fulfill your modding ambitions. However, we do want to be clear now that there will be some instances where we will be in disagreement about how a problem can, or should, be resolved. Moving forward, we ask that modders include more details about what they are trying to achieve when making suggestions, requesting support, or leaving feedback, rather than just suggesting a solution to their issue on its own. This will help us a great deal when exploring potential solutions, some of which may already be present. It would also be helpful if everyone could share future feedback and suggestions in the Official Tools & Modding Feedback section of the forum to ensure that your comments are processed correctly.

Hey @Dejan, thanks for the reply (life's been real busy for the last month and I didn't see it, my apologies!).

All the issues you itemized are very important to us, and I'm glad we were able to communicate them to you effectively.

As for the internal keyword- there are several hundred (possibly thousands) of usages of it scattered throughout Bannerlord's code, and frankly no one wants to make a forum post every time a system is guarded/impossible to modify because of it. I'm just a coder- I want to spend my time writing code, not dumping tons of precious time and energy (that I could be using to work on my mod) petitioning for you guys to fix your game.

Please correct me if I'm wrong, but what I've been told by other Taleworlds developers is that the purpose of the internal keyword is to "enforce mod compatibility". I don't know whom at Taleworlds is convincing everyone that making critical/frequently used methods and classes inaccessible will magically make mods be compatible with each other, but they are incorrect. An example of this: if you have 2 very simple mods that change the price of butter to different values, only the changes of one of those mods (the one that executes and changes the price last) will be reflected. Like I've said before, this could be remedied by simply replacing the word "internal" throughout the code, and would have literally no effect on how the code functions other than allowing us to reference/change it. I don't know of a single other game/studio that claims to support moddability, then purposely hamstrings the ability for those modders to make their mods (typically, they do the opposite). Until then, we're basically trying to write a book with only access to half of the alphabet.

Even with the insane overusage of "internal", our mod (and most mods that do anything mildly complicated) will almost certainly be incompatible with each other unless the mod developer takes great care to program their mod with compatibility in mind.

I think it would be a good idea for us to schedule a meeting between modders and Taleworld's engineers to discuss this further so we can reach common ground and find a solution that works for everyone. My discord username is Jance#8633 and you can find me in the official modding discord (I check that far more frequently than the forums).

 

[Dejan]

Hey @Dejan, thanks for the reply (life's been real busy for the last month and I didn't see it, my apologies!).

All the issues you itemized are very important to us, and I'm glad we were able to communicate them to you effectively.

As for the internal keyword- there are several hundred (possibly thousands) of usages of it scattered throughout Bannerlord's code, and frankly no one wants to make a forum post every time a system is guarded/impossible to modify because of it. I'm just a coder- I want to spend my time writing code, not dumping tons of precious time and energy (that I could be using to work on my mod) petitioning for you guys to fix your game.

Please correct me if I'm wrong, but what I've been told by other Taleworlds developers is that the purpose of the internal keyword is to "enforce mod compatibility". I don't know whom at Taleworlds is convincing everyone that making critical/frequently used methods and classes inaccessible will magically make mods be compatible with each other, but they are incorrect. An example of this: if you have 2 very simple mods that change the price of butter to different values, only the changes of one of those mods (the one that executes and changes the price last) will be reflected. Like I've said before, this could be remedied by simply replacing the word "internal" throughout the code, and would have literally no effect on how the code functions other than allowing us to reference/change it. I don't know of a single other game/studio that claims to support moddability, then purposely hamstrings the ability for those modders to make their mods (typically, they do the opposite). Until then, we're basically trying to write a book with only access to half of the alphabet.

Even with the insane overusage of "internal", our mod (and most mods that do anything mildly complicated) will almost certainly be incompatible with each other unless the mod developer takes great care to program their mod with compatibility in mind.

I think it would be a good idea for us to schedule a meeting between modders and Taleworld's engineers to discuss this further so we can reach common ground and find a solution that works for everyone. My discord username is Jance#8633 and you can find me in the official modding discord (I check that far more frequently than the forums).

We have gone over the usage of the "internal" keyword, the changes of which are coming with e1.6.0. We can discuss this further after you've seen the changes.

 

[Jance]

We have gone over the usage of the "internal" keyword, the changes of which are coming with e1.6.0. We can discuss this further after you've seen the changes.

Wow, fantastic! I went ahead and shared this news with the rest of the total conversion mod teams. I'm VERY excited for 1.6 now

 

[MadVader]

We have gone over the usage of the "internal" keyword, the changes of which are coming with e1.6.0. We can discuss this further after you've seen the changes.

Did you remove all "internal" keywords or only the vast (I mean VAST) majority of cases? Would 1.6 come out in the near future or soon?
(These are rhetorical TW meme questions, but feel free to answer seriously if you wish, particularly the "1.6 when" question.)

 

[order_without_power]

Great! Now when can we change certain areas of individual agent AI which is hardcoded in the C++ engine?

 

[dijiTurk]