[hlcoders] bf_write and unsigned characters
--
[ Picked text/plain from multipart/alternative ]
I've been trying to output messages that contain thësê kïñd of chæråchtèrs
to allow for multiple languages in my server plugin. For example, I would
use this code to output a chat area message:
void ChatAreaMsg(int index, char *msg) {
MRecipientFilter filter;
bf_write *buffer;
filter.AddRecipient(index);
buffer =
engine-UserMessageBegin(static_castIRecipientFilter*(filter), 3);
buffer-WriteByte(0);
buffer-WriteString(msg);
buffer-WriteByte(0);
engine-MessageEnd();
return ;
}
However, when I attempt to write out a message that contains characters that
are greater than 128 (unsigned) in byte size, they get stripped. I've also
tried replacing the WriteChar() in the WriteString() function with
WriteByte() but I still get the same result. Is there any way to write these
kind of characters into a bf_write? Or is this problem occurring somewhere
else downstream where these characters may be getting stripped?
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] bf_write and unsigned characters
Is your input string UTF-8 encoded ( looks like char * with high bits ) or
Unicode 16 (two bytes per character)?
You should be able to do what you are trying to do, but you could always write
your own version of WriteString that used the WriteBytes API instead and just
txmit the data as raw binary. Maybe prepend the # of bytes before the data
gets put into the buffer.
Looking at bitbuf, there's nothing here which will strip the 128 chars:
void bf_write::WriteChar(int val)
{
WriteSBitLong(val, sizeof(char) 3);
}
bool bf_write::WriteString(const char *pStr)
{
if(pStr)
{
do
{
WriteChar( *pStr );
++pStr;
} while( *(pStr-1) != 0 );
}
else
{
WriteChar( 0 );
}
return !IsOverflowed();
}
Yahn
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James
Sent: Friday, June 02, 2006 11:56 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] bf_write and unsigned characters
--
[ Picked text/plain from multipart/alternative ]
I've been trying to output messages that contain thësê kïñd of chæråchtèrs
to allow for multiple languages in my server plugin. For example, I would
use this code to output a chat area message:
void ChatAreaMsg(int index, char *msg) {
MRecipientFilter filter;
bf_write *buffer;
filter.AddRecipient(index);
buffer =
engine-UserMessageBegin(static_castIRecipientFilter*(filter), 3);
buffer-WriteByte(0);
buffer-WriteString(msg);
buffer-WriteByte(0);
engine-MessageEnd();
return ;
}
However, when I attempt to write out a message that contains characters that
are greater than 128 (unsigned) in byte size, they get stripped. I've also
tried replacing the WriteChar() in the WriteString() function with
WriteByte() but I still get the same result. Is there any way to write these
kind of characters into a bf_write? Or is this problem occurring somewhere
else downstream where these characters may be getting stripped?
--
___
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] bf_write and unsigned characters
However, when I attempt to write out a message that contains characters that are greater than 128 (unsigned) in byte size, they get stripped. I've also tried replacing the WriteChar() in the WriteString() function with WriteByte() but I still get the same result. Is there any way to write these kind of characters into a bf_write? Or is this problem occurring somewhere else downstream where these characters may be getting stripped? What's stripped? Are they being clamped to 128? Or is it possible that it's being wrapped around to -127? I've had issues before with bf_read/bf_write and casting signed/unsigned chars. It usually comes down to making sure that you aren't making any unneccessary casts. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals-curtime
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 to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. At 2006/06/01 11:24 PM, you wrote: 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gpGlobals-curtime
On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: 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 to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. That seems entirely plausible, but I've never seen it happen. On which callbacks is gpGlobals-curtime reversing server-side? In any case, I think there is less reason (other than that outlined above) for curtime to change server-side than client-side. As an aside, I considered tacking this onto the end of your realtime thread, but decided that it's sufficiently different to warrant a new thread. :) -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals-curtime
He's probably referring to network snapshots, where it may run code at x time; for a previous snapshot, for prediction purposes and whatnot. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: John Sheu [mailto:[EMAIL PROTECTED] Sent: June 3, 2006 2:36 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] gpGlobals-curtime On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: 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 to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. That seems entirely plausible, but I've never seen it happen. On which callbacks is gpGlobals-curtime reversing server-side? In any case, I think there is less reason (other than that outlined above) for curtime to change server-side than client-side. As an aside, I considered tacking this onto the end of your realtime thread, but decided that it's sufficiently different to warrant a new thread. :) -John Sheu ___ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] gpGlobals-curtime
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 currently isn't set during prediction, although gpGlobals-curtime and // gpGlobals-frametime are. We should probably set tickcount (to player-m_nTickBase), // but we're REALLY close to shipping, so we can change that later and people can use // player-CurrentCommandNumber() in the meantime. which leads me to believe there are known limitations here that just aren't otherwise documented. It's not clear whether the GameFrame/Dispatch dichotomy was intentional or a bug. The upshot is that, apparently, you should never do anything involving simulation time inside a console command. Instead it looks like the only reliable process is to set flags and such inside the ConCommand, and then wait until later in the CServerGameDLL::GameFrame() callback inside PhysicsSimulate etc to actually make use of the command data that was fed in. Confirmation from someone (presumably Valve) that the above statement is true and there is no simple work around to this limitation/bug would be helpful. Not sure if that helps clear things up for you, or if I'm on a tangent. :) At 2006/06/03 02:04 PM, Tony \omega\ Sergi wrote: He's probably referring to network snapshots, where it may run code at x time; for a previous snapshot, for prediction purposes and whatnot. -- -- omega Heroes of Excelsior http://www.heroesofexcelsior.com Blackened Interactive http://www.blackened-interactive.com -Original Message- From: John Sheu [mailto:[EMAIL PROTECTED] Sent: June 3, 2006 2:36 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] gpGlobals-curtime On Sat, 2006-06-03 at 13:21 -0500, [EMAIL PROTECTED] wrote: 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 to get you to the mod code. My guess is that when the server is compensating for lagged packets it sets curtime to the time it thinks the thing should have happened? This is all very sketchy, but at least it seems more reasonable than realtime. That seems entirely plausible, but I've never seen it happen. On which callbacks is gpGlobals-curtime reversing server-side? In any case, I think there is less reason (other than that outlined above) for curtime to change server-side than client-side. As an aside, I considered tacking this onto the end of your realtime thread, but decided that it's sufficiently different to warrant a new thread. :) -John Sheu ___ ___ 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
