I can take a look and cross-check them to see if they are valid for the C side of things.
As for things to work on, anything that you are interested in really. Nothing really set in stone at this point. rMod opens up ease of keeping things in a central project and allows for rapid development using addons and such. If you are interested in building things for it feel free to dig in and ask any questions you have.
(Combined post below.)
For your lua_pushcclosure, an easy way to find it is to locate lua_setfield via referencing the normal Lua 5.1 code base. You can find several strings that will align to it. In KoreVM inside of Reckoning.exe, lua_setfield is: 'sub_467550'
One of the main uses of lua_setfield is within 'luaI_openlib'. Which you can find inside of Reckoning via its strings that it uses:
- _LOADED
- name conflict for module
From there you can compare the code between the real Lua output and IDA's hexrays pseudo generation. The last loop within the function includes using setfield and pushcclosure:
for (; l->name; l++) {
int i;
for (i=0; i<nup; i++) /* copy upvalues to the top */
lua_pushvalue(L, -nup);
lua_pushcclosure(L, l->func, nup);
lua_setfield(L, -(nup+2), l->name);
}
Your address for pushcclosure is here too:
v24 = sub_8F8B20(v18, a1, *(_DWORD *)(v5 + 4), a5, 0);
v25 = (_DWORD *)(*(_DWORD *)(a1 + 36) - 8 * v18);
v25[1] = v24;
The only issue I see though is that it looks like it is used in a different manner with KoreVM. Instead of pushing onto the stack and continuing, its instead returning a value that is then used afterward. This, to me, looks like sub_8F8B20 is creating some type of object that is returned into v24, then the next line is determining the stack position to push it onto. (a1 + 36) is part of the stack top usage.
v25[1] here is placing into the 2nd DWORD of what v25 equals. So I do feel yours is correct just that the C usage is going to differ than stock Lua.