#bitfighter IRC Log

IRC Log for 2020-06-09

Timestamps are in GMT/BST.

06:41:46 BFDiscordBridge <raptor> using mDebugObjectSizes helps you verify you are handling your network data properly. if pack/unpack does not match, then that means you did not code/decode the same number of bits in a particular net object
06:43:26 BFDiscordBridge <raptor> I don't know about the EventConnections
08:41:51 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Well, I manage to get more information by outputting endingPosition and getBitPosition()
08:41:58 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> It expected 417 bits and I read only 190.
08:42:12 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> By looking thru the code, I've receive 53 bytes
08:42:28 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> 53 bytes however, is 424 bits
08:42:53 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> so I'm not entirely sure. Could it be strings are variable bits?
08:49:39 BFDiscordBridge <raptor> strings are variable - they use StringTableEntry or raw strings (huffman processed)
08:55:40 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> I see.
08:56:15 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Damn. This can be problematic because I'm not sure if it is U32, U32, StringTableEntry or U32, StringTableEntry, U32.
08:56:41 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> outputting just binary makes text not easily recognizable due to huffmann encoding...
08:56:47 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> i wish it was ascii... 😦
08:58:08 BFDiscordBridge <raptor> the secret is always in the pack vs unpack methods
08:58:25 BFDiscordBridge <raptor> both will use STE or huffman string
09:08:28 BFDiscordBridge <raptor> the pack/unpack methods must be symmetrical
09:26:12 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Sorry what is the difference. I thought STE is a huffman string
09:34:27 BFDiscordBridge <raptor> a STE is just a number - both server/client keep a list of Strings (huffman encoded) where the index in the list can be passed from server to client
09:35:03 BFDiscordBridge <raptor> so common game messages are stored in this way, but a chat message would not be
09:35:58 BFDiscordBridge <raptor> so server might say to client: use STE #31, and the client will use that to look up the string in its copy of the string table
09:42:06 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> I'm sorry but isn't it you defined TableStringEntry testString and you read it by testString.getString()
09:42:06 BFDiscordBridge <ChumpChange> Nice shooting @💜ᵖʰᵃⁱᶜᵐ💜! You just ranked up to level 3 !
09:42:11 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> What do you mean #31?
09:43:29 BFDiscordBridge <raptor> phaicm, yes that's correct, too
09:44:05 BFDiscordBridge <raptor> you define a STE, and both client and server will both have a copy of identical string tables
09:44:24 BFDiscordBridge <raptor> so to reduce network data, only the *index* of the STE is passed between client/server
09:44:38 BFDiscordBridge <raptor> #31 is just an example index saying "go look up string at index 31"
09:45:35 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> How am I supposed to define TableStringEntry's normally?
09:46:19 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> The client send's a string (its a full string as in "123-abcdef") I can see it using huffmann encoding to process this string for sending the packet
09:46:25 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> would this be a case for TableStringEntry?
09:48:57 BFDiscordBridge <raptor> no
09:49:03 BFDiscordBridge <raptor> a STE is sent as just a number
09:49:11 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Ah. So this is my mistake
09:49:38 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> what variable type should I be using instead? ByteDataPtr and do a manual readString()?
09:51:22 BFDiscordBridge <raptor> you mean if it's not an STE?
09:53:13 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> yes.
09:53:18 BFDiscordBridge <raptor> take a look here: https://github.com/bitfighter/bitfighter/blob/master/zap/TextItem.cpp#L335
09:53:32 BFDiscordBridge <raptor> it calls bitstream->writeString()
09:53:44 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> I am also getting help from Torque3D community. They just explained that TableStingEntry sends the string for the first time.
09:53:50 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> then sends only the index.
09:53:55 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> afterwards.
09:53:57 BFDiscordBridge <raptor> ah yes, that's right
20:23:26 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Thanks for the advise. I managed to get my expected string to be read from my server
20:23:51 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> However, I kinda cheated since I don't know how to properly declare my arguments from TNL_IMPLEMENT_RPC
20:24:31 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> it seems it wrote the following parameters U32, U48, U16, TableStringEntry
20:24:52 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> since U48 is not a thing i cheated and did U32, U32, U32, TableStringEntry
20:24:58 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> since they are equivalent (bit wise)
20:25:17 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> do you know a dataType that is U48?
20:47:22 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> oh
20:47:26 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> C /// Packed representaion of an IPAddress. struct IPAddress {    U32 netNum; ///< Address of the host in IP address format.    U16 port;   ///< Port field of the network address. };
21:34:34 BFDiscordBridge <💜ᵖʰᵃⁱᶜᵐ💜> Yes this worked.

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.

06:41:46	BFDiscordBridge	<raptor> using mDebugObjectSizes helps you verify you are handling your network data properly. if pack/unpack does not match, then that means you did not code/decode the same number of bits in a particular net object
06:43:26	BFDiscordBridge	<raptor> I don't know about the EventConnections
08:41:51	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Well, I manage to get more information by outputting endingPosition and getBitPosition()
08:41:58	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> It expected 417 bits and I read only 190.
08:42:12	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> By looking thru the code, I've receive 53 bytes
08:42:28	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> 53 bytes however, is 424 bits
08:42:53	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> so I'm not entirely sure. Could it be strings are variable bits?
08:49:39	BFDiscordBridge	<raptor> strings are variable - they use StringTableEntry or raw strings (huffman processed)
08:55:40	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> I see.
08:56:15	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Damn. This can be problematic because I'm not sure if it is U32, U32, StringTableEntry or U32, StringTableEntry, U32.
08:56:41	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> outputting just binary makes text not easily recognizable due to huffmann encoding...
08:56:47	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> i wish it was ascii... 😦
08:58:08	BFDiscordBridge	<raptor> the secret is always in the pack vs unpack methods
08:58:25	BFDiscordBridge	<raptor> both will use STE or huffman string
09:08:28	BFDiscordBridge	<raptor> the pack/unpack methods must be symmetrical
09:26:12	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Sorry what is the difference. I thought STE is a huffman string
09:34:27	BFDiscordBridge	<raptor> a STE is just a number - both server/client keep a list of Strings (huffman encoded) where the index in the list can be passed from server to client
09:35:03	BFDiscordBridge	<raptor> so common game messages are stored in this way, but a chat message would not be
09:35:58	BFDiscordBridge	<raptor> so server might say to client: use STE #31, and the client will use that to look up the string in its copy of the string table
09:42:06	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> I'm sorry but isn't it you defined TableStringEntry testString and you read it by testString.getString()
09:42:06	BFDiscordBridge	<ChumpChange> Nice shooting @💜ᵖʰᵃⁱᶜᵐ💜! You just ranked up to level 3 !
09:42:11	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> What do you mean #31?
09:43:29	BFDiscordBridge	<raptor> phaicm, yes that's correct, too
09:44:05	BFDiscordBridge	<raptor> you define a STE, and both client and server will both have a copy of identical string tables
09:44:24	BFDiscordBridge	<raptor> so to reduce network data, only the index of the STE is passed between client/server
09:44:38	BFDiscordBridge	<raptor> #31 is just an example index saying "go look up string at index 31"
09:45:35	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> How am I supposed to define TableStringEntry's normally?
09:46:19	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> The client send's a string (its a full string as in "123-abcdef") I can see it using huffmann encoding to process this string for sending the packet
09:46:25	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> would this be a case for TableStringEntry?
09:48:57	BFDiscordBridge	<raptor> no
09:49:03	BFDiscordBridge	<raptor> a STE is sent as just a number
09:49:11	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Ah. So this is my mistake
09:49:38	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> what variable type should I be using instead? ByteDataPtr and do a manual readString()?
09:51:22	BFDiscordBridge	<raptor> you mean if it's not an STE?
09:53:13	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> yes.
09:53:18	BFDiscordBridge	<raptor> take a look here: https://github.com/bitfighter/bitfighter/blob/master/zap/TextItem.cpp#L335
09:53:32	BFDiscordBridge	<raptor> it calls bitstream->writeString()
09:53:44	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> I am also getting help from Torque3D community. They just explained that TableStingEntry sends the string for the first time.
09:53:50	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> then sends only the index.
09:53:55	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> afterwards.
09:53:57	BFDiscordBridge	<raptor> ah yes, that's right
20:23:26	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Thanks for the advise. I managed to get my expected string to be read from my server
20:23:51	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> However, I kinda cheated since I don't know how to properly declare my arguments from TNL_IMPLEMENT_RPC
20:24:31	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> it seems it wrote the following parameters U32, U48, U16, TableStringEntry
20:24:52	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> since U48 is not a thing i cheated and did U32, U32, U32, TableStringEntry
20:24:58	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> since they are equivalent (bit wise)
20:25:17	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> do you know a dataType that is U48?
20:47:22	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> oh
20:47:26	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> C /// Packed representaion of an IPAddress. struct IPAddress { U32 netNum; ///< Address of the host in IP address format. U16 port; ///< Port field of the network address. };
21:34:34	BFDiscordBridge	<💜ᵖʰᵃⁱᶜᵐ💜> Yes this worked.