[hlcoders] Re: hlcoders digest, Vol 1 #2534 - 5 msgs
Hey guys, I tried the mdmp file, and it gave me the same result as running through the release build in msdev debug. It says that it crashes on this line- glowoverlay.cpp(299)m_flGlowObstructionScale = min( m_flGlowObstructionScale, 1.0f ); Im beginning to think it has something to do with the first chance exception messages I get when I run it, here is the console print. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\hl2.exe', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\launcher.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vstdlib.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\tier0.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\FileSystem_Steam.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\Steam.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\mswsock.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\uxtheme.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\datamodel.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\parsifal.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\dmserializers.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\datacache.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\inputsystem.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\winmm.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\usbkt1x1.dll', No symbols loaded. 'hl2.exe': Unloaded 'C:\WINDOWS\system32\usbkt1x1.dll' 'hl2.exe': Loaded 'C:\WINDOWS\system32\usbkt1x1.dll', No symbols loaded. 'hl2.exe': Unloaded 'C:\WINDOWS\system32\usbkt1x1.dll' 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\MaterialSystem.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\StudioRender.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vphysics.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\valve_avi.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\avifil32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msacm32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msvfw32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vguimatsurface.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vgui2.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\engine.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\wininet.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\crypt32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msasn1.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\steam_api.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\shaderapidx9.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\d3d9.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\d3d8thk.dll', No symbols loaded. 'hl2.exe': Loaded
[hlcoders] help Re: hlcoders digest, Vol 1 #2534 - 5 msgs
Hey guys, I tried the mdmp file, and it gave me the same result as running through the release build in msdev debug. It says that it crashes on this line- glowoverlay.cpp(299)m_flGlowObstructionScale = min( m_flGlowObstructionScale, 1.0f ); Im beginning to think it has something to do with the first chance exception messages I get when I run it, here is the console print. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\hl2.exe', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\launcher.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vstdlib.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\tier0.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\FileSystem_Steam.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\Steam.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\mswsock.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\uxtheme.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\datamodel.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\parsifal.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\dmserializers.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\datacache.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\inputsystem.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\winmm.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\usbkt1x1.dll', No symbols loaded. 'hl2.exe': Unloaded 'C:\WINDOWS\system32\usbkt1x1.dll' 'hl2.exe': Loaded 'C:\WINDOWS\system32\usbkt1x1.dll', No symbols loaded. 'hl2.exe': Unloaded 'C:\WINDOWS\system32\usbkt1x1.dll' 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\MaterialSystem.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\StudioRender.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vphysics.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\valve_avi.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\avifil32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msacm32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msvfw32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vguimatsurface.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\vgui2.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\engine.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\wininet.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\crypt32.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\msasn1.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\steam_api.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\steam\SteamApps\pellethead\half-life 2 deathmatch\bin\shaderapidx9.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\d3d9.dll', No symbols loaded. 'hl2.exe': Loaded 'C:\WINDOWS\system32\d3d8thk.dll', No symbols loaded. 'hl2.exe': Loaded
[hlcoders] Server uses different classe tables
I'm having a strange problem with my mod's dedicated server rejecting clients on connection with the following message Server uses different classe tables (along with a Your .dll [bin\client.dll] differs from the server's. error message in the console). I have triple check the file versions on the server and my client, made sure I was using the same build, but it would still give me this error. What really baffles me is that I can connect no problem to a friend of mine running the same version of the mod on a listen server (that is, he's hosting the game and playing at the same time). I have tried updating the dedicate server software using the HLDSUpdateTool with the -command update -hl2mp but everything seems to already be up to date. Ive also noticed that it seems to happen as soon as we introduced new code using network tables. If we remove the network tables, or dont alter any existing one, the dedicated server will let client connects. If we remove an entry in one of the network tables (on both client and server side) the dedicated server will display the error message above. Any got some suggestions to fix this problem? Maybe a recent Source update has had a side effect on this? Thanks in advance, Spk ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Server uses different classe tables
-- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Server uses different classe tables
Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ 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] Server uses different classe tables
The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). It's weird that it's only happening on a dedicated server but I heard something from Krenzo (empires mod) a while back.. he was in the same situation except the class tables didn't match only when they tried to record demos. Weird. Is it just linux dedicated server or windows too? On 6/11/06, William Ravaine [EMAIL PROTECTED] wrote: Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ 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] Server uses different classe tables
The last srcds update was not backwards-compatible. Make sure you've updated or you will get this error. This isn't the first srcds update that has had this bug/feature - it happened a couple months back as well. At 2006/06/11 04:33 PM, Garry Newman wrote: The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). It's weird that it's only happening on a dedicated server but I heard something from Krenzo (empires mod) a while back.. he was in the same situation except the class tables didn't match only when they tried to record demos. Weird. Is it just linux dedicated server or windows too? On 6/11/06, William Ravaine [EMAIL PROTECTED] wrote: Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ 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] Server uses different classe tables
Thanks for the answer. The dedicated server is running on a WinXP system. I've never had this problem before, and the first time it happened was when I commented out one entry of an entity's network table, on both the server and client side: Client Side BEGIN_RECV_TABLE_NOBASE( C_NDBaseNetDataManager, DT_NDBaseNetDataMgr_SightData ) RecvPropFloat( RECVINFO( m_fSourceXpos ) ), RecvPropFloat( RECVINFO( m_fSourceYpos ) ), //RecvPropInt( RECVINFO( m_iSourceTeam ) ), END_RECV_TABLE() IMPLEMENT_CLIENTCLASS_DT(C_NDBaseNetDataManager, DT_NDBaseNetDataMgr, CNDBaseNetDataManager) ... // Only sent to teams that have sighted source entity RecvPropDataTable( basenetdata_sightdata, 0, 0, REFERENCE_RECV_TABLE(DT_NDBaseNetDataMgr_SightData) ), ... END_RECV_TABLE() Server Side // Sight Data - Only sent to teams that have sighted source entity BEGIN_SEND_TABLE_NOBASE( CNDBaseNetDataManager, DT_NDBaseNetDataMgr_SightData ) SendPropFloat( SENDINFO( m_fSourceXpos ), -1, SPROP_COORD ), SendPropFloat( SENDINFO( m_fSourceYpos ), -1, SPROP_COORD ), //SendPropInt( SENDINFO( m_iSourceTeam ), 4, SPROP_UNSIGNED ), END_SEND_TABLE() IMPLEMENT_SERVERCLASS_ST( CNDBaseNetDataManager, DT_NDBaseNetDataMgr ) ... // Only sent to teams that have sighted source entity SendPropDataTable( basenetdata_sightdata, 0, REFERENCE_SEND_TABLE(DT_NDBaseNetDataMgr_SightData), CNDBaseNetDataManager::SendProxy_SightData), ... END_SEND_TABLE() Using the code above, with the m_iSourceTeam entry commented out, I would get the server uses different class tables error on the dedicated server (listen server would run just fine). If I restore it like it was before by removing the comment, the server works again. Since I didnt know exactly what was causing this issue and why, Ive had to leave the m_iSourceTeam entry there even though I wanted to remove it. Later on, another coder on the team commited a weapon code update which was also using a network table (but totally unrelated to the one above though) and the error restarted happening on the dedicated server. I'm really not sure what's causing this, it doesnt make much sense to me right now. What puzzles me is that it's working fine on a listen/local server, but fails miserably on a dedicated server. Any more ideas/suggestions anyone? Could really use some help here :) Thanks in advance, Spk From: Garry Newman [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 22:33:07 +0100 The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). It's weird that it's only happening on a dedicated server but I heard something from Krenzo (empires mod) a while back.. he was in the same situation except the class tables didn't match only when they tried to record demos. Weird. Is it just linux dedicated server or windows too? On 6/11/06, William Ravaine [EMAIL PROTECTED] wrote: Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ 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] Server uses different classe tables
Yes that's what I suspected either - As I've explained in my first mail, I've update tried updating the dedicated server using the HLDSUpdateTool, but maybe I did that wrong? Here's the command line Im using: HldsUpdateTool.exe -command update -game hl2mp This is a mod based on the hl2mp code. When I ran it, it said everything was up to date already (which is suspicious since you've said there's been an update recently). Is it the wrong command or do I need to update something else? Maybe there's a new version of the updater too? From: [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 16:45:42 -0500 The last srcds update was not backwards-compatible. Make sure you've updated or you will get this error. This isn't the first srcds update that has had this bug/feature - it happened a couple months back as well. At 2006/06/11 04:33 PM, Garry Newman wrote: The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). It's weird that it's only happening on a dedicated server but I heard something from Krenzo (empires mod) a while back.. he was in the same situation except the class tables didn't match only when they tried to record demos. Weird. Is it just linux dedicated server or windows too? On 6/11/06, William Ravaine [EMAIL PROTECTED] wrote: Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Round 2: srcds on newer linuxes
I've updated the KI list with the code issues that prevent compiling on gcc 4: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Mod_fails_to_compile_with_gcc_4.x Unfortunately there are now run-time issues. The first big issue is that every time you respawn, your vision is stuck very close to the ground. This seems to be very similar to the long-standing #15 Deeper Underground HL2DM bug as listed on the http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 HL2DM bug list page, however it occurs every time. Crouching and uncrouching fixes the issue. Has anyone else seen this? I may try reverting to gcc3.x... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Server uses different classe tables
The last steam update that broke compatibility was mid last week I believe. At 2006/06/11 04:53 PM, William Ravaine wrote: Yes that's what I suspected either - As I've explained in my first mail, I've update tried updating the dedicated server using the HLDSUpdateTool, but maybe I did that wrong? Here's the command line Im using: HldsUpdateTool.exe -command update -game hl2mp This is a mod based on the hl2mp code. When I ran it, it said everything was up to date already (which is suspicious since you've said there's been an update recently). Is it the wrong command or do I need to update something else? Maybe there's a new version of the updater too? From: [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 16:45:42 -0500 The last srcds update was not backwards-compatible. Make sure you've updated or you will get this error. This isn't the first srcds update that has had this bug/feature - it happened a couple months back as well. At 2006/06/11 04:33 PM, Garry Newman wrote: The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). It's weird that it's only happening on a dedicated server but I heard something from Krenzo (empires mod) a while back.. he was in the same situation except the class tables didn't match only when they tried to record demos. Weird. Is it just linux dedicated server or windows too? On 6/11/06, William Ravaine [EMAIL PROTECTED] wrote: Yes that's the first thing Ive done. We also use SVN to keep our version in sync, but just to be sure Ive uploaded a zip file holding the server client dll from my computer directly to our remote server, so the server client dlls are definately the same on both ends of the wire. I wished it would have been so simple a fix though :) Any ideas? Im looking for more detailed information on what's causing this error to happen while the DLLs are definately identical on both sides. From: Aaron Schiff [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 15:21:05 -0500 -- [ Picked text/plain from multipart/alternative ] The problem isn't between the client.dll and server.dll It's a difference between the client.dll on the dedicated server and the client.dll in your SourceMods Just overwrite the dedicated server's client.dll with your SourceMods one -- ts2do -- ___ 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] Server uses different classe tables
I really wish they'd fix the tools as well, it's been almost 2 weeks now and the tools still don't work properly. Steam is great because you can release updates and whatnot.. but come on, breaking everything in the process??!?? -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: June 11, 2006 6:01 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables The last steam update that broke compatibility was mid last week I believe. At 2006/06/11 04:53 PM, William Ravaine wrote: Yes that's what I suspected either - As I've explained in my first mail, I've update tried updating the dedicated server using the HLDSUpdateTool, but maybe I did that wrong? Here's the command line Im using: HldsUpdateTool.exe -command update -game hl2mp This is a mod based on the hl2mp code. When I ran it, it said everything was up to date already (which is suspicious since you've said there's been an update recently). Is it the wrong command or do I need to update something else? Maybe there's a new version of the updater too? From: [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 16:45:42 -0500 The last srcds update was not backwards-compatible. Make sure you've updated or you will get this error. This isn't the first srcds update that has had this bug/feature - it happened a couple months back as well. At 2006/06/11 04:33 PM, Garry Newman wrote: The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Cvar revert crashes
--
[ Picked text/plain from multipart/alternative ]
I've got a weird problem here...
void test_Callback_f( ConVar *var, char const *pOldString )
{
var-Revert();
}
ConVar test( test, , 0, test, test_Callback_f );
The following code makes hl2.exe immediately shutdown (HL2 has never closed
so fast!) when it reverts the convar.
Greetings,
Robbie
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Server uses different classe tables
The breaking of class tables compatibility may have been unavoidable for whatever reason - but a notice would be helpful. At 2006/06/11 05:15 PM, you wrote: I really wish they'd fix the tools as well, it's been almost 2 weeks now and the tools still don't work properly. Steam is great because you can release updates and whatnot.. but come on, breaking everything in the process??!?? -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: June 11, 2006 6:01 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables The last steam update that broke compatibility was mid last week I believe. At 2006/06/11 04:53 PM, William Ravaine wrote: Yes that's what I suspected either - As I've explained in my first mail, I've update tried updating the dedicated server using the HLDSUpdateTool, but maybe I did that wrong? Here's the command line Im using: HldsUpdateTool.exe -command update -game hl2mp This is a mod based on the hl2mp code. When I ran it, it said everything was up to date already (which is suspicious since you've said there's been an update recently). Is it the wrong command or do I need to update something else? Maybe there's a new version of the updater too? From: [EMAIL PROTECTED] Reply-To: hlcoders@list.valvesoftware.com To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Server uses different classe tables Date: Sun, 11 Jun 2006 16:45:42 -0500 The last srcds update was not backwards-compatible. Make sure you've updated or you will get this error. This isn't the first srcds update that has had this bug/feature - it happened a couple months back as well. At 2006/06/11 04:33 PM, Garry Newman wrote: The different class tables doesn't nessisarily mean that the dlls weren't compiled at the same time.. you could have just messed up the send/recv tables. It usually happens when the server is trying to send something and the client doesn't have a variable ready for it.. (their tables don't match). ___ 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] Cvar revert crashes
Just a guess since I'm not in front of the code right now, but are you
sure it isn't recursing here? (i.e. Revert() calls your callback until
the stack gets blown)
Jay
[ Picked text/plain from multipart/alternative ] I've got a
weird problem here...
void test_Callback_f( ConVar *var, char const *pOldString ) {
var-Revert();
}
ConVar test( test, , 0, test, test_Callback_f );
The following code makes hl2.exe immediately shutdown (HL2
has never closed so fast!) when it reverts the convar.
Greetings,
Robbie
--
___
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] Cvar revert crashes
-- [ Picked text/plain from multipart/alternative ] Looking at what Revert calls...that seems to be the correct diagnosis Try if(!Q_strnicmp(var-GetString(),var-GetDefault())) before calling var-Revert() -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Round 2: srcds on newer linuxes
I've updated http://developer.valvesoftware.com/wiki/Compiling_under_Linux to mention that gcc 4.x will not work. However this behavior is surprising as I've extensively used cross-gcc version libraries before, due to the need to interface with third party products on old OSes. Generally you should be able to load a library with a new gcc as long as both libraries link to the correct runtimes dynamically. For instance http://gcc.gnu.org/onlinedocs/libstdc++/abi.html#ABI_multi_testing contains an example of essentially the exact scenario that I attempted, and it should work. My current suspicion is that gcc 4 is generating code that is invalid, possibly due to a gcc bug, or possibly due to the code containing undefined behavior, which gcc 4 interprets differently than gcc 3 did. Unfortunately due to the necessity low warning levels it's hard to say which it might be. In any case I've reverted to gcc 3.4.4 and both issues have gone away. At 2006/06/11 06:17 PM, Alfred Reynolds wrote: The C++ ABI implemented in GCC 4.x differs significantly from 3.x, I am amazed the binary even loads. You will need to use the 3.x series of GCC to compile your mod. - Alfred [EMAIL PROTECTED] wrote: I've updated the KI list with the code issues that prevent compiling on gcc 4: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Mod_fails_ to_compile_with_gcc_4.x Unfortunately there are now run-time issues. The first big issue is that every time you respawn, your vision is stuck very close to the ground. This seems to be very similar to the long-standing #15 Deeper Underground HL2DM bug as listed on the http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 HL2DM bug list page, however it occurs every time. Crouching and uncrouching fixes the issue. Has anyone else seen this? I may try reverting to gcc3.x... ___ 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] Round 2: srcds on newer linuxes
Libraries under Linux make use of C bindings, their binary format is static and well defined. The Source engine makes use of C++ entities between its shared libraries (in particular pure virtual interfaces), the C++ ABI is NOT stable between GCC major versions. A quick google of this will give you plenty of details. - Alfred [EMAIL PROTECTED] wrote: I've updated http://developer.valvesoftware.com/wiki/Compiling_under_Linux to mention that gcc 4.x will not work. However this behavior is surprising as I've extensively used cross-gcc version libraries before, due to the need to interface with third party products on old OSes. Generally you should be able to load a library with a new gcc as long as both libraries link to the correct runtimes dynamically. For instance http://gcc.gnu.org/onlinedocs/libstdc++/abi.html#ABI_multi_testing contains an example of essentially the exact scenario that I attempted, and it should work. My current suspicion is that gcc 4 is generating code that is invalid, possibly due to a gcc bug, or possibly due to the code containing undefined behavior, which gcc 4 interprets differently than gcc 3 did. Unfortunately due to the necessity low warning levels it's hard to say which it might be. In any case I've reverted to gcc 3.4.4 and both issues have gone away. At 2006/06/11 06:17 PM, Alfred Reynolds wrote: The C++ ABI implemented in GCC 4.x differs significantly from 3.x, I am amazed the binary even loads. You will need to use the 3.x series of GCC to compile your mod. - Alfred [EMAIL PROTECTED] wrote: I've updated the KI list with the code issues that prevent compiling on gcc 4: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Mod_fails_ to_compile_with_gcc_4.x Unfortunately there are now run-time issues. The first big issue is that every time you respawn, your vision is stuck very close to the ground. This seems to be very similar to the long-standing #15 Deeper Underground HL2DM bug as listed on the http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 HL2DM bug list page, however it occurs every time. Crouching and uncrouching fixes the issue. Has anyone else seen this? I may try reverting to gcc3.x... ___ 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] How to Create a Model Attached to the Player using only code.
--
[ Picked text/plain from multipart/alternative ]
Thanks for the help, but I was wondering, is it possible to do this
clientside?
On 6/8/06, Michael Kramer [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ]
Alright, I have tested this and it works, Simply, in sdk_player.h (if you
did create mod from scratch) or hl2_player.h (if you did modify half-life
2)
or hl2mp_player.h (if you did modify half-life 2 Deathmatch) you need to
add
the following:
#define BOX_MODEL_NAME models/props/barrelLid.mdl
//
//
//
//
class CBox : public CBaseProp
{
public:
public:
DECLARE_CLASS( CBox, CBaseProp );
typedef CBaseProp BaseClass;
CBox();
//boolCreateVPhysics( void );
voidSpawn( void );
virtual void Precache();
DECLARE_DATADESC();
};
Then somewhere under class CSDKPlayer (or CHL2Player, or CHL2MPPlayer) add
CBox *pBox; // This makes it a global variable so you can call it in both
the InitialSpawn, and on death.
In sdk_player.cpp (or hl2_player.cpp or hl2mp_player.cpp) add the
following
somewhere near the top.
BEGIN_DATADESC( CBox )
END_DATADESC()
LINK_ENTITY_TO_CLASS( box, CBox );
void CBox::Precache()
{
SetModel( BOX_MODEL_NAME );
BaseClass::Precache();
}
CBox::CBox()
{
}
//-
// Purpose:
//-
void CBox::Spawn( void )
{
Precache();
SetModelName( MAKE_STRING( BOX_MODEL_NAME ) );
}
Then find the InitialSpawn() function and add the following:
pBox = CREATE_ENTITY( CBox, box );
Vector origin = GetAbsOrigin();
origin.z += 65; //Spawn above player, can be tweaked
pBox-SetAbsOrigin(origin);
pBox-SetAbsAngles(GetAbsAngles());
pBox-Spawn();
pBox-SetParent(this);
Then, goto the Event_Killed( const CTakeDamageInfo info )
and add UTIL_Remove(pBox);
That should be it, hope this helped.
--
___
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] Round 2: srcds on newer linuxes
Thanks for the tips! I'd forgotten that fact about the Source SDK, although I'd actually discovered it once before when trying to run efence on a mod in order to try to debug Physical Mayhem. Quite frankly I'm still baffled as to how it resulted in the behavior it did, but oh well I've got bigger fish to try. :) I've strengthened the messaging on: http://developer.valvesoftware.com/wiki/Compiling_under_Linux#Requirements At 2006/06/11 08:23 PM, Alfred Reynolds wrote: Libraries under Linux make use of C bindings, their binary format is static and well defined. The Source engine makes use of C++ entities between its shared libraries (in particular pure virtual interfaces), the C++ ABI is NOT stable between GCC major versions. A quick google of this will give you plenty of details. - Alfred [EMAIL PROTECTED] wrote: I've updated http://developer.valvesoftware.com/wiki/Compiling_under_Linux to mention that gcc 4.x will not work. However this behavior is surprising as I've extensively used cross-gcc version libraries before, due to the need to interface with third party products on old OSes. Generally you should be able to load a library with a new gcc as long as both libraries link to the correct runtimes dynamically. For instance http://gcc.gnu.org/onlinedocs/libstdc++/abi.html#ABI_multi_testing contains an example of essentially the exact scenario that I attempted, and it should work. My current suspicion is that gcc 4 is generating code that is invalid, possibly due to a gcc bug, or possibly due to the code containing undefined behavior, which gcc 4 interprets differently than gcc 3 did. Unfortunately due to the necessity low warning levels it's hard to say which it might be. In any case I've reverted to gcc 3.4.4 and both issues have gone away. At 2006/06/11 06:17 PM, Alfred Reynolds wrote: The C++ ABI implemented in GCC 4.x differs significantly from 3.x, I am amazed the binary even loads. You will need to use the 3.x series of GCC to compile your mod. - Alfred [EMAIL PROTECTED] wrote: I've updated the KI list with the code issues that prevent compiling on gcc 4: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Mod_fails_ to_compile_with_gcc_4.x Unfortunately there are now run-time issues. The first big issue is that every time you respawn, your vision is stuck very close to the ground. This seems to be very similar to the long-standing #15 Deeper Underground HL2DM bug as listed on the http://forums.steampowered.com/forums/showthread.php?s=threadid=248425 HL2DM bug list page, however it occurs every time. Crouching and uncrouching fixes the issue. Has anyone else seen this? I may try reverting to gcc3.x... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Map Scaling
Has anyone tried shrinking down all players and models to get larger sized maps? I know at least one mod has done it, but I can't remember which mod that was. I recently started to shrink down all things in my mod to get larger map sizes so that aircraft have more room to play in, and most of it doesn't seem to be hard. However, physics start to act strangely with the scale down. I don't know exactly why, but when I shrink the model down for my plane, it starts to become twitchy and won't stay exactly still. Then there's the issue of inertia. When I decrease engine speed to go along with the decreased scale, inertia starts to become a problem. After you turn the aircraft, it continues to go in the same direction it was going, and turning down the model's inertia doesn't seem to help until you below a certain point where it suddenly just starts spinning uncontrollably. To get to the point, has anyone successfully scaled physics objects down with satisfactory results, or is there a different method I could use to get larger map sizes without the scaling issues? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
-- [ Picked text/plain from multipart/alternative ] To get it to stop twitching, you'll probably have to network more angle bits... -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
On Sun, 2006-06-11 at 22:13 -0400, Justin Krenz wrote: Has anyone tried shrinking down all players and models to get larger sized maps? I know at least one mod has done it, but I can't remember which mod that was. http://www.youtube.com/watch?v=4-zA97BnOwo Physics seems fine to me. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
Justin, what kid of physics do you mean? Physics props interacting with the world, etc? Justin that looks pretty sweet btw - but let's see you hit an asteroid get some real physics going :D Quoting John Sheu [EMAIL PROTECTED]: On Sun, 2006-06-11 at 22:13 -0400, Justin Krenz wrote: Has anyone tried shrinking down all players and models to get larger sized maps? I know at least one mod has done it, but I can't remember which mod that was. http://www.youtube.com/watch?v=4-zA97BnOwo Physics seems fine to me. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
On Sun, 2006-06-11 at 20:59 -0700, Tim Holt wrote: Justin that looks pretty sweet btw - but let's see you hit an asteroid get some real physics going :D That's my project, BTW :-P And yeah, physics is in that, the whole nine yards. FYI that's at 1/40 scale. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Map Scaling
So is your ship an actual physics object and if so are you applying forces or modifying the velocity directly? What do you have as your drag coefficient and inertia values? John Sheu wrote: On Sun, 2006-06-11 at 20:59 -0700, Tim Holt wrote: Justin that looks pretty sweet btw - but let's see you hit an asteroid get some real physics going :D That's my project, BTW :-P And yeah, physics is in that, the whole nine yards. FYI that's at 1/40 scale. -John Sheu ___ 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
