Re: [hlcoders] ClipBox/Bounding Box Issue
I can't see anything I have done to rendering the model client side or moving it around weirdly in the pm_shared files. I haven't implemented any part of the 9wb interface or functions server side or client side. If the client was rendering the model wrongly, wouldn't the server still detect a hit and fire the events? I'll try setting the gaitsequence to 0 to double check the client and server match up, but I don't think thats the problem. Ben Jorge Rodriguez wrote: This is just a shot in the dark, but could the problem possibly be that you are making modifications to the position of display of the model on the client which are not reflected on the server? Have you messed at all with the extended server blending interface? From what it seems, the way the client displays the models is not representative of the way the server has them. (Or maybe I just read this wrong.) On Sat, Sep 04, 2004 at 12:02:50PM +0100, Ben Banfield wrote: I wonder if anyone can help me. Recently I have been trying to fix an issue with the crouched hitboxes. Specifically the head hitbox. It can't be hit with guns or melee weapons. I know this isn't the hitboxes fault, they are just the symptom. The issue lies with the clipbox or the bounding box. My understanding is that the clipbox ( is this the same as the hull? ) is used for world collisions, and the bounding box is used for when determining whether a traceline has intersected with our model. If the bounding box isn't hit then hitboxes aren't triggered. If the bounding box extends outside the clipbox then will the regions outside the clipbox still be triggered? I've been searching the wavelength forums and hlcoders archives over the past few days trying to find a solution for this. I've found Robin Walkers patch for GetHullBounds, didn't work. I've found suggestions involving SetObjectCollisionBox which haven't worked. Likewise for UTIL_SetSize. I've tried both of omega's rescaling tuts. PM_ShowClipbox shows the correct size client side and server side. The models even work perfectly in hldm, where I can shoot the heads no end while the victim is crouched. Last night I tried setting the clipbox/hull/bounding box/everything i could find for crouching to be 100 units tall and still no change bar not being able to jump on top of a crouched player. This leads me to believe that I'm only changing the clipbox atm, so I'm wondering where I am going wrong. Anyone have any ideas? Ben Banfield The Battle Grounds Lead Coder ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] ClipBox/Bounding Box Issue
I wonder if anyone can help me. Recently I have been trying to fix an issue with the crouched hitboxes. Specifically the head hitbox. It can't be hit with guns or melee weapons. I know this isn't the hitboxes fault, they are just the symptom. The issue lies with the clipbox or the bounding box. My understanding is that the clipbox ( is this the same as the hull? ) is used for world collisions, and the bounding box is used for when determining whether a traceline has intersected with our model. If the bounding box isn't hit then hitboxes aren't triggered. If the bounding box extends outside the clipbox then will the regions outside the clipbox still be triggered? I've been searching the wavelength forums and hlcoders archives over the past few days trying to find a solution for this. I've found Robin Walkers patch for GetHullBounds, didn't work. I've found suggestions involving SetObjectCollisionBox which haven't worked. Likewise for UTIL_SetSize. I've tried both of omega's rescaling tuts. PM_ShowClipbox shows the correct size client side and server side. The models even work perfectly in hldm, where I can shoot the heads no end while the victim is crouched. Last night I tried setting the clipbox/hull/bounding box/everything i could find for crouching to be 100 units tall and still no change bar not being able to jump on top of a crouched player. This leads me to believe that I'm only changing the clipbox atm, so I'm wondering where I am going wrong. Anyone have any ideas? Ben Banfield The Battle Grounds Lead Coder ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Player-specific Hitbox Bug? (Help, Alfred? Help, valve? Reproduction steps included.)
How many other game companies would continue to patch their game and provide updates 5-6 years after release? On Mon, 9 Aug 2004 17:22:52 +0200 (CEST), Thomas Ackermann [EMAIL PROTECTED] wrote: Am Di 27.07.2004 17:20, Jeffrey botman Broome [EMAIL PROTECTED] schrieb: [BIGGEST EDIT EVER] Valve has fixed the bug. It should be updated to Steam sometime soon, according to the email. GG on this one, everyone. Yay! Go Valve! Anybody who says Valve doesn't care about or support the Half-Life community can go shove a snark up their ass! :) To fix a sold product is not sooo much of support. If they would not fix bugs, they would soon not sell things. They forced STEAM upon us - which is quite NOT support :-( About fixes: What about starting a server with 21 Slots, reserving one with AMX, so that only 20 players can connect. Will the bug still arise?!? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Ben Banfield The Battle Grounds CoLeader, Lead Coder and Admin ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Weird missing dll error
Not quite, its the runtime for VS .Net ( the original version ) compiled files. Looks like one of the dlls you're using was compiled with VS .Net or one of the ms command line tool packs. The simple fix is to put msvcr70.dll and msvcp70.dll in the same dir as the hl executable. Ben Karl XP-Cagey Patrick wrote: MSVCR70.dll is a .Net runtime... are you linking to any 3rd party dlls? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 04, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Weird missing dll error Almost at random times during a game this pops up and the server crashes. But its fairly rare. The dynamic link library MSVCR70.dll could not be found in the specified path then it goes on to point to a number of locations including my steam/... half-life/ dir What the heck is that all about? I'm using VS 6.0 with standard compile options that came with the sdk. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] UserMsg 57..... ?
There is an interesting thread on thewavelength regarding an error like this ( usermsg 67 ). http://forums.thewavelength.net/index.php?showtopic=10455hl=usermsgst=15 It seems to suggest that it isn't about us sending a msg which got regged with number 57, as that gives a different error (UserMsg: No pfn craptest 95). My own logging of messages concurs with that, as i've never managed to catch a msg sending 57 as the msg id (this was using a technique botman mentioned back last october). This morning I tried to reproduce the bug along mazor's line of thinking (overflowing), by sending a mass of cvars and messages per frame, but all I got was a lot of lag and compressing split packets. Bar a router, which at the point in time I don't particually want to accept, I think we need to find a method for reproducing this. Ben Adam amckern Mckern wrote: I think that has been talked about, but mayb not looked into Quote from lower down On Behalf Of Alfred Reynolds There is no usermsg 57, the engine defined ones stop at 56 (and mod created ones start at 64). Sounds like you are corrupting your network steam (by mismatching what the server sends and how the client parses it typically). - Alfred --- [EMAIL PROTECTED] wrote: There seems to be quite a lot of different reasons for this occuring with it happpening in many mods to everyone on the server at the same time, and also to individuals with weird routers. But why is it always UserMsg 57? I think the only person who can answer this is someone at valve by looking up their source code. With it being a problem in many mods it would be time well spent. If its happening for different reasons, then perhaps some more specific error messages might be useful too. Peter. = hl2hosting.com AIM SN - amaperman __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] UserMsg 57..... ?
Good point and I would agree with you if it was just one mod or even two. But we're talking about 50% of the 10 top 3rd party mods on steam (I just searched and saw the specialists have it as well). I also can't find an occurrence of usermsg 57 before the steam time period. We could be collectively be doing something wrong, but at the moment its unreproducible for most users, its cryptic and doesn't give us any more info to try and track it down. We're all stabbing the dark here as can be seen from the wide variety of possible causes/solutions on the subject. Could it be also possible that a lack of valve features could be causing it, e.g. not having vac causes this in certain circumstances. Again this is only conjecture, but having been trying to pin this down since the first report of this in November for me is trying. Ben Jeffrey botman Broome wrote: tei wrote: Humm... call me naive but... I suggest to create a dummy usermsg 57 that catch and try to fix network stream corruptions (TCP packets assembling errors?) A aproach can be to ignore the full frame (posible?).. well.. that its better than crash or unconnect As Alfred stated earlier, network messages below 64 are created, sent and intercepted by the engine (server side and client side). The MOD code has no access to these network message (it can't parse them, it can't intercept them, and it can't change them). If there is a generic engine problem or a generic networking problem (routers, firewalls, etc.) you would see lots of reports of this error in Valve MODs (deathmatch, TFC, CS, and DoD). If there aren't significant reports of this error occuring in Valve MODs, but there are significant reports of this error occuring in non-Valve MODs, then I would tend to believe that the non-Valve MOD code is at fault (and not the engine or the network). I realize this doesn't help track down what the problem is, but it would help to identify who or what is at fault. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] UserMsg 57..... ?
Sorry for the double post but I've come off like I'm flaming people and valve. Thats not what I've been trying to do. I'm simply a bit exasperated and am just looking for more information to hunt this down or for this bug to not cause half the clients on the server to quit. Sorry Ben Ben Banfield wrote: Good point and I would agree with you if it was just one mod or even two. But we're talking about 50% of the 10 top 3rd party mods on steam (I just searched and saw the specialists have it as well). I also can't find an occurrence of usermsg 57 before the steam time period. We could be collectively be doing something wrong, but at the moment its unreproducible for most users, its cryptic and doesn't give us any more info to try and track it down. We're all stabbing the dark here as can be seen from the wide variety of possible causes/solutions on the subject. Could it be also possible that a lack of valve features could be causing it, e.g. not having vac causes this in certain circumstances. Again this is only conjecture, but having been trying to pin this down since the first report of this in November for me is trying. Ben Jeffrey botman Broome wrote: tei wrote: Humm... call me naive but... I suggest to create a dummy usermsg 57 that catch and try to fix network stream corruptions (TCP packets assembling errors?) A aproach can be to ignore the full frame (posible?).. well.. that its better than crash or unconnect As Alfred stated earlier, network messages below 64 are created, sent and intercepted by the engine (server side and client side). The MOD code has no access to these network message (it can't parse them, it can't intercept them, and it can't change them). If there is a generic engine problem or a generic networking problem (routers, firewalls, etc.) you would see lots of reports of this error in Valve MODs (deathmatch, TFC, CS, and DoD). If there aren't significant reports of this error occuring in Valve MODs, but there are significant reports of this error occuring in non-Valve MODs, then I would tend to believe that the non-Valve MOD code is at fault (and not the engine or the network). I realize this doesn't help track down what the problem is, but it would help to identify who or what is at fault. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] UserMsg 57..... ?
I have this behaviour. I have never seen it drop everyone. This led me into thinking it could be a pvs/pas message for a while or broadcast as that goes to unreliable iirc. 50% was me being lazy writing. However, iirc ns drops all however i'm not sure. Cale Dunlap wrote: When it happens in FA its completely random, it does not discriminate between teams and such, and no its not always 50% of the players, sometimes only 3 to 5 on a 28 player server will drop, sometimes 20 will drop. They all drop at the same time too. -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey botman Broome Sent: Wednesday, May 26, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] UserMsg 57. ? Ben Banfield wrote: Sorry for the double post but I've come off like I'm flaming people and valve. Thats not what I've been trying to do. I'm simply a bit exasperated and am just looking for more information to hunt this down or for this bug to not cause half the clients on the server to quit. Hmmm, that might be useful (half the clients on the server quit). Does this happen to several clients at the same time? I know it's probably hard to tell, but do people on the server see 50% of the players suddenly go away? If so, then that might help to track it down. If it's a teamplay MOD are all of those players on the same team? Adding some stats tracking debug code to the server could help to identify when this happens. Perhaps you can log (in memory) what's currently happening for each player (in a circular buffer in memory) and when you see a large number of players suddenly disappear from the server, dump this log of data to a text file. Then you can go back and look at what network messages had been recently sent or what type of activity was occuring when a large number of players suddenly disappeared. P.S. I don't think it sounded like you were flaming anyone. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] UserMsg 57..... ?
Its not just FA and NS that have had this. My mod, BG has had it (and still does) and i remember Kuja saying DPB had it too. Is it possible this is a steam or sdk bug as the chance of 4 wildly different mods causing the same error are extremely low imho. If we we're mismatching wouldn't we be having different usermsg number's each time ( or am I misunderstanding something here ). I'd love to see a resolution to this as well. Thanks Ben Cale Dunlap wrote: Oh. Crap. Ok, I'll check out all the messages and make sure they're parsed correctly. Thanks Alfred! -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: Monday, May 24, 2004 12:43 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] UserMsg 57. ? There is no usermsg 57, the engine defined ones stop at 56 (and mod created ones start at 64). Sounds like you are corrupting your network steam (by mismatching what the server sends and how the client parses it typically). - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cale Dunlap Sent: Sunday, May 23, 2004 5:26 PM To: [EMAIL PROTECTED] Subject: [hlcoders] UserMsg 57. ? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] What is UserMsg #57. I've determined it to be within the engine.. Its causing crashes in FA right now and I'm having a difficult time figuring out why. If I can find out what the message contains I can probably figure out where its being sent from. The error steam has been giving is UserMsg 57 not present on client. Valve guys help out pzl? *puppy dog face* -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bayonet Kill Sprite Logging
I do my bayonet kill sprite by changing the classname before and after a attack using the bayonet. Tony omega Sergi wrote: I do it like this in household death to make the thrown fork use the stabbing forks death message/icon (you can use the same idea to accomplish yours ;)) const char *forks = fork; if (strstr(killer_weapon_name, forks)) killer_weapon_name = forks; //omega; override (weapon name is weapon_forks, but the actual thrown fork is proj_fork, so i wan't to make it so if you stab, it does the same as if you throw a fork and kill.) -omega -- Blackened Interactive - http://www.blackened-interactive.com FLF:Defiance - http://www.frontline2.com Wavelength - http://www.thewavelength.net Cale 'Mazor' Dunlap wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Firearms has a bayonet attached to the AK47 as some of you might know. I'm trying to get the correct kill sprite to appear when killed via the bayonet. When you kill someone currently, it just uses the AK47 edict. is there a way to tell the PlayerKilled functions that the player was killed with a bayonet? I tried adding a new entity with the classname weapon_bayonet so the kill sprite appears, but it crashes. I know why it crashes, but I'm sure there's a better way to do it than creating a whole new entity. any ideas? Cale 'Mazor' Dunlap Programmer Firearms Half-Life http://www.firearmsmod.com/ -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Host_Error under Steam
Alright thanks. My logging attempts have got me nowhere so far bar a 127meg log file with no hits for msg57. Gonna have to have a few releases with this logging in place by the looks of it :( This request as to Valve : Would it possible for this error not to cause the client to be dropped unless they were running with -dev or a high developer cvar setting. This would allow us to continue tracking down this bug without whole chunks of one team being dropped at random while playing. Ben The Battle Grounds Lead Programmer Charlie Cleveland wrote: We never did figure out why this error was happening, but I did manage to fix it. Tom is right, it was happening when a player was kicked off the server. The way I fixed it was by removing a UTIL_SayToAll (or whatever it's called), that was telling everyone that the player was being booted off the server. That seemed to fix it, though I have no idea why. That was quite awhile ago, and for some unknown reason, this error has seemed to come back again in a recent playtest build, so I have no idea what's happening. -Charlie -- Charlie Cleveland Game programmer and designer http://www.natural-selection.org http://overmind.org I'm one of NS playtesters, and if Charlie doesn't get back to you... I do believe it was part of his custom authentication code for handling the playtesting that was doing it. If a player who wasn't authenticated to play joined a server, he could get so far as the readyroom fine. But if he joined the team, the authentication would kick him. If I recall correctly, it was a bug in the authentication process where an unauthorized player joining would kick everyone. Tom Grim aka Elven Thief --- Ben Banfield [EMAIL PROTECTED] wrote: I have just encountered this bug in the latest version of bg and am about to start debugging using the method botman prescribed in this thread. However I'm just wondering what you're findings were for ns on this bug. Was it a special ns message? Is there anything I can do to help narrow this down? And help is appreciated as I fear this could be a long sunday afternoon otherwise :/ Thanks Ben The Battle Grounds Lead Programmer Charlie Cleveland wrote: We're running some NS playtests under Steam, and one of the big problems were having is something called a Host_Error. Suddenly, everyone on the server will get kicked off the server, and will be back in their Steam UI. Written to everyone's console is this ominous error message: Host_Error: UserMsg: Not Present on Client 57 Does anyone have any idea on what might be causing this, or how to fix it? -Charlie ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Host_Error under Steam
Jeffrey botman Broome wrote: I don't think you'll ever see any pfnMessageBegin() calls with messages IDs below 64. The engine uses IDs 1-63 for internal stuff to the client. The only messages you will see going from the MOD code to the engine (via pfnMessageBegin) will be the ones the MOD registered (via REG_USER_MSG) and the first one the MOD registers will be 64 and go up from there. You get some under 64 which can be sent by the mod. 51 is the director message and 23 is the temp entity one. Nothing for 57 though. Back in the good ol' days you could run your MOD on a LAN and put a network sniffer inline capturing the network packets and look at those un-encrypted (since WON didn't authenticate and give you a encryption hash), but nowadays the LAN packets are encryped and you won't be able to decipher anything from them either. Your best bet is to start commenting out HUGH chunks of code and eliminating features one-by-one until the problem goes away and then you know what area to concentrate your investigations in. Other than that, your up the proverbial creek without a paddle. If I'm not actually sending a message with id 57, then what is going on. I find it pretty strange to think that two widly different mods have come up with the same error when in steam. It also begs the question why haven't we seen this in won. I don't know about NS, but I've never encountered this in won. I guess I better start paddling then. -- Jeffrey botman Broome Ben The Battle Grounds Lead Programmer. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Host_Error under Steam
I have just encountered this bug in the latest version of bg and am about to start debugging using the method botman prescribed in this thread. However I'm just wondering what you're findings were for ns on this bug. Was it a special ns message? Is there anything I can do to help narrow this down? And help is appreciated as I fear this could be a long sunday afternoon otherwise :/ Thanks Ben The Battle Grounds Lead Programmer Charlie Cleveland wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] We're running some NS playtests under Steam, and one of the big problems were having is something called a Host_Error. Suddenly, everyone on the server will get kicked off the server, and will be back in their Steam UI. Written to everyone's console is this ominous error message: Host_Error: UserMsg: Not Present on Client 57 Does anyone have any idea on what might be causing this, or how to fix it? -Charlie -- Charlie Cleveland Game programmer and designer http://www.natural-selection.org http://overmind.org -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] [Fwd: [hlds_apps] Engine interface changes]
I am assuming we don't update our mods with this if we want to retain
won compatibility for the moment.
Ben
Alfred Reynolds wrote:
This change is not needed for mods, I didn't want to confuse people with
what was required. It will be okay to add this to your mod however as
long as you release it after our update.
Yes, there will be a steam update that contains an updated client (and
engine) that will occur when this change is made live.
- Alfred
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeffrey botman Broome
Sent: Monday, November 10, 2003 7:12 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] [Fwd: [hlds_apps] Engine interface changes]
Any reason this wasn't sent to hlcoders?
Alfred, will this only effect dedicated servers or will there be a
client update coming in the near future?
Original Message
Subject: [hlds_apps] Engine interface changes
Date: Mon, 10 Nov 2003 13:49:44 -0800
From: Alfred Reynolds [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
We will be releasing a new engine soon (within the next couple of days
we expect), we have added some new functions to the engine function
structure (from eiface.h). If you are responsible for a third party
program such as MetaMod you will need to update this engine structure
and recompile your program. Not updating will cause a crash when your
users try to use the new engine with the old engine interface
structure.
- Alfred
// Engine hands this to DLLs for functionality callbacks
typedef struct enginefuncs_s
{
int (*pfnPrecacheModel)
(char* s);
int (*pfnPrecacheSound)
(char* s);
void(*pfnSetModel) (edict_t
*e, const char *m);
int (*pfnModelIndex)
(const char *m);
int (*pfnModelFrames)
(int modelIndex);
void(*pfnSetSize) (edict_t
*e, const float *rgflMin, const float *rgflMax);
void(*pfnChangeLevel) (char*
s1, char* s2);
void(*pfnGetSpawnParms) (edict_t
*ent);
void(*pfnSaveSpawnParms)(edict_t *ent);
float (*pfnVecToYaw) (const
float *rgflVector);
void(*pfnVecToAngles) (const
float *rgflVectorIn, float *rgflVectorOut);
void(*pfnMoveToOrigin) (edict_t
*ent, const float *pflGoal, float dist, int iMoveType);
void(*pfnChangeYaw)
(edict_t* ent);
void(*pfnChangePitch)
(edict_t* ent);
edict_t*(*pfnFindEntityByString)(edict_t
*pEdictStartSearchAfter, const char *pszField, const char *pszValue);
int (*pfnGetEntityIllum)
(edict_t* pEnt);
edict_t*(*pfnFindEntityInSphere)(edict_t
*pEdictStartSearchAfter, const float *org, float rad);
edict_t*(*pfnFindClientInPVS) (edict_t
*pEdict);
edict_t* (*pfnEntitiesInPVS)(edict_t
*pplayer);
void(*pfnMakeVectors) (const
float *rgflVector);
void(*pfnAngleVectors) (const
float *rgflVector, float *forward, float *right, float *up);
edict_t*(*pfnCreateEntity) (void);
void(*pfnRemoveEntity)
(edict_t* e);
edict_t*(*pfnCreateNamedEntity) (int className);
void(*pfnMakeStatic)(edict_t
*ent);
int (*pfnEntIsOnFloor)
(edict_t *e);
int (*pfnDropToFloor)
(edict_t* e);
int (*pfnWalkMove)
(edict_t *ent, float yaw, float dist, int iMode);
void(*pfnSetOrigin) (edict_t
*e, const float *rgflOrigin);
void(*pfnEmitSound) (edict_t
*entity, int channel, const char *sample, /*int*/float volume, float
attenuation, int fFlags, int pitch);
void(*pfnEmitAmbientSound) (edict_t
*entity, float *pos, const char *samp, float vol, float
attenuation, int
fFlags, int pitch);
void(*pfnTraceLine) (const
float *v1, const float *v2, int fNoMonsters, edict_t *pentToSkip,
TraceResult *ptr);
void(*pfnTraceToss)
(edict_t* pent, edict_t* pentToIgnore, TraceResult *ptr);
int (*pfnTraceMonsterHull) (edict_t
*pEdict, const float *v1, const float *v2, int fNoMonsters, edict_t
*pentToSkip, TraceResult *ptr);
void(*pfnTraceHull) (const
float *v1, const float *v2, int fNoMonsters, int hullNumber, edict_t
*pentToSkip, TraceResult
Re: [hlcoders] upon futrhe investigation
steam.dll is no longer the newest version and as it isn't part of the half-life dir by default, it isn't kept up to date. I solved this by grabbing the latest version from my main steam dir. Ben Kyle wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I discovered its steam.dll and steamapp.cfg which are causing the problem. Did something change in the last 2 weeks to make these files no longer work the way they originally did? They are both in my half-life dir and my steamapp is correct, well it worked for debugging for the last month, don't see why it would quit now. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HL2 Source Leaked
A confirmation or statement from valve would be required before hearing how this affects things. Stan Bubrouski wrote: Well, As many of you probably know, the source to HL2 is being distributed over P2P and IRC already. Valve, I have heard nothing from your end, on this... how does this affect things? -sb ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Debugin mods with steam
He may want to be prepared and have a working version before the transition is forced upon us. The more he can sort out now the less pressure there is when the switch is final. Unfortunately I have no idea how to debug a steam mod and I haven't tried as I am in the fortunate position of my mod and the development version of my mod both working on steam. Are you launching hl via steam.exe or hl.exe in the steamapps\email addy\half-life\ dir? I'd try debugging with steam.exe as that is what the steam installed updated all my shortcuts to when moving mods across. Ben p.s I noticed some new params now that steam updated my shortcuts. They are -silent -applaunch 70. Not sure about the 70, but that should boot you into your mod rather than the steam menu and from their you should be able to debug, however like I said I haven't tried yet Tony omega Sergi wrote: Hence why I said, use regular hl until we're forced not to. -omega http://www.frontline2.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Webrant Sent: September 12, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Debugin mods with steam Problem is the mod crashes in GameUI.dll when I start a LAN server in steam. In regular HL everything works just fine :) - Original Message - From: Tony omega Sergi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 12, 2003 7:59 PM Subject: RE: [hlcoders] Debugin mods with steam I think you should just use the regular standalone hl for now. Until the actual hl patch, it still works. Just run it in lan mode. Much simpler until the actual patch is out (that's what im using at the moment to do my devel stuff) -omega http://www.frontline2.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Webrant Sent: September 12, 2003 1:46 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Debugin mods with steam HL.exe exits just after starting it and I have to reattach to to a new instance Anyone got a solution to that problem? /BulliT ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] first person spectator cam
The method I used to get my reload animations to play in firstperson was to use an event for the reload and play the animation and sound client side. There is probably an easier and quicker way to do it, but this worked for me. Ben - Original Message - From: Mark Gornall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 10:23 AM Subject: [hlcoders] first person spectator cam Hi, I use the sdk2.3 first person spectate cam when you are dead (like CS). You can see the gun model of the person you are spectating fire but there is no reload anim played when the player reloads. Nor does the fov change when they zoom. Both these things work in CS's cams, I was wondering if there is a simple way to add them? Thanks, Mark. __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] first person spectator cam
That is what i am talking about as well. In the sdk the weapons call DefaultReload to display their reload animation. I assume you have done the same. What I did was create an event which played the reload animation and was called like the firing events through PLAYBACK_EVENT_FULL. Ben - Original Message - From: Mark Gornall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 3:50 PM Subject: RE: [hlcoders] first person spectator cam Hi, I already use client side events for all weapons. I'm specifically talking about when your spectating someone else that view.cpp/hud_spectator.cpp doesn't know to play the reload or somehow my reload anim isn't linking up with the spectate code. Thanks, Mark. __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] weird issue when game starts
I found that I got unknown adresses, when an entity hasn't been exported properly. If you do it in debug mode you usally get more info, like which think/touch function hasn't been exported. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 23, 2002 10:21 AM Subject: Re: [hlcoders] weird issue when game starts I always get that unknown address, no idea what causes it, (Could be a message sending too early or something client side trying to use the engine) - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 23, 2002 7:07 AM Subject: RE: [hlcoders] weird issue when game starts Judge for yourself ;) Took it from CS and modified it game Ron's Useless MOD // Game title url_info www.sampier.com // information URL url_dl version Version? Who needs a stinking version // version of mod size 18400 svonly 0 // server side only mod? (1=yes 0=no) type multiplayer_only cldll 1 hlversion 1108 nomodels 1 nohimodel 1 mpentity info_player_start gamedll dlls\mp.dll gamedll_linux dlls/cs_i386.so trainmap tr_1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roachfood - the-coming.com Sent: Saturday, February 23, 2002 2:01 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] weird issue when game starts shot in the dark here is your liblist.gam file configured correctly for multiplayer and everything? Like i said... shot in the dark :-P Roachie - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 23, 2002 12:40 AM Subject: RE: [hlcoders] weird issue when game starts I found the reason for the continual map change, but not why nor the reason for the numerous Can't find address errors :( For some unknown reason g_fGameOver is forever TRUE :( Which means the little block of code in CHalfLifeMultiplay :: Think(); Is repeatedly called which results in ChangeLevel(); being called I have done a search for g_fGameOver in both a CLEAN dlls dir and My current working dlls dir. Every single use of g_fGameOver is identical, Same # of calls to extern DLL_GLOBAL BOOL g_fGameOver as well as the same number of calls to setting it to TRUE/FALSE (even down to the same functions and line numbers). I have been in the debugger for nearly 3 hours now, tried to step through the code from InstallGameRules(); but that just wont work Seeing that once it tries to leave DispatchSpawn(); the debugger dies For I am not the keeper of the engine code nor have a debug version of hl.exe etc.. Can someone shed some light here? Regards, Ron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Yacketta, Ronald Sent: Friday, February 22, 2002 10:25 PM To: [EMAIL PROTECTED] Subject: [hlcoders] weird issue when game starts This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Can someone lend a hand here? When I fire up the game it does not crash, but changes maps every 5 seconds. I see this in console as well -Ron PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/muz1.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/laserbeam.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/WXplo1.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/bubble.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/bloodspray.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/blood.spr PackFile: C:\Sierra\Half-Life\valve\pak0.pak : sprites/explode1.spr Can't find address: 04e34071 Can't find address: 04e3405d Can't find address: 04e34071 Can't find address: 04e3405d Can't find address: 04e34071 Can't find address: 04e3405d Can't find address: 04e34071 Can't find address: 04e3405d Can't find address: 04e34071 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] 9 way blending?
Ok I don't know about all of you, but I allready had this code in a file which isn't by default included in the client project. See if you all have GameStudioModelRenderer_Sample.cpp GameStudioModelRenderer_Sample.h - Original Message - From: Persuter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 18, 2002 2:51 AM Subject: RE: [hlcoders] 9 way blending? lol... I liked the combination of these two sentences: i found out that it is from counter-strike You should contact the person that wrote the source code Many CS fans wish it were that easy, neh? Persuter -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED]] On Behalf Of botman Sent: Sunday, February 17, 2002 11:38 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] 9 way blending? i have downloaded a 9 way blending source from the absconder effect mod website (www.tae-mod.com) i found out that it is from counter-strike and two functions are undefined/unroutined : void Game_GetSequence() and void Game_GetOrientation() You should contact the person that wrote the source code to find out what those functions are supposed to do. There is a GetSequence() function in the SDK, you can look at that as a reference, but there is no GetOrientation() function in the SDK. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
