I don't see what the advantage of using a homebrew format to the dozens of already quite standard formats (with parsers written in every language) that are out there. That's really my only complaint about MSDP. It would be like instead of using zlib for MCCP someone had invented a new compression algorithm that was used. And then the algorithm had to be changed every so often because it wasn't quite right or feature complete. It just wouldn't have made sense in a similar way as what went on here. Is it good enough for your needs? Probably. Is it beyond criticism? I don't think it is.

We're getting close to debating what the meaning of "is" is.

So let me ask, since I really think we should at least try to avoid the recursive rhetorical arguing to argue that is looming…

If we are so wary of MSDP due to fragility, capricious maintainer, and cooties…what are some viable alternatives for convenient rich clienting?

-Crat
http://lpmuds.net

I'm sorry but I'm still not sure what your point is. The point isn't whether non-zero is bigger than zero. The point is that if you have nothing and are considering adding something, what you add should depend on what you need, not the fact that adding something means that you have something you didn't have before.

I disagree on that. I did not have msdp nor 256 color support. I did not need it as well. But I found the plugin, saw it was easily pluggable, and broke nothing. I still do not need it.
But now my players can have it, and everyone that connect knows he can have it. What you need in the end are players most likely. Not msdp or a database or anything tehnical anyway.

Looks like the trolls are out in force tonight. I could keep debunking these arguments, but having done so once should be enough to establish which party is clueless.

One note… if you ever want to display color codes as themselves (such as when editing things in OLC systems, etc), because of the way KaVir's snippet works (right before the actual socket send calls), you will have to hand-escape all such codes in your display as there is no way to send stuff without having the snippet "render" the codes into their ANSI/XTERM256 equivalent, that won't also risk breaking TELNET handling.

You could always do your own raw sends around the system, but then you risk corrupting a partially sent TELNET sequence already in the output buffers, or not having one in your own data properly escaped.



I think that was established long before this thread.

Something I was already doing way before using KaVir plugin, as when you edit stuff in olc you have to see exactly what you type, and not what is rendered.
That makes the plugin a little more costly for those who did not touch OLC at all.

And I have see Kavir fixed a rogue ; in msdp lately :)
I have a suggestion to all of you , dont use ; as a nop, use {} instead, you will avoid this :)
last versions of gcc detects rogue ; and missing potential break as well, it worth it to always use the last version.

I do for Mudlet, using ATCP - and my snippet supports the same functionality. It could be done through MSDP just as easily, but Mudlet doesn't support MSDP, and I don't know of any other clients that natively offer autoinstallers.


Or you could spend 2 minutes modifying the snippet.

In protocol.h, add the following variable to the protocol_t struct:

bool_t bShowRawCodes;

In protocol.c, add the following initialisation in ProtocolCreate():

pProtocol->bShowRawCodes = false;

In protocol.c, replace the following line near the top of ProtocolOutput():

if ( pProtocol == NULL || apData == NULL )

With:

if ( pProtocol == NULL || apData == NULL || pProtocol->bShowRawCodes )

Now you can toggle between showing and hiding the raw codes by setting the flag.

My snippet is primarily designed to add MSDP support, and although it does also offer additional features that I consider useful, there will be always be further functionality that specific muds want. However I would postulate that those who are unable or unwilling to make even simple customisations like the above are unlikely to benefit from the tools provided by the snippet, anyway.


I did use {}:

/* If we don't support MSDP, fake it with ATCP */ 
            if ( !pProtocol->bMSDP );
            { 
                 pProtocol->bATCP = true;

Note that the impact of the above bug was minimal, because MSDP already overrides ATCP. All it meant was that if your client supports both MSDP and ATCP, the mud would send SERVER_ID twice.

if ( !pProtocol->bMSDP ); will create a warning in gcc now. It saw it, but I thought this was just a placeholder for later code so I did not reported it to you.
And like some break you did not put (as they are useless anyway, I concur, around 4 or 5 of them) will now send warnings.
the {} was not specifically targeted to you, but when you look at a code you did not write, a {} stand out a lot more than a ; as a nop operation. Makes the other coder intention clearer as well.

True, you could toggle the entire rendering of color codes easily enough (as shown). That means, and correct me if I'm wrong here, that your OLC editor can't used color while displaying color codes in text being edited (such as you may want for syntax highlighting, or menu choices) unless you have a way to force immediate buffer flushing to the socket. The ProtocolOutput() routine would normally be called as your output buffer is flushed to the socket at the top/bottom of your main loop, so code that toggled that boolean on, wrote something, and then toggled it off and wrote something else would not work as expected because the toggle would be in the off state for the whole buffer.

There are ways around it, obviously. You can add an "escape color codes" function. You could add color tokens for "stop processing color until you see this token again". You could track the byte positions at which you did the toggling. You could even change the buffering system to keep every output as a seperate string, to be emitted in order, and then have such a boolean associated with each seperate string.

Just pointing out that, as it stands, it doesn't seem quite as trivial as you suggest, and the "You" above means the end-user, not necessarily you, KaVir.

No that just means you have to separate the renderer from the editor, thing that is pretty much the first thing to do in the first place. (separate data from how they are viewed)
And it is quite easy to do as a matter of fact, as when wherever you edit text in OLC you just replace the disaply method call by one that tells it must no touch the data at all. (actually very few methods I have 8 direct calls from immortals commands that need to see the pure text to edit it, 4 from the text editor itself).
It really is trivial and should be done anyway even without using KaVir Snippet , as whatetver escape char you use for any reason, you need a way to see and edit it.

That principle generally has to do with separation of concerns…model vs view… For maintainability and dryness. It's defeated when you're repeating yourself with code for multiple cases that are so similar. Furthermore, if you really want to separate the data from how it's viewed you wouldn't have embedded color codes in the model at all.

What do you mean by embedded color code ? the actual telnet color or a tag ?
Because for me the tag is part of the data, and the telnet color code should only appear when rendered, by using the data in the tag. Or do you mean something else ?
I

I think The Way It's Displayed ™ is classically indicative of something that shouldn't be part of the model. You can't really get around the need to send telnet color sequences (because that's the technology we're using) but that doesn't mean you *must* mirror the practice. From a pragmatic stand point it may be very reasonable to have the color codes embedded, but it's very similar to how in the HTML world it used to be common practice to use inline styles to modify the way the text is viewed by the browser. Especially the color. That's fallen so far out of practice that the tags that make it even possible have been depreciating, and most projects ban anything similar to the practice. It's much better to consider classes of data, then if you need markup to use markup that represents broad classes of data. What it is, not what it should display as.

The problem with this is often that you want to expose color codes to users. (I never did. I never had color codes on my mud for players to use.) And this may definitely be more pragmatic, because it's far more simple to do it this way and expose.

Well I use very few forced colors, it is more like'all object' will be of those colors, all room desc of this one etc.
But on some VERY rare occasion I want to force a color in the middle of an object description. For this I use what I have: &1 to &23 (not the brightest idea of a choice of tag delimeter but well…inherited it and have other thing to do atm) and &0 to revert to previous character color choice. I dont see how you could do without having a kind of tag for it.
But the telnet code itself should never appear in your datas.
To make in game editing possible I simply go to a routine that print data as is. There is very few of them as editing stuff in olc will go to a single entry point. I dont have the need but it would be really trivial to add a rendering preview in the editor itself. So Kavir Plugin really is not the problem as if you used color already, you would need a way to see the raw data anyway.
So I dont see what is quixadhal point.

That's the point. If you have an output routine that bypasses KaVir's snippet, you can't be 100% certain that you aren't breaking a TELNET sequence.

Consider. Normal output goes through the snippet's filter, it ends up emitting a partial TELNET sequence, or perhaps an opening part to a sequence where data will follow and be closed by an IAC SE later. In the previous loop, that initial part was sent, then YOU come along and send stuff out the socket, and then the remainder of the valid sequence is sent on the next buffer flush. You just corrupted the data being sent.

Now, perhaps the snippet refuses to send any TELNET negotiation unless it's 100% complete, in which case one hopes use of MSDP datasets are carefully controlled to always finish inside a single main loop iteration, or that it maloc's off memory as needed, in case something large is sent in pieces (like a mudlist).

I never looked at the telnet protocol so I will trust you on this. That means that you can send data one after the other, but they will not be treated one after the other in case of a transmission problem ?

No, it's normally called before copying a string to the output buffer. If you toggle the flag on, send the message, then toggle the flag off again, it will copy the string directly to the output buffer without parsing it. Send another string and that will be parsed before being copied to the output buffer. Then when the buffer is next flushed, the first part will be raw data while the second part will have been parsed. The solution I offered will work fine.


ProtocolOutput() only handles colour, MXP, MSP and Unicode, none of which use subnegotiation. You could remove the function entirely and MSDP will still work perfectly fine. The solution I offered would have no impact on MSDP.

The underlying technology guarantees no transmission problem if the data is received at all. In the case of a broken connection, naturally, you'd need to reconnect somehow.