अनुसंधान निष्कर्ष: दोनों सीमाएँ संरचनात्मक हैं

ऑनलाइन खिलाड़ी सीमा = 255 (प्रोटोकॉल बिट-चौड़ाई कठोर बाधा)

स्थान	सामग्री
src/network/network_type.h:21	static const uint MAX_CLIENTS = 255;
src/network/network_type.h:54	ClientPoolIDTag : PoolIDTraits<uint16_t, MAX_CLIENTS + 1, 0xFFFF>
src/network/core/network_game_info.cpp	clients_max / companies_max को Send_uint8 / Recv_uint8 के माध्यम से SerializeNetworkGameInfo (पंक्तियाँ 251-296) और डिसीरियलाइज़ेशन (पंक्तियाँ 422-432) में प्रेषित किया जाता है
src/table/settings/network_settings.ini:241	network.max_clients (SLE_UINT8, max = MAX_CLIENTS, डिफ़ॉल्ट 25)
src/network/network_server.cpp:360	प्रवेश निर्णय _network_clients_connected < MAX_CLIENTS

निष्कर्ष: 255 पहले से ही uint8 प्रोटोकॉल फ़ील्ड की ऊपरी सीमा है। इसे तोड़ने के लिए clients_max और संबंधित फ़ील्ड को uint16 में बदलना होगा — यह क्लाइंट↔सर्वर ऑनलाइन प्रोटोकॉल, UDP प्रसारण और गेम कोऑर्डिनेटर (Game Coordinator) प्रोटोकॉल को बदल देगा, जो एक बाहरी प्रोटोकॉल परिवर्तन है (fork के अंदर दोनों छोर एक साथ अपग्रेड कर सकते हैं, लेकिन सार्वजनिक सर्वर सूची संगतता प्रभावित होगी)।

कंपनी संख्या सीमा = 15 (टाइल owner भंडारण प्रारूप कठोर बाधा)

स्थान	सामग्री
src/company_type.h:25	CompanyIDTag : PoolIDTraits<uint8_t, 0xF, 0xFF> → MAX_COMPANIES = CompanyID::End().base() = 15
src/tile_map.h:195	SetTileOwner: SB(_m[tile].m1, 0, 5, owner.base()) — टाइल owner केवल 5 बिट संग्रहीत करता है (_m[].m1 के निचले 5 बिट)
src/company_type.h:30-33	OWNER_TOWN{0x0F}, OWNER_NONE{0x10}, OWNER_WATER{0x11}, OWNER_DEITY{0x12}, OWNER_END{0x13} कंपनी ID के साथ समान बाइट स्थान साझा करते हैं

निष्कर्ष: Owner और CompanyID एक ही प्रकार हैं, टाइल स्वामित्व फ़ील्ड केवल 5 बिट (मान 0-31) है, जिसमें से 15-18 विशेष owner द्वारा उपयोग किए जाते हैं। इसलिए वास्तविक कंपनी सीमा 15 मानचित्र सरणी प्रारूप द्वारा निर्धारित है — इसे तोड़ने के लिए टाइल owner भंडारण का विस्तार करना होगा (m1 के सभी 8 बिट या _m संरचना बदलना) और OWNER_* स्थिरांकों को स्थानांतरित करना होगा, जिसमें पूर्ण सेव रूपांतरण और मानचित्र मेमोरी वृद्धि शामिल है, जो एक बड़ा प्रारूप पुनर्गठन है (यही कारण है कि OpenTTD अपस्ट्रीम ने वर्षों से ऐसा नहीं किया है)।

वैकल्पिक समाधान

समाधान	परिवर्तन	संगतता	सुझाव
A. यथास्थिति बनाए रखें	कोई नहीं	सेव/प्रोटोकॉल/कोऑर्डिनेटर पूर्ण संगत	✅ अनुशंसित: 255 क्लाइंट / 15 कंपनी मल्टीप्लेयर के लिए मूल संस्करण से पहले से कहीं अधिक है
B. क्लाइंट → uint16 प्रोटोकॉल	network_game_info.cpp सीरियलाइज़ेशन/डिसीरियलाइज़ेशन में Send_uint16/Recv_uint16; MAX_CLIENTS को 4095 तक बढ़ाएं; network_settings.ini में max_clients को SLE_UINT16 करें; settings_type.h फ़ील्ड को uint16 करें; console_cmds.cpp:1056 प्रदर्शन चौड़ाई	fork के अंदर दोनों छोर चल सकते हैं; सार्वजनिक कोऑर्डिनेटर/पुराने क्लाइंट संगत नहीं	वैकल्पिक, यदि वास्तव में >255 क्लाइंट की आवश्यकता हो
C. कंपनी → टाइल प्रारूप पुनर्गठन	टाइल owner फ़ील्ड चौड़ा करें + OWNER_* स्थिरांक स्थानांतरण + पूर्ण सेव रूपांतरण	सेव प्रारूप परिवर्तन (एकमुश्त रूपांतरण)	अल्पावधि में कार्यान्वयन की अनुशंसा नहीं

वितरित सामग्री

• यह डिज़ाइन दस्तावेज़ (सटीक फ़ाइल/पंक्ति संख्या सहित);
• वैकल्पिक पैच option-clients-uint16.diff (समाधान B का पूर्ण परिवर्तन, लागू नहीं, git apply समीक्षा के लिए)।

निष्कर्ष पहले: दोनों सीमाओं का "विस्तार" मूल रूप से प्रारूप/प्रोटोकॉल अपग्रेड है, न कि कॉन्फ़िगरेशन आइटम समायोजन; सेव और सार्वजनिक नेटवर्क संगतता बनाए रखने के लिए, वर्तमान 255/15 सीमा है। यदि संगतता लागत स्वीकार्य है, तो समाधान B/C के परिवर्तन ऊपर दिए गए हैं।