Is it preferred to use collection proxies or factories? It seems like both can achieve pretty similar ends, but from reading about the difference between the two, proxies might be a little heavier weight? Any advice on which to use?
Looking at the example in the Monarch repo, it seems like each gui_script invokes msg.post(".", "acquire_input_focus") in the init function - is that necessary? When I remove that call in my project, things seem to work, and looking at the monarch.lua source, I believe it will post that message automatically?
This one relates to the design: with both proxies and factories, there’s some (not saying it’s a lot, but some) duplication going on with setting up the game objects in main which link to the actual collection representing the screen itself (which then requires a .collection in addition to a .gui and .gui_script). Just curious how realistic it would be to have another mode, call it “immediate,” as a 3rd option instead of factory or collection. My thought was the game object in the main scene could be used directly, instead of having a separate collection file - you would just add the gui component directly to it and reference a screen_immediate.script file instead of screen_proxy.script or script_factory.script. Just a random thought I had, curious if there’s a reason it wouldn’t work (other than forcing the load of all the assets at once).
Other than those questions, seems like the library does exactly what I was hoping for - thanks!
I preferred collection factories so far. Because nesting screens can only be done using factories.
You are right about “acquire_input_focus” message passing. But it is wise to debug it for every collection u have created.
I use a dummy screen (or loading screen) while preloading all collections. It depends mainly on weight of your atlases and number of screens to be loaded. script_factory.script automates such things like granting each screen an id. Haven’t got any performance issues using that yet
I don’t think so, it certainly seems like that’s an officially supported way to go, I was just curious what the trade offs are (if any).
Cool thanks for your feedback @wowerwow23. When you say “it is wise to debug it for every collection u have created”, any specific gotchas? I’ll probably leave out the “acquire_input_focus” messages for now if they’re not necessary.
Regarding my own question #3, I suppose the obvious issue is that all the objects would start created, and so would need an easy way to switch between “disabled” and “enabled”, which might change the semantics too much. I think I’ve seen support in Defold for enable/disable but not sure if that extends to an entire gui component and all its nodes.
They are in many ways very similar. One difference is that a collection loaded using a proxy creates a separate “world” with its own physics engine context etc. You can also not manipulate game objects across “worlds”.
Monarch will acquire input focus for the script loading the collection proxy. This is needed for the input stack to work. Refer to the input manual for details.
I think some of this setup could be automated by our new Editor Extension Script functionality. I haven’t thought about this in detail but it’s something I’d like to explore later.
This is a good idea and definitely something that could be done! Please create a ticket in the Monarch repo and me (or someone else) will pick it up when there’s time.
) duplication going on with setting up the game objects in main which link to the actual collection representing the screen itself (which then requires a