First I would like to request a reference entry for all the limitations of BYOND, such as 65535 lists, 65535 objects, and so forth. But since I know that will require a software update, and I can't wait that long, I was wondering if anyone could help me out in listing all the known BYOND limitations? Specifically important are:
* how many items in a list
- whether associations make any difference
* how many variables on any one given atom
- whether the amount of variables on atom and atom/movable are calculated differently
* how many variables in the game at once
* how many procs running at once
Any help would be greatly appreciated.
~Polatrite~
ID:135051
![]() Apr 13 2005, 6:07 pm
|
|
![]() Apr 13 2005, 10:05 pm
|
|
Sounds like a job for the Bwicki.
|
proc/testLists() |
Well, I noticed that even if you can access them all by typing it in the pink bar, Byond won't show more than 200 options in a popup menu.
|
I actually ran my own tests last night because nobody responded within an hour. I found that I could go up to 900k, so no fear of the problems there. Another question I had: how many images can exist at once?
~Polatrite~ |
The more fun test would be to see how many variables can be hard-coded onto one object. The only way I can think of would be to generate, during thousands of iterations, BYOND code code files with increasingly large numbers of variables piled onto a datum, then a mob, then an obj, etc. Each would be in turn run, compiled, and the log file would be checked to see if it returned any BYOND bugs. I'd go up to about 10k or to the point of bugging, because 10k hard-coded variables is a lot!
If there are known limits, a posting of them would be really nice though. -LoW |
In [link], Dan said that lists could store 2^32 members, but there could be memory problems before that happened. An associated list would have a smaller number of members because the objects which can be keys are limited. I'm guessing that the limit would be somewhere around 65535 times the number of key types.
I'm not sure about the variables. I'm curious too. |