Re: [hlcoders] Crash in engine.dll help?
From what I could tell, the stack wasn't corrupt, I did see valid calls to the OS kernel... or at least what I would expect to be valid calls to the kernel at the time of the crash (waiting for mutex on some threads, and obviously the exception on the main thread where the crash occurred). None of the addresses appeared random and were all within valid memory bounds of modules that were active at the time of the crash. Anyway, I went back through the revisions between last week and this week and only one thing changed... the removal of several screenspace effects, that is all. Very little changed between last week and this week's test. Regardless, we're going to try playing last week's build next weekend to see what happens. The weekend play tests are the only time we get the player counts up to the level at which we need them in order to see the crashes; as it seems load-dependent. Otherwise we do small regression tests during the week if any larger and/or sensitive changes have taken place, but lately those haven't been happening due to our upcoming release. I agree that it would be nice to have stripped PDB's, if nothing else to size out the call stack information so its at least reliable. However, I understand the business reason to not have them available so I can't say I blame Valve for not making them public, it isn't in their best interest to do so from their perspective. It is for that reason that I decided to take a long-shot and ask for help with it. I figured if nothing else maybe someone in the community could offer up some insight. On Mon, Jan 28, 2013 at 11:30 AM, Nicholas Hastings psycho...@alliedmods.net wrote: Stripped PDBs would give an idea of where crashes happen without having nearly as much information. http://msdn.microsoft.com/en-us/library/y87kw2fd(v=vs.110).aspx Sammy sam...@gmail.com Monday, January 28, 2013 11:26 AM Unfortunately it also exposes the source code of the engine in a human readable way, line by line except for comments, with the right tools. Which is why, I believe, they don't. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders Neico ad...@neic0.de Monday, January 28, 2013 4:26 AM It really would help if Valve would provide an Symbol Server like SourceMod and Microsoft do, it makes the whole debugging process way easier... - Neico On 28.01.2013 07:39:56 GMT+0100, Sammy sam...@gmail.comsam...@gmail.com wrote: ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders Sammy sam...@gmail.com Monday, January 28, 2013 1:39 AM I support Saul. Often when it happens with me it's some stupid little thing I forgot or did wrong in the code. You don't have to manually go rev by rev, try to remember exactly when it started to happen, the sooner the better, if not try to identify a rev you're sure would not be the issue, like before you've started working on the current feature or when you lastly released a patch, then keep decreasing the possibilities until the possibilities are minimal. I remember cases where a single line caused crashes with no call stack or random addresses in the engine. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders Saul Rennison saul.renni...@gmail.com Sunday, January 27, 2013 8:02 PM That's most likely due to stack corruption. If it happened this week, keep going back revisions until you don't crash. Then figure out where in the code you MAY be dereferencing hanging pointers. Kind regards, Saul Rennison ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders Cale Dunlap cale.dun...@gmail.com Sunday, January 27, 2013 7:50 PM I understand that crashes in the engine can and most often do result from calls originating from the game dlls. However as I've said in the original post, every active thread at the time of the crash contains no game code anywhere in their respective callstacks. That's why I'm wondering if its possible for someone at Valve to tell me the function in which the referenced address resides. Since the PDB files for the engine aren't public, the call stack information below the call in the stack at the referenced address isn't reliable and therefore may still involve game code. So if I knew the function in the engine DLL where the crash occurred I could attempt to locate calls to that function from the game code and possibly determine a cause of the crash and which
[hlcoders] Crash in engine.dll help?
During our weekly play test for Firearms: Source today, we had a unusually high number of crashes. 99% of the crashes were due to what appears to be a NULL pointer exception or pure virtual function call somewhere in engine.dll. If I provide a call address inside of engine.dll, would it be possible for someone from Valve to tell me which engine function was being called? Just wondering if maybe we're making a call to something that ended up getting deprecated and ultimately removed from the code base yet the declaration for the function still exists in the engine headers provided with the SDK. The entire call stack for every running thread at the time of the crash contains no game-side code, and this particular crash occurred in the main thread. Without PDB's for the engine dll, anything below the offending address in engine.dll may not be correct, meaning it may still be game-code making the call, correct? Right now the calls prior to the address in which it crashed are all calls to the OS Kernel's ReadFile function. I also saw some crash dumps calling GetProcAddress right before the crash, which is why I thought perhaps it was trying to make a pure virtual call (if the symbol didn't exist). Any help would be very appreciated. The offending address is 0x100CC018, assuming the base address of the engine.dll is 0x1000. -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Crash in engine.dll help?
I understand that crashes in the engine can and most often do result from calls originating from the game dlls. However as I've said in the original post, every active thread at the time of the crash contains no game code anywhere in their respective callstacks. That's why I'm wondering if its possible for someone at Valve to tell me the function in which the referenced address resides. Since the PDB files for the engine aren't public, the call stack information below the call in the stack at the referenced address isn't reliable and therefore may still involve game code. So if I knew the function in the engine DLL where the crash occurred I could attempt to locate calls to that function from the game code and possibly determine a cause of the crash and which code path led there. On Sun, Jan 27, 2013 at 7:40 PM, Sammy sam...@gmail.com wrote: Usually crashes in the engine are caused either by the map or game dlls, you could try with older versions and see if the crash still happens. Once you find where it started to happen it's easier to find the issue. 2013/1/27 Cale Dunlap cale.dun...@gmail.com During our weekly play test for Firearms: Source today, we had a unusually high number of crashes. 99% of the crashes were due to what appears to be a NULL pointer exception or pure virtual function call somewhere in engine.dll. If I provide a call address inside of engine.dll, would it be possible for someone from Valve to tell me which engine function was being called? Just wondering if maybe we're making a call to something that ended up getting deprecated and ultimately removed from the code base yet the declaration for the function still exists in the engine headers provided with the SDK. The entire call stack for every running thread at the time of the crash contains no game-side code, and this particular crash occurred in the main thread. Without PDB's for the engine dll, anything below the offending address in engine.dll may not be correct, meaning it may still be game-code making the call, correct? Right now the calls prior to the address in which it crashed are all calls to the OS Kernel's ReadFile function. I also saw some crash dumps calling GetProcAddress right before the crash, which is why I thought perhaps it was trying to make a pure virtual call (if the symbol didn't exist). Any help would be very appreciated. The offending address is 0x100CC018, assuming the base address of the engine.dll is 0x1000. -Cale ___ 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] Player Models
I haven't personally done what you're trying to do, but perhaps looking at bone followers would provide some insight. I'm not sure if they'll address what you're asking. Other members of the list can correct me if I'm wrong. I've actually been curious about this myself. On Oct 1, 2012 4:29 PM, tja...@comcast.net wrote: Thanks for the help on the objective entity, i got it working! I didn't wanna send two messages.. My next question is about player models. In HL1 the client can set there player model to whatever models they had installed, and any other clients that didn't have the model they just appeared as the default player model. I'd like to implement this in HL2. I allowed clients to set there model to anything, which does a (late) precache so the model actually shows up. But other clients get the error.mdl model - anytime to change this? 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
Re: [hlcoders] Player Models
Crap, wrong thread sorry. That's what I get for responding via cell phone lol. On Oct 3, 2012 2:00 PM, Cale Dunlap cale.dun...@gmail.com wrote: I haven't personally done what you're trying to do, but perhaps looking at bone followers would provide some insight. I'm not sure if they'll address what you're asking. Other members of the list can correct me if I'm wrong. I've actually been curious about this myself. On Oct 1, 2012 4:29 PM, tja...@comcast.net wrote: Thanks for the help on the objective entity, i got it working! I didn't wanna send two messages.. My next question is about player models. In HL1 the client can set there player model to whatever models they had installed, and any other clients that didn't have the model they just appeared as the default player model. I'd like to implement this in HL2. I allowed clients to set there model to anything, which does a (late) precache so the model actually shows up. But other clients get the error.mdl model - anytime to change this? 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
Re: [hlcoders] Show a model on the player
I haven't personally done what you're trying to do, but perhaps looking at bone followers would provide some insight. I'm not sure if they'll address what you're asking. Other members of the list can correct me if I'm wrong. I've actually been curious about this myself. Cale On Thursday, September 27, 2012, Jan Hartung wrote: Hi, ** ** I’m trying to render different items (models) on the player model. The player model has been set up with various attachments where I could render the items. My problem is that I couldn’t find a way to attach an item to any of the attachment points. The net doesn’t really help with this and I couldn’t find the code used to show the weapons on the player models. Any hints on how to render models on attachment points? ** ** Jan ** ** ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Hung hl2.exe process for 2007-based mods
Sometimes they monitor this list, but most of the time they stay pretty quiet. I've corresponded with them as a mod developer and business customer. The business customer responses are a little more swift than the mod developer ones, though it has been a while since then. Maybe things have changed? PS: lol @ Minh =D On Wednesday, May 23, 2012, Andrew McWatters wrote: Thanks for the clarification, the licensee SDK bit is what I figured immediately after I read the bit about filesystem_steam in Garry’s post. Besides Garry, do any of you have any positive experiences with contacting Valve over issues with the engine? I’ve never bothered trying, considering my other emails never get responses. Andrew McWatters ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Hung hl2.exe process for 2007-based mods
Update on this... Saul, I tried your suggestion but it didn't have any effect. It sounds like that was sort of expected though since your stacktrace was different than mine. Oh well, worth a shot at least and I appreciate the suggestion. Andrew, I had actually come across your hack by way of Google when I first started looking into this problem. I didn't immediately jump on it because--like your comments in the code--its a hack. I did however take note that it was there, figuring it would be an option when needed. Well, it turns out it was needed... the hack worked and hl2.exe closes now. Though I can't say for certain it is closing gracefully, most likely not. But now at least I won't have a bunch of testers whining about not being able to launch the mod a second time without encountering a nag about a previous instance already running, lol. Until we find a more appropriate fix, or Valve decides to patch the 2007 SDK again, this will have to work. I highly dislike doing little duct-tape toothpick hacks like this, but I guess it is the only option at the present time. Thanks again everyone. -Cale On Monday, May 21, 2012, Cale Dunlap wrote: Great feedback everyone, I appreciate it. It is good to know it isn't just 218-based mods that have this problem. That sort of reinforces my findings--being related to Steam, or something outside of the game/mod. I'll try out some of the suggestions and report back. Thanks again! -Cale On Sun, May 20, 2012 at 1:52 PM, Saul Rennison saul.renni...@gmail.comwrote: Let me know if this works for you guys. We had this problem in CSProMod and I fixed it a few months ago, but my stacktrace was different to yours Cale, so this might not be it. public/tier1/utllinkedlist.h, around line 654: while ( i != InvalidIndex() ) Replace with: while ( IsValidIndex(i) ) Kind regards, *Saul Rennison* On 20 May 2012 16:43, Ben Pye bfh...@gmail.com wrote: Happens to me on Alien Swarm sometimes too, odd issue. On Sun, May 20, 2012 at 3:42 PM, Jan Hartung jan.hart...@gmx.de wrote: We’re strictly 2007 based and it happens for our mod as well. Although it didn’t happen up to about 3 or 4 weeks ago and also doesn’t happen every time now. It’s a strange problem. ** ** Jan ** ** *Von:* hlcoders-boun...@list.valvesoftware.com [mailto: hlcoders-boun...@list.valvesoftware.com] *Im Auftrag von *Tobias Kammersgaard *Gesendet:* Sonntag, 20. Mai 2012 15:53 *An:* Discussion of Half-Life Programming *Betreff:* Re: [hlcoders] Hung hl2.exe process for 2007-based mods ** ** I believe this happens with mods based on Alien Swarm, if that's any consolation . We're currently bringing our mod over to that branch, and I've noticed Swarm.exe keeps running in the background after shutting the mod down. ** ** - ScarT ** ** ** ** On 20 May 2012 07:55, Andrew McWatters mcwattersand...@gmail.com wrote:* *** You're not alone, Cale. This happens on all 2007-based mods, and it's been months without a fix. I can't remember when this first started, but I don't see it being fixed anytime soon. Considering that I can't remember when the issue started, it could even have been years since the issue first arose.* *** ** ** To be frank, considering support for the Source SDK codebases is sparce in terms of frequency, you'll just have to deal with the problem. A terrible way that I resolved the issue with my mod was to simply terminate the process right at the end of the game code shutdown routine. ** ** http://code.google.com/p/hl2sb-src/source/detail?r=50path=/trunk/src/game/client/cdll_client_int.cpp ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Hung hl2.exe process for 2007-based mods
Great feedback everyone, I appreciate it. It is good to know it isn't just 218-based mods that have this problem. That sort of reinforces my findings--being related to Steam, or something outside of the game/mod. I'll try out some of the suggestions and report back. Thanks again! -Cale On Sun, May 20, 2012 at 1:52 PM, Saul Rennison saul.renni...@gmail.comwrote: Let me know if this works for you guys. We had this problem in CSProMod and I fixed it a few months ago, but my stacktrace was different to yours Cale, so this might not be it. public/tier1/utllinkedlist.h, around line 654: while ( i != InvalidIndex() ) Replace with: while ( IsValidIndex(i) ) Kind regards, *Saul Rennison* On 20 May 2012 16:43, Ben Pye bfh...@gmail.com wrote: Happens to me on Alien Swarm sometimes too, odd issue. On Sun, May 20, 2012 at 3:42 PM, Jan Hartung jan.hart...@gmx.de wrote: We’re strictly 2007 based and it happens for our mod as well. Although it didn’t happen up to about 3 or 4 weeks ago and also doesn’t happen every time now. It’s a strange problem. ** ** Jan ** ** *Von:* hlcoders-boun...@list.valvesoftware.com [mailto: hlcoders-boun...@list.valvesoftware.com] *Im Auftrag von *Tobias Kammersgaard *Gesendet:* Sonntag, 20. Mai 2012 15:53 *An:* Discussion of Half-Life Programming *Betreff:* Re: [hlcoders] Hung hl2.exe process for 2007-based mods ** ** I believe this happens with mods based on Alien Swarm, if that's any consolation . We're currently bringing our mod over to that branch, and I've noticed Swarm.exe keeps running in the background after shutting the mod down. ** ** - ScarT ** ** ** ** On 20 May 2012 07:55, Andrew McWatters mcwattersand...@gmail.com wrote: You're not alone, Cale. This happens on all 2007-based mods, and it's been months without a fix. I can't remember when this first started, but I don't see it being fixed anytime soon. Considering that I can't remember when the issue started, it could even have been years since the issue first arose. ** ** To be frank, considering support for the Source SDK codebases is sparce in terms of frequency, you'll just have to deal with the problem. A terrible way that I resolved the issue with my mod was to simply terminate the process right at the end of the game code shutdown routine. ** ** http://code.google.com/p/hl2sb-src/source/detail?r=50path=/trunk/src/game/client/cdll_client_int.cpp http://code.google.com/p/hl2sb-src/source/diff?spec=svn50r=50format=sidepath=/trunk/src/game/client/cdll_client_int.cpp#sc_svn50_973 ** ** This hack isn't documented anywhere publicly other than on my repo. ** ** Anyway, most issues with the Source SDK I attempt to resolve myself or through the assistance of other clever developers. Some wiki scraps and mailing list snippets here and there also help to a certain degree, but generally speaking, you get nearly nothing to work with, and I don't know when Valve will pump out an update for the Source SDK that isn't hat related. There also don't seem to be many regulars who work with Source and share their progress publicly anymore. ** ** Honestly, I thought it was somewhat commendable you brought this up. ** ** Best of luck. ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
[hlcoders] Hung hl2.exe process for 2007-based mods
Have any other mod developers been experiencing hung hl2.exe processes after closing their mods? I've got 3 completely different Source SDK Base 2007 mods on my machine and none of them seem to ever actually stop the hl2.exe process after closing the launcher. This happens in release and debug builds alike, including a vanilla 'Create a Mod' build with absolutely no changes to the code. As far as I can tell, this appears to be rooted outside of the SDK code itself and somewhere in the Steam API. Since I was able to reproduce this in a debug build, I attached the VS debugger and checked the module list to see if any SDK code was still churning. No mod sdk code was in in memory on any running thread during the hang; client and server dlls shutdown and unloaded without issue. The debug output window gave a few hints as to where the problem might be. Once the mod shuts down and the launcher window closes, the last message in the output window is: The thread 'CIPCServer::Thread_MainLoop()' (0x1a00) has exited with code 0 (0x0), which of course expected during normal operation. However the main loop exit message is followed several seconds later by 8 repeats of Thread CNet Encrypt:0 (ID 3228) failed to shut down. So could CNet Encrypt:0 be the hung thread? Keeping that question in mind, I opened the thread list in Visual Studio, found the CNet Encrypt:0 thread and opened its call stack. It appears to be getting stuck in crashhandler.dll. The call stack is below: ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes crashhandler.dll!6a779f78() [Frames below may be incorrect and/or missing, no symbols loaded for crashhandler.dll] crashhandler.dll!6a77c9a4() ntdll.dll!_NtQueryInformationThread@20() + 0x12 bytes kernel32.dll!@BaseThreadInitThunk@12() + 0x19 bytes Also noting the apparent (by its name) networking-related nature of this thread, I took a look at which IP ports the hl2.exe process was still bound to. The only one in the list of ports still open by hl2.exe was UDP 26901 (Steam master server?? can't find reliable documentation on it). So as far as I can tell it appears that the thread dealing with master server updates is crashing sometime during execution--presumably at shutdown. This ends up triggering a signal hook (maybe?) in crashhandler.dll to capture whatever is left on the stack and write it to a dump before it goes completely belly-up. But something inside the dump-writing process is waiting on a mutex or condition that never ends up getting released or triggered respectively? IE: thread deadlock? Can anybody else confirm/deny the reproducibility and possibly offer any other insight? I haven't yet confirmed if this occurs for other app id's. All three of the ones I tested are based on 218. Thanks, Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Scaleform in Source?
Cool, good to know. Thanks Matt. On Tue, Apr 5, 2011 at 9:14 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: You should be safe if you in general launch with -insecure or stay through VS launched builds which are also in Vac Insecure mode. On Tue, Apr 5, 2011 at 6:11 PM, Cale Dunlap cale.dun...@gmail.com wrote: Agreed, but we just acquired a Scaleform GFx evaluation license for a project I'm working on. I was just curious if anybody has ever hacked up enough of the Source SDK code to implement essentially a different UI package in general, I would figure the process would be similar regardless of what package it is. Of course being a Source SDK licensee would make things easier, but unfortunately the license that this project has with Valve is limiting to say the least. I'm still going to try, just to see how far I can get :) I'm sure I'll hit a huge roadblock somewhere. Got myself another Steam account specifically for this task, in case VAC flags me =/ Thanks Tony. -Cale On Tue, Apr 5, 2011 at 8:15 PM, Tony omega Sergi omegal...@gmail.comwrote: I would think, given that scaleform requires a license to use, and to attain their SDK, that noone would be implementing scaleform into SDK code, but would rather do it as a licensee, and into the engine properly. Speaking of that, Mabinogi (vindictus) uses scaleform instead of VGUI. On Wed, Apr 6, 2011 at 4:48 AM, Cale Dunlap cale.dun...@gmail.comwrote: This is probably a long-shot, but I thought I might ask before I embark on this journey... has anybody made any sort of attempt at implementing Scaleform into the Source SDK? I assume that since without the code to the material system interface this is nearly impossible, short of injecting assembly jumps into Direct3D after it's been loaded into memory and hijacking the render loop. I also assume this would get an account VAC-banned pretty quick? Any input/feedback is appreciated. -Cale ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Scaleform in Source?
This is probably a long-shot, but I thought I might ask before I embark on this journey... has anybody made any sort of attempt at implementing Scaleform into the Source SDK? I assume that since without the code to the material system interface this is nearly impossible, short of injecting assembly jumps into Direct3D after it's been loaded into memory and hijacking the render loop. I also assume this would get an account VAC-banned pretty quick? Any input/feedback is appreciated. -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Scaleform in Source?
Agreed, but we just acquired a Scaleform GFx evaluation license for a project I'm working on. I was just curious if anybody has ever hacked up enough of the Source SDK code to implement essentially a different UI package in general, I would figure the process would be similar regardless of what package it is. Of course being a Source SDK licensee would make things easier, but unfortunately the license that this project has with Valve is limiting to say the least. I'm still going to try, just to see how far I can get :) I'm sure I'll hit a huge roadblock somewhere. Got myself another Steam account specifically for this task, in case VAC flags me =/ Thanks Tony. -Cale On Tue, Apr 5, 2011 at 8:15 PM, Tony omega Sergi omegal...@gmail.comwrote: I would think, given that scaleform requires a license to use, and to attain their SDK, that noone would be implementing scaleform into SDK code, but would rather do it as a licensee, and into the engine properly. Speaking of that, Mabinogi (vindictus) uses scaleform instead of VGUI. On Wed, Apr 6, 2011 at 4:48 AM, Cale Dunlap cale.dun...@gmail.com wrote: This is probably a long-shot, but I thought I might ask before I embark on this journey... has anybody made any sort of attempt at implementing Scaleform into the Source SDK? I assume that since without the code to the material system interface this is nearly impossible, short of injecting assembly jumps into Direct3D after it's been loaded into memory and hijacking the render loop. I also assume this would get an account VAC-banned pretty quick? Any input/feedback is appreciated. -Cale ___ 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
[hlcoders] Custom render targets always 64x64?
Has anybody else ever seen a case where their render targets are always returning 64 for both GetActualWidth() and GetActualHeight() ? This seems to be most prevalent on HDR maps for some reason. Here's the code that is creating my render target: pMaterialSystem-CreateNamedRenderTargetTextureEx2( VarArgs(_rt_Sensor%d, idx), 512, 512, RT_SIZE_OFFSCREEN, pMaterialSystem-GetBackBufferFormat(), MATERIAL_RT_DEPTH_SHARED, TEXTUREFLAGS_CLAMPS | TEXTUREFLAGS_CLAMPT, CREATERENDERTARGETFLAGS_HDR ); Where idx is a number between 0 and 7 (total of 8 render targets). Any ideas why this is happening? Thanks in advance! -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Custom render targets always 64x64?
Yes there is actually. In order to achieve the effect required we have to force the tonemap scale to a specific value when rendering the output that goes to the render target. On Fri, Jan 7, 2011 at 10:11 AM, Saul Rennison saul.renni...@gmail.comwrote: Is there a reason why your render target needs to be HDR? I've been able to create render targets perfectly fine without problem. Thanks, - Saul. On 7 January 2011 14:59, Cale Dunlap cale.dun...@gmail.com wrote: Has anybody else ever seen a case where their render targets are always returning 64 for both GetActualWidth() and GetActualHeight() ? This seems to be most prevalent on HDR maps for some reason. Here's the code that is creating my render target: pMaterialSystem-CreateNamedRenderTargetTextureEx2( VarArgs(_rt_Sensor%d, idx), 512, 512, RT_SIZE_OFFSCREEN, pMaterialSystem-GetBackBufferFormat(), MATERIAL_RT_DEPTH_SHARED, TEXTUREFLAGS_CLAMPS | TEXTUREFLAGS_CLAMPT, CREATERENDERTARGETFLAGS_HDR ); Where idx is a number between 0 and 7 (total of 8 render targets). Any ideas why this is happening? Thanks in advance! -Cale ___ 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] Custom render targets always 64x64?
If by RT_SIZE_EXACT you mean RT_SIZE_NO_CHANGE, then yes I've tried that as well. I'm pulling my hair out :( I've seriously tried about every combination of flags I can come up with. Is it possible that the material system is deciding not to create a render target texture as big as I'm asking so it just sets it down to 64x64 I wonder... just to prevent resource over-allocation or something? Who knows... its such a closed system... :( On Fri, Jan 7, 2011 at 10:52 AM, Saul Rennison saul.renni...@gmail.comwrote: Have you tried RT_SIZE_EXACT? That might ensure that the render target is created with exact dimensions. Thanks, - Saul. On 7 January 2011 15:30, Cale Dunlap cale.dun...@gmail.com wrote: Yes there is actually. In order to achieve the effect required we have to force the tonemap scale to a specific value when rendering the output that goes to the render target. On Fri, Jan 7, 2011 at 10:11 AM, Saul Rennison saul.renni...@gmail.comwrote: Is there a reason why your render target needs to be HDR? I've been able to create render targets perfectly fine without problem. Thanks, - Saul. On 7 January 2011 14:59, Cale Dunlap cale.dun...@gmail.com wrote: Has anybody else ever seen a case where their render targets are always returning 64 for both GetActualWidth() and GetActualHeight() ? This seems to be most prevalent on HDR maps for some reason. Here's the code that is creating my render target: pMaterialSystem-CreateNamedRenderTargetTextureEx2( VarArgs(_rt_Sensor%d, idx), 512, 512, RT_SIZE_OFFSCREEN, pMaterialSystem-GetBackBufferFormat(), MATERIAL_RT_DEPTH_SHARED, TEXTUREFLAGS_CLAMPS | TEXTUREFLAGS_CLAMPT, CREATERENDERTARGETFLAGS_HDR ); Where idx is a number between 0 and 7 (total of 8 render targets). Any ideas why this is happening? Thanks in advance! -Cale ___ 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] Custom render targets always 64x64?
Alright the pattern seems as if this _only_ happens on HDR maps hmm... a clue. On Fri, Jan 7, 2011 at 11:04 AM, Cale Dunlap cale.dun...@gmail.com wrote: If by RT_SIZE_EXACT you mean RT_SIZE_NO_CHANGE, then yes I've tried that as well. I'm pulling my hair out :( I've seriously tried about every combination of flags I can come up with. Is it possible that the material system is deciding not to create a render target texture as big as I'm asking so it just sets it down to 64x64 I wonder... just to prevent resource over-allocation or something? Who knows... its such a closed system... :( On Fri, Jan 7, 2011 at 10:52 AM, Saul Rennison saul.renni...@gmail.comwrote: Have you tried RT_SIZE_EXACT? That might ensure that the render target is created with exact dimensions. Thanks, - Saul. On 7 January 2011 15:30, Cale Dunlap cale.dun...@gmail.com wrote: Yes there is actually. In order to achieve the effect required we have to force the tonemap scale to a specific value when rendering the output that goes to the render target. On Fri, Jan 7, 2011 at 10:11 AM, Saul Rennison saul.renni...@gmail.comwrote: Is there a reason why your render target needs to be HDR? I've been able to create render targets perfectly fine without problem. Thanks, - Saul. On 7 January 2011 14:59, Cale Dunlap cale.dun...@gmail.com wrote: Has anybody else ever seen a case where their render targets are always returning 64 for both GetActualWidth() and GetActualHeight() ? This seems to be most prevalent on HDR maps for some reason. Here's the code that is creating my render target: pMaterialSystem-CreateNamedRenderTargetTextureEx2( VarArgs(_rt_Sensor%d, idx), 512, 512, RT_SIZE_OFFSCREEN, pMaterialSystem-GetBackBufferFormat(), MATERIAL_RT_DEPTH_SHARED, TEXTUREFLAGS_CLAMPS | TEXTUREFLAGS_CLAMPT, CREATERENDERTARGETFLAGS_HDR ); Where idx is a number between 0 and 7 (total of 8 render targets). Any ideas why this is happening? Thanks in advance! -Cale ___ 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] Custom render targets always 64x64?
Alright I think I found a workaround. I created 8 new render target *.vtf files and didn't do the Init() operation on the ITexture instances until the render target has actually been requested for the first time. This seems to do the trick for now. The old way I was doing it was create them all in memory and then initialize them all in my IClientRenderTargets implementation when InitClientRenderTargets() is called and then shut them down when ShutdownClientRenderTargets() is called. The render targets are passed out as necessary and marked as in-use until they are given back. This didn't seem to work too well. During game load, InitClientRenderTargets() is called--even for the launcher menu. This created the render targets just fine; with the correct size. However once I load a map that uses HDR, the ShutdownClientRenderTargets() function is called followed by another call to InitClientRenderTargets(). It is this second call that re-creates the render targets with the incorrect size. Anyway, long story short. I think I got it. -Cale On Fri, Jan 7, 2011 at 11:14 AM, Cale Dunlap cale.dun...@gmail.com wrote: Alright the pattern seems as if this _only_ happens on HDR maps hmm... a clue. On Fri, Jan 7, 2011 at 11:04 AM, Cale Dunlap cale.dun...@gmail.comwrote: If by RT_SIZE_EXACT you mean RT_SIZE_NO_CHANGE, then yes I've tried that as well. I'm pulling my hair out :( I've seriously tried about every combination of flags I can come up with. Is it possible that the material system is deciding not to create a render target texture as big as I'm asking so it just sets it down to 64x64 I wonder... just to prevent resource over-allocation or something? Who knows... its such a closed system... :( On Fri, Jan 7, 2011 at 10:52 AM, Saul Rennison saul.renni...@gmail.comwrote: Have you tried RT_SIZE_EXACT? That might ensure that the render target is created with exact dimensions. Thanks, - Saul. On 7 January 2011 15:30, Cale Dunlap cale.dun...@gmail.com wrote: Yes there is actually. In order to achieve the effect required we have to force the tonemap scale to a specific value when rendering the output that goes to the render target. On Fri, Jan 7, 2011 at 10:11 AM, Saul Rennison saul.renni...@gmail.com wrote: Is there a reason why your render target needs to be HDR? I've been able to create render targets perfectly fine without problem. Thanks, - Saul. On 7 January 2011 14:59, Cale Dunlap cale.dun...@gmail.com wrote: Has anybody else ever seen a case where their render targets are always returning 64 for both GetActualWidth() and GetActualHeight() ? This seems to be most prevalent on HDR maps for some reason. Here's the code that is creating my render target: pMaterialSystem-CreateNamedRenderTargetTextureEx2( VarArgs(_rt_Sensor%d, idx), 512, 512, RT_SIZE_OFFSCREEN, pMaterialSystem-GetBackBufferFormat(), MATERIAL_RT_DEPTH_SHARED, TEXTUREFLAGS_CLAMPS | TEXTUREFLAGS_CLAMPT, CREATERENDERTARGETFLAGS_HDR ); Where idx is a number between 0 and 7 (total of 8 render targets). Any ideas why this is happening? Thanks in advance! -Cale ___ 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] Anyone using an SSD Drive for compiling?
I use a SSD in my laptop for work when I write code. I don't notice much of a difference when coding, but booting is definitely faster. However I've had some issues with it, not sure if it is just the laptop in general or the SSD. Sometimes the system will hang up periodically, like it is waiting on disk for a long period of time (by long I mean a few seconds, not like minutes or anything). Once those momentary losses in performance clear up, everything is pretty quick again. They just happen more frequently than I would like... and sometimes it does that shortly before blue-screening. Like I said though, not sure if its the drive or the laptop (Hell Splatitude D830). I'm not convinced on the quality/reliability of the drives though, yes they can be fast, but like Haza said, they're built on cheaper parts. I'm almost inclined to say that using the ol' whirling disks-o-fury is a safer bet than a SSD. Just my $0.02, or 28.7769784 KRW =D Cale On Mon, Dec 8, 2008 at 10:17 AM, Haza [EMAIL PROTECTED] wrote: USB keys are not the same as a SSD drive. The NAND flash in them is usually cheap poor quality, and slow(Like worse than a HDD + the speed limitations of the USB bus). Your best way to a cheap solution, would be to get a Compact Flash card and a CF to IDE adapter. Have a look here for any information about card speeds. http://www.hjreggel.net/cardspeed/ http://www.hjreggel.net/cardspeed/cs_udmacf.html Also USB drives for comparison: http://www.tomshardware.com/reviews/data-transfer-run,1037-10.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Monday, 8 December 2008 9:34 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Anyone using an SSD Drive for compiling? Does running the compiler and storing the code on a 8Gb USB stick count as an SSD drive? :D - Jed 2008/12/8 Andrew Ritchie [EMAIL PROTECTED]: 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 ___ 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] Preventing USP from equipping silencer
Hi Tan,
You can override the Equip( CBaseCombatCharacter *pOwner ) function to
handle the first pickup of a weapon. This gets called when a player obtains
the weapon either by touching it or when they are given it programmatically
using GiveNamedItem().
Also, why do you need to keep track of the silenced status at the player
object when it really only relates to the gun? If you kept the silenced
state local to the gun itself and not to the player then just un-set the
silencer boolean on the weapon object when the player drops the gun to the
ground then the next player that picks it up will have an un-silenced USP.
It might be a better design to do it that way and it will probably prevent a
few bugs along the way... such as if a player picks up a gun and you don't
set the player's silenced flag to false, any gun they could pick up could be
silenced regardless of it has a silencer or not. Unless I'm just totally
missing the real reason why you're holding the silencer flag on the player.
I hope that helps.
-Cale
On Fri, Jul 11, 2008 at 4:22 AM, Tan Theodore [EMAIL PROTECTED]
wrote:
I've created a USP with a silencer but I would like to prevent the USP to
be equipped with the silencer if the player swaps weapon/throws it. I've
tried doing this:
void CUSP::SecondaryAttack( void )
{
m_pPlayer-m_iSilencing = 1; //equipping silencer now
if (m_pPlayer-m_iSilencing == 1) //if it's being equipped now
{
if (m_iSilenced == 0) //if sliencer is not attached
{
m_pPlayer-m_iSilencing = 1; //start equipping
SendWeaponAnim( USP_ADD_SILENCER ); //play anim
m_flTimeWeaponIdle = m_flNextPrimaryAttack = m_flNextSecondaryAttack =
UTIL_WeaponTimeBase() + 3.2;
m_pPlayer-m_iSilencing = 0; //stop equipping
m_iSilenced = 1; //silencer attached
}
else //if silencer is attached
{
m_pPlayer-m_iSilencing = 1; //unequipping now
SendWeaponAnim( USP_REMOVE_SILENCER ); //play anim
m_flTimeWeaponIdle = m_flNextPrimaryAttack = m_flNextSecondaryAttack =
UTIL_WeaponTimeBase() + 3.2;
m_pPlayer-m_iSilencing = 0; //stop equipping
m_iSilenced = 0; //no silencer attached
}
}
else if (m_pPlayer-m_iSilencing == 0) //if it's not being equipped
{
m_iSilenced = m_iSilenced; // get the value of previous silencer status
return;
}
}
void CUSP::Holster( )
{
if (m_pPlayer-m_iSilencing == 1) //if holstered while silencing
{
m_iSilenced = m_iSilenced; //get the previous value.
}
else
{
}
}
Player.h
.
.
.
int m_iSilencing; //is the silencer being fitted for the USP.45?
weapon.h
.
.
.
int m_iSilenced; //is the USP.45 silenced?
I've tried all morning to make this work but to no avail. Any suggestions?
I even tried looking at the reload function but it's very indepth and I was
wondering if there is a simpler way. Sorry if this is double-posted.
Something's screwy with my router.
_
Check out Barclays Premier League exclusive video clips here!
http://fc.sg.msn.com/index.aspx
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Engine Error Related to Physics Props
Hello all, I have a map with numerous props on it, most of them are prop_static or prop_detail, but a few are prop_physics or prop_physics_multiplayer. When the game loads up and it loads the map I get an engine error with the message: UserMessageBegin: New message started before matching call to EndMessage. I think I understand what this error means. If my understanding is correct, it means the client has been sent the same message twice without ending the first one? This seems to ONLY be related to a certain prop model--one of the stock HL2 ones (the toilet). Is there any way to find out what message is being sent and when? This error generates a mini dump but the call stack isn't going back far enough to find out what made the engine calls. I can't debug it any further than simply seeing this message on the screen and identifying a pattern. I still have no idea what user message it is this is. Any help would be appreciated. Thanks, Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Engine Error Related to Physics Props
Perhaps I wasn't clear in what I'm asking. This only happens on specific prop models. I want to know what message is actually the culprit. I havent modified any prop code so it isnt a custom message. Even if it were, i would not know what message it was. On 6/15/08, Tom Edwards [EMAIL PROTECTED] wrote: Every UserMessage() has to be closed by MessageEnd(). Cale Dunlap wrote: Hello all, I have a map with numerous props on it, most of them are prop_static or prop_detail, but a few are prop_physics or prop_physics_multiplayer. When the game loads up and it loads the map I get an engine error with the message: UserMessageBegin: New message started before matching call to EndMessage. I think I understand what this error means. If my understanding is correct, it means the client has been sent the same message twice without ending the first one? This seems to ONLY be related to a certain prop model--one of the stock HL2 ones (the toilet). Is there any way to find out what message is being sent and when? This error generates a mini dump but the call stack isn't going back far enough to find out what made the engine calls. I can't debug it any further than simply seeing this message on the screen and identifying a pattern. I still have no idea what user message it is this is. Any help would be appreciated. Thanks, Cale ___ 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] Avatar On Scoreboard No Longer Working
Scratch or Multiplayer? On Tue, Jun 10, 2008 at 10:31 PM, Olly [EMAIL PROTECTED] wrote: We are using the OB sdk, and SteamFriends()-GetFriendAvatar() to get the avatar 2008/6/11 Cale Dunlap [EMAIL PROTECTED]: What sdk are you using? Are you using some other method to get the avatars for the players? -Original Message- From: Olly [EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 8:46 PM To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Avatar On Scoreboard No Longer Working Still working for me :o 2008/6/10 Ben 'amogan' K. [EMAIL PROTECTED]: Yes I can confirm that they've stopped working, in valkyrie as well. :P Noticed it when I was modifying the scoreboard two days ago. :S -Ben - Original Message - From: Tony omega Sergi [EMAIL PROTECTED] Yeah, the api was changed. I don't think theywork in valkyrie anymore either, but I haven't really loaded it up to see, lol On Tue, Jun 10, 2008 at 6:39 AM, Cale Dunlap [EMAIL PROTECTED] wrote: Hello all, I had the avatar features working on our scoreboard at one point. Then they suddenly stopped working a few months ago. I put a breakpoint in when it calls UpdatePlayerAvatar() then stepped into the code. The first line if that function is: if ( kv ShowAvatars() SteamFriends() SteamUtils() ) What I'm finding is that: kv != NULL, good ShowAvatars() is true, good SteamFriends() unable to find symbol, not good SteamUtils() unable to find symbol, not good SteamFriends() and SteamUtils() are hooks into the steam API. Could this be broken by a version mismatch? If so, is there any way to get this working again? Any help would be appreciated. Thanks, Cale ___ 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 [The entire original message is not included] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Avatar On Scoreboard No Longer Working
Hello all, I had the avatar features working on our scoreboard at one point. Then they suddenly stopped working a few months ago. I put a breakpoint in when it calls UpdatePlayerAvatar() then stepped into the code. The first line if that function is: if ( kv ShowAvatars() SteamFriends() SteamUtils() ) What I'm finding is that: kv != NULL, good ShowAvatars() is true, good SteamFriends() unable to find symbol, not good SteamUtils() unable to find symbol, not good SteamFriends() and SteamUtils() are hooks into the steam API. Could this be broken by a version mismatch? If so, is there any way to get this working again? Any help would be appreciated. Thanks, Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Avatar On Scoreboard No Longer Working
What sdk are you using? Are you using some other method to get the avatars for the players? -Original Message- From: Olly [EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 8:46 PM To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Avatar On Scoreboard No Longer Working Still working for me :o 2008/6/10 Ben 'amogan' K. [EMAIL PROTECTED]: Yes I can confirm that they've stopped working, in valkyrie as well. :P Noticed it when I was modifying the scoreboard two days ago. :S -Ben - Original Message - From: Tony omega Sergi [EMAIL PROTECTED] Yeah, the api was changed. I don't think theywork in valkyrie anymore either, but I haven't really loaded it up to see, lol On Tue, Jun 10, 2008 at 6:39 AM, Cale Dunlap [EMAIL PROTECTED] wrote: Hello all, I had the avatar features working on our scoreboard at one point. Then they suddenly stopped working a few months ago. I put a breakpoint in when it calls UpdatePlayerAvatar() then stepped into the code. The first line if that function is: if ( kv ShowAvatars() SteamFriends() SteamUtils() ) What I'm finding is that: kv != NULL, good ShowAvatars() is true, good SteamFriends() unable to find symbol, not good SteamUtils() unable to find symbol, not good SteamFriends() and SteamUtils() are hooks into the steam API. Could this be broken by a version mismatch? If so, is there any way to get this working again? Any help would be appreciated. Thanks, Cale ___ 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 [The entire original message is not included] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] OB Shader SDK?
Very well. Thanks for the info. I will try to wait it out then. -Original Message- From: Matt Stafford [EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:24 AM To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] OB Shader SDK? You'll have an annoying time trying to get shaders working in OB. It involves screwing around with the paths in the Perl scripts and Batch Files, and half the time the stuff you're doing probably won't even work. HOPEFULLY it will be coming in the next SDK update, coz alot of us have been waiting for it On Tue, Jun 3, 2008 at 4:53 PM, Ryan Sheffer [EMAIL PROTECTED] wrote: No word yet I'm afraid. I think a lot of people are waiting for the same thing. On Mon, Jun 2, 2008 at 6:13 PM, Cale Dunlap [EMAIL PROTECTED] wrote: Hello all. Don't shoot me if this has already been answered, but I couldn't find an answer for it so here it goes: What's the word on a shader SDK for the orange box? Was it part of a recent update and I just missed it? Or does one not exist yet? If there isn't one available, is there any workaround to creating custom shaders? Or at least port any custom shaders from the EP1 engine to the OB engine? Thanks in advance. Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~Ryan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Matt Stafford (Wraiyth) http://www.wraiyth.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
[hlcoders] OB Shader SDK?
Hello all. Don't shoot me if this has already been answered, but I couldn't find an answer for it so here it goes: What's the word on a shader SDK for the orange box? Was it part of a recent update and I just missed it? Or does one not exist yet? If there isn't one available, is there any workaround to creating custom shaders? Or at least port any custom shaders from the EP1 engine to the OB engine? Thanks in advance. Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Second View Model?
Hello All, It's time for a stumper I've got a case where I need to have the player hold two weapons--each weapon animating independently. Our animations get pretty complex, so instead of trying to make our animator create a bunch of combinations of animations for the left and the right hand, I'm wondering if it is possible to create a second view model and how I'd go about doing it if it is. The reason for the second view model would be so that I can send activities to a single side (left hand or right hand) at a time. That way our animator only has to animate a single set of animations on a single side, then just duplicate it on the other side. I hope I'm being clear, if not, I'll answer any questions to clear up confusion. If creating a second view model isn't possible, does anybody have any other suggestions on how I can achieve this? Animation blending perhaps? QC magic? Thanks in advance! -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] G15 Keyboard Support
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] Has anybody gotten the G15 keyboard support stuff to work yet? I saw the source for it in the SDK, but apparently it needs the g15.dll. Does anybody know if that is a Valve DLL or if it is just the SDK DLL for the G15 keyboards? If it is a Valve DLL, will be in the “Everything SDK” project for VS? Thanks. Cale No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.9/1294 - Release Date: 2/22/2008 6:39 PM -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Compiling Shaders with Orange Box
-- [ Picked text/plain from multipart/alternative ] So, since the Orange Box uses a new shader format... is there any documentation anywhere about it yet? The old SDK had the sdkshaders directory, but I can't seem to find it in the Orange Box SDK. Is it not going to be there at all, or is it just omitted from this beta SDK version? I have to start porting the old shaders to the new version. Any help would be appreciated. Thanks. Cale -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Compiling Shaders with Orange Box
-- [ Picked text/plain from multipart/alternative ] *sadface* Alright. Thanks for the info. On Sat, Feb 23, 2008 at 2:30 AM, Tobias Kammersgaard [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The SDK shaders was left out of the beta SDK on purpose. Mike said they'll be added later :-) /ProZak On 23/02/2008, Cale Dunlap [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] So, since the Orange Box uses a new shader format... is there any documentation anywhere about it yet? The old SDK had the sdkshaders directory, but I can't seem to find it in the Orange Box SDK. Is it not going to be there at all, or is it just omitted from this beta SDK version? I have to start porting the old shaders to the new version. Any help would be appreciated. Thanks. Cale -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Orange Box Scoreboard
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] Has anybody had any trouble getting the scoreboard working for the Orange Box SDK? I can't get it to display a player list even though the list object itself is populating. Are there some sort of animation vars or font definitions I'm missing that were added/changed in the new version? I couldn't find any comparing to a scratch SDK. Also, I can't seem to check a vanilla install of the scratch SDK during runtime. I'm getting Could not load library client right out of the box after doing Create a mod. Any help would be appreciated. -Cale No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 5:50 AM -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] When is OB SDK coming out of beta? Also, difficultly in merging code?
Well, I had my fair share of issues, but as omega said to me... they were mostly bad ports. A lot of my problems were related to overriding base-classes like the player and such. If you've done any of that, make sure that your overridden functions include any additional function calls that were previously not in the Scratch SDK but are in the Orange Box SDK. It is probably best to start with a scratch orange box SDK project, then move your old code into it, not move the new code into the old project. Also you'll have to recompile your shaders and the shader DLLs themselves. Hope that helps. Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dave daveslastname Sent: Wednesday, February 13, 2008 9:51 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] When is OB SDK coming out of beta? Also, difficultly in merging code? -- [ Picked text/plain from multipart/alternative ] I have two questions for the more experienced: First, when is the OB / EP2 codebase coming out of it's beta status? We're going to be porting our mod's source code to the new engine, but don't want to do so until it's out of this experimental stage. Second, for those of you have done it or are currently doing it, how hard is it to merge EP1 code (we're using the scratch SDK) into the EP2 engine? How long will it take and what obstacles can we be expected to run into? Thanks in advance! -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] When is OB SDK coming out of beta? Also, difficultly in merging code?
That is a useful find Nick. Thanks for sharing that with everyone. Another one that is pretty good is Beyond Compare (http://www.scootersoftware.com/). It isn't free but the program is pretty good for code merges. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Wednesday, February 13, 2008 11:30 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] When is OB SDK coming out of beta? Also, difficultly in merging code? For merging new code I found the easiest way is http://kdiff3.sourceforge.net/ make sure you have the vanilla copy of your previous codebase (ep1 scratch sdk) add your modified codebase (ep1 scratch sdk) then set the new codebase ep2 scratch sdk takes a day or so though to work out manual merges, mostly smooth last time I did it though. On Feb 13, 2008 9:16 PM, Dylan [EMAIL PROTECTED] wrote: On a related note I have a couple of questions. Is there going to be a beta sdk update alongside the big TF2 update? If so may we see a changelog? -- From: dave daveslastname [EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 8:51 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] When is OB SDK coming out of beta? Also, difficultly in merging code? -- [ Picked text/plain from multipart/alternative ] I have two questions for the more experienced: First, when is the OB / EP2 codebase coming out of it's beta status? We're going to be porting our mod's source code to the new engine, but don't want to do so until it's out of this experimental stage. Second, for those of you have done it or are currently doing it, how hard is it to merge EP1 code (we're using the scratch SDK) into the EP2 engine? How long will it take and what obstacles can we be expected to run into? Thanks in advance! -- ___ 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008 9:41 AM ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Player not clipping against physprops
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] With the beta OBSDK has anybody experienced the player not clipping against physics props such as barrels and crates? My player just runs straight through barrels and crates. I’m sure it is probably a simple fix, but I don’t understand the player collision code well enough to even start to debug it. Any suggestions? Thanks in advance. -Cale No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.0/1268 - Release Date: 2/9/2008 11:54 AM -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Weapon Prediction Problems?
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] Alright, I’m stumped. I can’t tell if this is a prediction problem, or of something else is going on. I’ve written about 35 or so new weapons and they ALL experience animation and effect glitches in a laggy environment (net_fakelag 100 is how I’ve been testing this). If I have a semi-auto weapon such as a pistol which is only allowed to fire every 0.2 seconds it can fire every single frame when there is any sort of lag introduced to the game. Obviously when I say “fire” I mean just play the effects, it doesn’t actually fire on the server-side. This happens on full auto as well, but isn’t so obvious to the player because it is masked by the real rate of fire. When I run the debugger, I discovered that the server and client time get out of sync, causing the m_flNextPrimaryAttack variable to become instantly stale on the client side. Here is the rundown of what is going on: 1. Client sends fire command, plays the effects 2. Client updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 3. Server acknowledges, fires the weapon 4. Server updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 5. Server sends client updated m_flNextPrimaryAttack time 6. Client corrects m_flNextPrimaryAttack which ends up BEHIND gpGlobals-curtime 7. Client sends fire command, plays effects 8. Client updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 9. Server denies command because it isn’t allowed to shoot on the server yet 10. Server sends client updated m_flNextPrimaryAttack time 11. Client corrects m_flNextPrimaryAttack again, ending up BEHIND gpGlobals-curtime again allowing it to shoot again Basically the server is sending the client an old m_flNextPrimaryAttack time near continuously. This would normally be OK, but the gpGlobals-curtime variables become out of sync. The server thinks it is 1263.6800 when the client has 1263.7500. This only happens when there is lag. To test to make sure it wasn’t my mod, I ran a vanilla setup of the scratch SDK and discovered that the weapons built into that SDK experience the same symptoms. I’m not sure if it is for the same reasons or not though, I didn’t run it through the debugger. I sure hope there is some easy way to fix this. Perhaps it is just a symptom of using fake lag? Maybe I should just set up a server in the same room, then shake the Ethernet cable violently until bits fall out of the cable, creating lag? (joke) Thanks in advance. Cale No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 1:50 PM -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Weapon Prediction Problems?
Thanks Mark. I will give that a try.
-Original Message-
From: Mark Chandler [EMAIL PROTECTED]
Sent: Sunday, February 03, 2008 8:20 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Weapon Prediction Problems?
http://list.valvesoftware.com/mailman/private/hlcoders/2007-September/022161
.html
Quote
I'm glad you brought this topic back up, and I've found the definite
fix. The original problem was that weapons would shoot too fast, but
I've been encountering a problem where weapon animations are just plain
glitchy when not at a sub 50 ping. Both of these problems are only
evident in the base SDK and not the HL2 DM SDK. Your moving the
m_flNextPrimaryAttack variable into the player is an interesting hint at
the real source of the problem, but the problem is not due to anything
about how networked data is updated or received. The problem is that no
weapons are being predicted!
If you put cl_predictionlist in the console, it will print a list of
all entities in the world that are being predicted. If you run in HL2
DM, the list is something along the lines of player, view model, and
player weapons. However, if you look at the list in a base SDK mod,
only the player and view model are listed. That's because your weapons
aren't being predicted. The reason they're not predicted is because
CWeaponSDKBase does not override C_BaseEntity's ShouldPredict() function
to tell the game to predict the weapons. In the HL2 DM sdk, the weapons
are derived from CWeaponHL2MPBase which overrides ShouldPredict() and
returning true if the local player is the one holding the weapon.
How to fix this bug:
In weapon_sdkbase.h, add:
#ifdef CLIENT_DLL
virtual bool ShouldPredict();
#endif
In weapon_sdkbase.cpp, add:
#ifdef CLIENT_DLL
bool CWeaponSDKBase::ShouldPredict()
{
if ( GetOwner() GetOwner() == C_BasePlayer::GetLocalPlayer())
return true;
return BaseClass::ShouldPredict();
}
#endif
Credit Goes to Justin Krenz
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo
'r2d2rigo' Diaz
Sent: Sunday, February 03, 2008 8:37 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Weapon Prediction Pro
[The entire original message is not included]
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] SteamWorks we should get a piece of that pie ;)
I see all of the news sites saying it is free, but I can't find anything official from Valve saying so. *nudges valve* eh? Eh? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Leighton Sent: Tuesday, January 29, 2008 11:57 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] SteamWorks we should get a piece of that pie ;) I think thats wrong, anyone else think so? Brandon Dunham wrote: -- [ Picked text/plain from multipart/alternative ] :D Steam works appears to be free. http://www.next-gen.biz/index.php?option=com_contenttask=viewid=8880Itemi d=2 From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] SteamWorks we should get a piece of that pie ;) Date: Wed, 30 Jan 2008 04:07:31 + Yeah, my idea being that VALVe dont store anything on their servers, its all third party on the mod dev's servers, etc. Maybe we will get suprised with something? :P who knows Brandon Dunham wrote: -- [ Picked text/plain from multipart/alternative ] This would be a swell idea. If only, if only. =/ From: [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] SteamWorks we should get a piece of that pie ;) Date: Wed, 30 Jan 2008 00:31:23 + Could VALVe not implement an api where that a mod ID if you will is registered with SteamWorks, (no need for anything fancy, maybe a guid style id, or simply a number), and then the mod developers can add Update URL (Update location, maybe some data files to tell what update is newer, etc) Stats URL (Stats location, used for achievements, etc) and stuff like that. It means valve dont store anything, we can have steam functionality, and maybe even an integrated steam download/installer? :P _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -- ___ 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 _ Need to know the score, the latest news, or you need your Hotmail®-get your fix. http://www.msnmobilefix.com/Default.aspx -- ___ 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.15/1249 - Release Date: 1/29/2008 9:51 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.15/1249 - Release Date: 1/29/2008 9:51 AM ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] OrangeBox SDK Port Problem
Ok, I think I made some progress on this. I can take the DLLs from my mod's directory, and copy them right into a fresh mod from the OBSDK and then run it. There are a few errors in the console that (to me) look like they could stop the client.dll from loading in certain circumstances (which I haven't determined yet): ---SNIP--- Type teleport_countdown_screen of meta class teleport_countdown_screen undefined! MetaClass missing for teleport_countdown_screen ---/SNIP--- There are others regarding missing game events and usermessages as well. I've fixed the events and usermessages but this one stumps me. teleport_countdown_screen? I can't find it in the code anywhere, no references to it or anything. Oh, also there were some missing ConVars too (hud_saytext and spec_drawstatus). I have no idea what they are, but apparently something somewhere is using them. I basically just created a stub for them until I figure out what they are used for. So, what is this teleport_countdown_screen? -Mazor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Janes Sent: Sunday, January 27, 2008 8:32 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] OrangeBox SDK Port Problem Are your dlls being copied to your bin folder correctly? The first release had a broken solution in that respect. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cale Dunlap Sent: 27 January 2008 12:15 To: hlcoders@list.valvesoftware.com Subject: [hlcoders] OrangeBox SDK Port Problem -- [ Picked text/plain from multipart/alternative ] Its been a while since I've used this I hope everyone is as helpful as they were years ago :) I recently downloaded and began to port my existing mod code into the Orange Box Beta SDK. Now when the mod starts, I get Could not load library client. and quits. When I run this in debug mode, it breaks into the debugger and has the following in the call stack: engine.dll!20184ec7() [Frames below may be incorrect and/or missing, no symbols loaded for engine.dll] FileSystem_Steam.dll!CreateInterface() + 0x780b bytes FileSystem_Steam.dll!0d141e93() FileSystem_Steam.dll!0d135d7d() FileSystem_Steam.dll!0d135dc6() MaterialSystem.dll!CreateInterface() + 0xa571 bytes engine.dll!F() + 0xa0f31 bytes 0001() From what I'm guessing... it is attempting to create an interface into the client DLL and then failing. Can someone help me out by giving me some common causes of this? I know Could not load library client is a pretty vague message, but I hope the call stack helps. I've changed my SteamAppID to 420 (like the create-a-mod ScratchSDK's gameinfo.txt is). I've checked user messages and mod events too to make sure that I am catching all of mine. It almost seems as if it is a simple missing file or something. I've always hated tracking these down :( Perhaps someone can point me in the right direction. Thanks. -Mazor -- ___ 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.12/1245 - Release Date: 1/26/2008 3:45 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.12/1245 - Release Date: 1/26/2008 3:45 PM ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] OrangeBox SDK Port Problem
-- [ Picked text/plain from multipart/alternative ] Its been a while since I've used this I hope everyone is as helpful as they were years ago :) I recently downloaded and began to port my existing mod code into the Orange Box Beta SDK. Now when the mod starts, I get Could not load library client. and quits. When I run this in debug mode, it breaks into the debugger and has the following in the call stack: engine.dll!20184ec7() [Frames below may be incorrect and/or missing, no symbols loaded for engine.dll] FileSystem_Steam.dll!CreateInterface() + 0x780b bytes FileSystem_Steam.dll!0d141e93() FileSystem_Steam.dll!0d135d7d() FileSystem_Steam.dll!0d135dc6() MaterialSystem.dll!CreateInterface() + 0xa571 bytes engine.dll!F() + 0xa0f31 bytes 0001() From what I'm guessing... it is attempting to create an interface into the client DLL and then failing. Can someone help me out by giving me some common causes of this? I know Could not load library client is a pretty vague message, but I hope the call stack helps. I've changed my SteamAppID to 420 (like the create-a-mod ScratchSDK's gameinfo.txt is). I've checked user messages and mod events too to make sure that I am catching all of mine. It almost seems as if it is a simple missing file or something. I've always hated tracking these down :( Perhaps someone can point me in the right direction. Thanks. -Mazor -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: OrangeBox SDK Port Problem
yes, they are being copied correctly. the modified timestamps are changing on each dll to the time the build was completed. On 1/27/08, Chris Janes [EMAIL PROTECTED] wrote: Are your dlls being copied to your bin folder correctly? The first release had a broken solution in that respect. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cale Dunlap Sent: 27 January 2008 12:15 To: hlcoders@list.valvesoftware.com Subject: [hlcoders] OrangeBox SDK Port Problem -- [ Picked text/plain from multipart/alternative ] Its been a while since I've used this I hope everyone is as helpful as they were years ago :) I recently downloaded and began to port my existing mod code into the Orange Box Beta SDK. Now when the mod starts, I get Could not load library client. and quits. When I run this in debug mode, it breaks into the debugger and has the following in the call stack: engine.dll!20184ec7() [Frames below may be incorrect and/or missing, no symbols loaded for engine.dll] FileSystem_Steam.dll!CreateInterface() + 0x780b bytes FileSystem_Steam.dll!0d141e93() FileSystem_Steam.dll!0d135d7d() FileSystem_Steam.dll!0d135dc6() MaterialSystem.dll!CreateInterface() + 0xa571 bytes engine.dll!F() + 0xa0f31 bytes 0001() From what I'm guessing... it is attempting to create an interface into the client DLL and then failing. Can someone help me out by giving me some common causes of this? I know Could not load library client is a pretty vague message, but I hope the call stack helps. I've changed my SteamAppID to 420 (like the create-a-mod ScratchSDK's gameinfo.txt is). I've checked user messages and mod events too to make sure that I am catching all of mine. It almost seems as if it is a simple missing file or something. I've always hated tracking these down :( Perhaps someone can point me in the right direction. Thanks. -Mazor -- ___ 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] Debug crash
have you tried breaking when you see the first assert == NULL message? then step through the code until it crashes? On 1/27/08, Emiel Regis [EMAIL PROTECTED] wrote: Yes, I figured that out also :p It happens just after the server.dll is called, and after the first Assert == NULL thingy... However, the hl2.exe wasn't changed so I don't know what exactly fucks it up, only in debug... On Sun, 27 Jan 2008 21:22:04 +0100, Adam Maras (memzero) [EMAIL PROTECTED] wrote: Looks like the engine is trying to call a null function pointer somewhere. You'll have to get Valve's help on this one! // Adam Maras (memzero) Emiel Regis wrote: Hi, I'm using the non-beta version of SDK and Source SDK Base as engine. I noticed this debug crash a while ago, reinstalled steam, reverted my code, lately also reinstalled Visual Studio - it's still there. ReleaseHL2MP works fine. Here is the last call stack: () engine.dll!20188584() [Frames below may be incorrect and/or missing, no symbols loaded for engine.dll] engine.dll!201ed84b() engine.dll!20188997() engine.dll!201ed8e5() engine.dll!20188a2e() engine.dll!20188aec() launcher.dll!100083e1() launcher.dll!100083e1() launcher.dll!10005cf2() Next, 'unhandled exception' and crash. Can somebody help me? Cheers, Emiel Regis -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ 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 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] VGUI2 Positioning with Resource Files
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Are the numbers defining the xpos and ypos dependant on the clients resolution or are they scaled so they look similar/same at runtime? Remember how in HL1SDK there were macros called XRES and YRES? I found them in the SSDK but Im wondering if the numbers from the scheme files get processed through these macros also. Im using a combination of resource files and hardcode for a team menu. This question was probably already asked, but I havent found it yet. -Cale -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005 -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Re: Hey Eric
Those are Valve assimilated mods, not third party ones. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Imperio59 Sent: Friday, July 02, 2004 11:12 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Re: Hey Eric This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] DOD 1.2 has been released through steams, and CS updates are also being released through steam, so it's already being done :) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] UserMsg 57..... ?
When it happens in FA its completely random, it does not discriminate between teams and such, and no its not always 50% of the players, sometimes only 3 to 5 on a 28 player server will drop, sometimes 20 will drop. They all drop at the same time too. -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey botman Broome Sent: Wednesday, May 26, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] UserMsg 57. ? Ben Banfield wrote: Sorry for the double post but I've come off like I'm flaming people and valve. Thats not what I've been trying to do. I'm simply a bit exasperated and am just looking for more information to hunt this down or for this bug to not cause half the clients on the server to quit. Hmmm, that might be useful (half the clients on the server quit). Does this happen to several clients at the same time? I know it's probably hard to tell, but do people on the server see 50% of the players suddenly go away? If so, then that might help to track it down. If it's a teamplay MOD are all of those players on the same team? Adding some stats tracking debug code to the server could help to identify when this happens. Perhaps you can log (in memory) what's currently happening for each player (in a circular buffer in memory) and when you see a large number of players suddenly disappear from the server, dump this log of data to a text file. Then you can go back and look at what network messages had been recently sent or what type of activity was occuring when a large number of players suddenly disappeared. P.S. I don't think it sounded like you were flaming anyone. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] UserMsg 57..... ?
I'd check for messages being sent a LOT at the same time (Think functions especially). It seems as though this '57' deal had something do with overflows. I was doing checks and junk in the Think function of our game rules for when a server changed a cvar (allow_spectators, mp_specteam, etc) and found that if I just moved those to the InitHUD function it stops (or at least lessens) the players from being dropped. It has its downsides though, because now for everybody to get the new cvar value the server has to either be restarted or every player has to reconnect (since its in the InitHUD function). -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Banfield Sent: Tuesday, May 25, 2004 6:08 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] UserMsg 57. ? Its not just FA and NS that have had this. My mod, BG has had it (and still does) and i remember Kuja saying DPB had it too. Is it possible this is a steam or sdk bug as the chance of 4 wildly different mods causing the same error are extremely low imho. If we we're mismatching wouldn't we be having different usermsg number's each time ( or am I misunderstanding something here ). I'd love to see a resolution to this as well. Thanks Ben Cale Dunlap wrote: Oh. Crap. Ok, I'll check out all the messages and make sure they're parsed correctly. Thanks Alfred! -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: Monday, May 24, 2004 12:43 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] UserMsg 57. ? There is no usermsg 57, the engine defined ones stop at 56 (and mod created ones start at 64). Sounds like you are corrupting your network steam (by mismatching what the server sends and how the client parses it typically). - Alfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cale Dunlap Sent: Sunday, May 23, 2004 5:26 PM To: [EMAIL PROTECTED] Subject: [hlcoders] UserMsg 57. ? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] What is UserMsg #57. I've determined it to be within the engine.. Its causing crashes in FA right now and I'm having a difficult time figuring out why. If I can find out what the message contains I can probably figure out where its being sent from. The error steam has been giving is UserMsg 57 not present on client. Valve guys help out pzl? *puppy dog face* -Cale ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Another SZ_GetSpace overflow....
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] What does this mean: SZ_GetSpace: overflow without FSB_ALLOWOVERFLOW set on Server Spectator I'm totally confused. :-( -Cale -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] UserMsg 57..... ?
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] What is UserMsg #57. I've determined it to be within the engine.. Its causing crashes in FA right now and I'm having a difficult time figuring out why. If I can find out what the message contains I can probably figure out where its being sent from. The error steam has been giving is UserMsg 57 not present on client. Valve guys help out pzl? *puppy dog face* -Cale -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Another SZ_GetSpace overflow....
It looks like the issue lied in an un-precached file which was knocking clients off when it needed to be played. Its all fixed now. From: tei [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Another SZ_GetSpace overflow Date: Mon, 24 May 2004 00:33:04 +0200 Cale Dunlap wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] What does this mean: SZ_GetSpace: overflow without FSB_ALLOWOVERFLOW set on Server Spectator I'm totally confused. :-( -Cale -- I am newbie but... a memory allocation fatal error has occur in Server Spectator maybe you are sending more data than what the netcode buffer allocate (maybe the netcode buffer is fixed-size, but able growns(realloc's) with FSB_ALLOWOVERFLOW) try to use the smaller packet size posible to avoid evil routers fragmentation :/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] :-)
Why is it always Alfred that gets the viruses? lol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Finol Sent: Wednesday, May 19, 2004 1:50 PM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] :-) Now that's funny. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tei Sent: Wednesday, May 19, 2004 8:15 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] :-) the virus come from here: (map) http://telejano.berlios.de/option/tomasz1.gif (city itself) http://www.nofrag.com/image.php?url=/screenshots/actualite/2003-09-01_ha lflife2_04.jpg I suggest to send our agent Gordon Freeman to this location AS FAST AS POSIBLE. Ryan Professional Victim Desgroseilliers wrote: The Polish Conspiracy strikes again! - Original Message - From: K. Mike Bradley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:45 AM Subject: RE: [hlcoders] :-) LOL ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCormack, Chris Sent: Wednesday, May 19, 2004 4:17 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] :-) get him tei GET HIM ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: 18 May 2004 21:35 To: [EMAIL PROTECTED] Subject: [hlcoders] :-) -- Looking forward for a response :P password for archive: 54213 -- [ AttachedFile.zip of type application/octet-stream deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. ___ 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] :-)
LMFAO! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Finol Sent: Wednesday, May 19, 2004 1:50 PM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] :-) Now that's funny. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tei Sent: Wednesday, May 19, 2004 8:15 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] :-) the virus come from here: (map) http://telejano.berlios.de/option/tomasz1.gif (city itself) http://www.nofrag.com/image.php?url=/screenshots/actualite/2003-09-01_ha lflife2_04.jpg I suggest to send our agent Gordon Freeman to this location AS FAST AS POSIBLE. Ryan Professional Victim Desgroseilliers wrote: The Polish Conspiracy strikes again! - Original Message - From: K. Mike Bradley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 9:45 AM Subject: RE: [hlcoders] :-) LOL ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCormack, Chris Sent: Wednesday, May 19, 2004 4:17 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] :-) get him tei GET HIM ! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: 18 May 2004 21:35 To: [EMAIL PROTECTED] Subject: [hlcoders] :-) -- Looking forward for a response :P password for archive: 54213 -- [ AttachedFile.zip of type application/octet-stream deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. ___ 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] Weeeeee! ;)))
What password is that?! :D -Cale :D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 05, 2004 3:38 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Wee! ;))) -- I don't bite, weah! pass: 40327 -- [ Text.zip of type application/octet-stream deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Bullet Penetration (why is this so damn hard?!)
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Maybe I'm making this overly complex, but I'm having serious trouble getting bullets to go through X number of walls at X width from X distance. There was an old system like this in Firearms, but for 2.8a, I reverted back to the original FireBulletsPlayer function from the SDK, since it works better with the client side on getting a proper end point. Is there anybody out there that knows a system that can be easily adapted to the FireBulletsPlayer function for wall penetration? I tried writing my own several times with no luck. -Cale 'Mazor' Dunlap Firearms Half-Life Programmer http://www.firearmsmod.com http://www.firearmsmod.com/ -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Bullet Penetration (why is this so damn hard?!)
Oh Christ lol, why didn't I think of that. Thanx. -Cale -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony omega Sergi Sent: Saturday, November 29, 2003 2:03 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] Bullet Penetration (why is this so damn hard?!) Look at the Gauss code, and adapt from there. -omega http://www.frontline2.com -Original Message- From: Cale Dunlap [mailto:[EMAIL PROTECTED] Sent: November 29, 2003 2:54 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Bullet Penetration (why is this so damn hard?!) This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Maybe I'm making this overly complex, but I'm having serious trouble getting bullets to go through X number of walls at X width from X distance. There was an old system like this in Firearms, but for 2.8a, I reverted back to the original FireBulletsPlayer function from the SDK, since it works better with the client side on getting a proper end point. Is there anybody out there that knows a system that can be easily adapted to the FireBulletsPlayer function for wall penetration? I tried writing my own several times with no luck. -Cale 'Mazor' Dunlap Firearms Half-Life Programmer http://www.firearmsmod.com http://www.firearmsmod.com/ -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] VAC
*does a dance and claps hands* OH GOODY! LA LA L V-A-C... LA LA LA V-A-C Cale 'Mazor' Firearms Programmer From: Eric Smith [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: [hlcoders] VAC Date: Mon, 2 Dec 2002 10:21:51 -0800 We're working on having additional mods take advantage of the VAC security modules. We'll release more information when we're ready. We don't have a date for this yet. Mods using the VAC security modules will *not* need to have Valve buy them out. -Eric -Original Message- From: Mazor [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 8:36 AM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] VAC My understanding was that valve needs to 'buy your mod out' for them to let you use the VAC technology. I remember asking Valve about it a while back about using it with Firearms. Too bad I have a horrible memory and can't remember what they said in reply, but I think it was somewhere along those same lines. -Cale 'Mazor' Firearms Programmer http://www.firearmsmod.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Gornall Sent: Monday, December 02, 2002 9:58 AM To: '[EMAIL PROTECTED]' Subject: [hlcoders] VAC What's the word on using this regarding us 'normal' mods? (feeling community pressure here...) thanks, Mark. www.planethalflife.com/vampire www.planethalflife.com/ios __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep?
Heh, I didn't know it was a vec... oops. I thought it was just a z value for a vector. I guess I'm off I was just thinking along the lines of anything times zero = zero -Mazor From: Persuter [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep? Date: Thu, 07 Nov 2002 22:06:11 -0500 ??? vec3_t view_ofs; // eye position How does pev-view_ofs = 0 work? Sounds suspiciously like you just set view_ofs to NULL. Anyway, the difference is three floating-point multiplications. Not a huge problem in a Think function. :) Persuter At 04:44 PM 11/7/2002 -0600, you wrote: HAHA *changes the line in the Firearms code to read: pev-view_ofs = 0; * THANK YOU! -Original Message- From: [EMAIL PROTECTED] [mailto:hlcoders-admin;list.valvesoftware.com] On Behalf Of Oskar 'Zoot' Lindgren Sent: Thursday, November 07, 2002 3:37 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Valve´s programmers need more sleep? This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi! I found a funny thing: pev-view_ofs = pev-view_ofs * 0.0; from trigger.cpp line 859 It can be done better... and you will get about 0.0008027% higher FPS, i have tested. / A bored Zoot -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] VGUI Menu Order Problems
It is sent before the chooseteam menu. I just don't want them displaying at the same time. -Mazor From: dJeyL [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [hlcoders] VGUI Menu Order Problems Date: Sat, 12 Oct 2002 02:11:01 +0200 just invert them i don't remember it exactly right now, but i had the same problem with a metamod plugin i wrote ; i just managed to send motd before chooseteam menu (or after ; just check) ok, i've just checked my sources : motd must be sent before chooseteam vgui menu hope it helps ! cheers, -- djeyl - Original Message - From: Mazor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 11, 2002 6:07 AM Subject: [hlcoders] VGUI Menu Order Problems This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I get a problem with the Team Menu and MOTD menu conflicting at client join time. If there's an MOTD present, the server sends the motd menu and the team menu at the same time (normal, it should be like that anyway), but one should be hidden at first (the team menu), but they're both displayed, the MOTD menu in front, team menu behind that. When you click the OK button for the MOTD menu, the team menu goes away, and your left with the MOTD menu still sitting there screaming HAHAHAHAHAHAH YOU CAN'T GET RID OF ME, then you click ok, and it goes away. Then you gotta bring the team menu back up to pick your team pain in the ass. -Mazor FA Programmer ___ 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 Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Water Surface Points?
I'm trying to make a water slash effect for my mod when a bullet traceline goes into a water entity. I'm having a world of trouble finding the entry point of the traceline. Any ideas? Someone said someone asked this before, but I was looking through the archives and was unable to find any reference to this problem. Please help, thanx. -Mazor http://nuke.shiftify.com/ Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Hunted gameplay?
I want to get a 'Hunted' gameplay type mode for my mod. I tried using a round based system thats heavily modified, but its just far too difficult for me to convert. Does anybody know of any tutorials or sites that could help with this? I just need two teams, one team being limited to one person who is the 'hunted'. When that player dies, a new 'hunted' is chosen, and that old 'hunted' person, switches to the other team, the 'hunters' where the rest of the players in the server are held. Any ideas? Tutorials? Sites? ANYTHING?! Thanx! -Mazor _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] HL1109 Prediction Problems?
Has anyone else been getting crashes when cl_lw is 1 in their mods ONLY with 1109? This has been happening to me, my debugger isn't telling me ANYTHING at all, the call stack has 3 calls in it, 2 to the engine, and for whatever reason, one to (), I'm not even sure what library thats being called from, but thats what it crashes on due to an access violation. This ONLY happens in HL1109, not with any previous version. Me and a couple other testers have also had this same problem, so its not our computers, unless its one bigass coincidence. Suggestions? BTW: Yes I have 3 custom weapons, all w/ client side prediction enabled on them. -Mazor [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] HL1109 Prediction Problems?
Could it have anything to do with Info string length exceeded messages popping up all the time in the console? I dunno... I'm shootin in the dark here. I know that has SOMETHING to do with player physics, and I know the physics are predicted (I'm pretty sure anyway). Anyone??? -Mazor From: Cale Dunlap [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [hlcoders] HL1109 Prediction Problems? Date: Fri, 26 Apr 2002 05:03:56 + That IS the previous thing, thats the first one there is in the call stack, the other 2 are !HW calls, I can't see what they do. So I'm completely clueless. I even went as far as removing ALL of my custom weapons from the game, and it still did it, with regular HL weapons. -Mazor From: James Mitchell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [hlcoders] HL1109 Prediction Problems? Date: Fri, 26 Apr 2002 14:04:36 +1000 Check the previous thing in the call stack, see what that is, because its probley something that contains a pointer to a function, that has nothing.. Because () is going to be the header, not a function unless it rewrites the PE in the memory -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Cale Dunlap Sent: Friday, 26 April 2002 1:57 PM To: [EMAIL PROTECTED] Subject: [hlcoders] HL1109 Prediction Problems? Has anyone else been getting crashes when cl_lw is 1 in their mods ONLY with 1109? This has been happening to me, my debugger isn't telling me ANYTHING at all, the call stack has 3 calls in it, 2 to the engine, and for whatever reason, one to (), I'm not even sure what library thats being called from, but thats what it crashes on due to an access violation. This ONLY happens in HL1109, not with any previous version. Me and a couple other testers have also had this same problem, so its not our computers, unless its one bigass coincidence. Suggestions? BTW: Yes I have 3 custom weapons, all w/ client side prediction enabled on them. -Mazor [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Multiplayer + OpenGL = sound problems...
I threw in a particle engine and a new set of gamerules, based off of the teamplay game rules in HL, an da VGUI HUD. I didn't manage to catch when it started happening. I know it happaned after the VGUI HUD, and before the particle engine. As far as code modifications between those times, they were very minute, adding weapons, etc, tweaking small things here and there, etc. From: Miguel Aleman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Multiplayer + OpenGL = sound problems... Date: Fri, 15 Mar 2002 06:07:31 -0600 Not really, considering you can still hear your own gunfire I doubt it could be the soundcard. What did you change in the code so far? - Original Message - From: Cale Dunlap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 14, 2002 10:49 PM Subject: [hlcoders] Multiplayer + OpenGL = sound problems... Anyone ever had this happen to them? I get into a multiplayer game of my mod, I'm in OpenGL mode... and I don't hear explosions, world sounds, or other people's gunfire. I only hear my own gunfire. It isn't just me that experienced this during testing. Anyone in OpenGL mode experienced this. I didn't really notice WHEN this started. I thought it had something to do with the MP3 player, but even after I took everything out, it didn't work. This ONLY happens in multiplayer... its confusing... any ideas? -Mazor Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ 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 Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -Me _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] certain sounds only in software mode...
-- [ Picked text/plain from multipart/alternative ] I have a problem with my explosion sounds, ammo pickup sounds, and other players' weapon sounds They will only play in software mode but this only happens when I'm in a multiplayer game They'll play in a normal single player game, but not multi Possible reasons could include: my new particle system or my mp3 player I've looked into the mp3 player one, and I dont think thats the case Any clue? Thanx! -Cale 'Mazor' Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee -MeGet more from the Web FREE MSN Explorer download : http://explorermsncom ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://listvalvesoftwarecom/mailman/listinfo/hlcoders
[hlcoders] New post, same subject as before, pictures work...
-- [ Picked text/plain from multipart/alternative ] Anyone know why this would happen to triAPI particles? http://mazorcekkentnet/particles1jpg http://mazorcekkentnet/particles2jpg The only difference in the screenshots is the gib that I threw into view The second it comes into view, the particles lose their render colors and alpha's When I walk out of the view of the gib, that stops happening, and it goes back to looking like particles1jpg Any ideas? -Cale 'Mazor' Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee -MeGet more from the Web FREE MSN Explorer download : http://explorermsncom ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://listvalvesoftwarecom/mailman/listinfo/hlcoders
Re: [hlcoders] New post, same subject as before, pictures work...
-- [ Picked text/plain from multipart/alternative ] I got it the particles weren't being rendered in the right order... they were being rendered in the HUD_DrawTriangles function, when I needed them to be rendered in the HUD_DrawTransparentTriangles function. Doesn't that have something to do with pre/post frame? -Cale 'Mazor' - Original Message - From: Patrick Phillips Sent: Sunday, March 03, 2002 9:54 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] New post, same subject as before, pictures work... I remember toying around with using sprite textures a while back. It's something like . . . if you don't get a sprite texture ptr but bind a texture anyways, it'll use the first index or something. From: Reedbeta [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [hlcoders] New post, same subject as before, pictures work... Date: Sun, 3 Mar 2002 12:15:10 -0800 (PST) It looks to me as if the sprite that is being drawn for the particles has changed from whatever sprite you're using to one of HL's lens flare sprites. You can see this at the edge of the particle stream in particles2.jpg. Perhaps the sprite indices are getting b0rked somehow, causing your particle code to render the wrong sprite? --- Cale Dunlap [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Anyone know why this would happen to triAPI particles? http://mazor.cekkent.net/particles1.jpg http://mazor.cekkent.net/particles2.jpg The only difference in the screenshots is the gib that I threw into view. The second it comes into view, the particles lose their render colors and alpha's. When I walk out of the view of the gib, that stops happening, and it goes back to looking like particles1.jpg . Any ideas? -Cale 'Mazor' Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee. -MeGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders __ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp; ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcodersGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] client side vectors... WTF?!
--
[ Picked text/plain from multipart/alternative ]
I'm not fully understanding how the hell someone can deal with 'float *' and treat
them as vectors, and get them to actually work I found a particle system tutorial,
written by TheTinySteini I wrote a new function that takes a parameter ('float
*origin'), and uses that in determining the origin of the particle When that function
gets called, the actual position ends up to be something like: -59237234, 1045868234,
0 and I can't figure out why The parameter it passes is pTrace-endpos, I used that
endpos vector when I used R_TempSprite's to do the smoke puffs of bullets, it worked
fine with that Now that I'm trying to use particles, the origin isn't passed right
any ideas?
-Cale 'Mazor'
Even in death, feelings carry on; love -- the ultimate power -- will stay within me,
as I will stay with thee
-MeGet more from the Web FREE MSN Explorer download : http://explorermsncom
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://listvalvesoftwarecom/mailman/listinfo/hlcoders
[hlcoders] Ignore my last one, read this one...
-- -- [ Picked text/plain from multipart/alternative ] Take a look at the attached images tell my this happens w/o any entities in view of the player, the particles render correctly, with correct color and alpha However when I throw a gib into view, the particles render all white and have a hard alpha channel any ideas why? -Cale 'Mazor' Even in death, feelings carry on; love -- the ultimate power -- will stay within me, as I will stay with thee -MeGet more from the Web FREE MSN Explorer download : http://explorermsncom -- -- [ particle2jpg of type image/jpeg deleted ] -- [ particle1jpg of type image/jpeg deleted ] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://listvalvesoftwarecom/mailman/listinfo/hlcoders
