20 Jul, 2010, KaVir wrote in the 41st comment:
Votes: 0
Tyche said:
KaVir said:
Mudlet doesn't support open protocols or MSDP, therefore Mudlet users don't have that choice.


Mudlet is using QTsockets, and doesn't have a lot of cruft yet. It was quite easy to modify Mudlet to instead call my own network library instead of QT's.

Mudlet is open source, so it's perhaps not the fairest comparison, but it was just an obvious one that sprung to mind. The protocol support issue would be of more concern for closed-source clients - it's just fortunate that the major ones I've encountered do seem to support open protocols.
20 Jul, 2010, Scandum wrote in the 42nd comment:
Votes: 0
MSDP is going to have nesting added. The debate was about whether to switch to C-like notation or keep NEW-ENVIRON derived notation.

I'm still open to input, but it looks like it'll be NEW-ENVIRON notation, with nesting added to allow nested associative arrays. There will be no support for Lua array notation as that would create two ways to create arrays - which would probably be too confusing.
21 Jul, 2010, Scandum wrote in the 43rd comment:
Votes: 0
I updated the specification, looking as following:

Quote
Nesting

Sometimes it's useful to send data as a bundle, which can be done in MSDP using MSDP_OPEN and MSDP_CLOSE after MSDP_VAL, and nest a variable and value inside the MSDP_OPEN and MSDP_CLOSE arguments. There is no limit on the number of nests, or the number of variables and values within a nest. It is up to the client to decide how to exactly process nested data.
Nested ROOM data in MSDP would look like:

IAC SB MSDP MSDP_VAR "ROOM" MSDP_VAL MSDP_OPEN MSDP_VAR "VNUM" MSDP_VAL "1234" MSDP_VAR "EXITS" MSDP_VAL MSDP_OPEN MSDP_VAR "N" MSDP_VAL "1235" MSDP_VAR "S" MSDP_VAL "4321" MSDP_CLOSE MSDP_CLOSE IAC SE

The quote characters mean that the encased word is a string, the quotes themselves should not be send.
22 Jul, 2010, Scandum wrote in the 44th comment:
Votes: 0
Regarding the original array question, using $ : { } notation, the following format is probably the simplest, and should work universally with the new msdp core:

$AFFECTS : { $name : icon : type : duration $name : icon : type : duration }

This will work out of the box for tt++ 2.00.3 and if someone writes a generic MSDP parser for MC that loads MSDP data into Lua tables it should make MSDP a lot easier to use in MC as well.

I think it's important to understand that using universal formats, while more complex to parse, will in the long run make the data easily accessible in MSDP enabled clients for a decent parser only needs to be written once.
22 Jul, 2010, David Haley wrote in the 45th comment:
Votes: 0
Quote
I think it's important to understand that using universal formats, while more complex to parse, will in the long run make the data easily accessible in MSDP enabled clients for a decent parser only needs to be written once.

The increase in complexity of parsing is only marginal; the fear of "complexity" here is a little overblown I think. I completely agree with you that the long-term gains are very considerable here.
19 Jun, 2011, Scandum wrote in the 46th comment:
Votes: 0
After some more client side work I've come to realize that the way MSDP handles arrays isn't the best way to go about things. The biggest issue is complexity (my json parser is a lot cleaner than my MSDP parser) and the inability to create an array with only one index.

Having given this quite a bit of thought I think it's best to go the JSON / LPC route and add an operator to open and close an array.

I'll leave the current MSDP semi array handling for unnested data as it currently is so KaVir's server implementation remains valid. I don't foresee any backward compatibility issues.
06 Jul, 2011, Scandum wrote in the 47th comment:
Votes: 0
I've incorporated array support in the MSDP specification, and it's supported by tintin++ 2.00.7.

This change makes MSDP compatible with JSON, allowing MSDP over JSON if desired.
22 Aug, 2011, KaVir wrote in the 48th comment:
Votes: 0
Has anyone had any success getting nesting to work with MUSHclient or Mudlet?

I had a go at the weekend, but I can't seem to receive MSDP_TABLE_OPEN or MSDP_TABLE_CLOSE - one of them seems to be silently stripped before reaching my plugin, the other appears to corrupt the data, causing it to bleed into the next variable. I'm getting the same with MSDP_ARRAY_OPEN and MSDP_ARRAY_CLOSE.

Note that this was before I did any parsing. As soon as the subnegotiation sequence arrived, I'd loop through the data, replacing ASCII characters 1-6 with displayable characters, then display the string. It works fine for 1 and 2 (MSDP_VAR and MSDP_VAL) as well as most later values (such as bell and tab), but as far as I can see, some ASCII values (including 3, 4, 5 and 6) are either stripped or corrupt the sequence.

I'm wondering if the values might be parsed at a higher level - they represent "end of text", "end of transmission", "enquiry" and "acknowledge" respectively. It appears to do the exact same thing in both MUSHclient and Mudlet, however, which also makes me wonder if it might be Lua related.
22 Aug, 2011, Scandum wrote in the 49th comment:
Votes: 0
Maybe easiest to ask the client developers?
23 Aug, 2011, Scandum wrote in the 50th comment:
Votes: 0
It's kind of unlikely anyone would look into nesting support if no muds support it. In the case anyone is interested in looking into this as well, my test mud supports the ROOM variable which uses nested data as described on the specification page. If the MSDP table is translated to a Lua table it should be fairly easy to get the mushclient automapping plugin to work with it. Adding support for the ROOM variable should be pretty straight forward for most MUDs that already support MSDP.

The address is: lolamud.net 6969

A tintin++ script for MSDP automapping is available here: http://tintin.sourceforge.net/scripts/ms... for those that are only interested in adding the ROOM variable.
23 Aug, 2011, KaVir wrote in the 51st comment:
Votes: 0
It looks like the problem I encountered was almost certainly caused server-side. I was helping someone get the snippet working on their mud, and thought I might as well add the nesting before any of their players started writing scripts. Looks like I'll need to follow the data through each step of the code to find out what's happening.

But if that is the case, then any codebase that works with TinTin++ should in theory also work with MUSHclient and Mudlet. Which codebases did you test after updating the installation instructions in my snippet?
23 Aug, 2011, Scandum wrote in the 52nd comment:
Votes: 0
I didn't test the code, a combination of a lack of interest and a lack of time. The main objective was to remove rogue structured data, fearing it would spread like a cancer which would seriously damage MSDP as a protocol.
23 Aug, 2011, KaVir wrote in the 53rd comment:
Votes: 0
Seriously? You change the specification 2.5 months after I release my snippet and "don't foresee any backward compatibility issues", but a month later you change the specification again, then yet another month later my implementation has suddenly become a "cancer" because it doesn't implement variables that the specification describes as "mere suggestions"?

Then you update my snippet, first with a corrupted installation file - and you haven't even tested it to see if it works?

Your specification seems to undergo changes every few weeks, if you're going to keep updating it that frequently then you can't expect everyone to be following your latest fancy - most developers just don't make major decisions that fast; some of them have spent literally months playing with the snippet before going live.

I've put a lot of time and effort into the snippet, not just developing it but also promoting it, including the creation of demo GUIs and installation instructions for other muds to encourage them to use it. If you start promoting and distributing a version of the snippet that doesn't even work then your "lack of interest and a lack of time" is going undermine a lot of the credibility I've been fighting to build up for the protocol; the phrase "poisoning the well" springs to mind.

While I disagree with some of the decisions you've made, I've still been gradually refining and tweaking the snippet to bring it in line with the latest version of the specification - but you're not making it easy. There are now 20 muds that support MSDP, and all but 2 of them are using my code, so this is no longer just about what you want or what I want. The snippet needs to follow the specification, but it can't do that until the specification becomes stable. Please, stop tinkering with it, unless you're adding optional extensions.
24 Aug, 2011, Scandum wrote in the 54th comment:
Votes: 0
The main reason for the change 3 months ago was the custom basic array data structure you were using. This kind of forced my hand to add a better, nestable array data structure based on JSON, as discussed and announced in another thread. I then requested (for the 3rd time) you update your snippet, you declined and insisted to keep using your custom data format. I then forced your hand by linking a compliant version of your snippet that works with tintin++ and any other client/snippet following protocol, instead of just your GUI plugin.

Anyways, the core is finished and stable, and I hope we can get past this hurdle soon.
24 Aug, 2011, Cratylus wrote in the 55th comment:
Votes: 0
24 Aug, 2011, Rarva.Riendf wrote in the 56th comment:
Votes: 0
I do not care about that much about the updates…but find a better way to push them, pushing a full file were we have to look for the differences is painful, just put the diff.
— /home/riendf/nerf/src/comm.c	2009-09-09 08:49:45.000000000 -0700
+++ ./comm.c 2009-09-09 11:00:52.000000000 -0700
@@ -30,6 +30,7 @@
#include <stdlib.h>
#include <time.h>
#include <stdarg.h>
+#include <crypt.h>
#include "an.h"
#include "recycle.h"
#include "mob_prog.h"
@@ -1791,7 +1792,7 @@
write_to_buffer(d, "\n\r", 2);
#endif

- if (str_cmp(argument, ch->pcdata->pwd)) {
+ if (str_cmp(crypt(argument,ch->name), ch->pcdata->pwd)) {
sprintf(buf, "Wrong Password: %s@%s\n\r", ch->name, d->host);
info(buf, LEVEL_SENIOR, BUG_INFO);
write_to_buffer(d, "Wrong password.\n\r", 0);
@@ -1930,7 +1931,7 @@
}

free_string(ch->pcdata->pwd);
- ch->pcdata->pwd = str_dup(pwdnew);
+ ch->pcdata->pwd = str_dup(crypt(pwdnew,ch->name));
write_to_buffer(d, "Please retype password: ", 0);
d->connected = CON_CONFIRM_NEW_PASSWORD;
break;
@@ -1939,7 +1940,7 @@
write_to_buffer(d, "\n\r", 2);
#endif

- if (str_cmp(argument, ch->pcdata->pwd)) {
+ if (str_cmp(crypt(argument,ch->name), ch->pcdata->pwd)) {
write_to_buffer(d, "Passwords don't match.\n\rRetype password: ", 0);
d->connected = CON_GET_NEW_PASSWORD;
return;


+ and - show where there is a diff, and wich line it was
24 Aug, 2011, Rarva.Riendf wrote in the 57th comment:
Votes: 0
Before someone argue this code does not work…(a problem of library not present or not linked or not the right one I dunno, but once the password is more than 8 chars or something like that it gives the same crypted result for azertyui and for azertyuiazzeaze.
It was just to show how to push the differences, as mudbytes does not support any update to a code posted unfortunately. (oh and put a date in it so we know wich version is the last one)
24 Aug, 2011, Davion wrote in the 58th comment:
Votes: 0
Rarva.Riendf said:
It was just to show how to push the differences, as mudbytes does not support any update to a code posted unfortunately. (oh and put a date in it so we know wich version is the last one)


Update to code posted is fortunately included in the mudbytes code repository. It also has two datestamps. One when it was first uploaded, and the second is for when it was last updated.
25 Aug, 2011, Tyche wrote in the 59th comment:
Votes: 0
Davion said:
Rarva.Riendf said:
It was just to show how to push the differences, as mudbytes does not support any update to a code posted unfortunately. (oh and put a date in it so we know wich version is the last one)


Update to code posted is fortunately included in the mudbytes code repository. It also has two datestamps. One when it was first uploaded, and the second is for when it was last updated.


Maybe I missed it, but the only problem with the update feature is that I don't see a way for anyone to access the other versions of the code.

I believe Rarva is referring to a policy issue. Only the author/original submitter can use the update feature. This is good policy, please don't change it.
You might vaguely remember the "destructive" updates to old mud code that occurred over on MudMagic. ;-)

Whether someone chooses to submit a fork as a patch file, a partial or complete distribution is best left to the author of the fork.
I don't think any board policy on this (other than following the license) would be productive.
25 Aug, 2011, Rarva.Riendf wrote in the 60th comment:
Votes: 0
Quote
I believe Rarva is referring to a policy issue. Only the author/original submitter can use the update feature. This is good policy, please don't change it.
You might vaguely remember the "destructive" updates to old mud code that occurred over on MudMagic. ;-) '


Nod, though I do not see how you can have destructive update when you have branches (forks) and know who does the update. (and of course have access to wichever branch you want). My concern was about something like Scandum did to Kavir snippet. Someone coming here to include mssdp support has hardly any way to know wich version he should choose, if Kavir Snippet still works etc.
I alerady asked this question as I planned to post updated/enhanced code of some snippets but found disturbing to have to create a new thread. As I am not the original code writer and it creates problem for people to know which version they should choose.
40.0/77