Quote:
Originally Posted by DrJones
TDW's options can not be read by this application. His Options are held in a script. This one safes the options in a separate file.
|
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.
Your best bet is to design the interface in the .py files (and menu editor). That way it's guaranteed to be thread-safe.