Truncated into Nonsense

[Idiosyncratic]

Is it possible to somehow edit the code so that the truncated emotes are not displayed, but instead returned to the user? This would serve as an effective means to resolve the clutter of nonsense and awkwardness resulting from such calamities.

Semper Pax,

Dirr

[corona]

Excellent idea. Sometimes if I'm having to do too much at one time (full tavern, three people in my head, etc, etc) I don't realize that what I just sent was too long and it can make for a confusing situation, it sucks trying to find where I need to pick up and fill in what I was unable to supply because of the code.  

[Xygax]

A better approach to this is to set up your mud client to restrict your output to the mud.  The mud would never really be able to tell if some extraordinarily long line of text SHOULD be acted upon or shouldn't, even if it is an emote, and adding code to EACH specific command to detect this situation and short-circuit would be unpleasant to say the least.

-- X

[Larrath]

A better approach to this is to set up your mud client to restrict your output to the mud.  The mud would never really be able to tell if some extraordinarily long line of text SHOULD be acted upon or shouldn't, even if it is an emote, and adding code to EACH specific command to detect this situation and short-circuit would be unpleasant to say the least.

-- X

I hope I'm not being annoying with this question, but why is it difficult?  There is already some snippet of code that checks if the input is too long and truncates it if it is; can't the Emote/Pemote commands use a modified version that will simply block the emote and say that the emote is too long, and possibly even which word was the first past the limit?

[Stroker]

A better approach to this is to set up your mud client to restrict your output to the mud. The mud would never really be able to tell if some extraordinarily long line of text SHOULD be acted upon or shouldn't, even if it is an emote, and adding code to EACH specific command to detect this situation and short-circuit would be unpleasant to say the least.

Do you happen to know how I can accomplish this task with simpleMUD?

[Xygax]

Do you happen to know how I can accomplish this task with simpleMUD?

It look like the source is available, you could either hard-code it into the input handling routines or add a nice option for it.  It would be slick if it actually limited the input field itself (ie. so that if you reached the end you'd get a beep or something, before you hit return).

-- X

[Pontius Pilate]

It look like the source is available, you could either hard-code it into the input handling routines or add a nice option for it. It would be slick if it actually limited the input field itself (ie. so that if you reached the end you'd get a beep or something, before you hit return).

Okay.... but I still don't know how to do that.... is it difficult? Could you detail this coding in some way? Can -I- actually do it? I'm fairly illiterate when it comes to coding.

[Stroker]

Uhh... the previous post was by yours truly.

[Xygax]

Oh, I lied.  There is an open source project called SimpleMUD, but it is a server, not a client.

Too bad.

[Stroker]

Am I too assume, then, that you cannot accomplish any such implementation with simpleMUD? Any other *free* client that you can recommend with such potential?

[Xygax]

If I had a problem with long emotes, I'd set my input-window up to use a fixed with font, and then set it to the with or 1/2 the longest possible emote.  That way, you know that if your emote is 2 lines, you probably need to wrap it up before it...  well, wraps.

This can be done with putty+tintin or putty+tinyfugue or any other combination of putty+unix-shell-based client.  Other clients very likely have similar abilities, though.

-- X

[Jherlen]

Echoing Larrath's post... if the code is already there to detect long input, couldn't it simply be sent back to the use with a message "Error: input string too long, shorten your text and try again." rather than truncated and acted on?

[The7DeadlyVenomz]

It can be done. But it's a tad time consuming.

[Stater of the Obvious]

if the code is already there to detect long input, couldn't it simply be sent back to the use with a message "Error: input string too long, shorten your text and try again." rather than truncated and acted on?

Clearly it could, as this is what happens with too-long ldescs and gone messages.  I don't know anything about coding, but it seems like you could just import the same function with a different limit and a different return message for emotes.

[Larrath]

If I had a problem with long emotes, I'd set my input-window up to use a fixed with font, and then set it to the with or 1/2 the longest possible emote.  That way, you know that if your emote is 2 lines, you probably need to wrap it up before it...  well, wraps.

This can be done with putty+tintin or putty+tinyfugue or any other combination of putty+unix-shell-based client.  Other clients very likely have similar abilities, though.

-- X

This is very problematic because using symbols in your emote can make even half a line gigantic.

Code Select Expand


emote eats ~kalan while ~big, ~fat and ~ugly bang on ~table, ~sunglasses hiding his eyes.
The short, large-headed midget eats his partially eaten kalan fruit while the big, muscle-corded half-giant, the fat, sweaty half-elf and the ass-ugly templar bang on a long, rectangular black baobab table, his dusty set of Kurac-emblazoned sunglasses with dark red lenses hiding his eyes.


This is also problematic because currently, the emote could end up like this:

Code Select Expand


The short, large-headed midget eats his partially eaten kalan fruit while the big, muscle-corded half-giant, the fat, sweaty half-elf and the ass-ugly templar bang on a long, rectangular black baobab table...

Not a pretty image.

[Anonymous]

I don't think posting an absurd example of an emote is a good way to prove there's really a problem here.  I've never hit up against the emote text limit and I consider myself something of an emote fiend.  (Meaning I try to do it a lot, at least when solo not that I think I'm a genius with emotes)

That's just a crappy emote, regardless.  That many sdescs makes it nearly impossible to read for those around you.  If there are more than two people or objects being referred to make it generic and don't use ~ placeholders, for all of our sakes.

[Anonymous]

Why is there a limit in the first place? I cannot recollect... or possibly never actually possessed such valued knowledge.

Semper pax,

Dirr

[Anonymous]

Why is there a limit in the first place?

I can't answer that question but I hope the answer is 'to keep players from writing novels instead of emotes' because damn, you know some of you people would do that.

[Anonymous]

I can't answer that question but I hope the answer is 'to keep players from writing novels instead of emotes' because damn, you know some of you people would do that.

Usually, it becomes tedious and improbable in terms of size, length, and speed involved. However, as you pointed out, during solitary role-play? Why not?

Semper Pax,

Dirr

[Anonymous]

Because people that use more than one (or a combination of) as, while, during, at the same time or any other phrase connectors or, God forbid, a period followed by another sentence in a single emote should be shot on principle as dangers to the human race.

[Anonymous]

Because people that use more than one (or a combination of) as, while, during, at the same time or any other phrase connectors or, God forbid, a period followed by another sentence in a single emote should be shot on principle as dangers to the human race.

I'd rather have -that- than some of the one-liners that I've seen. I don't know about you, but I've had just about enough of: so and so templar licks him lips.

Semper ... well it's no longer pax, but WAR WAR, damn it.

Dirr