Re: [hlcoders] CS Damage system
At 01:35 AM 9/24/2004 -0400, you wrote: He i was wondering how the damage is done depending on the distnace between attacker and victim in CS. Maybe some calculations or info on this will be helpfull. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders As a first stab at the problem, you might try calculating the distance between the damaged entity and pevAttacker in TakeDamage. Then scale flDamage inversely with respect to that distance. Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Steam/Mod/Coding concerns- attn: Valve
Another consideration is whether mods for standalone HL2 would need to be installed differently than mods for HL2 downloaded over Steam. Presuter At 01:00 PM 9/7/2003 -0400, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] First off, I know this is the hl coding list; part of this concerns that, but it is generally about steam and mod functionality. I don't know of where else to ask this, where that anybody could respond to my concerns without everyone asking the same things down the line. I also know that several valve members are on this list still. I have some concerns regarding steam and mod functionality. Especially from a coding/debugging standpoint. I've experimented with steam (placing mod in it) and it's a pain. I didn't bother trying to debug it, since I found no way of running it via the command line, this poses somewhat of an issue as well. How will a user run other mods? Will EVERYTHING go in the steam "available games" menu? This itself is a concern for me the way that steam works; how that everything is cached multiple times. CS + TFC + DMC + HL itself inside steam use 600mb+ more than they do with standalone "old" non-steam hl! Because content is duplicated, and there is a cache! Installing a mod into one of this is also an issue. I know it can be done, as Alfred showed me how. (simply copy the mod into one of the cache folders, and add -game mod_dir in the advanced options of that game to run it) Will this be the case for ALL MODs? This troubles me, especially at how much trouble the average, computer/gaming 'noob' has in installing a regular mod! So what does this mean for us modders? Are we going to have to go through extra steps to make our mods function, and waste space etc? I'm having trouble wording this so it makes more sense. Grr. As for debugging; if we will have to run through steam, how will we go about debugging the mod then? Will it still run standalone? Imo, steam is good in some aspects, but horribly, horribly designed in others. I hope all of this is different for non-beta than what I've discovered already. -- ___ 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] Linux compilation problem
It's -l Persuter At 08:54 PM 6/15/2003 +0200, you wrote: Florian Zschocke wrote: > botman wrote: >> >> I believe the Valve MODs are compiled and linked with 'gcc' and not >> 'g++'. The g++ compiler is probably where you are getting the >> standard C++ library (libstdc++) requirement from. > > If you ling with g++ it will automatically link against the libstdc++ > dynamically. If you want to link against it statically, you should use > gcc and add the static library explicitely on your commandline. OK. I search for the command to link statically to a particular lib, but I didn't find it. Do you know it ? Great thx. Michaël "Cortex" Monerau. cort at meloo dot com == C++ power ! == ___ 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] SDK line crashing linux servers
At 03:32 PM 6/9/2003 +1200, you wrote:
I'd say the most likely explanation is indeed shimms' and hofer's
conjecture, i.e., that it has not been initialized. There is no serious
compiler that will not follow the left-to-right rule, that's a fairly
integral part of the C++ specification, which is used a lot (it's used
throughout the HL SDK, for example), and certainly they all follow the
correct precedence rules.
Persuter
--
I think it can depend on whether the compiler would use 'full' boolean
logic (where all of a statement is evaluated, even if it's something simple
like 1 && 0), or 'short circuit' (where the code will not evaluate further
if it's obvious what the result will be, like 0 || 0) logic... I know
Delphi (Object Pascal) can use either one, I'm sure C++ ones can too.
As for sticking to a standard, since when has MS started doing that?
Sigh...
C++ uses lazy ("short circuit"), left-to-right evaluation. All serious C++
compilers follow that. Seriously, I can't believe none of you have noticed
this, it is used quite a bit in the HL SDK.
By the way, 0 || 0 is not amenable to short circuit evaluation, since the
first one is not true. I think you meant 0 && 0. And obviously if you
actually put 1 || 0 the compiler will go ahead and evaluate that at
compile-time to true.
Persuter
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SDK line crashing linux servers
--
[ Picked text/plain from multipart/alternative ]
At 06:01 PM 6/8/2003 -0400, you wrote:
>On Sat, Jun 07, 2003 at 12:22:19PM -0700, James Couzens wrote:
>
>> Why does this logic crash a linux dedicated server?
>>
>
>I'm assuming you're using MSVC on windows.
I'm not quite sure that's a safe assumption.
> If so, MSVC does not
>evaluate boolean expressions according to the ANSI standard. The correct
>way to do what you want is:
>
>if( (!pPlayer) || !pPlayer -> IsNetClient())
This is blatantly not true. I just checked it. Cmon, do you really think MSVC would
have screwed up the PRECEDENCE rules?
CBP* pPlayer = NULL;
if( !pPlayer || !pPlayer->IsNetClient() )
{
printf( "MS can write a compiler!\n" );
}
Compiles and prints out the statement, as it should.
I'd say the most likely explanation is indeed shimms' and hofer's conjecture, i.e.,
that it has not been initialized. There is no serious compiler that will not follow
the left-to-right rule, that's a fairly integral part of the C++ specification, which
is used a lot (it's used throughout the HL SDK, for example), and certainly they all
follow the correct precedence rules.
Persuter
--
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SDK line crashing linux servers
No, the C++ specification is such that it always evaluates conditions in a
lazy manner from left to right.
Persuter
At 11:51 PM 6/8/2003 +0200, you wrote:
You cannot assume that it is not evaluated. Maybe the compiler compiles the
code is such a way both get checked anyways. Or maybe the compiler copiles
it so the second statement gets checked first. You -never- know for sure, so
you should be explicit about it. I would do it this way (please note I use
NULL instead of using !, because strictly taken, you should always check
pointers with NULL. I think gcc even complains about it.)
if (pPlayer == NULL)
{
// Do the code
}
else
{
if (!pPlayer->IsNetClient())
{
// Do the code here too
}
}
This structure is a bit odd, beacouse you have the code twice. So you should
use a function there. If you want to avoid using a function, just figure out
a different way to write the check (there always is a way to do it). Just
make sure you never try "pPlayer->IsNetClient()" if pPlayer is NULL.
Jeroen "ShadowLord" Bogers
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SDK line crashing linux servers
If pPlayer is NULL, then !pPlayer will return true, in which case the second part of the or statement will not get evaluated, so that's not the problem. Persuter At 10:02 PM 6/8/2003 +0200, you wrote: hmm, if pPlayer = NULL then you can´t do pPlayer->IsNetClient().. - Original Message - From: "James Couzens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 07, 2003 9:22 PM Subject: [hlcoders] SDK line crashing linux servers > if (!pPlayer || !pPlayer->IsNetClient()) > > Why does this logic crash a linux dedicated server? > > Cheers, > > James > > --- > James Couzens > ClanMod Dev Team > WWW: http://unitedadmins.com/clanmod.php > UA LISTS: http://list.unitedadmins.com/mailman/listinfo > > ___ > 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] c++ vs. scripts
Yeah, this is what I've been saying too. There's a time and a place for scripting languages. Like, scripting languages for use by mappers to create cool far-ranging effects, that type of thing. For main logic use, however, it seems pointless. Any scripting language complex enough to use would be just as complex as a normal programming language, with the detriment of no one knowing it. Persuter At 10:09 PM 5/27/2003 -0700, you wrote: Scripting languages belong OUTSIDE of hlds. Take for example halfd, written in TCL (a scripting language). Wonderful tool for hlds_l admins. It remains outside of hlds as a wrapper that intercepts console and interacts to whats going on in hlds from outside of the binary executable. If we are going to have a big debate over what should and shouldn't be in hl2 it would be more productive to discuss a better api for interacting with hlds from outside the engine AND mod. The current hlds server protocol (for queries) is crap, imho. A lesson could be learned from Halfd and its "newapi" protocol. yes I probably am biased since I helped come up with the protocol but it's not exactly new thinking. tab delimited is a widely used format. For what it's worth, I believe in using the best language for the job. Sometimes I find scripting languages to be best, sometimes I find C/C++ best for the project at hand. Ok so I didn't add much to this discussion. But I would like to see the hlds query (aka server protocol) api discussed. I hope Valve will make serious changes to it prior to coming up with a formal SDK for hl2. -- ab. Brian A. Stummd88b. [EMAIL PROTECTED] 8P"YP"Y88 http://www.bs-linux.com 8|o||o|88 The Choice of a Gnu Generation8'.88 8`._.' Y8. # d/ `8b. ### .dP . Y8b. ## # d8:' " `::88b. ## ### ### ### ### ### ### ### d8" `Y88b ## # ## ### ## #### ## ## :8P ' :888 ## # ## #### #### ### 8a.: _a88P ##### #### #### ###._/"Yaa_ :.| 88P| ## # ####### ###### ## \YP" `| 8P `. #### ### # #### ### ### ## ## / \._.d|.' # ### ### ### ### ### `--..__)88P`._.' ___ 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] new to the list
sluggo and I were going to do something like this recently, he put a Doxygenated SDK up on his site, but it really never materialized. I don't think it would take that long to highlight the important features, i.e., flesh out stuff like CBasePlayer, leave things like CAGrunt and the like for more energetic people. Certainly there is much duplication of effort in everyone relearning things. Persuter At 07:20 AM 3/31/2003 -0600, you wrote: > Have a good look at botman's article at > http://www.planethalflife.com/botman/MOD_FAQ.shtml > > A thousand links there. It's too bad that no MOD coder has taken the time to more fully document the SDK functions (basics about what they do, etc.). There's some good information on the SDK/engine interface at the www.metamod.org website. Also, you could try running Doxygen (www.doxygen.org) on the SDK to get a list of functions and parameters (with no description of what it does, of course). Other than following the hundreds of Half-Life coding tutorials out there, I think the way that everyone learns the SDK is by reading the source code and asking questions in forums (like theWavelength.net). At one point a year or so ago, I had considered sitting down for a few months and completely documenting everything that I know about the SDK (more server side stuff than client side stuff). At the time I thought it would be a wasted effort since TF2 was SURE to come out within a year or so and I was expecting the TF2 engine and interface to be radically different. I've seen several people attempt to create websites where everyone would work together to document the Half-Life SDK and submit lots of tutorials. Of course, this never happened. People were too busy learning stuff to create tutorials for everyone else and other people just lost interest and moved on to other games and engines. I guess it just boils down to the fact that is you are REALLY serious about developing a Half-Life MOD, you will learn the SDK source code mostly on your own an and will dedicate whatever time it takes to learn it (even though the game is over 4 years old). 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] How do i get my mod registered?
I think he's talking about, like, that thing where it claims that it can download a mod from the Internet in Half-Life. Anyway, 007, I don't think anyone does that anymore. Persuter At 12:56 PM 3/24/2003 +1100, you wrote: Register a mod? But apart from that, 10 days isn't that long to be waiting mate, the people at Valve are pretty busy, patience is a virtue. Shimms -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [LMS]007 Sent: Monday, March 24, 2003 12:53 PM To: [EMAIL PROTECTED] Subject: [hlcoders] How do i get my mod registered? I follwed the steps, emailed [EMAIL PROTECTED] more then once, and i have not got anything back. I have servers running my unregistered mod and im uhappy with the lack of consideration for emails requesting a registration. Its been 10 days since i requested. Do i have to drive over the kirkland and pound in some heads? bellevue is not that far, i'll do it! lol Help me out guys ___ 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] External Program?
Try checking out Botman's HPB bot and Beej's Guide to Network Programming (google for them). Persuter At 08:55 PM 3/4/2003 +0100, you wrote: Exactly: I would like to use as you say the " (such as socket communication, named pipes, etc.), " and i would like to comunicate with the client.dll and i really need a good tutorial to start :) my project is to use the client.dll and add a IRCbot that will act like a real player and will be controled over IRC ;) so if som1 got a good link/sourcode commented/tutorial it will be pleasure for me to read it :) Best Regards David. >Messsage du 04/03/2003 20:46 >De : <[EMAIL PROTECTED]> >A : <[EMAIL PROTECTED]> >Copie à : >Objet : Re: [hlcoders] External Program? > > Well, do you want to do this with a specially modified hl.dll, or do you > want to use something like metamod, i.e., something that can go "on top of" > already existing mods? Either way, you need to look into interprocess > communication (such as socket communication, named pipes, etc.), so that > you can communicate with either the game dll or a metamod-type dll. > > Persuter > > At 08:43 PM 3/4/2003 +0100, you wrote: > >First of all thx for the answer ! > >Here is my real question i will try to change it :) > >Q: I looked many forums/newsgroups about the Hl programming client/server > >side and i looked the metamod too but its not my real question, My > >question is: I would like to create a EXTERNAL (No depending the > >HAlf-life) program that will allow me to print a message to the Hl/HL mod > >console, some ppl are talking about the "DLL injection method" and Som1 > >ppl talk about the client.dll call fonctions i really don't know what they > >meen and i would like to find a good example/tutorial/source code that > >will let me to simply : When i execute the 'Myprogram.exe' it prints on > >the HL/HL mod console "Hello" :), I got the sdk2.3 and vc++ 6.0 and Dev > >c++ 4.x and gcc under linux, and no i don't want to execute commands with > >rcon :) > >Best Regards > >David. > > > > > > > > >Messsage du 04/03/2003 20:16 > > >De : <[EMAIL PROTECTED]> > > >A : <[EMAIL PROTECTED]> > > >Copie à : > > >Objet : Re: [hlcoders] External Program? > > > > > > > Hi all, i am new to this 'list' > > > > i would like to have some informations about the communication with HL > > > > engine > > > > Example: i would like to create a little win32 console application that > > > will > > > > send to the halflife engine sometext to the console when it will be > > > > executed, is it possible ? > > > > > > That depends. Do you want to execute the command using 'rcon' (and you > > know > > > the rcon password on the server)? Or do you just want to execute arbitrary > > > commands on any ol' server? > > > > > > If you want to execute rcon commands, see the 'server protocol.txt' file in > > > the 'Server Info' folder of the large SDK (not the source code only one). > > > > > > You can download the SDK from VERC... > > > > > > http://dev.valve-erc.com/?go=hlsdk > > > > > > If you are trying to just arbitrarily execute commands on any ol' > > server, it > > > can't be done (since it's a security problem). > > > > > > 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 > > ___ 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] External Program?
Well, do you want to do this with a specially modified hl.dll, or do you want to use something like metamod, i.e., something that can go "on top of" already existing mods? Either way, you need to look into interprocess communication (such as socket communication, named pipes, etc.), so that you can communicate with either the game dll or a metamod-type dll. Persuter At 08:43 PM 3/4/2003 +0100, you wrote: First of all thx for the answer ! Here is my real question i will try to change it :) Q: I looked many forums/newsgroups about the Hl programming client/server side and i looked the metamod too but its not my real question, My question is: I would like to create a EXTERNAL (No depending the HAlf-life) program that will allow me to print a message to the Hl/HL mod console, some ppl are talking about the "DLL injection method" and Som1 ppl talk about the client.dll call fonctions i really don't know what they meen and i would like to find a good example/tutorial/source code that will let me to simply : When i execute the 'Myprogram.exe' it prints on the HL/HL mod console "Hello" :), I got the sdk2.3 and vc++ 6.0 and Dev c++ 4.x and gcc under linux, and no i don't want to execute commands with rcon :) Best Regards David. >Messsage du 04/03/2003 20:16 >De : <[EMAIL PROTECTED]> >A : <[EMAIL PROTECTED]> >Copie à : >Objet : Re: [hlcoders] External Program? > > > Hi all, i am new to this 'list' > > i would like to have some informations about the communication with HL > > engine > > Example: i would like to create a little win32 console application that > will > > send to the halflife engine sometext to the console when it will be > > executed, is it possible ? > > That depends. Do you want to execute the command using 'rcon' (and you know > the rcon password on the server)? Or do you just want to execute arbitrary > commands on any ol' server? > > If you want to execute rcon commands, see the 'server protocol.txt' file in > the 'Server Info' folder of the large SDK (not the source code only one). > > You can download the SDK from VERC... > > http://dev.valve-erc.com/?go=hl_sdk > > If you are trying to just arbitrarily execute commands on any ol' server, it > can't be done (since it's a security problem). > > 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] Triggering a door from the client
If you're not using one, you could set one of the iusers to it, I think. Persuter At 10:01 PM 2/2/2003 +1100, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi all, Just after some conceptual help here on how you'd go about triggering an entity (in most if not all instances a door) to open from the client side. I'm recoding the func_door to open a VGUI menu for the user to enter a pin code. If the pin is correct the door should open if not then it should remain closed. Ideally this should be able to be done so that the player can't emulate it via console commands etc. Anyway, looking forward to your ideas, Thanks, Michael Shimmins <mailto:[EMAIL PROTECTED]> Sesechial Software ___ Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments, check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of Sesechial Software. -- ___ 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] Models and memory management
I believe the specific deal was three souls (Newell, Bernier, and Birdwell)
in return for the most successful singleplayer and multiplayer
first-person-shooter ever. But this is just what my demonic contacts tell
me, and they're notorious liars.
Persuter
At 01:40 PM 1/28/2003 -0600, you wrote:
> I have added the code for usehunk==5 :) Note the comment ;)
>
>
> else if (usehunk == 5)
> {
> buf = (byte *)Mem_Malloc(len + 1); // YWB: FIXME, this is evil.
> }
That brings up an interesting point. Have you ever noticed how much "evil"
is in the Half-Life source code?
There's "the most hacked, evil, bastardized thing" kjb has ever seen.
There's the EvilImpulse101. There's "see no evil if prisoner is set".
There's "I'm not following you, you evil person!!!", and the "// this is
evil" comment in a couple of places.
So what's the deal with Valve and Evil? :)
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] [hlcoders]different bipeds for player models
I believe they all must be the same as player.mdl in the models directory. Persuter At 04:40 PM 1/21/2003 +, you wrote: Hi, Is it possible to use different bipeds for different player classes or do they all have to go off whatever has been SET_MODEL'd for anims,biped,collision boxes? 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] Profiling server & client dlls
I sent this in PM but just in case anyone else is interested in the answer: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_profiling_dlls_from_a_batch_file.asp (Note that you can't do this if the DLL is loaded, freed, and then loaded again. I'm not sure if HL does this or not.) Persuter At 05:09 PM 12/12/2002 -0500, you wrote: Does anybody know of a way to profile the server and client dlls? Ive tried both vTune and MS's profilers, but neither work without the ability to compile the hl engine in profile, so I have the files (for which I cant remember the name of at the moment) to allow the profile to even run. I really need to profile these dlls to find the major choke points so I can speed everything up a lot more, but I can't seem to figure out a way to do so. Has anybody (who doesn't have access to the engine of course) been able to successfully profile these dlls recently? I've noticed some major slow down with my particle engine (which runs like a hot knife through butter on its own, and in the quake engine itself when I was playing with a quake derivative engine a couple months ago) but it seems to just choke inside the client dll. (and I'm not using tri-api for it either, opengl mode is actually using straight opengl, software/d3d use standard hl efx api effects, to retain speed, and give opengl the extra boost of quality) There are other anomalies too, on the server that I wish to rectify. If anyone can give any assistance on this matter, I'll be kissing your feet =) (well, maybe I'll get someone else to kiss your feet, but someone will =D ) -omega Blackened Interactive - http://blackened-interactive.com Front Line Force - http://www.flfmod.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] [hlcoders]
Might want to try (CBasePlayer*)(CBasePlayer::Instance( pevAttacker )) instead.
Persuter
At 09:01 PM 12/11/2002 +00-03, you wrote:
I'd been working on coding out a money system for a while now, and recently
began work on having monsters give you money everytime you kill them. This
is where I'm having troubles. Botman suggested the following in
CBaseMonster::Killed in combat.cpp
CBasePlayer *pPlayer = GetClassPtr((CBasePlayer *)pevAttacker);
// is it a player (and not a grenade, hornet, rocket, etc.)?
if (pPlayer->IsPlayer())
{
pPlayer->m_Money += m_MosterMoneyValue;
}
In my mind, I thought this would work, I've tried it though and I find that
pPlayer isn't referencing the player properly, and therefore m_Money (which
exists in player.h under class CBasePlayer : public CBaseMonster), stays at
zero (I've used alert (at_console) in my code to check this). Any ideas
anyone?
___
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] Saving Variables
So far as I know, all you must do is go to the top of player.cpp and add it to the list of m_playerSaveData[] via DEFINE_FIELD. Should be fairly straightforward. Persuter At 07:56 PM 12/10/2002 +00-03, you wrote: I've got a variable defind in player.h, in class CBasePlayer : public CBaseMonster Any idea how I'd get the game to save that variable when I save/load ? ___ 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] a couple of issues
I think the brute force polling method would work fine, actually. Just keep a list of which indexes of players are connected, then check them every couple of seconds and do what you need to do, unless it needs to come RIGHT after they disconnect. Even then, checking a bunch of indexes every frame is hardly going to be much, since presumably people aren't going to be getting disconnected en masse. Persuter At 10:07 AM 12/10/2002 -0800, you wrote: I haven't found a way to detect drops from the server using the SDK either (any elegant way that is, where it tells you). You could try the brute force polling method :) omega wrote: Grah! I meant while its connected! Oops, I didn't even notice that :( anyway, besides that, the proxy isn't treated like a client, clientconnect etc don't get called for the proxy until the proxy disconnects. Mad weird. And thanks, we miss you =) And clientDisconnect isn't being called when someone goes linkdead and drops :/ -omega Blackened Interactive - http://blackened-interactive.com Front Line Force - http://www.flfmod.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of BigGuy _ Sent: December 10, 2002 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] a couple of issues actually get called when a client disconnects (link death, not actually quitting) ? ie: when it says "so and so dropped". I need to reset ClientDisconnect() in client.cpp is the only disconnect function I remember. It would be nice if edicts were reset/removed sometimes... The other thing, with standard hltv configuration, I sometimes get this spamming into the server; Too many entities in visible packet list. If the proxy is treated like a normal client, you might be able to use ClientConnect() to set a flag that the proxy isn't fully connected, then in ClientPutInServer() set the flag to say the proxy is ready and then in SetupVisibility() you just check the proxy + your flag before letting the proxy see/hear all. -bigguy Good work on FLF omega. _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ 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] What to do when people blatently steal your code?
Ehh, this is the time to just take a deep breath, accept the fact that there are assholes in the world, and move on. :) Persuter At 01:24 PM 12/4/2002 +, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I know this is slightly OT, but ill go on anyway :) I used to code for SvenCoop, www.svencoop.com and made the mp3 player for it, both Sniper and Shimms can vouch for this. Then a coder named Mark joined the team, but was eventually kicked as we suspected he had stolen parts of our code, and he was found to have entered rouge code. Then a few days go, some shots on PHL showed our mp3 player in their mod. We then got into discussions with planet halflife on what to do as we wanted to warn them of mark. Then we found this on their site: Well lately we have been receiving complaints from the Sven Co-Op team saying that we stole their mp3 player code, because Real DM Co-Leader, and lead coder, Mark, was a previous coder for them. While the SC team is claiming we stole the code which was originally written by previous coder, Tom. Mark has told me that he wrote the majority of the code for SC mp3 player, and Tom helped him with it. However, Sven Viking has said otherwise... [...] However, someone from the SC team is also accusing us of stealing other parts of the code for Real DM and that is just pure lies. I don't even consider the mp3 player "Stealing" because Mark wrote the majority of it, however, accusing us of stealing other code just because of an assumption, is not right. The mp3 player was completly written by me ( with advice&help from another1 another ex-coder of svencoop), and its just lying that he claims he wrote it. Anyhow, we are trying to get it sorted, but im not sure there is much we can do, any thing you can think of? --tom -- ___ 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] Re: CRC/checksum on files
The CRC that comes with the HL SDK doesn't seem to have any definition, at least none that I can find. http://www.eskimo.com/~weidai/cryptlib.html is a third-party library you could use to do it, although it's a tad much for what you're looking for, I suspect. Some sample code of CRC generation: http://www.createwindow.com/programming/crc32/ http://www.libpng.org/pub/png/spec/PNG-CRCAppendix.html http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1952.html#sec-8 Persuter At 03:01 PM 12/4/2002 +1300, you wrote: Hi I've been trying to do this for sometime without much luck :\ I would like to read several binary files into the Sparky client hook for TFC and get their CRC values. Then I would like to check the values each file generated against a table of accepted values for that file. If the client is found to have a file that does not match one of the accepted values the hook can take required action. Is this a silly idea? Are there any better methods? I suppose I need to use crc.h that comes with the HL SDK Thanks Michael ___ 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] ERROR: No EXPORT
Paste the definition of your class and the definition of the function (if they're long, just cut out everything except where it actually says void Think( void ) in both cases). Persuter At 12:51 PM 11/19/2002 +, you wrote: >1.) A missing EXPORT macro in the functions declaration.. so it should look >like this in your class declaration: > void EXPORT Think (void); I tried shoving EXPORT on front of everything in sight, the error still shows up. 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] Monster YAW Speeds/Turn Rate
Actually, interesting, I dunno if the two are related, but I was reading some documentation about the OGRE engine today and the guy mentioned the same thing: When you get really high framerates, like 200+, because the computer isn't very good at accurately telling very small amounts of time, it starts to screw the framerate calculations up. Possibly the same thing is going on. Persuter At 10:43 PM 11/9/2002 -0500, you wrote: Actually, you SHOULD want to go by the frametime. I've never seen this thing you report either, on a low end machine, or my current. It's the same as when doing visual effects, ie: with opengl, you want to calculate with the frametime, or else for one person who may get 20fps, things would move slower than a person with 60fps. Frametime is just the amount of time between the last frame, so its always consistent. Ie: if time for one person is 1. in one frame, and 1.1000 in the next, and another person is 1. in one, and 1.0100 in the next, you'd subtract the two and multiply the speed you want to move it so it moves the same distance in the same amount of time. Anyway, as for your turning slower on faster machines, well like caleb said, I've never seen that either. Heh. -omega Blackened Interactive - http://blackened-interactive.com Front Line Force - http://www.flfmod.com -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders-admin@;list.valvesoftware.com] On Behalf Of Sniper Sent: November 9, 2002 8:10 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Monster YAW Speeds/Turn Rate I found out the problem. Their turn rate is based on the server's framerate, yet it doesn't seem to be correct for higher end machines. Since Half-Life was launched when today's low-end machines were high-end, it makes sense that the math for a monster's yaw speed wouldn't be correct. This line right here is the problem (in CBaseMonster::ChangeYaw ): speed = (float)yawSpeed * gpGlobals->frametime * 10; The turn rate for monsters shouldn't adjust to the server's framerate ever... off the top of my head. It wouldn't make sense. I'm not sure if this was updated in newer SDKs, but I'm going to replace frametime with the frametime of a game running at 30fps. I'll see how it works out. -Sniper - Original Message - From: "Caleb 'Ghoul' Delnay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 09, 2002 5:56 PM Subject: Re: [hlcoders] Monster YAW Speeds/Turn Rate > No idea what your talking about. It all looks fine to me. > > > Caleb 'Ghoul' Delnay > Project Leader: Kill Or Be Killed > http://www.llamanade.net/kobk/ > > - Original Message - > From: "Sniper" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, November 09, 2002 11:24 AM > Subject: [hlcoders] Monster YAW Speeds/Turn Rate > > > > There seems to be some sort of problem with a monster's turn rate (yaw > > speed)... On higher end machines/servers, I noticed monsters can react > very > > quickly, yet turning to face their enemy results in an extremely slow turn > > rate. > > > > I'm wondering if a monster's yaw speed is somehow related to the server's > > framerate... similar to Bots and their running speed (earlier version > bots). > > > > On my low end machine, a pentium 2 233mhz with 160mb of ram (yes, > half-life > > runs perfectly fine), monsters would have much more realistic looking turn > > rates. On my high end machine, an AMD AthlonXP 2400+ GeForce4 ti4600 and > > 512mb ram, monsters turn slow. > > > > Any help would be appreciated... Rather confusing. Faster Sven Co-op > servers > > let players strafe around monsters with ease. > > > > -Sniper > > > > ___ > > 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep?
??? vec3_t view_ofs; // eye position How does pev->view_ofs = 0 work? Sounds suspiciously like you just set view_ofs to NULL. Anyway, the difference is three floating-point multiplications. Not a huge problem in a Think function. :) Persuter At 04:44 PM 11/7/2002 -0600, you wrote: HAHA *changes the line in the Firearms code to read: pev->view_ofs = 0; * THANK YOU! -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders-admin@;list.valvesoftware.com] On Behalf Of Oskar 'Zoot' Lindgren Sent: Thursday, November 07, 2002 3:37 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Valve´s programmers need more sleep? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi! I found a funny thing: "pev->view_ofs = pev->view_ofs * 0.0;" from trigger.cpp line 859 It can be done better... and you will get about 0.0008027% higher FPS, i have tested. / A bored Zoot -- ___ 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] Fog in Software Mode?
It would probably be rally slow though, TriAPI slows down like crazy with large additive transparency sprites. Persuter At 12:26 PM 10/28/2002 -0500, you wrote: could you layer colored quads using billboard code? Wouldn't that be faster ? granted it wouldnt be as smooth as GL fog but it'd probably look similar. - Original Message - From: "botman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 11:56 AM Subject: Re: [hlcoders] Fog in Software Mode? > > I have been able to create fog in hardware mode but not software. Has > > anyone been able to create fog (or a resonable facsimilie of it) for the > > software mode? If so, can you send any hints or suggestion on how to do > > it? > > Sprites, lots and lots of sprites (or using Triangle API to draw tiny little > particles, but sprites would probably be faster). > > 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] Problem with client-side events
To follow up:
I used this to fix it:
void CParticleEmitter::Spawn( void )
{
Precache();
}
void CParticleEmitter::Precache( void )
{
m_usStartParticle = PRECACHE_EVENT( 1, "events/particle.sc" );
}
void CParticleEmitter::MakeAware( edict_t* thisedict )
{
PLAYBACK_EVENT_FULL( FEV_HOSTONLY, thisedict, m_usStartParticle,
0.0, (float *)&(pev->origin), (float *)&g_vecZero, 0.0, 0.0, type, 0, 0, 0 );
}
with this in the InitHUD function:
CParticleEmitter* pEntity = NULL;
while( (pEntity = ((CParticleEmitter*)(UTIL_FindEntityByClassname(
pEntity, "func_particle" != NULL )
{
pEntity->MakeAware( pPlayer->edict() );
}
So basically the same sort of thing as you were talking about, but with an
event rather than a message. Not much difference between the two, just
makes it easier to send a vector, really. :) Thanks for the help.
Persuter
At 10:30 AM 10/27/2002 -0500, you wrote:
I think that A is the crux of the thing not working in one sense. If you're
sending a message on the entities' spawn (or playing an event), the event
is sent to clients far before they are in a state to 'play the event'.
Why not cache the values you need from your entity in member variables in
your keyvalue function, and then send them in InitHUD (just search by
classname, and xmit the data to the clients as they connect).
At least anything I've done that involves some map entity that is relevant
to the client (I render mine with yummy triAPI), I took that approach and
once I realised it was probably good to free the memory for it (big oops in
an internal build), it's been flawless.
One message isn't too costly, paticularly if it's just an 'on/off' type
(one byte).
Cheers,
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com
At 08:16 AM 10/27/2002 -0600, you wrote:
Just taking a swing here at this. But 2 problems I see right off with this
system is the fact that
A.) With a entity being in the map (your grate to emit steam) its spawn
function is called generally when the map is still loading (your not in the
map yet). So wouldnt sending a playevent while your not fully in the game,
b\c the server is still loading, pretty much void that call ?
B.) If this is a multiplayer mod then the other clients would not get this
event b\c its only called on map load. So clients connecting after that load
would never get the msg.
Thats the 2 possible problem areas Im seeing right off.
-Brandon "Axis" Russell
Programmer for
Day of Defeat
-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-admin@;list.valvesoftware.com]On Behalf Of Persuter
Sent: Sunday, October 27, 2002 1:25 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Problem with client-side events
Hey folks.
I have a question about client-side events. I'm trying to program something
simple here: an entity that sends a message to the client-side telling it
to start a particle system when it spawns, i.e., a grate from which dynamic
steam emits, or something similar.
I have the following code:
void CParticleEmitter::Spawn( void )
{
Precache();
PLAYBACK_EVENT_FULL( FEV_GLOBAL | FEV_UPDATE, edict(),
m_usStartParticle,
0.0, (float *)&g_vecZero, (float *)&g_vecZero, 0.0, 0.0, type, 0, 0, 0 );
}
void CParticleEmitter::Precache( void )
{
m_usStartParticle = PRECACHE_EVENT( 1, "events/particle.sc" );
}
(type, by the way, is the type of system to add)
Now, this all works fine and dandy, the event gets precached, the playback
function goes through fine, the problem is that on the client side the
corresponding function never gets called. On the client-side dll, I've
added the function declaration in both ev_hldm.cpp and hl_events.cpp, and
I've added the HookEvent in hl_events.cpp as well. I dunno, I'm perfectly
able to do weapons but for some reason this one has me at a loss, and the
one client-side non-weapon event in the SDK isn't much help. Am I missing
something required in the spawn function or on the client side that is
simply part of the weapons code?
Thanks for any help.
Persuter
___
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
[hlcoders] Problem with client-side events
Hey folks.
I have a question about client-side events. I'm trying to program something
simple here: an entity that sends a message to the client-side telling it
to start a particle system when it spawns, i.e., a grate from which dynamic
steam emits, or something similar.
I have the following code:
void CParticleEmitter::Spawn( void )
{
Precache();
PLAYBACK_EVENT_FULL( FEV_GLOBAL | FEV_UPDATE, edict(), m_usStartParticle,
0.0, (float *)&g_vecZero, (float *)&g_vecZero, 0.0, 0.0, type, 0, 0, 0 );
}
void CParticleEmitter::Precache( void )
{
m_usStartParticle = PRECACHE_EVENT( 1, "events/particle.sc" );
}
(type, by the way, is the type of system to add)
Now, this all works fine and dandy, the event gets precached, the playback
function goes through fine, the problem is that on the client side the
corresponding function never gets called. On the client-side dll, I've
added the function declaration in both ev_hldm.cpp and hl_events.cpp, and
I've added the HookEvent in hl_events.cpp as well. I dunno, I'm perfectly
able to do weapons but for some reason this one has me at a loss, and the
one client-side non-weapon event in the SDK isn't much help. Am I missing
something required in the spawn function or on the client side that is
simply part of the weapons code?
Thanks for any help.
Persuter
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rope attached to NPC?
You might be surprised at what you can get the GPU to do, especially with the newer Cg stuff. But yes, it does seem unlikely that you could do it in Half-Life. :) Persuter At 02:36 AM 10/13/2002 +0100, you wrote: errm.. you cant used the GPU to do the hull colluision stuff :P - Original Message - From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 13, 2002 1:25 AM Subject: Re: [hlcoders] Rope attached to NPC? > Use the GPU, n00b... =P > - Original Message - > From: "Phantom" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, October 13, 2002 12:35 AM > Subject: Re: [hlcoders] Rope attached to NPC? > > > > errm... because althought the GF4 will do a nice job at rendering the > thing, > > all those colluision calcs. are happening on the CPU, so regardless of it > > you have a GF4 or an orignal GF, your gonna get the same performance hit > > from the calcs. > > > > - Original Message - > > From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, October 12, 2002 10:50 PM > > Subject: Re: [hlcoders] Rope attached to NPC? > > > > > > > Why make it so hard? Just buy a GF4 4600TI... it makes you work > faster > > > =P > > > - Original Message - > > > From: "Persuter" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Saturday, October 12, 2002 11:28 PM > > > Subject: Re: [hlcoders] Rope attached to NPC? > > > > > > > > > > /me blinks. > > > > > > > > I'd call Eidos Interactive and see if you can buy the rights to their > > > > Glacier engine. > > > > > > > > Basically, I think most of the stuff will have to be hand-done, and I > > > think > > > > it will be very difficult. You can detect collisions between the rope > > and > > > > the objects in a map with a simple traceline, but I don't think you'll > > be > > > > able to bend it properly around anything, without some major > performance > > > > hits. You can definitely create and draw the rope entity in both taut > > and > > > > loose states with a little physics simulation and some TriAPI work. On > > the > > > > HUD side, I wouldn't even really bother doing the hand gripping the > > rope, > > > > I'd simply have it coming out. If you must do it like that, use > > > > V_CalcGunAngle in view.cpp, I believe, to control the angle at which > > your > > > > model is positioned, that way you can accurately simulate the rope > going > > > > back and forth. > > > > > > > > However, in general, it would probably be a better idea to do it with > a > > > > less static method, i.e., something more like a tractor beam rather > than > > a > > > > rope. That would be far simpler with the same effect on gameplay. > > > > > > > > Sorry to be a pessimist, but I just doubt that the rope thing will > work > > > out > > > > that well. Actually, thinking about it a little more, if you treat the > > > rope > > > > as a bunch of short segments, kinda like those hard plastic jumpropes, > > and > > > > then hard-lock the beginning of each segment to the end of the last > one, > > > > and use TraceHull to prevent the rope from going through anything, you > > > > might be able to do it the way you're talking about, but that's some > > > > serious tracing, and it will probably take up a lot of CPU cycles. > > > > > > > > Persuter > > > > > > > > At 03:45 PM 10/12/2002 -0400, you wrote: > > > > >This is a multi-part message in MIME format. > > > > >-- > > > > >[ Picked text/plain from multipart/alternative ] > > > > >Let's say in my game I want the player to be able to "lasso" an NPC, > > and > > > > >have the attachment be persistent. That is, once roped, the NPC > cannot > > > > >get free of the rope until the player let's go. For argument's sake > > > > >imagine the rope is around the NPC's waist, once attached. I know > > that: > > > > > > > > > >- I'll need a HUD animation to show the player's hand gripping the > > rope. > > > > >- When
Re: [hlcoders] Rope attached to NPC?
/me blinks. I'd call Eidos Interactive and see if you can buy the rights to their Glacier engine. Basically, I think most of the stuff will have to be hand-done, and I think it will be very difficult. You can detect collisions between the rope and the objects in a map with a simple traceline, but I don't think you'll be able to bend it properly around anything, without some major performance hits. You can definitely create and draw the rope entity in both taut and loose states with a little physics simulation and some TriAPI work. On the HUD side, I wouldn't even really bother doing the hand gripping the rope, I'd simply have it coming out. If you must do it like that, use V_CalcGunAngle in view.cpp, I believe, to control the angle at which your model is positioned, that way you can accurately simulate the rope going back and forth. However, in general, it would probably be a better idea to do it with a less static method, i.e., something more like a tractor beam rather than a rope. That would be far simpler with the same effect on gameplay. Sorry to be a pessimist, but I just doubt that the rope thing will work out that well. Actually, thinking about it a little more, if you treat the rope as a bunch of short segments, kinda like those hard plastic jumpropes, and then hard-lock the beginning of each segment to the end of the last one, and use TraceHull to prevent the rope from going through anything, you might be able to do it the way you're talking about, but that's some serious tracing, and it will probably take up a lot of CPU cycles. Persuter At 03:45 PM 10/12/2002 -0400, you wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Let's say in my game I want the player to be able to "lasso" an NPC, and have the attachment be persistent. That is, once roped, the NPC cannot get free of the rope until the player let's go. For argument's sake imagine the rope is around the NPC's waist, once attached. I know that: - I'll need a HUD animation to show the player's hand gripping the rope. - When the NPC tries to run away or move closer to the player, I'll have to change the rope entity to make it look loose or drawn taut. In addition, I assume that in the NPC think code I'll have to check for the rope being attached, and, if as the NPC I'm at the end of the rope, to halt my movement, to simulate the rope preventing my walking or running away. My main questions are: How do I create and draw the rope entity? Is there a convenient way to show the rope in a taut and "loose" state? Also is there any way I could detect collisions between the rope and objects in the map, so I could bend it properly around an intervening tree for example, or will that be too huge a headache to bother with? Lastly, how will I position or draw each end of the rope so it that the NPC-end looks like its realistically wrapped around the waist of the NPC, and the player-end is gripped realistically by the player's hand in the HUD animation? If anyone has a good idea/strategy or sample/example on how to make this happen I'd love to hear about it. Details please. Thanks. -- ___ 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] Half-life SDK v2.3
Nope, doesn't work for me or icewolf. And I'm sure I'm typing in the right one because it does something different than when you type in a wrong one. In IE, it says Error: opener.location is not an object, and then takes you to cgi-bin/login.pl which tries to close your window. Persuter At 07:10 PM 10/3/2002 -0700, you wrote: >In the past, we've released the "Full SDK" (which included the AI/monster >source for single-player) and the "Standard SDK" (which did not include the >AI/monster source). Now there will just be one SDK and it will include >folders called "Single-Player Source" and "Multiplayer Source". These >folders are the same, with the exception of the AI/monster source in the >"Single-Player Source" folder. > >Most of the bugs that were fixed have been mentioned on this mailing list at >some point since the last SDK release. I don't have a list right now. The >main bug I remember is the gauss fix (client prediction problem). > >The login is case sensitive, so make sure you're entering the information >correctly. I just tested it again and it appears to be working okay. > >-Eric > >-Original Message- >From: Persuter [mailto:[EMAIL PROTECTED]] >Sent: Thursday, October 03, 2002 6:15 PM >To: [EMAIL PROTECTED] >Subject: Re: [hlcoders] Half-life SDK v2.3 > >I have a question. What does it mean that the source code for both >single-player and multiplayer mods will be included in the same installer? >Weren't they always, or are you simply discontinuing the "Standard" SDK? > >Also, is there a list of these bugs? > >And finally, I can't log in to the server. :) > >Persuter >___ >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] Half-life SDK v2.3
Sorry to spam, but I meant list of these bug FIXES, just in case that wasn't clear. Persuter At 09:15 PM 10/3/2002 -0400, you wrote: >I have a question. What does it mean that the source code for both >single-player and multiplayer mods will be included in the same installer? >Weren't they always, or are you simply discontinuing the "Standard" SDK? > >Also, is there a list of these bugs? > >And finally, I can't log in to the server. :) > >Persuter > >At 06:04 PM 10/3/2002 -0700, you wrote: >>We're ready to release version 2.3 of the Half-Life SDK. This latest >>version of the Half-Life SDK changes format from previous versions. >>Starting with version 2.3, the source code for both single-player and >>multiplayer mods will be included in the same installer. >> >>Version 2.3 of the Half-Life SDK features the following items: >> >>* Updated single-player and multiplayer source >> - Ricochet source (w/multi-serve technology) >> - New spectator features included with the 1.1.1.0 release >> - New interface >> - First-person mode >> - Bug Fixes >>* Updated server protocol information >>* Valve Hammer Editor v3.4 >>* Missing cinematic files from v2.2 release >> >>You can download version 2.3 from the Valve File Depot: >> >>http://files.valve-erc.com/ >>login: hl_sdk >> pass: hl_sdk >> >>Half-Life SDK v2.3 Full Installation >>4a4adf8dc28a352d668df18f1488fa0bhl_sdk_v23.exe >> >>Half-Life SDK v2.3 Source-Only Installation >>2d9241ed096d25ea3b9468c1e775d964hl_sdk_v23_source.exe >> >>Let me know if you have any questions about this latest version of the >>Half-Life SDK. >> >>Eric Smith >>VALVe >>___ >>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] Half-life SDK v2.3
I have a question. What does it mean that the source code for both single-player and multiplayer mods will be included in the same installer? Weren't they always, or are you simply discontinuing the "Standard" SDK? Also, is there a list of these bugs? And finally, I can't log in to the server. :) Persuter At 06:04 PM 10/3/2002 -0700, you wrote: >We're ready to release version 2.3 of the Half-Life SDK. This latest >version of the Half-Life SDK changes format from previous versions. >Starting with version 2.3, the source code for both single-player and >multiplayer mods will be included in the same installer. > >Version 2.3 of the Half-Life SDK features the following items: > >* Updated single-player and multiplayer source > - Ricochet source (w/multi-serve technology) > - New spectator features included with the 1.1.1.0 release > - New interface > - First-person mode > - Bug Fixes >* Updated server protocol information >* Valve Hammer Editor v3.4 >* Missing cinematic files from v2.2 release > >You can download version 2.3 from the Valve File Depot: > >http://files.valve-erc.com/ >login: hl_sdk > pass: hl_sdk > >Half-Life SDK v2.3 Full Installation >4a4adf8dc28a352d668df18f1488fa0bhl_sdk_v23.exe > >Half-Life SDK v2.3 Source-Only Installation >2d9241ed096d25ea3b9468c1e775d964hl_sdk_v23_source.exe > >Let me know if you have any questions about this latest version of the >Half-Life SDK. > >Eric Smith >VALVe >___ >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] Messing with vis
/me continues the conversation with self. OK, the answer to this is yes, the engine will bork. Just in case you guys were curious. :) And I downloaded the source code for ZHLT with Merl's additions, so I'm looking at the g_maxdistance thing, but I'm still looking for, you know, some help. :) Persuter At 10:17 PM 9/28/2002 -0400, you wrote: >Also, if I go into bspfile.h and change the MAX_MAP_ENTITIES and whatnot, >is it to be presumed that that would have no effect, as the engine simply >would not accept those bsp files? I.e., if I run into a 4096 brush limit or >a 1024 entity limit, and I adjust those values upwards, recompile the >tools, and compile the map, would the engine bork on those maps? > >Persuter > >___ >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] Messing with vis
Also, if I go into bspfile.h and change the MAX_MAP_ENTITIES and whatnot, is it to be presumed that that would have no effect, as the engine simply would not accept those bsp files? I.e., if I run into a 4096 brush limit or a 1024 entity limit, and I adjust those values upwards, recompile the tools, and compile the map, would the engine bork on those maps? Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Messing with vis
Hey everyone, I had a quick question. I'm working on a 3rd person mod that has a relatively high camera. Thus, a player can never see more than, say, a few hundred units to his sides. I wanted to mess with vis so that we might take greater advantage of this, by declaring, for example, that a portal that is far away from another portal isn't visible, even though in the first person sense it may well be. However, as you might know, vis is rather confusing, alarming, and intimidating to people looking at it for the first time. My first intuition from checking out the code is that I should be looking in PortalFlow, but I'm really not sure. Can anyone with some experience with such things (such as if zoner's on this list :) give me a few pointers on where I should be looking for this stuff? Also, should I be looking at qbsp as well, to try to change the bsp to reflect our restricted viewing as well? Thanks, Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Particle System
Jim: yeah, that's what I said earlier. The benefit of using arrays lies in the fact that they're sequential and initialized early, so no memory allocation time. But as you so correctly pointed out, the problem of figuring out the most efficient use of space within the array is not simple. Anyway, I think we're all forgetting the 80-20 rule here. 80% of processing time is taken up by 20% of the program. I seriously doubt, based on my observations, that at reasonable amounts of particles, a carefully-programmed particle system using linked lists is in that 20%. Also, consider this. If you initialize a long linked list at the beginning of the program and create all the individual rendering lists from that, you get most of the advantages of sequentiality without the staticness of arrays, since malloc or new will allocate sequential memory. You can grow the list at any time, and you can shrink it within the program if memory limits start to be reached. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Jim Hunter > Sent: Thursday, June 27, 2002 11:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Particle System > > > Sure, having the ability to create a *variable* number of particles is a > > plus by using a linked list over an array. Why have 20,000 dormant > > classes/structures taking up memory when you don't have to? How about > > allocating new particles? Are you supposed to scan through the entire > array > > each time you wish to create a new particle to find that indexes 919 and > > 9294-12300 are free? By using a linked list, you can simply store a > pointer > > to the last particle and then add on to it as necessary. > > Forgive my ignorance, but aren't you just shifting that burden (of finding > empty space to store a new particle) from your own code to the heap > manager? > I have no idea which would be more efficient, but either way, *something* > has got to look for storage space and determine that it's unused, and > reclaim space that is no longer used. I would bet the performance would > be > close to equal; anyone know if a formal analysis of such a problem has > been > done? Just curious. > > Jim > > ___ > 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] Moving large amounts of data from client to server
I have considered it. Two problems: One is, I'm not quite sure how to get the IP of the client from the server, or vice versa for that matter. Secondly, I don't know UNIX sockets that well, and I'd have to port it over for the Linux dedicated server. But it's something I've considered. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Jim Hunter > Sent: Thursday, June 27, 2002 11:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Moving large amounts of data from client to server > > I hesitate to even suggest this, since my ignorance of networking is truly > astronomical. But this just occurred to me, so I throw it out for what > it's > worth. How difficult would it be to establish a separate TCP connection > from client to server (over a different port, I guess)? Then you could > send > whatever you want. > > Feel free to flame if this is a stupid idea. > > Jim > > > > ___ > 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] Moving large amounts of data from client to server
Lol, yeah, again... a big mess. :) But it's looking like I might have to do just that. Any ideas? Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Jim Hunter > Sent: Thursday, June 27, 2002 11:20 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Moving large amounts of data from client to server > > Resending this since I sent it from the wrong account before and it > bounced. > > > > B) Instead of sending an updatedata command for each field, > encode > > > the data into a big long char stream and send it over. First of all, > > > there are problems with sending encoded chars, specifically the > problem > > > of 0. Obviously I can constrain a short to 255*255, but this is just > > > > You could avoid the 0 problem by using some value (say 1) as a sort of > > "escape" value, which would have an additional byte following it to > > designate whether it represents 0 (say 0x02) or 1 (say 0x01). So > anywhere > > you have 0x00 in your data, you transmit 0x01 0x02 and anywhere you have > > 0x01 in your data you transmit 0x01 0x01. Any other value is > unmodified, > > except 0x00 terminates the string. > > > > There are probably better solutions, though. > > > > Jim > > > > ___ > 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] Particle System
EXACTLY. So quit dissing Percy's poor particle system and answer his OTHER question! /me points frantically. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Miguel Aleman > Sent: Thursday, June 27, 2002 10:34 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Particle System > > Iain, I'm not sure how you interpreted Scott's comment. If he mean what > you > said he could have said something such as "Sorry I cannot be more > detailed, > but I'm too busy to debate..." or "I'm short on time, but in a nutshell my > opinion is...". However, he insisted on saying something much more > abrasive > than was necessary. > > On to the particle engine topic, which is infinitely more interesting... > > Sure, having the ability to create a *variable* number of particles is a > plus by using a linked list over an array. Why have 20,000 dormant > classes/structures taking up memory when you don't have to? How about > allocating new particles? Are you supposed to scan through the entire > array > each time you wish to create a new particle to find that indexes 919 and > 9294-12300 are free? By using a linked list, you can simply store a > pointer > to the last particle and then add on to it as necessary. > > Rendering particles in a linked list would take about the same amount of > time as rending particles in an array. Using the array, you would > increment > the index, test the particle's validity, and then render it. Using the > linked list, you would render the particle, and then render the particle > connected to it until you reach the end of the list. Any speed advantage > would be negligible. > > A possible reason why indexes are used in engines such as Half-Life for > entities are because they are relatively long-life variables. You are > never > going have several thousand entities appear on the screen only to later > have > them disappear in 3/4s of a second. Also, the number of (non-particle) > entities in an entire scene is usually much less than the particles used > in > one effect. Memory for these entities is a much less important > consideration. > > Both methods have their advantages, but my opinion using linked lists for > a > particle engine is much superior than using an array. Variable memory > usage, > speed during allocation, and most importantly, simplicity more than make > up > for the lost speed during deallocation. > > - Original Message - > From: "Iain Farrell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 8:55 PM > Subject: Re: [hlcoders] Particle System > > > > - Original Message - > > From: "Miguel Aleman" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, June 27, 2002 11:04 PM > > Subject: Re: [hlcoders] Particle System > > > > > > Look Scott, if you don't have the time to enter this argument then > simply > > don't. That must of been the most arrogant comment I've heard this week. > > > > -- > > he wasn't trying to be arrogant, he was just saying (basically) "I can't > > argue my point fully, because I am busy with other things (probably > things > > we want him to busy with)" > > His point was simple though - you don;'t need a potentially infinite > number > > of particles, so link lists aren't necessarily the best answer > (especially > > when you may have to take into account slower machines) > > I gather from his post, he's trying to say you should try and estimate > the > > max. number of particles you'll need and use an array for that amount. > > you may be wasting memory, but on slower systems the sped increase may > be > > more beneficial > > > > > > ICQ : available on request > > > > "That's it - screw CNN, from now on - I'm going to rely on Porn sites, > > for news" -=[Clawz]=- in alt.games.half-life > > > > HL Mod Site : http://www.tfhl.net > > AGHL Geek Code: > > 78 M D T+ C- A+ Ca H+ K P S+ B Po* RGB+ I++ L3++ Sp- ICQ@ > > > > > > > > ___ > > 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
[hlcoders] Moving large amounts of data from client to server
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Siiigh, I have SUCH a tendency to put everything in the header. :-) I want to move a chunk of data, about 700 or 800 bytes, though it can probably be compressed down to 400-500 with a good bit of closer inspection of variable types, from the client to the server. My question is, how is something like this done? Some thoughts: A) Create a "updatedata" command with two arguments, one for the name of the field and one for the value of the field. This is simple, but there are about 100 fields, so I worry about message overload. This really isn't the sort of thing that I can amortize, so I'd have to send them all over at once. B) Instead of sending an updatedata command for each field, encode the data into a big long char stream and send it over. First of all, there are problems with sending encoded chars, specifically the problem of 0. Obviously I can constrain a short to 255*255, but this is just nasty, and I don't FEEL like it, damnit. If it's necessary, obviously it'll be done, but I want to try other options. C) I dunno, some sort of file transfer, something. Help me out here. :-) Persuter -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Particle System
Yeah, it boils down to whether it runs fast enough for your application. Static memory allocation is going to be somewhat quicker, but I just CAN'T see the justification, personally. Especially given the HIGHLY variable nature of the beast, in that one minute you might have no particles, the next you might have explosions galore in the middle of a blinding snowstorm. Moreover, it's more difficult to dynamically assign more space to one system with static arrays and maintain the consecutiveness. In fact, in terms of dynamically assigning space, I'm guessing linked lists are going to be faster in most cases, since if you want to maintain consecutive layout, it's time to screw with where everything else is. But the statement "linked lists are too slow" is just hands-down ridiculous. Are they slower than static? Yes. Are they too slow? Absolutely not. Again, my particle system and many others that are based on linked lists run perfectly fine. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Josh Coyne > Sent: Thursday, June 27, 2002 7:11 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Particle System > > well he does have a point. linked lists arent exactly the fastest things > around. They however are easy to implement; so chances of bugs, and > further > yet memory leaks are lower if you understand what the concepts are. In the > end i suppose it just boils down to personal preferences. > > - Original Message - > From: "Miguel Aleman" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 6:04 PM > Subject: Re: [hlcoders] Particle System > > > Look Scott, if you don't have the time to enter this argument then simply > don't. That must of been the most arrogant comment I've heard this week. > > - Original Message - > From: "Scott Velasquez" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 4:31 PM > Subject: RE: [hlcoders] Particle System > > > I don't have the time to get into this argument, but there is a reason > that > games like Half-life\QuakeX prefer static allocation; speed! There is no > reason you need infinite particles. > > Basically this boils down to the good 'ol speed vs. memory argument. > People > have argued this for decades. > > I would, however, argue that linked lists would be the better choice > though > if you were developing on a restrictive platform where memory is limited. > Of course you could just limit the max_particles to a very small size! See > what I mean! ;} > > Scott Velasquez > Programmer > Gearbox Software (www.gearboxsoftware.com) > -- > re.cur.sion n.: See Recursion. > -- > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Miguel Aleman > Sent: Thursday, June 27, 2002 3:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Particle System > > > Linked lists are the best way I know of to do a particle engine. > > You save processor time during allocation of new particles and even more > during deallocation. The ability to have virtually infinite particles is > also a plus. > > - Original Message - > From: "Tom" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 1:56 AM > Subject: Re: [hlcoders] Particle System > > > > linked lists may be to slow for a particle engine > > > > - Original Message - > > From: "Yacketta, Ronald" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, June 27, 2002 12:24 AM > > Subject: RE: [hlcoders] Particle System > > > > > > > I am writing my own :) > > > > > > Just looking to peek at others work to see how things were/are done > and > > > for some ideas. > > > Mine is using STL vice a stock home grown linked list > > > > > > -Ron > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Miguel > > > Aleman > > > Sent: Wednesday, June 26, 2002 7:20 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [hlcoders] Particle System > > > > > > > > > Check out NeHe on gamedev.net (www.gamedev.net/nehe) for a particle > > > system tutorial. Its in OpenGL, but its easy to change to TriAPI. Get > > > comfortable with it and then you can write your own. > > > &g
RE: [hlcoders] Particle System
People keep on saying this. How exactly are linked lists going to be "too slow" for a particle engine? What in the world would you use, arrays? This is exactly the sort of place you should use linked lists. Linked lists are very slow for sorting and searching, due to their sequential nature. However, they are perfect for iterating over a large range of data. I have no sorting or searching, thus I feel that a linked list is really the only option. As long as you make sure that you're careful about allocating memory, you should be fine. My particle engine utilizes two lists per system, one for particles to be displayed and one for trash particles to be reused. Eventually what I might want to do is simply have an engine list for the trash particles, so that all the systems can dip into the same pool. Anyway, though, the current system is plenty fast. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Tom > Sent: Thursday, June 27, 2002 2:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Particle System > > linked lists may be to slow for a particle engine > > - Original Message - > From: "Yacketta, Ronald" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 27, 2002 12:24 AM > Subject: RE: [hlcoders] Particle System > > > > I am writing my own :) > > > > Just looking to peek at others work to see how things were/are done and > > for some ideas. > > Mine is using STL vice a stock home grown linked list > > > > -Ron > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Miguel > > Aleman > > Sent: Wednesday, June 26, 2002 7:20 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [hlcoders] Particle System > > > > > > Check out NeHe on gamedev.net (www.gamedev.net/nehe) for a particle > > system tutorial. Its in OpenGL, but its easy to change to TriAPI. Get > > comfortable with it and then you can write your own. > > > > - Original Message - > > From: "Yacketta, Ronald" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 26, 2002 6:03 PM > > Subject: RE: [hlcoders] Particle System > > > > > > > I was just looking for a working particle system that I could use for > > > ideas and to answer some of my own questions from, I am in no way > > > looking to use someone else's engine. I am in the mist of my own > > > creation and just need something to peek at > > > > > > -Ron > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Persuter > > > Sent: Wednesday, June 26, 2002 5:35 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [hlcoders] Particle System > > > > > > > > > Ron: what exactly is your question? The particle system recently > > > discussed, I believe, was mine, which is available for any mod that > > > wants it. It is currently being used in Quest, Hostile Intent, and > > > something by C4 Software. > > > > > > Persuter > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > > > [EMAIL PROTECTED]] On Behalf Of Yacketta, Ronald > > > > Sent: Tuesday, June 25, 2002 9:25 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [hlcoders] Particle System > > > > > > > > Folks, > > > > > > > > I recall a recent conversation regarding the use / tutorial etc > > > someone > > > > had of a particle system for HL. I went searching my .pst's and > > > > could not find a reference nor in the HL archives. > > > > > > > > Might someone know of a POC (Point Of Contact) for the particle > > > > system > > > > > > > that was discussed? > > > > > > > > Regards, > > > > Ron > > > > ___ > > > > 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/hlcode
RE: [hlcoders] Particle System
Ron: what exactly is your question? The particle system recently discussed, I believe, was mine, which is available for any mod that wants it. It is currently being used in Quest, Hostile Intent, and something by C4 Software. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Yacketta, Ronald > Sent: Tuesday, June 25, 2002 9:25 PM > To: [EMAIL PROTECTED] > Subject: [hlcoders] Particle System > > Folks, > > I recall a recent conversation regarding the use / tutorial etc someone > had of a particle system for HL. I went searching my .pst's and could > not find a reference nor in the HL archives. > > Might someone know of a POC (Point Of Contact) for the particle system > that was discussed? > > Regards, > Ron > ___ > 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] vehicles
By the way, in general the method I've read uses a traceline down from each wheel. Then you simply determine the origins of the four hitpos, create a plane from that, and then get the normal of that plane and stick your car to it. This is, at least, how Midtown Madness 2's creators described their algorithm. As Sebastian said, getting the plane normal of the geometry below you is not sufficient. After you've gotten the correct pitch and roll of your vehicle, you simply set the vehicle at the correct position (I don't think HL's default physics would be capable of handling an angled vehicle, but I dunno). You can also add some think function reinstating gravity if the tracelines go too far down (a la Laverne and Shirley). One question that presents itself to me is that three points are enough to define a plane, which means in turn that having four means you won't always get a plane. I would probably take the back two wheels as a roll reference, then use whichever front wheel had the smallest flFraction as the pitch reference. So, assuming our vectors are in vecWheel[4] going clockwise around the car from the rear left, and the fractions are in the same size array and order, you might want something like the following. Vector right = (vecWheel[3] - vecWheel[0]).Normalize(); If( flFraction[1] < flFraction[2] ) Vector forward = (vecWheel[1] - vecWheel[0]).Normalize(); Else Vector forward = (vecWheel[2] - vecWheel[3]).Normalize(); Vector up = CrossProduct( right, forward ); Then you have the three vectors of the correct vehicle axes. Then the pitch is arcsin(forward[2]), the roll is arcos( up[2] / cos( pitch ) ), and the yaw is arcos( forward[0] / cos( pitch ) ). At least... if my algebra from the AngleVectors function is correct. Anyway, hope that helps. That should get you going up and down hills for sure. I dunno about banking left and right. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of botman > Sent: Friday, June 21, 2002 3:29 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] vehicles > > > I guess you have to do the following: > > Do a traceline straight down to the ground at the front and at the back. > > Then see whether there's any difference in trace length (forget about a > few > > tenths, it's only whole units that make a difference). If there is, use > some > > triangle maths to calculate the angle of the slope. Once you got it, use > > this new angle to correct the vehicle's acceleration. > > The angle of the slope will come from the vecPlaneNormal field of the > UTIL_TraceLine() result. Just shove it into UTIL_VecToAngles() to convert > the > vector normal to an array of angles, then set the body angles of the > vehicle > entity to match. > > 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
[hlcoders] Team Fortress II
I was thinking about this today and I was curious if any Valve programmers (or regular ol non-Valve HL coders) had any information: Is TF2 still coming out? They stopped posting on the official site a year and a half back. Is the project stopped or what? (I know it's not technically a coding discussion (unless of course someone wants to start leaking TF2 source :), but I was just curious. Please don't shoot me or anything.) Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Water Surface Points?
Is water represented by a block or a plane? In the former case, you could get the vertical size and the angle of the bullet and calculate when the bullet would have passed through it. I have no idea, just guessing here. :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Mazor > Sent: Saturday, June 15, 2002 9:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [hlcoders] Water Surface Points? > > That didn't help one bit... > > I don't think you know exactly what I'm tryin to do. I wanna get the > location on the surface of the water where the trace entered it. Tom is > sorta on the right track, but it seems wrather difficult to do. There > isn't an easier way to do it? > > -Mazor > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Michael > Shimmins > Sent: Saturday, June 15, 2002 5:03 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Water Surface Points? > > When you shoot out a trace line you specify how far its going, ie 1000 > units. > > The end point of a traceline is stored in the trace > result's 'flFraction' variable, ie: > > tr.flFraction > > The distance from the player to the surface is found by doing the > following: > > TraceLength * flFraction; > > An flFraction value of .5 means the end point was 50% of the length of > the traceline. > > Be sure to check that it did hit something though, ie: > > if (tr.pHit) // it did hit something. > > Hope this help, > > Michael Shimmins > The Absconder Effect (http://www.tae-mod.com) > > > I'm trying to make a water slash effect for my mod when a bullet > traceline > > goes into a water entity. I'm having a world of trouble finding the > entry > > point of the traceline. Any ideas? Someone said someone asked this > before, > > but I was looking through the archives and was unable to find any > reference > > to this problem. Please help, thanx. > > > > -Mazor > > http://nuke.shiftify.com/ > > > > > > > > "Even in death, feelings carry on; love -- the ultimate power -- will > stay > > within me, as I will stay with thee." > > -Me > > > > > > _ > > Chat with friends online, try MSN Messenger: http://messenger.msn.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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Understanding the AI
The entire schedule system is described here (warning, self-pimpage): http://hlpp.telefragged.com/tuts/ai-description.html Deepflame has an AI tutorial in three parts http://hlpp.telefragged.com/tuts/ai_tut1.htm http://hlpp.telefragged.com/tuts/ai_tut2.htm http://hlpp.telefragged.com/tuts/ai_tut3.htm Shadowman's page in general is great: http://www.planethalflife.com/hlsdk2/ and specifically this page http://www.planethalflife.com/hlsdk2/sdk/understanding_the_monster_ai.ht m Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of botman > Sent: Friday, June 14, 2002 5:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Understanding the AI > > > OK, I'm kind of ashamed to write something like this but here goes. > > > > Can anybody explain the AI for me? Are there any tutorials related to > it? > > It helps to look at the methods (functions) in the CBaseMonster and > CSquadMonster classes (basemonster.h and squadmonster.h). This will give > you an idea of what types of functions the monsters use to do AI stuff. > > The monsters have memory where they set bits based on what they have seen, > heard, smelled, etc. Look for some of the "HasConditions()" code to find > places where the monster AI code checks to see if certain conditions > exist. > The monsters.h file contains the memory bits that are used to handle > movement. The schedule.h file contains memory bits for movement toward > goals or enemies and memory bits for things that the monster wants to > react > to (like sights, sounds, smells, etc.). > > The biggest part in understanding the monster AI is being able to follow > the > schedule information set up for each type of monster. The > AI_BaseNPC_Schedule.cpp file handles much of this AI scheduling. The > schedules are basically a way to create a sequence of events that monsters > will run through as their AI. For example, one of the bullsquid schedules > is to look for headcrabs. When it smells a headcrab, the schedule says > "stop moving, do the I SEE A HEADCRAB DANCE, turn to face the headcrab". > Another schedule says "save the current postion, move next to the > headcrab, > play the eat sequence 3 times, eat the headcrab, return to the previously > saved position". Just look for all of the Task_t and Schedule_t stuff > inside each monster's .cpp file. You might want to walk through each > monster's GetSchedule function with the debugger to trace through the code > that it executes when running the AI schedules. > > 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] Problem with DispatchUserMsg
I'm using windowed mode in regular too. The executable line is the same
whether I'm going to debug or not.
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Cortex
> Sent: Monday, June 10, 2002 5:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Problem with DispatchUserMsg
>
> I have a suggestion for the fact that the game works fine in Debug
mode. I
> assume that you're launching HL in windowed mode to debug your mod.
Then,
> the 320 sprites are used, whereas the 640 ones are used in
non-windowed
> mode. Perhaps it comes from the sprites... I don't know why it could
have
> a
> relation with DispatchUserMsg, but it worth trying to verify your
> sprites/hud.txt.
>
> For the ".sbr ignored" warning message of MSVC, I get the same
messages on
> the "gamerules" files (teamplay_gamerules, singleplay_gamerules,
> multiplay_gamerules, mygamerules, ...). I've taken the decision to
ignore
> them as they ignore my .sbr files :D
>
> - Cortex : HL Albator coder and mapper ( www.hlalbator.fr.st )
> - email : [EMAIL PROTECTED] & ICQ : 71548738
>
> - Original Message -
> From: "Persuter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 10, 2002 2:06 AM
> Subject: RE: [hlcoders] Problem with DispatchUserMsg
>
>
> | Well, here's the WRITE_* bit, but this doesn't actually get called
until
> | quite a bit after it actually spawns, and until well after the game
has
> | actually started, so after the error occurs in singleplayer.
> |
> | MESSAGE_BEGIN( MSG_ALL, gmsgWeather, NULL );
> | WRITE_BYTE( Current );
> | MESSAGE_END();
> |
> | I've tried changing Current to an unsigned char, an int, and a byte,
to
> | no avail. There is an extern int gmsgWeather earlier in the file,
and
> | when I look at it in the debugger, while the rest of the values go
> | completely bonkers (I can't even evaluate local variables anymore in
the
> | MSVC debugger), gmsgWeather is 100.
> |
> | Here are the corresponding defines of gmsgWeather, both in the
normal
> | places that they should be:
> |
> | int gmsgWeather = 0;
> | gmsgWeather = REG_USER_MSG("Weather", -1);
> |
> | Again I don't know for sure that this message is actually the
problem,
> | I'm simply guessing. By the way, there's another odd problem with
this.
> | When I compile and run, the game crashes on singleplayer with the
above
> | message, but if I start it up in debug mode, the game does NOT
crash, it
> | goes right through, just like multiplayer.
> |
> | Also, there's a couple of other odd problems. For example, we have a
> | streetlamp entity that is supposed to display a sprite at the top of
the
> | lamp (a little glow sprite). Instead of each lamp displaying the
sprite,
> | however, one lamp displays ALL the sprites for the entire level.
That
> | is, all the lamps have no sprite except for one which has a major
> | sunburst.
> |
> | Now, more recently, the sunburst has moved to a random BARREL, which
> | isn't even the same ENTITY. At this point, is it fair to say I
should
> | just call shenanigans on the whole thing and start packing the stuff
> | into a new SDK, hoping that I'll get rid of whatever problems there
are?
> | :) This SDK was extensively worked on by a guy who really didn't
> | understand anything about C++, so I'm highly worried that somewhere
> | there's some insane error (or something like a zillion char array),
> | hiding and snickering quietly at me, waiting for me to finally
chance
> | across it.
> |
> | (There is also a problem that occasionally the compiler will throw a
> | warning "Minor error in .sbr
ignored."
> | occasionally.)
> |
> | Anyone who has seen these sorts of problems before, please help!
> |
> | Persuter
> |
> | > -Original Message-
> | > From: [EMAIL PROTECTED] [mailto:hlcoders-
> | > [EMAIL PROTECTED]] On Behalf Of Christopher McArthur
> | > Sent: Sunday, June 09, 2002 1:20 PM
> | > To: [EMAIL PROTECTED]
> | > Subject: Re: [hlcoders] Problem with DispatchUserMsg
> | >
> | > Yeah the problem is your accessing a user msg with the index of
255,
> | when
> | > the max number of user messages
> | > is 128. It seems unlikely that you have too many messages because
then
> | > youd
> | > be falling out on the 128'th youve added and not the 255th, my
guess
> | is
> | > your
> | > using a weird value in the WRITE_MESSAGE macro.
> | >
> | > - Original Message -
> | > From: "Persuter" <[EMAIL PROTECTED]
RE: [hlcoders] Problem with DispatchUserMsg
Well, here's the WRITE_* bit, but this doesn't actually get called until
quite a bit after it actually spawns, and until well after the game has
actually started, so after the error occurs in singleplayer.
MESSAGE_BEGIN( MSG_ALL, gmsgWeather, NULL );
WRITE_BYTE( Current );
MESSAGE_END();
I've tried changing Current to an unsigned char, an int, and a byte, to
no avail. There is an extern int gmsgWeather earlier in the file, and
when I look at it in the debugger, while the rest of the values go
completely bonkers (I can't even evaluate local variables anymore in the
MSVC debugger), gmsgWeather is 100.
Here are the corresponding defines of gmsgWeather, both in the normal
places that they should be:
int gmsgWeather = 0;
gmsgWeather = REG_USER_MSG("Weather", -1);
Again I don't know for sure that this message is actually the problem,
I'm simply guessing. By the way, there's another odd problem with this.
When I compile and run, the game crashes on singleplayer with the above
message, but if I start it up in debug mode, the game does NOT crash, it
goes right through, just like multiplayer.
Also, there's a couple of other odd problems. For example, we have a
streetlamp entity that is supposed to display a sprite at the top of the
lamp (a little glow sprite). Instead of each lamp displaying the sprite,
however, one lamp displays ALL the sprites for the entire level. That
is, all the lamps have no sprite except for one which has a major
sunburst.
Now, more recently, the sunburst has moved to a random BARREL, which
isn't even the same ENTITY. At this point, is it fair to say I should
just call shenanigans on the whole thing and start packing the stuff
into a new SDK, hoping that I'll get rid of whatever problems there are?
:) This SDK was extensively worked on by a guy who really didn't
understand anything about C++, so I'm highly worried that somewhere
there's some insane error (or something like a zillion char array),
hiding and snickering quietly at me, waiting for me to finally chance
across it.
(There is also a problem that occasionally the compiler will throw a
warning "Minor error in .sbr ignored."
occasionally.)
Anyone who has seen these sorts of problems before, please help!
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Christopher McArthur
> Sent: Sunday, June 09, 2002 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Problem with DispatchUserMsg
>
> Yeah the problem is your accessing a user msg with the index of 255,
when
> the max number of user messages
> is 128. It seems unlikely that you have too many messages because then
> youd
> be falling out on the 128'th youve added and not the 255th, my guess
is
> your
> using a weird value in the WRITE_MESSAGE macro.
>
> - Original Message -
> From: "Persuter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, June 09, 2002 9:39 AM
> Subject: [hlcoders] Problem with DispatchUserMsg
>
>
> > OK, it's time for Persuter's bimonthly Puzzle Of The Month! That's
> > right, folks, whoever gives the most correct answer to the following
> > question will receive a valuable nonmonetary prize.
> >
> > Actually, it's not really a question about code so much as a
question
> > about an error. Basically, with seemingly no explanation, our game
has
> > started throwing the following error:
> >
> > Host_Error: DispatchUserMsg: Illegal User Msg 255
> >
> > The interesting part is that it only throws it when we start up a
single
> > player game. When one starts up a multiplayer game it goes through
just
> > fine.
> >
> > What exactly does this error message mean? Does it mean we have too
many
> > user messages (seems quite unlikely)? And why should it start only
when
> > we're starting up a single player game? We have indeed added a
message
> > since the
> >
> > Anyway, I'm basically just looking for a place to start here, since
I'm
> > sort of at a loss for what exactly this error message means. Thanks
in
> > advance, and no doubt I'll figure it out in five minutes and feel
really
> > stupid anyway. :)
> >
> > (During the typing of this message I actually realized I wasn't even
> > copying the client dll to the cl_dlls folder. /me rolls his eyes. :)
> > Still doesn't work in the same way, though.)
> >
> > Persuter
> >
> > ___
> > 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
[hlcoders] Problem with DispatchUserMsg
OK, it's time for Persuter's bimonthly Puzzle Of The Month! That's right, folks, whoever gives the most correct answer to the following question will receive a valuable nonmonetary prize. Actually, it's not really a question about code so much as a question about an error. Basically, with seemingly no explanation, our game has started throwing the following error: Host_Error: DispatchUserMsg: Illegal User Msg 255 The interesting part is that it only throws it when we start up a single player game. When one starts up a multiplayer game it goes through just fine. What exactly does this error message mean? Does it mean we have too many user messages (seems quite unlikely)? And why should it start only when we're starting up a single player game? We have indeed added a message since the Anyway, I'm basically just looking for a place to start here, since I'm sort of at a loss for what exactly this error message means. Thanks in advance, and no doubt I'll figure it out in five minutes and feel really stupid anyway. :) (During the typing of this message I actually realized I wasn't even copying the client dll to the cl_dlls folder. /me rolls his eyes. :) Still doesn't work in the same way, though.) Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Confusing bit of code in the HL AI
Cool. I thought it had, just thought I might be confusing Q1 and Q2. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of botman > Sent: Saturday, June 08, 2002 7:54 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Confusing bit of code in the HL AI > > > I can't imagine it will be that long before Q2 source goes public > > domain. Or has it already? I know Q1's did. > > > > Persuter > > Yes. Thanks Carmack!... > > ftp://ftp.idsoftware.com/idstuff/source/ > > q2source-3.21.zip is the Quake II engine source code. > > 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] Confusing bit of code in the HL AI
I can't imagine it will be that long before Q2 source goes public domain. Or has it already? I know Q1's did. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of DeNiro > Sent: Friday, June 07, 2002 10:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Confusing bit of code in the HL AI > > Hehehe, well as sweet as this sounds I think Valve can't do that cause > the HL engine is built upon technology licensed from ID. :( > > Kuja wrote: > | Half-life advanced anyone? > | > | -Original Message- > | From: [EMAIL PROTECTED] > | [mailto:[EMAIL PROTECTED]]On Behalf Of Yacketta, > | Ronald > | Sent: Friday, June 07, 2002 10:25 PM > | To: [EMAIL PROTECTED] > | Subject: RE: [hlcoders] Confusing bit of code in the HL AI > | > | > | Yeah go Dyn, then in a few years put the engine (stripped somewhat) on > | the net for 100$ :) > > > > > ___ > 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] Confusing bit of code in the HL AI
Either that or they're about to get a Dynamix pulled on them.
Persuter
Always look on the brighter side of life
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Tim Holt
> Sent: Thursday, June 06, 2002 11:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Confusing bit of code in the HL AI
>
> --
> [ Picked text/plain from multipart/alternative ]
> Hmm, must be getting really close to next HL release, the Valve coders
> are posting responses, which means they have time to look on the
forums
> :^)
>
> Adrian Finol wrote:
>
> > And that too.
> >
> >-Original Message-
> >From: Leon Hartwig [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, June 06, 2002 6:30 PM
> >To: '[EMAIL PROTECTED]'
> >Subject: RE: [hlcoders] Confusing bit of code in the HL AI
> >
> >
> >ASSERT() in the HL SDK will actually just print a message to the
console
> >(when your have compiled in Debug mode), such as:
> >
> >ASSERT FAILED:
> >
> >
> >
> >
> >>-Original Message-
> >>From: Adrian Finol [mailto:[EMAIL PROTECTED]]
> >>Sent: Thursday, June 06, 2002 6:27 PM
> >>To: '[EMAIL PROTECTED]'
> >>Subject: RE: [hlcoders] Confusing bit of code in the HL AI
> >>
> >>
> >> That code sets the COND_ENEMY_OCCLUDE flag if the enemy is
> >>NOT visible.
> >>Hence the !FVisible. If it's visible, then it removes the flag.
> >>
> >> Assert is a debug function, it will break (stop) the debugger if
the
> >>condition passed is not met.
> >>
> >>-Original Message-
> >>From: geoff c [mailto:[EMAIL PROTECTED]]
> >>Sent: Thursday, June 06, 2002 6:22 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: [hlcoders] Confusing bit of code in the HL AI
> >>
> >>
> >>ladies and gentlemen of the jury, please direct your attention
towards
> >>monsters.cpp, line 1065:
> >>if ( !FVisible( pEnemy ) )
> >>{
> >>ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
> >>SetConditions( bits_COND_ENEMY_OCCLUDED );
> >>}
> >>else
> >>ClearConditions( bits_COND_ENEMY_OCCLUDED );
> >>
> >>I looked up the definition for ASSERT, which was #define ASSERT(f) .
I
> >>don't know what that does so it scares me.
> >>
> >>Am I correct in guessing that the above snippet of code checks (if
the
> >>enemy is visible) if the monster currently sees the enemy,
> >>and if so, turns
> >>COND_ENEMY_OCCLUDED on? And what would that be used for, and why?
> >>
> >>AI confuses me.
> >>
> >>-geoff c
> >>
> >>___
> >>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
> >
> >
> >
>
> --
> I think...I think it's in my basement. Let me go upstairs and check.
-M.C.
> Escher
>
>
> --
>
> ___
> 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] triApi speed problems
No, the code for the engine is fully free for anyone who wants it (lol, not like it's particularly amazing). I also gave you guys an example particle system which I asked you not to distribute. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Chris 'Tal-N' Blane > Sent: Monday, May 13, 2002 1:11 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] triApi speed problems > > Ahh now Bitmap said to me that we were going to be having this code > donated > on the basis that we don't share it. But if that's ok with you then I'm > fine > with it. > > - Original Message - > From: Persuter <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, May 13, 2002 3:40 AM > Subject: RE: [hlcoders] triApi speed problems > > > > Given that my particle engine is completely free for anyone to use, I > > invite pasting of the code. > > > > Persuter > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > > [EMAIL PROTECTED]] On Behalf Of Chris 'Tal-N' Blane > > > Sent: Sunday, May 12, 2002 1:40 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > Yeah i don't mind Rainmaker posting the explosion code since the > > particle > > > engine is needed as well to make use of it so cut and pasters can't > > use > > > it. > > > > > > - Original Message - > > > From: Miguel Aleman <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Sunday, May 12, 2002 1:48 AM > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > VSYNC puts a limit on overall frame rate, and it would not change in > > the > > > > presence of particle blending. Chris, do you mind posting the > > section of > > > > code you are using to render the particle to make sure you are doing > > it > > > > correctly. I can get thousands of particles on screen before a major > > > > slowdown. > > > > > > > > - Original Message - > > > > From: "Chris 'Tal-N' Blane" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Saturday, May 11, 2002 7:33 PM > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > I'd love to tell ya it worked... but it's still the same problem. > > :( > > > > Anyone > > > > > else got any ideas. ( it was on originally btw and tuning it off > > > didn't > > > > > help) And these are the most recent drivers from Nvidia > > [4.13.01.2832 > > > > > version] > > > > > > > > > > - Original Message - > > > > > From: Maximilian Marx <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > Sent: Sunday, May 12, 2002 1:16 AM > > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > > > > when using detonator driver go to control panel -> display -> > > > > settings -> > > > > > > advanced -> geforce2 -> advanced -> opengl settings -> vertical > > > sync -> > > > > > > always off > > > > > > - Original Message - > > > > > > From: "Chris 'Tal-N' Blane" <[EMAIL PROTECTED]> > > > > > > To: <[EMAIL PROTECTED]> > > > > > > Sent: Sunday, May 12, 2002 2:01 AM > > > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > > > > > > > Would this vsynch be a HL setting or something in device > > > > manager/display > > > > > > > properties? > > > > > > > > > > > > > > - Original Message - > > > > > > > From: botman <[EMAIL PROTECTED]> > > > > > > > To: <[EMAIL PROTECTED]> > > > > > > > Sent: Sunday, May 12, 2002 12:53 AM > > > > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > > > > > > > > > > > R
RE: [hlcoders] Re: triApi speed problems
Cue: The inevitable system spec pissing contest. :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Kuja > Sent: Sunday, May 12, 2002 7:24 PM > To: [EMAIL PROTECTED] > Subject: RE: [hlcoders] Re: triApi speed problems > > Send it here also, I have a really awesome computer that should be able to > handle anything > > Specs: 1.5ghz athlon tb, 4 gigs of ram, ATI Radeon 8500. > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Foss > Sent: Sunday, May 12, 2002 8:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Re: triApi speed problems > > > > From: "Chris 'Tal-N' Blane" <[EMAIL PROTECTED]> > > Ask Rain, i was only have old source before this was developed. I can > send > > the testmod folder but i don't think that the list allows for > attatchments > > no matter how small. > > Well, send it here, I'll test it on my box... > > specs: > K6-2 350, voodoo3, 320mb ram > > I'll see if it's hardware dependant. > > E-Mail: [EMAIL PROTECTED] > > ___ > 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] triApi speed problems
Given that my particle engine is completely free for anyone to use, I invite pasting of the code. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Chris 'Tal-N' Blane > Sent: Sunday, May 12, 2002 1:40 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] triApi speed problems > > Yeah i don't mind Rainmaker posting the explosion code since the particle > engine is needed as well to make use of it so cut and pasters can't use > it. > > - Original Message - > From: Miguel Aleman <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, May 12, 2002 1:48 AM > Subject: Re: [hlcoders] triApi speed problems > > > > VSYNC puts a limit on overall frame rate, and it would not change in the > > presence of particle blending. Chris, do you mind posting the section of > > code you are using to render the particle to make sure you are doing it > > correctly. I can get thousands of particles on screen before a major > > slowdown. > > > > - Original Message - > > From: "Chris 'Tal-N' Blane" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, May 11, 2002 7:33 PM > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > I'd love to tell ya it worked... but it's still the same problem. :( > > Anyone > > > else got any ideas. ( it was on originally btw and tuning it off > didn't > > > help) And these are the most recent drivers from Nvidia [4.13.01.2832 > > > version] > > > > > > - Original Message - > > > From: Maximilian Marx <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Sunday, May 12, 2002 1:16 AM > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > when using detonator driver go to control panel -> display -> > > settings -> > > > > advanced -> geforce2 -> advanced -> opengl settings -> vertical > sync -> > > > > always off > > > > - Original Message - > > > > From: "Chris 'Tal-N' Blane" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Sunday, May 12, 2002 2:01 AM > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > Would this vsynch be a HL setting or something in device > > manager/display > > > > > properties? > > > > > > > > > > - Original Message - > > > > > From: botman <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > Sent: Sunday, May 12, 2002 12:53 AM > > > > > Subject: Re: [hlcoders] triApi speed problems > > > > > > > > > > > > > > > > > Read the other post for more details, why would this effect > one > > > system > > > > > of > > > > > > a > > > > > > > higher spec 1.1Ghz 512Mb Ram with the same gfx card but not a > far > > > > slower > > > > > > > one? > > > > > > > > > > > > Do you have VSYNC enabled on one video card (the fast one) and > > > disabled > > > > on > > > > > > the other (the slow one)? Check the video adapter settings in > the > > > > control > > > > > > panel to see if VSYNC is enabled or not. (P.S. most people will > > have > > > > > VSYNC > > > > > > enabled since this is the default). > > > > > > > > > > > > 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 > > > > > > > > > > > > > > ___ > > > 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] triApi speed problems
I think the problem is not with my particle engine (how dare you suggest that!!! :) but with additive blending in general. What I've found is that the sprites impact framerate in direct proportion to their pixel size, which is exactly what you'd expect. The more pixels that must be modified by the sprite, the more slowdown. So, while a particle system running 2 or 3 thousand particles may run at 30 fps when the camera is twenty feet from the system, when you get close up, it slows down quite a bit to 8-10 fps. Five particles should be absolutely no problem for the engine, however, regardless of how close up it is. I don't think. :) If you want, send me the files, I can take a look at them. You have defined maxtrashparticles, btw, right? If not, news and deletes will take their toll on the system (although again, 5 particles should not be doing this regardless). Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] New patch and view angles
Did the update do anything with the way view angles are calculated? We use a third-person view, with a cursor at the point where the player is looking (by sending a traceline out from their origin down their view angles). The particular problem I'm having is in this code: cl_entity_t *player; pmtrace_t tr; vec3_t m_vAngles, forward, right, up, org; // Put the direction the player is looking into forward gEngfuncs.GetViewAngles((float *)m_vAngles); AngleVectors(m_vAngles, forward, right, up); player = gEngfuncs.GetLocalPlayer(); if ( !player ) return; org = player->origin; vec3_t farpoint; org.z+=30; farpoint = org + 8192 * forward; tr = *(gEngfuncs.PM_TraceLine((float *)&org, (float *)&farpoint, PM_NORMAL | PM_STUDIO_BOX, 1, -1)); VectorCopy( tr.endpos, origin ); This, however, somehow translates into the CAMERA position, not the view angles. So, the cursor appears directly in the middle of your screen. This code was working fine before the patch. Persuter ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: Re[2]: [hlcoders] Sprite problems
Lol, oh great. So now not only do I have a major problem, MSVC has
decided not to tell me what it is. :) Well, I knew that it was somehow
screwed up (since this pointers really oughtn't to change) but I was
hoping it was the code. Sgh...
OK, well then has anyone else had a problem with sprites refusing to
attach themselves to multiple entities? I've got a streetlamp entity
that I want to have a glow sprite on (I'm lighting the area around it
with dlighting, but I want a glow sprite on the lamp itself). I call
MakeSprite in the spawn function and use SetAttachment and
SetTransparency to attach it to the lamp.
At first, they would all attach to one particular lamp. Now they don't
seem to do that, they just don't attach to any lamp. (Or possibly they
are still attached to that lamp but aren't displayed, or don't do the
same washing out as it did before when they all displayed.) I'm not sure
why they attach to the lamp that they do.
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Cruise
> Sent: Wednesday, April 24, 2002 12:25 PM
> To: Persuter
> Subject: Re[2]: [hlcoders] Sprite problems
>
> I've not had the same problem with GetClassPtr...but I have noticed
> the same problem when stepping through code...
>
> The mod runs fine, but if I try to step through code, everything is
> haywire...the stack trace is nonsense (function above has no reference
> to the function I'm in), this pointers changing their value as I step
> through a member function, memeber variables treated as out of scope.
>
> Basically, really insane stuff...but the code is actually executing
> fine...I can see the effects on screen. Basically it means I can't
> step through the code at all...
>
> All the latest service packs, etc. Very odd...
>
>
> [ Cruise / www.casual-tempest.net ]
>
>
>
> > Further troubles... I tried making this a non-static function, but
that
> > didn't work either. But here's the REALLY weird part. I was stepping
> > through the new function in the debugger:
>
> > CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const
Vector
> > &origin, BOOL animate )
> > {
> > CSprite* pSprite = GetClassPtr( (CSprite *)NULL );
> > pSprite->SpriteInit( pSpriteName, origin );
> > pSprite->pev->classname = MAKE_STRING("env_sprite");
> > pSprite->pev->solid = SOLID_NOT;
> > pSprite->pev->movetype = MOVETYPE_NOCLIP;
> > if ( animate )
> > pSprite->TurnOn();
>
> > return pSprite;
> > }
>
> > It has the exact same error as before. However, I noticed that as I
step
> > through the function that the value of this, i.e., the street lamp,
> > changes three times. First it goes to some seemingly random memory
> > location, then it changes to 1, then it goes back to its regular
> > location. Is that CRAZY or what?
>
> > Upon further inspection, I found that in addition to this calamity,
the
> > Keyvalue function for the entity is not being called at all. This,
too,
> > seems a bit odd. My suspicion was that somehow the game is stumbling
> > over some of the fgd files and somehow, some way, that's messing up
the
> > files.
>
> > However, I then dropped into the disassembler to check what the
assembly
> > had to say about it, and learned to my shock that CSprite* pSprite =
> > GetClassPtr( (CSprite *)NULL ); has absolutely no assembly
counterpart.
> > In other words, the compiler is somehow skipping right the f**k over
it.
>
> > I have absolutely no clue. I'm going to try recompiling all the maps
and
> > the models involved in the hopes that somehow this will fix itself.
Is
> > there anyone who's had a similar problem with GetClassPtr? The rest
of
> > them seem to be compiling so I can't imagine it's a problem with the
> > template implementation, but the problems like KeyValue suggest to
me
> > that it's a run-time problem of some sort, because the fact that
> > GetClassPtr didn't compile shouldn't do anything to KeyValue...
>
> > Persuter
>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:hlcoders-
> >> [EMAIL PROTECTED]] On Behalf Of Persuter
> >> Sent: Monday, April 22, 2002 6:42 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: [hlcoders] Sprite problems
> >>
> >> Hey all, having a bit of a problem here:
> >>
> >> CSprite *CSprite::SpriteCreate( const char *pSpriteName, const
Vector
> >> &origin, BOOL a
RE: [hlcoders] Fog, sprites, and 1.1.0.9
I had a question about that: I remember with fog in 1108, things like func_illusionary were not fogged. Is that part of this fix or will we remain with fogged forests and unfogged bushes? D: Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Tim Holt > Sent: Wednesday, April 24, 2002 12:21 PM > To: [EMAIL PROTECTED] > Subject: [hlcoders] Fog, sprites, and 1.1.0.9 > > Anyone played with the "sprites in fog" fix in 1.1.0.9 to see how it > works? > > -- > I think...I think it's in my basement. Let me go upstairs and check. -M.C. > Escher > > > > ___ > 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] Sprite problems
Tried it. Numerous times. :)
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Cortex
> Sent: Tuesday, April 23, 2002 5:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Sprite problems
>
> Rebuild ALL ???
>
> - Cortex : mapper & coder www.hlalbator.fr.st
>
> - Original Message -
> From: "Persuter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 23, 2002 1:42 AM
> Subject: [hlcoders] Sprite problems
>
>
> > Hey all, having a bit of a problem here:
> >
> > CSprite *CSprite::SpriteCreate( const char *pSpriteName, const
Vector
> > &origin, BOOL animate )
> > {
> > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
> > pSprite->SpriteInit( pSpriteName, origin );
> > pSprite->pev->classname = MAKE_STRING("env_sprite");
> > pSprite->pev->solid = SOLID_NOT;
> > pSprite->pev->movetype = MOVETYPE_NOCLIP;
> > if ( animate )
> > pSprite->TurnOn();
> >
> > return pSprite;
> > }
> >
> > For some reason, when I execute the following code with
> > "sprites/glow01.spr", multiple times, the indicated line doesn't
execute
> > at all except for one instance, the last that is tried. When I use
the
> > debugger, it completely steps over the line, even when I try to step
> > into GetClassPtr. It's like the line doesn't exist... I try pleading
> > with the debugger, pointing at the line very insistently and so
forth,
> > but to no avail.
> >
> > Anyway, so it doesn't execute the line, which means that pSprite
does
> > not exist. This does not trouble the program, however, which happily
> > goes along executing the rest of the code, even while the debugger
shows
> > that pSprite doesn't exist. If I step into the function and check
the
> > value of this, I find that indeed it DOES have an address. But that
> > address is never returned, and the program proceeds as if nothing
had
> > been returned from the function at all! It doesn't even throw
errors.
> > It's very odd.
> >
> > Any ideas?
> >
> > 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
> >
> >
>
>
> ___
> 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] Sprite problems
Further troubles... I tried making this a non-static function, but that
didn't work either. But here's the REALLY weird part. I was stepping
through the new function in the debugger:
CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const Vector
&origin, BOOL animate )
{
CSprite* pSprite = GetClassPtr( (CSprite *)NULL );
pSprite->SpriteInit( pSpriteName, origin );
pSprite->pev->classname = MAKE_STRING("env_sprite");
pSprite->pev->solid = SOLID_NOT;
pSprite->pev->movetype = MOVETYPE_NOCLIP;
if ( animate )
pSprite->TurnOn();
return pSprite;
}
It has the exact same error as before. However, I noticed that as I step
through the function that the value of this, i.e., the street lamp,
changes three times. First it goes to some seemingly random memory
location, then it changes to 1, then it goes back to its regular
location. Is that CRAZY or what?
Upon further inspection, I found that in addition to this calamity, the
Keyvalue function for the entity is not being called at all. This, too,
seems a bit odd. My suspicion was that somehow the game is stumbling
over some of the fgd files and somehow, some way, that's messing up the
files.
However, I then dropped into the disassembler to check what the assembly
had to say about it, and learned to my shock that CSprite* pSprite =
GetClassPtr( (CSprite *)NULL ); has absolutely no assembly counterpart.
In other words, the compiler is somehow skipping right the f**k over it.
I have absolutely no clue. I'm going to try recompiling all the maps and
the models involved in the hopes that somehow this will fix itself. Is
there anyone who's had a similar problem with GetClassPtr? The rest of
them seem to be compiling so I can't imagine it's a problem with the
template implementation, but the problems like KeyValue suggest to me
that it's a run-time problem of some sort, because the fact that
GetClassPtr didn't compile shouldn't do anything to KeyValue...
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Persuter
> Sent: Monday, April 22, 2002 6:42 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Sprite problems
>
> Hey all, having a bit of a problem here:
>
> CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector
> &origin, BOOL animate )
> {
> CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
> pSprite->SpriteInit( pSpriteName, origin );
> pSprite->pev->classname = MAKE_STRING("env_sprite");
> pSprite->pev->solid = SOLID_NOT;
> pSprite->pev->movetype = MOVETYPE_NOCLIP;
> if ( animate )
> pSprite->TurnOn();
>
> return pSprite;
> }
>
> For some reason, when I execute the following code with
> "sprites/glow01.spr", multiple times, the indicated line doesn't
execute
> at all except for one instance, the last that is tried. When I use the
> debugger, it completely steps over the line, even when I try to step
> into GetClassPtr. It's like the line doesn't exist... I try pleading
> with the debugger, pointing at the line very insistently and so forth,
> but to no avail.
>
> Anyway, so it doesn't execute the line, which means that pSprite does
> not exist. This does not trouble the program, however, which happily
> goes along executing the rest of the code, even while the debugger
shows
> that pSprite doesn't exist. If I step into the function and check the
> value of this, I find that indeed it DOES have an address. But that
> address is never returned, and the program proceeds as if nothing had
> been returned from the function at all! It doesn't even throw errors.
> It's very odd.
>
> Any ideas?
>
> 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
_
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] SITWFODF1D #1
I don't know if this is similar, but: On Hostile Intent, we had oodles and oodles of player animations, and eventually studiomdl started crapping out with amazing memory dump errors. The solution, however, was simple, we simply had to increase MAXSTUDIOSEQUENCES or MAXSTUDIOANIMATIONS, I forget which one, and recompile studiomdl and the game, then recompile all the models with the new studiomdl. I see in studio.h that there is a MAXSTUDIOSKINS variable as well, set to 100. Perhaps if you increased that to something higher and recompiled both studiomdl and the game? Again, it's a simple fix so you've probably already tried it, it just seemed similar in many ways to the problem we were having (Valve's code pooping out due to throwing way more at it than it was meant to handle). Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Cortex > Sent: Tuesday, April 23, 2002 1:29 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] SITWFODF1D #1 > > Thx ;) It's cool to share the problem & solutions :) > > - Original Message - > From: "Dynerman David M" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, April 22, 2002 6:40 PM > Subject: [hlcoders] SITWFODF1D #1 > > > > Some Interesting Things We Found Out During FLF 1.5's Development Part > > #1 > > > > In the course of developing Front Line Force 1.5 we (the 2 coders, omega > > and I) hit upon some stumbling blocks which I thought I would post (to > > save other mod-makers time if they hit it) > > > > I'll be posting problems as they come to mind (1.5 was a several month > > project, so not everything is crystal) > > > > Part #1 - Texture Corruption > > > > Texture Corruption - The Half-Life engine apparently does not properly > > manage textures on dynamic objects such as player models, w_textures, > > etc, etc. The list of textures is fixed-size and doesn't clear at map > > change, so once you exceed it you'll start getting corruption issues. > > For example, our player models had 17 textures each. Additionally, we > > had 6 sets of players models (desert camo, arctic camo, etc, etc) - this > > added up to around 566 textures (there was additional overhead, i.e. > > each model had 2 full sets of textures to support a 'blinking' effect > > via manipulating pev->skin) this added up to 408 textures. Pushing > > these numbers, after only one map change we began seeing corruption > > (texture limit @ 1024 perhaps?) > > > > http://www.flfmod.com/david/arms_blending_off.jpg > > > > is a modest example, it got much worst. > > > > The solution we used to this was to combine all the skins on each model > > into one texture (i.e. instead of a texture for head, a texture for > > legs, etc, etc we had one big texture that was mapped to the model) > > > > This is more intensive on the modeler to get the coordinates right, but > > solved our problem nicely. > > > > > > Next time - hitbox issues! > > > > david > > ___ > > 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 _ 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
[hlcoders] Sprite problems
Hey all, having a bit of a problem here:
CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector
&origin, BOOL animate )
{
CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
pSprite->SpriteInit( pSpriteName, origin );
pSprite->pev->classname = MAKE_STRING("env_sprite");
pSprite->pev->solid = SOLID_NOT;
pSprite->pev->movetype = MOVETYPE_NOCLIP;
if ( animate )
pSprite->TurnOn();
return pSprite;
}
For some reason, when I execute the following code with
"sprites/glow01.spr", multiple times, the indicated line doesn't execute
at all except for one instance, the last that is tried. When I use the
debugger, it completely steps over the line, even when I try to step
into GetClassPtr. It's like the line doesn't exist... I try pleading
with the debugger, pointing at the line very insistently and so forth,
but to no avail.
Anyway, so it doesn't execute the line, which means that pSprite does
not exist. This does not trouble the program, however, which happily
goes along executing the rest of the code, even while the debugger shows
that pSprite doesn't exist. If I step into the function and check the
value of this, I find that indeed it DOES have an address. But that
address is never returned, and the program proceeds as if nothing had
been returned from the function at all! It doesn't even throw errors.
It's very odd.
Any ideas?
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
[hlcoders] (no subject)
Hey all, having a bit of a problem here:
CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector
&origin, BOOL animate )
{
CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
pSprite->SpriteInit( pSpriteName, origin );
pSprite->pev->classname = MAKE_STRING("env_sprite");
pSprite->pev->solid = SOLID_NOT;
pSprite->pev->movetype = MOVETYPE_NOCLIP;
if ( animate )
pSprite->TurnOn();
return pSprite;
}
For some reason, when I execute the following code with
"sprites/glow01.spr", multiple times, the indicated line doesn't execute
at all except for one instance, the last that is tried. When I use the
debugger, it completely steps over the line, even when I try to step
into GetClassPtr. It's like the line doesn't exist... I try pleading
with the debugger, pointing at the line very insistently and so forth,
but to no avail.
Anyway, so it doesn't execute the line, which means that pSprite does
not exist. This does not trouble the program, however, which happily
goes along executing the rest of the code, even while the debugger shows
that pSprite doesn't exist. If I step into the function and check the
value of this, I find that indeed it DOES have an address. But that
address is never returned, and the program proceeds as if nothing had
been returned from the function at all! It doesn't even throw errors.
It's very odd.
Any ideas?
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
RE: [hlcoders] Updated SDK for 1109?
/me notes that there's also WinDiff, which generally comes with the Microsoft Visual Studio package. Another great way to ensure ease of portability between SDK is usage of object-oriented design principles, rather than "spaghetti code". Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of botman > Sent: Monday, April 22, 2002 6:19 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Updated SDK for 1109? > > > Yea, how do change from SDK to SDK because I have a lot of uncommented > > spagetti code that seems to blend in nicely with the current HalfLife > > code (there should be a 'highlight changes' button). > > There is. It's called BeyondCompare... > > http://www.scootersoftware.com/ > > ...just compare all the files in SDK N-1 to SDK N and you see what was > changed. > > 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
RE: [hlcoders] Converting angles to screen pixels
I would suggest using a mathematical formula based on angle and possibly distance. For example, if you take an accuracy cone that is x units long, with angle y (from the center of the player's vision to the outside of the cone), the radius of the base of the cone is x * tan(y). (Simple trigonometry tells us this.) So, assuming that you just want a crosshair, i.e., fixed in depth, you just set x at something natural looking, and draw a circle or whatever of radius x * tan(y), where y is simply the accuracy cone of the weapon. If you want a circle that will enlarge as the terminus of the aim vector grows more distant (i.e., it projects the cone onto the wall you're looking at, telling you the exact maximum radius of a burst onto that wall), then all you need do is send out a traceline down the aim vector, use the traceline length for x, use the accuracy angle for y, and again you have a radius quickly, without screen pixel to angle transforms. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Commando > Sent: Sunday, April 14, 2002 5:33 PM > To: [EMAIL PROTECTED] > Subject: [hlcoders] Converting angles to screen pixels > > Okay, here's a tough one and I don't really know how to approach it. I > want to take an angle (a weapon's accuracy cone actually) and convert it > to > the number of pixels on screen from a player's viewpoint that angle would > cover. I know I will need to take the current FOV and the current screen > resolution into account, but I don't really know how to tackle this > one. If anyone has done this before, or even if someone can provide parts > of the transformation, I would really appreciate the help. > > Just in case I am not clear in what I am trying to do above, I will > explain > it here. I want to take a weapons accuracy in degrees (which changes > constantly in our mod) and draw sprites on the screen for the crosshair > that will give the player a good idea of how accurate their weapon is at > that time. I may do it as an expanding circle that represents the weapons > current cone of accuracy. > > Robert Prouse > http://www.tourofdutymod.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] This list is good...
Psssh all teachers are communists. Why else would you get a college degree and then get 30K a year at a soul-deadening job with nothing but the opportunity to help people as your reward? (I'd do an ":)" here but it's way too true.) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Reedbeta > Sent: Thursday, April 11, 2002 10:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] This list is good... > > Proletarier aller lander, verignt euch! > (Workers of the world, unite!) > My English teacher has a big poster on her classroom wall with the above > statement emblazoned on it. > > --- Miguel Aleman <[EMAIL PROTECTED]> wrote: > > lol > > > > They openly declare that their ends can be attained only by the forcible > > overthrow of all existing social conditions. > > Let the ruling classes tremble at a communist revolution. > > The proletarians have nothing to lose but their chains. They have a > world to > > win. > > Workers of all countries, unite! > > > > - Original Message - > > From: "Tim Holt" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, April 11, 2002 5:05 PM > > Subject: [hlcoders] This list is good... > > > > > > > Well I know it sounds dumb, but this list is good. It's a great > > > conversation. It's probably survived my subscribe-to list longer than > > > any news group or email list so far! > > > > > > And I admit that I have just been re-reading The Cluetrain Manifesto > :^) > > > http://www.cluetrain.com > > > > > > -- > > > I think...I think it's in my basement. Let me go upstairs and check. - > M.C. > > Escher > > > > > > > > > > > > ___ > > > 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 > > > > > __ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.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
[hlcoders] High-precision integer libraries
I admit in advance that this isn't HL-related, but there's a lot of smart programmers in here and I was hoping one of you had seen this before: I need a library that provides unlimited (or at least very high) precision integer and integer arithmetic. Specifically, I need at least an addition, multiplication, and modulus operator. Also, it'd be nice if it was written for WinNT as opposed to Linux, though not necessary. I've seen a couple of packages, like HugeCalc, but they're always missing something (e.g., HugeCalc has no modulus operator, hence it is useless). Pretty soon I'm going to have to reprogram into some godawful math language like Matlab or Mathematica. Please help! Anyone seen one of these, perhaps used it in your far-ranging programming journeys? :) 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
RE: [hlcoders] OT: what do langauge microsoft use for their apps?
/me notes that it seems unlikely that MS would use any type of MFC stuff in their programs. Why in the world would you use generalized libraries when you can knock on the next office and get the source? And Gollum, indeed I had noticed that VB5 and VB6 are light years ahead of the early stuff. Very nice for simple database applications, good SQL stuff. Kudos. :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Simon Rose > Sent: Friday, March 08, 2002 12:33 PM > To: [EMAIL PROTECTED] > Subject: RE: [hlcoders] OT: what do langauge microsoft use for their apps? > > I read in a book about someone who was trying to write a toolbar like > Microsoft's (this was some time back), so they used that Spy tool on one > of > Microsoft's products to intercept the messages expecting MFC type stuff or > similar going on. They found nothing of the sort and summised (correctly I > feel) that MS wrote quite a lot of their UI from the ground-up. > > I doubt they would have used VB for this, but I'm open to it being > possible. > > Simon > > PS: I wish MS would provide most of the standard UI elements (such as > power > toolbar, menu and docking windows a la InterDev etc) in their developer > products, that way we wouldn't have to spend the first 30% of our time > trying to be like them, only for the other 70% of our time trying not to > be > like them! > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Pat Magnan > Sent: 08 March 2002 09:39 > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] OT: what do langauge microsoft use for their > apps? > > > Ok, how dumb of me earlier. I ran all the .exes through the dependency > walker that comes with Visual Studio. > > A VB App (any that I've ever seen, are all dependent on: > MSVBVM50.DLL > which in turn depends on stuff like GDI, Kernell, etc type dlls > > An MFC App would have MFC42 dll in its dependency tree, then GDI and > kernell etc. > > For Office (for example), I see neither of those. I see WWINTL32.DLL > (don't know what this is) and MSO97.DLL (likely just a library of > common code for office), but no VB runtime or MFC42 anywhere in there. > > Therefore, if I had to make a semi-educated guess, I'd say that office > is written (office 97 is what I have, so this is a little dated) > entirely in C, no MFC, could be C++, but it's likely that it's using > straight Win32 API calls for the GUI. > > Oops, sorry about the WAG I made earlier ;) > > That's a great tool for remembering what to ship sort of complex > products, I always have it in my 'send to' menu, so I can make sure > that our distribution folks never forget to include a .dll or whatever > on a CD ;) > > > > > Maybe they wrote them in Delphi > > > > > > --- Florian Zschocke <[EMAIL PROTECTED]> wrote: > > > Simon Rose wrote: > > > > > > > > It always did my > > > > noodle that something could compile itself, if you > > > see what I mean. Cool > > > > though. > > > > > > It's called bootstrapping and every compiler does > > > it. You have to > > > start at machine level somewhere, tho, unless you're > > > cross-compiling (which is what is usually done). > > > > > > > > > > I would hope they don't use VB for anything. > > > Sorry, but imho, I don't think > > > > VB is up to the job. > > > > > > AFAIK the UIs are in VB. > > > > > > > > > Florian. > > > ___ > > > > > > > > > > ___ > > 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 > > ___ > 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] OT: what do langauge microsoft use for their apps?
I know at least that Microsoft claims that Microsoft Visual C++ was used to program Microsoft Visual Studio. I would guess they use C and C derivatives mostly, obviously asm is used in a few places (the operating system comes to mind), Visual Basic is probably used for UI-intensive stuff, but most of their programs have a very distinct C++ feel, as opposed to VB or Java. Also, Microsoft, as one of the largest software developers, no doubt has a whole retinue of proprietary products and possibly languages to assist in development. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of _Phantom_ > Sent: Thursday, March 07, 2002 12:33 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] OT: what do langauge microsoft use for their apps? > > I doubt asm tbh... most probably done in Visual C++ (using a combo of C++ > and C) > > - Original Message - > From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, March 07, 2002 5:39 PM > Subject: Re: [hlcoders] OT: what do langauge microsoft use for their apps? > > > > asm and c/c++ > > > > - Original Message - > > From: "Tom" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, March 07, 2002 6:30 PM > > Subject: [hlcoders] OT: what do langauge microsoft use for their apps? > > > > > > > This is a multi-part message in MIME format. > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > sorry about this post, its just that im doing a report for school and > Im > > trying to find out what language was used when making things like > Microsoft > > office and other Microsoft apps? > > > > > > Someone said VB but im not really sure if VB (not vb.net) has the > power > > for it all. Perhaps for the interface, but not the whole processing > system > > behind it... > > > > > > --tom > > > -- > > > > > > ___ > > > 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 _ 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] hgrunt code
void CTalkMonster :: FollowerUse( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value ) That particular FollowerUse, you mean? The one in the CTalkMonster class? :) You'll have to implement your own FollowerUse, StartFollowing, and so forth in your class (hint: just copy them over. :). Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Lee Shaw > Sent: Thursday, February 21, 2002 11:16 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] hgrunt code > > the #include "talkmonster.h" is already in the hgrunt code > > > >From: "Mike Blowers" <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: Re: [hlcoders] hgrunt code > >Date: Thu, 21 Feb 2002 17:14:58 - > > > >You'll have to add : > >#include "talkmonster.h" > >to be able to use the FollowUse code. > > > > > >- Original Message - > >From: "Lee Shaw" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Thursday, February 21, 2002 4:59 PM > >Subject: RE: [hlcoders] hgrunt code > > > > > > > right i implemented the slFollow task into code but when i add in > >SetUse( > > > FollowerUse ); just like barney and sci's have in there code exactly > >under > > > MonsterInit(); i get 2 errors which i don't no how to fix but when the > > > SetUse( FollowerUse ); bit aint there then it compiles fine. this is > >what > >i > > > get > > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\hgrunt.cpp(1043) : error C2065: > > > 'FollowerUse' : undeclared identifier > > > C:\SIERRA\Half-Life\SourceCode\dlls\hgrunt.cpp(1043) : error C2440: > > > 'static_cast' : cannot convert from 'int' to 'void (__thiscall > > > CBaseEntity::*)(class CBaseEntity *,class CBaseEntity > *,USE_TYPE,float)' > > > There are no conversions from integral values to > >pointer-to-member > > > values > > > > > > > > > - ^^RaZiEl^^ > > > > > > >From: "Persuter" <[EMAIL PROTECTED]> > > > >Reply-To: [EMAIL PROTECTED] > > > >To: <[EMAIL PROTECTED]> > > > >Subject: RE: [hlcoders] hgrunt code > > > >Date: Thu, 21 Feb 2002 00:39:37 -0600 > > > > > > > >Dude. Seriously. Do it my way. Don't implement the TalkMonster code, > it > > > >does not have the follow code in it. > > > > > > > >Read http://hlpp.valveworld.com/tuts/ai-description.html > > > > > > > >Add the slFollow task to the HGrunt class. > > > > > > > >:) > > > > > > > >Persuter > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > > > > [EMAIL PROTECTED]] On Behalf Of Lee Shaw > > > > > Sent: Wednesday, February 20, 2002 9:14 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [hlcoders] hgrunt code > > > > > > > > > > i've been tryin to merge the CTalkMonster follow code into the > > > > > CSquadMonster > > > > > code but i just keep gettin this.. > > > > > > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(94) : error > >C2065: > > > > > 'TLK_CFRIENDS' : undeclared identifier > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(94) : error > >C2057: > > > > > expected constant expression > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : error > >C2065: > > > > > 'TLK_CGROUPS' : undeclared identifier > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : error > >C2057: > > > > > expected constant expression > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : warning > > > >C4200: > > > > > nonstandard extension used : zero-sized array in struct/union > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(101) : error > >C2229: > > > > > class > > > > > 'CSquadMonster' has an illegal zero-sized array > > > > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(115) : error > >C2065: > > > > > 'm_hSquadLeader' : undeclared identi
RE: [hlcoders] hgrunt code
Dude. Seriously. Do it my way. Don't implement the TalkMonster code, it does not have the follow code in it. Read http://hlpp.valveworld.com/tuts/ai-description.html Add the slFollow task to the HGrunt class. :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Lee Shaw > Sent: Wednesday, February 20, 2002 9:14 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] hgrunt code > > i've been tryin to merge the CTalkMonster follow code into the > CSquadMonster > code but i just keep gettin this.. > > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(94) : error C2065: > 'TLK_CFRIENDS' : undeclared identifier > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(94) : error C2057: > expected constant expression > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : error C2065: > 'TLK_CGROUPS' : undeclared identifier > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : error C2057: > expected constant expression > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(100) : warning C4200: > nonstandard extension used : zero-sized array in struct/union > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(101) : error C2229: > class > 'CSquadMonster' has an illegal zero-sized array > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(115) : error C2065: > 'm_hSquadLeader' : undeclared identifier > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(118) : error C2673: > 'MySquadLeader' : global functions do not have 'this' pointers > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(123) : error C2673: > 'MySquadMember' : global functions do not have 'this' pointers > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(125) : error C2065: > 'm_hSquadMember' : undeclared identifier > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(125) : error C2109: > subscript requires array or pointer type > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(128) : error C2673: > 'IsLeader' : global functions do not have 'this' pointers > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(143) : error C2575: > 'MySquadMonsterPointer' : only member functions and bases can be virtual > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(143) : error C2673: > 'MySquadMonsterPointer' : global functions do not have 'this' pointers > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(145) : error C2133: > 'm_SaveData' : unknown size > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(154) : error C2143: > syntax error : missing ';' before '}' > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(154) : error C2143: > syntax error : missing ';' before '}' > C:\SIERRA\Half-Life\SourceCode\dlls\squadmonster.h(154) : error C2143: > syntax error : missing ';' before '}' > C:\SIERRA\Half-Life\SourceCode\dlls\talkmonster.h(63) : error C2371: > 'TLK_CGROUPS' : redefinition; different basic types > C:\SIERRA\Half-Life\SourceCode\dlls\talkmonster.h(164) : error C2057: > expected constant expression > C:\SIERRA\Half-Life\SourceCode\dlls\talkmonster.h(164) : warning C4200: > nonstandard extension used : zero-sized array in struct/union > C:\SIERRA\Half-Life\SourceCode\dlls\talkmonster.h(165) : error C2229: > class > 'CTalkMonster' has an illegal zero-sized array > Error executing cl.exe. > > > n e 1 no how i can fix it? cuz i don't have a clue > > > >From: Reedbeta <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED] > >Subject: Re: [hlcoders] hgrunt code > >Date: Tue, 19 Feb 2002 16:45:47 -0800 (PST) > > > > >You could also merge the CTalkMonster follow code into the > CSquadMonster > >code. > > > >Two words: multipleinheritance! MUAHAHAHAHAHAH! It's evil! > > > >--Reedbeta > > > > > >__ > >Do You Yahoo!? > >Yahoo! Sports - Coverage of the 2002 Olympic Games > >http://sports.yahoo.com > >___ > >To unsubscribe, edit your list preferences, or view the list archives, > >please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > _ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > > ___ > 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] hgrunt code
Perhaps not the simplest option, but the most correct, is by reading the tutorial: http://hlpp.valveworld.com/tuts/ai-description.html, and using the information in there to add the slFollow task, found in scientist.cpp, to the HGrunt. Shouldn't be that hard, really. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Lee Shaw > Sent: Tuesday, February 19, 2002 5:34 PM > To: [EMAIL PROTECTED] > Subject: [hlcoders] hgrunt code > > > > does any one no how i can add a follow code to the hgrunt code? as i have > been trying to do it for a while now but can't work it out, i've looked > for > some tuts on it but can't find n e 1 if n e 1 could help it would be a > great help cheers > > ^^RaZiEl^^ > > _ > Join the world's 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 _ 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] 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
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;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;i<3;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 yo
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;iif(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;i<3;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
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
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
RE: [hlcoders] Valve - confirm/shatter a myth for me
/me hugs his poor 700MHz clunker... "Don't worry, you're just as good as the rest of the computers, even if little handhelds can outperform you! Don't let anyone tell you you're different!!!" :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Nathan Taylor > Sent: Tuesday, February 12, 2002 5:19 AM > To: HLCoders > Subject: Re: [hlcoders] Valve - confirm/shatter a myth for me > > -- > [ Picked text/plain from multipart/alternative ] > /me glares in envy, damn techies with money > > I hiss at you! > > *hiss* *hiss* > > - Nate > > - Original Message - > From: Dynerman David M > Sent: Tuesday, February 12, 2002 12:54 AM > To: [EMAIL PROTECTED] > Subject: RE: [hlcoders] Valve - confirm/shatter a myth for me > > HLCoders on your cell phone? > > Impressive. > > david > > -Original Message- > From: [DRP]Avatar-X [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 11, 2002 11:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Valve - confirm/shatter a myth for me > > Yeah i read that on my phone on the way home and i was thinking about it > the whole way > home and it confused the hell out of me... "how can the DSL reduce the > 56k's load" > > Silly aaron! you wasted my valuable commute time! I could have spent it > staring blankly > out of the subway window! > > -av > > Persuter wrote: > > > Ahhh, good, I was turning it over in my head and trying to figure out > > what the hell he meant by the DSL "sharing part of the 56K's load." > Nice > > to get confirmation on the preposterous factor. > > > > Persuter > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > > [EMAIL PROTECTED]] On Behalf Of Leon Hartwig > > > Sent: Monday, February 11, 2002 12:13 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [hlcoders] Valve - confirm/shatter a myth for me > > > > > > This is a multi-part message in MIME format. > > > -- > > > No, 56k people don't lag servers. I have no idea what Aaron is > > talking > > > about though, because everything after the first two words in his > > > message is preposterous. > > > > > > > > > > -Original Message- > > > > From: Aaron Kalin [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, February 11, 2002 9:34 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [hlcoders] Valve - confirm/shatter a myth for me > > > > > > > > > > > > They dont, in fact when a 56K Player is in a server, if > > > > someone on say, a > > > > DSL joins in, that 56K player's ping drops because the DSL is > > > > now sharing > > > > part of the 56K's load. Thats the beauty of the netcode > > > > valve made, call it > > > > "load balancing" if you will. However some LPB's hate this > because > > ti > > > > shoves more load on thier system because they are making up > > > > for loss on the > > > > 56K's end. The rest of the logistics to the netcode im not > > > > sure of, but > > > > thats from what knowledge I have gathered. The netcode must > > > > be good if id > > > > is getting valves netcode for the q3a engine. > > > > > > > > -Theiggsta > > > > -Rats! Mod Team > > > > > > > > - Original Message - > > > > From: "Tim Holt" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Monday, February 11, 2002 12:01 PM > > > > Subject: [hlcoders] Valve - confirm/shatter a myth for me > > > > > > > > > > > > > Do 56K dial up people REALLY lag servers? > > > > > > > > > > ___ > > > > > 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] Valve - confirm/shatter a myth for me
Ahhh, good, I was turning it over in my head and trying to figure out what the hell he meant by the DSL "sharing part of the 56K's load." Nice to get confirmation on the preposterous factor. Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Leon Hartwig > Sent: Monday, February 11, 2002 12:13 PM > To: [EMAIL PROTECTED] > Subject: RE: [hlcoders] Valve - confirm/shatter a myth for me > > This is a multi-part message in MIME format. > -- > No, 56k people don't lag servers. I have no idea what Aaron is talking > about though, because everything after the first two words in his > message is preposterous. > > > > -Original Message- > > From: Aaron Kalin [mailto:[EMAIL PROTECTED]] > > Sent: Monday, February 11, 2002 9:34 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [hlcoders] Valve - confirm/shatter a myth for me > > > > > > They dont, in fact when a 56K Player is in a server, if > > someone on say, a > > DSL joins in, that 56K player's ping drops because the DSL is > > now sharing > > part of the 56K's load. Thats the beauty of the netcode > > valve made, call it > > "load balancing" if you will. However some LPB's hate this because ti > > shoves more load on thier system because they are making up > > for loss on the > > 56K's end. The rest of the logistics to the netcode im not > > sure of, but > > thats from what knowledge I have gathered. The netcode must > > be good if id > > is getting valves netcode for the q3a engine. > > > > -Theiggsta > > -Rats! Mod Team > > > > - Original Message - > > From: "Tim Holt" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, February 11, 2002 12:01 PM > > Subject: [hlcoders] Valve - confirm/shatter a myth for me > > > > > > > Do 56K dial up people REALLY lag servers? > > > > > > ___ > > > 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 > > > -- > [ winmail.dat of type application/ms-tnef deleted ] > -- > > ___ > 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] More Message Problems
But it's random stuff that all worked before. Something different
crashes the program each time, although there are certain entities,
.rects, CHudStamina, and CHudMapType that seem to crash it a lot.
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Tom
> Sent: Sunday, February 10, 2002 4:09 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] More Message Problems
>
> I think I solved my problem, I was sending the message too early, so
it
> wasnt ready (I think).
>
> Just thinking along the lines of my problem, are you sure that you are
not
> sending the message too early, and when you intersept it you then try
to
> call a memeber of gHud or the viewport which isnt there?
>
> - Original Message -
> From: "Persuter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, February 10, 2002 6:49 AM
> Subject: RE: [hlcoders] More Message Problems
>
>
> > For more of an update on this: I've removed the Initialize function
of a
> > different hud element, and it gets way farther now, only crashing
upon
> > beginning the render. Again, the problem seems to be that HUD
elements
> > keep losing pointers or something. I'll get an access error while
> > accessing something like hSprite in CHudHealth. The variables in the
hud
> > element classes just sort of disappear. What could be causing this?
> >
> > Persuter
> > Lead Coder of Hostile Intent
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:hlcoders-
> > > [EMAIL PROTECTED]] On Behalf Of Persuter
> > > Sent: Saturday, February 09, 2002 7:09 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [hlcoders] More Message Problems
> > >
> > > I'm having message problems of my own. I decided against the bsp
> > reader,
> > > since I just need to get one value. I set up a HUD element that
would
> > > keep track of the map type (the keyvalue info), so the HUD
functions
> > > that needed to know could hook into that.
> > >
> > > However, now I'm having a problem where CHud::Init() will crash in
> > > seemingly random places while running through all the hud elements
> > init
> > > functions. Generally one or more of them (m_Speed,
m_AmmoSecondary,
> > > etc.) will not be anything, but simply contain empty pointers and
> > > whatnot, and the program will crash out with an access violation
when
> > it
> > > tries to access the Init function.
> > >
> > > The especially weird thing is that these objects worked before I
put
> > the
> > > new message in and even if I remove the Init function for the new
> > > object, it still crashes.
> > >
> > > On the server-side:
> > >
> > > In player.cpp:
> > >
> > > int gmsgMapType = 0;
> > >
> > > In LinkUserMessages():
> > >
> > > gmsgMapType = REG_USER_MSG( "MapType", 1 );
> > >
> > > OK, now I think this is my problem, I really didn't know where to
put
> > > this:
> > >
> > > I have in CBasePlayer::UpdateClientData():
> > >
> > > if (m_fInitHUD)
> > > {
> > > m_fInitHUD = FALSE;
> > > gInitHUD = FALSE;
> > >
> > > MESSAGE_BEGIN( MSG_ONE, gmsgResetHUD, NULL, pev );
> > > WRITE_BYTE( 0 );
> > > MESSAGE_END();
> > >
> > > if ( !m_fGameHUDInitialized )
> > > {
> > > MESSAGE_BEGIN( MSG_ONE, gmsgInitHUD, NULL, pev
> > > );
> > > MESSAGE_END();
> > >
> > > g_pGameRules->InitHUD( this );
> > > m_fGameHUDInitialized = TRUE;
> > > if ( g_pGameRules->IsMultiplayer() )
> > > {
> > > FireTargets( "game_playerjoin", this,
> > > this, USE_TOGGLE, 0 );
> > > }
> > > }
> > > FireTargets( "game_playerspawn", this, this, USE_TOGGLE,
> > > 0 );
> > >
> > > CBaseEntity* pMapType = NULL;
> > > pMapType = UTIL_FindEntityByClassname( pMapType,
> > > "hi_maptype" );
> > >
> > >
> > > MESSAGE_BEGIN( MSG_ONE, gmsgMapType, NULL, pev );
> > > if( pMapType )
> > > WRITE_BYTE(
> > > ((CMapType*)pMapType)->m_iMapType );
> > > else
> > > WRITE_BYTE( 5 ); // Otherwise any models
> > > may be used.
> > > MESSAGE_END();
> > > }
> >
RE: [hlcoders] More Message Problems
For more of an update on this: I've removed the Initialize function of a
different hud element, and it gets way farther now, only crashing upon
beginning the render. Again, the problem seems to be that HUD elements
keep losing pointers or something. I'll get an access error while
accessing something like hSprite in CHudHealth. The variables in the hud
element classes just sort of disappear. What could be causing this?
Persuter
Lead Coder of Hostile Intent
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Persuter
> Sent: Saturday, February 09, 2002 7:09 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] More Message Problems
>
> I'm having message problems of my own. I decided against the bsp
reader,
> since I just need to get one value. I set up a HUD element that would
> keep track of the map type (the keyvalue info), so the HUD functions
> that needed to know could hook into that.
>
> However, now I'm having a problem where CHud::Init() will crash in
> seemingly random places while running through all the hud elements
init
> functions. Generally one or more of them (m_Speed, m_AmmoSecondary,
> etc.) will not be anything, but simply contain empty pointers and
> whatnot, and the program will crash out with an access violation when
it
> tries to access the Init function.
>
> The especially weird thing is that these objects worked before I put
the
> new message in and even if I remove the Init function for the new
> object, it still crashes.
>
> On the server-side:
>
> In player.cpp:
>
> int gmsgMapType = 0;
>
> In LinkUserMessages():
>
> gmsgMapType = REG_USER_MSG( "MapType", 1 );
>
> OK, now I think this is my problem, I really didn't know where to put
> this:
>
> I have in CBasePlayer::UpdateClientData():
>
> if (m_fInitHUD)
> {
> m_fInitHUD = FALSE;
> gInitHUD = FALSE;
>
> MESSAGE_BEGIN( MSG_ONE, gmsgResetHUD, NULL, pev );
> WRITE_BYTE( 0 );
> MESSAGE_END();
>
> if ( !m_fGameHUDInitialized )
> {
> MESSAGE_BEGIN( MSG_ONE, gmsgInitHUD, NULL, pev
> );
> MESSAGE_END();
>
> g_pGameRules->InitHUD( this );
> m_fGameHUDInitialized = TRUE;
> if ( g_pGameRules->IsMultiplayer() )
> {
> FireTargets( "game_playerjoin", this,
> this, USE_TOGGLE, 0 );
> }
> }
> FireTargets( "game_playerspawn", this, this, USE_TOGGLE,
> 0 );
>
> CBaseEntity* pMapType = NULL;
> pMapType = UTIL_FindEntityByClassname( pMapType,
> "hi_maptype" );
>
>
> MESSAGE_BEGIN( MSG_ONE, gmsgMapType, NULL, pev );
> if( pMapType )
> WRITE_BYTE(
> ((CMapType*)pMapType)->m_iMapType );
> else
> WRITE_BYTE( 5 ); // Otherwise any models
> may be used.
> MESSAGE_END();
> }
>
> On the client-side:
>
> In hud.cpp:
>
> m_MapType.Init();
>
> In hud.h:
>
> class CHudMapType : public CHudBase
> {
> public:
> int m_iMapType;
> int Init( void );
> int MsgFunc_MapType( const char *pszName, int iSize, void* pbuf
> );
> };
>
> In hud.h, in the definition of CHud:
>
> CHudMapType m_MapType;
>
> Further down, same place:
>
> int _cdecl MsgFunc_MapType( const char *pszName, int iSize,
> void *pbuf );
>
> In maptype.cpp:
>
> DECLARE_MESSAGE( m_MapType, MapType );
>
> int CHudMapType::Init( void )
> {
> HOOK_MESSAGE( MapType );
>
> gHUD.AddHudElem( this );
>
> return 1;
>
> }
>
> int CHudMapType::MsgFunc_MapType( const char *pszName, int iSize,
void*
> pbuf )
> {
> BEGIN_READ( pbuf, iSize );
>
> m_iMapType = READ_BYTE();
>
> return 1;
>
> }
>
>
>
>
> _
> 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
_
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
[hlcoders] More Message Problems
I'm having message problems of my own. I decided against the bsp reader,
since I just need to get one value. I set up a HUD element that would
keep track of the map type (the keyvalue info), so the HUD functions
that needed to know could hook into that.
However, now I'm having a problem where CHud::Init() will crash in
seemingly random places while running through all the hud elements init
functions. Generally one or more of them (m_Speed, m_AmmoSecondary,
etc.) will not be anything, but simply contain empty pointers and
whatnot, and the program will crash out with an access violation when it
tries to access the Init function.
The especially weird thing is that these objects worked before I put the
new message in and even if I remove the Init function for the new
object, it still crashes.
On the server-side:
In player.cpp:
int gmsgMapType = 0;
In LinkUserMessages():
gmsgMapType = REG_USER_MSG( "MapType", 1 );
OK, now I think this is my problem, I really didn't know where to put
this:
I have in CBasePlayer::UpdateClientData():
if (m_fInitHUD)
{
m_fInitHUD = FALSE;
gInitHUD = FALSE;
MESSAGE_BEGIN( MSG_ONE, gmsgResetHUD, NULL, pev );
WRITE_BYTE( 0 );
MESSAGE_END();
if ( !m_fGameHUDInitialized )
{
MESSAGE_BEGIN( MSG_ONE, gmsgInitHUD, NULL, pev
);
MESSAGE_END();
g_pGameRules->InitHUD( this );
m_fGameHUDInitialized = TRUE;
if ( g_pGameRules->IsMultiplayer() )
{
FireTargets( "game_playerjoin", this,
this, USE_TOGGLE, 0 );
}
}
FireTargets( "game_playerspawn", this, this, USE_TOGGLE,
0 );
CBaseEntity* pMapType = NULL;
pMapType = UTIL_FindEntityByClassname( pMapType,
"hi_maptype" );
MESSAGE_BEGIN( MSG_ONE, gmsgMapType, NULL, pev );
if( pMapType )
WRITE_BYTE(
((CMapType*)pMapType)->m_iMapType );
else
WRITE_BYTE( 5 ); // Otherwise any models
may be used.
MESSAGE_END();
}
On the client-side:
In hud.cpp:
m_MapType.Init();
In hud.h:
class CHudMapType : public CHudBase
{
public:
int m_iMapType;
int Init( void );
int MsgFunc_MapType( const char *pszName, int iSize, void* pbuf
);
};
In hud.h, in the definition of CHud:
CHudMapType m_MapType;
Further down, same place:
int _cdecl MsgFunc_MapType( const char *pszName, int iSize,
void *pbuf );
In maptype.cpp:
DECLARE_MESSAGE( m_MapType, MapType );
int CHudMapType::Init( void )
{
HOOK_MESSAGE( MapType );
gHUD.AddHudElem( this );
return 1;
}
int CHudMapType::MsgFunc_MapType( const char *pszName, int iSize, void*
pbuf )
{
BEGIN_READ( pbuf, iSize );
m_iMapType = READ_BYTE();
return 1;
}
_
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
[hlcoders] Map entities client-side
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
RE: [hlcoders] Making WorldCraft's editing area bigger?
lol... this is a very odd cyclic thread, keeps doubling back on itself... Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Tim Holt > Sent: Wednesday, January 30, 2002 10:55 AM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > Hmm. Must be Matt Boone's Day of Defeat? > > Mugsy _ wrote: > > > Damn you Tim Holt! The one time I feel like posting and you steal my > > thunder! > > > > > > > >> From: "Mugsy _" <[EMAIL PROTECTED]> > >> Reply-To: [EMAIL PROTECTED] > >> To: [EMAIL PROTECTED] > >> Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > >> Date: Wed, 30 Jan 2002 03:34:58 -0800 > >> > >> > >> You can use one trick.. > >> > >> Make a giant func_door that starts inside the editing space, but moves > >> outside on game start. Of course you can't actually run out there. > >> > >> Apparently thats how one of our beach maps got so darn huge. > >> > >> Mugsy > >> Day of Defeat > >> > >>> From: "botman" <[EMAIL PROTECTED]> > >>> Reply-To: [EMAIL PROTECTED] > >>> To: <[EMAIL PROTECTED]> > >>> Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > >>> Date: Tue, 29 Jan 2002 16:40:40 -0600 > >>> > >>> > Which has one minor flaw - Worldcraft itself won't make maps that > >>> big... > >>> > >>> But there are other Quakeish Level Editors that are Open Source. > >>> Download > >>> these and modify them to your hearts content. > >>> > >>> Jeffrey "botman" Broome > >>> > >>> ___ > >>> To unsubscribe, edit your list preferences, or view the list archives, > >>> please visit: > >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >> > >> > >> _ > >> Join the world's 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 > >> > > > > > > _ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > I think...I think it's in my basement. Let me go upstairs and check. > -M.C. Escher > > ___ > 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] Making WorldCraft's editing area bigger?
JD, perhaps another idea instead would be to make the size of the player models smaller. After all, if a unit represents six inches rather than one, it's a much bigger space. Or is this a pure mapping question? Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of HateFace > Sent: Monday, January 28, 2002 5:55 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > Yeah, I did that door trick with my desert map. But, I didn't wanna just > do > that, I wanted to let the players actually run around way out there, and > hide out there...and just play out there. > > Oh well, if it's not possible, I'll just stick with the limit. > > JD > > > - Original Message - > From: "Tim Holt" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, January 28, 2002 5:31 PM > Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > > > Well you might be able to make it bigger, but what do you do when you > > compile and your build tools say you've got a brush taht goes beyond the > > +/-4096 limit? > > > > There is one trick people have done. Make a large brush that represents > > terrain or whatever you want beyond the "edge". Now make the brush a > > func_door. THen trigger the door to "move". Such items can go outside > > the +/-4096 limit and still will be drawn. > > > > The new DoD 2.0 map "dog1" does this. It visually extends the beach and > > water of the map beyond the "edge". > > > > > > HateFace wrote: > > > > > No, not Gearcraft... > > > > > > I read somewhere that you can make the editing area bigger for > Worldcraft. > > > I thought it said something about the registry, but I'm not sure. > Anyway > > > know how? > > > > > > JD > > > > > > > > > - Original Message - > > > From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Monday, January 28, 2002 4:56 PM > > > Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > > > > > > > > > > >>Not GearCraft? > > >> > > >> > > >>- Original Message - > > >>From: "HateFace" <[EMAIL PROTECTED]> > > >>To: <[EMAIL PROTECTED]> > > >>Sent: Monday, January 28, 2002 11:49 PM > > >>Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > >> > > >> > > >> > > >>>I thought I read somewhere that you can make it bigger with this > newer > > >>>Worldcraft. > > >>> > > >>>JD > > >>> > > >>> > > >>>- Original Message - > > >>>From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> > > >>>To: <[EMAIL PROTECTED]> > > >>>Sent: Monday, January 28, 2002 4:28 PM > > >>>Subject: Re: [hlcoders] Making WorldCraft's editing area bigger? > > >>> > > >>> > > >>> > > >>>>decompile? > > >>>> > > >>>>- Original Message - > > >>>>From: "HateFace" <[EMAIL PROTECTED]> > > >>>>To: <[EMAIL PROTECTED]> > > >>>>Sent: Monday, January 28, 2002 10:27 PM > > >>>>Subject: [hlcoders] Making WorldCraft's editing area bigger? > > >>>> > > >>>> > > >>>> > > >>>>>I want to make a big map. I need to make WorldCraft's editing area > > >>>>>bigger...how do I do this? > > >>>>> > > >>>>>JD > > >>>>> > > >>>>> > > >>>>>___ > > >>>>>To unsubscribe, edit your list preferences, or view the list > > >>>>> > > > archives, > > > > > >>>>please visit: > > >>>> > > >>>>>http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >>>>> > > >>>>> > > >>>>> > > >>>>___ > > >>>>To unsubscribe,
RE: [hlcoders] Studiomdl errors
Nm, talked to randomnine on IRC. I just
had to increase MAXSTUDIOANIMATIONS in studio.h… Sorry about that, sometimes it’s
just right in front of your nose.
Persuter
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Persuter
Sent: Saturday,
January 26, 2002
5:26
PM
To:
[EMAIL PROTECTED]
Subject: RE: [hlcoders] Studiomdl
errors
Forgot to mention… the problem is almost
certainly not lack of physical memory. It’s been tested on two comps, one with
640 megs of memory, and the other with 1024, and the same error occurs in both.
Persuter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Persuter
Sent: Saturday,
January 26, 2002
5:15
PM
To:
[EMAIL PROTECTED]
Subject: [hlcoders] Studiomdl
errors
OK, so my animator’s gone a bit overboard
and has produced 86 megabytes of SMDs. When we run studiomdl, it grabs all the
smds but at the point where it should be displaying the BMP file names, it
crashes out with:
d:/ani/HI/histealth//H6AœFBðVCDgD˜wEì‡F@˜G”¨Hè¸I<ÉJÙKäéL8úMŒ
OàP4+Qˆ;RÜKS0\T„lUØ|V,W€XÔY(¾Z|Î[ÐÞ\$ï]xÿ^Ì` at0bÈ@c QdpaeÄqf‚gl’hÀ¢i³jhÃk
not found
OK, obvious sort of memory error. The
problem is something is overwriting texture[] with its own values. I track down
the source, and I find that it is line 2754 in studiomdl.c that is overwriting
the values:
for
(i = 0; i < numblends; i++)
{
panimation[numani]
= kalloc( 1, sizeof( s_animation_t ) ); ß This is the bad line here
sequence[numseq].panim[i]
= panimation[numani];
sequence[numseq].panim[i]->startframe
= start;
sequence[numseq].panim[i]->endframe
= end;
sequence[numseq].panim[i]->flags
= 0;
Option_Animation(
smdfilename[i], panimation[numani] );
numani++;
}
kalloc being the following function:
void *kalloc( int num, int size )
{
//
printf( "calloc( %d, %d )\n", num, size );
//
printf( "%d ", num * size );
k_memtotal
+= num * size;
return
calloc( num, size );
}
The problem seems to generally occur when
k_memtotal is around 78,000,000.
OK, so I have several questions. First,
the value kalloc returns is 0x0595caf8, nowhere near the 0x0b00790 values that
it is overwriting (the actual values, of course, change every now and then, but
they don’t seem very close at all). So why the hell is it overwriting my
texture values? Secondly, how can I fix it?
Another seemingly very odd thing is the
tendency of the program to overwrite texture[x].ppicture with the name of an
animation, like hold_car_down_center. I suppose this is probably because it’s
overwriting it with a pointer, but again, the pointer is always something like
0x059b1df0. I’m just not as up on C memory management as I should be, I admit.
Is this fixable? Anyone?
Of course, if you have any questions
whatsoever about the problem, please let me know.
Persuter
Coding Lead
Hostile Intent
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
RE: [hlcoders] Studiomdl errors
Forgot to mention… the problem is almost
certainly not lack of physical memory. It’s been tested on two comps, one with
640 megs of memory, and the other with 1024, and the
same error occurs in both.
Persuter
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Persuter
Sent: Saturday,
January 26, 2002
5:15
PM
To:
[EMAIL PROTECTED]
Subject: [hlcoders] Studiomdl
errors
OK, so my animator’s gone a bit overboard
and has produced 86 megabytes of SMDs. When we run studiomdl, it grabs all the
smds but at the point where it should be displaying the BMP file names, it
crashes out with:
d:/ani/HI/histealth//H6AœFBðVCDgD˜wEì‡F@˜G”¨Hè¸I<ÉJÙKäéL8úMŒ
OàP4+Qˆ;RÜKS0\T„lUØ|V,W€XÔY(¾Z|Î[ÐÞ\$ï]xÿ^Ì` at0bÈ@c QdpaeÄqf‚gl’hÀ¢i³jhÃk
not found
OK, obvious sort of memory error. The
problem is something is overwriting texture[] with its own values. I track down
the source, and I find that it is line 2754 in studiomdl.c that is overwriting
the values:
for
(i = 0; i < numblends; i++)
{
panimation[numani]
= kalloc( 1, sizeof( s_animation_t ) ); ß This is the bad line here
sequence[numseq].panim[i]
= panimation[numani];
sequence[numseq].panim[i]->startframe
= start;
sequence[numseq].panim[i]->endframe
= end;
sequence[numseq].panim[i]->flags
= 0;
Option_Animation(
smdfilename[i], panimation[numani] );
numani++;
}
kalloc being the following function:
void *kalloc( int num, int size )
{
//
printf( "calloc( %d, %d )\n", num, size );
//
printf( "%d ", num * size );
k_memtotal
+= num * size;
return
calloc( num, size );
}
The problem seems to generally occur when
k_memtotal is around 78,000,000.
OK, so I have several questions. First,
the value kalloc returns is 0x0595caf8, nowhere near the 0x0b00790 values that
it is overwriting (the actual values, of course, change every now and then, but
they don’t seem very close at all). So why the hell is it overwriting my
texture values? Secondly, how can I fix it?
Another seemingly very odd thing is the
tendency of the program to overwrite texture[x].ppicture with the name of an
animation, like hold_car_down_center. I suppose this is probably because it’s
overwriting it with a pointer, but again, the pointer is always something like
0x059b1df0. I’m just not as up on C memory management as I should be, I admit.
Is this fixable? Anyone?
Of course, if you have any questions
whatsoever about the problem, please let me know.
Persuter
Coding Lead
Hostile Intent
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
[hlcoders] Studiomdl errors
OK, so my animator’s gone a bit overboard
and has produced 86 megabytes of SMDs. When we run studiomdl, it grabs all the smds
but at the point where it should be displaying the BMP file names, it crashes
out with:
d:/ani/HI/histealth//H6AœFBðVCDgD˜wEì‡F@˜G”¨Hè¸I<ÉJÙKäéL8úMŒ
OàP4+Qˆ;RÜKS0\T„lUØ|V,W€XÔY(¾Z|Î[ÐÞ\$ï]xÿ^Ì` at0bÈ@c QdpaeÄqf‚gl’hÀ¢i³jhÃk
not found
OK, obvious sort of memory error. The
problem is something is overwriting texture[] with its
own values. I track down the source, and I find that it is line 2754 in studiomdl.c that is overwriting the values:
for (i = 0; i
< numblends; i++)
{
panimation[numani] = kalloc( 1, sizeof( s_animation_t ) ); ß This is the bad line here
sequence[numseq].panim[i]
= panimation[numani];
sequence[numseq].panim[i]->startframe = start;
sequence[numseq].panim[i]->endframe = end;
sequence[numseq].panim[i]->flags
= 0;
Option_Animation( smdfilename[i], panimation[numani] );
numani++;
}
kalloc being
the following function:
void *kalloc( int
num, int size )
{
//
printf(
"calloc( %d, %d )\n", num, size );
//
printf(
"%d ", num * size );
k_memtotal += num * size;
return calloc( num, size );
}
The problem seems to generally occur when k_memtotal is around 78,000,000.
OK, so I have several questions. First,
the value kalloc returns is 0x0595caf8, nowhere near
the 0x0b00790 values that it is overwriting (the actual values, of course,
change every now and then, but they don’t seem very close at all). So why the
hell is it overwriting my texture values? Secondly, how can I fix it?
Another seemingly very odd thing is the
tendency of the program to overwrite texture[x].ppicture
with the name of an animation, like hold_car_down_center.
I suppose this is probably because it’s overwriting it with a pointer, but
again, the pointer is always something like 0x059b1df0. I’m just not as up on C
memory management as I should be, I admit. Is this fixable? Anyone?
Of course, if you have any questions
whatsoever about the problem, please let me know.
Persuter
Coding Lead
Hostile Intent
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
RE: [hlcoders] Basic Problem, many a hairs lost!
I dunno if you typed this in, but if you copy/pasted it, it should be
size = particle[i1].size / 2;
not paricle[i1].size.
And what line is the compiler pointing at?
Persuter
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Philip Plante
> Sent: Friday, January 18, 2002 7:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Basic Problem, many a hairs lost!
>
> Funny thing when I tried that it fixed the error. So what if i paste
the
> whole func here:
>
> void ParticleSystem::Render(void)
> {
> float size;
> Vector vert, temporg, pos, viewangles;
>
> gEngfuncs.pTriAPI->RenderMode(kRenderTransAdd);
>
>
> cl_entity_t *player = gEngfuncs.GetLocalPlayer();
> if (!player) return;
>
> vec3_t v_up, v_forward, v_right;
> gEngfuncs.GetViewAngles( (float *)viewangles );
> AngleVectors(viewangles, v_forward, v_right, v_up);
>
> for(int i1 = 0; i1 < MAX_PARTICLES; i1++)
> {
> size = paricle[i1].size / 2;
> particle[i1].color[4] = particle[i1].alpha;
> // Draw code here
> }
> }
>
>
> Thanks :)
>
> - Original Message -
> From: "botman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 18, 2002 2:58 PM
> Subject: Re: [hlcoders] Basic Problem, many a hairs lost!
>
>
> > > Ok when I try to compile my particle engine code I am for
somereason
> > getting:
> > > error C2143: syntax error : missing ')' before ';'
> > > on this code:
> > > void ParticleSystem::Render(void)
> > > {
> > >
> > > int i;
> > > while( i < MAX_PARTICLES)
> > > {
> > > /*code*/
> > > }
> > > }
> > >
> > > But I dont know why the hell its doing that Any clues why it is?
> >
> > I suspect your error is actually caused by a line further up in your
> code.
> > The compiler is just recovering from the error at the it is showing
you.
> > I'll bet if you comment out that whole block (all code shown), you
will
> > still get the error in something later on in the file.
> >
> > 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
_
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] LOD stuff
Well yeah I am planning to do that, but it'd be nice to have some code there to look at while I'm doing it... :) Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of omega > Sent: Sunday, December 02, 2001 8:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] LOD stuff > > dunno about what he did, but i can tell you the simple way to do it.. > use a few body groups, 3 for example for the simple way. 0 = highest > detail > 3 = lowest. > then inside the studio code on the client > do a dotproduct/distance/fov check and force the bodies on all models > based > on how far away they are, relative to your fov. and while yer at it, use > the > same system to see if something is even on screen. if its not, dont render > it at all. heh > > -omega > Blackened Interactive > http://www.nofadz.com/blackened > - Original Message - > From: "Persuter" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, December 02, 2001 5:05 PM > Subject: [hlcoders] LOD stuff > > > > Hey Nusco, I know you released some files dealing with the Holywars LOD > > technology. Is that available for download anywhere? I seem to have lost > > my own copy of it, depressingly enough, and I now find myself working on > > a mod where I really need it. > > > > Thanks for any help. > > > > > > 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 > > > > ___ > 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] LOD stuff
Ha ha ha it is VERY sekrat Seriously, we're trying to develop it under wraps a bit, but basically it takes place in large urban areas with many cars and civilians about, so it's either LOD tech or pretty empty streets... Persuter > -Original Message- > From: [EMAIL PROTECTED] [mailto:hlcoders- > [EMAIL PROTECTED]] On Behalf Of Oskar 'Zoot' Lindgren > Sent: Sunday, December 02, 2001 4:11 PM > To: [EMAIL PROTECTED] > Subject: Re: [hlcoders] LOD stuff > > What type of mod are you going to make? > > - Original Message - > From: "Persuter" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, December 02, 2001 11:05 PM > Subject: [hlcoders] LOD stuff > > > > Hey Nusco, I know you released some files dealing with the Holywars LOD > > technology. Is that available for download anywhere? I seem to have lost > > my own copy of it, depressingly enough, and I now find myself working on > > a mod where I really need it. > > > > Thanks for any help. > > > > > > 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 > > > > > > ___ > 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
[hlcoders] LOD stuff
Hey Nusco, I know you released some files dealing with the Holywars LOD technology. Is that available for download anywhere? I seem to have lost my own copy of it, depressingly enough, and I now find myself working on a mod where I really need it. Thanks for any help. 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
