Re: [hlcoders] Map entities client-side
Cant you pass the keyvalues to the client in your message? I know for my mod we have animated plants and items that are on the server side only. For instance when the player touches the animated item, a message is sent to the client tellin it what it is and the inventory/hud info is updated accordingly. I dont know if that pertains to your original question... but anyway... =) If you really need the keyvalues, when the entity is created send a message to the client. Im tired... im going to bed. Roachie www.the-coming.com - Original Message - From: Persuter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 12:27 AM Subject: RE: [hlcoders] Map entities client-side Btw, to clear things up on this, I did indeed eventually use the message to client and it works fine now (better than I expected, actually), but I just found it odd that we can't get the keyvalues from the client-side. OK, now continue the digression... :) Thanks for everyone who helped, btw... Persuter -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED]] On Behalf Of Pat Magnan Sent: Tuesday, February 12, 2002 3:28 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Map entities client-side Two solutions come to mind: - parse the BSP client side... - transmit the value of that keyvalue to the client in a message, just once while the HUD is initializing should do it (keyvalues don't change do they?). I chose the latter for an entity that was placed in the map, and rendered client side by TriAPI. I think some folks were working on trying to parse the BSP client side, but ran into trouble keeping things in synch... I think you've been around longer than I have and may not need it, :) but if you want to see an outline of my approach, I did up a tutorial (concept mostly) here: http://www.tourofdutymod.com/tutorials.php Is there a way to access keyvalue info in the map from the client- side? I keep on thinking you must be able to, since obviously the client side has the map, but I haven't been able to find any way to do it. Thanks, Persuter _ 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 --- Eighty percent of life is showing up. -- Woody Allen ___ 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
Re: [hlcoders] Map entities client-side
Prasing the BSP Client side is the best way...Although if its just an entity
that is used once, then just sent it serverside its easier to setup...
I'm gunna lead you through using the BSP Client side...
First thing add to your project
bspfile.cpp
cmdlib.cpp
mathlib.cpp
scriplib.cpp
And I Include bspfile.h into the files you wish to use the bsp stuff Now,
time to get the name of the map, well we know entity in index 0 is the map,
so lets use the name of the model, to get the map...
gEngfuncs.GetEntityByIndex(0)-model-name will give the map..now to load
the BSP File..
LoadBSPFile(gEngfuncs.GetEntityByIndex(0)-model-name);
Now the epairs/entities aren't prased in that they are just stored, time to
prase the entities
ParseEntities();
Now its time to find the entity you need..
entity_t * FindEntityByClassName(char *classname)
{
for(int i=0;inum_entities;i++)
if(strcmp(classname, ValueForKey(entities[i],classname)) == 0)
return entities[i];
return NULL;
}
Now how about we try and find and aim at an info_player_deathmatch entity,
we would do the following..
entity_t * entity = FindEntityByClassName(info_player_deathmatch);
How about an example of using that entity, lets make it aim at that point :D
hehe gotta have some fun sometime
vec3_t dirAim;
vec3_t MyOrigin
float Angles[3];
VectorCopy(MyOrigin,gEngfuncs.GetLocalPlayer()-origin)
VectorMinus(entity-origin, dirAim, MyOrigin);
VectorAngles(dirAim, Angles);
for(int i=0;i3;i++)
if(Angles[i]180)
Angles-=360;
gEngfuncs.SetViewAngles(Angles);
Now There you are happy as can be, only one thing, you will be aiming from
the center of your body if you try that, but thats just to show how to use
the entity_t stuff, btw the entity_t struct is stored in bspfile.h
I Recommend only loading the bsp and prasing it, probley in HUD_VidInit
- Original Message -
From: Roachfood - the-coming.com [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 7:38 PM
Subject: Re: [hlcoders] Map entities client-side
Cant you pass the keyvalues to the client in your message? I know for my
mod we have animated plants and items that are on the server side only.
For
instance when the player touches the animated item, a message is sent to
the
client tellin it what it is and the inventory/hud info is updated
accordingly. I dont know if that pertains to your original question...
but
anyway... =)
If you really need the keyvalues, when the entity is created send a
message
to the client. Im tired... im going to bed.
Roachie
www.the-coming.com
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 12:27 AM
Subject: RE: [hlcoders] Map entities client-side
Btw, to clear things up on this, I did indeed eventually use the message
to client and it works fine now (better than I expected, actually), but
I just found it odd that we can't get the keyvalues from the
client-side. OK, now continue the digression... :)
Thanks for everyone who helped, btw...
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of Pat Magnan
Sent: Tuesday, February 12, 2002 3:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Map entities client-side
Two solutions come to mind:
- parse the BSP client side...
- transmit the value of that keyvalue to the client in a message, just
once while the HUD is initializing should do it (keyvalues don't
change
do they?).
I chose the latter for an entity that was placed in the map, and
rendered client side by TriAPI. I think some folks were working on
trying to parse the BSP client side, but ran into trouble keeping
things in synch...
I think you've been around longer than I have and may not need it, :)
but if you want to see an outline of my approach, I did up a tutorial
(concept mostly) here:
http://www.tourofdutymod.com/tutorials.php
Is there a way to access keyvalue info in the map from the client-
side?
I keep on thinking you must be able to, since obviously the client
side
has the map, but I haven't been able to find any way to do it.
Thanks,
Persuter
_
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
---
Eighty percent of life is showing up.
-- Woody Allen
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Weapon Recoil
Might also play around with the values in V_CalcGunAngle on the client-side. You can use that to dynamically change the motion of the gun. Persuter -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders- [EMAIL PROTECTED]] On Behalf Of [DRP]Avatar-X Sent: Wednesday, February 13, 2002 8:03 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Weapon Recoil You could animate the firing sequence of the weapon. Look at how the magnum fires in single-player... the view moves a bit and the weapon recoils -av Commando wrote: I am trying to simulate weapons pulling up and to the right when fired full auto by adjusting the punch angle client and server side and this works fairly well. The only problem is that the punch angle causes the point of aim and the player's eye direction to move, but it does not move the weapon model with it. This ends up looking kind of strange with the aim being up and right, but the model pointing at the original location. I like the effect that the punch angle creates in that it decays back to the original aim point, so does anyone know a way to get the weapon model to move with the punch angle? Any help, or even pointers to what I need to adjust so that I can do it myself would help. Rob Prouse Tour of Duty Mod http://www.tourofdutymod.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - [DRP]Avatar-X SillyZone Homepage: www.thesillyzone.com SillyZone Forums: forum.thesillyzone.com My Homepage: www.cyberwyre.com ___ 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
RE: [hlcoders] Map entities client-side
lol, reductor, yeah, I started looking at bspfile.cpp... Then I just
rolled my eyes and didn't do it. It's just something I need to send one
time. Making the message was simple in the extreme, I just wanted to
know if there was a simpler way that didn't take up net bandwidth on the
client-side.
But thanks, I'll be sure to keep this around for next time... :)
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of ReDucTor
Sent: Wednesday, February 13, 2002 4:29 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Map entities client-side
Prasing the BSP Client side is the best way...Although if its just an
entity
that is used once, then just sent it serverside its easier to setup...
I'm gunna lead you through using the BSP Client side...
First thing add to your project
bspfile.cpp
cmdlib.cpp
mathlib.cpp
scriplib.cpp
And I Include bspfile.h into the files you wish to use the bsp stuff
Now,
time to get the name of the map, well we know entity in index 0 is the
map,
so lets use the name of the model, to get the map...
gEngfuncs.GetEntityByIndex(0)-model-name will give the map..now to
load
the BSP File..
LoadBSPFile(gEngfuncs.GetEntityByIndex(0)-model-name);
Now the epairs/entities aren't prased in that they are just stored,
time
to
prase the entities
ParseEntities();
Now its time to find the entity you need..
entity_t * FindEntityByClassName(char *classname)
{
for(int i=0;inum_entities;i++)
if(strcmp(classname, ValueForKey(entities[i],classname))
==
0)
return entities[i];
return NULL;
}
Now how about we try and find and aim at an info_player_deathmatch
entity,
we would do the following..
entity_t * entity = FindEntityByClassName(info_player_deathmatch);
How about an example of using that entity, lets make it aim at that
point
:D
hehe gotta have some fun sometime
vec3_t dirAim;
vec3_t MyOrigin
float Angles[3];
VectorCopy(MyOrigin,gEngfuncs.GetLocalPlayer()-origin)
VectorMinus(entity-origin, dirAim, MyOrigin);
VectorAngles(dirAim, Angles);
for(int i=0;i3;i++)
if(Angles[i]180)
Angles-=360;
gEngfuncs.SetViewAngles(Angles);
Now There you are happy as can be, only one thing, you will be aiming
from
the center of your body if you try that, but thats just to show how to
use
the entity_t stuff, btw the entity_t struct is stored in bspfile.h
I Recommend only loading the bsp and prasing it, probley in
HUD_VidInit
- Original Message -
From: Roachfood - the-coming.com [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 7:38 PM
Subject: Re: [hlcoders] Map entities client-side
Cant you pass the keyvalues to the client in your message? I know
for
my
mod we have animated plants and items that are on the server side
only.
For
instance when the player touches the animated item, a message is
sent to
the
client tellin it what it is and the inventory/hud info is updated
accordingly. I dont know if that pertains to your original
question...
but
anyway... =)
If you really need the keyvalues, when the entity is created send a
message
to the client. Im tired... im going to bed.
Roachie
www.the-coming.com
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 12:27 AM
Subject: RE: [hlcoders] Map entities client-side
Btw, to clear things up on this, I did indeed eventually use the
message
to client and it works fine now (better than I expected,
actually),
but
I just found it odd that we can't get the keyvalues from the
client-side. OK, now continue the digression... :)
Thanks for everyone who helped, btw...
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of Pat Magnan
Sent: Tuesday, February 12, 2002 3:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Map entities client-side
Two solutions come to mind:
- parse the BSP client side...
- transmit the value of that keyvalue to the client in a
message,
just
once while the HUD is initializing should do it (keyvalues don't
change
do they?).
I chose the latter for an entity that was placed in the map, and
rendered client side by TriAPI. I think some folks were working
on
trying to parse the BSP client side, but ran into trouble
keeping
things in synch...
I think you've been around longer than I have and may not need
it,
:)
but if you want to see an outline of my approach, I did up a
tutorial
(concept mostly) here:
http://www.tourofdutymod.com/tutorials.php
Is there a way to access keyvalue info in the map from the
client-
side?
I keep on thinking you must be able to, since obviously the
client
side
has the map, but I haven't been able to find any way to do it.
Re: [hlcoders] THE DREADED NOOB POST
Hello to all the respected established coders of this list. My names Richard and I'm yet another one of those annoying newbie coders who has 100 questions but I'll them brake down to one. snip There isn't any kind of overall reference or API reference to the Half-Life SDK. Fully understanding the SDK requires a medium to advanced level of knowledge in C++. The only way you will learn how things work is by looking at and playing with the SDK source code. You will run into MANY, MANY times when something doesn't work (the game crashes, goes into an infinite loop, or doesn't do some effect that you are trying to do). In fact, you will find that there are more times when something doesn't work than you have when something does work. You will learn by trial and error. Some of these errors you will repeat over and over and will eventually learn not to do those things (via negative reinforcement). The best way to become completely frustrated with the SDK is to start out by ripping out 70% or 80% of what's there and completely replacing it with all your own code. You will find that you get dozens/hundreds of compiler errors and when you finally do get rid of all the compiler errors, the game crashed deep inside the Half-Life engine (where you can't determine what caused the crash). The best way to NOT get frustrated with the SDK is making very tiny small changes one by one to the SDK source code and testing things out after each small change. Once you begin to understand how the variables, classes and functions are used, you will find yourself making much larger changes at a time and will find that you have fewer and fewer problems with new code. The time span for this learning curve can be anywhere from 2 or 3 months up to 6 months or more, depending on your skill level in programming and your experience with programming in C++. Also, ALWAYS save backup copies of stuff that you are about to change so that you can easily roll back to a working version when you completely screw something up (which you will do more than once). When browsing through the SDK source code, it's useful to have several editor windows open at once to view the .cpp and .h files in the dlls folder and also to be able to view the .h files in the engine and common folders as well. Start with the thing that the engine deals with, the edict_t structure. This can be found in the engine\progdefs.h file. Every entity created in the game has one of these structures. It contains things like origin (3D world coordinates), health, velocity, angles and so on. This edict_t structure is pointed to by a class member variable called pev. Wherever you see pev used, just think edict_t. For example you'll see pev-health, or pev-angles or pev-velocity used all over the place. Every entity in the SDK source code is based on the CBaseEntity class and every other class inherits directly or indirectly from this CBaseEntity class. Look in the cbase.h and cbase.cpp files for the member variables and functions for this base class. Everything else is just inheritance of the CBaseEntity class with stuff throw in for that specific type of entity (for example, weapons contain ammo, players have weapons, etc.). Pretty much all basic C++ type stuff. If you can resist the urge to try to change too much stuff at once and try to understand one small piece of the puzzle at a time, it won't be too long before you are getting up to speed on how to create your own MOD with 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
RE: [hlcoders] Map entities client-side
Well yeah, that's why I didn't care, just makes sense to cut down on
network traffic whenever possible, 'specially if it's easier.
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of Tom
Sent: Wednesday, February 13, 2002 12:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Map entities client-side
well if you think about it, your only sending it over as they connect,
so
its not bad nettraffic, it doesnt get in the way of gameplay
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 5:20 PM
Subject: RE: [hlcoders] Map entities client-side
lol, reductor, yeah, I started looking at bspfile.cpp... Then I just
rolled my eyes and didn't do it. It's just something I need to send
one
time. Making the message was simple in the extreme, I just wanted to
know if there was a simpler way that didn't take up net bandwidth on
the
client-side.
But thanks, I'll be sure to keep this around for next time... :)
Persuter
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of ReDucTor
Sent: Wednesday, February 13, 2002 4:29 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Map entities client-side
Prasing the BSP Client side is the best way...Although if its just
an
entity
that is used once, then just sent it serverside its easier to
setup...
I'm gunna lead you through using the BSP Client side...
First thing add to your project
bspfile.cpp
cmdlib.cpp
mathlib.cpp
scriplib.cpp
And I Include bspfile.h into the files you wish to use the bsp
stuff
Now,
time to get the name of the map, well we know entity in index 0 is
the
map,
so lets use the name of the model, to get the map...
gEngfuncs.GetEntityByIndex(0)-model-name will give the map..now
to
load
the BSP File..
LoadBSPFile(gEngfuncs.GetEntityByIndex(0)-model-name);
Now the epairs/entities aren't prased in that they are just
stored,
time
to
prase the entities
ParseEntities();
Now its time to find the entity you need..
entity_t * FindEntityByClassName(char *classname)
{
for(int i=0;inum_entities;i++)
if(strcmp(classname,
ValueForKey(entities[i],classname))
==
0)
return entities[i];
return NULL;
}
Now how about we try and find and aim at an
info_player_deathmatch
entity,
we would do the following..
entity_t * entity =
FindEntityByClassName(info_player_deathmatch);
How about an example of using that entity, lets make it aim at
that
point
:D
hehe gotta have some fun sometime
vec3_t dirAim;
vec3_t MyOrigin
float Angles[3];
VectorCopy(MyOrigin,gEngfuncs.GetLocalPlayer()-origin)
VectorMinus(entity-origin, dirAim, MyOrigin);
VectorAngles(dirAim, Angles);
for(int i=0;i3;i++)
if(Angles[i]180)
Angles-=360;
gEngfuncs.SetViewAngles(Angles);
Now There you are happy as can be, only one thing, you will be
aiming
from
the center of your body if you try that, but thats just to show
how to
use
the entity_t stuff, btw the entity_t struct is stored in bspfile.h
I Recommend only loading the bsp and prasing it, probley in
HUD_VidInit
- Original Message -
From: Roachfood - the-coming.com [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 7:38 PM
Subject: Re: [hlcoders] Map entities client-side
Cant you pass the keyvalues to the client in your message? I
know
for
my
mod we have animated plants and items that are on the server
side
only.
For
instance when the player touches the animated item, a message is
sent to
the
client tellin it what it is and the inventory/hud info is
updated
accordingly. I dont know if that pertains to your original
question...
but
anyway... =)
If you really need the keyvalues, when the entity is created
send a
message
to the client. Im tired... im going to bed.
Roachie
www.the-coming.com
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 13, 2002 12:27 AM
Subject: RE: [hlcoders] Map entities client-side
Btw, to clear things up on this, I did indeed eventually use
the
message
to client and it works fine now (better than I expected,
actually),
but
I just found it odd that we can't get the keyvalues from the
client-side. OK, now continue the digression... :)
Thanks for everyone who helped, btw...
Persuter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-
[EMAIL PROTECTED]] On Behalf Of Pat Magnan
Sent: Tuesday, February 12, 2002 3:28 PM
To: [EMAIL PROTECTED]
Subject: Re:
Re: [hlcoders] THE DREADED NOOB POST
I found the easiest way was to create a mod (not like release it, just plan out some ideas), because then if you know what your aiming for, you know what you have to do! - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 8:39 PM Subject: Re: [hlcoders] THE DREADED NOOB POST Hello to all the respected established coders of this list. My names Richard and I'm yet another one of those annoying newbie coders who has 100 questions but I'll them brake down to one. snip There isn't any kind of overall reference or API reference to the Half-Life SDK. Fully understanding the SDK requires a medium to advanced level of knowledge in C++. The only way you will learn how things work is by looking at and playing with the SDK source code. You will run into MANY, MANY times when something doesn't work (the game crashes, goes into an infinite loop, or doesn't do some effect that you are trying to do). In fact, you will find that there are more times when something doesn't work than you have when something does work. You will learn by trial and error. Some of these errors you will repeat over and over and will eventually learn not to do those things (via negative reinforcement). The best way to become completely frustrated with the SDK is to start out by ripping out 70% or 80% of what's there and completely replacing it with all your own code. You will find that you get dozens/hundreds of compiler errors and when you finally do get rid of all the compiler errors, the game crashed deep inside the Half-Life engine (where you can't determine what caused the crash). The best way to NOT get frustrated with the SDK is making very tiny small changes one by one to the SDK source code and testing things out after each small change. Once you begin to understand how the variables, classes and functions are used, you will find yourself making much larger changes at a time and will find that you have fewer and fewer problems with new code. The time span for this learning curve can be anywhere from 2 or 3 months up to 6 months or more, depending on your skill level in programming and your experience with programming in C++. Also, ALWAYS save backup copies of stuff that you are about to change so that you can easily roll back to a working version when you completely screw something up (which you will do more than once). When browsing through the SDK source code, it's useful to have several editor windows open at once to view the .cpp and .h files in the dlls folder and also to be able to view the .h files in the engine and common folders as well. Start with the thing that the engine deals with, the edict_t structure. This can be found in the engine\progdefs.h file. Every entity created in the game has one of these structures. It contains things like origin (3D world coordinates), health, velocity, angles and so on. This edict_t structure is pointed to by a class member variable called pev. Wherever you see pev used, just think edict_t. For example you'll see pev-health, or pev-angles or pev-velocity used all over the place. Every entity in the SDK source code is based on the CBaseEntity class and every other class inherits directly or indirectly from this CBaseEntity class. Look in the cbase.h and cbase.cpp files for the member variables and functions for this base class. Everything else is just inheritance of the CBaseEntity class with stuff throw in for that specific type of entity (for example, weapons contain ammo, players have weapons, etc.). Pretty much all basic C++ type stuff. If you can resist the urge to try to change too much stuff at once and try to understand one small piece of the puzzle at a time, it won't be too long before you are getting up to speed on how to create your own MOD with 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] THE DREADED NOOB POST
here's an idea i've been playing with, i dunno if it would be worth it to you guys but it would definately help me out... I program win32 programs using windows API, if you've never programmed using this, let me tell you there are a LOT of API calls available..i'm still scratching my head over many of them. anyway, reguardless of how much i know, i tend to forget relatively quickly what is available and what it does. SO. short story long, go check this out http://www.allapi.net there is a download available that does the following: 1) lists the API's 2) in words, tells shortly what the function does, what the variables passed in are and are for 3) gives a small sample of source code showing you how to use the function i have used this almost every day since downloading it, it is a very handy tool...my point to this whole spurge of long winded ascii spew is that i would like to see something like this utility created for the HL SDK functions. i havent had much time to really get into the SDK, or do any tinkering with it, so i'm still in the dark about the whole thing...however, i am willing to code this utility. all it would require is that those who know what they are doing email me with functiom calls, explanations, and sample source. i would then post the program and its updates for you to download. what do you guys think? _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] THE DREADED NOOB POST
i'll have to agree with mr botman. Thats the way i went through it. I'm still not 100% great with the sdk, as i haven't touched triapi, monster ai, player movement prediction OR the model rendering stuff... But i get to each one as i require to make a new change. When first looking at the sdk its daunting. Its bloody big and scary and you don't know what half the crap does(and yes at first it looks like crap) Trial and error to begin with is what lets you learn the sdk. You get crashes here and there then realize that your trying to access hud elements no initialized etc and you learn the tricks of the trade. If you have a fairly good c++ background knowing pointers and OOP stuff you should be good to go. If you know nothing then i pity you plunging into it but since you stated you have c++ knowledge then your right :) just hang in there... it took me the 1 year i have spent with it to get where i am... others have spent longer. Make sure you enjoy it all the time too or learning becomes a major bitch :/ just my 2 cents. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 14, 2002 9:30 AM Subject: Re: [hlcoders] THE DREADED NOOB POST I found the easiest way was to create a mod (not like release it, just plan out some ideas), because then if you know what your aiming for, you know what you have to do! - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 8:39 PM Subject: Re: [hlcoders] THE DREADED NOOB POST Hello to all the respected established coders of this list. My names Richard and I'm yet another one of those annoying newbie coders who has 100 questions but I'll them brake down to one. snip There isn't any kind of overall reference or API reference to the Half-Life SDK. Fully understanding the SDK requires a medium to advanced level of knowledge in C++. The only way you will learn how things work is by looking at and playing with the SDK source code. You will run into MANY, MANY times when something doesn't work (the game crashes, goes into an infinite loop, or doesn't do some effect that you are trying to do). In fact, you will find that there are more times when something doesn't work than you have when something does work. You will learn by trial and error. Some of these errors you will repeat over and over and will eventually learn not to do those things (via negative reinforcement). The best way to become completely frustrated with the SDK is to start out by ripping out 70% or 80% of what's there and completely replacing it with all your own code. You will find that you get dozens/hundreds of compiler errors and when you finally do get rid of all the compiler errors, the game crashed deep inside the Half-Life engine (where you can't determine what caused the crash). The best way to NOT get frustrated with the SDK is making very tiny small changes one by one to the SDK source code and testing things out after each small change. Once you begin to understand how the variables, classes and functions are used, you will find yourself making much larger changes at a time and will find that you have fewer and fewer problems with new code. The time span for this learning curve can be anywhere from 2 or 3 months up to 6 months or more, depending on your skill level in programming and your experience with programming in C++. Also, ALWAYS save backup copies of stuff that you are about to change so that you can easily roll back to a working version when you completely screw something up (which you will do more than once). When browsing through the SDK source code, it's useful to have several editor windows open at once to view the .cpp and .h files in the dlls folder and also to be able to view the .h files in the engine and common folders as well. Start with the thing that the engine deals with, the edict_t structure. This can be found in the engine\progdefs.h file. Every entity created in the game has one of these structures. It contains things like origin (3D world coordinates), health, velocity, angles and so on. This edict_t structure is pointed to by a class member variable called pev. Wherever you see pev used, just think edict_t. For example you'll see pev-health, or pev-angles or pev-velocity used all over the place. Every entity in the SDK source code is based on the CBaseEntity class and every other class inherits directly or indirectly from this CBaseEntity class. Look in the cbase.h and cbase.cpp files for the member variables and functions for this base class. Everything else is just inheritance of the CBaseEntity class with stuff throw in for that specific type of entity (for example, weapons contain ammo, players have weapons, etc.). Pretty much all basic C++ type stuff. If you can resist the urge to try
RE: [hlcoders] THE DREADED NOOB POST
I agree as well, hell those on the list (Leon?) can defiantly agree that I have asked my share utterly stupid retarded ridiculous absurd moronic questions ;) why? Hell I have no clue about the SDK and don't even attempt to think I do. I have a semi (hell 100% home schooled) grasp (at times) of c++ which limits what I can do/ understand in the SDK. All in all I have defiantly learned a boat load (thanks to the list and private emails to Valve members) sense I started mucking with the SDK nearly 6 months or so ago! It does wonders to try something, have it core dump and leave you sitting in front of that (POS) MSVS debugger wondering WTF did I do and why the F it is not working. -Ron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Christopher Long Sent: Wednesday, February 13, 2002 10:30 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] THE DREADED NOOB POST i'll have to agree with mr botman. Thats the way i went through it. I'm still not 100% great with the sdk, as i haven't touched triapi, monster ai, player movement prediction OR the model rendering stuff... But i get to each one as i require to make a new change. When first looking at the sdk its daunting. Its bloody big and scary and you don't know what half the crap does(and yes at first it looks like crap) Trial and error to begin with is what lets you learn the sdk. You get crashes here and there then realize that your trying to access hud elements no initialized etc and you learn the tricks of the trade. If you have a fairly good c++ background knowing pointers and OOP stuff you should be good to go. If you know nothing then i pity you plunging into it but since you stated you have c++ knowledge then your right :) just hang in there... it took me the 1 year i have spent with it to get where i am... others have spent longer. Make sure you enjoy it all the time too or learning becomes a major bitch :/ just my 2 cents. - Original Message - From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 14, 2002 9:30 AM Subject: Re: [hlcoders] THE DREADED NOOB POST I found the easiest way was to create a mod (not like release it, just plan out some ideas), because then if you know what your aiming for, you know what you have to do! - Original Message - From: botman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 8:39 PM Subject: Re: [hlcoders] THE DREADED NOOB POST Hello to all the respected established coders of this list. My names Richard and I'm yet another one of those annoying newbie coders who has 100 questions but I'll them brake down to one. snip There isn't any kind of overall reference or API reference to the Half-Life SDK. Fully understanding the SDK requires a medium to advanced level of knowledge in C++. The only way you will learn how things work is by looking at and playing with the SDK source code. You will run into MANY, MANY times when something doesn't work (the game crashes, goes into an infinite loop, or doesn't do some effect that you are trying to do). In fact, you will find that there are more times when something doesn't work than you have when something does work. You will learn by trial and error. Some of these errors you will repeat over and over and will eventually learn not to do those things (via negative reinforcement). The best way to become completely frustrated with the SDK is to start out by ripping out 70% or 80% of what's there and completely replacing it with all your own code. You will find that you get dozens/hundreds of compiler errors and when you finally do get rid of all the compiler errors, the game crashed deep inside the Half-Life engine (where you can't determine what caused the crash). The best way to NOT get frustrated with the SDK is making very tiny small changes one by one to the SDK source code and testing things out after each small change. Once you begin to understand how the variables, classes and functions are used, you will find yourself making much larger changes at a time and will find that you have fewer and fewer problems with new code. The time span for this learning curve can be anywhere from 2 or 3 months up to 6 months or more, depending on your skill level in programming and your experience with programming in C++. Also, ALWAYS save backup copies of stuff that you are about to change so that you can easily roll back to a working version when you completely screw something up (which you will do more than once). When browsing through the SDK source code, it's useful to have several editor windows open at once to view the .cpp and .h files in the dlls folder and also to be able to view the .h files in the engine and common folders as well. Start with the thing that the engine deals with, the edict_t structure. This can be found in the engine\progdefs.h
