Research: Info files for engines and buildings

This thread will contain my research into the workings of the info files used by engines and buildings. I know that mod teams have knowledge about this and I hope that they will realise that the modding community needs to share knowledge to progress. And that they will contribute to this thread.

Some valuable information was posted by JeromeGrasDyke:



You've got the workings of the collision/bpi system pretty much correct. Part of the problem is that if the generated BPI file is incorrect in any way, the information gets discarded silently at load time, so it may just be that your new physical info .cas files do not contain everything that's needed or has some incorrect data in it.

Here's a chunk of general comments about the workings of this part of the game code:

DATA ENCODED INTO PHYSICAL INFO FILES:

General warnings:

First, always check the cas file with the cas viewer. Export options can be tricky. Some
items require vertex colour data, so export that. Once exported, the geometries should remain
separate and not have several merged into one.

For collision outlines and tunnels, make sure there are no duplicated verts. For
multi-level outline geoms (eg three-way tunnels), smoothing may have to be enabled to prevent
multiple verts being generated for different planes. Even though MAX may claim there are the
right number of verts, the exporter may add some, so check the CAS file!


PERMITTED GEOMETRIES:

Collision outlines and volumes:

Geometry names starting with 'collision'. 2D and 3D collision data. 3D collision data starts 'collision3d' or
'collision_3d' (note the 'collision' has to check it's not collision3d or collision_3d)
3D data is converted into a collision representation for projectiles and mouse interaction. All 3D collision
geometries in an info file are merged into one representation. There is a mechanism to provide a default
3D collision volume, ie if no collision3D geoms are found, it uses all the geoms in the supplied
default model. This is currently used in buildings to that lowest lod models are always used.
Listing the info file in its descr_building_battle entry with an extra no_3d_default paramater
prevents the use of the default, eg:
physical_info no_3d_default <filename>

2D collision geometries are projected to 2D, then have their outline traced to yield a clockwise connected loop.
Note that each geometry results in exactly one outline - disconnected outlines must be provided in separate
geometries. Vertices must be exact, and the vertex list for the geom should contain no duplicates. The
outline can be created in 3D, ie it need not all be in the same plane - however, when exported extra vertices
will be added if the normals are not smoothed, causing the tracing code to fail, so count your verts!


Tunnels:

Geometry names starting with 'tunnel'.

These are defined for either two-door or three-door tunnels currently. The geometry should
project to a 2D outline of four sides or six sides for two-door and three-door tunnels respectively.
The shortest edge in the geometry is used to flag a door position, with alternate edges then
also being considered to be doors. The sizes of the door edges dictate the sizes of the tunnel
entry and exit areas, while the middles of the door edges are entry and exit positions.

Note the outlines should have four or six verts, and so the geoms should also only have four or six
verts.

The entry direction for the door defaults to inward, ie from outside the outline to inside.
If the doorway is coloured with black verts, this flips the direction - used in siege towers.
Entry vector is 2D.

At this level, the tunnels are any-to-any tunnels. In battle_map, they get added as multiple
single-direction tunnels.


Platforms:

Geometry names 'platform_N_<edges>' for N 0-9. The names must have an edge-specifier part at the end,
which labels platform edges as hard (obstructed), soft (can fall off), and clear (allowed to pass over).

The geometry has its outline traced, and one edge must have verts that are black at both ends, flagging it as the
front edge for the platform (required for soldier positioning and other reasons). The edge specifier consists of
H, S or C for hard, soft and clear, and dictate the edge status in a clockwise order starting with the front edge.
Eg, a straight wall segment may have a hard front, soft back, and clear elsewhere. So, the platform would be called
platform_0_HCSC

Soldier positions on platforms are also specified in geometries. The positions are given as slot rows, one for
each rank. Each rank is defined using a line and number of men along that line, which we encode as a
single-triangle geometry using an isosceles triangle. The first soldier position is the middle of the shortest
edge, and the last is the opposite tip. By default, the spacing is roughly one metre, but the total number of
men for that slot can be specified in the geometry name, as can details of the nature of each slot position -
each position can be given info as to whether its covered, half-covered, or open, defaulting to open.

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.


Spawn positions:

For ambient spawning. These are named 'spawn' or 'respawn'. 'spawn' positions are battle-start only.
'respawn' can be used throughout the battle. They are encoded as isosceles triangles, with the base centre
being the creation position and the tip being the target after creation.


Entry ways:

An entry consists of a muster position and a set of entryways. Each entryway consists of start and end and a
number of waypoints (possibly zero). Start is outside the building, end is inside.

These are encoded as follows. The muster position is a simple geometry starting 'muster_'. It should be followed
by a one-digit number so that entryways can be associated with it. The centre of the geometry is used as the
muster position.

For a given muster point eg 'muster_0', entryways are defined as 'entry_0'. Multiple entryways for the
same muster point should be called 'entry_0_0', 'entry_0_1' etc. Entry geoms must consist of a simple outline
defining a directed line. Required features: odd number of faces and verts; number of verts = number of faces + 2;
all verts must appear in the traced outline (note same conditions for outlines as for collision outline -
no duplicated verts).

The line is defined by a single triangle at one end of a list of quads, like a pointy-headed worm.
If there's only the triangle, it has to be isosceles to flag which way it's pointing. The tip of the head, then
each edge centre of the linked quad sides, are used to define the line. See an example to clarify this.

A building can have multiple entryways.


Banner positions:

When a unit hides in a building then it's banner is displayed ontop of the building. The 'banner' geometry specifies at
what point on the building to show the banner

Arrow slots:

Arrow slots are defined for towers. Each arrow slot should have an 'arrow_horizontal_x' and 'arrow_vertical_x' geometry.
Where the x is a single digit to specify which slot number. The two geometries should be simple isoceles triangles with
a shared point to specify the weapons position (just inside the slot), and the angle of both geometries at that point
describing a field of view for the weapon.

Hopefully that puts you onto the right track about what should be in a physical info cas file and what the various entries do. It's a fairly complex system. I'm afraid comments on pathfinding in cities are going to have to wait for another day, as I must dash...

I am currently using the Siege Towers as a base to found out what Jerome meant. Most elements he explained are there such as the tunnel, platform and slot_platform elements. I suspect that wall info files have these to, so we should be able to duplicate the info using Siege Towers as a base. And then hopefully will the R:TW engine generate BPI files. Just like with ITEM and VEGE files. If not, then there might be a work around. Engines do not use BPI files so it might be possible to avoid using them for walls likewise.


The Zhanguo mod has a watchtower for walls that includes the elements explained above. There is also talk that the team has a tool. Perhaps it is to place the elements, but it could also be that the BPI files are automatically generated if the elements are included in the ITEM file as is the case with the watchtower item. Will test this.


Missed this: https://forums.totalwar.org/vb/showp...46&postcount=6
Hopefully they will release it soon enough before M2TW starts to cast a shadow on R:TW projects.

I thought the Zhanguo mod had a watchtower with the info elements, but I can't find it anymore... must have been modding for too long.

Edit1: It seems I got stuck. BPI files are as I expected indeed generated based on a supplied CAS file that contains the elements. However INFO files do not contain materials while the CAS exporter does not export without material so I added a material. R:TW does not seem to like this as it halts during loading. To go on the CAS editor might need to be adjusted so that it does not need materials to export.
I will verify this by editing a siege tower info file and saving it with a material. It does not use a BPI file so I can at least see wether the material creates an error.

I used the info file from a siege tower for a straight wall segment. I had hoped that since the build up of the file should be correct that it might just get past loading to notice that the generated BPI file is indeed working albeit without making sense in this case. However it also halted during loading, this could be because it perhaps uses things not normally associated with walls. There are a few other options but I will test that later.

And I think I have found the problem with the Siege tower bug, but that will require further research.

If alpaca from Chivalry: Total War or anyone from the Zhanguo mod can help then please do so. I know that you have some information.

Edit2: The colour of the vertices that tell which edge is the front one are blue instead of black in the engine info files.

I used the info file of the straight wooden wall segment for a large stone wall segment (ROMAN_CITY_WALL_STRAIGHT). I guess it contains nothing more than the Scene Main as there is no interaction with the wall. This time the loading process got a bit farther before halting again.

When using the stone wall segment (ROMAN_TOWN_WALL_STRAIGHT) as a substitute it halts at the exact same loading phase and I had almost given up but it did finish loading. A siege tower could be placed next to the wall, but then crew abandoned it (is this the siege tower bug?)
On the second try I was the besieged and loading time increased even more. I couldn't place my men on the straight wall sections, so it appears that when platforms do not match it gets ditched. But why does it ditch the straight one and not the others? It could be that the platform needs to be above the actual model and not inside.

Edit3: For one reason or another I could export a cas file without materials after importing a wall segment with "ignore texture" on.

Ok, I got it working. I placed a platform with a slot_platform on the exact same height, width, length as the top of the straight wall segment. I changed the edge vertices to the colour black and it simply worked. Note as I wrote in Edit3 of the previous post that somehow I could export without materials and that might be the key. Although it might have also worked before if I had justed waited longer. The increased loading time does worry me a bit, but perhaps that is the sacrifice until someone comes up with a tool. A tutorial will follow.


Normally I would jump into the air and be very happy with making a modding breakthrough. But this time it is severly diminished by the fact that modding teams and modders are keeping things secret. I found out that some use their information to trade with other teams. I found out that there is a new CAS editor (that fixes animation flickering and multiple textures) but as far as I know it wasn't announced/released publicly. One team keeps their tool secret until they have made a release.

It is understandable that you want your mod to be unique but in my opinion this should not result in an overly competive community. We should do this for fun and the occasional pat at our back and not for the prospect of money (contributions) or personal fame at all costs.

I am very dissapointed in what the modding community is turning into and I fear for the future. M2:TW will be even more complex than R:TW and if we don't start sharing every discovery that we have made then we are only handicapping ourselves.

I know that I haven't made tutorials for all my discoveries. Some I merely explained in a quick reply when asked for while others were never noticed. If anyone has the idea that I have made a breakthrough (by looking at my screenshots or posts) then please send me a pm or post a question where you request for some more info.

:shame:

Quote:

---

I am very dissapointed in what the modding community is turning into

---

DJ, please don't say that....

It's a great shame when modding teams hold back info, if they had always done this, then there would only be one mod (if that). Its always been a point of honour not to hold back from the community anything that I've done. I might try to make my mod individual, but I'll do that by methods which all modders can use. Such as scripts and little tricks with the campaign map, well designed models etc.

I don't think it's necessary to be so pessimistic. I'm one of those foolish naive people who thinks that most people are decent enough, and I also think that whilst modders are still working together, the community spirit will always be there.

I'd like to second what you said, but you say it in such a negative way that I have to tweak it. This goes out as a message to all modders as well, though we work in teams that separate us and we all compete a little, lets not forget that if we didn't share, we'd be nowhere. If you take from this community, try to give something back to it.

I hope you are misunderstanding the situation, I don't have any more info than what you have (which is basically Jerome's post).
It's true that I figured out some parts of how to make the game generate those BPI files and make them work. It's also true that there is a newer version of Jerome's cas export tool which can export colored vertices and doesn't need materials anymore (which he made after I showed him the post you quoted), but it can be found on the eb webspace and thus is publicly available - although he didn't announce it in a separate thread, he mentioned it in a thread in the EB subforums on TWC.

About this "trading" issue:
1. I don't see why models should be drastically different to research. I spent some hours to figure out how to make cas files the game can interpret and I think it would be fair if I got some help in exchange for that time (which I could also have spent scripting or modelling in which case you wouldn't have bothered).

2. It's not like I'm deliberately "holding back" anything, neither is Zhanguo. I already told you the story about Verci's script.
Additionally, you should understand that I don't release everything publicly right when I discover it anymore, because a) it won't always work and b) if I don't get anything for it, I want at least to have a small head start in experience on it (if you checked the tutorial section lately, I posted a method of adding buildings to BI to which no-one replied, which wasn't exactly encouraging, either).
Another reason for my not releasing what I knew (and only for a few days) is that I simply didn't have time to work it all out, I merely got tunnels and platforms (including slots) to work, nothing else, and I think you pretty much figured that out yourself within a few hours. So what about it? Anybody with enough brains could do that, the info was all there. It's a bit like your tree models really, you worked that out pretty much before you released it, too. And you didn't release your models yet either. So let him who is without guilt throw the first stone, right?

A general note on your behaviour: It's not exactly good style either to drag such things to the public without listening to the other side of the argument first. You might just have sent me a pm, and we could have discussed the matter. I'd probably have provided you with an example of what I found out when I'd found time (which I don't have atm because of exams).
To conclude as I started: I really hope you misunderstood the situation, otherwise I think I should feel offended.

Quote:

---

Originally Posted by Duke John

Normally I would jump into the air and be very happy with making a modding breakthrough. But this time it is severly diminished by the fact that modding teams and modders are keeping things secret. I found out that some use their information to trade with other teams. I found out that there is a new CAS editor (that fixes animation flickering and multiple textures) but as far as I know it wasn't announced/released publicly. One team keeps their tool secret until they have made a release.

---

I love the misinformation of the R:TW modding community; it's always good for some drama :). The updated script is public but was not announced (although I did mention it in a thread or two) because it is experimental. It'll be "announced publicly" when it is more stable... I haven't heard of anyone withholding information or tools except for the Chinese mod team (whose name I forget) and even then I don't understand what they are withholding and would guess it to be trivial.

Quote:

---

Originally Posted by Vercingetorix

The updated script is public

---

:shocked3: my precious!! keep it secret, keep it safe!

I think it's just the lack of a proper pool of information on the more complex aspects of modding right now, compared to when modding just started and everyone was excited about new tools that came out. But now most modders and teams are content with what they got that they care little for further improvements, especially when it features things they won't use for their mod. So news of new tools get spread out slower.

I myself had to find out about Verc's updated tool by bugging alin on a weekly basis, then had to convert my animations at the last minute before a patch release.

My lack of reply to research threads like this is because I have no idea what's going on, but I do appreciate what everyone is doing, and yes, withholding information on discoveries is bad, bad, bad. Even if someone don't release their tools or models or whatever, it's always common courtesy to at least provide the community with some info. Especially when your tool is someone else's tool that you modify.

So thanks, DJ. For all the support to the modding community.


PS. I'm still figuring out how to make those nice trees in your other thread but so far mine has been pretty crappy, so I didn't respond out of shame.

Guys guys, let it go... alpaca I personally DID read your buildings tutorial, and found it wonderful and very helpful. My only error was that I didn't post this, but don't hold that against us :) Just post things that you think are helpful to everyone :) I got like 4 replies to my settlement plans tutorial on TWC, but so what :) And plus, over the months I've received quite a bunch of private PMs about it, etc. Anyhow, good job guys. DJ you rock.

i haven't read through . too long passage to read :)
the tools of us just follow the CA's direction to change some code of the CAS import/export .i had been send to EB ,CTW ,LOTR TW and some people a long time before our mod release.
it seems that Vercingetorix had been add our tools code to the cas_import_export_79b and fix the bugs .you can use it for test .
for the bpi file , as i know , it generated by RTW engine itself . it means you use the cas tool to creat a new 3d model , then mix in game . when you go in game the system would generate a new bpi file of itself .but remember , if you use the original name of the tower file of the game , you should expack the pack files and delete the bpi files of that tower . after generate a new bpi file , you'd better repack it in the pack file , because our beta demo of ZTW haven't repack it in pack file so the tower Animation didn't work . we found it after the beta release .....(beta was mixed very hurry we haven't test enough)
i think you also can make a new bulidings that can stand soldiers on it inside the city . we haven't test but work in theory.
what's more , there are some guilds of whole settlement plan and buliding of our know are writting . i post some guilds 2 days before in TWC ,but it in chinese , sephodwyrm is work on the translation . if you can find some friends who know chinese well , you can find them to read first .
http://www.twcenter.net/forums/show...1322#post801322

Dj do u know how to make this part work ?

Quote:

---

Arrow slots:

Arrow slots are defined for towers. Each arrow slot should have an 'arrow_horizontal_x' and 'arrow_vertical_x' geometry.
Where the x is a single digit to specify which slot number. The two geometries should be simple isoceles triangles with
a shared point to specify the weapons position (just inside the slot), and the angle of both geometries at that point
describing a field of view for the weapon.

---

I mean I made new towers but didn't edit anything about arrow slots , are they firing in automatic per a text file to be edited or is something to be done on the model?

I haven't tried it, but I guess that you need to define the arrow slots in the info model. To see how an info model looks like open a siege tower info file and keep Jerome's post at hand. You will then start to understand how it fits.

To test my theory I used a siege tower info file as a base, kept a single platform plus the Scene Root. Then I placed at the same height and with the same width and length as the top of the wall. Checked wether the front edge was at the right place (I guessed the outer side) and CSCH or whatever it should be. I got it ingame and while there was 1 soldier getting stuck it did work.

I am the moment busy with other things. This thread was mostly intented to show that the interaction with walls and buildings can be edited. I am far from being an expert on this issue.

Quote:

---

Originally Posted by PROMETHEUS

I mean I made new towers but didn't edit anything about arrow slots , are they firing in automatic per a text file to be edited or is something to be done on the model?

---

This is probably done on the model.
You have to provide two triangles that look like an arrow pointing to the inside of the building (and are orthogonal to each other).

Cool, so in theory you could edit out the arrows completely, and even better, change towers so that they could be walkable and "archer-able", like Zhanguo did. Nice stuff.