[WIP] Option Designer for Developer

[DrJones]

Hy @ All

I'am still working on an Option Designer for Developers and Users to create and edit options.

These options will be saved in a XML File wich can be easily read out and be edited over an dll file in .ps in SH5.




To Create a new option you have to give an impressive name.




It is possible to add as much values to this option as you like



This is how the XML file is created



The Programm is written in Visual C# Express 2010.

More Information will follow...

Best Regards

DrJones

[fromhell]

brilliant work.
look forward to it

[Jaeger]

very nice. this could become the new "silent huunter 5 commander". would be nice to see some grafics, too (eye candy). would it be possible to read tdw's optionfiles? (which are a bit confusing some times because of the lack of grafic gui)?

Greeetz, Jaeger

[DrJones]

Originally Posted by Jaeger

very nice. this could become the new "silent huunter 5 commander". would be nice to see some grafics, too (eye candy). would it be possible to read tdw's optionfiles? (which are a bit confusing some times because of the lack of grafic gui)?

Greeetz, Jaeger

Thank you....About grafics and eye candy can we talk when the fully function is given.
This project is still in the construction area.

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.

in the future...Who knows....

Best Regards

DrJones

[DrJones]

Originally Posted by fromhell

brilliant work.
look forward to it

Thank you...me Too !!!

[TheDarkWraith]

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.

[DrJones]

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

[TheDarkWraith]

Originally Posted by DrJones

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).

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

Yep, trial and error is the best way to learn I thought I'd give you some pointers so you can avoid some of the major headaches I went through.

I compiled for .NET 3.5. I also saw that trying to compile against .NET 4.0 was problematic

The one thing I find very strange is that Python has a compiler to compile python code. I tried compiling some python code and importing it and the game wouldn't accept it. Very strange