গবেষণা সিদ্ধান্ত: দুটি সীমাই কাঠামোগত

অনলাইন প্লেয়ার সীমা = ২৫৫ (প্রোটোকল বিট-প্রস্থ হার্ড কনস্ট্রেইন্ট)

অবস্থান	বিষয়বস্তু
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 (২৫১-২৯৬ লাইন) ও ডিসিরিয়ালাইজেশন (৪২২-৪৩২ লাইন) এ ট্রান্সমিট হয়
src/table/settings/network_settings.ini:241	network.max_clients (SLE_UINT8, max = MAX_CLIENTS, ডিফল্ট ২৫)
src/network/network_server.cpp:360	গ্রহণ শর্ত _network_clients_connected < MAX_CLIENTS

সিদ্ধান্ত: ২৫৫ ইতিমধ্যেই uint8 প্রোটোকল ফিল্ডের উপরের সীমা।突破 করতে clients_max ইত্যাদি সম্পর্কিত ফিল্ড uint16-এ পরিবর্তন করতে হবে——এটি client↔server অনলাইন প্রোটোকল, UDP ব্রডকাস্ট ও গেম কোঅর্ডিনেটর (Game Coordinator) প্রোটোকল পরিবর্তন করবে, যা বাহ্যিক প্রোটোকল পরিবর্তন (ফর্কের মধ্যে উভয় প্রান্ত একসাথে আপগ্রেড করলে খেলা যাবে, কিন্তু পাবলিক সার্ভার তালিকা সামঞ্জস্য প্রভাবিত হবে)।

কোম্পানি সংখ্যা সীমা = ১৫ (টাইল ওনার স্টোরেজ ফরম্যাট হার্ড কনস্ট্রেইন্ট)

অবস্থান	বিষয়বস্তু
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()) —— টাইল ওনার শুধু ৫ বিট সংরক্ষণ করে (_m[].m1-এর নিম্ন ৫ বিট)
src/company_type.h:30-33	OWNER_TOWN{0x0F}, OWNER_NONE{0x10}, OWNER_WATER{0x11}, OWNER_DEITY{0x12}, OWNER_END{0x13} কোম্পানি ID-এর সাথে একই বাইট স্পেস ব্যবহার করে

সিদ্ধান্ত: Owner ও CompanyID একই টাইপ, টাইল মালিকানা ফিল্ড শুধু ৫ বিট (মান ০-৩১), যার মধ্যে ১৫-১৮ বিশেষ ওনার দ্বারা দখলকৃত। তাই প্রকৃত কোম্পানি সীমা ১৫ ম্যাপ অ্যারে ফরম্যাট দ্বারা নির্ধারিত——突破 করতে টাইল ওনার স্টোরেজ বাড়াতে হবে (m1 সম্পূর্ণ ৮ বিট বা _m গঠন পরিবর্তন) এবং OWNER_* কনস্ট্যান্ট মাইগ্রেট করতে হবে, যা সম্পূর্ণ存档 রূপান্তর ও ম্যাপ মেমরি বৃদ্ধি জড়িত, একটি বড় ফরম্যাট পুনর্গঠন (OpenTTD আপস্ট্রিম বহু বছর ধরে এটি করেনি, এটাই কারণ)।

বিকল্প পরিকল্পনা

পরিকল্পনা	পরিবর্তন	সামঞ্জস্য	পরামর্শ
A. বর্তমান অবস্থা বজায় রাখা	কিছু না	存档/প্রোটোকল/কোঅর্ডিনেটর সম্পূর্ণ সামঞ্জস্যপূর্ণ	✅ প্রস্তাবিত: ২৫৫ ক্লায়েন্ট / ১৫ কোম্পানি মাল্টিপ্লেয়ারের জন্য মূল সংস্করণের চেয়ে অনেক বেশি
B. ক্লায়েন্ট → uint16 প্রোটোকল	network_game_info.cpp সিরিয়ালাইজেশন/ডিসিরিয়ালাইজেশন Send_uint16/Recv_uint16 এ পরিবর্তন; MAX_CLIENTS ৪০৯৫ পর্যন্ত বাড়ানো; network_settings.ini-এর max_clients SLE_UINT16 করা; settings_type.h ফিল্ড uint16 করা; console_cmds.cpp:1056 প্রদর্শন প্রস্থ	ফর্কের মধ্যে উভয় প্রান্ত খেলা যাবে; পাবলিক কোঅর্ডিনেটর/পুরনো ক্লায়েন্ট সামঞ্জস্যপূর্ণ নয়	ঐচ্ছিক, যদি সত্যিই >২৫৫ ক্লায়েন্ট প্রয়োজন হয়
C. কোম্পানি → টাইল ফরম্যাট পুনর্গঠন	টাইল ওনার ফিল্ড প্রশস্তকরণ + OWNER_* কনস্ট্যান্ট মাইগ্রেশন + সম্পূর্ণ存档 রূপান্তর	存档 ফরম্যাট পরিবর্তন (একবার রূপান্তর)	স্বল্পমেয়াদে বাস্তবায়নের পরামর্শ দেওয়া হয় না

ইতিমধ্যে বিতরণকৃত বিষয়বস্তু

• এই ডিজাইন ডকুমেন্ট (সঠিক ফাইল/লাইন নম্বর সহ);
• ঐচ্ছিক প্যাচ option-clients-uint16.diff (পরিকল্পনা B-এর সম্পূর্ণ পরিবর্তন, প্রয়োগ করা হয়নি, git apply পর্যালোচনার জন্য)।

সিদ্ধান্ত আগেই: দুটি সীমার "বিস্তার" মূলত ফরম্যাট/প্রোটোকল আপগ্রেড, কনফিগারেশন আইটেম সমন্বয় নয়;存档 ও পাবলিক নেটওয়ার্ক সামঞ্জস্য বজায় রেখে বর্তমান ২৫৫/১৫-ই সীমা। যদি সামঞ্জস্য ব্যয় গ্রহণ করা হয়, তাহলে পরিকল্পনা B/C-এর পরিবর্তন পদ্ধতি উপরে দেওয়া হয়েছে।