coding question

Hello!

I'm rather new to the coding scene...so please forgive me if this comes across as a stupid question...

I'm running a slightly modified SWR11FUSS...i say slightly, but its converted now over to C++ instead of C...at any rate...my question is this:

With mobprogs, roomprogs, objprogs and notes/disks...when you do something such as this:

mpedit whatever add speech test

(open buffer)
'This is the beginning of the mobprog tutorial course. Once you feel that you have mastered the training, please feel free to move on to the advanced mobprog tutorial area and see what you can see.
(close buffer)

Once you fire the program by saying 'test' you'll get this:

Whatever says, 'This is the beginning of the mobprog'

Once you go into the program do a /l, you'll see this:

1>'This is the beginning of the mobprog tutorial course. 2>Once you feel that you have mastered the training, please 3>feel free to move on to the advanced mobprog tutorial 4>area and see what you can see.

what I *want* is for this:

1>'This is the beginning of the mobprog tutorial course. Once you feel that you have mastered the training, please feel free to move on to the advanced mobprog tutorial area and see what you can see.
2>

So that way when you fire the trigger, you get the entire message instead of having to try to count out the 74 characters to a line. It just seems like it'd be much, much easier for the builders and would give a little bit more freedom with maneuvering. How would you cause notes and the different programs to read beyond the newline character?


Now, I've messed around in comm.cpp and tweaked with the line-length and such, changed it from 256 to 1024 so that the players can pretty much emote or say or whatever away without having to see the "Line too long" message. Anyhow, in doing this, I came across the function at around line 980 that looks like this:


for( i = 0; d->inbuf[i] != '\n' && d->inbuf[i] != '\r' && i < MAX_INBUF_SIZE; i++ )
{
if( d->inbuf[i] == '\0' )
return;
}

/*
* Canonical input processing.
*/
for( i = 0, k = 0; d->inbuf[i] != '~' && d->inbuf[i] != '\r'; i++ )
{

if( k >= 1024 )
{
write_to_descriptor( d, "Line too long.\n\r", 0 );

/*
* skip the rest of the line
*/
/*
* for ( ; d->inbuf[i] != '\0' || i>= MAX_INBUF_SIZE ; i++ )
* {
* if ( d->inbuf[i] == '\n' || d->inbuf[i] == '\r' )
* break;
* }
*/
d->inbuf[i] = '\n';
d->inbuf[i + 1] = '\0';
break;
}


Now...being inquisitive, I started asking around and learned that one would have to change the newline character to a tilde character, then install the smash-tilde function if it were not already installed. As can be seen, I changed the newline to a tilde...this is where I'm rather stumped. I know that what I'm doing *can* be done. When I've tweaked with it a little farther, I got it to almost working like I wanted to...leastways it didn't chop off at the end of line one. Unfortunately, it looked ugly since it was just reading line after line after line and then it started giving "Missing endif" errors on all mobs with progs...which is annoying since the endif was definately there.

Any assistance...preferably what I should change and how...would be highly appreciated...but just a tip to give a nudge in the proper direction would be completely spiffy.

Lots and many thanks!

Kerrias
aka
Jessica

What client are you using? Is this simply a display issue?

No, what its doing is assigning each line of the program to it's own line:
1>'This is the beginning of the mobprog tutorial course.

2>Once you feel that you have mastered the training, please

3>feel free to move on to the advanced mobprog tutorial

4>area and see what you can see.

What I want it to do is to do this:

1>'This is the beginning of the mobprog tutorial course. Once you feel that you have mastered the training, please feel free to move on to the advanced mobprog tutorial area and see what you can see.

2>

That way, the object or mob in question will say or emote or mpecho everything that you wanted it to, up to the predefined max-buffer size, without so much as a hiccup. As it sits, when you fire a mobprog that has the before-mentioned setup, you'd get this:

You say 'Test.'

Whatever says, 'This is the beginning of the mobprog tutorial course. '

and the rest is forever lost to the netherworld that is coding.

And by the way, Mr. Gammon, thanks for making such a marvelous product such as MUSHClient available for us to use. I've been an avid user of it for my entire mudding life and reccomend it to everybody that I come across.

Could this be a client issue, where the client is breaking up the long line into several lines?

It could also be the mudprog, or something else, that is line-wrapping things to be of the right width. To be honest I haven't looked at that code in such a long time that I don't really remember. :-)

See, that's what I'm saying, Mr. Haley...everybody's client is going to be a little different with the wordwrap making it fit on the screen and such. Rather than trying to write up an entire TCP/IP config thingy to set it at a constant, it seems to me that it'd be easier to make it read as one-line until it hits a tilde. I've played games before where the next line in the program/note didn't happen until it ran out of space in the buffer or the user hit enter...thats what i'm trying to get...lemme copy paste what I mean from the mud instead of from memory...

speech_prog test
'This is the first line of the mobprog. I want this to continue until I
hit enter, but it won't. It'll chop off somewhere, no matter what I try
to do...and it really hurts my feelings that it does that. I wish that it
wouldn't but it does and now I'm going to cry because I cant figure this
stupid thingy out. Please help meeee!
cry

now, aside from the line wrapping and such, that was all one consecutive line...when triggered, it does this:

You say 'test'
A nurse droid says 'This is the first line of the mobprog. I want this to continue until I'
A nurse droid bursts into tears.


Now, the reason that it's chopping off at that point is this:

Begin entering your text (/? =help /s =save /c =clear /l =list /f =format)
--------------------------------------------------------------------------
>
/l
------------------
1> 'This is the first line of the mobprog. I want this to continue until I
2> hit enter, but it won't. It'll chop off somewhere, no matter what I try
3> to do...and it really hurts my feelings that it does that. I wish that it
4> wouldn't but it does and now I'm going to cry because I cant figure this
5> stupid thingy out. Please help meeee!
6> cry
------------------

when what I'm trying to get it to do is wait for the carriage return to insert a newline...ok, maybe that's not the right word...but I want this to happen:

1>THis line will go on until the user presses enter. When the user presses enter, it will continue to the new line.

2>True, there was more than one line before, but you notice now the code is reading as line 2 here...I only want that to happen when the user hits enter or runs out of buffer space...which in my mud is set to 1024...shouldn't ever run out.


Honestly, I don't know if I'm making any sense to anybody but me...lordy I hope it makes sense to somebody else, though...preferably somebody what can tell me how to fissit.

Well, I guess what I meant is that we first need to isolate the point at which the one-line of typed input is getting turned into several lines for the MUD. I see these possibilities:

- you type one line in the client, but it breaks it up into several lines (somewhat unlikely, to be honest, because that could induce simply incorrect behavior in many cases)
- you type one line, and the MUD reads it as one line, but the MUD prog formatter line-wraps the program for you
- you type one line, it gets saved as one line, but when it gets written to disk and comes back, it gets line-wrapped (unlikely, because then it would be working for you the first time around)


From memory, the MUD input routines don't do any line-wrapping, but will cut off lines at something like 256 characters, giving you an error about lines too long.

But you don't seem to be hitting that limit; rather, something is line-wrapping your input.

I suspect that the culprit is MUD prog automatic formatting, doing linewrapping and stuff. But I don't know why somebody thought that was a good idea.

When I get home tonight I'll take a look at the code and see what might be going on; I don't have easy access to the code at the moment.

I think I see what you are getting at here.

You are trying to type in a long line in the MUD editor, so it wraps at the client end (like MUSHes do), rather than pre-deciding where the line breaks are to go.

I don't think we need to get too bogged down in discussions about tildes and buffer sizes. I suspect the internal editor is designed to limit lines to around 80 characters.

I'm not sure if there is a heap of point in doing it, as in SMAUG areas room description generally wrap at column 80 anyway, so trying to cater for shorter or longer lengths will not achieve much, as most people would need to set their client to show around 80 columns anyway.

In the SMAUG Area Editor (available on this site) I had a feature where you could just type in a paragraph "naturally" and then get it to wrap at column 80 for you when outputting the description. This let you more easily compose descriptions without having to add line breaks everywhere, although they got put in eventually.

there was a snippet out for smaug that had an editor that works like you are trying to do, you might want to check it out.

http://cronel.mube.net/code.shtml

editor.0103.tgz
13.87kb
New editor code
This code replaces the stock SMAUG editor by a new one that is less restrictive and a bit more flexible.
(Version 0.103).
Author: Cronel

As far as I remember you could type very very long lines in the editor, and they would stay on one line. So if you figure out how they did it you should be able to convert it over to yours.

...ok, the max-characters/line used to be 256...you can change that in comm.cpp to whatever, in my case I changed it to 1056. That applies to notes, mobprogs, emotes, whatever else.
Mr. Gammon, my problem isn't with the word-wrap in descriptions and what have you...it's the mob-progs and such, as previously stated. It just really makes me want to shave my head and call myself fluffy to have to build things like,
mpechoat $n Input text line here, but be careful
mpechoat $n because when you are not careful then
mpechoat $n you wind up with something like this

which outputs

Input text lines here, but be careful
Because when you are not careful then
You wind up with something like this.

call it my own little anal-self, I guess...but that just looks really really ugly, not to mention frustrating for a builder when you go through the hassle of trying to write a nice complex mobprog, get 18 lines in then go back and notice that it chopped off half of line 7 due to the word wrap...

really this is just a convenience thing that i'm looking at here...nothing earth-shattering, I guess.