Quote:
Originally Posted by TheDarkWraith
There's a good reason why I put them in .py files too. The version of Python used with the game is not very 'thread' friendly and/or the game wasn't coded 'correctly' to work with user Python code calling out to external DLLs. Calling out to external files is very tricky with this game. You'll find yourself getting CTDs with no explanation if you call out to something and it isn't 'synced' with the game. With everything in .py files you can pretty much eliminate this problem (since the code in the .py files is operating in the same thread as the game).
If you think about the architectural design of the game and the version of Python used they are completely different. The game was made using C++ (unmanaged code, no CLR), the version of Python uses managed code (has CLR). This is where things get tricky when you have unmanaged code running managed code that calls out to managed/unmanaged code
When you import a .py file all the 'items' in it are added to that object's global space. Since they are now in it's global space they can be accessed by it without having to call out to any DLL and thus risking a game crash.
The way you call out to DLLs and the way they respond back to the game has to be in-sync also or you will be in CTD heaven. You'll find out soon enough  When you get the error "Silent Hunter 5 has experienced a problem and needs to shutdown" you know you have a DLL sync problem.
You are making an on-demand type of interface that will have many callouts and callbacks from it (you say you want to be able to change in real-time). Unless you are a master of multi-threading you will run into problems. Your callbacks cannot directly manipulate a .py file or you risk a crash. You have to connect the callbacks to the game in a soft and synchronized way (when the game is ready to answer your callback).
In my DLLs that change game values I use locks and other multi-threaded techniques to make them thread-safe and thus avoid the crash.
|
ui thank you for that and the hints
it is as you also often say failing is the way to learn. i know it is a lot of trial and error. as you i also had sometimes a very big headache as i began to import the magui interface to that what it is now...(addins and further changes will follow).
The techniques you have used are very well known to me....also to the code of scriptmanagerwrappers and the code of the ironpython.dll....
can you tell me in wich version of framework you compiled you dll's. Version 4 causes Problems. With 3.5 the dll file could be loaded...so far any problem sighted. But i'am sure that there will come some crashes.
Thank you very much
Best Regards
DrJones