Page 1 of 12 1234567891011 ... LastLast
Results 1 to 20 of 234

Thread: Beginner's Modding Manual (RTW)

  1. #1

    Default Beginner's Modding Manual (RTW)

    BEGINNER’S MODDING MANUAL
    for RTW


    The goal

    What we are going to do: We will make a simple, fully modfoldered mod, based on vanilla Rome:TW. Then we will make some beginner-level modifications to various aspects of the game trying to cover all the basics of modding, in order to give you an overall taste of what it takes to create a modification and how the game works.



    The approach

    How we are going to do this? Step by step. We will give a list of specific tasks to be done, that will guide you through the process as smoothly as possible.
    **Note: The order at which these tasks are done is not absolute, but there are certain steps that have to be completed before others are addressed, whereas others can be ‘swapped’ and done in reverse order from the one we will suggest here. We will make this distinction clear where it exists.

    **Note: There are ‘disciples’ of modding that inevitably intervene. The division I am making here has a purpose to group tasks into distinctive categories as far as possible, but remember that there are occasions were no clear line can be drawn. For example, descr_strat.txt is a text file the modification of which can be classified as “coding”, but it is also essential as a map file. For the purposes of the manual I have included it in the “Mapping” section.
    List of Contents:



    Click to view content: 

    • General Information
    • Useful Modding Tips
    • Useful Tools
    • Command Line Switches


    Click to view content: 

    • What is a modfolder?
    • How does the modfolder work?
    • Why is the modfolder useful?
    • How do I make a modfolder?
    • How do I launch a mod that uses a modfolder?
    • Testing the modfolder
    • Working Example


    Click to view content: 

    • Knowing the files
    • Creating a landmass
    • Editing heights
    • Editing ground types
    • Editing features
    • Editing climate
    • Creating a new region and settlement
    • Editing region ownership, settlement and army details
    • Working Example


    Click to view content: 

    • Knowing the files
    • Editing a name
    • Adding a name
    • Removing a name
    • Working Example


    Click to view content: 

    • Editing faction names
    • Editing quotations
    • Editing credits
    • Editing miscellaneous things
    • Working Example


    Click to view content: 

    • What is a trait?
    • What is an ancillary?
    • What is a trigger?
    • Knowing the files
    • Changing a trait's/ancillary's description
    • Changing a trait's/ancillary's effects
    • Creating a new trigger
    • Creating a new trait
    • Creating a new ancillary
    • Working files
    • Additional resources


    Click to view content: 

    • Knowing the files
    • Editing unit stats
    • Editing unit names and descriptions
    • Adding a new unit (UI, skin, model provided)

    • Buildings: (Not yet done)

    Click to view content: 

    • Change the stats of 1 unit.
    • Change the name and descriptions of 1 other unit.
    • Add a completely new building in its own tech-tree.

    • Visuals: (Not yet done)

    Click to view content: 

    • Change 1 faction’s banners
    • 1 other minor retexturing (needs specifying)

    • Sounds: (Not yet done)

    Click to view content: 

    • Adding a new music track
    • Adding a unit identification shout
    • Adding a voiceover
    • Adding an effect sound

    • Scripting: (Not yet done)

    Click to view content: 

    • Make 1 simple campaign script
    • Make 1 simple show-me script

    Last edited by Aradan; April 14, 2010 at 02:03 PM.

  2. #2

    Default Re: Beginner's Modding Manual (RTW)

    Before we get started: General Information


    Before you start modding, there are certain things it would be useful for you to get familiar with, because they can really save you much time, effort and frustration.

    General Information:

    • What a Mod leader Should Know:
      Click to view content: 


      Introduction

      Hi, If your reading this there is a good chance your thinking of starting up a mod or recruiting a mod team, i have asked some of Twc's resident and best modders (and a couple of great posts from the .Org) to give a small insight as to what can be involved in such a task.

      Some are basic overviews and some are more specific but all have plenty of insider knowledge that we hope you will find useful as you enter the world of modding Total war games. Now reading these may turn you off as they may make modding seem a daunting task, but consider this, these guys were all just like you once and they wouldn't be still modding if it wasn't for the help and support of the community and the simple fact that modding is fun.

      Good luck.

      Halie Satanus .

      Posts from the .Org posted with permission from the Authors.


      Muizer
      Publius
      Professor420
      Lusted
      Makanyane
      Bwain
      Khelvan
      Dol Guldur


      Muizer.

      Mapping.

      1) before engaging a mapper it would be preferable if at least a rough sketch exists of the map layout including:
      - the area it will cover
      - an idea of what a regions map would look like.

      this is necessary because:

      2) you need to confer with the mapper about size and resolution of the map

      3) the mapper should then set up the template for the map, freezing the resolution for the rest of the project. Map extents are less critical and be reduced afterwards.

      4) On the template will be drawn the main geographical features (coastlines, rivers, mountain ridges)

      5) the template is then returned to the team to work out in detail the scenario (the "human geography"). Region boundaries can be painted on the template with any paint program.

      6) the filled in template is returned to the mapper who uses it to make a regions map and thus complete a basic map set. The minimum set of files that need to be modified are:

      text files:
      descr_regions.txt
      descr_region_and_settlement_name_lookup.txt
      imperial_campaign_regions_and_settlement_names.txt
      descr_strat.txt
      descr_win_conditions.txt
      descr_mercenaries.txt
      descr_terrain.txt

      tga files
      map_climates.tga
      map_features.tga
      map_ground_types.tga
      map_heights.tga (map_heights.hgt is the 32bit version)
      map_regions.tga
      map_trade_routes.tga

      These will be stripped of all information not crucial to getting the game on-screen. That is basically where the task of the mapper ends until:

      7) troubleshooting of the map during play testing.

      A mapper will generally know how to place resources on the map, buildings in cities, set up family trees, defining armies, characters, diplomatic stances etcetera, but cannot as such be expected to be creative or knowledgeable in this regard.

      Of course I'm heavily biased towards working on physical rather than human geography. I bet others work differently, but unless they say so we'll never know.

      Muizer




      Publius

      The Scriptorium's Modding Catalogue is a good place to reference. In regards to unpacking, I will shamelessly self promote and link you to this tutorial.

      Key Elements You Need to Start a Mod

      1. Tools and Utilities:
      -3dsmax: Currently the only program which allows you model for the Rome Total War engine via Vercingetorix' cas importer/exporter. (Note: This is not freeware)
      -GIMP: Freeware 2d graphic editor. With dds plug in you can use this to skin. You can alter virtually any 2d element in the game with this program.
      -DDS Converter 2: Useful for viewing skins if you are trying to find them. I find little practical use for it outside of that, but still handy to have.
      -XPAK: To unpack models, ui, and a lot of other game files you will need this.
      -XIDX: To unpack animations you will need this.

      2. Maps: Getting a working map is the most important part for your game. You cant play a mod unless the map itself loads. As such this should be an element of primary importance, but doesn't require you halt progress on other elements (like units, ui, etc). It is best to get your map working as soon as possible so you can refine and test it - theres a lot of code associated with a new map which means lots of mistakes are possible.

      3. Modellers and Text Editors:
      Some mods can get away without modellers (by simply doing reskins, gameplay fixes, etc.) So the key to this is knowing what your goals are. If you are planning a major conversion (such as a fantasy based mod, like LOTR) then make sure you have at least one or two full time modellers to help. As for editing files, it is nice if you can find someone you can do this but ultimately as mod leader you should be prepared to take the brunt of this burden, if necessary. Text editing requires no extra programs (just notepad) and the plethora of tutorials available make the only excuse for not knowing how to do this (if it is your task) laziness.

      4. 2D artwork:
      This is the icing on the cake. It is not needed to make a mod, but it is needed to help make a good mod. Immersion is key when you are trying to make in essence a new game for people to use, so things like loading screens, unit cards, faction icons, etc. will go a long way towards making your modification a stand out.

      5. Organization and Leadership: Have a plan. Don't go into a project with little or no idea about what direction you want to take it, and how. Try to keep information on who has what tasks, and what tasks have already been completed, very easy to find so that you dont have people doing the same work. At times you may also have to ask mod members to work harder, faster, change something they have done, etc. This may not always be easy, as often these are your friends as well, but keep your advice here simple and constructive, and you should have few problems. Also, when people ask to join your mod, be very hesitant to say no to them. Even if they have no modding experience whatsoever - modding can be learned, but hard work and dedication cannot.

      Peace,
      Publius.





      Professor420

      "So you want to make a mod, eh?"

      Let me preface this article by saying, every single gamer on the entire planet has a great idea for a game, or a mod of their favourite game. Their ideas are always superior to all other ideas, and unique to all other ideas. And sometimes, they are. But the ingenuity of an idea, or the greatness of a concept, is irrelevant. What matters, as someone starting the mod, is YOU. YOU will run the mod, fuel it, push it, not the other way around. This is the first fundamental mistake people make. Ideas are worthless, and with few exceptions (Lord of the Rings, Star Wars, etc.,) no one will be as excited about your idea as you are, and you will get no talented recruits based on an idea alone. What matters, is YOU.

      Are you able to start a successful mod? Likely not. Have you ever worked on a successful mod before? Have you ever led a mod? Do you currently possess all the skills required to complete your idea (art and coding)? These are vital questions that most people do not ask themselves when they start a mod. Because, honestly, its depressing. But they are questions that hold true, in example after example. Now, it will be very easy to ignore this advice. There is nothing to stop you from posting it anyway and looking for team members. So let me try to convince you why it is in your best interest to not start your glorious mod idea.
      • Is your idea REALLY that good? World War II/III? Comon. Deadly virus outbreak? Comon... Post-apocalypse? Warcraft? Generic fantasy? No matter how good, and how nuanced, your idea is, on the surface, it is extremely generic. ALL ideas are, there are very few 'original' ideas. And if you think yours is original, it is likely because you do not have enough experience as a designer. On the other hand, all ideas are unique. But the unique aspect is always second to the generic aspect, until you create something so people take more time to peer into your concept.
      • Is your idea copyrighted? Is it based on Star Wards, Lord of the Rings, Wheel of Time, etc? I don't give a care to intellectual property infringement as far as mods/nonprofits go. But if you do not possess the skills to start a mod otherwise, what gives you the right to start a mod based on a pop-culture concept? Leave it to the experienced people to start the mod, then you can work on your favourite franchise, and learn, at the same time. Starting a mod based on these franchises takes zero skill, and even less originality. Just because you will automatically attract more talented people, does not mean the mod will be healthy. YOU will be its initial driving force, and if you aren't able to drive, you are going to steer the ship off course or crash it entirely.
      • What will you do? Unless you are able to produce assets of production quality, or have a good amount of coding knowledge to implement the mod's important features, you don't serve a purpose. You hold no practical power or authority as the founder, as the leader, as the manager, "web-guy," or designer. I have met only a handful of skilled designers, and I have never met a designer that formed the team and led it. Design is an auxiliary role, and if designers are leaders, it is because they have inherited a team, are extremely skilled and respected at what they do, and the team has proven they can get things accomplished beyond design.
      • Can you create a decent product if you are by yourself? For artists, this means, can you create enough art to push the mod past the starting line, and after that, most of the art for the entire mod? For coders, this means, can you set up the gameplay systems and features on your own, as the only coder? Things such as maps, sound, design, etc., are auxiliary, and do not create an entire mod in and of themselves.
      • What do you have to gain from starting a mod? Are there any other mods similar to yours? Why not join one of these mods, to contribute to a product, develop your skills, and aid others? If your mod is "Dinosaurs vs. Smurfs," your concept is likely too unique to find another mod similar enough to be interested, but on the other hand, too unique to find anyone with a similar interest or passion to help you with the mod. As I said before, ideas mean nothing. If you can do the work, you can make people excited for your Dinosaur/Smurf game.
      • If you had your dream skills, would you be content working at the whim, or even at the same level, as the former-you? Why would anyone who possesses great skills work for/under someone who lacks any real skills? Do not expect to find people much more talented than yourself. And do not expect them to work on your project. They will often naturally come along to 'pop culture' projects such as Star Wars or Lord of the Rings, but it is highly unlikely a skilled artist will sign up for a mod that has skins made in MSPaint.
      • Finally: You need skills to make games. A lot of skills. Mad skillz. You are much better served spending your time learning and 'doing,' rather than struggling to create your own team. Then, once you've blossomed, you can start your own project will experience, confidence, and skills. If you lack the fortitude to invest the time required to build your skills, you will never be able to create your own mod. And I hope, after reading this, you won't think you can convince other people to make your mod for you.


      Professor420


      Lusted

      How to Make a one man mod.

      First off i must say this is the hardest way of making a major mod for TW, just because of the sheer amount of work involved. For minor mods it is easier as the amount of work is reduced.

      Reasons to make a one man mod.


      There are various reasons. The reason for me to make TE a one man mod was because i do not work very well in a team, and like to set my own deadlines for my work. For Alexandros, i worked mainly alone because no one else actually wanted to help it seems. But the main reason for both was because i wanted to make my mods. I was making them for myself first, and the community second. I was driven by the desire to play the finished mod. This was especially true, and it was a huge blow when i lost all the work on it and TE Gold due to computer probelms.

      Learn to do as much as you can yourself


      I started off as a unit editor, first text files, then 2d textures, then 3d models. But for TE i had to branch out into many different aspects of modding to get the work done, such as trait modding, faction editing, building editing, sprite making, adding in night battles, making recruitable generals and so on. This meant that when it came to Alexandros, i could doo most of the work myself, though there were some aspects of modding i could never grasp mapping, and so asked a mapper to help me out.

      Make things easy for yourself

      Use other peoples work if you can and they give you permission. Do not spend months on a new map if there is already a perfectly good one out there tht does what you want. Likewise with unit models and skins, most of those in TE are not done by me, and this helped move things on a lot quicker. Sometimes though you do want to have something in it that is yours, like i always had my Romans in TE, and for Alexandros i was determined to do most of the models and skins myself. But if you go down that road, get help if you need it. Countless times i've run into problems only for a modder i now to help me out.

      Luckily there are a huge amount of tutorials and tools in the RTW mod community so thst anyone can learn how to do any aspect of modding.

      Its your mod

      Remember that what you are doing, you are making yourself. Listen to other peoples suggestions, but don't give in to what most people seem to want if you don't want to. Your maknig this for yourself remember.

      Lusted




      Makanyane

      TEXT EDITING – (WHAT A NEW MOD LEADER SHOULD KNOW…)

      Text editing is the rather unglamorous side of modding but it is essential (and also unfortunately the area most prone to producing CTD bugs!)
      Once everyone has admired the nice looking units / new map etc., what will keep users playing a mod is whether or not the game play is to their liking. Except for map geometry and scale, all aspects that affect faction balancing and AI behaviour are controlled by the text files.

      As mod leader if you’re not heavily involved in either the modelling / skinning or map making aspects then your team is likely to expect you to take on at least some of the text editing. Even if you are going to be otherwise occupied it would still be useful to have a good grasp of the text files and what can / cannot be done with them, before you attempt to recruit a team. If you haven’t modded before I would therefore recommend making small alterations to a vanilla campaign to familiarise yourself with the files. It would also be helpful to have some understanding of the scale of the tasks involved before trying to assign them to volunteers. (Try adding one region / unit and multiply time taken by number required in game – then allow for testing / balancing etc.)

      Below is a very simplified overview of the files / areas involved for certain types of mods.

      MAP ONLY MODS
      Using all existing units but on a new map e.g. a new larger map or one that just covers Italy / Greece etc. (Off topic but important first make sure you / your map maker can actually get the land shape you envisage to load at the scale of map you want – as there are limitations on that! )

      There are other text files involved in making map load but main ones for optimisation are descr_regions.txt and descr_strat.txt:
      Descr_regions.txt has a base farming level that controls growth rate for each region (effects balancing), default faction and rebel type for each region and hidden resources (which can be used to alter recruitment etc and hence links to export_descr_buildings) - plus also starting religion settings in BI.
      Descr_strat.txt has amongst other things visible resources – they effect trade levels for each region (and are rather time consuming to place!) Each factions, starting regions, diplomacy settings, starting money, family tree and the position / make up of armies, and starting character traits are set in this file. Each regions’ faction_creator, initial population and pre-built buildings are also defined here.

      Small changes to any / all of these settings can make a large difference to how hard or easy a faction is to play and how well the AI controlled factions expand initially.

      UNIT ONLY MODS
      You’re using an existing map but have decided to have Smurfs instead of Romans etc..

      To get new units into game you need to add them to at least the following: export_descr_unit.txt (all unit statistics and balancing), descr_model_battle.txt, export_descr_unit_enums.txt, export_units.txt (descriptions), export_descr_buildings.txt (to make them recruitable), descr_strat (to put them in at start).

      Also depending on what type of unit they are possibly descr_character.txt, descr_sm_factions.txt, descr_mount.txt, descr_rebel_factions.txt, descr_mercenaries.txt and (I’ve probably missed some) To add lots of new units you’ll also have to amend many of the above files to remove existing units to make space within the hard coded limits.

      You may also need to consider alterations to descr_formations_ai.txt, to get the battle performance you want.

      FULL CONVERSION
      Work required for a full conversion can probably expand exponentially to fill any amount of time that can conceivably be allotted to it!

      All of the above areas are involved plus most if not all of the following: General expanded text editing for faction names etc. Addition of new buildings and /or building descriptions. Alterations / additions to religions (for BI). Alterations to cultures (and possibly inclusion of an additional culture) Traits and ancillaries (probably an area that could have infinite amount of refinements). Scripting if used (another area which could be expanded almost indefinitely). Editing to get in new features such as sounds / terrain etc. Alterations to names of leaders, quotes and events etc – so ‘immersion’ is maintained…..

      I’ve probably missed some but that should give some idea of the possible workload just on the text side!

      Makanyane



      Bwain

      I, for one, was pleasecd to see the sensible approach to modding that was adopted around conditions of use. I think, as a community, we handled it far better than most. It reflects the general sensibility of the people who come here, and a degree of maturity in the community that is a refreshing change to some...'other' areas if the wonderful world of forums!

      Having a section of answers saves having a mass of 'sticky' threads and also takes the load of the search function...so often missed by those who need it most! You can just point a novice in that direction and let him find the answers as best they can, without having to trawl the depths of years of posts! All good.

      It is also good to highlight some of the things that have caused mods to sink, both those that fizzled out some months after their start, or those that launched majestically off the slipway only to plough straight beneath the waves before the paint was even dry.... All too ogften, the same mistakes are made over and over, resulting in despair. We cvan, as a community, point people in roughly the right direction.... but they STILL need to be free to make their own mistakes.

      Lessons:
      Some good points here..plus some stuff that is just as unhelpful as no advice at all! Personally, I have been pretty much a team of one. My experiences reflect the way I like to work on things. I can model, skin, animate, text edit, make a map and generally...given enough time....can do all the tasks that a mod requires. I have had people join me to help..but these have been volunteers who approached me and who had something to give. All too many 'recruitment' threads attract a mass of volunteers to research or test..but not to model, skin, animate etc. By relying on myself, I am in control of the development and the direction. For me to hand that over, I would have to be sure the person I handed it to shared my vision of the finished product. This works for me....but would be a disaster for most teams!
      I refrain from giving advice on this point because I know my advice would not bo good for most.

      Modders / Members .... only time and invovlement can do this. A member gains value in the community by learning, sharing that knowledge ( not sitting on a grand breakthrough to give their mod an ego boost! ), and by involving themselves in what goes on.

      Mod Packs ..... hmmm.... interesting!
      A mod is what you want to make it. I released my Skeleton Horde as a simple replacement for the Gauls. Unit stats were virtually unchanged bar minor tweaks, and the thing was just a fun way of putting some new visual content into the game. That is a simple 'modellers' mod and anyone could do it that way. Release them as simple swaps that can run in both skirmish and full campaign battles and that works very well. I was going to do more with them...but people wanted to play with them, and this was a simple solution.

      Metal Mayhem, however, cannot be handled that way. It can't be sliced up into 'packs' since it changes far too much to ever be balanced. I have already had to remove all the standard horse and camel models from the game to make room for the units I have added. New build trees, new everything! It either goes out as a finished product....or I keep it on my HD for my own fun and for the entertainment of my kids...who love it!

      In all things, though, the MOST important thing for ANY mod is to really thoroughly scope out what you intend to do, and the volume of work you will have to do to complete it. Be 100% sure that you can do everything you plan to do, and DO NOT EVERassume you can 'solve that problem later on once the mod gets going' . Test the concept, and if it works carry on. If it doesn't...work around it or give up!

      I tested my animations, tested my 'all horse' concept ( and had to include some bi-pedal robots for skirmish battles involving cities... it INSISTS you have a sapper or ladder etc. ) I knew all the things I had to do COULD be done, and that left me just with the challenge of making the content.

      I PLANNED it , I TESTED my theories...and then I started my Mod. I have pages and pages of notes, sketches, diagrams etc. and I know what I want to get done. If every mod did the same, I think more would get done!

      Bwain

      Posted from the .Org with permission.




      Khelvan

      I have to stress that there is no one right way or wrong way to organize and manage a team. This depends on the person and the team members, (and in a business setting, the organization at large).

      In my experience, the more people are being compensated, the more they are willing to follow a single person's will. That compensation may be financial, for "real" jobs, or in the form of recognition, or even in the form of having their ideas used and valued, for non-paying jobs. Perhaps it is in seeing the realization of a purpose or cause, or end goal.

      For modding I think that the more "power" that individuals have in a mod team, the more they feel valued, and the more engaged they are in doing their part. EB has never had a single brain at the top. We have had several "leaders," but not in the sense of creative control. Rather, we act as moderators, or very much like project managers in business whose subject matter experts are the people on the team. The manager just makes sure that all ideas are heard, that decisions are made efficiently, and that disputes are mediated.

      Size matters - a big team is of course much more difficult to manage than a small team. However, ability and reliability are the primary factors in team size. There are times when a small number of people have a great deal of skill and dedication; these can be the core component of a team, and may be all that are needed to complete smaller mods. Or just one, for the smallest.

      The numbers will likely have to increase as the size and complexity of the mod grows. Like business organizations, tasks will tend to become more specialized as the complexity (and team size) grows, and thus will need more management. Unlike someone said above, I think there is a place for many historians, if the mod is focused on history. But this has to be balanced with people who can do the work, in a mod where these tasks are broken out, otherwise lots of research will be done but the mod will never get going.

      As a leader and/or the public face of a mod team, I can guarantee you that staying emotionally detached will be incredibly difficult. This is where I failed most as a "leader." Emotional attachment is sure to be high for all people on the team; there is no financial compensation, so people are dedicated for other reasons. As a public figure, you can't really afford to be engaged in this way, otherwise you will make poor decisions. For instance, I did not have a job for quite a long time, and dealt with a very serious medical condition, and I channeled my frustration and emotions into EB. This led me to state things emotionally in a way I would never do normally. Especially in a business environment, I would never have said things like that. Keeping your emotions in check is very important. This can lead to people leaving the mod, as well, and I guarantee it will if you get angry/snap at people easily.

      A release schedule generally depends on the mod and the mod team. Here we consider individuals' goals. For instance, if one of the goals of the mod team is to be exposed to game companies so that the members can earn jobs in the industry, it is in their best interest to release only versions that could be considered polished. Likewise if the mod is hurting for members, the team has to do a very good job of keeping the fans involved, through distributing information, or through more quick releases. Releasing too quickly will be a problem in that case, though, as fans don't like to have to restart their campaigns often. It really depends on what your needs and goals are.

      Finding some balance between introducing information to the public but not committing yourself to anything is very difficult. In general, if you care at all about pleasing the fans, never, ever, ever give a release date or make any promise of any kind at all. Even in the real software development industry where people are paid to do this work and can be held accountable by someone external to them release dates are often missed. Not missing the dates leads to great disappointment and even more heartache for all involved. Keep expectations low and you have a much greater chance of exceeding them and pleasing the fans.

      However, keeping the fans involved is important to most mod teams. Regular information posts with teasers can help keep interest up. I am sure there must be some way to keep the fans informed, perhaps with some sort of constantly-updated post that contains percentages done for various areas of the mod toward the next release, but I don't know how to do it.

      Potential members must be fully informed that if they can't meet whatever deliverables they are tasked with that they have to be able and willing to hand over the work they have done and keep everyone informed. In fact in a situation like this making sure team members' work is transparent is very important. Team members should keep the team updated at all times as to the status of their tasks. There should be no reason to hide what work is being done from the team.

      I don't really have advice on how to make and stick with decisions. I guess this is just something that you learn through experience. There should always been room for improvement, but there is no need for endless debate about things where no new evidence is presented. Change control is important; you don't want the scope of the project to keep creeping, either.

      Stay as light-hearted as possible. Learn what makes the team members happy, and try to give it to them. Make sure everyone stays civil. Jerks and people who are simply not nice to others do not make for a happy or productive team. The skill that they bring is not worth the problems with other people. Personality is important. Some people just do not play well with others.

      Khelvan .
      Europa Barbarorum.

      Posted from the .Org with permission.




      Dol Guldur

      TOP NINE REASONS WHY MODS NEVER GET FINISHED


      Unless you are a glutton for wasted time and effort you probably want to actually finish the mod you begin. This article is a practical (and quite opinionated) look at how to finish mods by planning in advance. Why such an article? If you are new to TW modding you may be unaware of all the forums, threads and even mod-specific web sites that have "died" over the past couple of years or more. Their numbers are testament to the failure of mod starters (modders or non-modders) to finish. One can only imagine what might have been achieved had things been done more wisely.

      Before we get into what it takes to finish a mod we should probably say that there are different types of mod. Let's take a look at them first:

      1. Enhancement Mods - these enhance the original (aka vanilla) game by improving or correcting certain aspects of it. This may range from tweaking the AI and correcting annoying bugs to full realism mods where much of the visual and textual elements may be improved and changed to reflect a more historically-accurate game. These can be some of the quickest mods to make, but the full realism ones may take almost as much effort and time as Full Conversions (see below) if the mod team are dedicated to detail.

      2. Game-Era Mods - these are modifications which convert many aspects of the game into a period of history either similar to the vanilla or one which focuses on an area of the vanilla. These can vary in terms of time and effort but are generally the ones that tend to get completed a lot quicker than Full Conversions or the larger Realism mods.

      3. Full Conversions - these endeavour to totally change every or nearly every aspect of the game, not in terms of enhancement but in terms of total change. They are sometimes called Total Conversions. They take the vanilla game engine and seek to create a world very different from the era of the original game. Such conversions may be based on known sci-fi or fantasy worlds, mythology or just from original imagination. These kinds of mods need to be most carefully thought about in the planning stage because they will eat up a lot of time and effort to complete.

      This article applies least to the more narrow of the enhancement mods, and most to the full conversion - but I think all modders and would-be modders can benefit from it (I hope). I'm going to use the example of the Fourth Age mod because (a) Middle-earth is a world that most people are basically familiar with compared to other fantasy/sci-fi worlds, (b) it falls into the total conversion category and (c) I am personally familiar with the history of that mod and so can share examples of things we did right and things we did wrong...

      Now, as to those reasons why most mods sink into the sea of oblivion...

      REASON #1: SETTING SIGHTS TOO HIGH

      Unless you've been seriously modding the Total War engine for at least a year you probably have little idea about how long things take and what's involved. It's not just a case of the obvious: research, code, model and create artwork. There's also testing, balancing, mod and forum management, dealing with feedback and tech. support, installers, tools, and a whole host of other issues that are not maybe so obvious when you start or want to start a mod. An don't assume that fans and "the public" will flock to support you in practical terms. Most just want the mod to play. They won't want to learn new skills or be involved in tedious tasks such as thorough beta testing. Your team will likely have to do all the most important work even in that regard. Make sure there is someone on your team - or at least advising your team - who has experience about how long things take. This is critical.

      The Fourth Age probably wasted almost a year because of our initial unawareness of such things.

      REASON #2: IMMATURE TEAM MEMBERS

      Someone once said that character can be defined by following through on your decisions once the emotion of making them has passed. We've all committed to things we've then given up on - no one's perfect. But completing a mod will need to see a good few members on your development team who are of a maturity that will not give up after a few weeks or months. I suspect that most mods that languish and pull through do so becuase they have more mature members in their make-up. It is not entirely bound to age of course, though by and large the older members will be more mature in this regard.

      REASON #3: A MODDING TEAM WITH NO UNITY

      Every member of your team should understand that they will have commitments for a couple of years, and for at least 5 hours per week (managers more). Mod teams must be cohesive and working hard is a good way of achieving that. Those who do not put in the time and effort will drag down those who do and these former should be removed (or not hired in the first place) and put in an outsource or support capacity. Members who are lazy or who have very limited time can even frustrate some modders enough to leave the team - and that is just not worth it. This happened to us at least twice at the Fourth Age and each time we lost good modders. It is often the best modders (who tend to have the higher temperament ) that get affected by the laziness (real or imagined) of others on the team.

      Of course, many can help as outsource support such as voice actors, concept artists, composers, LOD makers, etc. Some may be freelancers. The principle is - whether outsource or team member - that a person's circumstances should be known and their commitment made and completed every week. As long as people abide by their commitments things usually go smoothly.

      Now at the Fourth Age we do not accept new members onto the team off the bat. We put them in Outsource support and if, after a few months, they prove diligent and constant we take them onto the team. Past experience has shown us that the majority of people who join a mod team off the bat (with no trial period) leave after about a week. It's true that many don't complete the trial period but a core committed team of 4 is going to work better than a core committed team of 4 with 4 others doing little.

      REASON #4: TAKING ON MEMBERS THAT REQUIRE TOO MUCH WORK TO NURTURE

      Some would-be modders are of the opinion that they can only be a good modder if they have a personal mentor. Sometimes we even see people launch mod ideas and plans and then announce that they have no modding skills! Generally they do not read tutorials or get very confused if they do try to follow them. My advice is to avoid such individuals and get them to help out in a way that suits their acumen. They will waste a lot of your time if your try to help them. Modders, imho, need to be self-educated and have initiative. Sure, a lot can be learned from discussion on modding forums with other modders but the real learning comes from our own volition.

      Be cautious of those who want to help but say they have no modding skills but are willing to learn - why did they not learn an aspect of modding first if they are so interested in helping? There are plenty of good tutorials to become a good anc/trait coder, a good tech-tree coder, a good texturer, a good modeller, a good audio coder, a good 2D artist, a LODer, a mapper, ad. inf!

      REASON #5: NO RELEASES

      Morale in a mod team (and among those who support the mod) will be best secured by making sure you have some releases. A year without any release is going to see morale plummet and team members leave. Your first release might be a custom battle to showcase your work, maybe a historical battle too. See Reason #6 for more advice on how to make sure releases are forthcoming.

      REASON #6: FAILURE TO PLAN

      I've mentioned this here because it deserves special attention though it certainly overlaps with Reason #5 and Reason #1.

      When the Fourth Age firmed up its ideas back in September/October 2004 (just a few weeks before I joined) it decided upon setting the mod in the entirety of the map found in the LoTR novels. And there was no limit I remember as to the culture/faction slots which were to be used. When it dawned on us that we could not have two very different factions in the same culture slot (because of shared portraits etc.) we adjusted downwards but it was not until December 05 that a decision was made (after some weeks of discussion as to the viability of finishing 14 (I think) factions and the entire map) to focus on a part of the map and get that completed first.

      So much more could have been achieved if we had come to this decision a year before. My advice here is more for full-conversion mods but I think it is very important. The principle is simply to identify the smallest self-contained and playable area of the mod you would ideally *like* to complete and then work on that area as if it was the entirety of the mod.

      This is what we did with Corsair Invasion and got it done in 11 months (estimated 3000 hours of work). For a TW mod I would advise the following:

      * select 5 factions that can fit into no more than 3 cultures
      * select an area of your map of no more than 50 regions
      * If possible, select cultures that most nearly approach vanilla cultures
      * focus only on modding units, code and the strat map (don't worry about battlemap buildings/settlement plans)

      This may not seem like much but it will probably still take you a year if you intend to make a good job of it.

      Once it is complete you may reassess your goals and team strength and decide to quit or to do something different or to add more to the campaign to work towards your original 'big picture' mod.

      REASON #7: BAD ORGANIZATION

      Bad organization on a mod team ends up with very buggy releases (if any releases at all). Why? Well, let's look at how an organized team would work...

      Each member, when they complete their assignment, should (after approval of the design or art director) pass it along to the Build Manager (the person who maintains the whole build of the mod). They should have tested it (if possible) before handing it over. The Build Manager can then add and test it in the full build. A Build Manager must be intimately aware of the files and be a good bug tracker and squasher. Coders need to make sure they do not overwrite the work of others and so it is important that if a file needs to be changed in order for a coder to get something in his area of files to work then he *not* make the change but get the person maintaining that file to make it (though the Build Manager will often be that person).

      On the Fourth Age we have 4 coders - an audio coder (whose work is quite independent of other files), a trait and ancillary coder, a map coder and the one who does everything else who is also the Build Manager. If the Map Manager wanted to change the name of a settlement, or the tech-tree coder (the Build Manager in this case) the name of a building this might affect the coding of the anc/trait coder who may reference that settlement name or building in their code. So the map manager/tecth-tree coder does *not* alter the anc/traits files but informs the trait/anc coder of the change or submits his code to the Build Manager with a note that files not under his jurisdiction need changing. The Build Manager may be the one maintaining those specific files at that time or it may be the assigned coder.

      Not keeping track of such things is bound to cause loss of work (by one coder overwriting the work of another or rendering the work of another unuseable because changes cannot be identified) or - potentially even worse - create bugs!

      Of course, the best releases will have some bugs in them and probably even fatal ones. There's a lot that can go wrong. But being very caerful in coding and testing almost everything as it is coded will greatly reduce the occurence of crashes. Don't code a page of coding and then test - it may take you a lot longer to track down the cause of a CTD than it would have done to code in smaller steps, testing after each. Some files are very sensitive, even a missing space or comma can cause a CTD with no error message to help!

      When things get too buggy it can cause members of your team and players to lose interest. And on a side point, don't release buggy betas. All releases should have a basic team-tested integrity regarding fatal errors.

      REASON #8: NO MODDERS ON THE TEAM

      Historical/milieu research, nice concept art, nice visuals, nice music...all of these are not worth much unless you have some good strong skilled modders onboard. Map makers, unit builders, tech-tree coders, 'traiters', game mechanics researchers, code researchers, etc. - these are the ones who produce the glue to bind everything together so that it is in the right place and firmly held. This is where the bulk of the modding time will be in any mod. This is where the frustration and energy will circulate. Better to have these guys with you and doing some of the graphics and research than a whole bunch of historical experts or designers with imaginations that have no concept of hardcoding.

      Many people have offered their services to the Fourth Age, claiming that although they do not know how to mod they have read the LoTR books - we're grateful for their support but that stuff has been long-since covered and, besides, the existing team is made up of members who have all read the books (some of us quite a few times!).

      Don't launch mods with no modders!

      REASON #9 : UNFOCUSED TEAM MEMBERS

      Unless team members stay focused and pay attention errors will creep in. If someone on your team does not even know which of your modded factions match up with the vanilla internal faction names then you probably ought to downgrade them to outsource. Your team need to be on the same page - not in a different book or even in an entirely different scriptorium altogether


      This article is posted here for comment and improvement. It is written as I thought it and has not been revised; and indeed is in much need of it.

      Dol Guldur
      Fourth Age....


      Posted from the .Org with permission from DG.


    • Mod Public Relations:
      Click to view content: 
      BdCSo, you’ve completed your mod, unit descriptions, models, it even has its own flashy installer with simple instructions which most won’t follow anyway. But if you don’t spread the word many people won’t even spend the hour or two it takes to download and try it out.

      In fact, without good PR you probably won’t even manage to get your mod off the ground in the first place. Public interest won’t only keep your valuable (and I bet very few) team members motivated, it may very well attract new artists, and even experienced modders. People don’t join modding teams for life, and when they feel their work is done they move on, looking for projects that interest them, ones that are seriously led and with members that get work done.

      First, it is better to have one person take over all the PR stuff, usually the mod leader. It’s up to that person to make all the important announcements, whether it’s posting new screenshots or revealing future plans. You can’t have various artists-team members posting uncontrollably, even if it is their own work; looking professional is very important, even if you are just making a mod.

      Getting your own webpage is taking it a step further. Usually a room in the .org and/or the twc is more than enough to get people from the total war community interested, but why stop there? A proper website will allow your mod to reach gamers outside of the twc series, whether its fans of Boudica, Tolkien or Bonaparte. Of course, the servers would have to be paid, and advertisements, if you chose to allow them, probably won’t cover all the expenses.

      Ok, screenshots are very important, we all know that. You can post the most eloquent announcement about your team’s work, but if you don’t have pics “it never happened”. But if a picture is worth a thousand words, what about movies? Yes, making a short promotional film of your mod is the hardest yet most rewarding of all PR endeavors. It allows you to showcase all the work you have been doing for the past months, nay years, with action filled scenes displaying the graphics and the gameplay, all accompanied by a riveting soundtrack. It would be hard to imagine that a modding team would be able to attract professional interest (and start its own company!) without the following videos:

      http://www.youtube.com/watch?v=QW3ZBBBga4I

      http://www.youtube.com/watch?v=zu9LFF8rMqs


      But, regardless of how ambitious you are, good public relations are a necessity. Without it you will have a difficult time finishing your mod, and no chance in getting people to try it when it’s done.

      -BdC, NTW2


      Empress MegThe final texture has been rendered, the last script written, and the mod folder ready to be shared with the general public. It feels great when you get a finished product, but that doesn’t mean that your modding work stops there. If you want to share your modification with other people, then you need to do a bit more leg work.

      Your Manner
      When you write to other forums, heads of other mods (unless you know them personally), answering questions from fans, or are writing an official announcement for your modification, be aware of how you write it. Your manner really has an affect on how people perceive you and therefore your mod. Grammar, spelling, and tone all play a part in how people see you online.

      Try to write clearly; don’t worry about sounding impressive or well learned, just make sense! If you need help doing this, say English is not your first language or your spelling frightens spell check even, then ask for help. There’s nothing wrong with trying to make sense out of some seemingly silly words. (They’re there with their hair.) Ask another member of your team for advice or think about getting a PR person who will help to ensure your mod appears stunning in print as well as ingame.

      Keep your tone friendly and polite and your answers or statements clear and concise. Keep it easy to understand and you should have people willing to voice their own opinions on your mod providing valuable feedback.

      Always remember to provide contact information, links, and screenshots as required in each situation. If you find yourself encountering commonly asked questions, you may want to think about creating a FAQ to cut-down on time spent typing replies, see below.

      FAQ
      When something doesn’t work properly the first time, people get a bit upset. If the answer isn’t easily found it can really cause some issues, maybe even turn them off your mod completely. One of the more prudent things to consider is making a FAQ containing common questions. Save yourself the time of typing out the same reply to the same question asked fifteen times that month and link to the FAQ instead. It’ll provide smart users their answers quickly and will help cut down on the time it takes you to answer questions.

      You can easily create a FAQ before the final release of your modification; place one up when you release your mod to cut down on the prevalent mishaps. A FAQ can always be added to later on as more questions appear.

      Clear, well written Tech Help/Installation Instructions
      People who want to play your mod need to be able to install it after all, and any hard to read or unclear installation remarks won’t help them do this. Things to consider are:

      -Other installations needed to run the mod. Patches (for the game itself), previous patches for the modification, or other mods for instance. Provide links where necessary.
      -Where the file should be installed.
      -A link to any archival program needed to “unzip” the mod, like Winrar.
      -Where a user may find help if required (contact info, a website, or forum).

      Advertising
      Once the mod is ready for people to download you need to get the word out so people can try your mod. Many game forums and fansites allow for the announcement of a new modification release. (Be sure that you check with a site before you post any PR announcements, as some sites prefer not to advertise.)

      Places like the Org and the TWC have a dedicated space for community news and announcements including modification progress reports and release mentions, so make sure that you use them! Provide a small PR notice to be placed up on the site frontpage, including a screenshot or two and a link to your download page, remember to be concise.

      Other ways of advertising your modification in addition to the larger PR announcements include signatures, avatars, screenshots captures or videos, and word of mouth.

      Other Forums (or fora if you like)
      A forum is a great place to advertise, just make sure that you are allowed! Pick a message board that you know deals with TW modifications. The Org, the TWC, the official TW forum and site, the Heaven sites all have bustling community boards with people eager to get their hands on a new mod. Make sure that your PR information is clear, with links and details on how to get your mod.

      Personal Forum
      Many larger mods have their own site and forum. This is a plus because it allows you the freedom of not depending on other sites that may or may not host your mod, or won’t allow advertising. This is expensive though and time consuming. A website and forum oftentimes requires its own little team to help run it so as to not take away from any work on the modification.

      There are of course many free forum sites out there with various modules to help make your forum unique. There generally are space limitations that come along with the “free” aspect of the board, but it is a forum, it is your own and it is perfect for a centralized location to compile modding work and the community that follows your mod.

      The Hosted Forum
      On the Total War Center modding teams have a great opportunity to ask for a hosted forum. Grant it, these sub-boards for larger modifications but they are something to keep in mind if you want a space of your own without having to worry about setting up a forum from scratch. If you think that your modification has gotten large enough to warrant its own hosted forum at the TWC, get in contact with an administrator and they’ll help you through the process.

      Screenshots
      I think that you can find a wealth of information in the Picture of the Week forum at the TWC, but in the meantime some basics principles.

      -Get acquainted with the TW movie cam. Take screenshots from a replay game, this way you can pause, move around, and snap the best position and image possible for your announcements.

      -Put the detail settings as high as they will go, you don’t need to worry about lag getting you killed here, this is for publicity.

      -Use a picture capture program like Fraps instead of the built in screenshot button. It’s much easier to have Fraps running in the background to snap images then it is having to press a button, leave the game, save it, and hop back into the game.

      Movies
      Place them on Youtube and off you go! These take a dedicated person or persons to create. They aren’t easy but boy do they bring in a lot of interest. If you have someone on your team who has the skills to create a short film to display the qualities of your modification, don’t turn them down. Work out a story board and get the thing done and floating round cyberspace.

      Mod-related Avatars and Signatures
      These can be done by nearly anyone. If you have a 2d artist who is waiting for the new model to come to him why not have them make an avatar or two while they wait? Or, if you have a researcher who wants to try their hand at modding, this is the perfect step to get them familiar with GIMP or Photoshop without putting too much pressure on them to create a top-notch texture.

      Just make sure that the avatars and siggies are the correct size and style for the forum they are being made to grace. You don’t want to have siggies not be used just because they don’t prescribe to a certain forum’s specifications!

      Word of Mouth
      This happens naturally. Don’t worry about it, if you’re done your homework and spent time in dealing with some of the other ways to spread your mod around this will come. Just be ready when it does and provide support and tech help and friendly answers in turn.

      Useful Links
      Fraps (for screenshots or videos if you so choose)
      http://www.fraps.com/

      Image hosting sites
      http://photobucket.com/
      http://imageshack.us/

      Filefront: Great for uploading anything from single pictures for a PR announcement to the very largest of module folders.
      http://www.filefront.com/

      Other sites which allow larger folder uploads:

      http://rapidshare.com/
      http://www.megaupload.com/
      http://www.mediafire.com/

      Winrar (archiver program)
      http://www.rarlab.com/

      Places TW related that will upload and host your modification for you.
      http://rtw.heavengames.com/
      http://medieval2.heavengames.com/
      http://www.totalwar.org/
      http://www.twcenter.net/

      Empress Meg, NTW2


    Useful Modding Tips:
    Click to view content: 

    1. ALWAYS make backups of the files you are about to edit, even if it will be the most trivial change. The amount of time and energy that you will spent afterwards trying to fix a possible error is nothing compared to the time it will take you to copy the files somewhere safe. Plus, if your pc crashes or anything unexpected happens, you’d bless your luck for having these backups.
    2. Test your modifications little by little. Don’t wait to test something after having spent an hour on it. If something has gone bad and you’ve made a simple mistake, it will take you ages to locate it, thus wasting valuable time. Every time you edit something, go in-game to see if it works and then go back to keep messing with it.
    3. Make regular backups of your entire modding material, be it a whole modfolder or just the 4-5 files you have been working on. Many mods have failed simply because a disk crashed and all the data was lost, so do yourself a favour and keep an up-to-date copy somewhere safe.
    4. Take the time to make a proper search. Got stuck and can’t find an answer to your question/problem? Before asking others or just giving up or trying random things, make a good search over the net. There are tons of tutorials and threads out there, waiting for people like you to read them. Chances are your problem has already been encountered by others and a solution already made known. You just have to look for it. And don’t expect others to do your work for you; you are a modder, and proper research is part of being one.




    Command line switches: (Link 1, Link 2, Link 3)

    • What are the command line switches?
      Click to view content: 
      Command line switches are "commands" for the game that force it to do a specific thing or change its behaviour in a specific way. They can be extremely useful, so learn how to use them to your advantage.
    • How do I use the command line switches?
      Click to view content: 
      Double-click on your RTW shortcut and select ‘Properties’. In the menu that appears, the first Text box line is named "Target". The command line switches are added at the very end of the line, after the closing quotation mark ("), being separated from it and from each other by a space character.
      Click to view content: 

      Image 1: Note how multiple switches can be used, and how they have to be added at the end of the target line, separated from each other and the rest of the code with spaces.

    • Which are the command line switches?
      Click to view content: 

      There are quite a few of them, but the most commonly used and more important ones are:
      • -show_err: Shows an error message for basic errors when an error is detected or when you exit the game, with some information about it. The message will not come up for all errors, sometimes it is useless in terms of info and it only reports the first error encountered, but still it is by far the most valuable command switch for debugging and one that you can’t go without. Use it!
      • -mod:my_mod: Allows to load data from your own modfolder, where my_mod is the name of that modfolder. Extremely useful, allows multiple mods and vanilla to work on just one RTW installation and makes organisation of your mod easy (see Modfolder section). Use it!
      • -multirun: Allows multiple instances of the game to be run at the same time.
      • -ne: Allows RTW to run in windowed mode. You can switch back and forth between it and other applications instantly by pressing alt+tab and the game will keep running at the background. Very useful when you’re testing for long-term bugs or campaign balance under the -ai command (see below)
      • -nm: Disables all videos, including the introductory videos and the menu background video. Speeds up loading significantly and saves you time (you’ll understand after the 100th time you start up the game to test something)
      • -na: Disables all audio.
      • -sw: Runs the game with no video at all, only sounds.
      • -ai: Allows AI to take control of all factions after you start a campaign. The player cannot interfere and all battles are automatically resolved. Very useful for testing campaign balance, long-term bugs or AI expansion behaviour.
      • -strat:campaign_name: Skips all the menus and immediately starts a new campaign, where campaign_name is the name of the campaign subfolder within data\world\maps\campaign that you want to load. This is useful for repetitive testing of the campaign, saving you clicking time.
      • -enable_editor: Enables the historical battle editor, a link for which will appear in the Options screen of your game.
      • -sprite_script: Disables the game, but allows to generate sprites, using a sprite_script.



    Last edited by Aradan; June 22, 2010 at 12:35 PM.

  3. #3

    Default Re: Beginner's Modding Manual (RTW)

    Step 1: Creating the modfolder
    **Note: We need a completely CLEAN installation of RTW for this, so make sure you have one.

    Click to view content: 
    The modfolder is a folder that exists inside the main RTW directory (or its Alexander or BI subdirectories) which holds all the files of one particular mod, so that the game’s original files are not altered/replaced when the mod is installed. The files and folders inside the modfolder are structured exactly as they are structured in the main RTW directory. Using the modfolder method saves you from having multiple copies of your game engine installed on your hard drive, taking up lots of space and ultimately affecting your pc’s performance. Modfoldering is a very effective solution to this problem, and is the standard today for any mod. Setting a modfolder up is the very first step of making a mod, as it saves you valuable time and provides with a solid base upon which you can work later. It is not completely obligatory, but you will find it extremely useful, so do this first!

    • How does the modfolder work?

    Click to view content: 
    When a mod is launched (using its own shortcut) the game’s executable first looks into the modfolder for the files it needs to run. If a file with the same name exists in both in there and in the main game’s directory, then the game reads the one from the modfolder and ignores the other. So, the modfolder is essentially a way to override the game’s original files and make the game use our own mod files, but without replacing the former.

    • Why is the modfolder useful?

    Click to view content: 
    The modfolder is useful, because it allows you to have multiple mods on the same installation of RTW, that will not affect at all the game’s original files and will all be compatible with each other.

    • How do I make a modfolder?

    Click to view content: 
    We are going to be basing our mod on the vanilla RTW.exe, because BI has a bit more complex modfoldering procedure, so here’s what we’re going to do:
    First, let’s make the mod folder itself. Simply open your main RTW directory, and create a new folder in there. You can name it as you want, but for this lesson we will be using the name BMM in this manual. Also, for this lesson, we will be referring to the Rome’s main directory (usually named “Rome – Total War”) as “RTW”.
    Click to view content: 

    Image 1: The folder named BMM is our modfolder, anything for our mod goes in there. The main RTW directory is always the one where the RTW.exe exists.
    A modfolder can contain any text file we wish or else any non-text file which however is not declared anywhere in the text files. For example, if the game by default looks for a specific image file in a specific folder without that folder or image having been declared in a text file, then placing that image inside the modfolder will result in it being used instead the original one. But if we just replace the image file of a unit’s skin, then our new image will be ignored, because the game will read the original descr_model_battle.txt file(since we have not included that file in our modfolder), which will be pointing by path to the original image.
    So we see that unless we want to make very limited modification of specific files, we should definitely include text files in the modfolder. And since most of the text files have an effect that is actually visible during campaign then the best move would be to start our modfolder by creating a new campaign.
    **Note: It is possible that you don’t create a new campaign in the modfolder. The game however expects from each modfolder to include a campaign; in other words, if you do not include one, the game will NOT load up the original campaign.
    Creating a new campaign essentially means you need a new campaign map and its assorted files. These files are:
    a)everything that exists inside the data/world/maps/base folder
    b)everything that exists inside the data/world/map/campaign/imperial_campaign folder
    c)the imperial_campaign_regions_and_settlements.txt that exists in the data/text folder
    **Note: Remember, the folder structure in your mod-folder must be identical as the one in the game’s original directory.
    Lets do it! Inside your “BMM” folder, create a “data” folder and inside the ‘data’ folder create a folder named “text” and another one named “world”. Now go inside the ‘world’ folder, create a folder named “maps” and inside ‘maps’ create a folder named “base” and another one named “campaign”. Finally, inside the ‘campaign’ folder create a folder named “imperial_campaign”.

    Now, copy the files we mentioned above from their vanilla locations to your mod-folder. So, to reiterate, this means the imperial_campaign_regions_and_settlements.txt is copied from your RTW/data/text folder inside your RTW/BMM/data/text folder, the contents of RTW/data/world/maps/base/ are copied inside RTW/BMM/data/world/maps/base/ and the contents of RTW/data/world/maps/campaign/imperial_campaign/ are copied inside RTW/BMM/data/world/maps/base/imperial_campaign/.

    Click to view content: 

    Image 2: Note how the folder structure is identical to the one in original RTW, but everything exists inside our BMM modfolder. The contents of the folders are identical. Here are the contents of our mod's world/maps/campaign/imperial_campaign folder.

    Click to view content: 

    Image 3: Note how the folder structure is identical to the one in original RTW, but everything exists inside our BMM modfolder. The contents of the folders are identical. Here are the contents of our mod's world/maps/base folder.

    Click to view content: 

    Image 4: Note how the folder structure is identical to the one in original RTW, but everything exists inside our BMM modfolder. The contents of the folders are identical. Here are the contents of our mod's text folder.

    There you go, now you have your own mod-folder with its own map and campaign. Yes, currently it is identical to Rome’s campaign, but not for long.

    First, let’s make sure everything works as it is supposed to before we start modifying.

    • How do I launch a mod that uses a modfolder? (Link 1, Link 2)

    Click to view content: 
    Create a new shortcut on your desktop for the executable file your mod is running on. Here we are using the RTW.exe, so make a shortcut for that one. Now right-click on it and go to ‘Properties’. The top line there is called “Target” and it should be looking something like this:

    Code:
       "C:\Program Files\The Creative Assembly\Rome - Total War\RomeTW.exe"
    In order to make the game look into our modfolder’s “data” folder first instead of the original “data” folder, we will need to redirect it there. This is done by adding “ –mod:xyz” to the end of the line, where xyz is the name of our modfolder and its relative path to the main RTW directory. So, since our modfolder is called BMM and it is placed directly into the main RTW directory, the part we will add is “ –mod:BMM” and the ‘Target’ line should now look like that:

    Code:
       "C:\Program Files\The Creative Assembly\Rome - Total War\RomeTW.exe" –mod:BMM
    Click to view content: 

    Image 5: The -mod:BMM command forces the game to use our modfolder. If our modfolder was inside the bi/ directory, then the command would be -mod:bi/BMM. There are also other switches in this picture's shortcut, see the relevant section for their functionality.
    **Note: Note that the path to your main RTW directory may differ, according to where you have installed the game, but this shouldn’t matter here, because you are not supposed to make any changes to anything inside the quotation marks anyway.
    After you’ve added the command at the end of the shortcut’s line, just select ‘OK’ and you’re done.

    You now have a shortcut for your modfoldered mod. Double click on it to launch it and see if everything works all right. When you launch it, start a new Imperial campaign. If all goes well, it should load up fine and you’ll be seeing the familiar RTW campaign.

    • Testing the modfolder

    Click to view content: 
    Now we're gonna run a very simple test to see if our modfolder works properly. We are going to rename a settlement and check if this will have an effect on our campaign.

    Open up RTW/BMM/data/text/imperial_campaign_regions_and_settlement_names.txt.
    **Note: Remember that before making any modification you should backup the files you are about to change. We are making a very trivial edition now and our file is an exact copy of the vanilla one (so we can use the original as backup) and that's the only reason we are not making a backup now. But as a general rule always make backups.
    Scroll down the file or press ctrl+f and search to find this line:
    Code:
    {Rome}            Rome
    Now replace the red part with "Roma Invicta" (without the quotation marks), so that the line looks like:
    Code:
    {Rome}            Roma Invicta
    Be careful to not delete any tabs or spaces, only the text itself.
    Click to view content: 

    Image 6: Edit just the right-hand entry, NOT the one on the left, just like that.

    Save and exit. Launch your mod by double-clicking the shortcut you made in the previous step. Start a new Campaign and take a look at the settlement of Rome. If all went well, the settlement should now be named "Roma Invicta" instead of "Rome" as it was in vanilla.
    Click to view content: 

    Image 7: As you can see, Rome's new name now is "Roma Invicta", our modding was successful.

    If this is so, congratulations, your modfolder works and you have already made your first modification of the files! If not, then something went wrong, so you had better start all over and be careful to do everything as described. Don't despair, modding involves failure as well, it's the determination to keep going that counts.

    • Working Example

    Click to view content: 
    You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.

    Last edited by Aradan; January 31, 2010 at 08:49 AM.

  4. #4

    Default Re: Beginner's Modding Manual (RTW)

    Step 2: Editing the map
    **Note:For this part of the manual, a 2d-editing software like PhotoShop, PaintShopPro or Gimp is required. PaintShopPro was used for this tutorial, so some tool names or functions might be slightly different on other software or other versions of PSP.
    **Note:We are going to be testing things a lot in this part and we will often need to start a campaign, so it would be very useful and time-saving if you added the “ -strat:imperial_campaign” command to your shortcut. That will make the game load directly the main campaign every time you start BMM.

    Click to view content: 
    A map is a mix of various kind of elements, including information about the landmass placement, the ground height, the ground types, the placement of rivers, cliffs and volcanoes, the arrangement of regions settlements and armies and so on. There are several files that govern all the above aspects of our map, located in the world/maps/base/ and the world/maps/campaign_imperial_campaign/ folders, and also the imperial_regions_and_settlements.txt inside the text/ directory. Here is a list of them, along with a brief explanation of each one’s purpose (a detailed one will follow when each aspect is examined):

    Text files:


    • descr_disasters.txt - Contains the list of the possible disasters (earthquakes, floods, etc)
    • descr_regions.txt – Contains the list of all the provinces on the map, with information about each one (RGB value, settlement, resources etc)
    • descr_terrain.txt - Contains the info about the dimensions of the map.
    • descr_events.txt- contains the list of pre-defined events that happen in game (date, location etc).
    • descr_mercenaries.txt - Contains the list of mercenary pools and relevant data (available mercs, cost, replenish rate etc)
    • descr_strat.txt - Contains info about the campaign (start/end date, options, playable factions etc), a list of all the resources on the map and their locations – including landmarks/wonders), a list of all settlements, armies, characters, agents and family trees listed per faction and the faction starting relations.
    • descr_win_conditions.txt - Contains the victory conditions for each faction
    • imperial_regions_and_settlements.txt - Contains the list with all the regions and settlements both internal (used by the game) and external (appear on screen) names
    • descr_regions_and_settlement_name_lookup.txt – Contains a simple list of all the regions and settlements names of the map (unused, for reference only)
    • There are other text files (descriptions), but they are redundant, so just ignore them.



    Image files:


    • map_climates.tga – It must be twice the size of map_regions.tga +1 pixel in both dimensions. This is where the various climate types on the map are set, with each one of 12 specific RGB values indicating a different climate type.
    • map_FE.tga - Appears in the place of the faction’s map on faction selection screen, when no map exists for a faction.
    • map_features.tga – It must be the same size as map_regions.tga. This is where the positions of rivers, crossings, volcanoes and cliffs are defined.
    • map_ground_types.tga - It must be twice the size of map_regions.tga +1 pixel in both dimensions. This is where the various ground types on the map are set, with each one of 14 specific RGB values indicating a different ground type.
    • map_heights.tga - It must be twice the size of map_regions.tga +1 pixel in both dimensions. This is where the 3D aspect of the campaign map is defined, with various RGB values (always shades of grey) indicating different height.
    • map_roughness.tga – It must be twice the size of map_regions.tga, but seems to be unused otherwise.
    • map_trade_routes.tga – It must be the same size as map_regions.tga, but seems to be unused otherwise.
    • water_surface.tga - This is a texture for the surface of the water on the campaign map.
    • map_regions.tga – It must be the size defined in desr_terrain.txt. This is where the regions of the map are defined, with every different RGB value indicating a different region, 2 extra RGB values used for settlement and port locations and another RGB value for the sea.
    • disasters.tga – It must be the same size as map_regions.tga. Contains the locations on the map for the different disasters.
    • leader_pic_faction_name.tga – where faction_name is the internal name of a faction (ie greek_cities). This is the portrait for the first leader of that faction.
    • map_faction_name.tga - where faction_name is the internal name of a faction (ie greek_cities). This is the image that appears on the faction selection screen a faction, usually showing which regions it controls on campaign start.
    • radar_map1.tga – It must be 255x156 pixels. This is the minimap for the campaign, when it is not zoomed in.
    • radar_map2.tga – It must be 510x312 pixels. This is the minimap for the campaign, when it is zoomed in.



    Other files:


    • map.rwm – This file contains a compilation of the campaign map’s data. When a change is made in one of the map files, it must ALWAYS be deleted otherwise the changes will not take effect. The engine will generate a new one with the updated info the next time a campaign starts.
    • map_heights.hgt – Unused for RTW 1.5 / BI 1.6. It is a “packed” version of map_heights.tga, now redundant. As long as it exists, the game will read this and not the .tga file, so it should be deleted.

    **Note:Some of the files listed above can exist in either of the “base” or the “*campaign_name*” folders (here campaign_name is imperial_campaign), but we will be following vanilla’s setup here.

    • Creating a landmass

    Click to view content: 
    Now that we roughly know what each file is useful for, it’s time we go on to modify our map. Obviously most of map-modding takes place on land. Since this is our first effort at this, we don’t want to mess at all with the existing land of our map, so what we are going to do is create a new landmass for ourselves to experiment with.
    **Note: Remember to ALWAYS back up the files you are about to change!
    Creating a new landmass mainly involves “raising” a part of our map from sea level to ground level - while removing it involves sinking it back in. This, as you may have guessed by now, means that we must edit the 3d aspect of our map, which is the “height” aspect. This aspect is governed by the map_heights.tga file. Open up the file with your 2d-editing program. Now, select a very dark shade of grey (grey colour means that Red, Green and Blue values of the colour are the same – ie ‘2,2,2’). I am using (8,8,8), but you can use anything close to that. Now go to the area between Hellas, Sicily and Cyrene and use that colour to paint a rectangle, the one I painted has its corners on the following pixels: top-left (233, 232), top-right (251,232), bottom-left (233,249) and bottom-right (251,249). It might not be an exact square, but we’ll call it a square for now. Fill the entire area between these pixels with the colour you chose. The file should now look like this:
    Click to view content: 

    Image1: A simple black square in a dark shade of grey (8,8,8)

    That’s it, save and exit.

    Every time you make a change in one of your map files, don’t forget to delete the map.rwm file, otherwise your changes will not take effect. So, delete map.rwm now.
    Let’s see if what we did was successful. Fire up BMM and start a new campaign. Loading will take a bit more than usual, because the engine is creating the map.rwm file with the new data in it. Once the campaign loads, go check the area between Sicily and Hellas. If you did everything right, you should be seeing a large, empty, flat piece of land that wasn’t there before, like that:
    Click to view content: 

    Image2: The new landmass should look like that, a flat and empty square of land.

    Ok, first part is done; we have created our new landmass. Let’s go back to mess with it some more now.

    • Editing heights

    Click to view content: 
    Now it’s time we modded the 3d element of our map; we are going to do a bit more complex heights editing by sculpturing the ground a bit so that we create a mountain of sorts, a part of land where the ground will gradually rise.
    **Note: The map_heights.tga file does not control the appearance (ie textures) of the ground, only it’s elevation. So, an elevated part of land on heights.tga will not be snow-capped or textured like a mountain, only it’s actual height will change.
    Again, open map_heights.tga. Find an area close to the centre of the large square we made earlier and preferably a bit to the left. Now select a shade of grey that is lighter than the shade you used for the square; I am using (53, 53, 53), you can use something different.
    **Note: Remember to use only shades of grey on map_heights.tga (ie Red=Green=Blue). Do not use (0,0,0) as the engine thinks that this colour is sea. For sea use only shades of blue (Red=Green=0, Blue=Anything not 0); values from (0,0,253) to (0,0,230) are mostly used)
    Make a smaller rectangle (it is sized about 9x8 pixels in my map, but you can use something different). This new rectangle that is using the lighter shade of grey will make the ground at this area on the map rise higher than the rest of our large square around it. Now, choose an even lighter colour (always a shade of grey of course) and make a second, smaller rectangle inside the first one. Then again lighten the colour even more and make a third rectangle inside the second one, and then in that way make one final rectangle inside the third one. The result should look like the image below:
    Click to view content: 

    Image3: As we go, we make the colour lighter and the rectangles smaller. The lighter the shade of grey we use, the higher the ground will rise at that point on our map.

    The gradually lightened colours we use should produce a gradually elevating part of land that will resemble a mountain or a high hill (the actual height depends on the RGB values of our colours – the lighter, the higher). Let’s see in-game what we have made. Save and exit the image. Once again, delete the map.rwm file and fire up BMM. Our new landmass should now look something like that:
    Click to view content: 

    Image4: Indeed, making our colour gradually lighter has produced a smooth elevation that created a hill of sorts.

    Great, our height-editing is done for now. Let’s go to something else.

    • Editing ground types

    Click to view content: 
    It is time now to change how the ground on our new landmass looks. There are 14 different ground types in RTW, ranging from ‘high fertility’ to ‘swamp’ and from ‘high mountains’ to ‘dense forests’, each one represented by a unique RGB value on map_ground_types.tga. Here is a list of each ground type and its respective RGB value:

    • Fertile Low - Grey-Blue (0, 128, 128)
    • Fertile Medium - Light Green (96, 160, 64)
    • Fertile High - Olive (101, 124, 0)
    • Wilderness - Black (0, 0, 0)
    • Mountains High - Light Brown (196, 128, 128)
    • Mountains Low - Brown (98, 65, 65)
    • Hills - Olive-Brown (128, 128, 64)
    • Forest Dense - Dark Green (0, 64, 0)
    • Forest Sparse - Green (0, 128, 0)
    • Swamp - Bright Green (0, 255, 128)
    • Ocean - Dark Maroon (64, 0, 0)
    • Sea Deep - Dark Red (128, 0, 0)
    • Sea Shallow - Red (196, 0, 0)
    • Beach - White (0, 0, 0)


    As you may have noticed, the ground type that covers our new island is currently “low fertility”, even though we did not set this anywhere. That is the type the engine uses by default for any landmasses for which the ground type has not been defined. Now, we are about to change that. The low mountain we created in the previous step still looks like an elevated grassy plain and that’s because as far as map_ground_types.tga is concerned, it’s just another part of ‘low fertility’ ground. We need to change that.
    First, we somehow need to know exactly where the ground on our map has been altered (ie which pixels comprise our large square and which ones comprise the smaller rectangles on map_heights.tga), so that we can accurately know which pixels on map_ground_types we should change.
    **Note: There might be more than one ways to do the following, I will be using the one I judge to be easier and faster at this point.
    Open up map_heights. Using the selection tool mark exactly the large, dark-shaded rectangle that makes up our landmass. Once accurately selected, go to the menu-bar and then ‘Selections->Save to Disk and save the current selection somewhere, under the name sel_1 (for example). Now repeat this for the larger of the small rectangles, then for the second one and so on, until you have saved a selection for each one of them. Exit the file without saving.
    Now open map_ground_types.tga, go to the menu-bar, ‘Selections->Load from Disk and load the first selection you saved (sel_1). On your image you should see now the frame of a square, at the exact location and size of our large black-ish square map_heights. That’s the area we need to paint. We want to make this area be a medium fertility ground, so change your current brush colour to the appropriate RGB value for that ground type (consulting the list above will show you that this is (96, 160, 64). Once the colour is set, use the Flood Fill tool and paint the whole framed area in that colour. That’s it, now our entire island is “medium fertility” ground.

    But we are not done yet, there is still our mountain to do. In the same way we just used, load up the second selection you saved earlier, the one that corresponds to the largest of the small rectangles. Once you load it, you’ll see again a small frame, indicating the area we raised on map_heights.tga. We want this to become “low hills”. So, change the colour to the appropriate one -(128, 128, 64) in this case- and fill the framed area with it. Use this ground type (hills) for the second rectangle as well.
    **Note: Always remember when editing map_ground_types.tga: Only pixels with odd numbers for both dimensions (eg 123, 389) really matter as to what will appear in-game on the map. For example, if you paint a single pixel with the high-mountains RGB value and this pixel is, say, (231, 268) you will not see anything different on your in-game map, because in that case the vertical dimension pixel is even-numbered. If, you do the same but use a pixel like (231, 269) however, where both pixels are odd numbers, you *will* see a single high-mountain pixel on your in-game map. So, actually out of a 2x2 square of pixels, only 1 of them us useful and will translate accurately into our map.
    Our various height “levels” of the mountain in map_heights.tga only differ by 1 pixel (at least in my version of it), so if we used a different value for each one, every line or column being at an even-numbered coordinate would be ignored. That is why we are using the same ground type RGB value for every two “zones” in this example, so that we have no information loss. Of course, if on your map the different height-zones are more than 1 pixel wide, then you can apply a different ground type to each zone.
    For the last two rectangles, repeat the same procedure, but use the ‘low mountains’ ground type, which is the (98, 65, 65) colour. Finally, after you are done, paint a 4-pixel wide frame surrounding our island using the “shallow sea” ground type - (196, 0, 0). After you are done, your map_ground_types.tga should look like that:
    Click to view content: 

    Image5: Different RGB values represent different ground types. Our island is “medium fertility”, with the immediately surrounding waters being “shallow”, the feet of our mountain are “hills” and the rest of it is “low mountains”.

    Let’s now check what all that works looks like in-game. Save your file and exit. Delete map.rwm, as usual, and start up BMM. The island now should be looking like that:
    Click to view content: 
    Image6: Notice how the textures have changed now; the feet of our mountain are ‘hilly’ and the top is grey, like a proper mountain should be. If you want to check this by getting a character on the island by ship, you will notice that a) the waters near the island allow faster travel because they are “shallow sea” and that the top of the mountain is not accessible, because it has now become (low) mountain.

    Ok, we have made our island look more natural now by changing the ground types. Now, if you like, you can experiment a bit on your own. Put some pixels here and there on the bottom-left corner of the islands, using the (0, 128, 0) RGB value. That should create a bit of sparse woodland at the southwest corner of our island. Remember that only odd-numbered pixels (both dimensions) matter. And of course always remember to delete map.rwm after changing any map files, if you want to see the effect of your editing.

    • Editing features

    Click to view content: 
    Our island looks a bit empty now, so it is time we added some features to make it come alive a bit. Features are added in map_features.tga and include mainly rivers, but also cliffs and volcanoes. A river on map_features must consist of a pixel indicating its source, a continuous line of pixels indicating the body of water and optionally one or more single pixels indicating a river crossing, with every different type of pixel(s) having its own specific RGB value.
    **Note: 1) The river can split into multiple branches, but it cannot re-join itself. 2) It can’t go diagonally, ie from pixel (x,y) to pixel (x+1,y+1). It must, for example, first go from (x,y) to (x+1,y) and then from (x+1,y) to (x+1,y+1). 3) You cannot have a square in the river (ie a 2x2 area with all four pixels belonging to the river).
    Volcanoes are represented by single pixels indicating the actual crater and cliffs by either lines or single pixels indicating impassable shoreline. Here follows a list with the RGB values indicating every different type of feature:

    • River Source - White (255,255,255)
    • River Body- Blue (0,0,255)
    • River Crossing - Light Blue (0,255,255)
    • Volcano - Red (255,0,0)
    • Cliff - Yellow (255,255,0)


    Let’s add some on our map now. First, we need to know the area we will be working on. As you can see map_features in not of the same size of map_heights or map_ground_types, so, using a selection as before does not seem like such a good idea. There are two ways we can do this, take your pick:

    First way: Open up map_heights.tga. Since we are working on a rectangle, we only need to know the coordinates of the two opposing corner pixels in order to be able to draw our rectangle on another image. So, note down the coordinates of the top-left and the bottom-right pixels of our new landmass. Now, for both of them divide both their coordinates by two. If the result of a division is a non-integer number, then subtract 0.5 from the result of that division. After you’re done with this, you should have a couple of new coordinates. Note these two sets of coordinates down. Now open up map_features.tga and find the two pixels that have the same coordinates as the ones you noted down just now. Take a colour that is unused for this file (pink, orange, green, purple, whatever works for you) and paint with it these two pixels. Now, using the selection tool, mark the rectangular area that has these pixels as corners. The marked area is where our new landmass lies on the map. Any feature-editing we make, wil be done inside that area.

    Second way: Leave the BMM modfolder, where we have been working all this time, for a bit and go back to the main RTW directory. If you have fired up the game after modding map_heights.tga you should be seeing a file named corrected_map_regions.tga in there. Open it up. You will see that there is a rectangle on it, in the area our new island is. Select this rectangle with the selection tool and save the selection somewhere. Now, simply open map_features.tga and load that selection. You should see a rectangular area framed; that is where our new landmass is, and that’s where we are going to make our editions.

    Ok, we have located our target area on the image, it is time to add our features now. First, let’s make a cliff. Using yellow (255,255,0) paint the 2-3 upper pixels of the left border of our rectangle. That’s it, cliffs done. Now for the volcano. Use red colour (255,0,0) to paint a single pixel; I put it near the top-right corner of the island, that’s where I want my volcano. Finally, let’s make a river. Let’s try to be realistic about this. We want rivers to have their sources on some mountain side, so we will have to know where such a mountainside exists. Open map_heights.tga and find the pixel you want to use; it will probably be one of those between the feet and the top of the mountain. Note down its coordinates. Now, divide them by 2 and subtract 0.5 from any non-integer values. The results you have now are the coordinates of our river-source pixel. Go back to map_features.tga, find that pixel and paint it with white (255,255,255). Now change your colour to blue (0,0,255) and make continuous line that will end at one of our selected area’s borders. You don’t have to make it straight, you can have it follow whatever kind of line you want, as long as you comply with the restrictions mentioned in the note above. Furthermore, if you feel like making a branch, go ahead and do it, again taking care to not violate any restrictions. After you are done creating your river, select light-blue (0,255,255) and paint a pixel of your river with it; the pixel can’t be the first or the last of the river and it can’t be on a corner.
    After you are done with all that, your image should look similar to this:
    Click to view content: 
    Image7: The left coast of our island has now been turned into a cliff, there is a volcano at the top-right corner of it and a branched river with a crossing.

    Let’s check that in game. Save and exit the image, delete map.rwm once more and fire up BMM. Have a look at our island; it should look a bit more vivid now.
    Click to view content: 
    Image8: The northern part of the left coast of our island has now been turned into a cliff (no idea why all of it isn’t), our volcano has risen from the ground and we also have a branched river that comes down from our mountain to the sea with a nice crossing.


    • Editing climate

    Click to view content: 
    Another important aspect of a map is the climate, as it adds variation to the map and makes it look more realistic. A low fertility grassland looks different in the Mediterranean than it does on some highlands of northern Europe or the arid lands of Africa for example. Apart from that, these grasslands will not covered with snow mid-winter on the high-lands, but not in the other two cases.
    **Note:Each different combination of ground type, climate and season can have its own texture, specified in data/descr_aerial_map_ground_types.txt.
    The various climate types that cover the map are defined in map_climates.tga; there are 12 climate types available, each one with its own specific RGB value. Here is a list of all of them:

    • Sub-Arctic - Dark Green RGB(0, 166, 81)
    • Alpine - Green RGB(57, 181, 74)
    • Highland - Light Green RGB(141, 198, 63)
    • Swamp - Yellow RGB(255, 242, 0)
    • Deep Temperate Forest - Light Orange RGB(247, 148, 29)
    • Light Temperate Forest - Orange RGB(242, 101, 34)
    • Infertile Temperate Grassland - Red RGB(237, 28, 36)
    • Fertile Temperate Grassland - Dark Pink RGB(237, 20, 91)
    • Mediterranean - Pink RGB(236, 0, 140)
    • Semi-Arid - Blue RGB(0, 114, 188)
    • Sandy Desert - Dark Purple RGB(102, 45, 145)
    • Rocky Desert - Mauve RGB(146, 39, 143)


    Open up map_climates.tga. As you can probably guess, it currently lies deep in the “mediterranean” zone, which is actually quite realistic. But for the purposes of this manual we will make some not quite realistic editions to it. First, let’s select the area we will be working on, as we have done before with the ground types or features. Open up map_heights.tga (it is the same size as map_climates, so we should be fine), select the island and save the selection. Additionally, do the same thing for the area where the mountain we added gets high; that would probably be the two “central” height zones.

    Now that we have our two selections saved, go back to map_climates.tga and load the first one. Now, paint the right half of it with Fertile Temperate Grassland (237,20,91) and the left half as Sandy Desert (102, 45, 145). Now load the second selection we saved, the one for the mountain, and paint it with Alpine (57, 181, 74) – there are mountains there, so it seems fitting.
    Your map_climates.tga should be looking something like that right now:
    Click to view content: 

    Image9: As you can see the area surrounding our island has mediterranean climate, but the island itsel has been divided in two different zones, with our mountain having its own climate

    We are done here, save and exit. As always, delete map.rwm, otherwise the changes will not take effect and then start up BMM.
    Your map should be like this now:
    Click to view content: 

    Image10: Notice how the texture has now changed for the two parts of the island, even though the two areas have the same ground type. The part on the bottom left uses a different texture than the rest of the “desert” area, because, as you can see, it belongs to the Sicilia_Graecus region (Syracuse) where a farm building has been constructed; farms change the texture of the land when they are built. If you end the turn and wait for winter to come, you will see that depending on the climate, some parts of the island are covered with snow and others are not. This can also be seen on the battle-map.

    If your map looks similar to the picture here, congratulations, you’re going very well and it is now time to move on to the aspect of mapping that gets closer to coding and deals with more than just image files.

    • Creating a new region and settlement

    Click to view content: 
    A map, after being “built”, has to be split in various regions, each one with its own settlement. This is done in map_regions.tga, where the map is divided into smaller parts, each one using a unique RGB value, with all pixels of that colour belonging to the same region. Also, there single black (0,0,0) and white(255, 255, 255) pixels representing settlements and ports/fishing villages, as well as areas of the map representing sea bodies.

    As you have definitely noticed by now, our new island, even though we did not do anything about it, has already been divided into several smaller parts and each one has been assigned to an already existing region. But opening your map_regions.tga you will see that the area between Sicily, Hellas and Cyrene is still coloured as a part of the “sea region”. So how did this happen? Every time a campaign starts, the game takes all the information from map_heights and map_regions.tga, compares the two files and then generates a new file, called corrected_map_regions.tga, which is essentially an adjusted version of map_regions. This file, which is stored at the main RTW directory, is the actual file the game uses when it runs a campaign - this does not mean however that map_regions.tga is not needed. Mappers usually create their map_regions.tga file, run a campaign so that the game generates the corrected_map_regions.tga and then copy the corrected version and put it in the place of map_regions.tga and continue editing that file instead. This saves them from the trouble of making minor adjustments themselves, just as it will save us from the trouble of creating the area of our new island on our own.

    So, go to your main RTW directory, copy the corrected_map_regions.tga, then go to our modfolder, delete map_regions.tga and put the copied file in its place, after renaming it to “map_regions.tga” as well. Now open the file. As we have already seen in-game, the new square that has been created to represent our island has been coloured with various RGB values, which means every differently coloured part belongs to another region; usually the ones that are next/close to it. We want to make this island a new region of its own, so we need to find an RGB value that is not being used by any other regions and paint our square with it. I chose (253,67,233) for our example, which is a bright pink one, but you can use anything you want as long as it is not used anywhere else on the file.
    **Note:A good way to check that a region has its unique colour is using the “colour count” function that 2-d software provide. Before painting the region with your colour check how many colours your image uses. Paint your region and then check again. If the colour count has increased by 1 then everything is ok, otherwise you need to choose a different colour.
    Using your colour paint the entire square. Once you’re done and everything is fine, it means we have a new region. But we are not done yet. A region also requires a settlement. Settlements are represented by single black (0,0,0) pixels. So, using that colour, paint a single pixel where you want your settlement. Generally, in land regions, that pixel must not border other regions.
    **Note: If our island was flat and empty, you could put the settlement anywhere on it, but since we have rivers, mountains, volcanoes etc on it, the game will show you a relevant error message and then it will CTD if you put the settlement on an invalid tile. You will need a bit of trial and error here to get it right, or if you have used the same coordinates as me throughout the manual, you can put it on (117,123), where it works for sure.
    Since this is an island, we want it to be able to have a port/fishing village, so we will have to add a “port” pixel as well; ports are optional though, even for coastal regions. Using white (255,255,255), paint a single pixel with at least one of its sides bordering the sea. Be careful not to put it on the pixel where our river mouth is.
    **Note:Here are a few other things you should remember about regions:

    • they should be 'convex' (one landmass, no inaccessible areas)*
    • they should have only one settlement and only one port
    • all land tiles should be part of a known region
    • each non-sea region should contain at least some fertile tiles
    • continuous sea surfaces should form one region
    • the maximum number of regions supported is 200
    • the distance between the centres of any two adjacent regions should not exceed 50 tiles*


    *: not doing these things shouldn't cause a crash, but it may cause the AI to mess up.
    After you are done with this, your map_regions.tga should look like this:
    Click to view content: 

    Image11: The pink square is our new region, the black pixel is the settlement and the white pixel is where the fishing village/port is.

    Ok, we are now done with the graphical part of creating a new region. Now comes the time for some coding.
    First we must “create” our new region, code-wise. The data for all the map regions are stored in the descr_regions.txt. Open the file and scroll down to the end. Copy the entry for the last existing region, press enter, and paste the copy right below. Time to edit it now, according to our preferences.
    The first line you see is the internal name of the region itself.
    **Note:Internal means that the info is what the engine uses, not necessarily what the player will be seeing on screen. It is a very important discrimination, that will be used throughout this manual.
    Let’s name our region “New_Region” for now. Be careful with the upper/lower case letters and the underscores.
    Right below is the internal name of the region’s settlement. Let’s name it “New_Settlement” for now.
    The third line is the default_faction for that region. We will not get into the details about that here, but, roughly, the default faction is the faction that the region will be most loyal to. We will be making this island a greek colony, so we are going to use their internal name, “greek_cities”, for this line.
    **Note:You can use here the internal names of any factions present on the campaign map, as these are coded at the top of descr_strat.txt.
    The fourth line is the rebel “faction” that belongs to this region. We will be using an already existing rebel faction for the island, so scroll up (or ctrl+f) the text file until you find the entry for Syracuse (“Sicilia_Graecus” region), copy the rebel faction name from there (“Syracusans”) and put it in our new entry. So, when our region revolts, the rebels that will be spawned will be “Syracusans” and will use the appropriate units.
    **Note:The rebel factions are defined in descr_rebel_factions.txt along with the units that “belong” to them.
    The fifth line of a descr_regions.txt entry is the region’s RGB value we assigned it on map_regions.tga. So, just open the image file, find out what colour you used to paint our square and then write down its RBG value in that line, with a space character separating the three numbers from each other.
    The sixth line is a comma-separated list of all the region’s resources, both trade (visible resources) and hidden ones.
    **Note:Trade (or visible, as they are sometimes called) resources need not be listed here, if they are listed in descr_strat.txt. Declaration just in descr_regions.txt is enough to activate effects that require them (such as the building of mines where gold exists) but the model for the resource will appear only if the resource is declared in descr_strat.txt. We are going to follow vanilla’s example here however and list the resources in descr_regions.txt as well. Trade resources are defined in descr_sm_resources.txt. Hidden resources are defined at the top of export_descr_buildings.txt (more on that in another section of this manual)
    Let’s decide what types of resources are there on our island… Ok, let’s have slaves, gold, olive_oil and grain. We can always add some more later, if we want to.
    The seventh line of the entry is called “triumph value” and it is unused, so just ignore it.
    The eighth line is the farming level of that region (indicates fertility). Let’s set it to 5 for now, we don’t want to make the island too productive.
    If you have done all the above, your descr_regions.txt should be like that now:
    Click to view content: 

    Image12: That’s how the bottom of your descr_regions.txt should look like. If you have used a different colour for the new region in map_regions.tga, then the fifth line should be on par with your colour and therefore different than the one in this image.

    Now that we have created our region and its resources code-wise, it’s time to also create the settlement for it and also put the resources on our map. Resources, as well as settlements and the buildings that exist in each one of them are defined in descr_strat.txt (it lies in the world/maps/campaign/imperial_campaign directory). The file can be roughly divided into 4 different sections, the first being the “options” section, the second being the “resources” one, the third being the “faction setup” one and the last being the “diplomacy” section. We will be focusing on the second and third sections for this manual.

    First, search for the “resources section” text. Then scroll down to the end of the section (it should be line 440). We have added four resources in our region, so we are going to need four new resource lines. Copy the last resource line and paste 4 copies of it right below it. Each line’s format is the following: The word “resource”, then the internal name of the resource type we want and then the x and y coordinates of our map, where the resource will be placed. We know the names of our resources (slaves, gold, olive_oil, grain) but we do not know yet where we are going to place them. Let’s find out. Open up map_regions.tga. Now here is the catch. Your software counts pixels starting from the top-left corner, while RTW counts using the bottom-right corner as the (0,0) coordinate. So, if you try to match a coordinate from your .tga image to a point on the map directly, you will get the horizontal coordinate just fine, but you will get the vertical coordinate wrong. There are two ways to get the right vertical coordinate for a pixel.

    a) Simply “flip” the image upside down in your 2d-editng software. Optionally, you can paint the pixel you want with a distinctive colour, so that you don’t “lose” it when the image is flipped. The pixel you want will now have the same coordinates in the image as it will have on the map. Just don’t forget to NOT save the flipped image.
    b) Note down the vertical coordinate of your pixel. Let’s say it is Y_img. We also have the total height of our map or our image; let’s name that H. The accurate in-game vertical coordinate of our pixel, which we will name Y_map, is given by this formula: Ymap = H – Y_img – 1.

    We will be following the first way here, in order to avoid math. Choose a colour you want and paint with it the pixel where you want the slaves resource to appear. Then using different colours do the same for gold, then for grain and then for olive oil. Now flip the image (menubar->Image->Flip). Find the coloured pixels you made, and note down their coordinates. When you’re done, exit the file without saving the changes.
    Back to the resource section of descr_strat.txt. Fill in the proper coordinates we just found out for our added resources. That’s it, we are done with this; your descr_strat should be like that at this point:
    Click to view content: 

    Image13: That’s how the bottom of your resource section should look like. The four last lines are the resources we just added to our island, and next to them you can see the point of the map they will appear on.

    It is now time to create our new region’s settlement.
    Scroll down to the “factions” section of the file. Take some time to see how it is organised. In a nutshell, it is divided in several parts, each one for every faction. At the top of each faction’s part there is general info about the faction (faction name, starting treasury etc), then there is a list of all their starting settlements, then a list of their armies, their leading characters and their agents and finally information about the faction’s family tree. We will be dealing with the second part now, the one about the settlements.
    Scroll down the file until you get to the “slave” faction’s part – we will give this settlement to the rebels for now. Scroll a bit further down, until you find the end of the settlements part. It should be line 4260. Copy the existing entry for the Tripolitania region and paste the copy below it. That will become the entry for the settlement we put in our new region.

    Every settlement’s entry starts with the word “settlement” and then, inside curly brackets follows the settlements information.
    The first line is the settlement level. There are 6 levels ranging from village (the smallest) to huge_city (the biggest) and the settlement level determines the buildings that can be built here, as more advanced buildings require high-leveled settlements to be constructed. For now our new settlement will be a small village, so don’t change this line.
    The second line of the entry is the internal anme of the region where the settlement belongs. We named our region ‘New_Region’ earlier, so that is what we are supposed to put in this line.
    Next comes the foundation year line, which is redundant, so leave it 0.
    The fourth line is the starting population of the settlement. You can have anything here, between 400 and 50,000 and it is not linked to the settlement’s level, but it is usually better if these two are ‘compatible’ (ie a town-level settlement should have from 2,000 to 6,000 people, because if it had more, there would be high squalor). Set this to 500 for our settlement.
    The next line is the settlement plan that our settlement will be using on the battle-map. Each settlement can have its own, specific one, otherwise if declared as “default_set”
    It will be using the predefined plan for it’s culture/level combination. So, just leave this line alone for now.
    The last line is the faction_creator, which declares who “built” the settlement. The buildings that exist in that settlement will look like the buildings of the faction that has been defined as faction_creator. We want our buildings in the settlement to look greek, so greek_cities is what we fill in here.
    **Note:Any faction belonging to the greek culture would do for our purpose, but faction_creator is also linked to some other things we will not be analysing here, so we are going to use greek_cities.
    Usually, after the faction_creator line, follows a list of the settlement’s buildings, but for now we are going to leave our settlement without any of them, so we will add nothing here.
    And that’s it, we have created our settlement’s code as well, and descr_strat.txt should now be looking like this:
    Click to view content: 

    Image14: That’s how the bottom of your slaves/settlement section should look like. A village with 500 people, built by the greek city-states, without any buildings in it.

    Ok, one final step to go before we are done. We have to update the list of regions and settlements with our island’s info. Go to the text/imperial_campaign_regions_and_settlement_names.txt and scroll down to the end of the file. We have to make two new entries, one for our region and one for its settlement.
    At the very end of the line, write the internal name of our region enclosed in curly brackets. Now, using the ‘tab’ button and NOT the spacebar, make three spaces and then write the external name of the region; the external name is what you will be seeing in-game. Make a new line and then do the same thing for the settlement’s name.
    **Note:Remember that internal names can only use latin characters and the underscore, no special characters or spaces at all. The external names can use any character you lik, including spaces and punctuation.
    After that, your imperial_campaign_regions_and_settlement_names.txt should be like that:
    Click to view content: 

    Image15: That’s how the bottom of your imperial_campaign_regions_and_settlement_names.txt should look like. Note how the bracketed internal names on the left use only a limit selection of characters, while the external (in-game) names on the right can use special characters as well as spaces. Also, note that the gap between the internal and external names are made using ‘tabs’ and NOT spaces and that after the last name, there must always be a last, blank line, otherwise the engine will 'cut' the last name's last letter.

    Time to check our new editions in game now. As always, delete map.rwm and start up BMM. Starting as the Julii, remove the fog of war and take a look at our island. If all went well, you should be seeing a new region, with gold, olive-oil and grain on it and also a lonely greek settlement, without any buildings or garrison and a fishing village on the eastern coast.
    Click to view content: 
    Image16: You can see here everything we added. The island now is a region on its own, belonging to the rebels, there are trade resources on it (slaves do not appear until someone captures and enslaves the settlement) and there is also a greek-looking village and a fishing village.

    Good work, we have almost covered the basics of mapping; just a little more to go.

    • Editing region ownership, settlement and army details

    Click to view content: 
    It is time now that we re-arranged some of the various elements of the map that comprise our ‘campaign’. These elements include region ownership, army location/setup and settlement population/level/buildings.
    First we will deal with the ownership of regions on our campaign map. Ownership of a region/settlement is determined mainly by one factor: the location of the settlement’s entry in descr_strat.txt. As we saw in the previous part of this tutorial, descr_strat.txt has a “factions” section, which is divided in sub-sections, each one dedicated to a specific faction, where there is a list of its starting settlements, among other things. So, every settlement that exists on our map has to exist in the “settlements” section of one of the factions. So, in order to change its ownership, we simply have to remove its entry from the original owner’s settlement list, and add it to the new owner’s list. Usually though, each settlement has a garrison, an army that is deployed inside it at campaign start. Even if we change the ownership of a settlement from faction X to faction Y, if an army of faction X still occupies the spot on the map with the same coordinates, then the settlement will still belong to faction X when we start our campaign. So after moving the settlement’s entry to the new owner’s list, we must make sure to move the garrison (if any) to a new location; this is done either by removing the army’s entry altogether or by simply moving it somewhere else. Let’s try all that on our own map now.

    Open descr_strat.txt. Scroll down to the part where we previously added the entry for our new settlement. As you can see it is located at the end of the rebel faction’s settlement list, so it currently belongs to the rebels. Let’s give the settlement (and the region therefore) to the Greek City-States. Highlight the settlement entry, like this and cut it.
    Click to view content: 

    Image17: This is the entry for our new settlement, that we must remove from its current location (the rebels’ settlement list)

    Scroll up to the greek_cities section now and go to the end of its own settlement list – this should be line 3196. Now paste the entry there, like that:
    Click to view content: 

    Image18: This is where the settlement’s entry must go, in the greek_cities settlement list. It doesn’t have to be at the end, we put it there for ease of use. If we put it at the top of the settlement list, the settlement would become the faction’s capital.

    The settlement was not garrisoned previously, so moving its entry is enough to change its ownership, we don’t have to move or delete an army. We are going to add our own later, but for now the region ownership swap is complete.

    Let’s take now the next step; we are going to edit our settlement’s details, adding some buildings to it and some population. The first thing you should know is that every building and its capabilities/requirements/upgrades are listed in export_descr_buildings.txt. A major attribute of each building is that it has a settlement-level prerequisite, so that it is not available in settlements of lower level. That also means that buildings cannot be put in settlements with insufficient level via descr_strat.txt either. So, in order to add a building, we must first make sure our settlement is of a high enough level. Check the first line of our settlement’s entry; it reads ‘village’ and villages in RTW cannot have any buildings. So, first we want to change that. Replace the word ‘village’ with ‘town’, so that the settlement becomes a small town, like this:
    Click to view content: 

    Image19: We have changed the first line of the entry to read ‘town’ and now our settlement will become a small town.

    Now, we must also add the relevant government building in the settlement, which will also be its first building. Each building has its own entry in a settlement, which includes two basic elements, apart from the keywords “building” and “type” and the brackets; the building’s “tech-tree” name and also the specific “tech-tree” level’s name.
    **Note:Buildings in export_descr_buildings.txt are grouped in “tech-trees”, with each tree containing one or multiple levels, that define a building type and its upgrades. For example, the “hinterland_farms” tech-tree contains all the farm-type buildings, each one of which has its own name: farms, farms+1, farms+2 etc.
    Let’s add our government building now. The government buildings are listed at the top of the export_descr_buildings.txt, and they belong to the building-tree named “core”. A small town is the first settlement level that uses a government building, so we want to use the first level of that tree, which is named “governors_house”. The building entry we will add to our settlement should look like that therefore:
    Click to view content: 

    Image20: Note that we first define the building-tree’s name and then we specify the name of the level we want to add.

    Now that we have completed our settlement’s “upgrade” procedure, and added a building along the way, let’s add some more. First we will be needing some protection, so let’s make ourselves some walls. Our settlement is supposed to be pretty small, so a first level wall (the Wooden Pallisade) should be enough.
    **Note:If you cannot figure out the internal name of a building (which is the one you must use when coding), a good way is to consult text/export_buildings.txt. Every building’s on-screen name and description are defined in there, usually on a per-culture base (more on that in another section of the manual). So you can search for a building’s on-screen name and then see which internal building name it is associated with.
    Whatever method you use, you will find out that the tree name of the wall-buildings is “defenses” and the internal name of the first level is “wooden_pallisade”. If you check the “settlement_min line” of the level, you will see that it reads “town”, so our settlement is indeed able to have such a building in it and we are good to proceed with adding the relevant code. Our new building entry for our settlement’s walls should be like that then:
    Click to view content: 

    Image21: As we did previously, we added a new building entry, including our new building’s tree and level names.

    Following the above procedure, add now the maximum possible level of barracks and farms in the settlement. We will not be indicating which these are, you will have to find that out yourself either by comparing the settlement level prerequisites of your buildings by trial and error, until you get things right. Since we are adding barracks we will also be needing recruits in our settlement, so increase its population to 850 as well. Below follows an example of what your settlement entry should look like after you are done, but do not view it until you are either done or utterly confused.
    Click to view content: 

    Image22: All our buildings are now in place and our settlement’s population has increased to 850.

    Let’s fire up BMM and check if everything is all right. The new settlement, upgraded to a “Small Town” now, should have a barracks, farms, a palisade and the governor’s residence.

    Now that the settlement detail editing is done, there is one last thing to do; army editing. The town is under the control of the Greek City-States, but they currently have no forces there. Let’s give them a garrison. An army in RTW consists of two parts: the leader, which can be either a named character/family member or a simple captain, and the army itself, meaning the various units that make it up. Armies are declared in the “armies” section of a faction in descr_strat.txt, right below the ‘settlements’ section.
    This is a small, new colony for the Greeks, so there will be just a small garrison under a simple captain guarding it. First, we must create the army leader’s entry. This consists of the character’s name, his type, his age and his coordinates on the map. The coordinates of the leader define where the whole army will be. In the case of an heir or the faction leader an extra attributed is added, to declare this fact. The character’s name must be included in the respective faction’s name list in descr_names.txt. If it is not, you will get an errorless CTD on campaign start.
    **Note: Always be very careful with the names you use, they are a very common cause of problems. Make sure you have defined them properly otherwise they can cause a great deal of frustration. (more in the next section of the manual)
    Let’s create our greek captain then. First, copy the entry of the last greek_cities family member, Memnon, lines 3266-7. We will not use the traits/ancillaries lines, because simple captains cannot have those two. Now paste these lines right below the entry of Memnon’s army. Pick a name for the general, from the greek_cities male names list and use it to replace the “Memnon of Sparta” part. I chose the name “Basileios”. Then we need to change his character ‘type’. He is not a named character with a portrait, so we have to replace “named character” with “general”, which means our army leader is a simple captain. Next, you can change the character’s age. The minimum you can set is 16 and the maximum 124. And finally, we have to change his location of the map. The coordinates currently are the same as Memnon, which should not be happening – two characters cannot be placed on the same map tile. We want to put Basileios inside our town, so we must find the map location of the settlement. You can use one of the methods described previously in order to get these coordinates. After acquiring them, replace the old ones with them. Our character entry should now look like this:
    Click to view content: 

    Image23: The character entry is the first half of an army’s entry. The character’s name must belong to the respective faction’s male name list, defined in descr_nams.txt. The coordinates he is placed on must not be already occupied by another character.

    The second half of an army’s entry is the various units that make it up. First is the unit of the army leader and then all other units, each one in its own line, which includes the unit’s type as it is defined in export_descr_unit.txt and the unit’s starting experience level and armour/weapon upgrades. The units given to a character have to belong to the character’s faction, ie the faction must be included in the ownership list of the unit’s entry in export_descr_unit.txt. If not, a CTD will occur.
    Let’s give some units to Basileios now. I chose to give him two battalions of Militia Hoplites, one of Hoplites, one of Peltasts and one of Greek Cavalry. Basileios’ unit will be the Hoplites.
    **Note:If you cannot figure out the internal name/type of a unit (which is the one you must use when coding), a good way is to consult text/export_units.txt. Every unit’s on-screen name and description are defined in there, usually on a per-culture base. So you can search for a unit’s on-screen name and then see which internal unit name/type it is associated with.
    **Note:Remember to use tabs and not spaces, as vanilla files do. Certain files like descr_strat.txt are very sensitive to such formatting errors and can become quite a pain, so play safe and follow vanilla’s example.
    Now copy the ‘units’ section of Memnon’s army and paste it directly under Basileios’ character part. Replace the first unit type, which currently is “greek general's guard cavalry early” with the unit type of Hoplites, which is “greek_hoplite”. That is Basileios’ unit. Then, do the same with the rest of the units, replacing with the unit types you want (2 militia hoplites, 1 peltast, 1 greek cavalry). Add lines when necessary, but make sure you follow the existing format of tabs and spaces. When you are done adding the units, give some experience to them. Basileios’ bodyguard can have 2, which translates to 2 bronze chevrons, and the rest can have 1, which translates to 1 bronze. Finally, give the Hoplites +1 armour and +1 weapon, using the last two values of the unit’s entry. If you did everything properly, the army entry should now be like this:
    Click to view content: 

    Image24: A compete army entry in descr_strat.txt. The first unit listed is the army leader’s unit. The unit types that follow the ‘unit’ keyword must correspond to a unit type in export_descr_unit.txt and they must belong to the character’s faction.

    Ok, now that we have added our garrison in the settlement, let’s also add a small naval force. As with a land army, a fleet is made up of two parts, the ‘admiral’ part and the ‘ships’ part. The admiral part follows the same principles as the captain part, with one difference: instead of the “general” keyword, the word “admiral’ is used. Of course the admiral’s name must belong to the faction’s name list, the coordinates have to be a valid location at sea and the units (ships) must belong to the faction in export_descr_unit.txt. Go now and add a new fleet right where the town’s port would be (next to the fishing village), consisting of two bireme ships. Here follows an example of what your fleet entry should be like, but do not view it until you are either done or about to give up.
    Click to view content: 

    Image25: A compete army entry in descr_strat.txt. The principles applied here are the same as with land armies.

    After you are finished, save and exit. Go in-game to check your changes. If you can see a new army in the settlement and a new fleet next to the fishing village, congratulations, you have succeeded.

    Exercise: This is an exercise you can do in order to test your skills. It is optional and you can simply ignore it if you don’t feel like doing it. In any case, it is not covered in this manual and instructions or guidance are not provided, so attempt it at your own risk. It would be best if you backed up all your files before doing so.
    The exercise for this section of the manual is this: Using the knowledge you acquired, split your new island region in two regions, rename them and their settlements and give the second one to Carthage along with a garrison of your choice. Also give Carthage a port and a fleet stationed there. Make all necessary editions to the map files.

    With this, the basics of mapping have been covered and you have a basic grasp of how to modify aspects related to your map and your campaign. Well done!

    • Working Example

    Click to view content: 
    You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.

    Last edited by Aradan; April 14, 2010 at 02:08 PM.

  5. #5

    Default Re: Beginner's Modding Manual (RTW)

    Step 3: Editing character names - (Link 1)


    • Knowing the files

    Click to view content: 
    Our game’s character names actually include male and female names as well as surnames. In this section we will be referring to all these as "names", specifying a certain category only when we need to. All the information about names is stored in two files:

    • descr_names.txt - Contains a list of all the internal names of our mod, categorised first by faction and then, within each faction's section, by category ("characters" for male names, "surnames" for surnames and "women" for female names). A name available to multiple factions must be listed once in each of these factions' name-lists.
    • text/names.txt – Contains a list of all the internal names of our mod defined in descr_names.txt and the external name each one is associated with. Each internal name, even if it exists multiple times in descr_names.txt, must be listed only once in names.txt.
    • descr_names_lookup.txt – Contains a simple list of all the internal names of the game (unused, for reference only)

    **Note:Remember: 'Internal' is an element what the game's engine uses, while external (or on-screen) is what will appear on the screen. Internal elements use only latin characters, numbers and the underscore, while external ones can use special characters as well, such as spaces, punctuation etc.

    • Editing a name

    Click to view content: 
    Now that we know which files we will be messing with, time to edit them. The first step, obviously, is to bring them inside our modfolder. Open your main RTW data directory, find descr_names.txt, copy it and paste it inside our BMM/data/ folder. Then copy the RTW/data/text/names.txt and paste it inside our BMM/data/text/ folder.
    Now that we have our files ready, let's make our first, simple step; we are going to change how a name appears on screen. That means we are not going to add an altogether new name, just change an existing one - ie edit the external name that is associated with a certain internal one. Open up your text/names.txt and search for "Julius", which is a surname available for the Julii and the Senate factions. When you find it, you should be looking at something like that:
    Click to view content: 

    Image1: The name inside brackets on the left is the internal name, which must not be touched, and the one on the right is the external name, which we will edit.

    The name on the left is the internal one, the one the engine uses, so we don't want to touch this now. All we want to do is change the external name associated with it, so we will be editing the one on the right. As you can see the external name of "Julius" is again "Julius" - change it to "of the Julii" (without the quotation marks) like this:
    Click to view content: 

    Image2: The internal name is left untouched, we only change how it will appear on screen. All "Julius" characters will now be surnamed as "of the Julii".

    Be careful not to change anything inside brackets, and keep the formatting of the file, with spaces between the internal and external names being crated with tabs and not the space character. Save and exit the file, and start a campaign as the Julii. If you did everything correctly, your family members now should be called "xyz of the Julii":
    Click to view content: 

    Image3: Every character whose surname was "Julius" has now become "of the Julii", according to the plan.


    • Adding a name

    Click to view content: 
    We have learned how to edit a name now, but in fact most mods do not stop there; they usually add names of their own to suit their own needs. You can add a new, historically-accurate name, your family's surname or your grandmother's name in the list, whatever you like. Let's find out how to do that.
    As we explained above, a name consists of two things: the internal entry and the external entry. So in order to create a new one, you have to make both these entries in the appropriate files. First, let's create the internal part. Open descr_names.txt and scroll down to the section of the faction your new name will belong to. We will be adding a new roman name in this manual, but we don't want it to be available to the Scipii. That means we must add the name to the name-lists of Senate, the Julii and the Brutii. Do just that. Find the name-lists of these 3 factions and at the bottom of the male names sections of each add "my_male_name" (we are using a generic internal name, since we have not yet decided what kind of name we want), like this:
    Click to view content: 

    Image4: At the bottom of the male name-list of each of the factions we want to have this new name, we add an entry for the internal name.

    Right, we now have assigned our new name to the factions we want. But we are not done yet. We need to link this internal name with the one that will appear on screen and we can do this via text/names.txt. Open the file up and go to the very end of the file. Make a new line there. First make a pair of curly brackets and then inside those put the internal name you created, exactly as you typed it in descr_names.txt. Then, outside the brackets, make some (usually 3-5) spaces using the tab key and after the tabs type your external name. It can be anything you like, including spaces, special characters, punctuation marks and so on; we are going to use something totally ahistorical and lame here, the name "Modderius". It does not matter that we added the name to 3 factions earlier, since the name is one, it only needs one new entry in names.txt. After you are done, make a final, blank line pressing "enter". So, the bottom of our file should be like this now:
    Click to view content: 

    Image5: On the left we have the internal name in brackets and on the right, separated with tabs and not spaces, we have the external name, which might be totally different than the internal one.

    Now, following the example of "Modderius" we are going to add a surname and a female name to our mod, both for the factions of Julii, Scipii and the Senate. The surname should be listed at the bottom of the “surname” section of the factions and the female name at the bottom of the “women” one obviously. Their internal entries will be "my_surname" and "my_female_name" and their respective external entries will be "Noobius" and "Mak" (without the quotation marks of course). If you do everything correctly, your descr_names.txt and names.txt should look like that:
    Click to view content: 

    Image6: We can see the new female name and the new surname defined in descr_names.txt (in all 3 factions' lists of course) and also the names associated with them in names.txt.

    Now we are going to see if our modification was successful. Open up descr_strat.txt and go to the Julii section. At the start of the "armies" section you will see the entry for the one of Flavius Julius, the faction leader. It is time now to use our new names in game. Replace the word "Flavius", which is the character's first name, with "my_male_name" and the word "Julius", which is his surname, with "my_surname". Then, scroll down a bit until you find the "family" section of the faction. First find the "character_record" line of Faustina and replace "Faustina" with "my_female_name" and then the "relative" line for Flavius' family (it should be line 582). Again, replace "Flavius" with "my_name" and "Julius" with "my_surname". Finally, replace "Faustina", which is the name of his wife, with "my_female_name". Be careful not to delete any commas or spaces during the process. When you are done your descr_strat should be like this:
    Click to view content: 

    Image7: You can see that we have used the internal names here and not the external ones. Also note that we have replaced all instances of a specific character's name/surname.

    Now let's check that everything works as it should. Fire up BMM and start a campaign as the Julii. Open your family tree and have a look there. Your faction leader should now be called Modderius Noobius and his wife Mak, like that:
    Click to view content: 

    Image8: Our faction leader and his wife have had a name change and they are now using our new names. Note that it is the external names that are being used on screen.

    If yes, you have been successful.
    **Note:You will notice that upon exiting the campaign, you will get an error report, saying that the engine could not find the character entry of Lucius Julius. But we didn't touch Lucius, did we? In fact we did, in Roman families the surnames are inherited from father to son, so all your family members now have the "Noobius" surname in-game, but their surname in the files is still "Julius". Oops, what did we do! We need to fix that. So go on to the next part to learn how.

    • Removing a name

    Click to view content: 
    So, we have a problem with our new surname. We can do a number of things to fix that, but what we will do here is simple; we will remove our new surname altogether from the mod. Removing a name means two things:
    Firstly, removing it from the list of available names for a faction - or from all factions' lists if we want it completely gone (it is not necessary that we remove its entry from names.txt, but we will do it as well, in order to keep our mod clean and up-to-date).
    Secondly, it means removing/replacing all instances of that name in other files, such as descr_strat.txt. If we remove a name from descr_names.txt and we are still using it in another file, we will get an errorless CTD, so be very careful about that!
    Let's open up descr_names.txt now. Find the places where you added the "my_surname" entry and simply delete it. Do this for all 3 factions you had added it for. Now open text/names.txt and remove the associated line of code.
    Good, now we have eliminated the surname from the lists. But we also need to remove it from the game. The only file where it is currently used is descr_strat.txt, so open it up and search for "my_surname". It is of course only used for the Julii faction leader currently, so replace every instance of it with "Julius". That's it, when you are done with it, you have successfully removed the name from the game.
    Click to view content: 

    Image9: Our faction leader and his sons are named “of the Julii” again and our custom surname is gone from the mod.
    **Note:Always make sure that the names you are using in various text files are properly defined in descr_names.txt and names.txt, CTDs caused by name-related code are usually errorless and very hard to track down.

    • Working Example

    Click to view content: 
    You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.

    Last edited by Aradan; January 31, 2010 at 08:52 AM.

  6. #6

    Default Re: Beginner's Modding Manual (RTW)

    Step 4: Editing text and descriptions


    • Editing faction names (Link 1)

    Click to view content: 
    As you may know, the number of factions in RTW is hardcoded at a maximum of 20 + rebels. So, whether you want to add a faction of your own or you just want to correct a historical inaccuracy, simply renaming a faction externally, while keeping the same internal tags is the best way to go. External renaming means that we are not going to touch any internal tags at all, but instead we will only change how each of these translates on screen.

    All the files that determine the on-screen appearance of text are located in the data/text/ folder, so that’s where you have to go. The files that we are going to need for faction renaming are: expanded_bi.txt (for nearly all entries), campaign_descriptions.txt (for the campaign description obviously) and just for romans the event_strings.txt (civil war messages). For our purposes, we will be re-naming the “House of Julii” faction into “House of Romani” here, so take all three aforementioned files from RTW/data/text/ and put them into your RTW/BMM/data/text/ folder.

    Open up expanded_bi.txt and have a look at the structure. On the left side there are the internal entries, inside curly brackets, and on the right side we have the corresponding on-screen text of each one. It is possible that the same internal tag has multiple instances throughout the file, in which case only the one that’s closer to bottom of the file is used, as it overwrites the previous ones. The structure of the other two files is similar, with internal entries inside curly brackets preceding the external ones. Now, what we essentially have to do in order to rename our faction is locate every instance of the word “Julii” that belongs to an external entry and edit it to read “Romani” instead. So, we cannot just do a global replace of “Julii” with “Romani” because that will also affect the internal tags – and we don’t want that!
    **Note:You can try making a global replace of the word “Julii” but making sure the upper/lower case letters match – internal entries use all capitals, so they will not be affected in that case. Still, you have to be careful.
    The entries that mention “Julii” in the external part are following, in order of appearance:


    expanded_bi.txt

    Code:
    {ROMANS_JULII}
    {EMT_ROMANS_JULII_SPY}
    {EMT_ROMANS_JULII_ASSASSIN}
    {EMT_ROMANS_JULII_DIPLOMAT}
    {EMT_ROMANS_JULII_ADMIRAL}
    {EMT_ROMANS_JULII_GENERAL}
    {EMT_ROMANS_JULII_NAMED_CHARACTER}
    {EMT_ROMANS_JULII_VILLAGE}
    {EMT_ROMANS_JULII_TOWN}
    {EMT_ROMANS_JULII_LARGE_TOWN}
    {EMT_ROMANS_JULII_CITY}
    {EMT_ROMANS_JULII_LARGE_CITY}
    {EMT_ROMANS_JULII_HUGE_CITY}
    {EMT_ROMANS_JULII_CAPITAL}
    {EMT_ROMANS_JULII_FORT}
    {EMT_ROMANS_JULII_PORT}
    {EMT_ROMANS_JULII_DOCK}
    {EMT_ROMANS_JULII_FISHING_VILLAGE}
    {EMT_ROMANS_JULII_WATCHTOWER}
    {EMT_ROMANS_JULII_FACTION_LEADER}
    {EMT_ROMANS_JULII_FACTION_HEIR}
    {EMT_YOUR_FORCES_ATTACK_ARMY_ROMANS_JULII}
    {EMT_YOUR_FORCES_ATTACK_NAVY_ROMANS_JULII}
    {EMT_YOUR_FORCES_AMBUSH_ARMY_ROMANS_JULII}
    {EMT_YOUR_FORCES_ATTACKED_ARMY_ROMANS_JULII}
    {EMT_YOUR_FORCES_ATTACKED_NAVY_ROMANS_JULII}
    {EMT_YOUR_FORCES_AMBUSHED_ARMY_ROMANS_JULII}
    {EMT_VICTORY_ROMANS_JULII}
    {EMT_VICTORY_DESCR_ROMANS_JULII}
    {EMT_DEFEATED_BY_ROMANS_JULII}
    {EMT_SHORT_VICTORY_ROMANS_JULII}
    {ROMANS_JULII_DESCR}
    campaign_descriptions.txt

    Code:
    {IMPERIAL_CAMPAIGN_JULII_TITLE}
    {IMPERIAL_CAMPAIGN_JULII_DESCR}
    event_strings.txt

    Code:
    {roman_civil_war_julii_start_notify_title}
    {roman_civil_war_julii_start_notify}
    {rome_outlaws_julii_notify_roman_title}
    {rome_outlaws_julii_notify_foreign_title}
    {rome_outlaws_julii_notify_roman}
    {rome_outlaws_julii_notify_foreign}
    Locate these tags, one by one, and change their corresponding on-screen entries to read “Romani” instead of “Julii”, like that:
    Click to view content: 

    Image1: The internal tags of the “Julii” faction have been left in tact, but the on-screen text they are associated with has been changed to read “Romani” instead.

    After you make the appropriate changes in all three files, save and exit. Note that there might be some other entries were the word “Julii” is mentioned like the defeat message of Gauls, or the description of an ancillary, but these are not so for all factions. So if you mean to be thorough, you must make a good search around the text/ folder and make sure no text file mentions the term “Julii” in an external entry – those that do should be edited. After you are done, fire up BMM and check out the results of our renaming.
    Click to view content: 

    Image2: All instances of the word “Julii” have been replaced with “Romani”. Our faction renaming is successful.

    There are no more “Julii” in the game. The “Romani” have taken their place!


    Click to view content: 
    One of the easiest things to change when it comes to text and one that helps improve a the game’s immersion is editing the loading screen quotations. You will need two files in order to do that: descr_transition_screen.txt and text/quotes.txt. First, copy these files from their vanilla locations and put them into their appropriate new locations inside our modfolder. When you are done with that, let’s see how they work.
    Quotations have two parts: the ‘author’ and the ‘quote’ itself; and in some cases also a third part, the quote’s translation. As with names, each of these parts has an internal entry, used by the game’s engine, and an external one, which is what appears on screen. Open up text/quotes.txt and have a look at the top entries. You will see that the file’s formatting is as follows: first, inside curly brackets, comes the internal tag of the quote, the author or the translation and then, right below, comes the corresponding external text. The order they are arranged does not matter, all that is important is that external entries are right below their corresponding internal ones.
    Click to view content: 

    Image3: The entries marked with blue are the internal entries of quote/author/translation and the ones marked with red are their respective associated on-screen text.

    Let’s now do some editing. A useful thing to know about quotes is that there is one of them that always appears at the first loading screen, right before the main menu comes up. So, we are going to be editing that one, in order to easily see the results of our modding. That quote in BMM is the one by Archidamus of Sparta, saying “It is the noblest and safest thing blablabla”. If you check quotes.txt you will see that these entries correspond to the internal entries of “Author_6” and “Quote_6”. That’s what we are going to change then. In quotes.txt change the external entries of these two, so that they now read: “Archidamus the Spartan” and “it is the most noble and most safe thing”. It’s very minor editing, but it will be enough to let us know if what we are doing is correct. Be careful not to change anything inside brackets! Your entries should now look like that:
    Click to view content: 

    Image4: We have slightly changed the on-screen text of both the author and the quote, but the internal tags have been left in tact.

    Let’s see how we did. Fire up BMM and wait until the splash screen is gone, to see the first loading screen. If all went well, you should be seeing this:
    Click to view content: 

    Image5: Both the quote and the author have been changed exactly as we wanted.

    Now, we can’t just edit old quotes, can we? We also have to add our own. First, obviously, we must add the quote and the author. Open up quotes.txt again and go to the bottom of the file – you don’t *have* to go there, but we’ll do it that way so we can easily keep track of our changes. First, make an internal name for your quote; “my_quote” will work just fine for now (without the quotation marks – that goes for all the entries that follow). Put that in curly brackets. Now, in the next line type the actual text for the quote; “I can edit quotes!” seems fitting. Next, add your quote author’s internal entry; “my_author” will do. After you’ve put that in brackets as well, add the actual text for the author; for example “Me, of course”. So, now the bottom of your quotes.txt should be like this:
    Click to view content: 

    Image6: The internal and external entries for my quote and author have been coded. Note that their internal tags don’t have to follow the vanilla convention of “quote_x/author_y”

    We have added the quote and author to the game, but we haven’t yet instructed the game to use them. To do that, we must link the newly-added quote to the newly-added author via the descr_transition_screen.txt file. Open the file. Following the existing structure, add one line at the bottom for the internal entry of the quote and one more for the entry of the author. That’s it, now the game knows that it must link that phrase with that person and we are done; almost. Normally, one can add the entries for his quotes/authors anywhere in the file one likes, but now we want to use the trick with the quote that always comes up at first, so after you create the entries, cut them and paste them before the entries for “Quote_6” and “Author_6”, so that now our new ones are the 6th on the list. Your descr_transition_screen.txt should be like that when you are done with adding and moving:
    Click to view content: 

    Image7: The quote and the author we added previously in quotes.txt are now linked and they will appear together. We have put our entries in the place of the “always-first” quote, so that we can immediately check if they work.

    Save, exit and start up the mod. If you did everything correctly, that’s what the first loading screen should look like:
    Click to view content: 

    Image8: Success. Our new entries are working – we can indeed edit quotes!

    And that’s about it for quotes. Go add some of your own now. To remove one, you simply have to delete its entries from descry_transition_screen.txt.

    • Editing credits

    Click to view content: 
    Credits are important in a mod. People have to know who did what, so that modders and contributors can get their rightfully deserved reputation. So, let’s find out how to edit the game credits.
    The file you need is credits.txt and it can be found inside the data/ directory, so copy the vanilla one into our mod’s data folder.
    Open the file up now and take a look at it. Its structure is not difficult to understand, except for two things. The first is the underscore used before some entries. That character makes the entry that follows it be its own paragraph and use a slightly larger font size, like a header. The other strange element is the vertical bar (‘|’) that divides some entries that exist on the same line. That bar makes the entries on both its sides form ‘columns’ so that each one has the same distance from the axis that runs down the centre of the screen, regardless of character length.

    Let’s add some text of our own now, above the vanilla credits. Go to the very top of the file and in the first line write the mod’s name in capitals, making it a header by using the underscore. Leave a blank line and below add “Creator” also making it a header. And finally, leave another blank line and write there your name; of course leave another blank line after that so that CA credits are not directly underneath your name. So the top of your credits.txt should look like that:
    Click to view content: 

    Image9: The underscores will make the entries be ‘header-style’ and blank lines create blank space between entries.

    Start up the game and go check the Credits section (Options->Credits). You should be seeing something like this:
    Click to view content: 

    Image10: The mod’s name and your own, as the creator, proudly displayed at the top of the credits!


    • Editing miscellaneous things

    Click to view content: 
    There are many minor textual details that can really improve immersion for a mod, but are often overlooked. We will see here how simple it is to change the season names, the currency of our mod and the dating system. That info is coded in shared.txt, strat.txt and also tooltips.txt, so bring copies of these files over from the RTW/data/text folder to the respective folder of our mod. Then, open shared.txt file and search for “denari”; you should find the entry {ST_X_DENARI}. If you take a look at its corresponding on-screen entry, you will see that this is the entry that defines the name of our currency in-game. Also, if you look at the entries following that, you will see the two that deal with the dating system and further down are four entries dealing with seasons of the year.
    **Note: As we have said again, an entry might have multiple instances within the same file, but only the one nearest to the bottom of the file will be used. So, we can actually edit the text here without changing any existing entries. If we simply change already existing entries, we must make sure there are no other instances of them further below in the file that will overwrite ours.
    Select and copy the lines for: the currency, the dating system and the winter and summer seasons (spring and autumn are unused in RTW). Then go at the bottom of the file and paste those lines there, leaving an extra blank line after them. We can now change the on-screen text that is associated with each tag.
    **Note:Always remember, editing the on-screen appearance of things, never change the internal entries that are coded inside brackets!
    First, replace the word “denari” with “mnai”. Then replace “Summer” with “Theros” and “Winter” with “Cheimon” and finally replace “BC” with “Before Christ” and “AD” with “Anno Domini”, so that the bottom of shared.txt now looks like that:
    Click to view content: 

    Image11: The internal entries have been left in tact, but their respective on-screen text has been changed. We are modding the instances of these entries that are closest to the file’s bottom, so we are sure they will not be overwritten by other possible instances.

    Save and exit the file. We are not yet done. You will have noticed that when you mouse-over the little “sun/snowflake” icon on the camp-map panel, a tooltip comes up with the season’s name on it. The text for that tooltip is coded separately in tooltips.txt. So, go there, find the entries for summer and winter, copy and paste them at the bottom of the file (always leaving a blank line after them) and change their on-screen text. That does it for seasons, but we are still not done.

    The currency name that is displayed in scrolls, for example when you offer a tribute and the scroll reads “We will offer tribute of XYZ denarii”, is coded in strat.txt, so we have to mod that as well. You have two options; either find each entry that includes the currency’s name separately and edit it (or create duplicates at the bottom of the file and edit those instead) or, make a global replace of “denarii” with “mnai” and “Denarii” with “Mnai”. Make sure that the character upper/lower case distinction is on, otherwise the global replace will also change internal tags, thus breaking the file. I chose the global replace option here, but you can ho either way.
    After all this replacing is done with, it is time to save the file and go in-game to check if everything works well. If it does, you should be looking at something like that:
    Click to view content: 

    Image12: The loading screen, the tooltips, the scrolls, all have been changed to display our names for the currency/seasons/dating system.

    Excellent work! This was but a small taste of the countless textual elements of the game that can be very easily changed in order to improve immersion. You can now experiment on your own, changing any text you never really liked in RTW.

    • Working Example

    Click to view content: 
    You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.

    Last edited by Aradan; April 14, 2010 at 02:10 PM.

  7. #7

    Default Re: Beginner's Modding Manual (RTW)

    Step 5: Traits and Ancillaries


    • What is a trait? (Link 1)
      Click to view content: 

      Traits are used by RTW to affect your characters attributes. Traits represent the physical and mental characteristics of your character, such as good general, healthy, intelligent, good farmer, etc.
    • What is an ancillary? (Link 1)
      Click to view content: 

      Ancillaries are used by RTW to affect your character's attributes. Ancillaries represent the retinue that your characters acquire over the course of their lives in the game. They can acquire retinues such as a doctor, a bodyguard, a cook, etc.
    • What is a trigger? (Link 1)
      Click to view content: 

      Triggers are used to control which traits and ancillaries are acquired by a character throughout their lives. A trigger has three main parts:
      • The event - determines when a trigger is tested
      • The condition(s) - determines what condition(s), if any, need to be met
      • The results - what happens when the event occurs and all conditions, if any, are met



    • Knowing the files
      Click to view content: 

      There are 4 files that are used to determine traits and ancillaries:

      export_descr_ancillaries.txt (EDA) - This file defines the ancillaries and their corresponding triggers
      export_descr_character_traits.txt (EDCT) - This file defines the traits and their corresponding triggers

      text\export_ancillaries.txt - This is the file that contains all in game text related to ancillaries
      text\export_VnVs.txt - This is the file that contains all in game text related to traits

      Now that we know which files we're going to work with lets move them into our mod folder. Copy the first two from RTW/data to BMM/data and the last two from RTW/data/text to BMM/data/text.
    • Changing a trait's/ancillary's description
      Click to view content: 

      So you want to change the description of a trait? Lets see how we go about doing this. We're going to change the title and description of the third level of the BadMiner trait.
      First let's look at the BadMiner trait. Open EDCT and go to the BadMiner trait (line 2930) and lets have a look at the third level of the trait. There are three pieces of information we want to look at: the Level, Description and EffectsDescription lines.
      The Level shows what the internal name of the text string for the level is (what you see when viewing character details).
      The Description shows the internal name of the text string of the level description (the description you see when mousing over the level).
      The EffectsDescription shows the internal of the text string for the description of the effects of the level (also seen when mousing over the level name).

      Since we are changing the title (Level) and description, lets keep track of the first two (Bad_Mine_Manager and Bad_Mine_Manager_desc).
      Next we need to give them new values, so lets open up export_VnVs.txt (it's in the BMM/data/text if you forgot), and find the entry {Bad_Mine_Manager}. The entry {Bad_Mine_Manager_desc} is just below, but if it wasn't we'd need to find it as well once we done.
      Let's change:
      Code:
      {Bad_Mine_Manager}    Bad Mine Manager
      To:
      Code:
      {Bad_Mine_Manager}    Terrible Miner
      **Note: The white space between the } and the entry is a tab, not spaces.
      Now let's change:
      Code:
      {Bad_Mine_Manager_desc}
      This man has an active aversion to the business of mining, and such works suffer under his mismanagement.
      To:
      Code:
      {Bad_Mine_Manager_desc}
      This man has an active aversion to mining, and any mines suffer immensely under his mismanagement.
      **Note: when changing an entry we are only changing the part outside the {}, swigly brackets, never what's inside of them as the inside part, the internal reference, links this file to EDCT.
      Save the changes. Start the imperial campaign as the Julii. Open the Rome Console (use the ~ key) and type give_trait "Vibius Julius" BadMiner 3. If you examine Vibius Julius you'll see he has the third level BadMiner trait, and it will have the changes we just made included.

    • Changing a trait's/ancillary's effects
      Click to view content: 

      So now that we know how to change what appears in game, we going to change the effects of a trait. If you've played RTW for a while you'll notice that when, as a Roman, you go from a National Hero to a Legendary Hero, the morale bonus you get actually goes down. We're going to fix that.
      The trait those levels are associated with is the RomanHero trait. Let's find that in EDCT. Once you've found it, we need to examine the effects each level has. In the last section we looked at the level name, level description, and effects description lines, this time we want to look at the effects line.
      The effects that are associated with a level are located below the threshold line for the level. If we look at the effects of the 5 levels, we'll notice that th values for TroopMorale are increasing by one per level, and the PopularStanding is increasing by 5, except for the last level. The TroopMorale goes from 4 to 2, so we're going to change it 5.
      Change:
      Code:
      Effect TroopMorale  2
      To:
      Code:
      Effect TroopMorale  5
      Save the change. Start the imperial campaign as the Julii. Open the Rome Console (use the ~ key) and type give_trait "Vibius Julius" RomanHero 5. Look at Vibius Julius' details and you'll notice that when you mouse over the Legendary Hero trait that it still shows "+2 Troop Morale".
      This is because we changed the internal values, but didn't update the on screen text. So, we need to do that as well. Open export_VnVs.txt and change the EffectsDescription line for Legendary_Hero, as per the previous section. Save changes, run the Imperial Campaign and again give Vibus Julius the 5th level of RomanHero, this time the description should be correct as well.

      Notes:
      1)For a complete list of the possible effects you can give a trait/ancillary look at the guides in the Additional Resources section, as they contain lists of possible effects.
      2)This section and the previous one can also be applied to ancillaries, the only difference is that ancillaries don't have levels

    • Creating a new trigger
      Click to view content: 

      OK, so we've now covered how to change various aspects of trait/ancillaries, we're going to take a brief detour and discuss triggers. Triggers are a big topic, so if you haven't read the earlier section What's a trigger please do so before continuing.
      We are going to add two new triggers to the game. One of peeves with the vanilla triggers is that the Intelligent trait has three level, but the second and third level aren't achievable through triggers, we are going to remedy this problem.

      Let's open EDCT and go to the very end of the file.
      Let's put in the comment seperator line that is used between traits and between triggers ;------------------------------------------, this is purely for readability and can be omitted if desired.
      First thing we need to do is determine a name for our new trigger. We're going to name the triggers based on what the triggers do, gives improved intelligence. On the line after the comment separator we'll add:
      Code:
      Trigger improved_intelligence1 ;This tells the game that here starts a new trigger called improved_intelligence1
      Now we need to pick the event that we can the trigger to happen on. If you take a quick glance through the file you quickly notice that most triggers happen on a few events, in this case we'll use the CharacterComesOfAge event. On the next line let's add:
      Code:
          WhenToTest CharacterComesOfAge ;you'll want to keep the spacing from the code box for readability, WhenToTest tells the game which event the trigger should be tested on
      It's time to add the conditions for the trigger. There will be only one condition for this trigger, we want the higher level of intelligence to be achieved, but only if the character already has the intelligence trait. For readability add a blank line after the WhenToTest line, then add the following:
      Code:
          Condition Trait Intelligent >= 1 ;this says the character who has just comeofage must have an intelligence of at least 1
      Last thing we need to do for this trigger is to add the affects line, this says what we want to happen (and with what likelihood) if all conditions are met. We want to add 1 point of intelligence to the character 1/3 of the time. Again add a blank line for readability, and then the following code:
      Code:
          Affects Intelligent  1  Chance  33
      The competed trigger should look like:
      Spoiler Alert, click show to read: 

      Code:
      ;------------------------------------------
      Trigger improved_intelligence1 ;This tells the game that here starts a new trigger called improved_intelligence1
          WhenToTest CharacterComesOfAge ;you'll want to keep the spacing from the code box for readability, WhenToTest tells the game which event the trigger should be tested on
      
          Condition Trait Intelligent >= 1 ;this says the character who has has comeofage must have an intelligence of at least 1
      
          Affects Intelligent  1  Chance  33


      For the second trigger, create a trigger that is called improved_intelligence2, the event is CharacterComesOfAge, the condition is the character has the Intelligence trait with a level of at least level 2, and they get 1 point of intelligence with 10% probability.
      Try to figure this one out on your own, and I've included the finished result in the below spoiler to check your work against.

      Spoiler Alert, click show to read: 

      Code:
      ;------------------------------------------
      Trigger improved_intelligence2
          WhenToTest CharacterComesOfAge
      
          Condition Trait Intelligent >= 2
      
          Affects Intelligent  1  Chance  10


    • Creating a new trait
      Click to view content: 

      Now, we're down to the last two parts, however; these require being able to do everything that we've done up until now and more. So we are going to create a new trait. We're going to create a Haemophiliac trait, the trait will reduce hitpoints to reflect that a haemophiliac has difficulties stopping bleeding.

      Let's go the end the traits section (search for trigger). Add the comment separator below the last trait (and before the first trigger). We're going to call the trait Haemophiliac, we're going to allow all family members to get the trait. To do this we add the following code after the comment separator:
      Code:
      Trait Haemophiliac
          Characters family
      We now want this trait to have a single level called FreeBleeder, that will require a threshold of 1 point. The level will have the effect of reducing HitPoints by 1. To do this we need to add the following: (look at the other traits to see how to use whitespace for readability)

      Code:
          Level FreeBleeder
              Description FreeBleeder_desc
              EffectsDescription FreeBleeder_effects_desc
              Threshold 1
      
              Effect HitPoints -1
      Save the change. Start the imperial campaign as the Julii. Open the Rome Console (use the ~ key) and type give_trait "Vibius Julius" Haemophiliac 1. Look at Vibius Julius and . . . CTD!! Worse, there's no error!!
      Why did we get a CTD at this point? We didn't add any of the text descriptions. This was done as a little lesson, if you go to view a characters details and you get a CTD, almost every single time it means a missing trait description.
      So lets add the descriptions. We need to add three entries to the bottom of export_VnVs.txt, {FreeBleeder}, {FreeBleeder_desc}, {FreeBleeder_effect_desc}. The level name will be: Free Bleeder. The description will be: This man has trouble staunching his wounds., the effects description will be: -1 from your general's hitpoints (how many hits your general can take before dying). If you're having troubles with the entries I've included them in the spoiler below, you should try to add them yourself and not just copy the provided ones.

      Spoiler Alert, click show to read: 

      ¬--------------------

      {FreeBleeder} Free Bleeder

      {FreeBleeder_desc}
      This man has trouble staunching his wounds.

      {FreeBleeder_effects_desc}
      -1 from your general's hitpoints (how many hits your general can take before dying)


      Save the change. Start the imperial campaign as the Julii. Open the Rome Console (use the ~ key) and type give_trait "Vibius Julius" Haemophiliac 1. Look at Vibius Julius and viola you're new trait works. That's all well and good, but now we need to add a trigger that enables the trait.
      The details of the trigger to implement the trigger are as follows: Name: haemophiliac_trigger, Event: CharacterComesOfAge, Condition: The trait Inbred should have a value of at least 1, Affect: Give 1 point to the trait Haemopiliac with a probability of 3%. Try to implement this on your own, if you're having trouble I've included a correct version in the spoiler below.

      Spoiler Alert, click show to read: 

      ;------------------------------------------
      Trigger haemophiliac_trigger
      WhenToTest CharacterComesOfAge

      Condition Trait Inbred > 1

      Affects Haemophiliac 1 Chance 3


    • Creating a new ancillary
      Click to view content: 

      We've now our way through traits, so we'll look a bit at ancillaries. In most respects the things you can do with ancillaries are very similar to those you can do with traits, with a couple of exceptions: You can't easily directly detect if a character has a particular ancillary, a character can have at most 8. Two other important limitations are that ancillaries can't be upgraded (i.e. like trait levels), and you can't directly check if a character has a particular ancillary.
      Now that we've gone through the basics let's create a new ancillary. So we're going to create a new ancillary called imaginary_friend. Since ancillaries have images we need to specify which image we'd like to have, and we're going to use the hooded_ancillary.tga image. We also want to exclude the ancillary from being available to barbarian factions. These three lines of code will look as follows:
      Code:
      Ancillary imaginary_friend
          Image hooded_ancillary.tga
          ExcludeCultures barbarian
      The next thing we add for the ancillary are the internal in game description lines. Since there are no levels the description line and effects description line should take their name from the ancillary name (i.e. imaginary_friend_desc and imaginary_friend_effects_desc respectively). We also want an effect of -1 to Influence. This code would look as follows:

      Code:
          Description imaginary_friend_desc
          EffectsDescription imaginary_friend_effects_desc
          Effect Influence -1
      The completed ancillary code is in the spoiler below:
      Spoiler Alert, click show to read: 

      Code:
      ;------------------------------------------
      Ancillary imaginary_friend
          Image drunkard_ancillary.tga
          ExcludeCultures barbarian
          Description imaginary_friend_desc
          EffectsDescription imaginary_friend_effects_desc
          Effect Influence -1


      Open text\export_ancillaries.txt so we can add the in-game descriptions to the bottom of the file. Like the traits the {imaginary_friend_desc} and {imaginary_friend_effects_desc} entries need to be added, but since there are no levels, the name of the ancillary is the third entry which is equivalent to the level title entry, so we also need to add {imaginary_friend}. The three entries are:

      Code:
      ¬---------------
      
      {imaginary_friend}    Imaginary Friend
      
      {imaginary_friend_desc}
      "My friend says you're bad.  I don't like you!"
      
      {imaginary_friend_effects_desc}
      -1 Influence
      Now we need to add the trigger that will allow the ancillary to be received during the game. The name of trigger will be imaginary_friend_trigger, the event it triggers on will be CharacterTurnEnd, the condition will be that the trait Insane is at least level 2. The affect (AcquireAncillary for ancillaries) is the ancillary is acquired with a probability of 5%. Add the trigger to the bottom of EDA using other triggers for help. If you run into trouble the finished trigger is in the spoiler below:

      Spoiler Alert, click show to read: 

      Code:
      ;------------------------------------------
      Trigger trigger_imaginary_friend
          WhenToTest CharacterTurnEnd
          Condition Trait Insane >= 2
      
          AcquireAncillary imaginary_friend chance  5

      Save all changes (both EDA and export_ancillaries.txt). Start the imperial campaign as the Julii. Open the Rome Console (use the ~ key) and type give_ancillary "Vibius Julius" imaginary_friend and Vibus Julius should now have the imaginary_friend ancillary.
    • Working Files
      Click to view content: 
      You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.
    • Additional Resources



    Last edited by Squid; April 06, 2010 at 01:38 PM.

  8. #8

    Default Re: Beginner's Modding Manual (RTW)

    Step 6: Units

    • Knowing the files

    Click to view content: 
    Units are one of the core elements of any strategy game, and of course this couldn’t be any other way in a game as focused on real-time, large-scale battles as RTW is. Units in RTW are the sum of a number of files, each dealing with a specific aspect of them, from the stats and the visual appearance to the names and descriptions:

    Text files:


    • export_descr_unit.txt (EDU) - Contains all the entries of the different units in the mod, with each entry including the internal unit name (used as unit id), the dictionary name (used as internal description tag) and the various unit statistics (# of men, cost, atk/def values, owner factions, etc).
    • text/export_units.txt (EU) – Contains a list of all the internal description tags of our units, as they are defined in export_descr_unit.txt and the on-screen name each one is associated with; that is, the unit names, long and short descriptions.
    • descr_model_battle.txt (DMB) – Contains all the entries of the models our units use on the battlemap, with each entry indicating the skeleton used, the model and the texture and sprite each owner faction uses for that model.


    Model files:


    • models_unit/unit_model.cas – It is the 3d model that determines the shape our unit’s soldiers will have on the battlefield.
    • models_unit/textures/unit_texture.tga.dds – It is the 2d texture that covers each soldier’s 3d model as a skin, and determines how the unit will look.
    • sprites/unit_sprite.spr (and sprites/unit_sprite.tga.dds files) – It is the low-res 2d image that replaces a soldier’s model once we zoom far away from a unit, in order to reduce graphic load for the system.


    Card files:


    • ui/unit_info/faction_name/unit_dictionary_tag_info.tga – It is the large unit card that appears on the unit information scroll
    • ui/units/faction_name/#unit_dictionary_tag.tga – It is the small unit card that appears on the recruitment panel, the unit selection panel etc.

    For now we are going to need only the text files (we will be dealing with the other files later), so copy export_descr_unit.txt and descr_model_battle.txt from RTW/data to BMM/data and the export_units.txt from RTW/data/text to BMM/data/text.


    Click to view content: 

    Having a rough understanding of which file does what when it comes to units, it is time we moved on to the aspect of RTW modding most new modders start their experimentations with, due to that it requires very little knowledge of how things work and can have a significant effect on the game: editing unit statistics.
    This is done via editing the export_descr_unit.txt, so open this file and have a look at it. Generally speaking editing unit stats is a simple matter of editing numerical values and adding or removing attributes in the EDU (though making meaningful editions that result in well-balanced stats is quite more complicated than that). At the top of the file there is a header by CA which roughly explains what each value of a unit entry does, so you should spend some time reading it; otherwise you can check the guide we linked to at the beginning of this chapter. After you have read enough to have a basic grasp of the EDU file, let's do some modding. We are going to be editing the Greek Militia Hoplites, so press ctrl+f and search for "militia hoplites". This is what the unit stats look like currently:
    Click to view content: 

    Image1: This is how Militia Hoplites' stats look on their unit-info card while unedited.

    As you can see they are currently not that good, so let's do those guys some justice and turn them into a more potent unit. First of all, we are going to change their numbers; 40 men (on medium unit-size settings) might be a bit too much for greeks, so go to the 'soldier' line of their entry and replace "40" with "36". Next, we're going to increase their offensive capabilities, so go to the 'stat_pri' line (the unit's primary weapon stats) and replace "5, 2" with "6, 3" thus increasing their attack and charge by 1. In the same way we will increase the unit's morale, by changing the first value of the 'stat_mental' line from "2" to "5", and its recruitment cost, by changing the second value of the 'stat_cost' line from "230" to "280". Our edited EDU entry should look like that now:
    Click to view content: 

    Image2: Our edited EDU entry for the Militia Hoplites.

    As a final touch, let's make our militia hoplites a bit more resilient to fatigue, shall we? In order to do this, we have to add the attribute named "hardy" to the unit's attribute list. So, just go to the 'attributes' line, add a comma to the end of the line and then add "hardy" afterwards. The result will be like this:
    Click to view content: 

    Image3: The "hardy" attribute has been added to the unit. Note that the attributes are separated from each other with commas.

    Now, save the file and exit, time to see if what we have done so far is working. Fire up BMM, start a campaign as the greek cities and check out the Militia Hoplites at a barracks. If everything went well, you should be seeing this:
    Click to view content: 

    Image4: Our new stats seem to be in place, well done. Notice how adding the "hardy" attribute has caused a new 'ability' to appear on the info card, and how increasing the unit's morale has caused the "poor morale" one to disappear.

    Our stat-editing has worked, and we are ready to move on to the next step.


    • Editing unit names and descriptions

    Click to view content: 

    After editing the Militia Hoplites and making them a bit better, we are now going to change the units textual elements; that is the unit's name, its long description (the one that appears on the unit-info card) and its short description (the one that appears when we mouse-over the unit in the Custom Battle unit-selection screen, for example).
    Those three elements are defined in the export_units.txt folder, in our text folder. Open it up and take a look. As you can see, there are multiple entries, each one comprised of 3 internal tags inside brackets and their 3 corresponding on-screen text. The internal tags follow a specific format: the first (name) is just the unit's dictionary tag, the second (long description) is the dictionary tag plus the "_descr" element and the third (short description) is the dictionary tag plus the "_descr_short" element. In case you are wondering what the dictionary tag is, open the export_descr_unit.txt again and find the Militia Hoplites entry. The second line is the 'dictionary line'.
    Click to view content: 

    Image5: What we are interested in is the second line of the unit's EDU entry, the dictionary tag; it is essentially a pointer that tells the engine where inside the export_units.txt file to look for the unit's descriptions. Note that the part following the ";" character in the EDU is a comment and is ignored by the game, do not think that this is actually where the unit name is defined. It serves only as a comment for anyone looking through the file.

    Now that we have identified our unit's dictionary tag (greek_hoplite_militia), go back to the export_units.txt file and ctrl+f that term. You should be taken to the section of the file looking like this:
    Click to view content: 

    Image6: Notice how the dictionary tag from EDU is used in this file to identify the appropriate descriptions for a unit. The on-screen name and descriptions are the ones marked with blue. Keep in mind that internal and external entries are separated with tabs, not space characters, and that paragraphs are created with the newline character (\n), not with "enter".

    So, let's change those descriptions then. First replace "Militia Hoplites" with "Hoplitai Haploi" wherever you encounter it within the descriptions. Then, in the long description, replace the last few words "to attack the enemy" with "to pin the enemy down", and finally at the end of the short description entry add ", but make effective defensive soldiers" so that the entries now look like this:
    Click to view content: 

    Image7: We have edited the unit's textual entries to our liking.
    **Note: Remember, we are editing only the on-screen elements of the description, not the internal tags! Also, the latest version of RTW ignores the first paragraph of a unit's description (everything up to the first "\n\n"), which is why the "Can Form Phalanx\nSapping Ability" part is left there. The game ignores it, and starts displaying text from that point on.
    Save the file and exit now, let's check out how we did in-game. Fire up BMM and check the descriptions. Try a custom battle as the greek cities; in the unit selection menu you can see the unit name and short descr, while when the battle starts you can right-click on the unit to view the long description. If they look like the picture below, you have done well.
    Click to view content: 

    Image8: Our unit's new name, long and short description are all in place, just as they should be.



    Click to view content: 

    In order to add a new unit we should go back to step 1 and remember all the various files that make up a unit: the text files, the model files and the card files. For the purposes of this tutorial we will assume that the latter two (ie the model, skin, sprites and unit and info cards) have been provided and we have to deal only with putting them in the appropriate folders and coding them in (ie linking them together and telling the game where to find them).

    We are going to deal with the text/code-related tasks first. Step number one then would be to define the unit's entry in export_descr_unit.txt. The easiest way to add a new unit probably is to copy an existing entry that is similar to the one we'd like to add and then edit it appropriately. Here we are going to add a unit of swordsmen to the Greek Cities, so just copy the entry of Iberian Infantry, whose unit id is "carthaginian infantry" and paste it at the end of the file. Of course after copying it the first thing we should do is change its unit id, because unit ids (or 'types') should be unique; so replace "carthaginian infantry" with "my unit", without the quotation marks of course.
    Next step is changing the unit's dictionary tag. As it is now, it reads "carthaginian_infantry", which means our unit will have the same name and descriptions as the Iberian Infantry, which is something we don't want. So, change the dictionary tag to "my_unit".
    After that, take a look at the 'soldier' line of our EDU entry. It has 4 elements, the first of which is a name: "carthaginian_infantry". Don't confuse this with the dictionary tag, even if they are the same. This entry here is the name (or 'type') of the model that our unit's soldiers will have on the battlefield. We don't want our unit to look like Carthage's iberian infantry, so we'll need a new model type which we will call "my_soldier", so replace "carthaginian_infantry" with that.
    Finally, as we don't really care about our new unit's stats right now, we skip everything else and set its ownership. The last line of the EDU entry defines which factions can own the unit.
    **Note: Owning a unit is not the same as being able to recruit it. A faction may own a unit, which means the unit may be present in the faction's armies at campaign start or it may be bribed from another faction's army and join this faction instead of being disbanded, but not be able to actually recruit it.
    Our unit still has carthage, spain and slave as owners. We should change that. Replace "carthage, spain" with "greek_cities", so that now our unit can be owned only by greek cities and rebels. Your EDU entry should look like that now:

    Click to view content: 

    Image9: This is how our new unit's EDU entry should look right before we save it. Notice how we have changed only a couple of things. That's because we used a unit as a base that was similar to the one we are trying to create. If we had taken a cavalry or missile unit as a base, there would be a lot more things to change.


    Save the file now, but don't close it, as we will be using it as reference for the next steps. We now have our unit defined, but not much else, so let's add some text to it. Open text/export_units.txt] and go to the end of the file. Copy the last unit's (Egyptian Axemen) entry and paste it right below. The first thing that needs doing here is to tell the game that the name/descriptions that will follow should be used for our new unit. The way to do that is the tags that preceed each of the three entries. They currently read "egyptian_infantry"; but if you check the export_descr_unit entry we just finished creating, our unit's dictionary tag is "my_unit". Therefore all three instances of "egyptian_infantry" should be replaced with "my_unit" inside the brackets, so that the entries now look like this:

    Click to view content: 

    Image10: The important part is this: Editing these internal tags to reference our unit's dictionary tag, linking the unit to these textual descriptions and telling the game to use them for it. Editing the textual descriptions themselves is the secondary task.


    Now that we have linked our unit to these descriptions, we may go ahead and edit them to match it. This is done just like in the step of the tutorial where we edited an existing unit's name and description, it just boils down to editing the text on the right-hand side that is outside the internal tags. We are not particularly interested in creating an elaborate description here with lots of details, so we will do something simple. Name the unit "Greek Infantry". Its long description should be the following: "Those brave warriors are Greeks' response to roman legions. Being light and mobile troops their main role on the battlefield is to support the hoplite phalanx, covering its flanks and rear so that enemies cannot outmaneuver it. While not particularly well-trained or well-armoured, these valiant soldiers can be a useful tactical option for any Greek commander and should not be underestimated." And its short one like that: "These agile troops are good for supporting the greek phalanx, but should not be relied upon to turn the tide of a battle." The result should look like that:

    Click to view content: 

    Image11: Our unit now has updated descriptions and a new name.


    The next step is to give our unit a different look. A unit's look consists primarily of the model (.cas file(s)) and the skin (.dds file), and also the sprites (.spr and .dds files) and ui-cards (.tga files). The purpose of this tutorial is not to show how to create any of those, so we are going to use already existing files (courtesy of Webbird). These files are provided as an attachment to this post.

    First create a folder inside your BMM/data directory and call it "models_unit". You should put the 4 .cas files in there. Inside this folder create a sub-folder called "textures" and in it place the "GREEK_AGRIANOS_MACEDON.TGA.dds" file. Going back to the 'data' directory, create another folder named "sprites", where you should put the "wbb_mac_euzonos_sprite.spr" file and its two accompanying .tga.dss files. Finally, again in the 'data' directory, create a folder named "UI" and inside that create two sub-folders, "unit_info" and "units". In each of these two folders create two sub-folders called "greek_cities" and 'slave". Put the large UI card (my_unit_INFO.tga, 41 KBs) inside the unit_info/greek_cities and unit_info/slave folders and the small UI card (#my_unit.tga, 13 KBs) inside units/greek_cities and units/slave ones.
    **Note: When adding unit cards attention must be paid to the following: The cards must be added in the subfolders of every faction that can own the unit. Those subfolders are named with the factions' internal names. Also, the unit info card's name must have the following format: unit_dictionary_tag + "_info", while the name of the small ui card's format is: "#" + unit_dictionary_tag.
    Now that we have added our unit's model, skin, sprites and ui-cards in the appropriate folders, there is only one thing left; to let the game know where to find them in order to use them. The ui-cards are used automatically, depending on the faction folder they are in and their name that corresponds to units dictionary tags, but the rest need to be defined explicitly. This is done in descr_model_battle.txt (DMB for short). You should have already copied vanilla's DMB in step 1 of this section, but if you didn't, do so now.
    Since we are adding a swordsmen unit, it is better if we use another swordsmen unit as a base for our entry, so press ctrl+f and search for "carthaginian_infantry" (the model entry for the Iberian Infantry). Copy the entire entry and paste it at the bottom of the file (make sure there is at least one blank line at the end). The very first thing we should do is change the first line of the entry the model "type". This is the entry's id inside the file and the name that entries are referenced by in other files, so there should not be two entries with identical type names. If you remember, when creating our new unit in export_descr_unit, we defined a new "soldier" name for it, as the first value of its "soldier" line. This is the value you should use as the new DMB entry's type name.

    Click to view content: 

    Image12: We have now linked our unit with its model entry.


    We may have linked our unit with a new model entry, but that model entry is still identical to the iberian infantry one in everything but name. So what we are going to do next is edit that entry and point it to the model, skin and sprites we added before, so that it uses those instead.
    The entry's second line, which reads "fs_swordsman" is the skeleton (and associated animations) our model uses. That defines the way the model moves, attacks etc. Our unit is a swordsmen unit, so the vanilla swordsman skeleton will suit it just fine.
    A bit below that there are 3 texture lines. They define which skin the model will use for each owning faction, using a "faction_owner, path_to_texture/texture_name_for_that_owner.tga" format. Iberian infantry had 3 owners, carthage, spain and slave, therefore its model entry must have one texture line for each, each pointing to a different skin (though that last part is not necessary, multiple factions can use the same skin for a model). Our unit has greek_cities and slave as owners, so we need to change things. Firstly, delete the texture line for spain. Then replace "carthage" with "greek_cities", so that each owner faction has a skin available. And finally change the texture's path and name to make it point to the skin we added in the previous step. Keep in mind that the file assumes RTW's main directory as the root folder of the path, and that the .dds element of the texture file is omitted.
    **Note: Remember these two very important things: Firstly, that DMB uses vanilla RTW folder as 'root', so in order to direct the game to a texture in a modfolder, you need to prefix the texture path appropriately. For example, instead of "data/models_unit/etc", the line should read "BMM/data/models_unit/etc" if the .cas file is in the BMM/data/models_unit folder. And secondly, even if the model's skin is a tga.dds file, the .dds part is omitted in the DMB entry.
    The result should look like this:
    Click to view content: 

    Image13: Note the existence of a texture line for each owner faction, the omitted .dds element from the texture's name itself and the addition of "BMM/" in order to point the game inside our modfolder's models_unit folder and not the vanilla one.


    Right below the texture lines there are the model lines, starting with "model_flexi". These define the actual model for the unit, the .cas files.
    **Note: It is possible - and this is how it works in vanilla RTW - to use different models for a unit depending on the viewing distance. When the camera is zoomed out from a unit, higher-poly models are swapped with lower quality models ones, so that the game runs faster. The values at the end of the model lines are the distance thresholds at which the respective models are displayed. Modders can either stick to this practise and use varying quality versions of the same model or just use a single (high detail) model for any distance, suffixing the model line with the word "max".
    Similarly to how you did it for the texture lines, edit the model lines to point to the .cas files we added for our unit. Higher detail models are displayed at short distances (so the "_high") is used up to distance 15, the "med" up to "30" and so on.
    Finally, when you are done with the model lines, repeat the same process you used for textures with the sprites. There are three sprite lines there, but you should only use two, for slave and greek_cities, and you should direct them to use the sprites we added for the new unit, editing their path to reflect our modfolder structure.
    **Note: Badly defined (mis-spelled or non-existent) sprite names will cause errorless CTDs, so be careful when coding them.
    When you are done with this step too, the DMB entry should look like this:

    Click to view content: 

    Image14: Note the existence of a sprite line for each owner faction, and the addition of "BMM/", just like for textures, in order to point the game inside our modfolder's models_unit and sprites folders and not the vanilla one. Also how the multiple models are used for different viewing distances.


    If all went well, we should now be ready to enjoy the fruits of our labour! Save descr_model_battle and exit, and fire up BMM to try the new unit in a custom battle.

    Click to view content: 

    Image15: Our new unit is ready for battle! Description, statistics, model, skins, sprites and UI cards, all work fine.


    Congratulations, yet another aspect of modding RTW has been mastered. Well done.


    • Working Files

    Click to view content: 
    You can find a working example of everything covered in this part of the manual HERE (make sure you read the included read-me file). You are strongly advised to not use it, but rather study it, in order to see how everything is done and then try to apply this knowledge and create something on your own.

    Last edited by Aradan; April 14, 2010 at 02:12 PM.

  9. #9

    Default Re: Beginner's Modding Manual (RTW)

    Reserved

  10. #10

    Default Re: Beginner's Modding Manual (RTW)

    Reserved

  11. #11

    Default Re: Beginner's Modding Manual (RTW)

    Reserved

  12. #12

    Default Re: Beginner's Modding Manual (RTW)

    Reserved

  13. #13

    Default Re: Beginner's Modding Manual (RTW)

    Great job on this and I think it merits to be pinned and publicized more. Quite alot of new people ask where to start and instead of giving them a link to the whole workshop section it`s obviously much better to have an all in one thread to recommend. Much easier to find the relevant info on each chapter.

  14. #14

    Default Re: Beginner's Modding Manual (RTW)

    Making it more public means I have to complete it, that's why I kept it hidden.

  15. #15

    Default Re: Beginner's Modding Manual (RTW)

    Is there any plan to continue this thread?? I was finding really useful, I can do text editing but before this my mapping skills were non-existant
    Proud member of the Patria Libera team.

  16. #16

    Default Re: Beginner's Modding Manual (RTW)

    Yes, I plan to keep working on it.

  17. #17

    Default Re: Beginner's Modding Manual (RTW)

    Phase 6, Units, has been completed.

  18. #18
    Kylan271's Avatar Domesticus
    Join Date
    Jul 2007
    Location
    Vietnam
    Posts
    2,235

    Default Re: Beginner's Modding Manual (RTW)

    I share same thoughts with Florin. My respects to you in your work here,hard to find some data as scattered like grains of sand on a beach throughout the forums. So this is handy.

    #Need data on plugins as I found a list in Vanilla files but how to use can be useful here.

    #Mission edits? There are different missions left out of vanilla,ie kidnapping and poisoning wells etc,would be fun to know how to do ^_*???

    #Is it useful here for you mention docudemons for triggers data??? Not everyone has a clue about them or where to look?

    Delete this after reading as to make your work neater if need be.


  19. #19

    Default Re: Beginner's Modding Manual (RTW)

    There is a tutorial on plug-ins by Squid, but their functionality is so limited that doesn't warrant inclusion here, imo.

    Regarding mission edits, I don't ahve the slightest clue as to how to add those you mention to the game; if someone has (and wants to take over the scripting section), be my guest. This was intended to be a community project at first, but volunteers were not that many.

    Docudemons are already provided in the Resources of the Ancs&Traits section.

  20. #20
    Frederich Barbarossa's Avatar Protector Domesticus
    Join Date
    Aug 2009
    Location
    Edinburgh, Scotland (From Kendall, Florida and proud!)
    Posts
    4,348

    Default Re: Beginner's Modding Manual (RTW)

    I need help editing map regions here. I tried and failed. The only map that was successful was the height editing one and the rest I did not try. Can you give your msn or something to teach people or answer questions online sometimes plox?
    His highness, žežurn I, Keng of Savomyr!

Page 1 of 12 1234567891011 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •