Home › Dev CE (experimental)

Lua methods added by the Dev CE test build (experimental)

A development build of a Community-Extension-style GameCore that adds Lua methods by calling engine functions directly: the Lua call object:Method(a, b) becomes GameCore::Class::Method(this, a, b). The methods are generated from a table (address and signature from the symbol-build map and the Linux debug info; this from the game's own instance resolver for the Lua object); no per-function code is written. They exist only in Dev CE, an experimental fork of the Community Extension: https://github.com/cru121/civ6-dev-ce (AGPL-3.0; release zip with the DLL and the full source, see the README there). Dev CE replaces the game's GameCore, so it cannot be enabled together with the Community Extension or any other GameCore mod, works only with Steam builds 15038592 and 15296837 (same GameCore DLL; it checks the DLL itself, not the build number), is single-player only (many methods change synchronised state and can desync multiplayer) and has been run on one machine by one person. Ids and indices you pass are not range-checked; the bridge turns hardware faults into a Lua error but cannot catch silent memory corruption.

Potentially unsafe: Unit:ChangeSightRange hung the game once on a late-game save; PlayerTrade:ChangeDomesticTradeDisabledCount, ChangeInternationalMajorsTradeDisabledCount and ChangeInternationalMinorsTradeDisabledCount disable trade routes with +1 and do not bring them back with -1.

997 methods on 43 Lua objects (plus a few read-only getters the tests use to compare against vanilla). What was tested in the running game (build 15038592; build 15296837 has the identical DLL but was not tested separately; single player, disposable games and a copy of one late-game save; the 0.2.0 release has 1033 functions including the read-only comparison getters, the 0.1.0 release 251):

• plumbing (791 methods): the engine function is entered exactly once, this is not null, every argument arrives exactly as sent, the return value comes back to Lua intact.
• this ✓ (oracle): for the object, a vanilla getter and the engine function of the same class give the same answer, so the object pointer is right.
• effect ✓ (25 methods): the function was called with +1 and -1; a vanilla getter changed as the name says and everything returned to its starting value.
• "ran ±1, reversible ✓, no visible effect": called for real (91 methods), caused no error and was fully reversible, but no vanilla getter shows that state. That is not evidence that it works.
• robustness (earlier 251-method build only): every method was also called with the wrong kind of object, no arguments or garbage arguments (about 2,000 calls): all raised a clean Lua error and none reached native code with a bad this. Read-only getters called with out-of-range ids returned -1/0 or faulted (one getter, UnitExperience:HasPromotion); the faults were caught and the game kept running.
• loading: the methods register identically on every game load (new game, load a save, quit to menu, new game). The Community Extension's RegisterProcessor fix that Dev CE includes was tested in the same runs (handlers run, results return, a World Congress resolved normally).
• save and load: era score, influence tokens, alliance points and gold rate changed by Dev CE survive save, quit to menu and load (tested on the late-game save).
• not tested: multiplayer, loading a save made after a method changed state in plain CE or vanilla, other game builds, other machines, hostile arguments on the newer methods. 881 methods were not run for real at all, and 91 of the 116 that were show no effect through any vanilla getter, so for most methods nobody has seen whether they do what the name says.

Descriptions are written by an AI assistant from the decompiled code and are marked inferred unless a test confirms them; read them as leads, not documentation. 997 methods have a description; about one in twenty is marked low confidence (truncated or missing decompilation), and every description is one reading of the code, not a test result. Many methods change synchronised game state and are marked "may desync" in multiplayer. Where a method is not listed here, see native functions for what has no Lua route.