This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I edited this function to allow for players info to be sent regardless of
line of sight for a client side radar I coded a while ago. However I did
not realize this would in turn force the client to dra
Cstrike uses a separate message to send this information. Not all
players made be in your PVS so you don't know were everyone is.
AddToFullPack() is currently called num_players*num_map_entities per
frame, so adding anything extra in here is expensive (I am doing some
optimisation work right now to
thats the point tho, if the server had a max_public_players and max_players
cs would know not to let you on if you havnt got a password registed for
that server, as for sv_maxvisibleplayers i didnt know that existed so my
post is invalid
- Original Message -
From: "Florian Zschocke" <[EMAI
Alfred Reynolds wrote:
Cstrike uses a separate message to send this information. Not all
players made be in your PVS so you don't know were everyone is.
AddToFullPack() is currently called num_players*num_map_entities per
frame, so adding anything extra in here is expensive (I am doing some
optimis
Although with good intentions to fix stuff for bots, Valve did it again
and broke bot support.
I see the bit flags are now working again, thats very nice. Although it
does not matter anymore for any bot author on CS as we adapted our own
fix a lng time ago. Nevertheless we switch back to ensur
S. Hendriks wrote:
Suggestion:
- When releasing fixes for bots, TEST THEM FIRST.
Wait, let me rephrase that:
- When releasing ANYTHING, TEST IT FIRST (and ofcourse, with everything.
Run a bot server, run a metamod server)
Actually, it's not really Valve's responsibility to test a server with
Metam
I do see your point, but i don't really agree with that. I understand
that changes can break things, but fixes should not! Let me paste here
exactly what the STEAM Update says:
- Cstrike FL_FAKECLIENT fix (3rd-party bots should work fine in cstrike
once more)
This is partially true! FL_FAKECLIENT
AAAHHH, Isn't the testing the responsibility of the bot maker? Isn't
maintenance the responsibility of the bot maker? Why the heck would
Valve waist money and time testing software they don't develop. The last
thing I would ever want is valve to hold off a release because they have
to test third pa
I don't think the true point of contention here is whether or not Valve
should or shouldn't test 3rd party apps. It's when Valve makes a statement
like this and it turns out to be incorrect...
"- Cstrike FL_FAKECLIENT fix (3rd-party bots should work fine in cstrike
once more)"
I guess the key wo
Jeffrey "botman" Broome wrote:
Actually, it's not really Valve's responsibility to test a server with
Metamod, AdminMOD, AMX, bots or any other type of plugin.
Hmm, I'm not so sure about that anymore. I would normally agree
with you there, but Valve is moving from an application to a
platfprm with
Cstrike now uses a hash table in the mod to cache calls to
pfnFindEntityByString(), so you won't be able to intercept them any
longer. You could intercept pfnMessageBegin(), the following set of
calls should be unique to round start:
// reset all players health for HLTV
MESSAGE_BEG
Florian Zschocke escribió:
Jeffrey "botman" Broome wrote:
Actually, it's not really Valve's responsibility to test a server with
Metamod, AdminMOD, AMX, bots or any other type of plugin.
Hmm, I'm not so sure about that anymore. I would normally agree
with you there, but Valve is moving from an
I'm hooking (*g_engfuncs.pfnRemoveEntity) => void RemoveEntity (edict_t *e) in Metamod
and have noticed that it does nothing. The trace plugin also fails to register any
results for RemoveEntity (with proper tracers set). I've tried directly calling
REMOVE_ENTITY numerous times and the hooks d
13 matches
Mail list logo
