Re: RE channels, send, blast, stacks
A text message is the exact same size as a stack message with a string pushed onto it.
You don't have to use ZLIB, no, but if it's a very large message that can take a large chunk of the size off. If it's a small message it may actually increase the size (ZLIB has overhead).
I don't know what you mean by case sensitive?
Re: RE channels, send, blast, stacks
Case sensitive EX: a vs A
I'm trying to use the stack now, but can't get it work.
If you are sending bytes and shorts for example, do they have different indexes or the same one?
EX: 900 (short) Lacewing,0
700 (short) Lacewing,1
Q (ACII BYTE)Lacewing,2 or Lacewing,0
Re: RE channels, send, blast, stacks
I know what case sensitive means, I just don't know what you mean by it :P
They have different indexes. Look at my guide on using stacks.
Re: RE channels, send, blast, stacks
"I know what case sensitive means, I just don't know what you mean by it :P"
LOL
EX:
Say I had 2 guns in a game.
A big gun and a little gun.
So, for the big gun under the string variable called "guns" I wanted to use a capital G. For the small guns, I wanted to use a small "g" would both scenarios be interpretted as just a g?
Reasoning
If the less characters you use, the less bandwith you use, sending instructions with single characters looks like the way to go. If the letters are cap sensitive, that gives you 52 possibilities instead of 26. Though between subchannels and variable slots you are unlikely to run out of options, for the sake of simplicity using 1 variable slot and less sub-channels is preferable. :)
I realized my other mistake as well. I was using 2 characters and trying to send it as an ASCII. I'm about to try it again.
Re: RE channels, send, blast, stacks
Don't get what I'm doing wrong.
Sending message as blast stack on sub-channel 1
Push short for X coordinate
Push short for y coordinate
Push Byte for a single letter
Blash stack to channel on sub-channel 1
recieving message
set position x to short lacewing, 0 UNSIGNED
set position y to short lacewing, 1 UNSIGNED
set STATUS to Byte lacewing 0 ASCII
:s
Re: RE channels, send, blast, stacks
The number you put for getting values out of a stack is a byte position. You want 0, 2, 4.
Re: RE channels, send, blast, stacks
Thx
Think I get it.
So
if it's the first thing pushed it's 0
if it's a byte, count up by 1
if it's a short count by 2
if it's an interger count up by 4
if it's a float count up by 4
So it's 0 because it's the first push
Then 2 because the first push was a short so it took up 0&1
Then the last one is 4 because the second short took up 2&3
And if the message is sent it is signed, but if it is blasted it is unsigned correct?
I just tried it and it worked!
It seems like it has more lag than when I was using the parser though :O
Re: RE channels, send, blast, stacks
Send and Blast have no influence on wheather it is signed or unsigned. That just means sign like negative. Unsigned is only positive and signed is negative and positive. But there is a catch. Say you use a byte. The number of possibilties you can have with 8 bits (1 byte) is 256. The range of an unsigned byte is 0 to 255, but the range of a signed byte is -128 to 127. The same 256 possibilities are there but they just represent different numbers.
Now, with sending a byte with a stack, the reason you don't specifiy signed or unsigned is because it doesn't matter. Say you push byte 12. Then you recieve it as signed. You get 12. Or, you receive it as unsigned. You then also get 12. However, say you sent byte 255. unsigned would get you 255, as intended, but signed would get you 0! This is because 255 is outside the range of -128 to 127, so it 'wraps' around it. Difference between 255 and 127 is 128. And -128 plus 128 is 0.
Now, last but not least, with the same concept in mind, say we sent -128. When you recieve it as signed you indeed get -128. But, receiving it as unsigned gets you, you guessed it, 127!
because of how the numbers are represented, sending a byte number between 0 and 127 will be exactly the same signed as unsigned. but between -1 and -128 or 128 to 255 will cause wrap around for one or the other of signed and unsigned.
So, you just choose what you need based on your purpose of the emssage. EG coordinates would be signed because they can be negative, but animations don't g negative, so you could use unsigned.
;)
Re: RE channels, send, blast, stacks
Nice post about signed and unsigned, LB - people often ask me why there aren't separate send actions for signed and unsigned, while there are separate actions for reading.
Maybe you could throw that on the wiki somewhere :)
Re: RE channels, send, blast, stacks
Quote:
Originally Posted by LB
say you sent byte 255. unsigned would get you 255, as intended, but signed would get you 0! This is because 255 is outside the range of -128 to 127, so it 'wraps' around it. Difference between 255 and 127 is 128. And -128 plus 128 is 0.
Not quite. 127 is 127, 128 is -128. So you should be subtracting 128, and your answer for 255 should be -1.