Hamers wrote:Great fucking work! Glad someone else is interested in the LUA scripts
Well, to be honest, my goal is to get them to actually execute on my PC.
The files JayK sent me before contained a lot of function "outputs" and were to source to finding the Communicators and their ID's.
Now, in the decrypted main executable, I can see the templates of these functions and that they're just strings where the Communicator names and ID's are filled in to. Because I already generated a complete enum of the Communicators I can easily remake the generation of these functions.
An example:
function QDT.GAME_MANAGER.GetType() return 4222 end (not sure if this is valid Lua, not on my PC right now :A)
That's the simplest function, there's also {Communicator}.NewPlaced, {Communicator}.NewPlacedCtx, {Communicator}.New, etc.
I use DynamicLua to use Lua in C#, and it's pretty
dope.
To initialize this "dynamic database", I loop through the whole Communicator enum, getting the name and the ID of that Communicator.
Then I generate the functions as strings in a string array, just like the main executable seems to do.
After that I loop through the string array, executing them on the Lua instance.
It's really neat, to define a function I just have to do something like IW.Lua("function QDT.GAME_MANAGER.GetType() return 4222 end"); (IW being my main "glue" of all settings, sub-classes, etc.), and IW.Lua being the DynamicLua instance.
After that I just do this: IW.Lua.QDT.GAME_MANAGER.GetType()! Because it's generated on runtime I can use it like a native method
To get a correct output is a bit different though (not 100% sure, but it works).
To make it display on a message box I do: MessageBox.Show(IW.Lua("return QDT.GAME_MANAGER.GetType()").ToString());.
Still, that's pretty fucking neat
So once I have all of Beyond's kernel functions figured out I can call the Game Manager (which is a huge uncompiled Lua script which takes care of all game-related variables, a ton of game-related functions and also the functions which start the storyboard).
Beyond isn't actually
that complicated, the whole system is pretty minimalistic, but there are two things that still twist my mind:
- Why are the names of the Communicator attributes-"attributes" (the ones you see in the data containers, like COM_CONT, MESHDATA, PARTITIO, LOADCONT, etc.) still present? Isn't it much more efficient to just have a uint of the type of the attribute?? What's the advantage of having these strings still in there? Using uints would save a huge space considering all of these attribute names are 0x8 in size, every data container has a lot of 'em, and there are more than 30000 data containers!
- The way the DC_DATA section is formatted makes no sense, there are no offsets, just sizes before each Communicator attribute (so not the attribute-attributes like COM_CONT, but the blocks that contain them). I'm suspecting these tables are Lua tables of some kind. That would make sense, as Lua tables can contain their own functions, and a lot of these data containers have compiled scripts in them. Then still, the only way of parsing these DC_DATA tables is to go through each and every attribute and either skip the size of them to go to the next one or parse the whole thing, which would take up too much memory for a PS3 I think, however, the bigger data containers that contain textures have a "head" and "tail", the head being one segs archive containing the DC_INFO and DC_DATA section, and the the tail being the (compressed) texture.
