maybe you have recognized my current pullrequest Dynamic script hotswapping #15671 already which covers C++ script reloading while the server is running.
After a long time of preparation I finally could implement the actual script reloading part in the last 3 weeks which means the PR is close to be completed (only some minor work is missing).
For a detailed description about all changes take a look at the PR.
The PR is untested and requires a lot of final testing, code reviews and feedback.
Please consider about helping me on the final steps and test the PR or review the code so the PR can be shipped in the near future.
Its cool. And certainly makes testing and tweaking easier and faster in some situations (especially when debug startup takes 5 minutes).
However dlls are always a headache. I already managed to make my world freeze when I messed around with the scripts.
I compiled the server, started it and then I made some changes to the script that already existed (just changed a string from 3 to 5 or something). I also added a new script file of my own that was a copy of the existing example, but didnt use cmake or anything.
So I went ingame and everything was fine, until I saved the example script change I just described and soon after the server console started spewing the compilation. For some reason it compiled a whole lot of stuff (seemed like battlegrounds and scripts and more even though I dont thing I changed anything related to other than the example script). After that the server froze.
I suspect the reason for freezing might have been the whole server recompile.
Later I tried recompiling and restarting the server so nothing was wrong with the server. However the DLL was still old I think so as soon as I logged in everything froze again.
Shut it down, recompiled and installed this time to update the script dll. ( I only have the custom folder set as dynamic )
EDIT: Seems using .die on the test creature and then using .resp without targeting anything causes a server crash.
Here are some details:
Setting the NPC was spawned in: http://prntscr.com/967404
reproduce steps: spawn NPC, let it fight guards, change the C++ script and let it recompile and dll replace, kill npc with .die, target nothing and use .resp
cmake output: http://pastebin.com/cCpDhmM9
compile warnings (had no errors, I had cmake warnings on): http://pastebin.com/Tnh9ufF4
My changes to the source code: https://gist.github.com/Rochet2/377cdc16396ab0cfed57
Compile log in server console: http://pastebin.com/LKE7tjVe
And here are the crashlogs and dumps - newest is 0c6406ff190a_worldserver.exe_[24-11_0-48-14] - they are all from hotswap. (See attached Crashes.7z)
Ah probably it’s because the runtime compiler which is invoked on source changes compiles everything in “release” mode…
to use a compiler in debug mode you need to use the INSTALL target in visual studio by yourself (maybe this needs some adjustments).
So basically I not only need to use the install step, but also compile myself? - assuming the normal compilation would be release and I need debug.
(the whole auto compile feature is not usable atm in debug?)
No not atm. But I just need to make the cmake target configurateable… thats all.
Also i recognized that building in the worldserver is slower then in visual studio (probably bad adjusted resources).
And to use the INSTALL step is easy as well, since install depends on everything you just need to build INSTALL and it will update the .dll.
Ok, works fine now.
I assume your own made custom scripts should be added to the void AddCustomScripts() function in the custom_script_loader.cpp - as I have done in the diff.
Theoretically yes… but it won’t make a difference except that a CMake rerun is needed to add those scripts to the build.
How otherwise would I add them then?
And seems nice that you can add cpp files on the fly and not only limited to changing existing files : )
Added a small playerscript:
class myscript : public PlayerScript
myscript() : PlayerScript(“myscript”)
void OnLogin(Player* player, bool) override
std::cout << player->GetName().c_str() << std::endl;
Database bound scripts still have some limitations (which are caused through ancient code), but database unbound scripts like the PlayerScripts shouldn’t have any limitations.
EDIT: And it’s not important that the scripts are in seperated compilation units… for testing it’s ok if the scripts are written in the scriptloader.
/Push, fixed 2 Issues:
[ul][li]The recompiler project build type (Release/ Debug) now depends on the .dll/.so build type, thanks +Rochet2 for figuring this out.[/li]
[li]Fixed a minor issue regarding to checking before deleting a nullptr, thx +jackpoz[/li]
I just pushed the shared library linking stuff into both branches which is a huge step towards the dynamic script reloading.
Basically the 3.3.5 and 6.x branch allow to build the common, database, shared and game libraries with shared linking now (-DWITH_DYNAMIC_LINKING=1 - a GUI option was added too).
This feature is in early stage and could introduce unknown bugs (when linking dynamically only - the static build isn’t affected), testing is highly appreciated.
Please note that the worldserver isn’t capable of reloading scripts as of now (the required changes are still stashed in my PR and need some extra love).
The 3.3.5 port of the hotswap system is available now, check out https://github.com/TrinityCore/TrinityCore/pull/15671 for instructions.
The PR still needs a lot of testing, I highly appreciate your help.
I’m happy to announce that today, the hotswap system was merged into TrinityCore (in both branches) which enables C++ code hotswapping without restarting the server.
A guide is available at https://trinitycore.atlassian.net/wiki/display/tc/Using+the+script+hotswapping+system, which explains all features of the system and gives some background information.
I want to say thanks to all devs which helped me to make this unrealistic task possible, and all testers who tested the PR in development.
Some interesting facts about the PR:
[ul][li]The project was started in late August 2015 and took me ~8 months to finish.[/li]
[li]My goal was to provide a very good alternative to a long wished and proposed Lua engine, which is easy to use but doesn’t introduce a new script type (next to SmartScripts and C++ scripts), which would lead to code fragmentation (also learning C++ will help everybody to get into the project much faster then a scripting engine).[/li]
[li]Around 7000 lines were changed in approximately 30 seperated commits. (without counting the dependencies added)[/li]
Finally I hope that the system will increase the contribution of content (which should be very easy and funny to create now).