[hlcoders] Zoner's Half Life Tools license
Hello all, I was trying to find out how the source to ZHLT is licensed, but I don't see any thing in the source distribution that says anything about it. Basically, I've made some modifications and wanted to know what my rights responsibilities are in redistributing the source and/or binaries. Also, I wanted to know whether there was any restriction on the use of the source - for example, could I use parts of it to create a different tool (for processing a bsp file) and if so, could I release the source code? So, does anyone know how it's licensed? Or at least who owns the rights to it? (Valve? Gearbox?) Thanks in advance. Entropy ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
botman wrote: Only problem there is no corresponding function on the server. (Is there?) Jim pfnGetModelPtr(edict_t *pEdict) Jeffrey botman Broome That only seems to work for studio models. I get a cache failure when I use that function for a BSP model. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Rescaling clipping problems (again!)
You may have to wind up loading the BSP and brush geometry yourself and extracting the information you need from there. Not a good solution I know because it can take up quite a bit of memory. Perhaps if you only load the brush model geometry and not load the world BSP geometry, it won't take quite so much memory. I think I'll stick with caching the initial value of pmove-physents[0].model and assuming it's the address of the engine's models array. It's working so far. :) Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Rescaling clipping problems (again!)
I believe I have found the source of the clipping errors after rescaling. If you look at pmove-visents[x].model-hulls for the world and BSP models, you'll see that the clip_mins and clip_maxs for the hulls are the original hull sizes. If that part of the engine hasn't changed from the Quake I source, this would cause the offset returned from SV_HullForEntity to be wrong by the difference of the player's mins - clip_mins, which is consistent with what I had previously seen and tried to compensate for by modifying ZHLT. (see http://www.mail-archive.com/a href=/faq.html#spam[EMAIL PROTECTED]/a/msg04565.html and http://www.mail-archive.com/a href=/faq.html#spam[EMAIL PROTECTED]/a/msg04622.html) It looks like the clip_mins and clip_maxs are set in the engine (in the Quake I source, it's hardcoded in Mod_LoadClipnodes). At any rate, setting BSP models' clip_mins and clip_maxs to the correct hull sizes resulted in correct collisions. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
jc wrote: i tried the compensation thing and it didnt work that well. a weapon/attack that used UTIL_TraceHull suddenly f*cked up. it worked before the GetHull... fix, with the GetHull fix and the zhlt hack the players get stuck in the walls. so i've just stopped with the pre-GetHull fix code for now. If you change the clip_mins / clip_maxs, you don't need the modifications to ZHLT, you just need a hullfile. I haven't noticed any problems with getting stuck since changing this, so if you decide to try it I'd be interested in hearing if you have any problems. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
jc wrote:
where abouts did you set the values (remembering that im not much more
than a dumb ass n00b)
There are two ways that I know of, both in pm_shared, since I can't see
any other way to get a pointer to the engine's models array (Botman - I
tried GetModelPointer but it fails for brush models :) )
First, you can loop through all of the physents every frame and check
whether it's a BSP model and if so, set hulls.clip_mins and clip_maxs,like
so:
// My hullfile looks like this:
8 8 18
16 16 16
8 8 9
// I have my hull mins and maxs stored in global arrays like this:
#define SCALE_FACTOR 4.0
vec3_t VEC_HULL_MIN = { -16 / SCALE_FACTOR, -16 / SCALE_FACTOR, -36 /
SCALE_FACTOR };
vec3_t VEC_HULL_MAX = { 16 / SCALE_FACTOR, 16 / SCALE_FACTOR, 36 /
SCALE_FACTOR };
vec3_t VEC_DUCK_HULL_MIN = { -16 / SCALE_FACTOR, -16 / SCALE_FACTOR, -18 /
SCALE_FACTOR };
vec3_t VEC_DUCK_HULL_MAX = { 16 / SCALE_FACTOR, 16 / SCALE_FACTOR, 18 /
SCALE_FACTOR };
vec3_t VEC_LARGE_HULL_MIN = { -32 / SCALE_FACTOR, -32 / SCALE_FACTOR, -32
/ SCALE_FACTOR };
vec3_t VEC_LARGE_HULL_MAX = { 32 / SCALE_FACTOR, 32 / SCALE_FACTOR, 32 /
SCALE_FACTOR };
// In PM_Move before the call to PM_PlayerMove
for (i=0; i pmove-numphysents; i++)
{
if (pmove-physent[i].model) // physent::model is NULL if it's not a
BSP model
{
hull_t * hulls = pmove-physents[i].model-hulls;
// Note the hulls are in different order than usual
VectorCopy(VEC_HULL_MIN, hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN, hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX, hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN, hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX, hulls[2].clip_maxs);
}
}
The other way (which is how I'm currently doing it... use at your own
risk), is to make a few assumptions (which as far as I can tell are
valid):
1. The values for clip_mins and clip_maxs are loaded once at map load time
2. The address pointed to by pmove-physent[0].model when the FIRST map
is loaded is the first element in the engine's models array and this
address does not change when a new map is loaded.
3. The order of models in the models array does not change during a map.
4. The models array has 512 elements. This one I have no way to test;
the 512 was posted previously on this list. Quake I had 256.
I added the following to pm_shared.c:
model_t * g_modelarray = NULL;
int g_model_hulls_fixed = 0;
void PM_FixModelHulls()
{
int model;
// Get pointer to the world model, which is the first element in
// the models array when the first map is loaded
if (!g_modelarray)
{
g_modelarray = pmove-physents[0].model;
}
// Special case for the world model, since its name doesn't start with '*'
// It is only the first element of the models array for the first map.
// It is always pmove-physent[0], though
hull_t * hulls = pmove-physents[0].model-hulls;
VectorCopy(VEC_HULL_MIN, hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN, hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX, hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN, hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX, hulls[2].clip_maxs);
// All the BSP models other than the world have names in the format *%d
// Max # of models (of all types) assumed to be 512
for (model = 0; model 512; model++)
{
if (g_modelarray[model].name[0] == '*')
{
VectorCopy(VEC_HULL_MIN, g_modelarray[model].hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, g_modelarray[model].hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN,
g_modelarray[model].hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX,
g_modelarray[model].hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN,
g_modelarray[model].hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX,
g_modelarray[model].hulls[2].clip_maxs);
}
}
}
// In PM_Move, before the call to PM_PlayerMove:
if (!g_model_hulls_fixed)
{
PM_FixModelHulls();
g_model_hulls_fixed = 1;
}
// In world.cpp:
extern C int g_model_hulls_fixed;
// In CWorld::Spawn:
g_model_hulls_fixed = 0; // New map - make sure all the models get
fixed again
// In hud_msg.cpp:
extern C int g_model_hulls_fixed;
// In CHud::MsgFunc_ResetHUD:
g_model_hulls_fixed = 0;
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
Michael A. Hobson wrote: Try using the Studio Model Renderer API defined in cl_dll/r_studioint.h iEngineStudio.GetModelByIndex(1) is the world model corresponding to the WorldSpawn entity and so forth. The return value is a pointer to struct model_s (defined in common/com_model.h) Only problem there is no corresponding function on the server. (Is there?) Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Traceline going through people
Sorry for starting a new thread. Ye olde e-mail client is behaving erratically tonight. Reply follows. I have come across a very strange bug in my mod. If a Player is ducking, and you try to shoot him in the head or neck, the bullet/trace simply goes right through, with no hit registered. Anywhere else in the body the trace works correctly, but not the head or neck. I checked the hitboxes using r_drawentities 4, and there is a head/neck hitbox, so that is not the problem. Any ideas as to what could be causing this? The head of the model extends beyond the bounding box when ducked. You can see this if you uncomment the call to PM_ShowClipbox in PM_PlayerMove. If my understanding of the engine's collision detection is correct, the hitboxes on the model will never get checked if they are outside the bounding box. I *think* using SetObjectCollisionBox to increase the size of the box when ducked might solve the problem. Did you apply the hitbox patch from Robin Walker's post (from back in December of last year)?... I don't think that will help. BTW, did this fix get merged into SDK 2.3? I never downloaded 2.3 so I couldn't check myself. No, it didn't. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Macros are evil (or is it evalV?)
Came across an interesting little problem I thought others might find
amusing:
In a new C++ module for the server dll, I have the following:
#include extdll.h
.
.
.
extern C {
#include pm_debug.h
}
pm_debug.h contains the following prototype:
void PM_DrawRectangle(vec3_t tl, vec3_t bl, vec3_t tr,
vec3_t br, int pcolor, float life);
Everything compiled without a peep from the compiler, but the program
crashed when I called PM_DrawRectangle from the C++ module. Tracing
through in the debugger, I noticed that the copy constructor for class
Vector was being called during the call to PM_DrawRectangle! The
preprocessor replaced all the vec3_ts with Vector, because extdll.h
#defines vec3_t as Vector. The linker didn't complain, either, which I
can't say I understand, since in the preprocessor output for pm_debug.c the
vec3_t's are unchanged.
Jim
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Models and memory management
botman wrote: index=1). Try calling pfnGetModelPtr() with entity index 0 or 1 Interesting... OK, I'll give that a whirl. Thanks again. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Models and memory management
Does the model data for monsters remain in memory for the duration of a map, or is it dynamically loaded/unloaded? I'm guessing that the player model remains in memory. What I really need to know is, if I use g_engfuncs.pfnGetModelPointer, will that pointer remain valid or do I need to call it each time I need the data? I'm trying to decide whether to use the engine's copy of the model or just load it myself - it just seems a waste of memory to have the same thing loaded twice. Also, what is the purpose and range of values of the usehunk parameter in COM_LoadFile? Everywhere I see it in the SDK it's 5. Thanks in advance, Jim Hunter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Models and memory management
I have added the code for usehunk==5 :) Note the comment ;)
snip
else if (usehunk == 5)
{
buf = (byte *)Mem_Malloc(len + 1); // YWB: FIXME, this is evil. }
Thanks, botman and Alfred!
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Models and memory management
Ken Birdwell wrote: It rarely happens, but you can't count on the pointer being valid between subsequent calls to g_engfuncs.pfnGetModelPointer(), since the engine can move or throw away model data if something else needs the memory. In theory, each call to g_engfuncs.pfnGetModelPointer() could force a cache flush and any pointers it returned earlier will no longer be valid. Thanks for the clarification. I also recommend against loading a private copy of the model Any particular reason, other than not wasting RAM? At this point, I don't really plan to, just curious. I'm trying to get the model data from within the shared physics code, which is a bit problematic on the server, since it appears pmove-physent[i].studiomodel is always NULL. So I see two possible solutions: load the model file myself, or link to a C++ module with functions to get the data from the engine and process it. (I'm currently planning on using the latter). P.S. While we're at it, is there any way I can get a pointer to the engine's copy of the bsp file? Thanks again. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
