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
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
This appears to be a bug in the core engine that the SDK has no real control
over.
If I add this extra logging:
To the bottom of SendProxy_PlayerList:
Msg(sending player #%d = ent num %d\n, iElement, pOut-m_Int);
To the bottom of SendProxyArrayLength_PlayerArray:
Msg(sending size %d\n,
We'll have someone take a look at this with a debug engine and see what
changed.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, May 28, 2006 12:53 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] assert
This is certainly a promising step - thanks all.
However, can you explain what exactly this fixes? Is this supposed to fix the
classic Physical Mayhem Bug, or does this fix something to do with
scripts/propdata_cs.txt, which is presumably irrelevant to the generic HL2DM
Physical Mayhem Bug?
The following patch fixes the bug by disabling CTeam entirely. I'll eventually
remove CTeam from my mod, as it doesn't do anything, but for now here's a
backwards-compatible fix. (Unfortunately the player that is reporting crashers
since the latest Steam update was not helped by this fix.)
Garry sent in a deterministic way to cause some bad physics behavior.
Because of his repro case I was able to fix a bug with the code I posted
below. Personally, I have never been able to reproduce the behavior
you've described. I believe Adrian has seen the behavior in HL2DM at
some point, but
This morning I was working on something, and ran both the 3d party
mdldecompiler.exe with out any issues, plus studiomdl.exe in sourcesdk\bin
Later, I went back to run them again, and began getting odd DLL errors. First,
trying to build a model with studiomdl gives me this output (which I've
This is different fro mall the
http://developer.valvesoftware.com/wiki/SDK_workaround stuff posted earlier?
At 2006/05/28 08:33 PM, Tim Holt wrote:
This morning I was working on something, and ran both the 3d party
mdldecompiler.exe with out any issues, plus studiomdl.exe in sourcesdk\bin
Hmm possibly/probably (?) - I confess I hadn't seen that. This is a HL2MP based
mod so I assume the If your mod is based on a game other than Half-Life 2...
part applies if you take it literally.
I'm currently forcing a re-DL of the SourceSDK steam cache but when that's done
I'll try what's
Yes, that fixed it. Copied all dlls from hl2mp bin folder into sdk bin and now
the model compile runs.
/me pokes Valve to fix ASAP for all the little people
Quoting Tim Holt [EMAIL PROTECTED]:
Hmm possibly/probably (?) - I confess I hadn't seen that. This is a HL2MP
based
mod so I assume
Yeah part of my real job is engineering support so I understand the importance
of repro steps if engineering hasn't seen an issue. I'm a bit baffled though,
given how many people have reported it, that Valve hadn't seen it regularly.
(Does Valve have a public HL2DM stress test server? If so,
The particular case Garry reported was with a prop set to
COLLISION_GROUP_PUSHAWAY against another prop set to
COLLISION_GROUP_DEBRIS. The code in hl2mp gamerules returns different
values for:
ShouldCollide( COLLISION_GROUP_PUSHAWAY, COLLISION_GROUP_DEBRIS );
And
ShouldCollide(
13 matches
Mail list logo
