Re: [hlcoders] SDK 2013 issues
Somebody's mind is being read... ps: get tinfoil hat. From: Stephen Swires st...@swires.me To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 1 August 2013, 5:20 Subject: Re: [hlcoders] SDK 2013 issues A screenspace bloom shader sample was added to the SDK's git repo the other day. On 1 Aug 2013 03:28, Jorge Rodriguez bs.v...@gmail.com wrote: Oh one more thing, a wishlist item: * A fullscreen shader sample for this SDK would be great. I don't have one from the old SDK that I can port up to 2013 which leaves me without a place to start as far as screen space shaders go. 2013/7/30 Jorge Rodriguez bs.v...@gmail.com Thanks for the new SDK Jay/Valve! Here are a few things I've noticed about it: * I got the Linux port running, and I must admit I found the sensation strange to be building and playing a Source game client natively on Linux! The files won't load though unless the names are in all lowercase. I imagine this is because the engine handles Linux case sensitivity by slamming all file names to lowercase before opening them? That's a reasonable way to handle it, but it threw me for a loop when I triple checked the names in my files and they were correct. Mod authors will have to rename their entire asset tree to lowercase for the Linux port. Is this in some documentation somewhere? * The Windows dedicated server gives me this error message when clients try to connect: http://i.imgur.com/7jm2ZOJ.jpg Client connected with ticket for the wrong game. The Linux dedicated server works just fine otherwise. * We haven't been able to get servers to appear in the server list. Not even in the LAN list, it seems. Strangely enough, I can see 2007-based servers from the server browser, but I can't see 2013-based servers. With the exception of the above problem with Windows ded servers, it's possible to connect to a server by IP address, but nothing we've done has convinced the servers to show up in the browser. Thanks again for the SDK update, I'm psyched about the Linux and Mac ports, and I'll be digging into the VR stuff as soon as my Rift dev kit arrives :) -- Jorge Vino Rodríguez [ Tw | Fb | G+ | Ht ] -- Jorge Vino Rodríguez [ Tw | Fb | G+ | Ht ] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK 2013 Release
Its more a confirmation of work being done on a new source engine. From: Rodrigo 'r2d2rigo' Diaz r2d2r...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 27 June 2013, 2:00 Subject: Re: [hlcoders] Source SDK 2013 Release Future engines have been designed with cross platform support in the toolchain from the start. Oh my god, HL3 CONFIRMED! 2013/6/27 Alfred Reynolds alf...@valvesoftware.com No, hammer is only available on windows and we have no plans at this time to change that. It is a MFC app, which is a windows only UI tech, so a port would be difficult. Future engines have been designed with cross platform support in the toolchain from the start. From:hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jesse F Sent: Wednesday, June 26, 2013 4:46 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Source SDK 2013 Release Is hammer going to work on mac and linux now? I like that I can use not VS to build the sdk now. On Wed, Jun 26, 2013 at 4:44 PM, Alfred Reynolds alf...@valvesoftware.com wrote: There is a new Source SDK Base 2013 app (one for MP and one for SP) that ships with a complete suite of the modding tools, you should use those and set a custom VPROJECT (actually, you can use the tools from any game, just set that vproject environment). - Alfred -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Neico Sent: Wednesday, June 26, 2013 4:33 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Source SDK 2013 Release One question does appear in my mind with that tough... How are mods going to be able to use the tools like Hammer in the future? Games ship it with themselves, but for mods there would be a customizable solution needed, or do you expect us to rip the tools stuff from one of the games and modify it until it fits and ship it together with the mod? I think that's a rather big thing that isn't covered by the news at all and will have an impact if there's no solution coming soon. - Neico On 27.06.2013 01:02 GMT +2, Alfred Reynolds wrote: https://github.com/ValveSoftware/source-sdk-2013 That is where you want to go for the code. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joe Ludwig Sent: Wednesday, June 26, 2013 3:49 PM To: 'hlcoders@list.valvesoftware.com' Subject: [hlcoders] Source SDK 2013 Release http://store.steampowered.com/news/10962/ Source SDK 2013 Release We have released an update to the Source SDK, bringing support for Mac OS X and Linux to mod developers and exposing the ability for virtual reality support in your mod. The biggest change with this update is that we are using github to host the source code. You will find the code here. This Source SDK 2013 release also includes a new license that can be foundhere. This new license allows mod authors to share their changes to the SDK more easily. The other change with the Source SDK is that now Hammer and the other mod tools ship with their respective games instead of as part of the SDK Launcher. The launcher itself is being phased out, so it will disappear from your Tools list. You can find information about how to run the tools from the games here. The source for this new SDK release includes the latest code for all the included games, and has many new features: . The games now build and run clients on Windows, OSX, and Linux. Dedicated servers are supported on Windows and Linux. . Steam Pipe (the new Steam content delivery system) is supported by the sample mods. Existing mods can change their gameinfo.txt to match the new format and gain Steam Pipe support. . Support for Virtual Reality via the Oculus Rift has been added to the SDK. Running a compatible mod with -vr on the command line will run the mod in stereo and enable head tracking on the Rift. You can find instructions on getting started with the new Source SDK 2013 on the Valve Developer Community wiki. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:
Re: [hlcoders] Pre-Loading Maps
Prolly some OS caching after access. From: tja...@comcast.net tja...@comcast.net To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Monday, 14 January 2013, 14:47 Subject: Re: [hlcoders] Pre-Loading Maps That's a shame. I did look through zone cpp/h but it might be over my head, when it comes to memory allocation. Also, from what I've heard -heapsize command line doesn't matter anymore with orange box. So I'm not sure if that file is still relevant. Is there any cheap tricks to help performance? I'm bouncing between maps, and users are getting frustrated with load times. I do have a benchmark time that shows how long a map takes to load (grab curtime from preload and compare with curtime in postload. not sure how accurate) and I noticed if the map has been loaded before it takes half the amount of time to load. So something is staying in the memory. From: Jonatan Matějka jonatan1...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Monday, January 14, 2013 8:19:43 AM Subject: Re: [hlcoders] Pre-Loading Maps Hi, if there were not significant changes in engine after HL2 alpha leak, there is no way to load nextmap before mapchange. You can precache it, but it will be trashed on mapchange anyway. If you own leaked source, take a look at zone.cpp/h where you can take a look for yourself. 2013/1/14 Trevor Janok tja...@comcast.net Hello HLCoders. I have no idea how Source loads/renders the BSP levels. Since I assume most (if not all) of this is done in the engine which we don’t have access to. But is there anyway to load a BSP into “memory” so the client can switch maps faster? I mean, if you’re running on decent hardware Source maps load fast. But it would be nice to start “preloading” maps when players near completion of the current level. The gameplay of my mod would help greatly from this, as maps are broken up into multiple levels running on a master server. I guess I can’t really assume what it’s “preloading” as I’m not sure of what Source is doing when it’s switch to a different map. Anybody have any insight? Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] spam prevention...
Might be an idea to just make the mailing lists authenticate with steam login only to join it/able to post or view that page to join the list, that will end the spam. I seriously doubt that anyone legit on any of the lists has no steam account. Not to say that that must be linked, for some rather have another email address for it then the one linked to their steam account, for a variety of reasons. From: Staci Page danalmmp79...@yahoo.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Friday, 2 November 2012, 23:43 Subject: Re: [hlcoders] Starting the Mod Hi yet again! Are u any good at doing a massage? Work is sort of killin me and I have not had a good massage in quite awhile. I can host if you would want, let me know when is a good time for you. I have a adjustable schedule and do school in the middle so I'll make somethin work. Well I've got pics on here if u see them. Simply do the verification thing and it will give you my phone number and we can text or chat and get to know each other a little better. I do like ya thus far! I know its kind of strange to do the screening, the reason why is a few of my girlfriends who have hooked up on CL said to do it since another girlfriend of ours got sexually assaulted when she met a guy from another site and it had been good for them. I'm positive you see my reasoning. Shoot me a text so I'll know ya got it. | |} See you soon ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Prediction Jerkiness with aircraft ?
stop asking for the code, esp when they use it from the VALVE SDK's which means it should already be on your hard disk. If its some they wrote themselves, they wouldn't ask what the difference is between marine vehicle code and other handling code within it. Instead they would link up the code fragments that they wrote themselves. And this is bout the 4th time I see you asking for code or when they quote some code part asking for the full code where its totally irrelevant. Seems to me your not a dev, From: Nick xnicho...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 7 June 2012, 7:23 Subject: Re: [hlcoders] Prediction Jerkiness with aircraft ? Nobody can answer that if you don't share the code On Wed, Jun 6, 2012 at 9:19 PM, Psy_Commando psycomma...@gmail.com wrote: I tried to go with the marine/aircraft hybrid, but I decided to turn it into a marine driven vehicle before. And for some reasons, it works perfectly with no jitter ! What could be taking place in the marine code that would solve that jittering problem ? Thu, May 17, 2012 at 1:26 AM, Psy_Commando psycomma...@gmail.com wrote: Urgh, forget what I said before, the problem is still there.. However, attaching a point_viewcontrol to to the vehicle reduce most of the sluggishness And thanks for the answer Tony. On Wed, May 16, 2012 at 1:37 AM, Tony omega Sergi omegal...@gmail.com wrote: It's probably your movement type. If you're simulating with vphysics, then you've gotta use either applyvelocityimpulse or make a motion controller to apply the velocity properly. if you're not using movetype_vphysics then SetAbsVelocity should work with for example MOVETYPE_NOCLIP or MOVETYPE_FLY. On Wed, May 16, 2012 at 1:31 PM, Psy_Commando psycomma...@gmail.com wrote: Alright, I think I fixed some of the problem. It still jitters from time to time, but if you're lucky it won't do it at all.. Thanks for the help this far guys. The problem was that the new origin and velocity weren't matching. on the server itself during the same frame. But I still don't get it ... For some reasons if I set a velocity and then change the origin, the velocity will be applied 2x times to the entity, making it move very fast : SetAbsVelocity( Vel ); SetAbsOrigin( GetAbsOrigin() + Vel ); If I just set the velocity and not the origin, no movement at all: SetAbsVelocity( Vel ); If I calculate my new origin, by adding a velocity I computed to the current origin, the plane move a the right speed but the velocity stays at 0 evidently, causing issue with any velocity based method ... SetAbsOrigin( GetAbsOrigin() + Vel ); Does anybody knows what's applying the velocity, and why it doesn't apply it when the vehicle origin isn't changed ? On Thu, May 3, 2012 at 11:59 PM, Nick xnicho...@gmail.com wrote: Hard to believe a free sdk such as ALIEN SWARM is going to get any complaints if the code is buggy to begin with..I feel sorry for commando.because without him uploading aworking sdk with the problem, there is no way for someone to help him fix it. On Thu, May 3, 2012 at 12:02 PM, Mart-Jan Reeuwijk mreeu...@yahoo.com wrote: Nick, ppl only need that piece of specific code sometimes, the rest can just be discussed on points of interest. Which is what this mailing list is for. Nobody will upload a full working codebox to test it out, as the snippet of relevant code is the only part thats interesting to the case. He's only looking for pointers and idea's. That way he finds new places to explore in relation to the problem. Uploading the complete edited kit where he has a problem with solves nothing. For 99. % of all that is not relevant, not even withstanding that uploading a SDK is against terms most probably of the SDK. He stated that he used a certain SDK, and that his relevant snippet of code is on a certain place. Thats all thats needed really. From: Nick xnicho...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 3 May 2012, 6:34 Subject: Re: [hlcoders] Prediction Jerkiness with aircraft ? Everything would be solved if there was a working demo of the problem. If a random person can't download and reproduce the problem in one or two clicks... then... not going to be solved. Please give us an exact copy of the sdk u are using. so there is no doubt we can reproduce the problem exactly. that is the only way it will be fixed, ever. On Wed, May 2, 2012 at 4:50 AM, Saul Rennison saul.renni...@gmail.com wrote: Don't worry Tony, he'll ignore you again, and ask for the next week what's still wrong. On Wednesday, May 2, 2012, Tony omega Sergi wrote: Like i said in the first place.. it's only simulating properly
Re: [hlcoders] Prediction Jerkiness with aircraft ?
I told you where to find what his question is bout (don't even know if that part's source code is avail, not looked) you wanted to take a look on it. I would have replied to him if I had done stuff similar or with the same in the past and . As I didn't, and have no time to start figuring out from the SDK to come to the same position as he is now, its no use. I replied to you, to get you to get smarter with the replies, for you keep asking for full source code which nobody is ever going to give unless you're in the same team/project and have that already. Either give a meaningful reply, or give some feedback in which you might search, so they can continue. He as programmer wont be scared to try some stuff out or find out if its correct. Just replying without thinking which achieves nothing is just a waste of time. Now, go back to that question, what was the question about? The discussion had lead to the question what the difference in handling was between a marine object and another moving object. The first thing that comes to mind for me is vertical/horizontal movement limiters/dampeners or speed ramping in w/e capacity it is coded in. For movements in liquid should be moving slower, speeding up/down slower and more limited in speed/direction etc. But I didn't answer that, for I (normally) am not kicking in a open door, for he would know that already. Question would be: isn't the same type of code active, but just the marine with smaller bounds which make it way less/not noticeable. From: Nick xnicho...@gmail.com To: Mart-Jan Reeuwijk mreeu...@yahoo.com; Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 7 June 2012, 13:44 Subject: Re: [hlcoders] Prediction Jerkiness with aircraft ? LOL! U talk nice words. It is easy to pop up out of nowhere and attack me( i was only person to even offer a reply). Mart-Jan Reeuwijk can you determine what the problem is without looking at his code?? I would ask you (Mart-Jan Reeuwijk) to help. Please! This is a serious issue and Psy_Commando is very eager to have this thing fixed! On Thu, Jun 7, 2012 at 1:20 AM, Mart-Jan Reeuwijk mreeu...@yahoo.com wrote: stop asking for the code, esp when they use it from the VALVE SDK's which means it should already be on your hard disk. If its some they wrote themselves, they wouldn't ask what the difference is between marine vehicle code and other handling code within it. Instead they would link up the code fragments that they wrote themselves. And this is bout the 4th time I see you asking for code or when they quote some code part asking for the full code where its totally irrelevant. Seems to me your not a dev, From: Nick xnicho...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 7 June 2012, 7:23 Subject: Re: [hlcoders] Prediction Jerkiness with aircraft ? Nobody can answer that if you don't share the code On Wed, Jun 6, 2012 at 9:19 PM, Psy_Commando psycomma...@gmail.com wrote: I tried to go with the marine/aircraft hybrid, but I decided to turn it into a marine driven vehicle before. And for some reasons, it works perfectly with no jitter ! What could be taking place in the marine code that would solve that jittering problem ? Thu, May 17, 2012 at 1:26 AM, Psy_Commando psycomma...@gmail.com wrote: Urgh, forget what I said before, the problem is still there.. However, attaching a point_viewcontrol to to the vehicle reduce most of the sluggishness And thanks for the answer Tony. On Wed, May 16, 2012 at 1:37 AM, Tony omega Sergi omegal...@gmail.com wrote: It's probably your movement type. If you're simulating with vphysics, then you've gotta use either applyvelocityimpulse or make a motion controller to apply the velocity properly. if you're not using movetype_vphysics then SetAbsVelocity should work with for example MOVETYPE_NOCLIP or MOVETYPE_FLY. On Wed, May 16, 2012 at 1:31 PM, Psy_Commando psycomma...@gmail.com wrote: Alright, I think I fixed some of the problem. It still jitters from time to time, but if you're lucky it won't do it at all.. Thanks for the help this far guys. The problem was that the new origin and velocity weren't matching. on the server itself during the same frame. But I still don't get it ... For some reasons if I set a velocity and then change the origin, the velocity will be applied 2x times to the entity, making it move very fast : SetAbsVelocity( Vel ); SetAbsOrigin( GetAbsOrigin() + Vel ); If I just set the velocity and not the origin, no movement at all: SetAbsVelocity( Vel ); If I calculate my new origin, by adding a velocity I computed to the current origin, the plane move a the right speed but the velocity stays at 0 evidently, causing issue with any velocity based method ... SetAbsOrigin( GetAbsOrigin() + Vel
Re: [hlcoders] Prediction Jerkiness with aircraft ?
Nick, ppl only need that piece of specific code sometimes, the rest can just be discussed on points of interest. Which is what this mailing list is for. Nobody will upload a full working codebox to test it out, as the snippet of relevant code is the only part thats interesting to the case. He's only looking for pointers and idea's. That way he finds new places to explore in relation to the problem. Uploading the complete edited kit where he has a problem with solves nothing. For 99. % of all that is not relevant, not even withstanding that uploading a SDK is against terms most probably of the SDK. He stated that he used a certain SDK, and that his relevant snippet of code is on a certain place. Thats all thats needed really. From: Nick xnicho...@gmail.com To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Sent: Thursday, 3 May 2012, 6:34 Subject: Re: [hlcoders] Prediction Jerkiness with aircraft ? Everything would be solved if there was a working demo of the problem. If a random person can't download and reproduce the problem in one or two clicks... then... not going to be solved. Please give us an exact copy of the sdk u are using. so there is no doubt we can reproduce the problem exactly. that is the only way it will be fixed, ever. On Wed, May 2, 2012 at 4:50 AM, Saul Rennison saul.renni...@gmail.com wrote: Don't worry Tony, he'll ignore you again, and ask for the next week what's still wrong. On Wednesday, May 2, 2012, Tony omega Sergi wrote: Like i said in the first place.. it's only simulating properly on ONE SIDE. which is why you're jittering. I'm sorry I don't have time to actually play with it for you, but if you listen to me that should get you on the right track. the client side is running it's update code as it should, but the server is not moving. so the client is fighting with the networked values. On Wed, May 2, 2012 at 1:40 PM, Psy_Commando psycomma...@gmail.com wrote: *I meant in MP with predictions off On Wed, May 2, 2012 at 12:39 AM, Psy_Commando psycomma...@gmail.com wrote: I'm starting to think something on the server is messing with the server-side position.. I ran the code in MP , and noticed that the clientside position was steady, while the server-side pos was jittering. Update on prediction jittering On Mon, Apr 30, 2012 at 4:46 PM, Psy_Commando psycomma...@gmail.com wrote: Oh, and did I mention that the Hl2 buggy does the same thing ? On Sun, Apr 29, 2012 at 9:15 PM, Psy_Commando psycomma...@gmail.com wrote: Well I didn't change much from the ES code, I just cut the useful parts, and tweaked them to fit the vehicle code I had. So yeah, its pretty much the same thing they did, but I'm guessing maybe it was written that way to fix bug they had with the old prediction system, so that might explain why it doesn't work in my case. Also, since I want this to work in multiplayer, I have to have it shared between client/server. If its only server side the controls will be laggy, and if its client side, it will be difficult to update the position on other clients. I already did override the GetRenderOrigin method and copied the smoothing code for the player in there. The problem is that it works only if there are prediction errors detected, and it detects none. I think you're not far with the truth by saying it might be a battle between smoothing and simulation. One odd thing I noticed, is that when I run the game with maxplayer to 1, it runs only the server code, and the jitter is still there... On Sun, Apr 29, 2012 at 4:56 PM, Joel R. joelru...@gmail.com wrote: I'd start from scratch again. Quick question though... Are the ships in Eternal Silence updating the client entity position and angles as you are? Or is it server side only...? On the flip side... I would create my own custom clientside entity. This way YOU control everything that happens to it, and not the server, because it appears like you are battling with the prediction system. If the origin/angles are off by a small tolerance (defined in c_baseentity.cpp), the client will teleport immediately to the server values. Also, for the smoothing, I'd override the GetRenderOrigin and GetRenderAngles functions. This way you can display a smoothed origin/angles, but the simulation origin and angles are still simulated perfectly. This may be another reason why you are getting jitter, because of the battle between smoothing and simulation. On Sun, Apr 29, 2012 at 2:39 PM, Psy_Commando psycomma...@gmail.com wrote: Finally got the dedicated server to work with my local network ip. It does the same thing as with net_fakelag on the listen server, it doesn't look broken to me... Still can't find what part of the code is causing the stuttering... On Sun, Apr 29, 2012 at 10:43 AM, Ben Pye bfh...@gmail.com wrote: W -- -Tony -- Kind
Re: [hlcoders] Picking up server-side ragdolls like a physics prop
I remember very clearly that when I created a video from a recorded demo, (in
which I knew the ragdoll went particularly funny trajectory) that with the
replay of the demo the trajectory was different every time, which was due that
it was not server side decided upon, but by the client. After that, I called in
a couple friends on the server dragged one to low health and then asked all of
them to point where the ragdoll ended up for them after I shot the rocket. Each
pointed to a entirely different spot after
Ruined a lot of funny vids for me.
From: Nick xnicho...@gmail.com
To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
Sent: Tuesday, 20 March 2012, 3:39
Subject: Re: [hlcoders] Picking up server-side ragdolls like a physics prop
Are u SURE that props are serverside? I always thought they are
clientside entities? I remember that empiresmod had a problem reviving
ragdolls
On Sun, Mar 18, 2012 at 11:56 AM, Carlos Sotelo
charlysot...@hotmail.com wrote:
Greetings,
I've been trying to make the player be able to pick-up ragdolls. I already
included FCAP_IMPULSE_USE for the CRagdollProp::ObjectCap. Thus making them
usable. However, I cannot get my custom use function for ragdolls to get
called.
In the class declaration for CRagdollProp i have:
void OnUse(CBaseEntity *pActivator,CBaseEntity *pCaller, USE_TYPE useType,
float value);
for the DataDesc I have:
DEFINE_USEFUNC( OnUse ),
for its spawn function I added:
SetUse(CRagdollProp::OnUse);
Its implementation right now is simply:
void CRagdollProp::OnUse(CBaseEntity *pActivator,CBaseEntity *pCaller,
USE_TYPE useType, float value) //Underhell
{
Msg(My OnUse Called \n);
}
However, it does not get called ingame when i press E on a ragdoll (even
though the use sound gets emitted).
Any Ideas?
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] [SRC 2007] Problem with shadercompile.exe
Tried disabling HyperThreading (HT) in BIOS? From: Alexander Davidson aldavid...@gmail.com To: hlcoders@list.valvesoftware.com Sent: Thursday, 15 September 2011, 10:21 Subject: Re: [hlcoders] [SRC 2007] Problem with shadercompile.exe Unfortunately setting the affinity in the task manager doesn't work. Shadercompile.exe will still spawn 8 other instances of shadercompile.exe (on the i7 in this rig) and bomb out around 7864343 remaining. This issue isn't OS specific as i tested it under Win XP (SP3) and got the exact same problem. Any suggestions? -- -Alex Davidson (aldavid...@gmail.com) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
