Si, no habia previsto que se abrieran varios objetos a la vez, por eso hice estos hooks
//hook on command
OrigOnCommand = (OnCommand_t)DetourFunction((BYTE*)((DWORD)apo + 0x8CD0), (BYTE*)myOnCommand);
//hook regiuster lua functions
OrigRegisterLua = (RegisterLua_t)DetourFunction((BYTE*)((DWORD)apo + 0x2F20), (BYTE*)myRegisterLua);
//Hook createobject to save ptr
OrigObject_CreateObject = (Object_CreateObject_t)DetourFunction((BYTE*)((DWORD)apo + 0x8D50), (BYTE*)myObject_CreateObject);
la segunda y tercera se ejecutan en un principio para obtener el lua_State y el object ptr para el que hay que lanzar el evento, la primera es un funcion intermedia que ejecuta el evento oncommand en lua, como mediante modificacion de memoria habia eliminado el mensaje ese de mierda, funciona perfectamente si solo hay un object, si creas un segundo los hooks 2 y 3 machacan la informacion
En realidad, lo que deberia haber hecho, es desenmarañar la memoria de ECX en la funcion myoncommand, que corresponderia al puntero de un CIRPluginObject* (pero en realidad no es asi...) si esto se cumpliera podria usar ecx como puntero de objeto y ecx+4 como puntero a lua state (es asi por funcionamiento interno de ams, esta comprobado)
Si alguien esta muy muy interesado en fixearlo que me lo comente, pero creo que funciona bien y tal, y no es necesario tener un segundo objeto en nungun momento... si bien tambien podria quitar la dependencia de aser32 y generar my propio ribbon.apo que actue como proxy al plugin original, renombrandolo a ribbon.dll... son detalles pero bueno no se si merece la pena
me llevaria un par de horas que no quiero malgastar...