If I have to, I can start creating builds without each individual dependency to try and see if that solves things. I’m hoping I’ve just missed something stupid though… Does the above give any ideas for anyone?
Hmm, it shuts down without anything in the log or crash. Interesting. My first suggestion is that you change to a completely empty bootstrap collection and try to bundle again. That way we can rule out any scripts or assets causing the problem and narrowing it down to extensions and the engine itself.
Not quite. But we know that the extensions initialise just fine at least. I am assuming that some script of yours interacts with one or more of the extensions?
The extensions which are of interest are:
defos
defold-cjson
defold-luasocket
Those two use native code. The rest are pure Lua extensions. The most likely suspect is DefOS. How are you using it?
Oh, and I really recommend that you try to pin a version on all of the extension that have a release on GitHub. It probably doesn’t matter in this case but it really adds extra security for you as possibly breaking changes can’t sneak up on you when you start the project and the dependencies are fetched.
defos - actually never called in the bundle. During dev I use it to automatically send the build to my left monitor. Obviously later I use it for various settings like fullscreen etc, but none of that is implemented at the moment.
defold-cjson - used to encode/decode a settings file saved locally.
defold-luasocket - only used by defcon
Re: Pinning versions, I agree and I have started doing it generally but obviously not quite gotten into the habit. Some I have a valid excuse for, like druid, which is under development and I want the new features. I suppose even for those circumstances I should use specific releases and just update when new things are added.
Edit: I’m working on eliminating each of these in turn, will report back.
It seems to be druid and ludobits. If I remove just one of them, it still doesn’t work. If I remove both, it does work. After removing the dependencies, in order to get through the build process without errors I am commenting out large scripts, so it’s possible the issue is embedded somewhere within those scripts (meaning it could be that just one of the aforementioned dependencies is causing the issue, or the dependencies are actually innocent and my scripts are the cause).
Edit: I was correct - excluding druid and ludobits forced me to comment out scripts that were causing the problems. The dependencies weren’t actually the problem in themselves (I’ve now added them back in and it’s launching), it’s something in my scripts. I’ve gone a bit wild in my use of ludobits sequence, could that be a problem? I’ve caused issues with that before (something about yielding across a C boundary, but I can’t remember exactly) but obviously I’ve fixed those as they have appeared. Is it possible that a strange use of sequence is causing this, even if it doesn’t throw errors in builds?
Forget everything I said. About 50 bundles later (seriously) I’ve found the problem and it’s unrelated to anything else that’s been discussed.
In my localisation script (called lang.lua), I have a brief note explaining its usage:
--[[USAGE
local lang = require "utilities.lang.lang"
print(lang.txt(lang.text_id.DAMAGE, {damage_amount = 12, num_seconds = 3}))
]]
The issue is this require line in the comment and the incorrect (?) format of the block comments. I don’t know the inner workings of the engine, but I’m guessing that when building in the editor the line gets ignored as expected. In bundles, however, it isn’t ignored, and the resulting self-referencing require causes the game to shut down.
I note that these comment formats both successfully lead the line to be ignored:
--
--[[ --]]
But not this one, even though it works in the editor:
--[[ ]]
Programming in Lua is unclear, and seems to suggest both are options. The examples use --]] to terminate a block comment, but the description doesn’t:
Lua also offers block comments, which start with --[[ and run until the corresponding ]]
So potentially we have a couple of issues here:
Can/should a change be made so that --[] doesn’t cause issues like this;
If not, should an error be thrown when --[] is used; and
Should an error be thrown when a module tries to reference itself?
