[hlcoders] RE: Studio MDL Not Working
Hello guys,
It seems that I found a way to fix that StudioMDL problem by copying the
HL2DM bin\ folder content into the SourceSDK bin\ folder.
So, try it and let us know if that fixes anything for you.
Regards
--Thomas
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de
[EMAIL PROTECTED]
Envoyé : jeudi 1 juin 2006 06:20
À : hlcoders@list.valvesoftware.com
Objet : hlcoders digest, Vol 1 #2522 - 11 msgs
Send hlcoders mailing list submissions to
hlcoders@list.valvesoftware.com
To subscribe or unsubscribe via the World Wide Web, visit
http://list.valvesoftware.com/mailman/listinfo/hlcoders
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of hlcoders digest...
Today's Topics:
1. RE: collision issue (Jay Stelly)
2. Re: [Source] Thread-safety ? (Olef van de Stadt)
3. studiomdl.exe not working? (I I)
4. RE: studiomdl.exe not working? (Tony omega Sergi)
5. RE: collision issue (Tony omega Sergi)
6. Re: Homepage / Developer / Manual ([EMAIL PROTECTED])
7. Re: Error at engine.dll!0x0AF2 ([EMAIL PROTECTED])
8. Re: Homepage / Developer / Manual (Aaron Schiff)
9. Re: Homepage / Developer / Manual ([EMAIL PROTECTED])
10. Re: Error at engine.dll!0x0AF2 ([EMAIL PROTECTED])
11. Re: [Source] Thread-safety ? ([EMAIL PROTECTED])
--__--__--
Message: 1
Subject: RE: [hlcoders] collision issue
Date: Wed, 31 May 2006 11:33:33 -0700
From: Jay Stelly [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Reply-To: hlcoders@list.valvesoftware.com
Alright, I have a prop (model based) which has vphysics
collision, it has it's own collisiongroup. I have another
entity, a brush entity (like
func_door) that moves, and again, has it's own collisiongroup.
ShouldCollide has all the necessary checks and whatnot, but
when debugging, I've found that shouldcollide is never being
tested, yet the door collides with the prop, and gets
stopped; however, it's blocked function doesn't even get called!
It's not clear from your message whether you are expecting the objects
to collide or not. If not, then:
Which ShouldCollide()? The one in src/dlls/physics.cpp:
CCollisionEvent::ShouldCollide() ? That one should be getting called
constantly. I would put a trap in that function right at the top. Say
your two collision groups are group1 and group2:
int CCollisionEvent::ShouldCollide( IPhysicsObject *pObj0,
IPhysicsObject *pObj1, void *pGameData0, void *pGameData1 )
{
CallbackContext check(this);
CBaseEntity *pEntity0 = static_castCBaseEntity *(pGameData0);
CBaseEntity *pEntity1 = static_castCBaseEntity *(pGameData1);
if ( !pEntity0 || !pEntity1 )
return 1;
if ( (pEntity0-GetCollisionGroup() == group1
pEntity1-GetCollisionGroup() == group2) ||
(pEntity1-GetCollisionGroup() == group1
pEntity0-GetCollisionGroup() == group2) )
{
Assert(0); // breaks here, now step through and see why
they are colliding.
}
Otherwise, Blocked() is not called in every instance. It's only called
by the game physics. So depending on how each object moves it may not
get called. What are the movetypes of the two objects? Are they in any
hierarchies? There's not enough information here for me to answer
further.
Jay
--__--__--
Message: 2
Date: Wed, 31 May 2006 22:10:28 +0200
From: Olef van de Stadt [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] [Source] Thread-safety ?
Reply-To: hlcoders@list.valvesoftware.com
What changed in the Source engine since the 25th that a coredump occurs
on my plugin ?
Full trace:
#0 0x00e7a350 in ConCommandBase::FindCommand () from bin/vstdlib_i486.so
#1 0x02110491 in CCvar::FindVar () from bin/engine_i686.so
#2 0x021da8e1 in SV_ActivateServer () from bin/engine_i686.so
#3 0x021646cb in Host_NewGame () from bin/engine_i686.so
#4 0x0216d4f5 in CHostState::State_NewGame () from bin/engine_i686.so
#5 0x0216d949 in CHostState::FrameUpdate () from bin/engine_i686.so
#6 0x0216d9e7 in HostState_Frame () from bin/engine_i686.so
#7 0x021f9834 in CEngine::Frame () from bin/engine_i686.so
#8 0x021f74ce in CDedicatedServerAPI::RunFrame () from bin/engine_i686.so
#9 0x00146ffd in RunServer () from bin/dedicated_i686.so
#10 0x021f6eae in CModAppSystemGroup::Main () from bin/engine_i686.so
#11 0x022f9a73 in CAppSystemGroup::Run () from bin/engine_i686.so
#12 0x021f80bf in CDedicatedServerAPI::ModInit () from bin/engine_i686.so
#13 0x0014724a in CDedicatedAppSystemGroup::Main () from
bin/dedicated_i686.so
#14 0x00174d43 in CAppSystemGroup::Run () from bin/dedicated_i686.so
#15 0x00174d43 in CAppSystemGroup::Run () from bin/dedicated_i686.so
#16 0x0014760f in main () from bin/dedicated_i686.so
#17
Re: [hlcoders] [Source] Thread-safety ?
I find that hard to believe tbh, It kinda never broke before, and now it breaks all the time, even with thread-safe functions implemented or threading completely disabled. If you're doing something un-thread-safe, like calling game functions from another thread, you can expect it to break. The fact that it didn't break at some earlier time is pure luck. At 2006/05/31 03:10 PM, Olef van de Stadt wrote: What changed in the Source engine since the 25th that a coredump occurs on my plugin ? Full trace: #0 0x00e7a350 in ConCommandBase::FindCommand () from bin/vstdlib_i486.so #1 0x02110491 in CCvar::FindVar () from bin/engine_i686.so #2 0x021da8e1 in SV_ActivateServer () from bin/engine_i686.so #3 0x021646cb in Host_NewGame () from bin/engine_i686.so #4 0x0216d4f5 in CHostState::State_NewGame () from bin/engine_i686.so #5 0x0216d949 in CHostState::FrameUpdate () from bin/engine_i686.so #6 0x0216d9e7 in HostState_Frame () from bin/engine_i686.so #7 0x021f9834 in CEngine::Frame () from bin/engine_i686.so #8 0x021f74ce in CDedicatedServerAPI::RunFrame () from bin/engine_i686.so #9 0x00146ffd in RunServer () from bin/dedicated_i686.so #10 0x021f6eae in CModAppSystemGroup::Main () from bin/engine_i686.so #11 0x022f9a73 in CAppSystemGroup::Run () from bin/engine_i686.so #12 0x021f80bf in CDedicatedServerAPI::ModInit () from bin/engine_i686.so #13 0x0014724a in CDedicatedAppSystemGroup::Main () from bin/dedicated_i686.so #14 0x00174d43 in CAppSystemGroup::Run () from bin/dedicated_i686.so #15 0x00174d43 in CAppSystemGroup::Run () from bin/dedicated_i686.so #16 0x0014760f in main () from bin/dedicated_i686.so #17 0x0804909e in main () Console: L 05/31/2006 - 21:03:24: Started map de_dust (CRC -1541057188) couldn't exec skill2.cfg Executing dedicated server config file Error: Material sprites/bubble : proxy AnimatedTexture not found! L 05/31/2006 - 21:03:25: [TEST] Start of map, 32 players Section [Scenes]: 0 resources total 0 bytes, 0.00 % of limit (2.10 MB) ./srcds_run: line 426: 24429 Segmentation fault (core dumped) $HL_CMD Add -debug to the ./srcds_run command line to generate a debug.log to help with solving this problem I tried it with disabling every command and convar in my code, still the same result. I thought of updating the build sources to current and the SDK files to current. Game is also up-to-date Alfred Reynolds wrote: The Source engine is NOT thread safe. You will need to access the engine interface from the main thread and then use some safe dispatch mechanism to get them to your other threads. - Alfred Olef van de Stadt wrote: My plugin needs to create some threads for checking purposes. The concept is as follows: When a player has got a successfull Steam-ID, that ID is checked against an SQL database. To prevent the server from stalling, I use the threads (pthreads for linux, windows threads for... you guessed it.) In that thread I make calls to engine-GetPlayerNetworkIDString and playerinfo-GetPlayerNetworkIDString. Both crash every now and then on those calls or return NULL pointers. Is there any way I can get those classes to work in threads ? Or are there specific functions to call prior to accessing these class' functions ? Thanks, - Olef van de Stadt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.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] Homepage / Developer / Manual
-- [ Picked text/plain from multipart/alternative ] Thanks for the fix valve! On 5/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah nice, thanks Valve. They seem to have also fixed the regression where it kept changing my Steam internet games list back to HL2DM every time I clicked off that tab. It sure would be nice if they'd also fix that age-old bug where Steam chugs along for several minutes and then dies at the last second when you try to launch it, and it has updates, and you have a server running. Especially the part where you have to start over and go through the update again. At 2006/05/31 11:15 PM, Aaron Schiff wrote: -- [ Picked text/plain from multipart/alternative ] A fix was released today -- 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] Error at engine.dll!0x0DDDDAF2
-- [ Picked text/plain from multipart/alternative ] Pretty sure that was the cause, I recoded CTeam so it was a shared file and also made it Array3 + Steam update and the error dissapeared. Couldn't test Array2 because the code was already modified by then. Hmm I'll make it Array2 again and see what happens. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Error at engine.dll!0x0DDDDAF2
-- [ Picked text/plain from multipart/alternative ] Yup no crash. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Error at engine.dll!0x0DDDDAF2
What exactly are the differences between the three different Send/RecvPropArray methods? My only tests show that 3 seems to handle network traffic much better. Giancarlo Rivas wrote: -- [ Picked text/plain from multipart/alternative ] Pretty sure that was the cause, I recoded CTeam so it was a shared file and also made it Array3 + Steam update and the error dissapeared. Couldn't test Array2 because the code was already modified by then. Hmm I'll make it Array2 again and see what happens. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Error at engine.dll!0x0DDDDAF2
Look at the definition. 2 you can specify sizes. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: Justin Krenz [mailto:[EMAIL PROTECTED] Sent: June 1, 2006 1:50 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Error at engine.dll!0x0AF2 What exactly are the differences between the three different Send/RecvPropArray methods? My only tests show that 3 seems to handle network traffic much better. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] collision issue
Welp, In order to make it not stop moving, I had to take it out of the hierarchy, soon as I did that it worked fine. Also of note, when in hierarchy, I had to set the move angles 90 degrees different from where they should actually face, like the brushes were being rotated, without actually rotating. I guess the moveparent stuff as-is doesn't working well with brushes being attached to non-brush based entities. Now I have to add a bunch of stuff to cbaseentity so I can still establish the door as being a child, oh well. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: Tony omega Sergi [mailto:[EMAIL PROTECTED] Sent: May 31, 2006 6:57 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] collision issue Well I used that assert to step into andthrough the code, and it exists shouldcollide saying not to, yet, it still stops; but the server.dll Blocked stuff isn't getting called. It returns from vphysics, then hits vphysics again. Im going to quickly set the door to non-solid and see what happens,im baffled. Unless vphysics.dll is overriding something somewhere. And yes, there is hierarchy here; the door's parent is the prop (which should NEVER collide, according to the game code, but it's still colliding in the engine somewhere!) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] gpGlobals-curtime
I'm trying to get my head around the synchronization of curtime between and server. First, a few comments, from globalvars_base.h: // Current time // // On the client, this (along with tickcount) takes a different meaning // based on what piece of code you're in: // // - While receiving network packets (like in PreDataUpdate/ // PostDataUpdate and proxies), this is set to the SERVER TICKCOUNT // for that packet. There is no interval between the server ticks. // [server_current_Tick * tick_interval] // // - While rendering, this is the exact client clock // [(client_current_tick + interpolation_amount) * tick_interval] // // - During prediction, this is based on the client's current tick: // [client_current_tick * tick_interval] So, as I understand it client-side, in PreDataUpdate/PostDataUpdate (and perhaps OnDataChanged as well?) gpGlobals-curtime is set to what gpGlobals-curtime was on the server when this particular data update was stuffed into the pipeline. When rendering, though, what is the curtime? As I see it, there are two possibilities: The client's current tick tries to sync with what it thinks the server's current tick is. Thus, in a perfect situation, if the server is at tick 12, the client's tick is at 12, even if the last packet received was stamped with a tickcount of 9. The client's current tick is only barely ahead of its last received tick. If the server is at tick 12, but the client's last received packet is at tick 9, then the client will be rendering at somewhere between tick 9 and 10 (subject to interpolation_amount above). Which one of these is true? And which one of the three different meanings of curtime is used during entity thinking and IGameSystem updating? (I suspect the render one, but I can't be sure.) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
