30 Jan, 2010, Crelin wrote in the 1st comment:
Votes: 0
Well here's my new problem, a new area has been being worked on and when I went to copyover, the mud wouldn't come back up with the error
Sat Jan 30 11:30:47 2010 :: [*****] FILE: tinka.are LINE: 947
Sat Jan 30 11:30:47 2010 :: [*****] BUG: Fread_string: MAX_STRING 1413120 exceeded.

this error has nothing to do with the tinka.are file specifically, just that is the particular file it stops in when MAX_STRING is exceeded (i.e., I can reorder my areas and it'd show the bug in a different file). This confuses me quite a bit as well…we don't have that many areas and I've seen rom muds with a hell of a lot more areas and hell of a lot more strings…so why has mine maxed so quickly and what can I do about it? is there a way to change the max or can I just bypass the check or what?


Edit: For now I've just removed some stock areas I'm not using and that's freed up enough strings for now. However I'm still perplexed as to how the string limit was exceeded so quickly and if there's anything else I can do about this in the future.
30 Jan, 2010, Skol wrote in the 2nd comment:
Votes: 0
Crelin, in db.c find MAX_STRING.
IE Mine is:
#define			MAX_STRING	9437184// 9*1024*1024 (on 11/01/09)

I'd try 2097152 //(2 * 1024 * 1024)
Or 3* or 4* etc.

Basically you ran out of space to store all the areas. Rom makes a big massive string, your area pushed it off of the end.
30 Jan, 2010, Davion wrote in the 3rd comment:
Votes: 0
There's a lot of useful information in this previous thread about this exact problem if you want to know more about it.

[link=post]37050[/link]
30 Jan, 2010, Crelin wrote in the 4th comment:
Votes: 0
awesome, ty both….yeah, my biggest fear was that changing max_string could muck something up somewhere so I wanted to double check here first (that and I was looking for the max_string define in the .h files).
0.0/4