Maximum total input/output length for emotes/communication

[SchroedingersCat]

Hello,

What is the total maximum of <output> I can send IG while "saying", "emoting", "psi-ing" or something like that, before the <output> gets truncated?

The way I see it, there are 4 possible elements to any output of the aforementioned sort, e.g. in a typical "tell":

My Input:

• 1: <command>
• 2: <target>
• 3: <How_I_Say_It>
• 4: <What_I_Say>

My Input gets jumbled together, into two elements (typical "tell" or "say"), respectively only one element in the case of a simple emote:
Output:

• 1: <Speaking CONTEXT> (who speaks, to whom, how it is said, what happens while speaking, etc...)
• 2: <Spoken CONTENT> (What is being said) - respectively<EMOTE>

... and if "something" deems the entire output to be too long (or unworthy of being repeated?) the whole stuff gets truncated.


My Questions:

• Is there a <maximum length of characters> in total that can be stuffed into a single emote before it is truncated? How long is that?

In the case of the output consisting of the format above (a typical "tell" or "say"):

• Do <Speaking CONTEXT> and <Spoken CONTENT> get summed up for a total maximum of characters to decide whether it gets truncated? If so, how many characters  is that?
• Are <Speaking CONTEXT> and <Spoken CONTENT> evaluated seperately, and have each their own respective maximum lengths? If so, what are those maximums?

EDIT to add: I am assuming that the <OUTPUT Length> Is the deciding factor? Which makes it all a bit more difficult, as "~elf" might get translated into "elf dude", but also "long and slender elf dude with black sunglasses".


I have tried to search these forums, but could not find information on this. Any help would be greatly appreciated. I can't seem to figure this out by myself through trial-and-error.

[Cutthroat]

It's the input that seems to get counted, not the output, since the limit is there not only for talk/tell/say/emote/etc, but for any one line you can put into the game. Like into the text editor for chargen, tdesc, writing, boards, and so on (even though you should break these lines up anyway according to the ruler at the top).

As for max length it's probably somewhere around 275-300 total characters inputted. I never counted, but that's around where it seems to be (probably closer to 300). A coder probably knows the exact number.

[SchroedingersCat]

Ooh, that would be beautiful, Cutthroat. Then I could just arrange the input window according to that maximum number of characters, and see at a glance, when I am getting to the maximum.

Please, someone confirm and tell me the precise maximum number of characters?

[SchroedingersCat]

Further investigations into my logs have showed that - if it is truly the INPUT that is limited, in 6 cases I have the following number of characters (including spaces and -not- including the three dots that are added to indicate the trunkage) after the information "Line too long. Truncated to:"

248, 243, 248, 244, 247, 248;

I assume that the truncating happening only at the end of a word is the reason why the numbers vary a bit. 248 sounds like a very reasonable number to me, to be pleasing to an AI. I know I would like it if I were thinking in in binaries...

[Edit to add: No, on second thought, it would not please me, if I were processing in strict binaries... I'd prefer 256. But who am I to judge what pleases binary processors. My processor is a tangled mess of uncertainties and fuzzynesses]

Current working hypothesis: 248 characters including spaces = maximum input length.

[Delirium]

I was just thinking about this the other day. It'd be great to set up a MUSHclient plugin that catches too-long input for you.

[Fujikoma]

As far as not over-running the buffer, I could be imagining things, but one thing that helps me is when you're performing and emote is to try to throw in the special characters that include words like his/her(yours) instead of say, ~ or % or= after the first designator used in the emote that includes an sdesc, or however the wording make sense to you. There are plenty of excellent opportunities to embarass yourself honing the use of these designators, and the sooner you get used to them, the easier time you'll have. I'm still trying to break atrocious habits I developed when long ago I should have typed help emote and copy/pasted it into notepad for easy reference.

[SchroedingersCat]

[...] one thing that helps me [...] is to try to throw in the special characters that include words like his/her(yours) instead of say, ~ or % or= after the first designator used in the emote that includes an sdesc,[...]

I am not sure if I understand. Are you seeing less overflows when all the references that start with ^,$, 5,%, &, #, or + (like "^me") come -AFTER- first using one of those designators in front of a keyword that is included in a "sdesc"?
That would be truly mysterious...


And in case this question never gets a definite answer: I think Cutthroats theory is accurate: Since I am adhering to the rule of No more than 248 characters into my input window (including whitespaces) I get no more trunkaging - apparently independent of the amount of characters that eventually get printed to the output.

I tested it with an input of 230 characters (input window) with lots of reference to bloat it up to 460 characters (printed to output window) and it still got printed to the output.

Seems to confirm the working hypothesis above.

[Fujikoma]

[...] one thing that helps me [...] is to try to throw in the special characters that include words like his/her(yours) instead of say, ~ or % or= after the first designator used in the emote that includes an sdesc,[...]

I am not sure if I understand. Are you seeing less overflows when all the references that start with ^,$, 5,%, &, #, or + (like "^me") come -AFTER- first using one of those designators in front of a keyword that is included in a "sdesc"?
That would be truly mysterious...


And in case this question never gets a definite answer: I think Cutthroats theory is accurate: Since I am adhering to the rule of No more than 248 characters into my input window (including whitespaces) I get no more trunkaging - apparently independent of the amount of characters that eventually get printed to the output.

I tested it with an input of 230 characters (input window) with lots of reference to bloat it up to 460 characters (printed to output window) and it still got printed to the output.

Seems to confirm the working hypothesis above.

THAT is interesting. I don't know, maybe about the time I started working to reduce the number of sdescs appearing in my emotes I just got better at estimating the number of characters I could use in my emotes a little better. Good to know, thanks.

[Patuk]

The real question not becomes just how long an emote can be if you CRAM it full of lengthy sdescs.

[SchroedingersCat]

The real question not becomes just how long an emote can be if you CRAM it full of lengthy sdescs.

That is what I was trying to achieve with my experiments as mentioned above in my post. I think there is no limit. I crammed it full of ~DUDE references, and a bit of filler text to squeeze at least a little bit of sense inbetween the spam, and achieved 460 characters in the output. I haven't tested with spamming only sdescs, but I am fairly sure it would make no difference.

.. Input is what counts.

[SchroedingersCat]

Current Standing of Experiments:

We have to differentiate between different forms of spamming the output window with walls of texts:

Case 1
If you abuse vNPCs or your virtual surrounding for spamming text walls, (including @ somewhere] OR think that wall of spam silently to yourself, there is a limit of 254 characters (including whitespace) to scram into the input window.

Case 2
If you say something and put lots of spam into the (brackets) to express "how" you say it, and then include another lot of spam into "what" you say, there seems to be a limit of 252 characters (including whitespace] to scram into the input window.
I assume the same number holds true for psi-ing something, but I haven't tested.

Interestingly enough, Case 1 and Case 2 are also different in the form how they deal with this exaggerated expressivity: While too long "think"-ing or ": (...) @ (...)"-spamming just gets cut off, printing what is possible, to long "say"s (Case 2), gets trunkaged with three dots.


My curiousity is sated enough, that I can live with not digging any further into it. I am concluding this highly important and groundbreaking research with the observations that...

• You are on the safe side when you respect the 248 characters limit in the input window.
• You can probably get away with putting no more than 252 characters anywhere in the input window at once.
• You can enjoy the biggest limit I was able to detect with a glorious 254 characters when you bring your environment alive with the ": (...) @ (...)" emote or by thinking something.

... probably. Or maybe not. But it works for me.