Descriptive Problem Summary:
error: maximum number of text strings exceeded (65535)
Numbered Steps to Reproduce Problem:
Try to compile a big project
Expected Results:
Normal compilation
Actual Results:
build fail
When does the problem NOT occur?
When using a small map
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
No one works
Sometimes the project compiles under linux, 1 in 15, for example. Before updating to latest version it was just giving segmentation fault error, and now it gives this. So is this an over to Byond to making a really big games? To compile my project I've had to disable a numerous of features, but it makes the progress of development of project to stop.
ID:1315764
 Jul 6 2013, 10:35 am
|
|||||||||||||
Resolved
| |||||||||||||
On windows I have 499.1199, and on Linux 499.1197.
I think 500.xxxx aren't avaible to public, so I don't know about that. Also updated the main post with some workarounds | |
If you have 65,535 bare text strings you are doing something wrong. Consider that the PE file format, used on Windows, only allows ~2**32 bytes worth of global variables (well, technically, stuff in the .data section. Which is where globals are stored). If that's all strings, that's 65535 strings of 65535 bytes each. So actually not that much larger than BYOND's limit.
| |
That really is a lot of strings; it suggests you're using a lot of repetitive text with just minor changes, where a template-based approach would be better. E.g., "You are \a [classname]" vs. "You are a warrior" is a better way to go. I would suggest there are probably many ways you can trim down your project by reducing a lot of complexity and repetitive code. Obviously you're probably doing that for a lot of simple cases, but I bet there are cases you haven't considered that are similar, where perhaps it seemed easier to hard-code the string rather than, say, use a proc to generate it as needed. Your map is pushing it over the limit, but it has to be pretty close to the limit to begin with for that to be an issue. Eternia, a fairly large project, was used to test some recent compiler changes, and it only used around 13K strings, about 1/5 of the limit.
All that said, while I'm sure there are ways you can optimize your string load away, ultimately someone's going to need to pass the 64K limit. BYOND 500 does have this planned. The code that's capable of compiling this is actually in newer 499 builds, but because earlier 499s aren't capable of reading this DMB format, the limits are still in force until the next build. | |
You actually want to keep below 65280 strings, any reference to a string with an ID above that will cause the interpreter to die in a fire
| |
Also for reference SS13 (tg) used 52k or so when I last checked in dec. 2012, you're probably doing something very wrong (a lot of their strings were from stuff such as ion laws, which contained like 10 rediclously big pick()s)
| |
Tobba wrote:
You actually want to keep below 65280 strings, any reference to a string with an ID above that will cause the interpreter to die in a fire The limit really is 65535, but you may be seeing lower in your own projects because type paths and other factors contribute to string usage. | |
If a string goes above FF00 it confuses the decoding of instructions like get (unless theres a special thing to deal with that)
| |
get/set/etc is has its args encoded like
D3 FF (use src) F3 00 (string ID) Dont quote me on that D3 number, I cant check what it actually is now There are like 10 of those codes specifying different things | |
I have a new note to add to this report. One thing I did not notice when increasing compile-time string capacity in BYOND was the var encoding scheme, which uses special reserved string IDs and expects no compile-time strings to ever exceeed that value. By adding a shim for those cases to the compiler, and matching changes at runtime, I believe those cases should be settled.
| |
Lummox JR resolved issue with message:
Games with very large numbers of strings could have problems accessing certain variables at runtime. The compiler has been fixed so that any such conflicts are handled properly. Games that rely on this fix will need to run in the newest version. | |
There was a recent new feature which did something to expand the compile-time limit of things for large projects. This feature will be fully...implemented in BYOND 500, or something.
However, there is definitely ways to get around this. In a professional developing environment; you rarely ever hardcode strings. You'd use some XML (or even savefiles in DM's case) and keep the strings in an external file.