I'm getting reports that the latest srcds steam update has increased the amount
of vphysics bugs.
I'm fairly certain now there was a vphysics change. Does anyone know when the
last one occured? It apparently has introduced more bugs in the srcds core.
My vphysics.so is dated Feb 18 22:26 but
Attach to it and get a stack trace. You probably won't have symbols, but still
might be illustrative.
At 2006/03/03 10:13 PM, Adam \amckern\ Mckern wrote:
Steam.exe useing 100% cpu at random times?
When runing a half life mod, or half life 2 mod (or
even the core game its self) steam.exe
Well, the mid Dec one is it then. I know I didn't update my server between
Thanksgiving and New Years, and the others server hosts I know probably didn't
either. The symptoms are the same as the same as always, but the repro time
frame seems to have changed like I said.
Does anyone know what
What are talking about with respect to change? Change from what version to
what version? Looks like it's always been that way.
In any case, you can add another member function without worrying about engine
binary compatibility if you want.
At 2006/03/05 02:07 AM, you wrote:
Aaron Schiff
There's no engine change required. That's a seperate module. The engine
maintains it's own code for class member functions.
I've never had a need to do this particular change in the Source engine, but I
don't see how this could cause a problem.
At 2006/03/05 12:50 PM, Tom Parker wrote:
You can add member functions to Vector. It will not affect the structure's
binary layout.
At 2006/03/05 01:08 PM, Jorge Rodriguez wrote:
Tom Parker wrote:
Replacing this code with a more C++ friendly version would require
drastic changes everywhere in the engine, and be more of a pain than a
It's worth noting that whatever the change was, it primarily appears to have
gotten worse on linux. Although strangely vphysics.so crashers have, if
anything, gotten more rare.
The behavior of the bug has not changed much on Win32 it seems. Though again
may vphysics.dll crashers have gotten
Are you referring to this known issue?
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#GNU_crasher_for_maps_with_broken_ladders
At 2006/03/06 01:08 AM, Adam \amckern\ Mckern wrote:
You will also get crashing with linux if ladders are
not made one by one - such as you copy and paste
Is there another resource that might be able to explain the recent vphysics
change in particular, or shed light on HL2's vphysics bug in general?
At 2006/03/05 01:28 PM, [EMAIL PROTECTED] wrote:
It's worth noting that whatever the change was, it primarily appears to have
gotten worse on linux.
Frequently players - I believe always when dead - fall out of DM maps. This
causes servers crashes occasionally in some assert()s, alone with pages and
pages of PM Got a velocity too low on Z errors.
This isn't as critical of a srcds core bug as the vphysics bug (or even the
realtime
Well on dm_powerhouse for instance, do you know of any particular spawn point
that's broken? They're all official Valve maps so I couldn't modify them, but
maybe could hack in a code workaround to not use the broken spawn points if
that's the issue.
At 2006/03/09 08:30 PM, you wrote:
--
[
There's a long-standing issue with the HL2 core, or perhaps the SDK, that if
you change your screen res of window size, VGUIs get messed up until you
restart. I've never tried to investigate a fix though.
At 2006/03/10 08:49 AM, Benjamin Davison wrote:
--
[ Picked text/plain from
related to the problem bloodykenny brought up, because
he says it only happens when players are dead. But maybe they are the
same problem.
--
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http
Yes I'm running my mod, but it doesn't affect spawn points. Note, the player
never notices they're outside the map. I think it's only ragdolls, though I'm
not positive.
Let's put it this way, I don't have players yelling help I've fallen out of
the map. I just see in the server log pages
My mod does have bots now, but I've seen this problem forever - I distinctly
remember seeing one of the first times I ever loaded dm_runoff also, like a
year ago, and I had no bots then.
Hmm. Maybe the latest steam update fixed it? I haven't seen this bug since I
updated.
At 2006/03/11
Well I see the vphysics crasher is alive and well after the srcds update last
week.
vphysics.dll!260a2426()
vphysics.dll!260d3eae()
vphysics.dll!2608af8e()
vphysics.dll!2608b01b()
vphysics.dll!260a2697()
vphysics.dll!260aac2b()
Stack trace? Error message?
At 2006/03/13 09:51 PM, Michael Kramer wrote:
--
[ Picked text/plain from multipart/alternative ]
I don't know what happened, whether it was the last steam update or what.
But since then. The AI That I coded in, for MP (followed the tutorial on the
WIKI) no Longer
You want spectator bots?
At 2006/03/14 07:58 PM, Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Hi guys :D
Currently I'm wrestling with bots =) And I have them working nicely, but
when they first get put in the game I don't want them to spawn physically
into the
So move them to the spectator team.
I don't see what the purpose of spectator bots could be, but oh well, that
seems to be what you want.
At 2006/03/15 08:24 AM, Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Well sort of, basically what I'm doing is adding a bunch
Hmm this one's seemingly identical to the last one.
vphysics.dll!260a2426()
vphysics.dll!260d3eae()
vphysics.dll!2608af8e()
vphysics.dll!2608b01b()
vphysics.dll!260a2697()
vphysics.dll!260aac2b()
vphysics.dll!2609cd5b()
Here, the scoreboard: src\cl_dll\hl2mp\ui\hl2mpclientscoreboard.cpp
At 2006/03/18 04:40 PM, Michael Kramer wrote:
--
[ Picked text/plain from multipart/alternative ]
Howdo create a VGUI panel in MP games? I followed the tutorial on making
GameUI Panels, but it did not work for my mod :(
Can
Did you even look at that filename I posted? The scoreboard is a very good
example.
How about this, you fix the vphysics crasher and I'll write your gui for you.
At 2006/03/18 05:09 PM, Michael Kramer wrote:
--
[ Picked text/plain from multipart/alternative ]
Do you know where it is called?
I
For instance, every time a bot joins, I get:
GetUserSetting: cvar 'cl_playermodel' unknown.
GetUserSetting: cvar 'cl_playermodel' unknown.
Now I could do special-case hacks all over the place for bots, but surely
there's a better way?
___
To
In that vain I hope one day to have *a fix for bloodykenny's mod*, ie the
infamous Physical Mayhem bug.
At 2006/03/21 08:31 PM, Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
I found it sorta funny that Valve mentioned that it was a fix for *Garry's
Mod*
On 3/21/06,
Ah thanks. It's worth noting however that the mod gets callbacked prior to the
CreateFakeClient call even completing, so if one wants to fix this, you
apparently have to put a nasty hack into the void ClientActive( edict_t
*pEdict, bool bLoadGame ) function like so:
if
And another...
vphysics.dll!260a1f40()
vphysics.dll!260b6240()
vphysics.dll!2609444b()
vphysics.dll!260e577c()
vphysics.dll!260a2400()
vphysics.dll!260d3eae()
vphysics.dll!2608af8e()
vphysics.dll!2608b01b()
Hmm this one's a little different - has a tier0 in there.
I think Jay Stelly said one time that should be impossible. Well it's rare,
anyway.
I have minidumps of all of these btw, if anyone from Valve wants them.
vphysics.dll!2609993d()
tier0.dll!008738de()
Wow good catch! I saw the chat truncation thing once before, but chalked it up
to a networking glitch or something so I didn't report it. I should have
investigated further. Do you know how this bug trickles down to causing the
chat truncation?
Worthy of note is that stringpool.cpp contains
This is the same bug in the srcds core, unfortunately. In fact Valve probably
copied the Quake 2 code directly because Quake 2 had this exact same annoying
bug of failing to report dll load issues and continuing. That was the first
thing I fixed when they open sourced it. :)
Try
Bonus trace for today...!
vphysics.dll!260a2426()
vphysics.dll!260d3eae()
vphysics.dll!260d0590()
vphysics.dll!2608af8e()
vphysics.dll!2608b01b()
vphysics.dll!260a2697()
vphysics.dll!260c6716()
vphysics.dll!260aabf2()
Well UTIL_GetPlayerConnectionInfo wouldn't work because there's no entity so
player is null. But engine-GetPlayerNetInfo might have worked as a hack.
Good idea, but too late I already solved it manually. :)
At 2006/04/01 11:06 PM, Aaron Schiff wrote:
--
[ Picked text/plain from
This vphysics crasher is a new one - it crashed on
testbyte ptr [ebp],2
where ebp was a null pointer...
vphysics.dll!260a1f40()
vphysics.dll!260d3dc0()
vphysics.dll!260e577c()
vphysics.dll!260a2400()
vphysics.dll!260d3eae()
cl_entitylist is the client side name.
search for 'maxplayers'.
At 2006/04/09 12:20 PM, you wrote:
--
[ Picked text/plain from multipart/alternative ]
Now conceptually I have the idea down in my head; What I would first do is
find the entity and then find out it's position in the world(easy
What C++ class entity is the dm_runoff nuke damage stored in? Ie, how would I
go about correcting the damage to be more for a mod where the standard amount
is rather puny?
___
To unsubscribe, edit your list preferences, or view the list archives,
I've found that this bug seems to actually have two components, neither of
which the mod has seemingly any control over.
The first I mentioned below is that realtime will stand still before periods up
to 1 seconds or so if something else on the box is using lots of CPU.
There is a second,
Jay I'm confused because your response acts like client stuck on object is
hard to reproduce. If I flip a table upside-down and walk across it that
always causes the error message for me. Is it not supposed to do that? Or
maybe you were talking about something else - there were 3 issues in
Hmm I don't see a trigger_hurt being spawned on map startup.
At 2006/04/09 11:59 PM, Michael Kramer wrote:
--
[ Picked text/plain from multipart/alternative ]
uhh, It isn't like tha ti don't think, I think it has a huge trigger_hurt
all over the map (except in the building) and the damage is set
Using the 100% cpu method that always breaks rather easily, I get results as
follows, from the code below. It usually occurs in groups of 2 or 3. The
long-term slowdown may take several days to repro again. In this case you see
realtime being frozen for 2 milliseconds, calling GameFrame 3
Oh yea forgot to say it's an intel p4 single proc with HT enabled.
Here's one that repeated 6 times lasting 5 ms...
odd realtime 11172032919604142 1479.026855 1479.368408 0.015000
odd realtime 11172032923627014 1479.368408 1479.368408 0.015000
odd realtime 11172032926027614 1479.368408
Thanks much. When you say curtime will reflect the 0.015 increments per
tick, it sounds like you're saying that realtime is broken in this regard and
I should use curtime instead? That's ok, but please confirm, as I will need to
do a lot of search and replace.
I've run a few tests and
Did you confirm the broken spot in dm_runoff that I posted the link to earlier?
At 2006/04/14 08:42 PM, Skillet wrote:
--
[ Picked text/plain from multipart/alternative ]
The same issue happens in my mod (using HL2DM SDK base), so I would assume
it is a problem of the SDK and none of the
No, I do not need real time accuracy. I just need to know how the game thinks
time is advancing each tick. To give an example, I'm using gpGlobals-realtime
to set a stamp and change the weird feature where you can switch weapons over
and over almost limitlessly fast in HL2 DM.
I left it
Abstract code snippets are not useful. Post a stack trace.
At 2006/04/18 07:38 PM, Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Hi, I'm currently messing around with the CUTLVector class but I have a
problem. For some reason it will crash with a .AddToTail in some
So I happened to catch my server when the Physical Mayhem bug was in progress
but the server had not (yet) crashed.
(See http://forums.steampowered.com/forums/showthread.php?s=threadid=248425
for anyone unfamiliar with this bug.)
Anything I can do to help debug this? As usual with the
I noticed that most of the objects in the world have z values like:
z -880609.44 float
z -861464.81 float
z -1501742.9 float
So I guess when the Physical Mayhem bug is happening and all the items
disappear, they aren't getting removed from
Yes it does - #23
At 2006/04/18 09:57 PM, Jay C. wrote:
GoreMod doesn't call or hook anything in that trace :\
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED] On Behalf Of Benjamin Davison
Sent: 19 April 2006 00:20
To: hlcoders@list.valvesoftware.com
It could've had more callbacks along the way.
At 2006/04/18 10:25 PM, Jay C. wrote:
But inside that function, which is GameFrame, nothing else is called in this
chain.
-Original Message-
From: [EMAIL PROTECTED] [mailto:hlcoders-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent:
Inside engine-SolidMoved the engine.dll does a few callbacks to the open
source side to get collision properties and origins. Then it loops around for
a very long time, walking some sort of closed-source linked-list.
Is engine-SolidMoved supposed to be doing looping and cpu-intensive things?
I'm seeing plenty of callbacks to WorldSpaceSurroundingBounds from the core
engine side of things, and for what it's worth the SDK side is returning
seemingly valid, albeit hugely negative z, values.
+ pVecMins0x0012ddc0 {x=4984.7964 y=5646.7964 z=-1191362.9 }
Vector *
+
What is IsAsleep()? I can't find any documentation on it, but is it weird that
all the objects are IsAsleep() true?
I notice it because the closed-source side calls back to
WorldSpaceSurroundingBounds which calls ComputeSurroundingBox, and in there it
always goes to check and is always
OBB is just the bounding box around the model
USE_OBB_COLLISION_BOUNDS is probably there for other support that was never
implemented/never needed to be
So you think it's bad if every entity in the world is set to
USE_OBB_COLLISION_BOUNDS? Valve, is this bad?
Garry, are you talking about a
Code snippets like this inevitiably leave out the problem. You probably don't
have the string stored in a static? If the string is deallocated at any time,
the server won't send it. Also make sure it's null-terminated.
At 2006/04/22 04:15 PM, Benjamin Davison wrote:
--
[ Picked text/plain
The mod players were getting restless so I couldn't wait any longer for a
response from Valve so I had to shut it down. Unfortunately there's no
documentation on how most of that stuff is supposed to work, and there are
frightfully few asserts in the SDK. I guess I'll have to do a lot of
You should add a patch to
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List ...?
At 2006/04/23 08:02 PM, Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
If you're a coder, it's a simple fix...anyway, it's a modside fix:
if ( (ent-GetEntityName() !=
soapboxThe string_t type is just a thin char[] wrapper. A real C++ string is
std::string and has copyable, constructable operator semantics and
reference-counted garbage collection that prevent some of this confusion.
Nothing good can come of assignment operators on char[] wrappers, unless
I fixed this prior to creating
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List so I never posted
a good patch for it, but yea you had to set the spectator to alive or it
couldn't move.
At 2006/04/25 06:24 PM, Nick wrote:
--
[ Picked text/plain from multipart/alternative ]
I still
Yeah I've noticed that bug too. I'm not certain that's even in the SDK - it
may be a core engine bug.
At 2006/04/28 12:19 PM, Justin Krenz wrote:
The scroll bar background in my mod's MOTD panel is missing its texture
(appears as the purple checkerboard). Does anyone know what texture is
Well if you set the compiler options correctly, the code won't even compile
when you access a variable without initializing it. Unfortunately Valve's SDK
still needs a lot of work to be at that level. (I posted some of the changes
on the KI list.)
At 2006/04/27 03:57 AM, Garry Newman wrote:
Well I was referring to gcc actually, since it's a much better and extremely
helpful compiler when it comes to error-checking your code. But msvc has it
too:
configuration properties
C/C++
General
treat warnings as errors
At 2006/04/30 11:15 PM, Nick wrote:
--
[ Picked text/plain from
I'd highly recommend avoiding those CUtl things in that context. Just use
regular STL unless you're dealing with a Valve interface that demands something
else. STL is much more robust and easier to debug.
At 2006/05/04 08:58 AM, Jay C. wrote:
I'm trying (unsuccessfully) to use some of the
If you're using a newer version of gcc than the version the host box came with,
you may need to ship libstdc++.so, libc.so or others with your game .so.
GNU/Linux does an absolutely abysmal job of helping you in this respect. There
is, for instance, no way to fully statically link a
I'm not sure what is meant by 'kernel accessing functions' in the context of
static linking. However that's not what I was referring to. I was referring
to static linking being incompatible at the user code level. Ie, gcc doesn't
allow '-static' and '-shared' at the same time, and if you
Can you be more specific? Don't see it, but then the chatbear search is not
reliable.
At 2006/04/30 11:47 PM, Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
It certainly is an SDK bug and a fix *has been posted* on VERC forums.
--
ts2do
--
I'm worried that with such a tremendous delay between SDK updates, it's going
to take days to merge the codebase. Maybe I'm imagining more code thrash than
there's actually been though.
At 2006/05/11 11:26 PM, Aaron Schiff wrote:
--
[ Picked text/plain from multipart/alternative ]
He's lying!
In the base SDK there are only a few areas where realtime is used. None of
them should really be important, but I changed the non-perf related ones to
curtime for consistency in:
c_baseanimating.cpp
hl2_player.cpp
I left the perf ones as realtime in:
perfvisualbenchmark.cpp
vgui_fpspanel.cpp
I was just investigating too. It looks like in release mode there's a chance
of it crashing, but not certain. More evidence to support my ongoing theory
that Valve never does debug builds. :)
At 2006/05/27 01:13 PM, Jorge Rodriguez wrote:
Tony omega Sergi wrote:
Is anyone else getting an
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,
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.)
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
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,
I left my server on dm_steamlab overnight: no crash, and no Physical Mayhem
bug. (I'm still reluctant to say it's gone for good after 1 1/2 years of
spending so much of my modding time on this.)
So then I reverted the fix and applied just the assert. The instant I did
changelevel
That's interesting - I checked C_BasePlayer and you're right in that it falls
through to C_BaseEntity which uses the m_iTeamNum, which is only transmitted to
PVS-local entities.
However C_Team stills seems to not serve any useful purpose, because the easy
solution would be to change
Ok thanks, sounds good. CTeam does seem appropriate for storing something like
team win counters or whatever, but I still would not want to waste the
bandwidth (even though it should be fairly low) sending the team associations
two different ways, when the client can already figure that list
Ok thanks for the updates. I added a KI for that:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Server:_The_client.27s_team_membership_is_pointlessly_sent_across_the_wire_twice.
There seems to be another new crasher at work then in the latest Steam. I'm
getting lots of reports
What makes you think that? I've never seen any evidence of that.
At 2006/05/29 01:41 PM, Nick wrote:
--
[ Picked text/plain from multipart/alternative ]
I don't think the modding hl2:dm code is the exact same as valve's hl2:dm
release code
On 5/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
You can't always set a breakpoint in callbacks from the closed-source engine.
I'm not really sure why, but I've noticed, during my extensive time spent
trying to debug the closed-source vphysics.dll that it doesn't always work.
The stack trace gets messed up, presumably by inlined code that
Has anyone gotten the Homepage / Developer / Manual stuff working again in
their mod since that steam update broke it a few weeks back?
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
You mean it was working for a little while? I haven't seen it work in several
weeks.
At 2006/05/31 12:12 AM, Adam \amckern\ Mckern wrote:
Nope, the my media update broke it all again
Adam McKern
--- [EMAIL PROTECTED] wrote:
Has anyone gotten the Homepage / Developer /
Manual stuff
Note the latest Steam update broke array transmission so C_Team from the SDK
will crash. See the KI page.
At 2006/05/31 12:35 AM, Giancarlo Rivas wrote:
--
[ Picked text/plain from multipart/alternative ]
Hi, I am having trouble debugging my code since it crashes on the closed
source so I get
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
Ah an update yesterday even should fix that. Update your srcds and retry?
At 2006/05/31 11:11 PM, [EMAIL PROTECTED] wrote:
Note the latest Steam update broke array transmission so C_Team from the SDK
will crash. See the KI page.
At 2006/05/31 12:35 AM, Giancarlo Rivas wrote:
--
[ Picked
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
Coincidentally I'd just been doing some more research into gpGlobals-curtime
server-side. Not sure if this applies to client-side too, however it seems
that gpGlobals-curtime server side is able to go slightly backwards in some
situations. Apparently it depends on what call back is occurring
Apparently this curtime fluctuation issue to is due to ConCommands not being
handled within CServerGameDLL::GameFrame() but instead starting from within the
ConCommand::Dispatch() callback. This is all very bizarre, and what few
comments there are on this are things like
// tickcount
Neither srcds_i486 nor srcds_i686 will load my mod on FC5. They will load
hl2mp however. It's hard to say what's to blame because, as has been discussed
ad nauseam on the Verc forums, the srcds has a bug where it gives no indication
as to why it fails to load your .so, it simply skips it and
Ah - I should've thought of this, but it's rather late, thanks for leading me
down the right path there!
There were several gnu symbols undefined because srcds_i486 and srcds_i686
don't link to libstdc++.so, unlike the test program I was using to check the
validity of my .so, which of course
Yeah, a good best-practice. I'm linking to 5 other third-party libraries
statically, but somehow that one slipped by.
Here is, fyi to all, the program to check that your mod is loadable and exports
the right symbol. Sure would be nice if srcds would do this for you though
*cough*. It
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
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
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?
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
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
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
I'm not sure the fact that it works on a listen server means anything. Ie, my
guess is it is not even possible to get a 'Server uses different class tables'
on a listen server. However I've never launched my mod with anything other
than srcds, so I'm not really certain how it works if you're
Is that a fix for the bug where re-sizing your HL2DM causes the ammo hud to be
off the side of the screen? If so please elaborate, as I'm constantly annoyed
by that long-standing bug whenever I switch in/out of fullscreen mode.
At 2006/06/25 11:51 AM, Benjamin Davison wrote:
--
[ Picked
After a month or so without the commonplace Physical Mayhem bug that repros in
HL2DM, I have now managed to create a new Physical Mayhem bug that's possibly
unique to my mod, or at least to mods with similar features. This one is a bit
harder to repro - I've only seen it twice in the last week
This is a bug in HL2DM as well. The blood spatters on the wall don't appear
for your own blood.
At 2006/06/25 08:24 PM, you wrote:
Hi,
I was working on a new melee weapon for our mod Caliber when I ran
across this. I've been debugging left and right all night trying to
understand why the blood
So what exactly did Valve break in the hud? What files? Because HL2DM has
this same bug.
At 2006/06/26 11:32 AM, Tony \omega\ Sergi wrote:
Yeah you have to put the numbers in the scheme file relative to 640x480.
I use hud_reloadscheme a lot, and I've never had this problem after editing
them
Finally, I wish that Valve would roll back their changes to the SDK
tools. The latest version of the tools do not work properly. If you're
not going to fix them, then at least go back to a version that did work.
It's not nice doing unsolicited updates, installing broken code, then
just leaving it
1 - 100 of 284 matches
Mail list logo
