phf: asciilifeform: if something hit your phuctor logs from dc just now, that would be me, yes

phf: http://btcbase.org/log/2018-04-24#1805075 << i did a first pass on the spec over the weekend, but haven't had time to formulate my thoughts. it looks like enough to do a prototype short of three things: handshake process is still work in progress, i noticed that it's missing type of data descriptor values for 4.3.2 (there's a list of data types, but not the values that indicate which type it is), and there's no format description for the encapsulated f ☝︎

phf: ile types. for text client i will need the format of the map files, i suspect it's whatever crystal space is using, but some formalization is required there.

phf: it is otherwise a typical gaming protocol, a single header that wraps a range of message types. i don't quite remember but i think existing eulora protocol works somewhat like that, just a smaller number of message types. ☟︎

phf: there's also parts in the spec that describe the format, and you can infer the behavior from the format, but there isn't explicit description of behavior. for example movement type a.5.23-a.5.28 is presumably for moving things and self around, but without further details it's hard to say how it's supposed to work. so i can't really say much about the internal consistency of the protocol, i.e. are the message types sufficient to perform some set of in g

phf: ame actions.

phf: well, i'm still going to post a comment about it though on diana_coman's blog, this is more or less thoughts out loud.

phf: diana_coman: i meant to say that your protocol has less message types

phf: diana_coman: is the protocol the entirety of documentation for client writers or there's more stuff in the pipeline? ☟︎

phf: kk

phf nods