[sldev] message template updates, logging in change?

[John Hurliman]

Although our (libsecondlife's)  main protocol documentation page has not 
been updated yet, there is a bit of info at 
http://www.libsecondlife.org/wiki/New_Protocol. Beyond that the next 
best source of documentation might be the latest libsecondlife source 
code, specifically the code in _Packets_.cs that parses packet headers. 
The compression on the rest of the packet hasn't changed, except that 6 
bytes of the header are preserved (never zerocoded) now instead of the 
previous 4. You are correct about the "binary buckets" or undocumented 
struct fields. If you have any questions on a specific packet or field 
someone might be able to answer it.

And yes, this diff is not useful at all: 
http://www.libsecondlife.org/template/release/diff-1.18.0.5.txt, not to 
mention that diffing message_template.msg will not tell you anything 
about changes in the packet headers.

John Hurliman


Joel Riedesel wrote:
> Indeed a diff is normally useful.  Except when every packet has changed.
> And the template system doesn't describe the login xml rpc request.
> And the template message file does not talk about the headers.
>
> (not to mention compressed data blocks where the parsing isn't 
> described in the template file)
>
> Cheers,
> Joel
>
>
> Dzonatas wrote:
>> The message template file is pretty well human-readable. A simple 
>> "diff" command ran on the current and previous versions is very 
>> informative.
>>
>> Joel Riedesel wrote:
>>> Hello.
>>> The message templates changed to a version 2.0 in the 1.18 update.
>>> Message headers appear to have been changed as well allowing for 32 bit
>>> sequence numbers instead of 24 bit.  I think.
>>>
>>> I haven't been able to find any documentation on protocol changes for
>>> 1.18, is that available somewhere?  Has the login data changed at all?
>>> My initial login comes back with a circuit code, etc., but my first
>>> packet never gets a response (UseCircuitCode) which leads me to believe
>>> that I still do not have it constructed properly for the 1.18 update.
>>> (Although network sniffing makes me think I have my packet constructed
>>> properly as compared against what the SL Viewer is sending.)
>>>
>>> No problems until the 1.18 update was rolled out.
>>>
>>> I am not using the SL Viewer source code for my SL client.  Thus it 
>>> is a
>>> bit of a pain when the protocol changes without supporting 
>>> documentation
>>> (and if I'm wrong about that please correct me).
>>>
>>> Joel
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>
>>>
>>>   
>>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html