Does StaticShape::packUpdate() have guaranteed delivery ?
by Orion Elenzil · in Torque Game Engine · 05/24/2006 (6:06 pm) · 3 replies
Title pretty much says it all -
we're getting some dropped events
and one suspect is StaticShape::packUpdate().
say an event X occurs and we set the netmask, etc,
is that event guaranteed to be ghosted to all appropriate clients ?
i understand that different clients may get it at different times, that's fine,
but the guaranteed-ness is pretty important.
say our event is basically a sibling of PositionMask:
tia,
orion
we're getting some dropped events
and one suspect is StaticShape::packUpdate().
say an event X occurs and we set the netmask, etc,
is that event guaranteed to be ghosted to all appropriate clients ?
i understand that different clients may get it at different times, that's fine,
but the guaranteed-ness is pretty important.
say our event is basically a sibling of PositionMask:
if (bstream->writeFlag(mask & PositionMask)) {
bstream->writeAffineTransform(mObjToWorld);
mathWrite(*bstream, mObjScale);
}tia,
orion
About the author
#2
ai yai yai. this is gonna take a while to digest.
what about this, from player.cc ?
this looks like an event-type notification versus a state-transmission,
but maybe it actually is state.
or what about InvincibleMask from shapebase ?
that sure seems like information which needs to be guaranteed..
re our conversations,
we're actually sending the text down via ghosting.
putting the chatting into a different connection may indeed make sense,
we'll toss the idea around.
thanks,
ooo
05/25/2006 (2:29 pm)
Hey Stephen, thanks for replying.ai yai yai. this is gonna take a while to digest.
what about this, from player.cc ?
if (stream->writeFlag((mask & ImpactMask) && !(mask & InitialUpdateMask)))
stream->writeInt(mImpactSound, PlayerData::ImpactBits);this looks like an event-type notification versus a state-transmission,
but maybe it actually is state.
or what about InvincibleMask from shapebase ?
if (stream->writeFlag(mask & InvincibleMask)) {
stream->write(mInvincibleTime);
stream->write(mInvincibleSpeed);
}that sure seems like information which needs to be guaranteed..
re our conversations,
we're actually sending the text down via ghosting.
putting the chatting into a different connection may indeed make sense,
we'll toss the idea around.
thanks,
ooo
#3
What this means is that it will be sending an update for that object as soon as it can fit it into the packet. Since there is no guarantee that it's the very next packet (see net priority, as well as the higher priority updates such as control object and net events), when the time comes to be able to pack up the update, it will use the latest state of the object, instead of the time when you first noted an update was needed.
This is very useful, mainly in these high population packet scenarios, because you don't want to be sending stale data when you finally are able to send it, instead of sending data that may be 2-10 seconds old.
Now, since you are sending text via ghosting, you are in fact filling up your packets with some extremely difficult to compress data (unlike "normal" object updates, when you can pack down to bits instead of bytes), so what you will probably see when you actually grab some packets and take a peek inside is a LOT of strings in the ghost update portion of the packet, which are pushing out (causing to be sent in a later packet) your object updates.
Given your description, the only thing that prioritizes your chats vs your object updates is the netPriority that may (or may not, if you haven't played with it) of your object updates. You may want to look at balancing the priorities so that your object updates are being sent at a higher priority than a majority of your conversation object updates, but be careful not to go too far and flush the text out of the packet completely, or your conversations are going to start getting really wierd.
I'm curious in fact to see how your conversations are holding up when you take into account the latest state issue, because depending on how you store the lines entered, it's possible that some will be lost (packUpdate called a couple of times, due to a scenario like a line of text didn't fit into a packet, so it's packUpdate was called at a later time.)
I've actually been thinking about this quite a bit today after your initial question, and I do think pretty strongly that you will need to (sooner or later!) have two separate network pipes to your clients, one for object updates and one for text chat. Might be a good time to look at a standalone chat server, which will give you the added benefit of cross-Game Server chat if implemented well!
05/25/2006 (7:28 pm)
Anything that is using the ghosting system (if you are using stream->anything) is going to allow for a latest state update.What this means is that it will be sending an update for that object as soon as it can fit it into the packet. Since there is no guarantee that it's the very next packet (see net priority, as well as the higher priority updates such as control object and net events), when the time comes to be able to pack up the update, it will use the latest state of the object, instead of the time when you first noted an update was needed.
This is very useful, mainly in these high population packet scenarios, because you don't want to be sending stale data when you finally are able to send it, instead of sending data that may be 2-10 seconds old.
Now, since you are sending text via ghosting, you are in fact filling up your packets with some extremely difficult to compress data (unlike "normal" object updates, when you can pack down to bits instead of bytes), so what you will probably see when you actually grab some packets and take a peek inside is a LOT of strings in the ghost update portion of the packet, which are pushing out (causing to be sent in a later packet) your object updates.
Given your description, the only thing that prioritizes your chats vs your object updates is the netPriority that may (or may not, if you haven't played with it) of your object updates. You may want to look at balancing the priorities so that your object updates are being sent at a higher priority than a majority of your conversation object updates, but be careful not to go too far and flush the text out of the packet completely, or your conversations are going to start getting really wierd.
I'm curious in fact to see how your conversations are holding up when you take into account the latest state issue, because depending on how you store the lines entered, it's possible that some will be lost (packUpdate called a couple of times, due to a scenario like a line of text didn't fit into a packet, so it's packUpdate was called at a later time.)
I've actually been thinking about this quite a bit today after your initial question, and I do think pretty strongly that you will need to (sooner or later!) have two separate network pipes to your clients, one for object updates and one for text chat. Might be a good time to look at a standalone chat server, which will give you the added benefit of cross-Game Server chat if implemented well!
Torque 3D Owner Stephen Zepp
There exists a scenario in a very high network transmission situation (which I think applies to your situation) where NetEvents (which are what you are most probably using for chatting), which have a higher order of placement into packets, will "crowd out" ghost updates, and at very high transmissions, it's very possible that an extremely low update priority (based on the update priority rules, even with a skipped update counter) can conceivably be ignored for quite a long time....in other words, check your actual average packet content (not just size, they should always be very similar in size, near your MaxPacketSize in a high transmission scenario) and see if it resembles the above scenario.
It may actually be sensible to move off your chatting in a chat-intensive environment like this to a second connection somehow, so that you don't run into this interference, but obviously that's a big departure from your current beta environment.