Repository navigation
Conversation
Math, Core, IO, Scene, Physics and Platform units the AI library needs, plus the GameLogic/GameEvents AI call sites (collision-handler and radio-courier reports, CombatArea AI queries, PortalEvent, DropVehicleEvent producer). Minimal hunks only; Polynom.h keeps its libstdc++ licence notice. goUpInPath restores the leading slash it strips, as the ELF does; on Windows only when the path had one, because isPathAbsolute also accepts drive paths there. The Linux plugin loader calls deinitDll before dlclose so a map reload cannot reuse stale AI singletons ([CHOSEN, not recovered], a native-port design). The RendDX9 and bf2_runtime_pair manifests link the units the recovered Math code now needs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: OpenAI Codex <noreply@openai.com>
All 10,961 in-scope libaidll.so functions of BF2 1.50, recovered from the ia-32 ELF with amd-64 and PE cross-checks; evidence vocabulary as in AGENTS.md ([INFERRED], [UNRESOLVED], [PLATFORM], [CHOSEN, not recovered]). Chosen declarations exist only for never-implemented pure slots and null-only member pointers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: OpenAI Codex <noreply@openai.com>
…rary One AIDLL source manifest, Code/Build/aidll_sources.txt, feeds both CMake and aidll.cmd. It lists the units in the retail link order, which is also the static-initialisation order, read from the .ctors table of libaidll.so. The engine image excludes every AIDLL-only unit by a directory rule (AI/AIDLL minus the shared CommonSingletonServer, plus three units outside it), so bf2_w32ded.exe never links them. syntaxcheck.cmd covers every AI unit. The linux-x64 preset builds a native libaidll.so with an export map (AidllAbi); this native library is a native-port design, not retail. AIDLL test fixtures are updated for the retired stops. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: OpenAI Codex <noreply@openai.com>
The engine's instance (bf2 ds:0x8ABBCB0) was declared under the [CHOSEN] name g_random and defined in ParticleTemplate.cpp; the AI DLL's (libaidll BSS 0x4DD454) as Rand in Random.cpp. Both retail images name it dice::hfe::Rand and initialise it in Random.cpp's static init (bf2 0x83CB610, libaidll 0x48A850: iostream Init, then the default seed). Random.h now declares one extern Random Rand; Random.cpp defines it for each image; every g_random use is renamed (mechanical, no behaviour change). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-Authored-By: OpenAI Codex <noreply@openai.com>
The getter returned a fixed 2 ahead of its own logic, and the console setter raised every value below 2 to 2 in release builds, so a server could never start a round with a single player: the client kept showing "The game will start when 1 more player(s) join" even with sv.numPlayersNeededToStart 1 and bots on the map. Retail does neither. The bf2 ELF getter (080BC1F0) returns 6, or 8 from 33 slots up, on ranked servers and the configured value otherwise; the console SET is a raw field write. Both functions now match that. Validated on the Windows x86 dedicated server with the retail 1.50 client: with sv.numPlayersNeededToStart 1 the round starts on the first human spawn and the bots join the round. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The x86 server gets CBF2VoipServer from the separate BF2VoipServer_w32ded.dll (bf2_voipserver, defined only for x86, .def with x86 decorated names). The x64 dedicated server had no definitions, so its strict link failed. Add the voice-server sources to it, as the Linux image already does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5ddf524 to
86d73bf
Compare
|
Hell yeah, nice work! Seems like you've had your hands full! Did you have aidll_r.dll as well to look into? It may seem like the most detailed ai-related dll to get insights. I ran the PR through Claude which did some spot checks Notes from the AIDLL_r debug buildSummaryNo behavioural errors found. About 15 functions of upstream PR #68 were spot-checked
These are naming and documentation improvements; none changes behaviour. NamesWeapon type 4 is Object-type flags.
Example: Kit types (matches the code's Source placementAIDLL_r carries 210 real
The PR marks these placements [INFERRED], so the fix is a move plus dropping the marker. Verified against retailWhat this table is: each row is one claim the PR makes about how retail behaves. I opened the Address note: Ghidra loads libaidll.so ia-32 at base +0x10000, so Ghidra address = the PR's
Sniper branchIn The compiler kept the call but nothing uses its result. It looks like a sniper-specific skill or About AIDLL_r
|
AIDLL_r.dll is a DICE Canada BoosterPack2 debug build of the AI DLL (2006-05-04, asserts and __FILE__ paths, no PDB). It is older than 1.50 but already has the 1.50 AI features. It is used as evidence for names, enum values and source-file placement only; behaviour stays matched to retail 1.50 (libaidll.so / AIDLL.dll). Follows the review notes on B2BF#68. Names - WTSticky -> WTC4 (assert "wInfo->getWeaponType() == WTC4", BBC4.cpp). - Information::isOfType(InformationType), DICE's name (assert "!targetPrimaryInfo->isOfType(ITSoldier)"). The single-bit object-type flag tests use it with the IT* names (enum-to-string switch 0x100D3010), resolving the [UNRESOLVED] flag notes. BotMain::event_airborn tests ITAir, then ITHelicopter, as retail compiles it (ELF 0x18D740). - Kit types documented: 6 is KTAT, 7..12 KTExtended1..6. - 89 member and parameter renames from AIDLL_r assert expressions, each checked by the field offset the assert reads and by its use in the tree (BotNavigation, BotMain, SquadManager/Formation, SAI, AIStrategicObject*, AISettings, BotManager, QuadTree/ClusterGraph, ...). Evidence addresses are in the comments. Source placement (AIDLL_r __FILE__ paths) - Moved: Aimer, BotScript.h -> AIBotActionPlan/; UrgencyMerger -> AIBot/; AIMineManager -> AIKnowledge/; WeaponInfoManager, CustomCurve -> AIUtils/; AerialHeightMap -> AIPathFinding/AerialHeightMap/; UserOrderManager -> AIStrategicEntity/UserOrders/; AILandingZoneManager, InformationManager -> Main/. - Split, functions moved unchanged: SensingAgentPatterns into the Soldier, Turret, MouseFreeLook and Null pattern TUs; SCurve out of CustomCurve; IAIMain, IAIPathfindingSetup and IBotManagerModifier into their own TUs. - Code/Build/aidll_sources.txt, Code/Tests/syntaxcheck.cmd and the Code/Tests/aidll fixtures follow the moves and renames. No behaviour change intended: where AIDLL_r and the tree were compared, they agree with 1.50 apart from asserts. Built and smoke-tested on macOS (bf2_aidll, vtable audit unchanged, 16-bot round); the Windows fixtures were updated as text only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Indeed I didn’t - the latest commit contains now some additional improvements based on the _r version (mostly member names and some slight code improvements). Btw 64/32 windows and a macOS build is also almost done. |
…ainst retail) Recovers the retail Memory.dll (Ver 1.01, 2005/01/10 "Final") into Code/BF2/Memory as its own image, bf2_memory. Every function cites its PE address; placement follows the shipped function and data order. The Final build is mostly stubs: only the chunk pools, the sanity limit, getStatus and the resource counters do work; the counters, trace and histogram exports return constants, as in retail. - Platform seams behind #if, [CHOSEN, not recovered]: constructor/destructor instead of DllMain on POSIX, stderr instead of the message box, pthreads, and a 16-byte header slot on 64-bit. - BF2_MEMORY_PASSTHROUGH (AUTO/ON/OFF) forwards to malloc/free under AddressSanitizer. - Built on request only (EXCLUDE_FROM_ALL) and linked into no game image: the game keeps allocating through the shared CRT (issue #7). Code/BF2/Memory is skipped by the engine source discovery in CMakeLists.txt and Code/Build/build.cmd. - Windows: Code/Build/memory.cmd. Tests: Code/Tests/memory (unit tests, internal tests, and memory_diff, which runs one allocation script against the retail and the rebuilt DLL; the outputs were identical with MSVC x86). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fully reconstructed ai support