Logic would dictate that the entity numbers *should* be the same on
client and server; I don't see how the two can remain synchronized
They are the same client and server, but that's not what I'm concerned
about. I'm trying to read the entity lump in the map and match up those
The only circumstance in which this is handled in 8 bits is network
transmission, which can be changed by modifying delta.lst. That's what
it's there for. Surprise or no surprise, it's not hard coded in the
engine and the engine will happily handle as many sequences as you like.
You should be
It's bugging me, what where the names of those methods to emulate
constructors and destructors? Which classes should they be used for?
classes should they not be used for?
Constructors and Destructors should not be used for anything that inherits
from the CBaseEntity class (since
Repeat of destructor/constructor C++ discussion. TFC uses them. HL
doesn't. Read why and how below.
From: Ken Birdwell
Sent: Thursday, September 13, 2001 2:31 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [HLCoders] CBaseEntity Memory Mgmnt Q.
I guess an important
Leon is mostly correct, though the engine IS limited to only supporting
4,294,967,296 sequences. :P
In any case, the whole business of needing the sequence to line up is ONLY
if you're displaying a different model on the client than the one the server
is using. Since HL and TFC allow clients to
I haven't actually looked into this yet so i can't
really say i have had a go but i was just wondering what is involved when
changing a players skeleton to one that doesn't use the standard default valve
skeleton. Is any coding involved at all or should it all be handled already
One thing to remember is that any transformation applied to the model
client side has to be duplicated on the server in order to mantain hit
detection in order.
We had this problem with CS, where the client was doing all the blendings (
9 to be exact ) while the server had no idea about what
Mail list logo