Thank you @Askaholic those issues are great. I'll likely take you up on that when I get to that stage (or if something I do wouldnt be best shared with the community).
One way to look for differences between your Lua and the Games lua would be to compare the output of the globals.
local seen={}
function dump(t,i)
seen[t]=true
local s={}
local n=0
for k in pairs(t) do
n=n+1 s[n]=k
end
table.sort(s)
for k,v in ipairs(s) do
print(i,v)
v=t[v]
if type(v)=="table" and not seen[v] then
dump(v,i.."\t")
end
end
end
dump(_G,"")
My thoughts regarding a process to do this would be.
Phase 1. Move to in-house lua (PoC only)
Build a compatible (compare export list) LuaPlus + Lua dll as a drop in for LuaPlus_1081.dll
This will fail if there are any missing changes (and it sounds like there will be). Implementation of whats missing. Also need to look for any modifications that may have been made to LuaPlus.
Get "roughly playable" proving that the concept is possible.
This PoC wouldnt have to be perfect, the goals would be:
- To identify any otherwise unknown changes by GPG
- To verify the dll replacement method
Stage 2 (Luajit)
Swap the library to luajit and move the lua cfunctions to luajit. luajit is ABI compatible so this is actually pretty easy.
Deal with any ABI or language differences. There are some nuances for luajit applications none that I think will apply here (mostly with the calling of cfunctions from lua that call back into lua)
At this stage it's a suitable optional drop-in and we can focus on getting it properly playable and bug free
Stage 3 (further acceptance and performance)
Optimize the code for luajit. We now have a modern Lua variant