09 Jul, 2011, Scandum wrote in the 22nd comment:
That'd probably be best, and it's not that hard to update an MSDP parser to handle arrays as an alternative mode of input.
As neither GMCP nor ATCP are ideal I'm dropping the idea for now, which means I'm pretty much finished. If clients don't want to implement MSDP that's their loss, and there's always KaVir's implementation for MUDs wanting MXP and ATCP.
As neither GMCP nor ATCP are ideal I'm dropping the idea for now, which means I'm pretty much finished. If clients don't want to implement MSDP that's their loss, and there's always KaVir's implementation for MUDs wanting MXP and ATCP.
10 Jul, 2011, David Haley wrote in the 23rd comment:
Quote
I don't know what you mean by this.
It's a reaction to what is perceived as "useless theory" compared to "real world practice", which forgets that in order to get everybody to agree on implementations you do actually need some kind of reference standard. :shrug: It's why a lot of this stuff fails, unfortunately.
10 Jul, 2011, Scandum wrote in the 24th comment:
More so a case of not caring too much about what is ultimately a hack. I considered doing a full blown GMCP implementation, but it has no central specification.
Random Picks
I don't know what you mean by this.
In my book, that would be "MSDP.Report ["HEALTH", "HEALTH_MAX"]". The semantics for this message should dictate that the value of each element should be sent back. (And if I understood you correctly earlier, it should also assign the last element in the array to the server's REPORT variable.)