Please make sure you follow the
Forum Usage Guidelines when posting; in particular, please make sure to include the contents of your CEGUI.log file or if it was not generated make note of that. This log provides us with information regarding your environment, ex: CEGUI version, os, compiler, modules, so that we can better assist you.
laurens wrote:While this does compile, the run immediatly fails:
The application failed with exit code -1073741515 (0xc0000135).
This could indicate that no required .dll was found in the PATH.
Yet I do have CEGUILuaScriptModule_d.dll on the path (and linked to libCEGUILuaScriptModule_d as well). Are there any additional DLL's I need to have on the path
I have never seen this error before on these forums, so I am inclined to believe that this is unrelated to CEGUI. Have you tried excluding CEGUI from the build to see if the same error occurs? Usually when a missing CEGUI DLL is the issue CEGUI will throw a CEGUI-specific exception and log the exception information (name of missing module) in the CEGUI.log file. This looks more like a missing system or system-ish (.net, etc.) DLL. You might want to try
dependencywalker to figure out which DLLs are missing.
I am trying to use the Lua scripting module provided with CEGUI. The engine I am using, Leadwerks, also uses Lua (5.1) as the scripting language and thus I have access to an already open lua_State although I can only access it in the form of a byte pointer. My goal is to get that lua_State working with CEGUI. The initialization is as follows:
Code: Select all
_ceguiScriptModule = &CEGUI::LuaScriptModule::create(reinterpret_cast<lua_State*> (lua));
is not possible to cast the byte pointer to the lua_State like I am doing?
The easiest way to determine this would be to simply comment out this line of code and re-build and re-run the application to see if this is the cause of the crash; I highly doubt it is. As far as attaching CEGUI to an existing lua_State it should be possible using this method, however I am not sure what you mean by
byte pointer; if you are talking an opaque pointer or a void*, so long as it is pointing to the actual lua_State object, this should be fine.
are there any objections against having multiple states open at the same time?
Afaik having two open lua states is perfect fine as lua encapsulates the entire state within the lua_State object; eg there are no singleton/global state conflicts between contexts. The only caveat of course is that they cannot directly communicate with each other; you would need to mediate any necessary communication.