03 Dec, 2008, Guest wrote in the 1st comment:
Votes: 0
Hi,
im getting this error in the log file when i try to start up my Rom->quickmud mud, anyone know why?

Wed Dec 3 12:24:23 2008 :: [*****] FILE: chessbrd.are LINE: 19
Wed Dec 3 12:24:23 2008 :: [*****] BUG: Fread_string: MAX_STRING 1413120 exceeded.

i had two areas before this file, removed them both from the area.lst file to see if it would start but its just going to the next area and giving the same message…
03 Dec, 2008, Zeno wrote in the 2nd comment:
Votes: 0
What is line 19 (and lines around it) in chessbrd.are?
03 Dec, 2008, Guest wrote in the 3rd comment:
Votes: 0
#MOBILES
#15800
green pawn~
a green pawn~
A green pawn stands here proudly.
~
A green chess pawn. Tall in stature, and tough in spirit, it fights to
overthrow the evils of the black chess pieces.
(line 19)~
human~
AGHTW CF 777 0
55 6 10d204+1078 55d10+100 5d19+28 none
-24 -24 -24 -7
CEFKN H 0 I
stand stand none 4000
AHMV ABCDEFGHIJK medium unknown
#15801
red pawn~
03 Dec, 2008, Davion wrote in the 4th comment:
Votes: 0
Pretty sure the first 19 lines of a file aren't going to exceed a max_string of 1.4 million ;). You recently add a bunch of areas to your codebase?
03 Dec, 2008, Guest wrote in the 5th comment:
Votes: 0
nope, didnt add any areas, these are the same areas that have been in it for months, unchanged. Only differance is i switched mud hosts.
03 Dec, 2008, Saak wrote in the 6th comment:
Votes: 0
You need to decrease MAX_STRING value in your db.c file.
05 Dec, 2008, Skol wrote in the 7th comment:
Votes: 0
Or maybe 'increase' it to allow it to not exceed the limit ;).
Stock is 1413120.
Try 2097152 // (it's 2 * 1024 * 1024).
05 Dec, 2008, David Haley wrote in the 8th comment:
Votes: 0
Am I the only one bothered by the tiny snippet of an area above exceeding the limit of 1413120?
06 Dec, 2008, Saak wrote in the 9th comment:
Votes: 0
Ohh.. my bad.. sure the word is INCREASE :D

Skol said:
Or maybe 'increase' it to allow it to not exceed the limit ;).
Stock is 1413120.
Try 2097152 // (it's 2 * 1024 * 1024).
07 Dec, 2008, Skol wrote in the 10th comment:
Votes: 0
DavidHaley said:
Am I the only one bothered by the tiny snippet of an area above exceeding the limit of 1413120?

David, not quite sure how it's going there (my memory use understanding could be improved), but isn't it loading in all the areas in one spot? That'd be one _long_ string, especially as you add more and more areas.
07 Dec, 2008, David Haley wrote in the 11th comment:
Votes: 0
I don't think it loads all the areas into a single string. It should be reading the various entries component-by-component into single strings, and storing those into individual area structures.
07 Dec, 2008, Davion wrote in the 12th comment:
Votes: 0
Rom uses a heap allocation for strings. So technically all the strings are really one big string with a \0 delimiter. MAX_STRING refers to the length of that massive hunk of string *catcall*. Assuming that you're actually exceeding the limit, simply increasing MAX_STRING would fix the problem. However, if there's an error somewhere and you're reading massive amounts of data, then increasing it may not be the best thing. Best to first find out the cause (error, or just size) and then fix appropriately.
07 Dec, 2008, Skol wrote in the 13th comment:
Votes: 0
That's what I'd thought Davion.
I'd run into that issue years ago, same reason with adding areas and exceeding the allotted memory.
07 Dec, 2008, David Haley wrote in the 14th comment:
Votes: 0
Oh. Serves me right for thinking that ROM works like SMAUG does. It seems to be kind of weird to put a limit on the number of allowed strings, though…
0.0/14