Re: [hlcoders] A very fast novel game based on tf2 sdk, and makin money by sharing freely counterintuitively like billy
Seriously? I find his concerns about the speed of C# on 64 bit machines running under a D3D based interpreter to be highly insightful. And p2p in clients in Source, he may well be pushing the Source engine into a whole new era. Who are you guys to hold back such progressive ideas? On Mon, Oct 31, 2011 at 12:28 AM, Jonathan Murphy nuclearfri...@gmail.comwrote: Bot theory seems plausible especially because he ignores all our attempts to talk to him. :( On Sun, Oct 30, 2011 at 11:42 PM, Jan Hartung jan.hart...@gmx.de wrote: I’m almost certain that it’s a bot concatenating a bunch of loosely connected strings to build lenghty mails. ** ** Jan ** ** *Von:* hlcoders-boun...@list.valvesoftware.com [mailto: hlcoders-boun...@list.valvesoftware.com] *Im Auftrag von *Tony omega Sergi *Gesendet:* Sonntag, 30. Oktober 2011 03:53 *An:* Discussion of Half-Life Programming *Betreff:* Re: [hlcoders] A very fast novel game based on tf2 sdk, and makin money by sharing freely counterintuitively like billy ** ** This is the one and only time that i'm going to reply to anything you've said, *Pro-Tip*: Don't Post here when you're High. You make no sense 100% of the time. -Tony On Sun, Oct 30, 2011 at 5:11 AM, Sam aersi...@gmail.com wrote: just thought of this...one 'new' game based on tf2 might be simply modding the #s for the user. One option is increasing hitpoints and decreasing dmg for longer battles* *** ** ** ___ 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] Linux build prediction? issues
Originally I had thought it would have been fixed with the IsFirstTimePredicted check as well, but even with that, I found our frames were being rolled back and for whatever reason the system wasn't marking the already predicted frames as handled, or at least resetting it. We wrapped a test case in the base MP5 provided with the SDK and could recreate the prediction issues consistently, so might have run that by the latest SDK and see if it still happens. On Mon, Jan 24, 2011 at 11:11 PM, Nick xnicho...@gmail.com wrote: If it is a problem with the valve sdk, then don't even try to fix it, track the problem down, send valve a detailed report, and hope for the best. On Mon, Jan 24, 2011 at 3:06 PM, Maarten De Meyer maar...@off-limits.be wrote: I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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
Re: [hlcoders] Linux build prediction? issues
I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.bewrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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] Duplicate Keys with KeyValues
In the file you can just add more
gamelist
{
AdditionalID120
AdditionalID121
AdditionalID122
AdditionalID123
}
and then parse it out in code using a sub key iteration. If you want to add
duplicates in code I think it's a case of just create new key values with
the values add them as sub keys instead of doing the set methods.
On Tue, Nov 16, 2010 at 1:56 AM, Trevor 'Drak' dhlco...@wowway.com wrote:
File structure:
mount_list.txt
{
gamelist
{
AdditionalID120
}
}
If I wanted to add another “AdditionalID” with a different value, how can I
do this?
This, just replaces the key.
KeyValues *pNew = pMainFile-FindKey( GameList );
pNew-SetInt( AdditionalID, 200 );
___
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] Creating VGUI Menus with tabs?
pffft roll you're own, it's what all the cool kids do. On Sat, Nov 13, 2010 at 12:09 PM, Tony omega Sergi omegal...@gmail.comwrote: PropertyDialog. you create inherit PropertyPage for your panel, and add them to a PropertyDialog. -Tony On Sat, Nov 13, 2010 at 7:45 AM, Trevor 'Drak' dhlco...@wowway.com wrote: That's correct, it's used in the MP3 Player example. My bad, thank you! :D -Original Message- From: Saul Rennison Sent: Friday, November 12, 2010 5:32 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Creating VGUI Menus with tabs? It's a VGUI control called PropertySheet I think :D Thanks, - Saul. On 12 November 2010 22:20, Trevor 'Drak' dhlco...@wowway.com wrote: Simple question. I want to create a VGUI Panel with a list of tabs at the top. Example: http://img2.imageshack.us/img2/8057/sfasd.jpg 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 5615 (20101112) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -Tony ___ 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] Engine API?
There's a fair few doxygen's out there but in reality most people just ge their hands dirty by following the SDK classes. The only tricky parts of the SourceSDK would be the NPCs in the singleplayer, beyond that the SDK for multiplayer really implements skeletal stuff to start rooting around with almost immediately available examples of networking and entity IO. That's assuming gameplay is your biggest focus. The VGUI stuff is roughly fleshed out in the SDK panels too, even if it's not got many examples of how to make the most of the messaging beyond OnCommand, but you can pull out the majority of what you need to learn by starting with this those. Beyond that, if you're looking to do a lot of shader work you just have to figure out the limitations before trying anything too crazy, and if you want to replace BSP with dynamic data loading and procedural terrain generation you're going to be one sad panda that Valve aren't likely to impress with the SourceSDK. On Thu, Sep 2, 2010 at 12:22 PM, Tom Edwards t_edwa...@btinternet.comwrote: Yes, there's doxygen and there are several instances of it being used on the SDK (at various points) to be found online. The best solution is to open Visual Studio and use Class View, though. On 02/09/2010 12:12, Colm Sloan wrote: a mod-friendly company like valve questionable ;) I'd really like to see this too. Is there some program that can be run on a C/C++ project to extract this information and create such a reference document automatically? I almost sure I remember using something like this for a java program I made some time back. ___ 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] Engine API?
That's all available to the SDK, the tricky part I mentioned was more that it's written for Valve's games, rather than, like the SDK for MP the modders. So you just have to pick your starting point on your own, whether it be Alyx, Zombies etc.. There's nothing particularly engine specific for the AI for the most part it's all there for you to dabble with. On Thu, Sep 2, 2010 at 12:54 PM, Chris Courtney chriscourtne...@gmail.comwrote: What are the NPC limitations in terms of code? Is it that the interface for that part of the engine is very limited or is it just difficult to root through and understand the order of whats happening? I plan on doing a lot of custom AI stuff with models. Was just playing episode 2 and notice they've implemented a proper look at player thing for alex where she dynamically turns her head and then her body which is something I'll be using. Sorry I rambed... basically what sort of trouble is ahead in the NPC area for single player? Thanks for the help guys :) On Thu, Sep 2, 2010 at 12:40 PM, hlcoders-requ...@list.valvesoftware.com wrote: Send hlcoders mailing list submissions to hlcoders@list.valvesoftware.com To subscribe or unsubscribe via the World Wide Web, visit http://list.valvesoftware.com/mailman/listinfo/hlcoders or, via email, send a message with subject or body 'help' to hlcoders-requ...@list.valvesoftware.com You can reach the person managing the list at hlcoders-ow...@list.valvesoftware.com When replying, please edit your Subject line so it is more specific than Re: Contents of hlcoders digest... Today's Topics: 1. Re: Does Valve (America) offers internships? (Andrew Ritchie) 2. Re: linux binary compiling issues, missing reference (Nick) 3. Engine API? (Chris Courtney) 4. Re: Engine API? (Jonas 'Sortie' Termansen) 5. Re: Engine API? (Colm Sloan) 6. Re: Engine API? (Tom Edwards) 7. Re: Engine API? (Andrew Ritchie) -- Message: 1 Date: Wed, 1 Sep 2010 23:01:38 +0100 From: Andrew Ritchie gotta...@gmail.com Subject: Re: [hlcoders] Does Valve (America) offers internships? To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Message-ID: aanlktiktt78anqech0tgdc16s9zhcjddaoqqy26+c...@mail.gmail.comaanlktiktt78anqech0tgdc16s9zhcjddaoqqy26%2bc...@mail.gmail.com aanlktiktt78anqech0tgdc16s9zhcjddaoqqy26%2bc...@mail.gmail.comaanlktiktt78anqech0tgdc16s9zhcjddaoqqy26%252bc...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 goodness no, Somone is one of the most honest people I know. Minh on the other hand is a Grade A Canadian Liar... LIAR I says. And now I have to go change his wikipedia entry to say so, otherwise, who else but this list would know?! On Wed, Sep 1, 2010 at 2:08 PM, Jeffrey botman Broome botman.hlcod...@gmail.com wrote: WHAT? Are you calling somone on the internets a liar? How dare you sir. How dare you. :) On 8/31/2010 7:22 PM, Andrew Ritchie wrote: Liar On Tue, Aug 31, 2010 at 7:17 PM, Minh Leminh...@telus.net wrote: now in FixKorea? Unfortunately, yes. On 8/31/2010 6:23 AM, WRNM wrote: Oh, sorry I went serious =_=. BTW Just for curiosity, Are you the 'Minh Le' now in FixKorea? Richard Date: Tue, 31 Aug 2010 00:41:29 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? I don't believe there is a branch in Siberia. I was just poking fun at you because I found it amusing that you put America in brackets next to Valve. Everyone knows there is only one Valve, and its location is Mt. Olympus. On 8/30/2010 8:08 PM, Trevor 'Drak' wrote: I think he was kidding, because you added (America) -- From: WRNMassaultar...@hotmail.com Sent: Monday, August 30, 2010 10:53 PM To:hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? U. Is there a branch/studio in Siberia? Date: Mon, 30 Aug 2010 10:12:22 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? You might wanna try Valve (Siberia)... On 8/30/2010 6:35 AM, WRNM wrote: Hey guys, I don't really know if this is the right place or not but I'm wondering if Valve provides any chances for internships? I am currently a sophomore student majoring in Math. I can do some programming but I'm better in 3D/2D Art stuff. Just looking for some game development work experience, and of course I'm happy to do it for free. Please let me know if there's anything I can do
Re: [hlcoders] Does Valve (America) offers internships?
goodness no, Somone is one of the most honest people I know. Minh on the other hand is a Grade A Canadian Liar... LIAR I says. And now I have to go change his wikipedia entry to say so, otherwise, who else but this list would know?! On Wed, Sep 1, 2010 at 2:08 PM, Jeffrey botman Broome botman.hlcod...@gmail.com wrote: WHAT? Are you calling somone on the internets a liar? How dare you sir. How dare you. :) On 8/31/2010 7:22 PM, Andrew Ritchie wrote: Liar On Tue, Aug 31, 2010 at 7:17 PM, Minh Leminh...@telus.net wrote: now in FixKorea? Unfortunately, yes. On 8/31/2010 6:23 AM, WRNM wrote: Oh, sorry I went serious =_=. BTW Just for curiosity, Are you the 'Minh Le' now in FixKorea? Richard Date: Tue, 31 Aug 2010 00:41:29 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? I don't believe there is a branch in Siberia. I was just poking fun at you because I found it amusing that you put America in brackets next to Valve. Everyone knows there is only one Valve, and its location is Mt. Olympus. On 8/30/2010 8:08 PM, Trevor 'Drak' wrote: I think he was kidding, because you added (America) -- From: WRNMassaultar...@hotmail.com Sent: Monday, August 30, 2010 10:53 PM To:hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? U. Is there a branch/studio in Siberia? Date: Mon, 30 Aug 2010 10:12:22 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? You might wanna try Valve (Siberia)... On 8/30/2010 6:35 AM, WRNM wrote: Hey guys, I don't really know if this is the right place or not but I'm wondering if Valve provides any chances for internships? I am currently a sophomore student majoring in Math. I can do some programming but I'm better in 3D/2D Art stuff. Just looking for some game development work experience, and of course I'm happy to do it for free. Please let me know if there's anything I can do about it. Thanks, Richard ___ 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 ___ 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] Does Valve (America) offers internships?
Liar On Tue, Aug 31, 2010 at 7:17 PM, Minh Le minh...@telus.net wrote: now in FixKorea? Unfortunately, yes. On 8/31/2010 6:23 AM, WRNM wrote: Oh, sorry I went serious =_=. BTW Just for curiosity, Are you the 'Minh Le' now in FixKorea? Richard Date: Tue, 31 Aug 2010 00:41:29 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? I don't believe there is a branch in Siberia. I was just poking fun at you because I found it amusing that you put America in brackets next to Valve. Everyone knows there is only one Valve, and its location is Mt. Olympus. On 8/30/2010 8:08 PM, Trevor 'Drak' wrote: I think he was kidding, because you added (America) -- From: WRNMassaultar...@hotmail.com Sent: Monday, August 30, 2010 10:53 PM To:hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? U. Is there a branch/studio in Siberia? Date: Mon, 30 Aug 2010 10:12:22 -0700 From: minh...@telus.net To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Does Valve (America) offers internships? You might wanna try Valve (Siberia)... On 8/30/2010 6:35 AM, WRNM wrote: Hey guys, I don't really know if this is the right place or not but I'm wondering if Valve provides any chances for internships? I am currently a sophomore student majoring in Math. I can do some programming but I'm better in 3D/2D Art stuff. Just looking for some game development work experience, and of course I'm happy to do it for free. Please let me know if there's anything I can do about it. Thanks, Richard ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] client side grame frame
plugin_load only works on the server. The client has no knowledge of it.
You certainly can load them on a listen server but they only interact with
the game dll and not the client dll and it's subsiquent systems.
On Mon, Jan 4, 2010 at 7:06 AM, Joe Cabezas joe.cabe...@gmail.com wrote:
nope
clients DO LOAD plugins... via console commmand plugin_load...
ok, that's not the main question.
how to run commands every frame/tick in client?
2010/1/4 Andrew Ritchie gotta...@gmail.com
Quite simply the client does not load or run plug ins. If you were
making
your own mod then you could add a client side system that loads and runs
them ever tick, but the client engine does not expose any systems to run
plug in type features and no Valve game is likely to offer such a
feature.
On Mon, Jan 4, 2010 at 4:42 AM, Joe Cabezas joe.cabe...@gmail.com
wrote:
i know i can't!, actually i know that i'm doing a server solution, my
question is: how to make it work in a client plugin?
maybe threads?, thinks?, how?
2010/1/4 Olly oli...@gmail.com
You can't. Its a server plugin: CEmpty*Server*Plugin
2010/1/4 Joe Cabezas joe.cabe...@gmail.com
hello!
i want to execute some functions in a CLIENT SIDE PLUGIN, for
tf2...
with
no
results
this is what i'm doing:
void CEmptyServerPlugin::GameFrame( bool simulating )
{
Msg(this is a frame!);
}
but, it only works when i create a server, and not when i join a
server...
how can i access to a client-side gameframe event?
___
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] Inherited gamerules not transfering CNetworkVars
it's a bit messy looking but assert in release mode usually replaces with
nothing or in Source's case ((void)0) instead of the expression. So aslong
as you don't go messing with enabling asserts in release and don't use the
pEnt the compiler can live with it without erroring. Might get a warning
though.
What might be a better usage would be
...
g_pLastRebelSpawn = NULL;
Verify( CBaseEntity::Create( new_gamerules, vec3_origin, vec3_angle ) );
}
but it's also Valve's own code so no point going to nuts over it.
On Wed, Nov 4, 2009 at 1:18 PM, Jonas 'Sortie' Termansen
hlcod...@maxsi.dkwrote:
How can that possibly work, or compile? The pEnt is defined in _DEBUG
but you assert it in the non-_DEBUG build. Doesn't that throw a warning?
void CNewGameRules::CreateStandardEntities( void )
{
#ifndef CLIENT_DLL
CGameRules::CreateStandardEntities();
g_pLastCombineSpawn = NULL;
g_pLastRebelSpawn = NULL;
#ifdef _DEBUG
CBaseEntity *pEnt =
#endif
CBaseEntity::Create( new_gamerules, vec3_origin, vec3_angle );
Assert( pEnt );
#endif
}
___
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] Do high ping players cause extra lag?
Extra load on servers would imply a 100 ping player and a 500 ping player require different amounts of processing. The 2 obvious places this could potentially occur in Source are the think/movement calculations on each packet and rewinding players in prediction for the shot calculations. The former *might* be an issue if Source calculates and runs every individual command packet and accumulates them between tick frames. However that'd not be any more or less packets to calculate for someone with a higher ping, it would just mean their commands arrive later. If there's a lot of choke or backup in deliveries then it might be a case of they all arrive and are processed at one time. That all boils down to the individual engines' handling of packets, worst case would also be if an engine waited on and demanded synchronized packet order which could throw a spanner in the works on a dodgey connection, and that is really dependent on the networking model the developers chose. I'm sure you already know all that, so just confirming that there's a lot of different things that could potentially cause high pings to upset a game server. However if it's a consistent connection most people will just be complaining because prediction isn't perfect and extrapolation on high latency players will be more prone cause noticeable divergences from actual data from time to time. On Tue, Oct 13, 2009 at 1:23 PM, Marek Sieradzki marek.sierad...@gmail.comwrote: HL1 is ancient. ___ 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] terrains...finally its here:)
The purpose in this is what? Are you proposing you could have single handedly removed all of Source's BSP requirements, improved Source's geometry streaming, created that full terrain system and ensured it worked with the other game systems by yourself within a year? It looks very nice, the fact you did it in only a year is very cool, though if you look at the likes of Alan Wake, Crysis, Unreal they all have great terrain features, yet TF2 wouldn't be any better on it. In theory you could build your own terrain system within source already however it's still not an engine design for expansive out door exploration so even with your amazing demo Valve won't change anything until they need to. Again, very well done on writing your terrain engine and all but if this is an i told you so you'll probably want to get a few sales under your belt and then come back to it. On Fri, Oct 2, 2009 at 9:23 PM, Adam Donovan adamjjdono...@gmail.comwrote: so yeah I rant on about terrains systems..had to go and work for a game company to actually get things moving in the direction I wanted...glad I didnt just wait for valve to make one:) So after about a year working on this part time I can show off our new terrain engine...Highest res engine for terains I know of..less that half a meter pixel res.. i would have done this for Valve but they never sounded interested:P chuckle chuckle..Probably going to get shit for being so cocky now..oh I guess my spelling will come up again too haha http://tinyurl.com/ybhyyje Nav ___ 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] Modelling upheaval: Maya, DMX, XSI, Blender
Unreal Tournament 2003 shipped with a version of Maya, the PLE, so there may be something similar still available. On Mon, Sep 21, 2009 at 1:35 PM, Tom Edwards t_edwa...@btinternet.comwrote: The release of the Heavy model sources (which is excellent BTW) has confirmed that Valve's modellers now use Maya, and revealed the quasi-binary DMX format as the successor to SMD. What does this mean for XSI support, particularly the Mod Tool? Its exporter has needed updating for a long time, mainly in terms of UI but also core functionality. I'm sure the Maya plugin is an improvement on all fronts but it's no help to most modders, as Maya doesn't have a free Mod Tool equivalent. I'm also a little wary about DMX, since it can't be easily understood by someone wanting to write a new exporter. Can we (and by we I mostly mean Jed of course) see a spec for it? Does it support new features that SMD does not? The good news is that there's a new Blender exporter out http://dvondrake.com/scripts/blendersmd that does everything except VTA. Blender may have to become the new modder's choice for Source, which, as much as I like it, isn't ideal given the exotic UI. ___ 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] In game map editing
What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. Thanks, Vbitz ___ 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] In game map editing
VMF != BSP You CAN reference brushes and things back to the VMF from a BSP but I'd suggest you go and do a little more reading and file browsing to see why what you are suggesting would require the elimination of seperate file formats and if you want it in real time either an massive overhaul of the RAD calculation or full transition to dynamic lighting. On Sat, Sep 12, 2009 at 11:07 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Well the vmf file contains alot of data and it is easy to draw the brushs but you can still not do lighting without alot of extra work on valves part. from what i know we can have a map load draw brushs and put colsision physics on it, is that not something that can be doen with the sdk, anyway the uses of this are opening map editing to more less knolageable players wanting to make a map. Andrew Ritchie wrote: What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. Thanks, Vbitz ___ 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] Lines of code in Source SDK?
400k+ Depending on what you define as code it could be much more but there's atleast that. Only within the Client and Server projects, and it's always up for debate how much of it is functionally part of each project. On Wed, Aug 19, 2009 at 1:34 AM, Adam Buckland adamjbuckl...@gmail.comwrote: Just a quick question: How many lines of code would you estimate, make up the Source SDK? -- Bucky ___ 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] whats happening with this engine
Surely this topic could be split into several different points. Personally I see 4 different ones here. 1) Engine features 2) Tools Capabilities 3) Tools Availability 4) Tools Presentation The first is ignorable, Valve is clearly only going to add new features or change things, like BSP and displacement maps, when they think it's important. It's their engine and it needs to do what their games need doing. If you choose to use Source then you have to accept you are modding their engine. Sure TF, CS, DoD etc.. all were mods that made Valve a lot of money and brought huge success but they were also developed around the constraints of the engine rather than the engine being built FOR these mods to be made. If a technical limitation is big enough to warrent an engine change then do so rather than hanging about wanting Valve to add the feature, as big as the previous mentioned mods are you'd need to really prove you're up to their popularity before Valve would make a drastic change for you. So either accept the engine's features before you get underway or be prepared to encounter the fact you can't do certain things without a lot of work, if not at all. The Tools Capabilities I think is what Jed was really getting at, I don't mean like adding features to hammer and stuff but specifically allowing the chance for modders to by pass say model exporting to smd and just use a common format. The tool would need to have the importer and converter written but I personally think that approaching Valve with a specific and industry accepted intermediate format might be a good cause. Especially if it makes life easier for getting the raw assets into a format that the tool can then use. With the availability of tools, I mean those asking that they be open source. Specifically referring to a comment about hammer, look at Worldcraft and BSP ( Yahn's editor iirc ) they were originally personal projects. So you could take a leaf and have a bash at your own editor and open source it, you never know might turn out to be a better designed tool. However just having the source code to hammer, I doubt would be of any benefit, you'd have dozens of versions of the tool floating around and do you really think you could add something useful to it? It may have bugs but if you advocate open source then why not take the initiative and lead by example? The last one, has been brought up in regards to wrapping a tool with a UI or removing the need for QC files. With this I think the issue is balancing the technical knowledge and the capabilities of a tool. However I feel it again falls back to a situation where Valve are happy to use it the way it is, they understand it and can get any of their tools to do what they need. It's the new, non technical, or perhaps slightly lazy people who would need that more complex aspects automated for them. I'd refer this back to Hammer, the early days of mapping could often mean rooting around in a hex or text editor and as things progressed and art started needing the technical requirements to be simplified you found map editors hiding away the old formats. Worldcraft and Hammer essentially sit between the user and the BSP, VIS, RAD etc.. compilers. The format they accept might be, at this stage, more heavily tied into hammer but it's still a front end for those. Again perhaps Worldcraft was a special case with Valve gobbling it up, HLMV too, but I think if the community is adamant enough about simplifying and unifying the tool chain then perhaps a bit of proactive development could lead the way or at least prove to Valve that everyone is serious about rethinking the way we interact with the SDK. Ok, sorry bit of a ramble but mainly what I wanted to share was that specific things like adding FBX to the formats studiomdl can accept would be good ventures as they are specific and have an immediately obvious reason. The other stuff like creating a unified system might be something that is best approached with good old community spirit. If you're serious enough about wanting to use the engine but can genuinely improve the way users develop for it then get organized and see if it's a viable thing to tackle. Even if it's just to prove you were right. I know the later is a bit of a cop out but Jed, Nem and NS2 (prior to dropping Source ) are examples of those who have gone out of their way to do so with tools and Garrys mod is a prime example of taking what is available game code wise and adding the extensions (Specifically scriptint) you want. Plus it beats just falling back to the Valve Needs to Support Mods and Valve do whats best for Valve games and mods need to deal with it arguments that go no where. On Fri, Jul 24, 2009 at 11:17 PM, Ben Mears benmea...@gmail.com wrote: As a 3D modeller, animator, and mapper, (and not a coder) I agree with what Jed said 100%. Jed, can you please just go work for Valve? great, thanks! On Fri, Jul 24, 2009 at 12:23 PM, Jed j...@wunderboy.org
Re: [hlcoders] Source SDK Beta Concluded
Botman has won this round of spot the irony. You'd probably be better asking IF and then for the models that they did the Meet The Teams with. Should they be exactly the same as the in game ones then in fairness there's not fixing to improve them from Valve's perspective, as those are quality machinimas. ctf_2fort_extra_wagonwheels_pro_extreme_final2.bsp ftw On Mon, Jun 15, 2009 at 10:46 PM, botman botman.hlcod...@gmail.com wrote: On 6/15/2009 4:31 PM, Matt Hoffman wrote: Am I the only one that finds it ironic that you hate that the map sources are being released because people will fix them, but in the same email ask when the model sources will get releases so you can fix them? :) There is a difference between fixing the maps (arena_2fort_night_fixed_pro_b3) and my fixing of the characters. As it stands, the scout has been fixed. This fixing is not editing the model reference, It's re-compiling the characters with facial flexes so that I can do custom animations, *cough* machinima *cough* etc. Okay, but my point is that you assume that every no-talent so-called level designer will take the map sources and make crappy clones of them polluting servers with these maps. That may be true, but other skilled level designers will take the map sources, examine them and learn ways to things that they didn't know about beforehand (which benefits the community as a whole). Players who don't want the crappy maps will avoid playing on servers that run them. If no one plays on that server, it will shut down or will be at the bottom of the list in the browser. On the other hand, some awesome level designer may take the map, re-texture it using Mario textures or Lego textures and assets and make a custom map that's genuinely fun to play (possibly bringing back players who have left because all of the old maps have become tired and boring). -- 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] Why did VALVe remove almost everything we got in the new SDK beta update?
At the end of the day isn't it Valve who get to decide what tools should be publically available? They might have their reasons or they must just think you had too much stuff in your OB bin folder already. On Fri, Jun 12, 2009 at 10:02 PM, James K jimmy4...@gmail.com wrote: About 2 hours ago we got an update to the SDK beta that included new programs like normal2ssbump.exe and a few others, but then a patch released minutes after removed that and almost 90% of the stuff in my orangebox bin folder. What's the deal VALVe? Don't want us to have tools that should be publicly available? ___ 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] posting
Ironic? On Mon, Apr 27, 2009 at 7:37 PM, Piotr Burzykowski locwo...@gmail.comwrote: Hi, Can we avoid the silliness of another pointless thread? This is spam of the worst kind which the good Valve people will simply skip/delete along with valid threads. Best regards, Piotr Burzykowski LocWorks - Play. Adapt. Disseminate. ___ 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] subject: detecting entities in an area
add a filter entity that only passes on weapon_crowbars and then tie it to a logic counter or whatever they are. most of your problem could be solved through mapping afaik On Fri, Apr 3, 2009 at 8:29 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Are you using a trigger? If so, what are the flags. On Fri, Apr 3, 2009 at 11:32 AM, deadpeacht...@netscape.net wrote: I am trying to make a brush entity that detects a how many of a specific entity (ie weapon_crowbar) are? inside of it. part of my problem is that I cant seem to get it to detect anything inside of it at all. any ideas? ___ 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] Wierd Chatbubble problem
You could just zero out the pitch component of the look vector.
On Sun, Mar 22, 2009 at 10:15 AM, cheeseh-bu chew...@gmail.com wrote:
changing the offset should do it as previously stated, however you want it
to be above the players head, therefore you use the Z axis not the X axis
Vector offset = GetAbsOrigin() + Vector(0,0,92);
this will set the origin for the bubble 92 units above the players
('centre') of origin. Also this will not affect the position if the player
is looking up/down
if you have any more probs can you post/upload screenshots?
-[rcbot]Cheeseh
On Wed, Mar 18, 2009 at 5:55 AM, Yaakov Smith m4ngr...@gmail.com wrote:
I'm implementing the chatbubble in the OB SDK beta, but I ran into a
slight
problem.
When the player is looking down, the bubble is in front of them rotated
to
what I guess is the players origin.
When the player is looking up, the bubble is behind them, rotated as
above.
How do I get it to stay above them?
Code:
#define CHAT_BUBBLE_MODEL models/extras/info_chatbubble.mdl
class CChatBubble : public CBaseAnimating
{
public:
DECLARE_CLASS(CChatBubble, CBaseAnimating);
CChatBubble::CChatBubble()
{
UseClientSideAnimation();
}
virtual void Spawn()
{
SetModel(CHAT_BUBBLE_MODEL);
SetSolid(SOLID_NONE);
SetMoveType(MOVETYPE_NONE);
BaseClass::Spawn();
}
virtual void Precache()
{
PrecacheModel(CHAT_BUBBLE_MODEL);
}
};
LINK_ENTITY_TO_CLASS(chat_bubble, CChatBubble);
PRECACHE_REGISTER(chat_bubble);
void CBasePlayer::MakeChatBubble(int iChatBubble)
{
//Tony; incase there already is one, and another check failed.
if ( m_lifeState != LIFE_ALIVE || GetTeamNumber() == TEAM_SPECTATOR)
{
KillChatBubble();
return;
}
//Tony; don't make new ones if you already have one.
if (m_hChatBubble.Get() != NULL)
return;
Vector fr, rt, up;
AngleVectors(GetAbsAngles(), fr, rt, up);
Vector offset = GetAbsOrigin() + up * 92;
CChatBubble *pBubble = (CChatBubble*)CBaseEntity::CreateNoSpawn(
chat_bubble, offset, GetAbsAngles(), this );
if (pBubble)
{
pBubble-Spawn();
pBubble-FollowEntity(this, false);
m_hChatBubble = pBubble; //Tony; assign it
}
}
void CBasePlayer::KillChatBubble()
{
if (m_hChatBubble.Get() != NULL)
{
m_hChatBubble.Get()-FollowEntity(NULL);
m_hChatBubble.Get()-SetThink(CBaseEntity::Remove);
m_hChatBubble.Get()-SetNextThink(gpGlobals-curtime + 0.001);
m_hChatBubble = NULL;
}
}
void CBasePlayer::CheckChatBubble( CUserCmd *cmd )
{
if (!cmd)
return;
if (cmd-chatenabled)
MakeChatBubble(cmd-chatenabled);
else
KillChatBubble();
}
___
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] Orange Box SDK Beta (Not L4D)
Fail, you'll have to scrap it all and start again. :P Though you probably should format the change log a bit better On Tue, Mar 17, 2009 at 12:50 AM, Tony Sergi to...@valvesoftware.comwrote: Missing, sorry ;) Vmtcheck/vmt_tweak shouldn't have been mentioned either. My bad. -Tony -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto: hlcoders-boun...@list.valvesoftware.com] On Behalf Of James Keith Sent: March-16-09 8:38 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Orange Box SDK Beta (Not L4D) I see no normal2ssbump, where is it? ___ 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] Grenade aftermath sound effect.
Are you refering to the DSP effect? that's found in void CBasePlayer::OnDamagedByExplosion( const CTakeDamageInfo info ) On Sat, Feb 28, 2009 at 3:02 PM, Aditya Gaddam adityagad...@gmail.comwrote: Hi, I've been looking with no result in the GCFs in my steamapps directory to try and find this sound effect. It's the one that you hear when you have a grenade go off next to you. It sounds like a flatline in on an EKG or ringing in your years. Anyone know where this sound is stored or what it's script name is? I followed Grenade::Detonate Explode etc but didn't see where this sound was being played. Thanks, Aditya -- http://www.pixelfaction.com AIM:ApeWithABrain ___ 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] Client-side only model entity that can be bone merged?
We have a load out model that exists only on the client side and the weapon model for this follows a player model... just elaborate on what it does, and the code we use for that weapon setup is. m_pLoadoutWeaponModel-FollowEntity(m_pLoadoutModel, true, m_pLoadoutModel-LookupAttachment( M1_Root )); It works perfectly for our stationary model, though it does play animations and the weapon follows fine, the second parameter being the bone merge, and third come to think of it I don't think M1_Root exists in any of our models so that passes as an invalid attachment. Hope that helps. On Thu, Jan 22, 2009 at 1:20 AM, Tobias Kammersgaard tobias.kammersga...@gmail.com wrote: Isn't the weapon world models something like this? /ScarT (hello Lasershock) 2009/1/22 Jed j...@wunderboy.org To my great dismay and embarrassment I can't seem to get this working... :( I want to make a client-side only model entity derived from C_BaseAnimating to attach/detach to models. It's purely the server side of the code doesn't need to know about it at all. I want to use the bonemerge method to attach it to the model and then, when needed, drop it as a normal vphysics entity on the client much like debris. Looking through the code, I thought c_gib might be a good place to start but it seems overly simple. BaseCombatWeapon has the relevant bonemerge methods but its both a client and server type entity. So my question is - whats a good template to use for a entity to fulfill the following requirements: * Client side only as it's purely for visual. * Uses FollowEntity and bonemerge to attach to an animating model. * Can be detatched/dropped when needed. - J ___ 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] Making the player jerk up when hit
If you want it to return to it's previous position then you should use ViewPunch On Sun, Jan 18, 2009 at 3:13 PM, Willem Engel wil...@refreshmi.nl wrote: You could use the the viewkick function used when shooting (in baseweapon I think). If you put that somewhere in TakeDamage then all should be fine. TakeDamage also has damageinfo so you can make the kick damage relative. Regards Willem Scott Robson wrote: Hi, I am trying to make the players' crosshair jerk up quickly and return to the origin within a certain timeframe. I also want the amount of damage you take to affect how much the player jerks up. This is so the player can't just 'stand and deliver' it gets boring. Can anyone help? Cheers, Scott. _ Choose the perfect PC or mobile phone for you http://clk.atdmt.com/UKM/go/130777504/direct/01/ ___ 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] Technical Design Document or Quick Reference Guide?
Wouldn't architectural designs showing class relationships be more pressing
than going through and commenting every single function with that format?
What's the biggest problem people are complaining about? Is it that they
don't understand that int GetIDTarget() const; is a method that gets the id
of the target as an integer? Or could it be that they don't understand how
classes interact and what things exist on the server and what on the client
and how those classes all tie together or inheret to create all the elements
of the game?
If you are going to create a remotely useful guide it seems like you're
attacking the problem in very much the wrong way. The proposal of creating
a fully commented version of the SDK is not only a huge amount of pointless
coding, exhausting to maintain properly but also a missunderstanding of the
difficulties. If the original topic is still the topic at hand then it's
acquanting them with architecture and an easy to understand layout of how
the classes work rather than pedantic descriptions of specific methods that
you would want to create.
I'd suggest tackling the theory of how Source is implemented before wasting
your time describing hundreds of self explaniatory methods without any
insight into how it's tied together. For example with the GetIDTarget, it's
an example of client side maintained information that is later used by the
HUD to create a user name display and by player class to manipulate the head
angles so it appears to look at someone. Something like that is far more
usefull, but on the same token you wouldn't put that into the code itself
you'd have it kept in an external documentation or somewhere.
On Thu, Jan 15, 2009 at 5:53 PM, Steve Henderson
steven.j.hender...@gmail.com wrote:
Yes this is a good idea -- but how do we distribute it without
violating Valve's Source SDK agreement (which says we can only
redistro OBJ files)?
It seems to me that we'd need them to agree to let us release just the
commented functions and classes
(without the underlying source code view as is exported by default
with doxygen).
Then as mentioned earlier, we could identify priority classes and
split up the work using
a version controlled MOD. Then export only the classes and function
documentation.
But Valve would have to be OK with this.
It would also be interesting if this documentation project could be
distributed/viewed through the Steam
client...I'm not a big steam fan, and would rather use my own
browser...but this might allow
for access to the documentation for licensed users only
Steve
On Thu, Jan 15, 2009 at 1:41 AM, James Luzwick jluzw...@gmail.com wrote:
I figured the basic idea is to create block comments above each function
and
class javadoc style. This would allow whomever is doing the
documentation
to use doxygen (
http://www.stack.nl/~dimitri/doxygen/http://www.stack.nl/%7Edimitri/doxygen/).
For example, take this function from c_hl2mp_player.cpp (OB HL2
Multiplayer
Code)
/**
* This returns the Player's ID Target
*
* @param If I had any parameters I would describe them here.
*
* @return The ID Target as an int.
*/
int C_HL2MP_Player::GetIDTarget() const
{
return m_iIDEntIndex;
}
The doxygen tool would then parse the file and discover this
documentation
for the function and export it to a nicely formatted HTML page.
The Apache guys commonly use this (well a lot of people use this) an
example
of what it would look like, is this:
Apache Xerces XML C++ Library (
http://xerces.apache.org/xerces-c/apiDocs-3/classes.html )
On Wed, Jan 14, 2009 at 9:06 PM, Walter Gray chrysal...@gmail.com
wrote:
Well, I hope it will be moot when the next version comes out, but right
now I was thinking we could do both, and tag the version specific
parts. I just started a new mod, and was forced to go with EP1 for
shader support. I'd like to move away from it, but for now there are
valid reasons for using either version, so I figure both versions should
be supported. I think the key thing here is to turn it into a more
widespread community effort, which is what wikis are good for.
If you're working on a project, you add to the sections relevant to
what you're working on, or volunteer some time when you have it. I may
not have too much time free for the latter, but I plan to do plenty of
the former. I'm trying to teach my teammates how to use Source so I
figure if I'm going to be writing up notes, the least I can do is try
and make them easily accessible. I imagine that kind of thing is why
Valve stuck the documentation on a publicly editable wiki in the first
place.
I suspect the biggest roadblock right now is figuring out formatting
and getting the basic framework in place so people have some kind of
guideline to add to. Nobody seems to like setting up the architecture,
but once it's there and easy to add to, I expect
Re: [hlcoders] Technical Design Document or Quick Reference Guide?
Quake was made by id who made the engine... And UT3 is designed and built as a middleware as much as an engine. The easiest way to get programmers into Source is to just startup a project and let them check out the SDK classes. It's a solid grounding point as you see the highest level player class, gamerules and gamemovement. It's a steep learning curve but having a technical document in this situation isn't really going to be as thorough as taking the time to walk through areas of code that the SDK classes inheret. It's a daunting enough SDK and will take a while to master but so do most SDKs like this, and there's enough on the wiki to get you started including the simple example brush, model and logic entities. Hell the wiki is freely editable so if someone really wanted to start a full documentation section outlining that kind of stuff, they could start a new page there and let it expand from user input and their own explortations. The gist is that learning the SDK is a combination of some examples of features, such as networking tables, and then just working with the code. If you want something that has lots of documentation and is designed and marketed primarily as a third party game development platform then the likes of UT3 might be easier to jump in and get going right away. Source modding/coding is just analogous to learning to code in general, you can read as much as you want but the only way to really harness it is to just work with it and allow for time spent learning some of the systems. Offtopic about that last paragrph Nick wrote. Whatever you're smoking must be rather strong because the logic behind those claims is absurd. Especially since I'm sure Gabe himself wouldn't concider being bought by Microsoft good, if that were the case he'd have probably stayed with them and never bothered starting Valve in the first place. Open sourcing tools and formats would make no difference as only Valve are going to be the ones handling the engine itself. On Sun, Jan 11, 2009 at 7:20 AM, Nick xnicho...@gmail.com wrote: I am not Valve, I do not work for Valve, but I like Valve, and like a good friend I like to point out where I think they go wrong. There is no such technical design document for source, available to the modders, but I suspect there is such a design document if you pay for a license. Valve is a good company, and has excellent people. But the top games released for source have been made exclusively by and for Valve. The source engine is powerful and highly adaptable, if you work for Valve. I think other engines are designed to be easier to understand because the other major game engines are being used by people outside the original company. Quake/id and Bioshock/ut3 and america's army/ut3 are some examples I can think of here. Source engine is powerful if you know how to use it, Valve people are the only ones who know how to use it properly. That isn't going to change unless Valve invests heavily in making it more open or documenting it more. ( not anytime within the next 3 years). UT3 engine is equally powerful, but epic games has gone to great lengths to make it easier to use, and highly documented. Also actively encourages scripting instead of forcing everyone to use c++ like valve does. Bioshock/Americas Army/Gears of War 2. Look at the material editor that comes with ue3 http://hourences.com/book/tutorialsue3mated.htm includes shaders also from almost one and half years ago! http://www.unrealtechnology.com/features.php?ref=editor I hope valve seriously thinks about open sourcing the tools, formats, and making the engine available on linux. Unless valve thinks it can exist only by relying on steam sales/distribution. Eventually microsoft will make steam obsolete(by creating a steamlike replacement for windows7) or buy valve out entirely, which is probably bad for most people working for valve, but good for the owners :P On Sat, Jan 10, 2009 at 10:29 PM, Walter Gray chrysal...@gmail.com wrote: I want to preface this by saying I know it's probably a kind of silly thing to be asking for, but on the other hand I feel it would would be stupendously useful. I'm looking for something akin to a Technical Design Document for the source engine, or at least the parts of it which are distributed with the Source SDK. Really, any single document that lays out, in a concise fashion, the general structure of the most commonly used systems, what base classes they use, and enough about how they are supposed to work for someone to start messing with them. It seems to me that the general approach for mod developers has been to use the code itself as the documentation and ask the community or check the wiki if they find something they don't understand. This, unfortunately, means that there's no easy way to get new developers on a team familiar with the engine, which is what I'm aiming to do. I've looked around, and
Re: [hlcoders] Possible Crash
The obvious question is, Does it stop happening if you use UTIL_Remove? I've not run into it, though our knock down code never hit public release and I used the SDK base, but I'm fairly sure I used UTIL_Remove and was ok other than the god aweful bandwidth hogging. On Mon, Dec 22, 2008 at 10:37 AM, Justin Krenz kre...@gmail.com wrote: While working on my current mod (Smashball - www.smashball.tv), I came across a rare server crash in physics.cpp: line 454 (int CCollisionEvent::ShouldCollide function). This function tries to determine if two entities should collide. The physics system has the physics objects for each object along with a pointer to the CBaseEntity that owns the physics objects. Once-in-awhile this function would crash the server, and it appeared that one of the CBaseEntity pointers was dangling/no longer pointing to a valid CBaseEntity. I was watching the server console when one of these crashes occurred, and the last line indicated a player had disconnected. I didn't plan on trying to track down the reason soon due to the rarity of the crash, but tonight, I think I may have found the source of the crash. In hl2mp_player.cpp, the UpdateOnRemove function calls UTIL_RemoveImmediate( m_hRagdoll ) to immediately delete the player's ragdoll. Is this safe to do? I suppose normally the ragdoll doesn't have an associated physics entity on the server, but in Smashball, players do have server ragdolls to sync up the player's position with their ragdoll when they get up from being knocked out. I'm thinking that UTIL_RemoveImmediate deletes the ragdoll entity immediately, but the physics object is left around with the pointer to the entity until the end of the frame. Is that possible? ___ 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] Anyone using an SSD Drive for compiling?
I'd imagine you might see some improvements with intelisense if you're using Visual Studio, and probably a bit of an improvement on the compiling when it's creating and reading the obj files, but have no hard evidence. You may have the honour of being the first one to actually put it to the test. On Sun, Dec 7, 2008 at 11:00 PM, Matt Hoffman [EMAIL PROTECTED]wrote: I don't see how a SSD Drive would improve compile times at all. Most of the compile times is just crunching numbers, not read/write. Cannot remark on the coding aspect though. On Sun, Dec 7, 2008 at 2:56 PM, Minh [EMAIL PROTECTED] wrote: Hope this isn't too off topic but I'm considering purchasing an Intel X25-M SSD drive in hopes of improving my compile times and general coding experience (I do a lot of stop/edit debugging and constant searching in files). Does anyone have any experience using SSD drives? Is it noticably faster when compiling your binaries? ___ 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] Client sending info to server : alternative to engine-ClientCmd(szCmd)
You could mod the CUserCMD class I believe so that it is capable of holding extra data, like at the very end have a bit to indicate whether there is more data to be read or not. The issue you could have with that is the chance of the information never arrive or being discarded for being too late to be of use. But that command packet is the most flexible way you could attach data, otherwise pulling it out of the ClientCmd string. If you spend time rooting around in the SDK code yourself and understanding how sources networking functions you'll know immediately what the best approach is for your needs. On Fri, Dec 5, 2008 at 10:54 PM, Jorge Rodriguez [EMAIL PROTECTED] wrote: engine-ClientCmd() is equivalent to typing something into your console. A faster way to type something into your console is to bind a key to it. There's really nothing that ClientCmd() can send that can't be sent by binding it to a key somehow. -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Lip Syncing.
Yeah..I'm not paying $45.00 for something that could be learned for free.. that's rofl indeed, don't tell Universities that or you'll put them out of business! On Wed, Dec 3, 2008 at 9:49 PM, Jake [EMAIL PROTECTED] wrote: I love you. Matt Hoffman wrote: Youtube katana314, he has several faceposer tutorials. http://www.youtube.com/watch?v=WwjNBrRfRWAfeature=channel They go up to atleast 5, and cover how to get them into something such as TF2. On Wed, Dec 3, 2008 at 1:34 PM, Jake [EMAIL PROTECTED] wrote: Yeah..I'm not paying $45.00 for something that could be learned for free.. Ben Mears wrote: http://www.noesisinteractive.com/index.php?page=shop.product_detailsflypage=cn_flypage.tplproduct_id=51category_id=28option=com_virtuemartItemid=53vmcchk=1Itemid=53 On Wed, Dec 3, 2008 at 1:09 PM, Jake [EMAIL PROTECTED] wrote: Hey there, I'm trying to learn the faceposer tool, although it seems there's no real complete tutorial available. http://developer.valvesoftware.com/wiki/Choreography_creation/Lip_synching .. Are there any tutorials on the lip syncing part? I have managed to do this easily in the past, although I can no longer remember on how to do this.. Thanks in Advance -Jake ___ 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] L4D Plugin Headers
You're probably best waiting until after the full game is released. Given that the L4D available is a Demo I doubt Valve would be too happy with potential customers being driven off because they played on a server that didn't play the way the game was supposed to. On Thu, Nov 13, 2008 at 10:05 PM, Saul Rennison [EMAIL PROTECTED]wrote: I'm wondering if one of the Valve Devs would be able to zip up the new SDK headers that are required to make plugins. Mattie [Casper] noticed that VEngineCVar has updated from 004 (TF2) to 007 (L4D). He also noticed an update in eiface. I politely ask any of the Valve Devs to stick the new headers and or libraries up somewhere. Much thanks in advance, - Saul. ___ 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] VPK Extractor?
for bloodlines perhaps, for L4D no On Fri, Nov 7, 2008 at 2:45 AM, Jake [EMAIL PROTECTED] wrote: I was wondering if a tool that would extract vpk files (VTMB Bloodline Pak files (Not same version), and Left 4 Dead Pak Files (Mainly the one I'm talking about...) would come out with the newest version of source sdk (once l4d hits..) ___ 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] Detecting point is outside world
Trace straight down and see if you hit sky/nodraw? On Mon, Sep 22, 2008 at 2:12 AM, Minh [EMAIL PROTECTED] wrote: here's a tuff one. How do you find out if a point is underneath/behind terrain (ie. displacement ) ? Gayan Ediriweera wrote: I don't think you can use traces because the map enclosure isn't necessarily a convex shape. So you could imagine a point where a trace in any direction would hit brushes which is still not a valid position for the player. Cheers On Thu, Sep 18, 2008 at 5:49 PM, Andrew Watkins [EMAIL PROTECTED] wrote: Hey all, very simple question that I can't seem to find the answer to - how to tell if a point is outside the game world or not? I've added an ability allowing players to teleport a short distance, including through walls, to our HL2MP OB mod. This is great, and the code successfully avoids getting the player stuck inside world brushes or anything else when teleporting. It is unfortunately possible for them to teleport to completely outside the world geometry, and I can't work out how to stop this. I've tried my hull traces using various likely-looking masks collision groups, and have looked at all the UTIL_PointContents flags, but I can't see how to determine if a point is outside the world or not. I've also looked through gamemovement.cpp, as players don't fall when they teleport outside the world, so something must be stopping them, as they aren't in a solid - but nothing jumps out at me. So, does anyone know how to determine if a point / trace / entity is completely outside the world geometry? The best hacky method I can come up with is testing if a several-thousand-unit-long trace can be done in any direction (up/down/n/s/e/w), and if any can, assume its outside. I'm sure there's a point contents method, but I can't work it out. Help would be appreciated. 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 ___ 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] Old recorded demos
Wouldn't you also need the appropriate client/server libraries that match up with the version you recorded the demos in? On Thu, Sep 18, 2008 at 4:24 PM, Nick [EMAIL PROTECTED] wrote: The only possible solution valve could do for such a thing is a version system. Valve GAME ENGINE demo control interface Demoversion1.dll Demoversion2.dll Demoversion3.dll Demoversion4.dll newest one is added instead of replacing the old one Every saved demo uses specific version ID that enables it to work with the previous Demoversion1.dll. As long as the demo control interface remains the same, or keeps the same functionality, it should last as long as the engine does. On Thu, Sep 18, 2008 at 9:28 AM, botman [EMAIL PROTECTED] wrote: Nick wrote: A new format that won't have this problem? LOLOL Maybe they're going to store everything in a text file? XML? :) -- 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] SendTables animation problem
Make sure you're updating your animstate
On Thu, Aug 21, 2008 at 3:12 PM, Emiel Regis [EMAIL PROTECTED] wrote:
Hello,
I used omega's SendTable fixes in my mod (based on HL2MP Orangebox code),
but I can't get animations to work - every player is always jesus pose.
Here are the SendTables and stuff:
tne_player.cpp (old hl2mp_player.cpp):
void* SendProxy_SendNonLocalDataTable( const SendProp *pProp, const void
*pStruct,
const void *pVarData, CSendProxyRecipients *pRecipients, int
objectID )
{
pRecipients-SetAllRecipients();
pRecipients-ClearRecipient( objectID - 1 );
return ( void * )pVarData;
}
REGISTER_SEND_PROXY_NON_MODIFIED_POINTER( SendProxy_SendNonLocalDataTable
);
BEGIN_SEND_TABLE_NOBASE( CTNE_Player, DT_TNELocalPlayerExclusive )
//SendPropInt( SENDINFO( m_iShotsFired ), 8, SPROP_UNSIGNED ),
// send a hi-res origin to the local player for use in prediction
SendPropVector( SENDINFO(m_vecOrigin), -1,
SPROP_NOSCALE|SPROP_CHANGES_OFTEN,
0.0f, HIGH_DEFAULT, SendProxy_Origin
),
SendPropFloat( SENDINFO_VECTORELEM(m_angEyeAngles, 0), 8,
SPROP_CHANGES_OFTEN, -90.0f, 90.0f
),
//SendPropAngle( SENDINFO_VECTORELEM(m_angEyeAngles, 1), 10,
SPROP_CHANGES_OFTEN ),
END_SEND_TABLE()
BEGIN_SEND_TABLE_NOBASE( CTNE_Player, DT_TNENonLocalPlayerExclusive )
// send a lo-res origin to other players
SendPropVector( SENDINFO(m_vecOrigin), -1,
SPROP_COORD_MP_LOWPRECISION|SPROP_CHANGES_OFTEN,
0.0f, HIGH_DEFAULT,
SendProxy_Origin ),
SendPropFloat( SENDINFO_VECTORELEM(m_angEyeAngles, 0), 8,
SPROP_CHANGES_OFTEN,
-90.0f, 90.0f ),
SendPropAngle( SENDINFO_VECTORELEM(m_angEyeAngles, 1), 10,
SPROP_CHANGES_OFTEN ),
END_SEND_TABLE()
IMPLEMENT_SERVERCLASS_ST(CTNE_Player, DT_TNE_Player)
// playeranimstate and clientside animation takes care of these on the
client
SendPropExclude( DT_BaseAnimating, m_flPoseParameter ),
SendPropExclude( DT_BaseAnimating, m_flPlaybackRate ),
SendPropExclude( DT_BaseAnimating, m_nSequence ),
SendPropExclude( DT_BaseEntity, m_angRotation ),
SendPropExclude( DT_BaseAnimatingOverlay, overlay_vars ),
SendPropExclude( DT_BaseEntity, m_vecOrigin ),
SendPropExclude( DT_ServerAnimationData , m_flCycle ),
SendPropExclude( DT_AnimTimeMustBeFirst , m_flAnimTime ),
// Data that only gets sent to the local player.
SendPropDataTable( tnelocaldata, 0,
REFERENCE_SEND_TABLE(DT_TNELocalPlayerExclusive),
SendProxy_SendLocalDataTable
),
// Data that gets sent to all other players
SendPropDataTable( tnenonlocaldata, 0,
REFERENCE_SEND_TABLE(DT_TNENonLocalPlayerExclusive),
SendProxy_SendNonLocalDataTable ),
SendPropInt( SENDINFO( m_iPlayerState ), Q_log2( NUM_PLAYER_STATES
)+1,
SPROP_UNSIGNED ),
SendPropEHandle( SENDINFO( m_hRagdoll ) ),
SendPropInt( SENDINFO( m_iSpawnInterpCounter), 4 ),
//TNE stuff
SendPropInt( SENDINFO( m_iPlayerLives), 2 ),
SendPropInt( SENDINFO( m_iPlayerSoundType), 4 ),
SendPropInt( SENDINFO( TKPoints ), 5 ),
//Handled by client on his own
SendPropExclude( DT_BaseFlex, m_viewtarget ),
END_SEND_TABLE()
BEGIN_DATADESC( CTNE_Player )
END_DATADESC()
c_tne_player.cpp:
BEGIN_RECV_TABLE_NOBASE( C_TNE_Player, DT_TNELocalPlayerExclusive )
//RecvPropInt( RECVINFO( m_iShotsFired ) ),
RecvPropVector( RECVINFO_NAME( m_vecNetworkOrigin, m_vecOrigin ) ),
RecvPropFloat( RECVINFO( m_angEyeAngles[0] ) ),
//RecvPropFloat( RECVINFO( m_angEyeAngles[1] ) ),
END_RECV_TABLE()
BEGIN_RECV_TABLE_NOBASE( C_TNE_Player, DT_TNENonLocalPlayerExclusive )
RecvPropVector( RECVINFO_NAME( m_vecNetworkOrigin, m_vecOrigin ) ),
RecvPropFloat( RECVINFO( m_angEyeAngles[0] ) ),
RecvPropFloat( RECVINFO( m_angEyeAngles[1] ) ),
END_RECV_TABLE()
// main table
IMPLEMENT_CLIENTCLASS_DT(C_TNE_Player, DT_TNE_Player, CTNE_Player)
RecvPropDataTable( tnelocaldata, 0, 0,
REFERENCE_RECV_TABLE(DT_TNELocalPlayerExclusive) ),
RecvPropDataTable( tnenonlocaldata, 0,
0,REFERENCE_RECV_TABLE(DT_TNENonLocalPlayerExclusive) ),
RecvPropInt( RECVINFO( m_iPlayerState ) ),
RecvPropEHandle( RECVINFO( m_hRagdoll ) ),
RecvPropInt( RECVINFO( m_iSpawnInterpCounter ) ),
RecvPropInt( RECVINFO( m_iPlayerLives ) ),//[Millz]
RecvPropInt( RECVINFO( TKPoints ) ),//[Millz]
RecvPropInt( RECVINFO( m_iPlayerSoundType) ),
END_RECV_TABLE()
BEGIN_PREDICTION_DATA( C_TNE_Player )
DEFINE_PRED_FIELD( m_flCycle, FIELD_FLOAT, FTYPEDESC_OVERRIDE |
FTYPEDESC_PRIVATE | FTYPEDESC_NOERRORCHECK ),
DEFINE_PRED_FIELD( m_nSequence, FIELD_INTEGER, FTYPEDESC_OVERRIDE |
FTYPEDESC_PRIVATE | FTYPEDESC_NOERRORCHECK
Re: [hlcoders] Player rmodels not updating pose to correspond with aim.
Is this on the local player or other players? On Wed, Aug 13, 2008 at 11:11 PM, Jed [EMAIL PROTECTED] wrote: I've got a problem where a players playermodel isn't updating it's aim to correspond with where the player is looking. I noticed it today while testing on-line and against some bots and its really annoying as you can't tell where they're aiming their weapons. If I create a bot and set it to mimic me and then turn on sv_hitboxes for that bot, the hitboxes work fine, they follow my mouse movements and even the induced recoil from my code. As I look up, the hitboxe representation of the box looks up and so on. However, the player model itself just looks dead ahead and doesn't do anything at all. My player class just extends the CHL2MP_Player/C_HL2MP_player class and basically just overrides a few function so I haven't changed anything core and most of my overrides call BaseClass::Function() at the end anyway to execute the HL2MP code anway. So I'm a bit stuck as to how to solve it. I noticed in hl2mp_player_shared theres a class called CPlayerAnimState which has various functions for updating pose parameters and the client and server HL2MP classes have instances of it. I'm wondering if that has anything to do with it? Would the functions therein still not functions even though I'm using a class derived from it? A debug traces shows the code being called. I'm at a loss here :( - Jed ___ 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] Per non local player client side simulation code - where do I put it ?
UpdateClientSideAnimation or ClientThink perhaps? On Tue, Jul 29, 2008 at 5:41 PM, Maarten De Meyer [EMAIL PROTECTED]wrote: Hi list! Simple question really, I want to simulate a part of a certain weapon's behavior on the client, since it's visual and I don't want the visual aspects networked ( not necessary and makes things laggy ). I usually put stuff like that in ItemPostFrame, but I'm discovering that only the local player's ItemPostFrame functions are called on the client. Is this normal, and if so, is there an interface already for what I'm trying to do or do I just hook C_BasePlayer::PhysicsSimulate or something ( where the difference between local and non local players is made ) ? Thanks, Maarten ___ 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] Where is c_prop_portal.h
Not releasing it means you don't get to make your portal inspired mod, I don't think that hurts Valve in anyway since they get to maintain full control over how the tech they developed for portal is used. On Mon, Jul 7, 2008 at 3:55 PM, Nick [EMAIL PROTECTED] wrote: If someone is big enough to sell it, they are probably big enough to write their own portal gun code. Not releasing portal gun code, only hurts small modders, and players, and valve. On Mon, Jul 7, 2008 at 9:34 AM, Olly [EMAIL PROTECTED] wrote: If valve released the sourcecode for everything, then someone could just recompile it with a different name, and then sell it. Thats why they dont release it. 2008/7/7 Patrick Neese [EMAIL PROTECTED]: :P so other than HL2 no other source is released... awesome... ...*shakes head* Anyone know why that is? Thanks! On Sun, Jul 6, 2008 at 7:40 PM, Olly [EMAIL PROTECTED] wrote: Code for retail games is not released (i.e; CSS, DODs, Portal, TF2, etc) 2008/7/7 Patrick Neese [EMAIL PROTECTED]: So I just downloaded the new BETA sdk And I can't Find c_prop_portal.h which is inside a precompiler section for PORTAL. Have these cpp and header not been released yet so we can modify code for the Portal mod? Or am I just extremely daft? I added #ifndef PORTAL #define PORTAL #endif to see what would happen...um...definitely gave me some errors :) Building maps for Portal is fun and all...but modifying some NPC's to work with HL2 maps and portal gun... that would be amazing. ___ 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] Where is c_prop_portal.h
Yea and now they're both plain and boring :P :P Though even your Template mod seems to be tailored for multiplayer. On Mon, Jul 7, 2008 at 6:14 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: I wish I knew. ;) It's funny, after I did it, I ended up re-creating two of my personal mods with it.. hah On Mon, Jul 7, 2008 at 1:09 PM, Paul Peloski [EMAIL PROTECTED] wrote: Yeah I've seen that, I even mentioned it above. If there is anything that would make the Source SDK more like a GDK and less like HL2 source code, it would be something like that (and the ability to exclude HL2 entirely) Regards, Paul On Mon, Jul 7, 2008 at 1:03 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: Whenever my replcement for 'scratch' goes live, it'll be far more enjoyable to make real mods; It's a template, with a number of wanted base features that can be enabled or disabled via preprocessor definitions, a framework if you will to build off of. I've actually uploaded a video or two of it, there are still a few minor details I have to fix that I didn't realize at the time, though. http://www.youtube.com/watch?v=yEdCmN9WeWc On Mon, Jul 7, 2008 at 12:37 PM, Daniel Soltyka [EMAIL PROTECTED] wrote: Bingo. HL2DM and whatnot just show you ways to interact with the engine itself, which is what you are actually writing a mod for. On Mon, Jul 7, 2008 at 12:22 PM, Adam Buckland [EMAIL PROTECTED] wrote: The thing is, the name should give the name of the platform that the kit is for, and since you are not working on the HL2DM platform, you are working with the Source engine. Don't forget, if you are working from scratch, HL2DM doesn't even come into the equation It should therefore be called Source SDK, since that's the platform, like Windows SDK, iPhone SDK, etc On 7 Jul 2008, at 17:10, Nick wrote: Are you saying they should rename Source SDK to HL2DM SDK ? On Mon, Jul 7, 2008 at 11:03 AM, Paul Peloski [EMAIL PROTECTED] wrote: Well, I'm happy modding HL2 as I've been doing for years. Just saying that it's not a big leap of logic to assume that if Portal comes with the Source SDK that the Source SDK is a Software Development Kit for Portal. Like you'll be able to write some software to add-on to Portal. Hence we get a lot of people with questions like So where's the code for CS:S and Where's the code for the Portal Gun. Regards, Paul On Mon, Jul 7, 2008 at 11:47 AM, Olly [EMAIL PROTECTED] wrote: How many retail games do you know that release the source code? 2008/7/7 Paul Peloski [EMAIL PROTECTED]: I can see this actually, on the Portal page of the Steam Store it says Includes Source SDK. I would be a little confused trying to explain Includes Source SDK to myself, I think it's: - Source code for the latest (give or take) HL2 and HL2DM - Some sample code that doesn't get you much further than HL2DM - Possibly some mod template thing omega is working on (?) - Source tools (hammer, hlmv, faceposer, etc) Anyways, would be nice for people who haven't spend years following Valve to know at least that much without having to ask/search around. Regards Paul On Mon, Jul 7, 2008 at 11:14 AM, Patrick Neese [EMAIL PROTECTED] wrote: As creator of this thread I saylet it be! All though I am a little miffed that I just bough Portal thinking I could mod it when in deed i cannot. Wish i had known that the option to create a mod with Portal chosen didn't actually have all the code for portal..just other tools...like hammer Retarded. Now no more discussion on this. On Mon, Jul 7, 2008 at 10:07 AM, Michael Chang [EMAIL PROTECTED] wrote: Uh oh, not this again If someone is big enough to sell it, they are probably big enough to write their own portal gun code. Not releasing portal gun code, only hurts small modders, and players, and 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
Re: [hlcoders] Debug linux server crash ?
last time you asked a question On Sat, Jul 5, 2008 at 10:16 PM, Nick [EMAIL PROTECTED] wrote: Thanks! I cannot remember the last time someone posted so much good information.. On Sat, Jul 5, 2008 at 3:03 PM, Bombela [EMAIL PROTECTED] wrote: Yes, it's called coredump. On many GNU/Linux distribution, coredump is disabled by default, for security reason. An simple command can be change this limitation : ulimit -c 2000 2000 is in kilo bytes. This command must be applied before launch the server. Furthermore Valve provide facility, when you add -debug parameter to srcds_run the ulimit is called with 2000 kilo bytes (like my example). When the server crash, a new file appear, called core. You can launch gdb on this coredump like that : gdm ./srcds_i686 core Replace srcds_i686 by the executable really used on your system. Bye. vivoli a écrit : Hi, I have a crash with my Linux dedicated server (running my mod). There is a tool to debug a crash with Linux servers ? (like .mdmp files for Windows server) 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 ___ 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 Orange Box
I'm sure Valve have learned to ignore 95% of the criticism they receive and treat the other 5% with mild indifference as they have been successful thus far. The SDK is still far more than enough to make mods, a few bugs here and there won't hold every single mod back. Hell the fact that people can access the OB SDK at all without having to purchase the Orange Box itself is a testimant to the fact Valve does care. How many people had to completely upgrade from UT2k3 to UT2k4 just to play mods that had moved over to the 2k4 engine? This entire topic devolved from a fix put out to aid in Linux builds, but all the files there, as best as I can tell, were already available so it's not like you couldn't have fixed it yourself. How many companies let you do that without being a client ? On Sun, Jun 22, 2008 at 12:20 PM, Daniel Glenn [EMAIL PROTECTED] wrote: I'm not the only one who did a double take upon seeing the word Nigger in a HLCoders post summary, am I? On Sun, Jun 22, 2008 at 5:20 AM, Adam Buckland [EMAIL PROTECTED] wrote: I've kept quiet on this, but now the line has been crossed. You are acting like 4-year-old children, and should, quite frankly, feel ashamed of yourselves. When a product or update is released, not everyone is going to be pleased. If you are one of those that are not pleased, sometimes you've got to live with it. This mailing list is not the place for you to flame, nor a place to use such offensive language, Tobias. It is a discussion about the sdk, and a place to help each other. This behaviour needs to stop. Right now. 2008/6/22 Cory de La Torre [EMAIL PROTECTED]: Geezus guys, come on. On Sat, Jun 21, 2008 at 10:32 PM, Mulchman [EMAIL PROTECTED] wrote: Great language; I'm glad you're allowed to post to hlcoders - not. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tobias Kammersgaard Sent: Saturday, June 21, 2008 22:11 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Linux Orange Box Whatever those niggers say! I probably going to be hungover tomorrow. I demand satisfaction :-(! /ScarT On 21/06/2008, Nick [EMAIL PROTECTED] wrote: Tobias Kammersgaard, I don't know who's side you are on right now, but I know you are not on the side of Valve or the modding community. The source modding community has been waiting for over 6 months for even a half decent way of compiling mod binaries for linux. Thats complete bullshit, and totally unacceptable. I know better than to believe that it really needed to take that long. Valve has very smart people, and to have modders wait 6 months for something that should have been out in January is pathetic. Tobias, if you work for some other bullshit company, or there is some reason why you don't want an improved source sdk, you need to leave now. On Fri, Jun 20, 2008 at 11:10 PM, Tobias Kammersgaard [EMAIL PROTECTED] wrote: That statement is just dumb for so many reasons. /ScarT On 21/06/2008, Nick [EMAIL PROTECTED] wrote: At least you get paid to fix bugs. Imagine how many free mod developers, have to deal with the bugs you get paid to leave behind... On Fri, Jun 20, 2008 at 12:26 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: Awesome :D so just about 20 hours of anger and wanting to throw linus over a cliff paid off ;) -Tony On Fri, Jun 20, 2008 at 6:42 AM, John [EMAIL PROTECTED] wrote: Great work omega this fixed all my problems :) On 6/20/08, Tony omega Sergi [EMAIL PROTECTED] wrote: Hey guys, I think I've fixed the linux issue with ConCommands (ie: say, kill etc), and it appears to all have been makefile related. Here is a tarball of the makefiles, plus vcprojtomake.cpp you can unpack it into the src dir (it contains the paths from src) or somewhere else and copy the files to the appropriate location. Please read the top thoroughly as I've made some comments in there ;) Please let me know asap if everything is functional for you now. link: http://www.omegaowns.us/valvestuff/orange_makefiles.tar.gz -- -Tony ___ 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:
Re: [hlcoders] Linux Orange Box
No, we call that life. On Fri, Jun 20, 2008 at 6:26 PM, Tony omega Sergi [EMAIL PROTECTED] wrote: Awesome :D so just about 20 hours of anger and wanting to throw linus over a cliff paid off ;) -Tony On Fri, Jun 20, 2008 at 6:42 AM, John [EMAIL PROTECTED] wrote: Great work omega this fixed all my problems :) On 6/20/08, Tony omega Sergi [EMAIL PROTECTED] wrote: Hey guys, I think I've fixed the linux issue with ConCommands (ie: say, kill etc), and it appears to all have been makefile related. Here is a tarball of the makefiles, plus vcprojtomake.cpp you can unpack it into the src dir (it contains the paths from src) or somewhere else and copy the files to the appropriate location. Please read the top thoroughly as I've made some comments in there ;) Please let me know asap if everything is functional for you now. link: http://www.omegaowns.us/valvestuff/orange_makefiles.tar.gz -- -Tony ___ 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 -- -Tony ___ 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] Attaching a flame entity to the muzzle of a weapon
What about looking at how muzzle flashes are handled, they occur globally and in both weapon space and world space. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Orange Box SDK Code Update
Grats Tony you've got an HLCoders thread being dedicated to just who you are and what you do :) On Mon, May 19, 2008 at 5:34 PM, Tom Edwards [EMAIL PROTECTED] wrote: Yes, he's contracted. VPNs in I believe. It's been a while since I checked Valve's people page. The new bios aren't as funny as the old ones. :-p (Torsten Zabka - Community Support Germany? Where does he hang out?) Tobias Kammersgaard wrote: I was just about to point that out. Also, he works outside Valve just like Chris 'autolycus' Bokitch does(did?). /ScarT On 19/05/2008, Adam Buckland [EMAIL PROTECTED] wrote: He has a Valve profile on the forums? http://forums.steampowered.com/forums/member.php?u=442806 On 19 May 2008, at 16:59, Nick wrote: I was never convinced he worked for valve anyway. Nice guy though.. Lack of valve email always makes me wonder.. On Mon, May 19, 2008 at 9:27 AM, Tobias Kammersgaard [EMAIL PROTECTED] wrote: What is somewhat interesting too, Tony Omega Sergi stopped coming to the IRC channel in GameSurge (#HLCoders). /ScarT On 19/05/2008, Matthew Dryden [EMAIL PROTECTED] wrote: agreed Justin Krenz wrote: I don't care about the lack of features like the particle editor, but Valve really needs to fix the VAC connection issues and inability to compile a Linux server with the OB SDK. Those things are definitely holding mod teams back. ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Orange Box SDK Code Update???
http://www.youtube.com/watch?v=yEdCmN9WeWc But now we are getting a very limited environment with the OB engine. I'm sure that the lack of a particle editor or some bugs in the code didn't hold the CS team or TF guys back from developing their games which then became huge successes and resulted in many of them working for the very company that produced the SDK or working on an SDK by porting their game to said companies engine. It's a pain when not everything is perfect as you want it, but they are usually helpful on case by case basis and as is the situation where the company is still balancing making games, supporting games, supporting licensees, developing/fixing an SDK and looking to the future, enough people voicing requests for things is more likely to be heard than simply demanding it because you feel that it is their duty to support your needs. Btw Look at Garrys mod, Zombie Panic, Svencoop, Insurgency, etc, etc.. all examples of working with what you have been given and letting the sdk updates happen at their own pace. And if you're talking about the HL2 release still and how it's limited modders or something then just look at your own mentioned mods. 2008/5/18 Benjamin Davison [EMAIL PROTECTED]: I think they left Mike in Mexico by accident, he has been really quiet over the past couple of weeks. 2008/5/18 Ryan Sheffer [EMAIL PROTECTED]: I was excited about Half-Life 2 when it was released, but I was more excited for the modability. We have a lot, but at the same time, not enough. Valve originally showed off Half-Life 2, but also showed off how we could mod it. But now we are getting a very limited environment with the OB engine. One of the reasons Half-Life 1 stayed alive was because of modders, Counter-Strike being a mod not created by Valve. So why is it a bad thing to continuously update the Source sdk with fixes and such? Its not. As I see it, Valve already owe modders a great deal for sticking by them and making mods that are attracting people to launch Steam and play their products. Look at Garrys mod, Zombie Panic, Svencoop, Insurgency, etc, etc.. At this point, I want a fixed Source SDK over Episode 3 and L4D. 2008/5/18 Adam Maras (memzero) [EMAIL PROTECTED]: Wouldn't it also be fair to say that an SDK like the one provided by Valve is, in itself, something that's generally unheard of at the commercial level? I think we're all darn lucky that Valve lets us extend their engine at all... // Adam Maras (memzero) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel R. Sent: Sunday, May 18, 2008 10:10 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Orange Box SDK Code Update??? It's not about being owed something. It's that we've been given a broken SDK and it's been that way for over 5 months with no update in sight. This is unheard of at the commercial level. 2008/5/18 Daniel Glenn [EMAIL PROTECTED]: Heh. Is it too early to make this thread into a fanboy rant about how every other engine pales in comparison to Source? If not, I want to start it. But yes, I agree. I'm just not a big fan of people who think they're owed something. 2008/5/18 Ben Mears [EMAIL PROTECTED]: Here's my opinion. Valve doesn't owe us anything but it is in their best interest to keep us happy as we are the ones who promote and further the Source Engine. After all, where did Counter Strike, Team Fortress, and Portal originate from? I think Valve has done a pretty good job of supporting us modders but it's true that there is always more they could do for us. Maybe the people who are unhappy with Valve should move on to other engines, Unreal 3 or CryEngine 2 for example, see how those engines compare to Source and then re-evaluate their opinons. Again, that's just my two cents. On Sun, May 18, 2008 at 3:42 AM, Ondřej Hošek [EMAIL PROTECTED] wrote: Which would obviously reduce the longevity of their games. ~~ Ondra On 18.05.08 10:16 Uhr, Daniel Glenn wrote: We don't deserve a damned thing. Valve could have simply not released the source code at all. On Sat, May 17, 2008 at 11:25 AM, John[EMAIL PROTECTED] wrote: Come on Valve :D All us modders deserve that fixed code in good time :\ Its been a few months On Sat, May 17, 2008 at 2:25 PM, Tom Leighton [EMAIL PROTECTED] wrote: That was a fix from Tony Sergi (VALVE) Tom Edwards wrote: That /was/ a fix from Valve. Janek wrote: @Benjamin and Tom I saw this post as it was an answer to a question
Re: [hlcoders] Emitting a non-spatialised sound on the server
maybe something like this would work for you CReliableBroadcastRecipientFilter everyBody; UserMessageBegin( everyBody, SendAudio ); WRITE_STRING( Sound.Name ); MessageEnd(); On Sat, May 17, 2008 at 3:14 PM, Tom Edwards [EMAIL PROTECTED] wrote: The only function I have found that emits a sound without a source location (i.e. at full volume everywhere) is enginesound-EmitAmbientSound(), which is client-only. All other functions, even ones that describe themselves as ambient, play from a location in the world. I've been able to hack it in singleplayer by emitting from the player entity, but obviously that won't work online! Surely there is a way of doing this? ___ 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] Orange Box SDK Code Update???
I want to play Episode 3 more, so I'm happy enough with the the SDK update happening when it happens. Besides the update more than likely has enough changes to warrant the time spent on it. On Sat, May 17, 2008 at 5:25 PM, John [EMAIL PROTECTED] wrote: Come on Valve :D All us modders deserve that fixed code in good time :\ Its been a few months On Sat, May 17, 2008 at 2:25 PM, Tom Leighton [EMAIL PROTECTED] wrote: That was a fix from Tony Sergi (VALVE) Tom Edwards wrote: That /was/ a fix from Valve. Janek wrote: @Benjamin and Tom I saw this post as it was an answer to a question from me. But this fix is for sratch sdk (different in hl2mp) and also I prefer a fix frm Valva as there could have other less noticeable prediction issue. 2008/5/17 Mikie [EMAIL PROTECTED]: For the last four years, Valve has needed to hire more people. They have the budget considering the success they've had, I never understood why Valve management is so reluctant to do so. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Glenn Sent: Saturday, May 17, 2008 12:14 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Orange Box SDK Code Update??? Obviously, they're not working on at least two retail games right now or anything. Be patient is my advice. On Fri, May 16, 2008 at 10:35 PM, Joel R. [EMAIL PROTECTED] wrote: We've been patiently waiting for about 5 months now waiting on an update to the Source SDK Code. Major Things Needed: - Updated Source SDK (Scratch Mod/HL2MP) (This should be finished). - Source Shaders - Particle Editor Making effects is crucial to any game. Currently if you switch to Orange Box, you cannot use Shaders or optimized particles (Particle Editor system). The current SDK is riddled with bugs that have been fixed but are casually awaiting to be updated in. TF2 has received 26 updates since the release of Orange Box SDK. We have received 1 update to Hammer and Engine. We have received 0 updates to the code-base. In it's current state, Orange Box SDK is broken. I and many others would greatly appreciate an immediate update as soon as possible. Thanks for your time. ___ 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] Scale down mouse input?
Just skimming through my own code I did most of my stuff in void CInput::ApplyMouse( QAngle viewangles, CUserCmd *cmd, float mouse_x, float mouse_y ) and started with a scale of 1 and altered it based on states and such and then when it applied the values to viewangles I scaled it by that factor. I can't say if that's the best way or not, but I hope it's of some help or atleast a starting point. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] orange box tf2 third person animation code
As I said that's a possible fix for the Scratch SDK but the HL2DM is a bit more work though entirely possible. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] orange box tf2 third person animation code
Well here you go I guess, this isn't the ultimate soloution. But it works and it's the simpilest just replace m_angEyeAngles[PITCH] in the local player update with the EyeAngles()[PITCH] like they did with yaw and have fun. As I said above all you had to do was look at the way the animstate was updated. I can't guarantee it's the ultimate soloution, perhaps predicting m_angEyeAngles properly would be better, I can't say but for the most part this works. if ( this == C_SDKPlayer::GetLocalSDKPlayer() ) m_PlayerAnimState-Update( EyeAngles()[YAW], EyeAngles()[PITCH] ); else m_PlayerAnimState-Update( m_angEyeAngles[YAW], m_angEyeAngles[PITCH] ); ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Performance : OB engine vs ep1 engine
I blame tony's terrible coding. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] orange box tf2 third person animation code
Yes the Start from Scratch option is multiplayer and all multiplayer mods from Valve in the SDK implement client side animations, the Scratch SDK is also the simplest to get perfectly smooth animations on the local client as the fix for it really is trivial, if you're looking to do HL2MP it as well is entirely possible, it's just a case of understanding the animstate classes and what the process for updating them is. It shouldn't take too long to figure it out with a bit of detective work and experimenting, on the Advanced SDK it's quite straight forward. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] orange box tf2 third person animation code
The Advanced SDK for a long time has had great local player third person animations, no jitters and such as some of the HL2DM stuff sometimes has, even though that's entirely possible to fix. If you're desperate to use the HL2DM stuff though it is possible to smooth out as well. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] VGUI command KeyValues management
void Button::SetCommand( KeyValues *message )
{
// delete the old message
if (_actionMessage)
{
_actionMessage-deleteThis();
}
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] 9way animation code example?
For what you're looking to do you will just have your X and Y movement controllers and you get X and Y components of your 2D movement scale it to 1 and -1 then set your pose parameters to that, rather than how HL2DM does the yaw of your movement. Unless I'm miss reading the question then that's the change you're looking for. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rotating a player
The retrieval of render angles should just be passed through to the animstate class anyway. In the animation state you can do all the rotations you want and the code will be shared on client and server if you want it to be. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Medic-Beam effect
-- [ Picked text/plain from multipart/alternative ] You may want to look at the beam type TE_BEAMFOLLOW never used it myself but it seems to atleast be similar to what you are looking to do if not exactly. However I'm refering to a type from the Ep1 code so it may no longer exist or have been altered in OB, but it looks like most of the code you want to replicate or implement is already there and may require little to no alteration. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Which EmitSound method should I use?
-- [ Picked text/plain from multipart/alternative ] For world based things that our players say I use the EmitSound( sound.name, soundTime, duration ); as Tom mentioned, I'm fairly sure duration there just passes back how long the sound will take to play and soundTime is how far into the sound to start, I think, since I always pass 0.0 for it and no issues so far. On the local player, for things they only, in some cases breathing and such I just use EmitSound( sound.name ); Then for our win and lose music we actually use the user message SendAudio with a string parameter that is the sound name. This in turn does essentially the same thing as what the second one does there afaik. Beyond that the only other EmitSound I use is the one that takes a filter, in most cases just a prediction filter that omits your local player on the server call. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Get Map Name on Server that works for listen and dedicated!
-- [ Picked text/plain from multipart/alternative ] Is gpGlobals-mapname is what you're looking for? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Hiding the player's active weapon
-- [ Picked text/plain from multipart/alternative ] In your SetUpView method you could also try clamping your viewmodel FOV so it never goes below 1 or similar. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ERROR: end frame before start frame in @Idle01 ???
-- [ Picked text/plain from multipart/alternative ] I am spartacus. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Any Source 2007 code update?
-- [ Picked text/plain from multipart/alternative ] Cheers for the update mike -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] The rib bone's connected to?
-- [ Picked text/plain from multipart/alternative ] Also on the topic of the ragdoll, you maye want to look at the m_pRagdoll member of C_BaseAnimating, if that's valid you can use the GetRagdoll method in it to retrieve the ragdoll_t structure which is where AFAIK an array of the actual ragdoll physics info is kept. I'm not sure if that's right though and I don't know if the physics objects in reach ragdollelement_t structure retain the names of the bone to even be of use. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] The rib bone's connected to?
-- [ Picked text/plain from multipart/alternative ] Visual Studio 2k5, click Class View tab, double click the class you are interested in, that opens up the Object Browser, if it doesn't automatically go to it you can then just browse to your class. Click on the + beside it and it will drop down it's attributes and methods. If it has base types a folder right below the class name will appear called Base Types and you can open that up, to get the base types and recurse through that until you get to the lowest point. It's not perfect, #ifndef CLIENT_DLL and such will catch it out, but for the most part it's fine aslong as you select the approriate project as active. http://www.namit.org/~bush/hlcoders/c_baseplayer.jpg I had no idea it existed, never needed it, but took 2 seconds to find in 2k5 and I'm sure it'll exist in 2k3 to some extent. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] The rib bone's connected to?
-- [ Picked text/plain from multipart/alternative ] Ah sorry, you'd imagine it would be able to do that since you can have classes display both their base types and derived types. Ah well sorry about the prior post then, I can't really offer much to that topic. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] vgui panels on models
-- [ Picked text/plain from multipart/alternative ] The code wasn't written by me for our watches, but we no longer use them so I'm sure Jon won't mind me sharing :S But ours are pretty much setup the exact same way tutorial shows, now this could be an error on our part because the original to Ep1 merge wasn't as clean as it could have been but our watch panel definatley works on the Ep1 engine. It works fairly well, our modeller removed the acctually wrist watch model and I can't find an old screenshot but here it is in action. http://www.namit.org/~bush/rnl/rnl_field0069.jpg again it's just using CVGuiScreenPanel as it's parent like the tutorial does. class CWatchScreen : public CVGuiScreenPanel -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Timer or function that checks distance move everyframe
Of you look at how the duck timers and and such are saved off into the players local data and updated in gamemovement you should have a starting point. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Animation Blending
Source has examples of both, HL2MP uses prebuilt layers with gestures (self contained one cycle layers AFAIK) and the Scratch SDK uses the CSS style run time built layering. So you can do what you like. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (no subject)
Isn't m_vecOrigin a simulated variable so that it does get interpolated? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Orane box source code
Safely in the hands of Mike Durand, it hasn't been released yet, but will be released in a future update to the Source SDK. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Orange Box Release breaks Episode 1 SDK...
-- [ Picked text/plain from multipart/alternative ] Does the Ep1 SDK automatically mounts the 2007 Materials? I thought it still used the older engines materials which would be fine for hammer, otherwise if you're mounting the GCFs yourself I'd suggest waiting for Valve to officially update the SDK. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Weapon holsters
-- [ Picked text/plain from multipart/alternative ] I personally did it in the weapons draw method, and included the name of the attachment in the weapons script file. Then all it it does is when the weapon is inactive it sets the models location to the appropriate attachment on the player. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] CBaseClientRenderTargets and rendertarget interface
-- [ Picked text/plain from multipart/alternative ] Just a quick question to see if anyone knows if CBaseClientRenderTargets is no longer how the _rt_WaterReflection, _rt_Camera etc.. rendertargets are being intitalized. We've added our own rendertargets for simple view bluring and I've been trying to clean up our code a bit since people complain of the intialization of our targets causing increases in loading times. Anyway, after creating similar functions to the existing ones in CBaseClientRenderTargets I've discovered that the class never even has the init function called on it. Am I looking in the wrong place for this? Are the other render targets created inside of the engine? Or has somewhere along the lines our initialization of the render targets class been removed, even though the default ones are still available in game. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] TF2 Engine
-- [ Picked text/plain from multipart/alternative ] http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg20622.html -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CSS Player models in a HL2MP Based mod.
-- [ Picked text/plain from multipart/alternative ] If you compare the SDK and HL2DM anim state you'll see that the construction of player animations is entirely different, CSS relys on layering at run time for almost all the poses where HL2DM just adds gestures to the base activity. You could try including the SDKs player animastate aswell then depending on the players model update either the SDK player animstate or HL2DM animstate. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] New weapon effects not aligned to weapon world model
-- [ Picked text/plain from multipart/alternative ] the location of the viewmodel is really only known by the client, what traces and muzzleflashes do is grab the location of the world model weapon when the effect is non local player. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Filesystem seems to not be working in any mods of mine
-- [ Picked text/plain from multipart/alternative ] Is the problem that it's not loading it, or is it that it's treating those // as comments and not loading those lines? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Array of Arrays as network variable?
-- [ Picked text/plain from multipart/alternative ] Garry, that is brilliant. And probably the best soloution, only worry about one clip at a time and leave total ammo to the server, could probably eliminate some traffic at the same time. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Array of Arrays as network variable?
-- [ Picked text/plain from multipart/alternative ] I appologize, was a bit eager there to thank garry since it solved the problem I had. I don't need the GUI and the only thing the client needs to know is the amount in the current clip and the next clip for reloading sake. Didn't mean to steal your topic. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Populating multiplayer maps with items.
-- [ Picked text/plain from multipart/alternative ] I think the HL2DM SDK comes with an example of this, but I did a similar thing a year or so ago, if I remember correctly I just used a file with keyvalues containing the entity's position, name and extra data needed for it to spawn correctly and then just randomly grabbed entities in the file and spawned them. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] View Snapping when other players enter vehicle
-- [ Picked text/plain from multipart/alternative ] I get this too from time to time in the normal SDK, however our code base isn't completely up to date. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Ragdoll initial pose
-- [ Picked text/plain from multipart/alternative ] If you're talking about the client side ragdolls in the normal SDK, doesn't it grab their last animation and cycle position when creating the ragdoll, at the same time it grabs the model instance. For the local player it grabs just run_lower or something, I remember trying to change it to grab the local player the same way as normal players but it crashed in VPhysics. Anyway it should be in c_sdk_player.cpp under C_SDKRagdoll::CreateRagdoll() -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Crounching Override problem
-- [ Picked text/plain from multipart/alternative ] (CurrentViewheight - DesiredViewheight) / (LowestHeight - HighestHeight) = percentage transitioned or something like that, lol I just made it up there, appologies if there's a simplere way to do, such as simply finding the difference between your current and desired and working from there, At any rate, you can just do something similar to that, or even using them times themselves, and figuring out what percentage of the movement is complete using that to figure out the starting point of the opposite transition. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: hlcoders digest, Vol 1 #3090 - 8 msgs
-- [ Picked text/plain from multipart/alternative ] Muahahahah our plan of continuously bombarding you with delightful hlcoders information has succeeded, you are ours for ever now! or do what everyone else says. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Animation layers on the server side
-- [ Picked text/plain from multipart/alternative ] Afaik the updating of reloads and stuff is blocked in using the #ifdef CLIENT_DLL style checks, you could remove those, which I believe will cause a bit of work in terms of getting the UpdateLayerGeneric or whatever it's called running smooth, but you should be able to do it without too much hassle, also I'm pretty sure it does but make sure the server plays the reload animations and not just broadcast the events to the clients. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] coin collecing system
-- [ Picked text/plain from multipart/alternative ] I'd suggest looking at how the health packs are done in HL2, it's practically going to be the same way health is handled for the player and instead of NPCs dropping the health packs it will be other players. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] dynamically increasing weapon ammo
-- [ Picked text/plain from multipart/alternative ] Other than the clip and max clip size isn't the ammo stored on the player? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Module-based Models
-- [ Picked text/plain from multipart/alternative ] Just use the models and their animation. Every animations has a silenced and unsilenced version, make an attach and detach animation, then in code just call the appropriate activities depending on the silencer state and away you go. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
