11 Mar, 2010, Hades_Kane wrote in the 1st comment:
Votes: 0
Has anyone written a format string function that will keep double line breaks intact while otherwise maintaining regular formatting and would be willing to share? (preferably with color codes not being counted toward the 80 character width of a line)

To be more specific, I could type

This is a line of text and I am writing this to complete my sentence.
But, if I put a line break here
and then continue typing, this is what everything will look like. Let's make this sentence really long too! Yay!


and then format, it would still come out as:
This is a line of text and I am writing this to complete my sentence.  But,
if I put a line break here and then continue typing, this is what everything
will look like. Let's make this sentence really long too! Yay!


But something like this:
This is a line of text and I am writing this to complete my sentence.
But, if I put a line break here
and then continue typing, this is what everything will look like. Let's make this sentence really long too! Yay!

But I double space and keep typing, blah blah blah, and yay!
But then I type this.
And then I make a really long line and try to make it wrap past the 80 characters and what have you. MUDs are text based usually. Woo!


This is a line of text and I am writing this to complete my sentence.  But,
if I put a line break here and then continue typing, this is what everything
will look like. Let's make this sentence really long too! Yay!

But I double space and keep typing, blah blah blah, and yay! But then I type
this. And then I make a really long line and try to make it wrap past the 80
characters and what have you. MUDs are text based usually. Woo!


Anyone have anything like this already?

Thanks!
11 Mar, 2010, Davion wrote in the 2nd comment:
Votes: 0
I never bothered writing code to support this ;). Instead I created a colour code ({n) which outputs a new line. It'll be immune to .f as it's just another colour code.
11 Mar, 2010, ATT_Turan wrote in the 3rd comment:
Votes: 0
Davion said:
I never bothered writing code to support this ;). Instead I created a colour code ({n) which outputs a new line. It'll be immune to .f as it's just another colour code.


This. Except mine is {/ and is therefore inherently cooler.
11 Mar, 2010, Skol wrote in the 4th comment:
Votes: 0
There's a replacement part of string.c out there that does allow double returns to stay intact. Try in the diku/merc/rom/snippets I believe.
11 Mar, 2010, Hades_Kane wrote in the 5th comment:
Votes: 0
Skol said:
There's a replacement part of string.c out there that does allow double returns to stay intact. Try in the diku/merc/rom/snippets I believe.


I combed through some of the snippets last night, but admittedly I did so through a search for "format" so maybe I missed it.

I'll look some more, thanks!
11 Mar, 2010, Hades_Kane wrote in the 6th comment:
Votes: 0
I did a more extensive look and didn't come up with anything.

This is obviously not a big deal, just something I think would make more sense to allow for smarter formatting, and unfortunately string manipulation is one of my weaker skill sets, so any help would still be appreciated.

I do have the {/ = new line thing, but if possible I'd rather have the function support it without having to resort to that.
12 Mar, 2010, ATT_Turan wrote in the 7th comment:
Votes: 0
It's definitely possible, but I wouldn't consider it a very steep "resort" if your code already supports one option :smile: After all, how often do you have multiple paragraphs worth of room description that you think people will actually read?
12 Mar, 2010, Kline wrote in the 8th comment:
Votes: 0
edit: Wrong thread, sorry!
12 Mar, 2010, Skol wrote in the 9th comment:
Votes: 0
I'll post mine up tomorrow if I get to it HK.
12 Mar, 2010, Runter wrote in the 10th comment:
Votes: 0
ATT_Turan said:
It's definitely possible, but I wouldn't consider it a very steep "resort" if your code already supports one option :smile: After all, how often do you have multiple paragraphs worth of room description that you think people will actually read?


Help files, message boards, etc etc often interface with the same format function. It's more likely that people would read those multiple paragraphs there when it's explaining functionality or immortal announcements. :p
12 Mar, 2010, Hades_Kane wrote in the 11th comment:
Votes: 0
Runter said:
ATT_Turan said:
It's definitely possible, but I wouldn't consider it a very steep "resort" if your code already supports one option :smile: After all, how often do you have multiple paragraphs worth of room description that you think people will actually read?


Help files, message boards, etc etc often interface with the same format function. It's more likely that people would read those multiple paragraphs there when it's explaining functionality or immortal announcements. :p


What Runter said! It's actually more for player usage than immortal usage really, and the more user friendly I can make things for the players in that way, the better :)

Another poster emailed me some code that looks like it should help, I'll report on my success when I get home and have time to toy with it.
12 Mar, 2010, ATT_Turan wrote in the 12th comment:
Votes: 0
Good call, actually. I don't use it for help files, but I do use the same editor for message boards and character descriptions, and since the line feed code isn't advertised knowledge to players I can understand better now why someone would want the functionality you're looking for.
18 Mar, 2010, Hades_Kane wrote in the 13th comment:
Votes: 0
I meant to post this a few days ago. The code the other poster sent me seems to be working pretty good and as I was hoping. There are some quirks with what it decides to leave and what it doesn't, but we'll get it customized to fit what we need.

Thanks for the help!
02 May, 2010, Oliver wrote in the 14th comment:
Votes: 0
Hades_Kane said:
The code the other poster sent me seems to be working pretty good and as I was hoping.


Any chance this code could be sent to me? I've been having a problem or four with that function also.
02 May, 2010, Mudder wrote in the 15th comment:
Votes: 0
I'm interested too. Perhaps put it for upload and link it in this thread?
15 Jun, 2010, Oliver wrote in the 16th comment:
Votes: 0
I'm going to bump this thread!

I've looked over it again and I would really appreciate some help from anyone with this problem. A new and improved format_string() function in the repository could be helpful to a lot of people, I think.

The magickery involved in the original function has eluded my thoroughly mediocre code-fixingexpertise.
15 Jun, 2010, Hades_Kane wrote in the 17th comment:
Votes: 0
I would be happy to help if it were my code… You might send bbailey a private message and ask him if you could have it since that's where I got it.
15 Jun, 2010, Oliver wrote in the 18th comment:
Votes: 0
With a little bit of digging, I actually found a fixed version of the code in a set of code in the repository. It's not labeled as an improvement to the format code. Later today, I'll upload the snippet with credit to its authors.

I'll link it here after I've done that, seeing as how it seems like more people than just I have had problems with the stock OLC function.
16 Jun, 2010, Runter wrote in the 19th comment:
Votes: 0
Some code I wrote to do it recursively. Need to be cleaned up some, but it gets the job done.

http://codepad.org/aqZBsvKd
16 Jun, 2010, Runter wrote in the 20th comment:
Votes: 0
And just for the heck of it here is the same thing in Ruby.

http://codepad.org/EVjZ8yt4
0.0/24