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

http://www.mediafire.com/imgbnc.php/2a0a3628fdc8650fa423e4971592c8ec96a58b58468bb71092 7c8dc71405eff16g.jpg


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


http://www.mediafire.com/imgbnc.php/94b3793cc44c29f5828eb58114e97123c3e6c8c53a3093eb6b 25b1d6cdc6e8a96g.jpg

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

http://www.mediafire.com/imgbnc.php/1918da53afb177fc1af9b14c5608a8baaecbd95ec26a672802 1516d5de2737706g.jpg

This is how the XML file is created

http://www.mediafire.com/imgbnc.php/ce23c90892b421856138250914648cfd4a732d2f1c190667f8 c1e99ca1159e506g.jpg

The Programm is written in Visual C# Express 2010.

More Information will follow...

Best Regards

DrJones:salute:

[fromhell]

brilliant work:salute:.
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]

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:salute:

[DrJones]

brilliant work:salute:.
look forward to it

Thank you...me Too !!!;)

[TheDarkWraith]

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 :doh:

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 :yep: 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]

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 :doh:

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 :yep: 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:salute:

[TheDarkWraith]

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:salute:

Yep, trial and error is the best way to learn :up: 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 :yep:

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 :hmmm: