Thanks
Zargy
Recent community posts
Is he underlying editor framework (Ace) flexible enough to make a vertical tab mode possible (like Jetbrains Rider or other editors)? Having a large number of files open quickly gets disorganized and hard to read. Keep in mind that I'm not talking about the outliner, which is for looking at the structure of a single file.
Fair enough. Just wondering then, what would the performance implications of creating many separate Lua states be? The main thing I plan to use this for is creating scripted cutscenes/dialogue sequences (I.E. something that I really needed coroutines for). I'm used to working with MoonSharp, so I usually encapsulate loaded scripts into their own tables so I can define variables local to the script outside the main function that executes as a coroutine. (That's just the way I'm used to doing it for the huge JRPG I'm making though, this game is a lot simpler. I'd still like control)
For this case, my next option would be to try just spinning a separate state up for each loaded script. I don't have a lot of global state that I'd need to pass between scripts. I'd just like to know how "heavy" a lua state is in this instance, and how much performance one of them would take up.
I can see that there is no translation for Lua functions back to GML, only an API to call global functions. I'm used to working with Moonsharp in Unity where you can just call a function inside a table. I'd just like to know why this limitation exists. Is it something that would be possible, or is it too difficult to implement currently?
I am running GMS 2.2.5.481, runtime 2.2.5.378. I purchased GMLive and downloaded the 1.0.26 version for GMS2. I cannot upgrade to 2.3 due to work requirements. I have this bit of code:
if(live_call()) return live_result;
enum TestEnum1 {
Value1,
Value2,
Value3,
Sizeof,
}
enum TestEnum2 {
Value1 = TestEnum1.Sizeof,
Value2,
Value3,
}
Any attempt at reloading results in the error:
[live][9/27/2020 6:08:14 PM] Error in test_enum:
[live][9/27/2020 6:08:14 PM] test_enum[L11,c20] Enum values should be constant
Clearly the value of another enum is a constant. Why does this not work? We use this pattern of using values of earlier enums all over our code base, mostly in files that also happen to contain the code that we most need to reload live (player movement/mechanics). Any attempt to reload those files also results in this behavior. I believe this should work as this is supported by GML and I cannot see it mentioned anywhere in the Limitation section on the documentation. Is this a bug, or is this somehow intended? If it's unintended, when will it be fixed? I bought this package expecting to be able to use it to drastically cut down on iteration time, but it doesn't work for me at all.
I would need to think more about a clean way to edit them, but I'll say that this is a feature I would love to have. I was happy to discover variable defs. They're a great feature that make level creation a lot nicer. I'm almost free of having to deal with the GMS2 workspace, except for having to add them through their bulky editor, and not having them show up in GMEdit code completion.