SIEGE UNIVERSITY 2

Siege University II Tutorials
Modding FAQ
095: Upgrading DSII
100: The Basics of Siege Editor
201: Compass Map Radar
202: Conversations
203: Journal
204: Quest Indicator Icons
205: Start Positions
206: Teleporters
207: Town Portal Restrictions
208: Weapon Effects
209: Flick
210: Tuning Grids
211: Setting Up Good Map Lighting
212: Setting Up Simple Node Fading
215: Building Data Tables

Siege University I Tutorials
200: Concepts and Terminology
201: Templates
203: Triggers
204: Moods
205: Fades
206: Elevators
211: Naming Key
213: Dungeon Siege Resource System
301: Introduction to Dungeon Siege Architecture

Third Party Tutorials
A Simple Mod Part One - Armor Textures
A Simple Mod Part Two - A New Armor
Beginners Guide to Stitching Regions
How to Open and Create Tanks
Making Chants Work in a New Map
Ornaments
Understanding the NKK

Useful Links
Siegetheday.org
Dungeon Siege Outpost
Dungeon Raider
Kdawg.org - List of useful Links
MCarp DS Nodes
Dungeon Siege 2 at Gamefront
Broken World at Gamefront

Overview

·         Example

Generating the Radars Polishing the Radars Stitching the Radars Troubleshooting Tips and Tricks

 

Overview


When radars are generated, four things happen:

·         First, top-down maps of each fade group in the region are generated. These bitmaps are, at most, 256x256 pixels; if the fade group won't fit in that space, multiple bitmaps are generated for that fadegroup (example).

·         Second, the radar.gas file is updated with the coordinate info for all the radar bitmaps; each bitmap has an entry in radar.gas which contains references to all the bitmaps for the fadegroups connected to it, and coordinates for their relative positions. (example)

·         Third, each node in the region saves which bitmap it's associated with and the coordinates at which to display it. (example)

·         Fourth, the positions of any radar_icon gizmos in the region are saved with respect to the radar for the fade group of the node they're sitting on. This information is written to radar.gas as well.

What all this means is this: when the focus character is standing on a node, the radar bitmap associated with that node is drawn on the compass map, at the coordinates specified in the node's properties. Then, any radar bitmaps referenced by that radar bitmap's radar.gas entry are drawn, at the relative coordinates specified in radar.gas. (These bitmaps are only drawn if the fade groups they are associated with are faded in.) Then, for every faded in bitmap drawn, all the bitmaps referenced by their radar.gas entries are drawn, and so on. Basically, the radar drawing code walks outward along the chain of radar.gas entries until it hits a bitmap associated with a faded out fade group.

 

Example


Let's look at a simple example: the a2_03_01x_sa_amrendun2 region in the ds2_world map. This region has 10 fade groups, all small enough to fit on one 256x256 bitmap, so 10 radar bitmaps will be generated. The fade groups are:
1,1,-1
1,2,-1
1,1,1
1,1,2
1,1,3
1,1,4
1,1,5
1,1,6
1,1,7
1,1,8

1,1,-1 is the main room and 1,2,-1 is the side room. The other eight fade groups are ceiling beam groups in the main room. Our goal is to get the two room bitmaps to draw correctly without drawing the ceiling beam groups.

 

Generating the Radars


First, we open the region and turn off view objects, view gizmos, and view lights. If we don't, they will show up on the radar bitmaps.

Next, select 'Generate radar bitmaps' in the file menu. The radar dialogue will appear. Click 'Generate Current Region', and save after the dialogue disappears. Be sure to save nodes.

The radar bitmaps that were generated are strict top-down images of the fade groups:

radar.gas has been updated with the coordinate information for each fade group. Each fade group has a block in radar.gas like this:

    [t:radar_tex,n:a2_03_01x_sa_amrendun2_1_1_1_x0_z0]

    {

      i height = 32;

      i level = 1;

      i object = 1;

      x region = 0x00000FD1;

      i section = 1;

      f sort = 0.100000;

      i width = 16;

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_x_x0_z0;

          f u = 35.561871;

          f v = -0.000003;

        }

        [stitch_helper]

        {

        }

    }

The 1,1,1 fade group only connects to one other fade group (1,1,-1), so it only has one adjacent_texture block. (Note that 'x' is used in place of '-1' for fade group numbers in this file.) Compare that to the block for the 1,1,-1 fade group:

    [t:radar_tex,n:a2_03_01x_sa_amrendun2_1_1_x_x0_z0]

    {

      i height = 128;

      i level = 1;

      i object = -1;

      x region = 0x00000FD1;

      i section = 1;

      f sort = 0.900000;

      i width = 128;

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_2_x_x0_z0;

          f u = -62.588898;

          f v = 0.000003;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_8_x0_z0;

          f u = 5.689902;

          f v = -14.224749;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_7_x0_z0;

          f u = 19.914652;

          f v = 0.000000;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_6_x0_z0;

          f u = 5.689903;

          f v = 14.224751;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_5_x0_z0;

          f u = -8.534845;

          f v = 0.000004;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_4_x0_z0;

          f u = 5.689900;

          f v = -29.871965;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_3_x0_z0;

          f u = 35.561867;

          f v = 0.000000;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_2_x0_z0;

          f u = 5.689899;

          f v = 29.871969;

        }

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_1_x0_z0;

          f u = -35.561871;

          f v = 0.000003;

        }

        [stitch_helper]

        {

            5daf1dcc_10 = 0.000000,0.000000;

        }

    }

This fade group block has 9 adjacent_texture blocks; one for every other fade group in the dungeon. Also note that this fade group has an entry in its stitch_helper block: that gives the bitmap's coordinates with relation to the node in another region that it is stiched to. This dungeon is reached by an elevator, so it has only one stitch. The radar_stitch.gas file looks at the stitch_helper blocks to stitch all the regions' radars to each other; look at Stitching the Radars for more info.

In nodes.gas for the region, each node has had radar entries updated; for example, node 0x0120368f now has these entries:

            radar_tex = a2_03_01x_sa_amrendun2_1_2_x_x0_z0;

          f radar_u = 0.455548;

          f radar_v = 0.500000;

This node is in the 1,2,-1 fade group, and the radar bitmap has the offset 0.455548, 0.500000 with relation to the node. If the player stands on this node, these entries will set in motion the radar drawing process.

There are no radar icons in this region. If there were, blocks like this would appear in radar.gas:

        [t:radar_icon,n:icon*]

        {

          b directional = false;

          b initially_active = false;

            name = a2_estate;

            tex = b_gui_ig_m_i_rdr_quest02;

          f u = 0.911140;

          f v = 0.155622;

        }

This information is taken from the radar_icon gizmo's properties and from its position on a node. The above block will appear in the fade group block for the fade group that the node belongs to.

 

Polishing the Radars


Now, if we started the game and walked around in the region, we would see the radars, but they wouldn't be as helpful as we would like. There are areas in the 1,1,-1 fade group that the player can't walk to, but at this stage, they appear on the compass map. Also, the ceiling fade groups are being drawn, and they are unneccessary and take up texture memory.

To take care of the first issue, we will polish the radars in photoshop. The way I did it in DS2 was to draw white borders around the areas the player could walk, and fill in non-walkable areas with black. I then extended the bitmap's alpha mask to include the black areas so that they wouldn't show against the compass map's grey background.

·         Download the raw_to_psd converter here. At the bottom of this page, you'll find a text file which will explain how to set up your file types so that you can convert raws to psds and vice-versa.

·         Next, convert the bitmaps for all the fade groups that the player can walk on to .psd format. In our example, the player can walk on fade groups 1,1,-1 and 1,2,-1, so we'll convert them to .psd format and open them in photoshop.

·         Border the walkable areas of each fade group and cover the non-walkable areas with black. You might need to keep the region open in SE with floor drawing on for reference.

·         I use a 1-pixel-wide white pencil to border dungeons and a 3-pixel-wide white paintbrush for caves. For outdoor areas, I use a 5- to 9-pixel-wide black paintbrush to blot out the non-walkable areas of outdoor regions, then use a -3-pixel-wide white neon glow for the border.

·         Make sure to add all borders and blots on new layers. I'm a photoshop noob, so there might be way easier ways to do this, but this worked ok.

·         Now, extend the alpha mask to cover the non-walkable areas. I made a macro that does the following:

·         Use the 'Select color range' option to select the black you added on the border layer.

·         Switch to the 'Channel' view and select the alpha channel.

·         Use the paint bucket to fill in the selected area with black in the alpha channel. Now it won't show up on the compass map.

·         Save and exit photoshop, then convert your edited .psds back to .raw format. Now the radars that appear in the game will have nice borders.

·         Note: At this point, you don't really need the .psds any more, but I checked them into our file manager anyway. If, at any point in the future, the nodes in the region get changed (and you know they will), it's very easy to fix up the radars if you still have your layered .psd. Here's how:

·         Rename the existing .psds for the changed fade groups. (I usually just stick an '_old' on the end of the filename).

·         Regen the region's radars.

·         Revert the .raws and .psds for the fade groups that did not change.

·         Convert the changed .raws to psd form.

·         Open the new psd and the old one in photoshop

·         Copy your blot and outline layers onto the new psd.

·         Alpha out the black, then save and convert back to raw.

·         Make sure to test before checking in. After testing, I delete the old psd, since the new one should have all the layers you might need in the future.

Getting rid of radar bitmaps that we don't want to draw is a bit easier:

·         First, make a list of all the fade groups that you don't want to draw. Here's our list:

1,1,1
1,1,2
1,1,3
1,1,4
1,1,5
1,1,6
1,1,7
1,1,8

·         Open radar.gas. For each fade group in your list, delete its entire block and any sub-blocks of other bitmap blocks that reference it. So, to get rid of 1,1,1, we would delete its block:

    [t:radar_tex,n:a2_03_01x_sa_amrendun2_1_1_1_x0_z0]

    {

      i height = 32;

      i level = 1;

      i object = 1;

      x region = 0x00000FD1;

      i section = 1;

      f sort = 0.100000;

      i width = 16;

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_x_x0_z0;

          f u = 35.561871;

          f v = -0.000003;

        }

        [stitch_helper]

        {

        }

    }

And the sub-block of fade group 1,1,-1 that references it:

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_1_x0_z0;

          f u = -35.561871;

          f v = 0.000003;

        }

Once we have eliminated all eight extraneous fade groups, we will be left with a very short radar.gas that looks like this:

[radar_info]

{

  f meters_per_pixel = 0.703000;

    [t:radar_tex,n:a2_03_01x_sa_amrendun2_1_1_x_x0_z0]

    {

      i height = 128;

      i level = 1;

      i object = -1;

      x region = 0x00000FD1;

      i section = 1;

      f sort = 0.900000;

      i width = 128;

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_2_x_x0_z0;

          f u = -62.588898;

          f v = 0.000008;

        }

        [stitch_helper]

        {

            5daf1dcc_10 = 0.000000,0.000000;

        }

    }

    [t:radar_tex,n:a2_03_01x_sa_amrendun2_1_2_x_x0_z0]

    {

      i height = 64;

      i level = 2;

      i object = -1;

      x region = 0x00000FD1;

      i section = 1;

      f sort = 1.000000;

      i width = 64;

        [t:local,n:adjacent_texture*]

        {

            tex = a2_03_01x_sa_amrendun2_1_1_x_x0_z0;

          f u = 62.588898;

          f v = -0.000008;

        }

        [stitch_helper]

        {

        }

    }

}

Only the fade groups that the player can walk on are drawn, and the file is self-consistant. As far as the code is concerned, the other radar bitmaps don't even exist. If the player is somehow able to walk on a fade group whose radar bitmap was eliminated in this way, the game will throw an error. This occasionally comes up in testing when a tester ctrl-zs to an area that the player cannot get to, and sometimes it reveals an area in which I deleted a bit over-zealously.

Note that whenever you regenerate the radars for the region (to add radar icons, for example), you'll have to redo both these steps. Fortunately, this is very easy: to re-border the radar bitmaps, just revert them in your file manager (be sure not to revert radar.gas itself). Now diff radar.gas against the depot version, and copy over the blank spaces where fade group blocks were deleted.

 

Stitching the Radars


Now we just need to stitch our new radars to those of the rest of the map. Make sure to check out radar_stitch.gas from the map's radar folder. Also make sure that stich_index.gas was up to date before you generated your radars (i.e. if you just built the region, you'll need to stitch it, then generate the radars before you can stitch the radars).

With your region open, click on 'Generate radar bitmaps' in the File menu in SE and click 'Stitch Region Radars Together'.


It takes a minute or so. When it's done, make sure to save. You should now be able to play through into your region while the radars behave like they should.

 

Troubleshooting

·         If your radars flip around when entering the region, the north vector might be off. Make sure that the north vectors match across region boundaries, then regenerate the radars. If that doesn't work, and nodework was done recently, the regions might need to be re-stitched. Try regenerating the stitch index, then regenning and re-stitching the radars. Rememeber that radar.gas takes its stitching info from stitch_index.gas, and radar_stitch.gas takes it from radar.gas. If neither of those work, there might be an issue with the radar code itself. If that's the case, James will be very sad.

·         If your radars don't look like the region (if they look like a bunch of little colored dots, for example) the radars need to be regenerated.

 

Tips and Tricks

·         For regions with multiple radars in the same fade group (most natural regions will have at least 4 for their base fade group), make a new PSD with dimensions of 256*x by 256*z pixels, where x is the number of bitmaps across and z is the number of bitmaps down. Then copy all the bitmaps onto the new PSD and border the radars on that. After you're all done, make a grid with 256 pixels between each gridline, turn on snap to grid, and use a selection box to select the border layer for each bitmap. Then copy and paste each square onto the bitmap. This is hard to explain, but hopefully is intuitive; look at any large outdoor region in the ds2_world map to see an example.

·         It's pretty hard to see dungeon doors on the radars, so I just count the pixels. Doors are pretty much always 5 pixels wide, so I leave a 5 pixel blank spot in my white border for doors. It's usually pretty easy to center them so that the doors match up between different rooms.

·         For dungeon secret doors, I leave a door-sized hole in the border of the secret room, but border the wall of the next room that the secret door connects to. That way the player can't tell there's a secret door before they open it, but once it's open there's some indication of where the door is on the radar (since the white border is thinner there).

·         Some texture sets don't have much contrast between the walls and floor (the mines texture set has almost none). When I can't see the walls, I generate the region's radars with flooring turned on, draw my border layer, then regen radars and paste the border layer onto the new radar bitmaps.