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

Users who are viewing this thread

momo1 said:
What do you mean by misused?
To provide an example, Hero_OnAddedToParty is internal because it should only be called when a hero is added to a TroopRoster. Hero_OnAddedToParty is not meant to be called by any other place than a TroopRoster and directly calling it may not update all the game variables correctly; creating an unstable state.

Edith - unintentional smileys are best smileys.
Access modifiers are not added because of modders. It's done as part of our work and for our work.
I understood this that the reason they don't want to change all of the access modifiers, is because it prevents them from making changes in the game that would cause it to become unstable.
 
Access modifiers such as internal and private are a code design choice to enforce good practices and ensure that specialized parts are not misused. They are a part of our software engineering work and not there to enforce / enable mod compatibility.
We know what they are. We know that they are not there to enable mod compatibility. That was the whole idea. We are not claiming that this is the best thing to do but it's blocking the modders in certain areas. And after 2.5 months, we get "Eh we added more because of consistency ¯\_(ツ)_/¯" - so I'm guessing you didn't realize that you had a messy codebase that wasn't following any principle or whatsoever until a modder comes up and writes you an open letter?
Also using internal for whatever the example you gave above is not explaining the situation. If your intention is to keep your own engineers in line, you can use private - because the behavior you described fits to that. Internal means it's purposely limited to use outside of that assembly. Which means "We don't want anyone but us to reach or use this". I'm not even going into internal classes or nested classes inside them etc.
Indeed, there are already rather complex mods available to players.
I don't want to be rude to you Duh but we all know what TW thinks about the complexity :lol:
We won't drop the conventions that are important to our work,
Conventions that you realized after 1 year of EA + 8 years. Now that's what I call commitment.
At this point, the best approach would be to go with what Dejan said
This is a horrible approach. What are the guys expecting actually? Some modder to create a thread for a single class and then wait another 2 months? And another do the same etc? Do you really think this is feasible?

Look Duh, I appreciate that you are taking your free time and replying in here. I'm most certainly not supporting any idea that might break the process. And you can see that in my first posts in here too. However, I personally don't see any honesty in either of these statements. You won't admit it but I can voice that out for you, Bannerlord codebase is a mess. What is asked in that letter making it less messy? No. But it's making it less messy for the modders. And changing Internals is the simplest thing you could do in short time. Yet you as a company refused to do that (again for some wise-asses, I'm aware of the fact that it's a bad practice, but bad practice ship for TW's codebase is already sailed with a really huge load of cargo) And refusing this and even adding new ones doesn't make any sense for that letter context.

Currently what you are saying is conventions > modders. And that's also fine, as long as TW be transparent about it. By transparent, I mean TW should stop saying PR sentences like "We support modding" because it's not on the priority list even when it comes to change something simple as access modifiers.
But no you want to support modding? You have to compromise. You can't make a product with perfect OOP principles right before its release - because the current state of the product is far from perfect already and if you decide to fix that architecture and all other sides, good luck with spending another 2 years in EA. It's really funny that after 2,5 months, you stated that you did something opposite of what has been asked and you even set date for this "changes" to really TW style Soon again. Because we don't know when 1.6.0 gonna hit the release branch - most likely another 2 months since we still didn't see 1.5.10 in a release. And literally, 0 documentation/line or whatsoever shared with people in that timeframe. If you had internal documentation, it wouldn't be rocket science to shape in a way that it can be seen in public space. Anyway, I'm not here to teach you coding. I'm also aware of the fact, after that many years and revisions, codebases can become a ****storm. That's the nature of coding, especially if you don't have proper guidelines/documentation and vision. This is exactly the case in Bannerlord.

Also, can I get an explanation for why this is rejected? https://forums.taleworlds.com/index...pen-source-fork-of-module-source-code.441156/
Since it's just related to "your conventions" this shouldn't cause any issue. And I'm sure that your in-code comments would also help people to understand the scope of the methods/classes.
 
Thanks for linking this! I'll check it out.

I just wanted to take a moment to say that I've been conducting a thread archaeology expedition into the TW forum salt mines and that I've really appreciated the many comments you've made over the years. IIRC you've always been spot-on and helpful.
I agree with this, but the people representing the modding community here aren't the ones being toxic :smile:
Accurate. White knights are almost always the first to start a flamewar and usually get BTFO'ed in short order by fans dropping facts. It's kind of a funny scenario... I've never seen a forum so overwhelmed by negativity for the game from long-timers getting flamed by casuals for making complaints. It's a perversion the natural order.

Also, the white knights almost always melt away while the redpills and blackpills remain. @Phantom425 joined the forum last night but does anyone doubt that they'll still be here in a month or two?
 
I kind of would've liked to see if TW would've been way more humble if Bannerlord had a rough release.
Anyhow, if modders leave there's no future for Bannerlord at all.
 
Well then, what happens now? If we're supposed to be so patient, courteous, and hopeful with TW, then what is the protocol? What even is a sensible, realistic outlook and hope with that approach, and how would that be any different than the last two years? Does TW even have the slightest desire to listen to their community at all outside of the few developers that reply? Will this severely hamstring the modding scene, or is the impact of these modifiers being exaggerated? It sure doesn't sound exaggerated. If TW can't meet the requests of the modders then this game is dead. It is the only thing that will save this game, and probably the sole reason I have any desire to play the game again one day.
 
Well then, what happens now? If we're supposed to be so patient, courteous, and hopeful with TW, then what is the protocol? What even is a sensible, realistic outlook and hope with that approach, and how would that be any different than the last two years? Does TW even have the slightest desire to listen to their community at all outside of the few developers that reply? Will this severely hamstring the modding scene, or is the impact of these modifiers being exaggerated? It sure doesn't sound exaggerated. If TW can't meet the requests of the modders then this game is dead. It is the only thing that will save this game, and probably the sole reason I have any desire to play the game again one day.
The only thing that can be done at this point, as stated by the devs, is wait for the update to roll around. We cannot judge what has happened until it actually happens.
 
The only thing that can be done at this point, as stated by the devs, is wait for the update to roll around. We cannot judge what has happened until it actually happens.
They said they are not removing the blockers and will continue to use the same methods. Not sure what is left to glean here. The best mod for BL has just shutdown, I don't think this is real great news.
 
And what if the judgment is precisely correct?
Then continue to work with the devs as they have stated that they are open to further communication on the subject following the update. As Dejan said before, they are willing to continue to work with modders on what their opinion will be on the direction this update takes the game and accessibility for modding.
They said they are not removing the blockers and will continue to use the same methods. Not sure what is left to glean here. The best mod for BL has just shutdown, I don't think this is real great news.
From what they have said, they are adding and removing some in order to make things more consistent. We can only work with what TW gives us, and for that we will have to wait until the 1.6.0 update. Until then, guessing what will be added and what will be removed will not be productive. As for the best mod being shut down, that is entirely Bloc's own decision. While this is tragic, nothing can be done about it. And, to be frank, that is one of the three concrete pieces of information to come from this scenario: one being the discontinuation of the Freelancer mod and any other mods made by Bloc, two being that in the 1.6.0 update some blockers will be added and some will be removed to increase consistensy, and thirdly that TW is well aware of this issue and will continue to work on it.

Any further discussion about this is quite frankly pointless, and I don't want to partake in it on this forum any further, as at this point this is nearing the definition of insanity for me at least in terms of making my points. All that we can do is wait until the 1.6.0 update, and then see what happens.
 
Then continue to work with the devs as they have stated that they are open to further communication on the subject following the update. As Dejan said before, they are willing to continue to work with modders on what their opinion will be on the direction this update takes the game and accessibility for modding.

From what they have said, they are adding and removing some in order to make things more consistent. We can only work with what TW gives us, and for that we will have to wait until the 1.6.0 update. Until then, guessing what will be added and what will be removed will not be productive. As for the best mod being shut down, that is entirely Bloc's own decision. While this is tragic, nothing can be done about it. And, to be frank, that is one of the three concrete pieces of information to come from this scenario: one being the discontinuation of the Freelancer mod and any other mods made by Bloc, two being that in the 1.6.0 update some blockers will be added and some will be removed to increase consistensy, and thirdly that TW is well aware of this issue and will continue to work on it.

Any further discussion about this is quite frankly pointless, and I don't want to partake in it on this forum any further, as at this point this is nearing the definition of insanity for me at least in terms of making my points. All that we can do is wait until the 1.6.0 update, and then see what happens.
I hope not to drive you crazy with one more point: If you have 5 cones blocking the road you are on, and three are removed, and 3 are put back you still are gonna be late for work.
 
Access modifiers such as internal and private are a code design choice to enforce good practices and ensure that specialized parts are not misused. They are a part of our software engineering work and not there to enforce / enable mod compatibility.
Dear Duh, with all due respect let me say the following.

The main goal of software engineering is to fulfill certain needs (and solving problems is one), not following a coding convention. If you're at a point where your practice hinders that main goal, you should bend it a little, at least temporarily. After all, conventions are just guidelines. They're not mandatory.

Access modifiers happen to be a minor part of a coding practice that it's safe to break the conventions on them. It's not even an architectural design choice, or something that would affect the way functions function. It's just a guiding flag, and a decent programmer wouldn't even need it to know whether or not something is supposed to be used outside or not. They will read the code or its comments, and know.

Your product will be valued first by its functionalities, not how pretty and neat the code base is. You're already over a year in Early Access, and the product is already out. People are already using it, and modders are already working. Time is ticking away, and so does people's patience. It should be in your main interest to get the game's features to function as is should as soon as possible. You can tidy up your codebase later, with post-release patches with notes telling modders if there's any changes they need to pay attention to. You will have all the time in the world for that.
 
You are simply expecting too much and most of you seem to be just incapable of learning from the past. TaleWorlds stated that the game will be more moddable than Warband but "more moddable" does not mean that everything will be moddable. I am not sure how you could expect that they are removing all internal modifiers, you must have been daydreaming. Yes, it would be nice if they would explain their decission about why they don't do such but as told multiple times before, communication about decission processes have not been their strenght in the past ten years. There is also no financial gain to remove them all at once and all at the beginning. Look again at the past, to Warband. The Warband Engine developed nearly only when some DLC was about to be released. Modders (the scripters that is) got only access to new operations at such occasions, nearly never on request even when it was easily feasible. And now you have a game which is even just in Early Access and you already expect the full moddability? How are they supposed to earn money if not by DLCs, at whose release they also increase the moddability of the main game, to keep some features for DLC purposes? There are not many other options, in-game shops are already cried down at other parts of the forum and not many are looking forward for the console ports as far as I know. And there is not a real financial incentive to just update the game for the next years to keep modders happy since most sales already happened (thanks to the people doing EA-purchases, good job here) and since it also didn't really happened at Warband, to make again the look back into the past. They made some bug fixes but that was it.
Also pick up the offer of Dejan to report the internal modifiers which you need to modify so that he can take a look at the check lists to see if they have some special protection by a developer or are needed for a DLC. Don't crucify him for that offer, it's probably the best he can do within his possibilities.
And while it's not hard to understand the frustration, it's hard to understand the permanent frustration about everything. But again, that's due to the fact that some of you here are not willing to learn from the past two years (and more for people being around since a longer time) and are still expecting too much, so that's mostly on your own :razz:

TL;DR: Don't expect anything, be happy if they do something at all. It's not a good thing but a lesson of the past.
...This is a perfect summary of the current situation, I fully share your every word and in a special way the last sentence...

P.S.:...well, in my "perfect world", TW should have released full support to modders, see what would come out of their works, and then release paid DLCs on top quality content such as maps, textures, models and items, to increase the immersion of the different settings...
 
Access modifiers such as internal and private are a code design choice to enforce good practices and ensure that specialized parts are not misused. They are a part of our software engineering work and not there to enforce / enable mod compatibility.

Especially considering that this is an ongoing project, it should be no surprise that we intend to continue to use these tools for our work where appropriate. Having said that, we did go over the code to review their application across a broad range of classes - as was announced in our initial response to the open letter. The adjustments that will come with v160 aim to reduce inconsistencies as well as unnecessary limitations. As a result some modifiers were added while others were removed (alongside other changes).
You're so out of touch it's beyond belief, matter of fact the ego of this entire company to disregard the defining aspect of their games that brought in almost the entirety of their success is incredible.

You did not make Warband successful, I beg you as a company remember who did that.
 
Bannerlord is still early access and not even completed. I don't really care how it is right now. Most important is how it will be at day of full release. If things warrant to bring out the pitch forks then, then do so, but during this stage, not worth it.
Modders are making their complaints now because the work they want to do is already going to take a couple of years minimum, and if it doesn't become easier to work with the code very soon, that will add even more enormous delays.

Maybe patch 1.6 will help somewhat, but it still seems very counterproductive to be adding more uses of internal when modders repeatedly say it's a major impediment to their progress, and the only good reason TW can give for using it is trying to keep the code "in good practices and not misused" (which some have said can be done via code reviews instead).

Maybe there's something we're missing here still? Getting info out of TW is like getting blood out of a stone, and I appreciate Duh using his time to answer and bring clarification to me in this, since I was under the impression compatibility was the reason.

Edit: Removed incorrect information.
 
Last edited:
I support this letter for two reasons:

I loved The Last Days of the Third Age for Warband, and eagerly await its implementation in Bannerlord. However, it appears that if it does ever come about, it will take years to implement, probably years after the actual official release of the game. In other words, if these entirely voluntary fans burn out because TaleWorlds has made this game too hard to mod, we may never see those total conversions that we loved.

I despise the current state of the AI. Though there are some intelligent behaviors, eg. remounting when they're unhorsed, these are often few and far between. Combat is marred by hard-coded stupid actions. I, an AI attacker, have just scaled the wall of this castle. I will attempt to get to the other side of the castle, ignoring all enemies in the process. I will die. I, an AI archer, have just scaled the wall of this town. I will then run down to the ground and attempt to get to a corner where I can shoot my bow, ignoring all the enemies in-between until I'm forced into melee, where I will either attempt to use my bow, or rapidly switch between bow and melee weapon, never using either. I will die.

I would bet there's a modder who could make a mod where each class behaves in at least a less stupid fashion. Since many of these actions are apparently chiseled in stone, we will just have to hope that by release TaleWorlds improves the the AI, and it doesn't behave like its being commanded by Zapp Brannigan.

"You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won."
-Futurama, "Love's Labors Lost in Space"
 
Access modifiers such as internal and private are a code design choice to enforce good practices and ensure that specialized parts are not misused. They are a part of our software engineering work and not there to enforce / enable mod compatibility.

Especially considering that this is an ongoing project, it should be no surprise that we intend to continue to use these tools for our work where appropriate. Having said that, we did go over the code to review their application across a broad range of classes - as was announced in our initial response to the open letter. The adjustments that will come with v160 aim to reduce inconsistencies as well as unnecessary limitations. As a result some modifiers were added while others were removed (alongside other changes).

So can we clarify this: you guys are using the internal keyword to enforce good coding practices in-house? Is there a reason you can't remove the internal keyword when you distribute release branches?

I'm confused why this was not communicated earlier...

This, however, certainly doesn't mean that the game is unmoddable. Indeed, there are already rather complex mods available to players. Furthermore, it doesn't mean that we will not make further adjustments to resolve issues that are highlighted by the modding community.
While this is true, the overwhelming majority of features/systems are guarded by the internal keyword. Basically every mod on Nexus is just tweaks existing systems or creates entirely new ones using harmony patching/transpiling, but doesn't replace existing ones for this reason. Actually replacing (or even just disabling) those systems is nearly impossible because of the nested/hard-coded dependencies, which is critical for total-overhaul mods.
 
Some of their own staff have been fired for criticising the development structure too much.
interesting. got some links?

and what are your thoughts on this?
Also using internal for whatever the example you gave above is not explaining the situation. If your intention is to keep your own engineers in line, you can use private - because the behavior you described fits to that. Internal means it's purposely limited to use outside of that assembly. Which means "We don't want anyone but us to reach or use this".
 
Actually replacing (or even just disabling) those systems is nearly impossible because of the nested/hard-coded dependencies, which is critical for total-overhaul mods.
That's exactly my biggest fear, I have seen a dozen modders saying they do not want to start an overhaul project without the guarantee that it would be feasible.
 
Also using internal for whatever the example you gave above is not explaining the situation. If your intention is to keep your own engineers in line, you can use private - because the behavior you described fits to that. Internal means it's purposely limited to use outside of that assembly. Which means "We don't want anyone but us to reach or use this". I'm not even going into internal classes or nested classes inside them etc.
I thought private also didn't allow out-of-assembly access? Or am I misremembering? Been too long since I did any C#.
 
Back
Top Bottom