Simplified Its actually only one project but with 2 seperate collections (client.collection, server.collection) where of course the server contains more subcollections in it.
The setup is actually that when we develop, the client.collection contains the server.collection so that when building in the editor both collections are built. Then we only have a launch script launching the dmengine saying which collection should be the bootstrap collection.
For us it’s really performant yes.
3 Likes
Another plus for Defold as the engine then.
That should simplify and speed up dev a bit having the two right next to each other and in the same language.
Awesome, thanks for the info. 
3 Likes
Thanks for the advice. I am trying it out as I am speaking.
At first, I had tried print(crash.get_extra_data(crash.load_previous())) which returned empty (the handle is 1) upon the next loading after crash dump wrote. So I wanted to try backtrace, but for some reason the server app is not crashing now. Have no explanation to this random outcome now. Hopefully it will crash and I can read the backtrace() right.
Correct me if I am doing it wrong in reading the error as I am actually just testing out the functions with no idea what’s the outcome.
This looks good, I will try this next. Thanks for sharing and creating of this logging module!
1 Like
I had try your logger and this is the findings:
–START OF LOG–
2018-08-13 23:14:06 (1534176846)
Crash [1.2.134] [b2ef3a19802728e76adf84d51d02e11d636791a3]
Device Model :
Device Language : en
Device OS : Windows 6.2
Signum [57005]
Userdata0 = []
Backtrace:
00007FF708322AE8,00007FF708322A2E,00007FFD43F75057,00007FFD46DAE531,00007FFD46D96606,00007FFD46DAA57D,00007FFD46D3FD23,00007FFD46DA96EA,00007FF7083260E0,00007FF7080C2FE9,00007FF70820BAA8,00007FF70820BFF5,00007FF708219122,00007FF708212218,00007FF7080C04A9,00007FF7080C45E5,00007FF7080BF64E,00007FF7080BF7C9,00007FF7080BC914,00007FF70832443D,00007FFD45D18364,00007FFD46D6E851
–END OF LOG–
I have no idea what this means. Is there anyway I can decipher it?
The backtrace will be hard to understand in a release build. You need to extract debug symbols from the engine to be able to parse the backtrace. If you crash a debug build it becomes a lot more readable.
I tried to build a non-release build, but the result is the same.
Although I noticed I had this file generated at the same time:, “engine_crash_log.bin.dmp” which I opened with Visual Studio. Found this message…
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Is there any reason why I am still having unreadable log data?
Ok, we need to find this problem some other way. Are you able to run the server locally on some other machine. Does it crash there as well? Can you try on another OS?
How long does it take before it crashes? Can you add some logging (print stuff).
Can you describe a bit more what it is you are doing when it crashes.
Thanks for helping. Let me answer your questions in order.
I tried running the server locally and it’s crashed too, so it’s not just on VM.
I did not tried on other OS yet.
The duration between the launch and crash varies. Sometimes it’s takes seconds and some is hours.
The server already doing some logging (printing of stuffs to console) so I supposed it’s what you meant cause it’s meant for me to debug packets.
I merely just built it as headless Window application and run it directly. The server will run automatically which at the start will communicate to the gamesparks to announce that it’s available to connect, subsequently run the usual game logic, nothing fancy. I also tried with Administrator privilege. By using the App Manifest Generator, I unchecked everything except Release, but I also tried various combination but nothing worked out.
Initially I thought is just the VM issue cause I was able to run the full build version locally but not so in the VM. But when it comes to headless, both failed.
Greatly appreciated for all the helps.
Aha, so you’re using Gamesparks? I believe there could be some problems in that extension. @andreas.strangequest is using Gamesparks as well. Andreas, you came across stability issues as well right? If so, how did you fix them?
The main issues we have had with gamesparks is when the server is idle for a long time and then looses it’s connection (or when being redirected by the loadbalancer). Not really any crashes like that, more difficulty to pick up the connection again towards GS. We also are using Gamelift in between there but that is another story I guess. Hard to say what it could be but I’m not recognizing it at all.
Thanks @andreas.strangequest! @hmfafordev, can you please share a list of all the libraries you are using in game.project?
Sure, the following is the libraries I am using.
Hope I extract the right stuff out.
One thing I noticed is that you depend on the master branch of all libs. You should if possible depend on specific versions to “lock down” your dependencies. Monarch has many releases and sometimes (rarely) a breaking change is introduced. The same is likely for other libs. If you depend on master you always get the latest stuff which might not be compatible with your code.
As for defold-luasec would you mind trying:
It would be great to be able to test on another OS. Can I somehow try it on OSX?
Oh, okay, sure I will implement based on your advice. Hopefully it helps.
1 Like
I have made the amendments as suggested, but the issue persisted.
One thing I noticed about the Monarch is, your master release had screen.script deprecated and advised to use screen_proxy.script. but your latest version seems not the same version (screen_proxy does not existed). You might want to check that out. For now, I am using master release.
I also made changes to the luasec, but don’t see any form of improvement.
Regarding other OS, I probably able to get it on IOS, but this server will eventually installed on a Windows Workstation. So hope is not about OS issue.
Thanks once again.
Thanks! I had forgotten to make a release. 2.15.0 is now released with factory support.
I think the next step is that we give it a try here at the office. Can you share the project with me (bjorn.ritzl@king.com) together with instructions on how to reproduce the crash?
1 Like
Thanks for the assistance, sorry for the late response. I was out of town for quite some time.
In regards to sharing the project, do you mean by adding you as a member in the Defold dashboard?
Oh, sorry, yes, invite me (bjorn.ritzl@king.com) to your project via the dashboard. Or zip the project and e-mail it.