an attempt to animate spiders

**Lord Adherbal** · 09-14-2005, 16:17

Well, the way the settlements were done was by constructing them from stand-in pieces in Max, exporting a .cas and then running a small utility called cas_converter on it which would generate a large chunk of output for inclusion in descr_settlement_plans.txt ... nothing as complex as a whole "settlement editor" was ever written. But I will discuss releasing the utility and a sample settlement with El Queso Grande

I'm developing some tools myself and most of it is working fine. The only problems I'm still having is with pathfinding models (so called "streetplans"). I've tried to create some for the new settlement plans I made (small medieval castles) but the results aren't very satifying yet. I'm still "researching" so maybe I'll eventualy figure it out myself. Or hopefully that tool you guys used can make it a bit easier. To conclude if we dont get this tool or we can't figure out how to make pathfinding plans then it would be appreciated if a CA member could help us out. New settlements are cool, but there's not much point if units cant move through them properly

Another problem I'm facing is making new battlemap models "solid": right now my units can walk straight throught them. It appears you need to define a "physical_info" model, for example:

Code:

	bath_house
	{
		stat_cat medium_stone
		localised_name bath_house
		level
		{
			min_health 0
			battle_stats
			item		bath_house
			physical_info	info_bath_house.cas
		}
	}

It appears the game generates these files (BPI format) if they don't exist, but the problem is that even with the newly generated BPI file units still walk through new buildings as if they aren't there. However if I use an original RTW BPI file then the new building does block units (but obviously the dimensions of the collision box doesnt match my new model). So I wonder what I'm doing wrong, or whether there is a proper way of making collision boxes for new battlemap objects.

Sorry for asking so many questions but I have to use every oppertunity to get information from a CA member

**JeromeGrasdyke** · 09-14-2005, 17:01

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...

**Lord Adherbal** · 09-14-2005, 17:56

wow thanks, that sounds usefull - and complicated

but hey, we modders kick on that kind of stuff

So once I've created such a cas file and use it in physical_info, the game turns it into a BPI file ? Or how are BPI files related to physical_info cas files ? Also, since we can't open/import BPI files (unless Vercingetorix takes care of that) could we have a hand full of examples of those physical_info cas files ? I guess we'll eventually figure it out, but I'm sure a few examples would get us on the right track much faster. Guess that'll be up to El Queso Grande again