v.absmin and v.absmax

[BAStumm]

So PM you and I had this convo on botmans forum:


--------------------------------------------------
03/27/03 at 20:06:59 Reply by: PM (pm@racc-ai.com)
--------------------------------------------------
Normal, I'd say. :)
The BSP slicer aligns its slices taking the whole map bounding box as a reference. Thus, the center of the bitmap
will always correspond to the center of the map. But not to the center of the world !
Many maps are not centred around (0,0,0) actually.
--------------------------------------------------
03/27/03 at 21:03:35 Reply by: BAStumm (bs@bs-linux.com)
--------------------------------------------------
right so how might I attempt to guess at where the center is or what kind of offset to use or whatever. Must be a way, valve uses
an overlay (bmp file) in game for that one overview spectator mode.
--------------------------------------------------
03/27/03 at 21:47:09 Reply by: PM (pm@racc-ai.com)
--------------------------------------------------
Of course, all you have to do is to substract the coordinates of the center of the map's bounding box to the coordinates of your player.
The map (worldspawn) is model #0 in the BSP data, and entity #0 in the game.
v_relative_coords = v_absolute_coords - (INDEXENT (0)->v.absmin + INDEXENT (0)->v.absmax) / 2;
you get the idea... :)


But I am getting -1 for INDEXENT(0)->v.absmin.x and +1 for v.absmax.x and same for the Y versions of these values... Any ideas?

[Pierre-Marie Baty]

I was wrong in this discussion, worldspawn is not bindable as an entity. You can't do INDEXENT (0), it will give you an invalid edict pointer.

In order to know the map's bounding box, you have to read the BSP file and extract it yourself. It's simple :

// load the bsp file and get its actual size (can't fail to do this, the map already booted)
sprintf (bsp_file_path, "maps/%s.bsp", STRING (gpGlobals->mapname)); // build BSP file path
mfile = (char *) LOAD_FILE_FOR_ME (bsp_file_path, &bsp_file_size); // load bsp file

// read the MODELS lump of the BSP file
memcpy (bsp_file.dmodels, mfile + ((dheader_t *) mfile)->lumps[LUMP_MODELS].fileofs, ((dheader_t *) mfile)->lumps[LUMP_MODELS].filelen);

FREE_FILE (mfile); // everything is loaded, free the BSP file

// get access to the world's bounding box
v_worldmins = bsp_file.dmodels[0].mins;
v_worldmaxs = bsp_file.dmodels[0].maxs;


Look in the racc.h file of my bot source code for the right #define's and struct stuff.

[BAStumm]

thanks! :)

[BAStumm]

Looks correct to me.

From your code in my mm plugin

[root@Dragon root]# hlcmd -g dod -e 27016 watch |grep ABSMIN
** ABSMIN-X: -1152.000000 ABSMAX-X:2000.000000 **
** ABSMIN-Y: -2432.000000 ABSMAX-Y:2752.000000 **


From overviews/dod_avalanche.txt



// overview description file for dod_avalanche.bsp
global
{
ZOOM 1.58
ORIGIN 424 160 -609
ROTATED 0
}
layer
{
IMAGE "overviews/dod_avalanche.bmp"
HEIGHT -609
}



Math seems right to me...

Still need to use this new data to pre-offset the output coords but it fixes a big problem I've had with the code for my hlwebtv and phpua projects.

oh and I had messaged you once about this PM, but in the end I finally broke down and forced myself to figure out metamod coding. It was a lot easier than I thought. My botman code dropped right in after I figured out the sudtle differences and what not.