Modding Interview with Dresden
by
Published on April 14, 2019 09:47 AM
Sort - Number of Views: 22443
Dresden
- Always stick to your core philosophy and goals despite adversity and criticism. Feedback is useful but must be focused by the lens of your own creativity.
Interview with Dresden by ♔Greek Strategos♔
Hello Dresden! Thank you for this interview! It's a great honor for The Eagle Standard! I'm sure our users will greatly appreciate the knowledge and the modding experience you're about to share with us, so let's get straight to the point. Today we'll talk about startpos modding mostly, but also about your journey on TWC and last but not least, we'll share a few modding tips with our current and potential modders.
How did you get started in startpos modding?
When I first started modding, I was drawn to editing the startpos because there weren't many mods working on it. There is an inherent difficulty in modding the startpos in any meaningful fashion without the assembly kit. Other than changing one variable, like in turn per year mods, it is very difficult to change most parts of a startpos with the basic EditSF tool. However, there is a lot of potential for very sweeping changes when you can edit the startpos properly. The idea of having different scenario campaigns and different starting regions was exciting so I pursued those ideas.
I mostly began modding after Rome 2's release when I saw a lot of things that I thought needed to be changed. My first mods were smaller mods that tweaked basic values like turns per year, seasons, diplomatic options, etc. Once I got more into modding, I started looking into the more difficult aspects like startpos mods. Once I did that, I got hooked on the fundamental changes you could make with working on the startpos. That is when I created my initial mods like Hegemonia that expanded historical start positions. That mod was one of the original parts of Divide et Impera's mod collaboration and was probably the reason I initially joined DeI as one of its founders.
What difficulties did you run into with startpos (starting positions) modding?
Since we had no access to mod tools, creative solutions had to be found to make some fundamental changes. A few of us started working on cracking the code for changing region ownership and some of the other deeply buried parts of the startpos. These values are mostly a number of references and other weird values that are rather complicated to change properly and still have a functioning product. I used many of these methods to create some of the first region changes so that Carthage and the Seleucids would own more of their vassal territories or to make Rome a bit larger to start. However, there are limitations to this method on the technical side of things.
Therefore, instead of just directly editing the startpos using the EditSF tool (or PFM), I started to employ a method used since the Empire TW days. This method breaks apart the startpos into XML files that can be directly edited and changed. This method really opened up the possibilities in terms of what could be done. For example, it allowed me to create mods like Constantine where entirely new scenarios could be made. That mod specifically was made using a bit of creativity by loading the game, confederating large areas of land manually, then repackaging the save as a new startpos file. My early scenario mods were made using this method, a bypass of the much more complicated (and often impossible) method of directly editing values in the startpos itself.
What is the difference with current startpos modding? Do you have any specific startpos tips?
The obvious and biggest difference is the assembly kit, which allows modders to create and process any startpos changes they want. Rather than having to use obscure methods, anyone can load up the mod tools and create a startpos. However, it can still be a complicated headache due to the way the kit works. The main tip I have is that you have to be careful about what you change and how you change it. Most everything in the startpos (and the game) has a reference to something else. For example, let's say you want to change a faction's starting regions. At first, it seems easy, just go in and change the one entry that governs a region's ownership. However, you also would need to check if those regions are the faction's capital. If so, you would need to assign a new one. You also would need to check if there are armies or characters in that city, etc. That example is just a basic one, but once you start editing the startpos in any complex manner you have to think about how each part is interconnected.
Another tip that some don't know about is that the assembly kit reads the data pack files for a lot of the information when building a startpos. For example, unit sizes, garrisons, and many other parts are all constructed from what is in the data pack. Because of this method, you will need to create your own data pack (in movie file format) that loads with the compiler if you want to change any of these things. The best way to do that is to make these changes as you go in the assembly kit then export any changed tables to a pack file. Open that pack file and make it a movie type pack, put it in the data folder, and it will automatically load with BOB (the kit compiler) when you create your startpos. Alternatively, you can create the pack file in PFM as well.
How about the difference between startpos modding and non-startpos modding?
The difference between startpos and normal modding lies in the complexity, depth, and inflexibility of the startpos itself. The startpos is a fixed set of values like a saved game that determines a lot about how the game starts up a new campaign. Unlike a database table that you can directly access and change, many of the startpos elements are not so easily altered. A lot of the core parts of a startpos are deeply embedded in its structure and often use numbers and other esoteric means of referencing things. That's why you really need something like the assembly kit to truly alter major parts of a startpos, unlike database modding where you can access most information like a spreadsheet.
Note for non-modders
With the right modding tools, startpos modding enables you to mod things you can't mod otherwise. These are things like:
1) Starting armies-navies.
2) Generals and agents etc.
3) You can make new factions playable.
4) Starting treasury.
5) Starting date-Turns per year.
6) Adding victory conditions.
7) Convert minor to major cities.
8) Set Emergent faction to playable and Playable faction to emergent.
Note provided by ♔Greek Strategos♔
What mod projects have you worked on so far? Let's focus on the major ones since your smaller projects are far too many for this interview.
Along with DeI, I also worked on a mod called Tetrarchy: Civil Wars that became Constantine: Rise of Christianity. My initial mod changes there were all based on creating an entirely new campaign scenario for Rome 2, almost like a DLC, which was fairly unique at the time due to a lack of an assembly kit. When Ahiga and 'Gunny joined me, we expanded the mod into a full overhaul with all new units, battle changes, and a full roster replacement for the time period. I also worked with these same great modders on Fall of the Eagles for Attila, which is primarily a battle and unit overhaul. Most of my projects for newer titles like Warhammer have been much smaller mods.
The early stage of Constantine's Rise of Christianity was Tetrarchy: Civil Wars.
Were there any specific moments or difficulties you can remember when creating these mods?
Creating and managing large overhauls with a team of modders is difficult, but it's even harder when you realize that you have to keep two major overhauls and 10+ mods working through 17 game patches in around a year. Prior to Rome 2, CA really only patched games a few times. If you look at Rome 1, it probably had a handful of patches spread out over time. However, with Rome 2 CA had a lot of work to do and to their great credit, they really did improve the base game a lot in that first year. However, being a modder was very difficult at that time and being an overhaul modder was doubly so. Every patch was fairly large scale and we had no idea what exactly was changed or how to fix the mod other than trial and error. Along with having no mod tools, we had to basically search in the dark for what was different and had to be changed after every patch. Of course, that is still the case today in many ways. It was a huge challenge and a large portion of our time was spent getting mods working during the relentless patching schedule that first year.
You have mods for all of the current Total War franchises, what are the differences in modding them and which are your favorites?
The primary difference in modding each successive game is that more options usually open up for modders in terms of new scripting possibilities and new game mechanics to change or exploit for modding purposes. Unfortunately, sometimes new games also have less space for modders to play due to IP concerns like Warhammer. I think that building up to Rome 2, each older game had vastly more modding possibilities on a fundamental level. However, Rome 2's release cut a lot of those possibilities out, such as campaign map editing or battle map creation. Over the next few games after that, some of these have been added back in. At its basic level, though, most of the games are similar to mod you just have to take the time to learn the new features, tables, scripting commands, etc.
As far as my favorite game to mod, it remains Rome 2 simply because it was my first and what I have spent the vast majority of my time modding. I would say I know a significant amount about modding Rome 2, even though I regularly learn new things from other modders and even just from investigating myself. After modding it for over 5 years, I tend to have to relearn forgotten parts or even try to figure out why I made some changes that I did in the past. While I enjoy modding the other games for fun, to me Rome 2 and DeI are my modding home.
Do you have any general starting tips or useful things you have learned along the way?
I would first recommend reading tutorials and investigating other mods. I started out by downloading mods, opening them and figuring out how they are doing what they do and why they make certain changes. Magnar's video tutorials and various TWC tutorials on their workshop are great for that. Asking other modders questions can be a very helpful way to learn. I find that the modding community is a very sharing and giving one that set me up as the modder I am today. I would not be here without modders from Total War Center helping me along the way.
- Always have a backup folder that you copy your mod pack to after testing to see if it's working. Its also good to have an online backup that you regularly upload to. It can be extremely frustrating to lose hours of work because you didn't back it up. When I say lose work I do not mean from a disk failure but rather from a mod change that breaks what you are doing and you need an earlier version to compare. One thing to be careful about here is that sometimes backing up a file that is being read by the game can corrupt that file.
- Keeping a copy of previous game version data packs to compare to new ones can help figure out what changes in a patch, especially if you use a program like WinMerge. CA has actually been more helpful recently with releasing lists of changed tables, so this may not be as important now.
- Use table fragments in your mod unless you have to remove a vanilla entry. To use a fragment, just rename the table something different from vanilla. This allows for your mod to be much more compatible both with other mods and with future updates.
- Using spreadsheets is very helpful when editing tables. You can copy the whole table to a sheet, edit values with formulas or other techniques, then copy the rows back into PFM. The same is true of text editing. It is much easier to edit a text file in Google sheets, download it assets and import it.
- If you have a start-up crash or an update breaks your mod, start isolating tables and removing them until the mod will load. However, be careful when doing this because various tables will have dependencies, so you will have to remove them in groups. Once you have figured out the offending table, it will be much easier to find the issue causing the crash. The same can be said for in-game crashes. Try loading the save and removing some tables that have no dependencies so they will use vanilla variables again or changing various columns back to vanilla entries. This can often isolate a crash issue.
Final thoughts:
It's important for the community that players become modders and continue to interact with existing modders through feedback and conversation. Most mods would be a shadow of themselves without player communication and new modders are always important in pushing out new ideas and concepts. So, if you are reading this and you have any interest at all, you should give modding a try. It can be much more rewarding than you would imagine.
If you've enjoyed this interview, you might like to read some of the Eagle Standard's other articles. A full list of these
can be found here .
vBulletin Message