Krn3ll's RTW wall modding guide

[Seth Krn3ll]

Title: Krn3ll's RTW wall modding guide
Posted by: Seth Krn3ll
Modding area: Buildings (strategic - battle map)
Required software: Notepad (or other text editor), 3dmax, graphic editor like photoshop or GIMP
Summary: This tutorial explains how to mod walls in RTW.

PREMISE:

I am not SO good at modeling walls, but given there’s so few literature upon the matter, I share my knowledge for those who wants to get in the field. More experienced wall -modders are invited to deepen and correct what I state here.

KNOWING THE WALLS

Walls in RTW are somehow very hard to mod at good levels. Its easy to change their textures per culture, it’s a bit harder to change some of their features like the tower firing abilities, Its pretty challenging to create and add to the game new models for them, its VERY hard to change or mod mod brand new features for them (e.g. changing the rows of units who can stay, move and battle upon them, changing the siege approach points and functionalities and the like). I’ll do my best to give the reader at least an idea on all such aspects, even if on some of them I really have little – and troubled- direct experience.

First thing, BACKUP all the files involved. I suggest to backup a copy of the folders, so to be sure you can get back to start if things goes wrong.

Here is the list of files involved in the process:
data\descr_building_battle.txt
data\descr_engines.txt
data\descr_walls.txt
data\descr_building_battle\dbb_walls_*culture*.txt
data\descr_items.db
data\descr_items.txt
data\descr_items\di_*.txt
data\descr_projectile_new.txt
data\descr_oil_effect.txt

Lets see those fields one at a time, from the easier top the hardest.

1. CHANGING WALL TEXTURES

1. CHANGING WALL TEXTURES

Files involved: data\descr_building_battle.txt software needed: text editor, image editor if you have to create custom textures RTW gives the chance to switch the vanilla textures appearing on battle models, including walls. FIRST thing, as always, is to make a backup copy of the file. In case something will not work properly, you’ll always be able to restore the vanilla state. Then, all you have to do is to open descr_building_battle.txt and look for the “texture_variants” section. There you can do the changes you want, but be sure to let all them inside the brackets “{ “ and “ }”. Be very careful if you’re not skilled in file modding, because making errors there will result in many different possible CTDs. The use of this file is self-explanatory: you can tell here to the game engine which texture to use for each texture used. The variations can be assigned to player faction, player culture and current season. So you can give a specific texture set for greek in winter, or a specific one for macedon in summer, and the like in any combination. Syntax is easy: ; orig_texturename ; { ; <season or faction or culture, or any combination> variant_name ; } ; Note factions must be the underscored versions, ie no spaces. Also, no spaces allowed in texture names. ; eg: ; #roof.tga ; { ; winter #roof_winter.tga ; } Only tricky aspect in that job is to get which texture goes where. Some have self-explanatory names, some much less. Only way to get to it is to make the changes then test ingame if they fit what you wanted. If someone wants to enlist all the specific texture composing all walls levels and cultures to add them here for reference is welcome. Once saved the changes, no other work is necessary. Just start the game and if it does not CTDs you’ll probably see in game your new textures where you put them.

2. MODDING WALLS WEAPONS

2. MODDING WALLS WEAPONS

Related Tutorials: How To: Modify Siege Tower Aspects by Seasoned Alcoholic http://www.twcenter.net/forums/showthread.php?t=58787 Getting Rid of Boiling Oil (at last!) By Dol Guldur http://forums.totalwar.org/vb/showth...g-Oil-(at-last!) Files involved: data\descr_engines.txt data\descr_walls.txt data\descr_projectile_new.txt data\descr_oil_effect.txt software needed: text editor Towers and gates do have offensive features. They both can fire projectiles to the attacking troops and gates also can have boiling oil feature. All those may be changed in reloading rate, somehow modded in their effects or disabled. Lets say we want to modify the offensive capability of the towers used in Greek large stone walls. As said, all wall set are made of many pieces. Each level of wall have its own set, and each culture CAN have its own set of model items to use. Here’s the list of possible level/sets: Vanilla name – Item wall set names Wooden Palisade - wooden_short_wall_* Wooden Wall - wooden_tall_wall_* Stone Wall - *culture* _town_wall_* Large Stone Wall - *culture* _city_wall_* Epic Stone Wall- *culture* _huge_city_wall_* Each Item wall set have its own models, so there are for example greek_city_wall_straight, greek_town_wall_internal_corner, etc – then again eastern_town_wall_straight, eastern_town_wall_internal_corner, etc. So be sure to mod the level/culture set you are aiming to. As stated, now we want to modify the offensive capability of the greek large stone tower. The items used are greek_city_wall_watchtower for the straight tower, greek_city_internal_corner_watchtower and greek_city_external_corner_watchtower for the corner towers. 2.a) To change Towers/Gates firing rhythm: Open data\descr_walls.txt Look for “greek_city_wall_watchtower” You’ll find an entry like this: tower_straight { greek_city_wall_watchtower reload_ticks_arrow 5 reload_ticks_ballista 10 } The reload_ticks_* set the time needed for the tower to reload between each shot. Lessen it to have more fire rate, increase it to have less fire rate. The fact that it says both arrows and ballista is because some towers may have both weapons type. You may do the same for each tower model you want to fire-rating mod. 2.b) To mod the effects of wall tower weapons: Open data\descr_projectile_new.txt Look for “projectile tower_ballista” You’ll find an entry like this: projectile tower_ballista effect large_arrow_trail_set end_effect large_arrow_explode_set damage 12 damage_to_troops 5 radius 0 min_angle -30 max_angle 70 velocity 60 ;bounce 0.5 0.6 0.5 0.4 display aimed particle_trail invert_model_z model data/models_missile/missile_ballista_bolt_high.CAS, 40.0 model data/models_missile/missile_ballista_bolt_med.CAS, 80.0 model data/models_missile/missile_ballista_bolt_low.CAS, max and projectile tower_flaming_ballista flaming tower_ballista effect fiery_ballista_trail_set end_effect fiery_ballista_explosion_set effect_offset 1.0 damage 12 damage_to_troops 5 radius 0 accuracy_vs_units 0.15 fiery min_angle -60 max_angle 70 velocity 60 ;bounce 0.5 0.6 0.5 0.4 display aimed invert_model_z model data/models_missile/missile_ballista_bolt_high.CAS, 40.0 model data/models_missile/missile_ballista_bolt_med.CAS, 80.0 model data/models_missile/missile_ballista_bolt_low.CAS, max They both are projectiles used by the towers, along with arrows. There you can mod lot of things, but the more common modifications are: “damage” - defines the damage inflicted by wall towers to siege equipment of the attackers “damage_to_troops “” - defines the damage inflicted by wall towers to troops of the attackers “radius” - defines the width of an area effect “min_angle” - defines the minimum width of the angle of fire “max_angle” - defines the maximum width of the angle of fire “bounce” - defines the bounching property for the projectile fired If for instance you don’t want the tower to use any of such kind of weapon, you may set the “min_angle” and the “max_angle” to the same number. You can do the same for the other projectile types used by towers, like arrows. IMPORTANT NOTE Beware that changing the stats for projectiles will affect ALL units using them, not only the wall towers. Given I found no entry anywhere to give wall towers this or that specific weapon/projectile type, most people consider that as hardcoded. The only working way to mod it properly is to workaround and change the weapon/projectile to ALL the other units using it. This way all modding done on such projectiles will result working ONLY for wall towers. Here’s the how-to made by Wlesmana: - Make a copy of the entry "arrow", call it something else like "arrow2" - Change arrow_fiery entry's flaming with "arrow2" instead of "arrow". This makes flaming arrows secondary to units with arrow2. - Back in "arrow", change the min_angle and max_angle both with a value of 100. This will prevent arrows being shot at all because the angle is impossible - Do the same to the entry tower_ballista and tower_flaming_ballista - Do the same to scorpion entry to remove missiles from siege towers. Copy the entry first if you have scorpions in your game and rename to scorpion2 - Go to EDU.txt and change all "arrow" entry in missile type into "arrow2" - Do the same to scorpion if you have it (credits to Wlesmana for such trick) 2.c) To mod the boiling oil gate feature Open data\descr_oil_effect.txt You’ll find an entry like this: model_file data/models_building/models_spot/boiling_oil.cas envmap_tex data/textures/oil_envmap.dds ; checker_tex.tga ;data/textures/envmap.tga spurt_length 0.75 ; length of time to bbring spurt in and out. effect_length 2.0 ; length of time to play main main contact_pos_offset 0 -12 -5 ; offset in world units to ground contact position envmap_blend 0.75 ; blend factor between envmap and texture smoke_colour 75 75 75 ; red green blue anim_speed_mul 6 ; Play the anim at this times normal speed tex_scroll_speed 4 ; Units to scroll the texture per update. effect_contact_pos_offset -1 -12 -2 ; offset in world units to ground contact position effect_name burning_oil_set impact_effect_name burning_oil_steam_set All voices are already described. If you want to eliminate the weapon just use setting to avoid it: Dol Guldur suggests this: “contact_pos_offset 100 100 100”. To mod the rate of boiling oil use change the spurt_length. To mod the length of effect duration change the effect_length

3. CREATING OR CHANGING WALLS 3D MODELS

3. CREATING OR CHANGING WALLS 3D MODELS

Files involved: data\descr_walls.txt data\descr_building_battle\dbb_walls_*culture*.txt data\descr_items.db data\descr_items.txt data\descr_items\di_*.txt software needed: text editor, 3dsmax, image editor if you have to create custom textures To add brand new wall models to the game, you first need to have such models. If you are good at 3d modeling, you may create them yourself. I will not get here into the process of 3d models creations, so we start from the stage where you already have those models and explain just how to add them to the game. First thing, the walls are made of some pieces. You may want to mod just some of them or all of them, but keep in mind if you mod just some of them they shall fit with the remaining vanilla ones or you’ll have some mixed walls around with both your new models and some vanilla ones. Here’s the full list of walls models composing a wall set: Base models: straight internal_corner_link external_corner_link straight_link diagonal_link internal_left_link internal_right_link external_left_link external_right_link gateway tower_straight tower_internal_corner_link tower_external_corner_link Damage models: *_small_damage *_small_damage_anim *_small_damage_remains *_more_damage *_more_damage_anim *_more_damage_remains * _platform_collapse * _platform_collapse_anim *_platform_collapse_remains *_major_collapse *_major_collapse_anim *_major_collapse_remains All them must have their INFO files as well. INFO files are fundamental in walls modding, because they set most of their game interactivity. We’ll get on this in the next chapter, here we suppose you have working and fitting INFO files for all models. NOTE: if you go creating new models and are not able to create working INFO files for them, be sure to use the vanilla models as bases for all the dimensions, for the places to put the tunnel entries, for the general dimensions of walls and towers. Otherwise you’ll have units entering through walls, tower arrows coming out from nowhere, units using a little part of the wall roof or many other flaws around. So, here you have both models and INFO files and wants them in your game. First thing, put the new walls .cas models in Data\models_building\models_walls folder. If there's not such a folder, create it. The texture for your new wall shall be put in Data\models_building\models_walls\textures, but everything will work the same if they are put in Data\models_building\textures As far as I went, I’d been able to give new walls only following the culture-based vanilla structure. My tries to create new full rows of walls unlinked to vanilla structure didn’t work out yet. So, you can chose which culture and wall level to add your modded models. Lets say you decide to have them ingame at the place of greek_large_stone_walls.I’ll explain the process to add the new model of the gateway, named: “MYOWN_city_wall_gateway_high.cas” You’ll have to repeat it for all the new models you want to add. 3.a) open data\descr_building_battle\dbb_walls_greek.txt and look for “greek_city_gateway” Entry. It will look like this: greek_city_gateway { full_health 40 localised_name gateway level { min_health 0 battle_stats flammability_none impact_damage_low item greek_city_gateway physical_info info_walls/info_roman_city_gateway.cas } } And you’ll have to replace the vanilla item with your own: greek_city_gateway { full_health 40 localised_name gateway level { min_health 0 battle_stats flammability_none impact_damage_low item MYOWN_city_gateway ; item greek_city_gateway physical_info info_walls/info_roman_city_gateway.cas } } You have to do the same thing for all the new models you created. 3.b) open “data\descr_items.txt” and add a line like this: “include di_MYOWNWALLS_buildings.txt” No matter where you add it, just be sure not to put it inside some other scripts. Ok, lets make it easier: add this line at the first line of the file. 3.c) create a new text file and name it “di_MYOWNWALLS_buildings.txt” Save it inside “data\descr_items\ “ Folder 3.d) open your “di_MYOWNWALLS_buildings.txt” And add this line: type MYOWN_city_wall_gateway lod max_distance 4000.0 model_rigid models_walls/ MYOWN_city_wall_gateway_high.cas Again, you’ll have to add there an entry for each of the new models you created. 3.e) check if you added all the texture used in your new models to data/buildings_models/textures folder. If not, do it. Save all, go to data folder, make a backup copy of data\descr_items.db then delete it and start the game. Game will start and freeze. Give it a few seconds to do all his job then CTRL-ALT-CANC and kill it. Restart the game, enter in a city view where greek_large_stone_walls are present (or create a custom battle whit them in) and you should see your brand new walls. Of course, there are plenty chances you’ll get errors. Here are the most common: - game loads, tactical view freezes while loading: 90% the new models .cas are not good. - game loads, tactical view loads, the walls are the same as before: either you pick a settlement not using greek_large_stone_walls or you missed to do/save the 3.a) point changes. - game does not load at all: the new db had not been created or something went wrong in its creation. Check if there’s a new descr_items.db file in your data folder. If not, you made mistakes in 3.c) or 3.d) procedure. If so, god hates you. Restore the vanilla files and take some hours of sleep. - game loads, tactical view starts to load then crashes at some percentage: 90% there’s a texture missing problem. Check if you added all the textures used in your new models to data/buildings_models/textures folder. 10%, your new models cas files have problems, some bad fitting vertex thing or some problem with info files. Get back to 3dsmax. - game loads, all works but your brand new walls appears with some missing pieces, especially on corners. Hehehe, very typical. You made so much work to create one corner model so you said, hey well, lets just mirror-clone it and I’ll have the other one! Bad news, RTW don’t like bummers and so the mirror_clone feature does not work properly for RTW models. Get back to 3dsmax and remake the not working corner pieces. No mirror feature this time.

4. MODDING THE WALLS INFO FILES

4. MODDING THE WALLS INFO FILES

Related Tutorials: Complete guide to BPI - model info files or Complete guide to BPI - model info files by RedFox Explaination: Building Collision Files by Thor the Bassist Research: Info files for engines and buildings by Duke John Files involved: data\descr_walls.txt data\descr_building_battle.txt data\descr_building_battle\dbb_walls_*culture*.txt software needed: text editor, 3dsmax PREMISE Here we go. The INFO files in RTW are kinda tricky ones to manage, for some reasons. The first one is, the game uses them as BPI files, and we cannot open, edit or modify BPI files as they are – or at least I never found any software permitting so. So, we will have to work on .cas files which the game engine will later convert into BPI, but again we will never be able to check what exactly happened during such conversion. This missing step of control always leaves a gap because sometimes during the conversion something may go wrong, having ingame results working differently from the idea we made them for as .cas. Given that premise, here’s the simple procedure to edit or create new INFO files. A) INFO FILES SYNTAX IN TXT INFO files defines the parameters of an object- Being it a building, a mountain or whatever, the INFO files permits you to set its total health, some of its parameters like being more or less resistant to impact and flammability. Most objects in RTW does have an INFO file associated with them. Those INFO files are associated in the descr_building_battle.txt (DBB) file or in some dbb_* files that are actually included into the DBB file itself by such line: include dbb_[filename].txt Either way, the INFO files are associated with the game objects with this syntax: [ObjectName] { full_health [n] stat_cat [stat_cat set or blank if none required] localised_name [name] level { min_health [n] battle_stats [battlestats set or specific parameter or blank if none required] basespec [unused as far as I know] item [ItemName ] physical_info [ItemName_INFO].CAS } } So, you can have as far as four different Info.CAS files and ItemName for each object in the game, representing four different levels of health of the object. Of course you can use the same INFO or Item name for different levels, managing the differences as you prefer and letting them showed or not by a different aspect in the game. Here are some details on single code lines parameters: ObjectName is the name you set for this object. It may be the same of the Item or not, as you like. Those names are then used by some other files like descr_settlement_plan.txt or descr_walls to add them in the game. full_health [numbers] is total count of health for the object. You may set this to indestructable for special objects like the city INFO files, or mountains stat_cat In DBB are defined some grouped stat_cats mostly used to faster define buildings. Each of them sets a full health standard level, flammability and impact damage levels at once. Vanilla defined stat_cats are: tiny_wooden small_wooden medium_wooden large_wooden tiny_stone small_stone medium_stone large_stone medium_stone_nonflammable large_stone_nonflammable indestructable You can read and eventually change (probably even add if you feel the need to) the single parameters of each stat. Generally speaking they give an increasing resistance to damage, low flammability for stone and high for wooden. localised_name [name] this entry sets the name the game will visualize when the cursor roll over the item in game. Those names must also be defined in Data\text\building_battle.txt file. There are some localized name of general use which are none and ambient. The first will just produce nothing, the latter will make ingame appearing the sentence: “[culture] building”. They can be customized by adding them both to dbb entry and building_battle.txt file. The syntax for building_battle.txt file is: {MyBuildingNameUsedInDBBFileEntry} The sentence I want to see when I roll mouse over that building level Heach level sets a stage of health for the object and can manage its INFO parameters at that stage. One or more levels required, up to 4 min_health [number] Sets the minimum level of health for the current level. Must decrease with each level, last level must be 0. If there’s just one level, it’s 0 battle_stats specify the parameters of the object for such level of health. NOTE: in some files the battle_stats are not specified, leaving the general stat_cat chosen to work for all stages of damage. Known stats parameters are: flammability_high flammability_low flammability_none impact_damage_high impact_damage_medium impact_damage_none Basespec I have no idea about this parameter and its means. Seems to be nearly always blank or missing. Item ItemName This calls the name used in the di_* file for the object. This way a 3d model is called to represent the object at such stage of health (the level). It may vary at a different stage of the health, so that ingame the object looks different when its damaged or destroyed physical_info Object_info.CAS This calls the .CAS file with the INFO related to the current level of health for this object. Again, you may have different INFO.cas files for different stages of health of the same object and use them in different levels. So, for instance, a tower or a wall may have accessibility by troops until its too damaged. B) INFO FILES ELEMENTS IN .CAS Example INFO file Lets see what an INFO files may contain as a .CAS file now. There are some known kind of meshes there with some peculiar properties. a) collision_3d there can be just one collision_3d mesh in a INFO .cas file. The collision_3d mesh is a single tridimensional object and gives the game the encumbrance of the object. This obstruction will work ingame only for camera movements and missile hit purposes (the camera will move up when reaches the obstacle and missiles will impact it and stop there). The collision 3d is NOT VISIBLE in the game and WILL NOT interact with unit movements. So, you can have a little statue with a 3d collision 3 times higher or wider or smaller, as you like. Only missiles and camera movements will be affected by its dimensions and shape. About missiles, this file is important for some reasons. First thing, it defines when catapults or other siege attacking units will hit the object. So, if for instance yu want an object to be easily hit, you can make the collision_3d file bigger. On another hand, the collision_3d stops the missiles shot by units too. So, you can use the collision_3d of some objects to decide where units will be exposed or protected from arrows or other missile weapons – and again if and how units will be able to fire on enemies from a specific spot (e.g. from the top of a wall, a building or a tower). If you make a collision_3d with a very high wall on a side, on such side units will not be exposed to missiles and will not be able to directly fire their missile weapons. Or course, they will fire them at a high arch, with lower precision and effectiveness at a distance. Be aware that when you make a collision_3d the cursor during the game will recognize it so if you make it larger or of a different shape then the actual object appearing in the game you’ll have the cursor signaling its presence also outside the visible building. For instance, you cannot move units by clicking on a collision_3d covered area unless there are platforms there. b) collision Those meshes are single, flat (2D) objects and defines the areas where troops can’t walk. They shall be set at 0 altitude even if its not mandatory. You can have more then one collision meshes. Each collision must be named as “collision_01”, “collision_02” and on. Each collision mesh must be a single element, so if you use more then one polygon for a single “collision_[n]” be sure the weld the vertex where they match or the collision file will not work properly. Those meshes are pretty useful to let a building have some free areas or paths where troops may walk in/through. Note that when you use platforms or tunnels, troops on them will not consider collision_[n] limitations. c) tunnel Tunnels are simple meshes with 4 or 6 external edges (4 or 6 total vertex). They will be used by troops to walk across collision areas and reach platforms from/to ground or even to connect two or more platforms. Tunnels can be more then one and must be named as “tunnel_01”, “tunnel_02” and on. On a tunnel mesh the entrance will be set automatically as the shorter external edge of the mesh, then each external edge will be assigned to be non-entrance, then entrance, then non-entrance and on. If the tunnel is simple (4 sides) it will have two entrances and two sides, if its complex (6 edges) will have three entrances and three sides. To work, the tunnel entrance(s) external to the platform MUST be reachable by troops. So always check to have both vertex of external entrance(s) of a tunnel OUT of collision_[n] areas and not underground or other way covered or unaccesible, or troops will just not be able to reach the tunnel and use it. If you color the vertex of an entrance as black, units will enter/exit it backfacing it. Its useful for ladders. If you set just one tunnel accessing a platform, units will use it top enter and exit it indifferently. I noticed that most times, when you put two tunnels accessing a single platform, units will use one of them ONLY to enter the platform and the other ONLY to exit it. As I wrote, it works this way MOST TIMES but not ALL times, given many times I had two tunnels accessing one single platform and units using both or one of them as two way passage. Sill haven’t understand why, but well, its how it happens. Units accessing a tunnel will enter at the middle point of the entrance edge, walk in a direct single unit line and exit at the middle point of the exit edge. Units using a tunnel will not be selectable and cannot be redirected half way, and if you order to a group who’s already partially using a tunnel to move somewhere else units will act in a disordered way, and depending by circumstances some of them may be lost or try to regroup somehow. d) platform Platforms are areas where units can walk, run and fight regardless of collision_[n] limitations. A platform is made a 4 edges square and have an orientation, defined by the vertex color. Two vertex must be colored in black and they set the edge of orientation. You can have more then one one platform on a single INFO.cas file and each of them must be named as platform_0_[LETTERS], platform_1_[LETTERS], and on. I managed to have a max of 6 working platforms on a single INFO .cas file, dunno if there is a max number of them. The letters following the platform number in the name are at least 4 and can be: H,S,C or G. They set the properties of the edges of the platform. The first letter defines the edge of orientation and then the following in a clockwise circle. H (hard) means that edge is impassable by troops. S (soft) means that edge is not passable but troops can fall out of this side if pushed or jumped over (e.g. during battle or by a rush). Units falling over a platform will instantly and loudly die. C (communicating?) means that edge can be passed by troops. Beware that if there is another platform perfectly matching that edge units will pass on it, but if there’s nothing or the other platform is not matching, units will fall and die. G (ground) edges are special edges used to connect a platform to the ground. They are used by siege towers to let units enter their base and can be tricky for some reasons. Actually, in siege towers they must be inclined and that makes them tricky, due to the slot_platform mesh we’ll discuss next. Actually, G edges works pretty like tunnels but units can access them on all length and not in single lines. Unfortunately, for some unclear reasons, G edges often don’t work very well and units get stuck on them. A note on C edge parameter. On walls specifically most segments uses C edges on their sides, so to let the next piece of wall match them and permit troops to move from a piece of wall to another. This looks great as long as the two wall piece platforms edge match perfectly. If they don’t, units may not be able to pass at all, or try to pass and fall/die, or pass in just one direction and got stuck on the opposite, depending by the kind of mismatching (a more or less wide space between the edges, edges overlapping, edges at different degrees). I read about some more parameters addable to a platform name on a post by Duke John. I never worked on them so I just report here DJ’s observations: Geometries for slot rows are named 'slot_platform_N_M<_options>'. The N refers to the platform it is for, eg platform_0 has slot rows called slot_platform_0... The M refers to the rank of the slot row, with 0 being the front rank. Direction of the triangle doesn't matter. The row number M CAN be multiple digits. The optional part can contain a number of men, and/or an open/covered specifier. The number of men can be any number of digits, but the value must be at least 2. The open/covered specifier consists of H, C, and O for half-covered, covered and open. These values are repeated, so HO will flag alternate slots positions as half-covered and open. Eg, platform_0 could have slot_platform_0_0_10_HHO as its front rank of 10 soldiers, flagged as HHOHHOHHOH. Tests for validity include rank order - bigger rank should mean farther from the front edge. e) slot_platform To let troops use platforms they need slot_platforms. They are triangle-shaped parallel one to another meshes added at the same height or a little higher then the platform. They can and usually are more then one and represent each a row of troops. They must be named “slot_platform_1_00”, “slot_platform_1_01” and on, with the _1_ being the platform number and the 01,02 and on being the ID number of the single slot. The 00 must be positioned first and closer to the orientation edge of the platform, the others must follow subsequently. Troops deployed on a platform will turn facing the orientation edge. The direction of the triangle is not important. Given sometimes platforms may obtrude out of the actual item dimensions to be used on other items (it’s the rule in some wall segments) you may be careful that slots come enough closer to the side item’s platform slots so that units when deployed between the two platforms does group correctly – but also not too close to cover the other item platforms slot or troops will occupy twice the same position and on deployment they may fall and die. Each slot platform represent a row of troops. The more slot platforms you add to a platform the more row of troops are deploying there. Again, if triangles are too narrow or too close to each other troops will be deployed one on another and often fall and die. f) dock points Docks are cubes (not necessarily with all sides of the same lenght). They set the point where siege engines will attach the item. There are some kind of docks: dock_lad (or dock_ladder, they work with both names) and are used to define the point where ladders and siege towers will attach the item. There can be one or more on a item. They will work if named dock_lad, dock lad_01, dock_lad02 and on but also if they are all named dock_lad. The more dock_lad you add the more ladders will be used to climb that building. Actually, they work also if they are placed at a different height x and y from every other mesh of the INFO file. You may check ingame to decide where to place them to have the best fitting visual result. Only important note I can add there is that the ladders and the siege towers uses tunnels to move troops on the target platform, so if you use a tunnel in the sieged building too its ground level entrance must be pretty far from the building in the inner side of it – otherwise attackers will dock the ladder/siege tower then run against the wall at ground level trying to reach the inner tunnel and not using the siege tunnel. It’s a bug that kept me stuck for a week or so while modding some new walls. dock_sap are used by attackers with the sapping ability to make the building crumble. I never used it, but as far as I saw it just have to be placed somewhere at or near ground level near the building. dock_ram are used to define where the ram will stop and start hitting the gates. The dock_ram should be placed a bit far from the gate because the ram will slightly go onward during the ramming, so if you place the dock_ram right at the gate limit during the assault the head of the ram will protrude more and more inside the gate. Its your call, if you mod the gate too, to decide about this effect for a better result. Example INFO file 2 g) not yet studied elements: - Spawn positions (meshes to permit spawning and respawing of troops during a battle) Further experimentation needed to say more. - Entry way (meshes permitting to enter a muster field) Further experimentation needed to say more. - Muster field (meshes permitting troops to hid inside an item) Further experimentation needed to say more. - Banner positions (meshes setting the position of troop banners while they are hidden in a muster field) Further experimentation needed to say more. - Arrow slots (meshes used to define building ability to shot) Further experimentation needed to say more. C) SPOT FX files Spot fx are not element of INFO files. They are another kind of .cas files used to define the presence and position of some dynamic objects on an item. They set the position of vertical or horizontal flags, boiling oil spurting points, torches and the like. Further experimentation needed to say more. D) ADDING A NEW GENERAL INFO FILE TO THE GAME – WALLS HAVE A SPECIFIC CHAPTER NEXT To add an info file to the game: a) open descr_building_battle.txt with a text editor a1) decide to add the new info file there or to use an included dbb_* file for it. The latter is usually the best solution, so to use a specific include where you can group all the INFO files of a specific row of new objects. b) add an entry like this one for the new INFO file use: MyNewBuilding { full_health 100 stat_cat localised_name MyItemNameIngame ;(or none or ambient) level { min_health 0 battle_stats flammability_none impact_damage_high basespec item MyItemName physical_info MyItemName_INFO.CAS } } This will add the game an entry named MyNewBuilding, using ingame the model saved as MyItemName, not flammable, very vulnerable to attacks by catapults or other siege weapons, using all the features saved in the MyItemName_INFO.CAS file. Remember that the localized name MyItemNameIngame, to work, needs to be added to the building_battle.txt file too as explained. If you don’t want a localized custom name for that entry you should use “none” (cursor ingame will show nothing) or “ambient” (cursor will show “[culture] building” ingame). c) open a settlement plan file in data\settlement_plans folder. The plan you open and mod is the plan where you’ll see the new building ingame, so check to mod the right settlement plan. In the buildings section of the settlement plan you can add a line like this one: MyNewBuilding, 10.55, 75, 90, 40.7 This line will tell the game to place MyNewBuilding in the current settlement plan, at x position 10.55, y position 75, 90° degrees rotated, at the height of 40.7. Most buildings in vanilla game are placed at height of 0. Rotation is useful but also tricky, always test ingame results to decide if you want to modify parameters. Double check use of commas and/or points or the system will mess up things easily. E) WALLS INFO MODDING SPECIFICS Now, this procedure is standard for most objects’ INFO but Walls do have some more peculiar aspects to consider. First thing, walls dbb_files are for some reasons encoded – or at least I was not able to create and use custom dbb_walls files. So, you are forced to use the existing dbb_walls files which are: - dbb_walls_barbarian.txt - dbb_walls_eastern.txt - dbb_walls_egyptian.txt - dbb_walls_greek.txt - dbb_walls_roman.txt - dbb_walls_wooden.txt Each of them enlist the dbb entries for each piece of wall, which are: [culture]_town_gateway [culture]_town_wall_joiner_straight [culture]_town_wall_joiner_diagonal [culture]_town_wall_external_corner [culture]_town_wall_joiner_external_right [culture]_town_wall_joiner_external_left [culture]_town_wall_joiner_internal_right [culture]_town_wall_joiner_internal_left [culture]_town_wall_internal_corner [culture]_town_wall_straight [culture]_town_wall_watchtower [culture]_town_external_corner_watchtower [culture]_town_internal_corner_watchtower [culture]_city_gateway [culture]_city_wall_joiner_straight [culture]_city_wall_joiner_diagonal [culture]_city_wall_external_corner [culture]_city_wall_joiner_external_right [culture]_city_wall_joiner_external_left [culture]_city_wall_joiner_internal_right [culture]_city_wall_joiner_internal_left [culture]_city_wall_internal_corner [culture]_city_wall_straight [culture]_city_wall_watchtower [culture]_city_external_corner_watchtower [culture]_city_internal_corner_watchtower Of course [culture] stands for the current culture, e.g. roman, barbarian etc. Each of those entries have a single entry with some or lots parameters. Lets see an example: [code] roman_town_gateway { full_health 500 battle_stats flammability_none impact_damage_low localised_name gateway level { min_health 1 item roman_town_gateway physical_info info_walls/info_roman_town_gateway.cas spot_fx spot_fx_roman_town_gate.CAS } transition ; undamaged to collapsed { duration 120 physical_switch 0 item roman_town_gateway_collapse { 0 enable 0 dust_anim 90 4 2 2 0 3 120 disable } item roman_town_gateway_collapse_anim { 0 enable 0 anim 0 0 6 120 disable } } level { min_health 0 item roman_town_gateway_collapse roman_town_gateway_collapse_remains physical_info info_walls/info_roman_town_gateway.cas } } roman_town_gateway is the entry name. full_health 500 sets the full health of roman gateway to 500 when full. battle_stats flammability_none impact_damage_low says roman town gateway are not going to flame up and will receive a low amount of damage when hit. Nite that usually dbb entries does have stat_cat there and battle_stats only inside levels. Being it a relic of developers or not, walls does have battle_stats in both positions. localised_name gateway says that when the cursor ingame roll over that object it will show: “Roman Gateway” level starts the first level of damage for this object min_health 1 says this level will work from full health (500) to level 1 of health. Item roman_town_gateway says the game to use the di_* entry named “roman_town_gateway” physical_info info_walls/info_roman_town_gateway.cas says the game will use the INFO files of “info_roman_town_gateway.cas” located in games_buildings/ info_walls/ spot_fx spot_fx_roman_town_gate.CAS says the game will use “spot_fx_roman_town_gate.CAS” transition ; undamaged to collapsed is used to start a transition session. Transitions are used to define what will happen when a level is let and the next one starts, in such case when the roman gateway health will drop under level 1. The following parameters: duration 120 physical_switch 0 item roman_town_gateway_collapse 0 enable 0 dust_anim 90 4 2 2 0 3 120 disable item roman_town_gateway_collapse_anim 0 enable 0 anim 0 0 6 120 disable Are all defining the specific animations, effects and items to be shown in the transition duration. Yes, they all are customizable and no, I’m not gonna explain how because well, I do have a life sometimes Maybe in the future. Level starts the next level , and immediately says min_health 0 defining this level is the last one, ending with level 0 of health for the building. item roman_town_gateway_collapse roman_town_gateway_collapse_remains means the game will keep visible those two items from that point on physical_info info_walls/info_roman_town_gateway.cas means the game will use this info file for the building from that point on. Please note that, in such case, the INFO file is the same of full health building. That means the roman gateway will go on working precisely with the same features when its brand new or when its utterly destroyed. In some cases, buildings may work differently, for instance walls, once broken, do not host anymore troops on them, so they use a different INFO file. Given all that, if you want to add the game a custom wall, you’ll have to call the Custom Item instead of the “roman_town_gateway” item, along with its damaged and animated version. Then again, if you want/need to mod also the INFO files for specific features related to your modded walls, you’ll need to create and add the modded INFO files at the place of the vanilla ones. A few more notations for wall modders: a) walls .cas models are grouped in Data\models_building \models_walls folder. Its not mandatory, you can define the position of a wall .cas file in the di_* file where its set, but I recommend to keep this folder for all new walls models for simplicity. b) walls .info files are grouped in Data\models_building\INFO\info_walls folder. Same recommendation here. c) walls platforms will work during deployment ONLY if they are placed within the deployment area, which is set some meters from the wall piece scene root positioning. As walls do have some fixed grid to be positioned and work properly, you may check not to protrude platforms too much far from the root scene of the wall piece or the game will partially use, not use at all or even got errors and CTDs on troops deployment phase. d) the same grid limitation along with the quadrilateral forced shape of platforms severely limits the modding of walls shape, so that you can create and have ingame round shaped walls but you’ll have the hell to have them accepting troops deployment, moving and using properly their INFO features. Its possible, I actually did it, but its ALL but easy. e) vanilla walls INFOS are done with some peculiarities. For example, the platforms in some cases extrude from some wall pieces and in some other wall pieces are consequently shorter then the collision_3d. This will make no problem as long as 1) you make the modded platforms exactly the same size and shape of the vanilla ones or 2) you create a whole matching set (I mean the whole wall pieces, straight, links, gateway, towers etc) of info files to replace the vanilla ones Otherwise, if you replace just some INFO files and keep some vanilla ones, you’ll need to check your modded platforms fit perfectly with the ones you didn’t mod, or troops will get stuck, fall and die depending by the mismatch type.

***

Have fun.
Seth Krn3ll

[Kylan271]

You have to update your descr_cursor_actions texts also I think?

One thing in RTW that bugs me is the impassability of siege engines(unlike MTW2)through gates(not mentioning trees). Is there anything in your data on walls to help overcome this?

[Seth Krn3ll]

You have to update your descr_cursor_actions texts also I think?

One thing in RTW that bugs me is the impassability of siege engines(unlike MTW2)through gates(not mentioning trees). Is there anything in your data on walls to help overcome this?

never even opened "descr_cursor_actions" file.
I'll check what is it about.

Yes, at lotr:tw we are working at the impassability of gates to see if we can let elephant sized units inside the walls. Not sure if it may work for sieges too, that could be a hardcoded limit linked to city borders (e.g. the perimeter defined by walls or by an apposite file where walls are missing).

[Seth Krn3ll]

Added the 2. MODDING WALLS WEAPONS chapter

[Killerbee]

Great job !

[DAVIDE]

nice.. but what about replacing a Roman house with mine for example? the procedure is the same?

[Seth Krn3ll]

nice.. but what about replacing a Roman house with mine for example? the procedure is the same?

Nope, a lot easier.
Ambient buildings do not need a lot of passages.
Check out the tutorial I made about adding new buildings to the game:

Krn3ll Guide to add brand new buildings to RTW 1.5

Even if.. well, ambient buildings do not even need many of the steps explained in that one.
I shall add a chapter about ambient buildings sooner or later. They are very easy to add to the game.

[Seth Krn3ll]

Added the 4. MODDING THE WALLS INFO FILES chapter

[Kylan271]

Just on the instance of Seasoned Alchoholic's guide above,I found fire arrows can set towers on fire,due to 'flamability',however I note a wooden wall can not catch fire,so why is this? Then again buildings-though not tested.

[Seth Krn3ll]

Just on the instance of Seasoned Alchoholic's guide above,I found fire arrows can set towers on fire,due to 'flamability',however I note a wooden wall can not catch fire,so why is this? Then again buildings-though not tested.

Not sure which guide are you talking about.
Siege towers are flammable because there is a specific line assigning that feature in descr_engines.txt:

engine_flammable    true

On the other hand, wooden walls do not have any specific battle_stat parameter specified in vanilla game. I've never tried it before but if you want to see if they can be set on fire you should try adding the "flammability_high" at the battle_stats line in dbb_walls_wooden.txt and see ingame if it works.

[Kylan271]

The guide is within '2' modifying wall weapons. I have found the various walls data,but I will also check for wall death,as in buildings collapsing,since to have a wall catch fire it needs to burndown correctly also.

[Seth Krn3ll]

The guide is within '2' modifying wall weapons. I have found the various walls data,but I will also check for wall death,as in buildings collapsing,since to have a wall catch fire it needs to burndown correctly also.

Yep, we shall see if the burndown visual effect is working with walls.
Please reply here about your results, that may be an interesting info for some wall modders.

[nikossaiz]

I would like to ask if there is a way to change the angle that wall towers fire? i want to fire only to the outer side of the wall, is that possible?

[Seth Krn3ll]

I would like to ask if there is a way to change the angle that wall towers fire? i want to fire only to the outer side of the wall, is that possible?

Unfortunately in the mod I have been working in the last five years we removed the firing abilities from towers, so I never deepened such aspect. I can tell you that, as a side effect of studying the wall structures, I found some interesting coding lines about missile from towers, such as the use in 3d models of some indicators which may define angles and other effects of the projectiles, but I never worked practically on them so I can't be much of help.

You may check the other tutorials or posts I linked as references to see if you can find something more precise and useful there.

[Fallen851]

Hi Krn3ll,

I was successfully able to change the textures of the Greek and Roman walls, but the Eastern Walls I've been unable to change.

I added this piece to desr_building_battle text:

STONE_BUMPY.TGA
{
eastern Stone_Bumpy3.tga
}

And copied the new texture (Stone_Bumpy3.tga) into my models_building/textures folder, but it doesn't show in game.

Any advice on how to change the texture of the Eastern, Egyptian or Carthage walls?

Thanks for any and all help.