> But i think a libary will be a correct solution. No, it doesn't work like that. The constant you've found (MAX_PAKFILES) is something that cannot be modified without recompiling the code that uses it. In this case, you're talking about the ET v2.55 engine code, which is closed source.
Not only that, but I suspect the issue isn't as simple as increasing that constant. Presumably the "illegible server command" messages are a form of overflow that occurs, and probably doesn't relate directly to the MAX_PAKFILES constant since it looks like that is typically much higher than you're reporting. Most likely there is something else that overflows much lower than the MAX_PAKFILES (such as the list of pure pk3s, which overflows at a total string length of 1024 or something). The better fix is as you said, to upgrade to version 2.60b of ET, where it seems they already addressed this issue. If there are fewer players on the newer build (which is presumably "better" judging by the long list of fixes listed in the change history), then perhaps you need to help educate your users that they should switch because it solves problems such as this one. Anthony
_______________________________________________ ioquake3 mailing list [email protected] http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
