Hi, please don't take this as a dig, its not intended that way, but your implementation of Lua is lacking argument error checking and causing GG to crash, I have lots of experience working with Lua and have built Lua based runtimes, plugins and modules myself so I feel compelled to bring this up as this is pretty much the standard for Lua based applications

for example, I changed a Prompt to a PromptLocal but forgot to add the 'e' argument, the result is GG crashing, to solve this you need to make use of Lua's 'error' function and check argument types before sending the direct call as this crashes the internal lua_state

the correct method of checking arguments in a lua script:


the result is I am informed of the error, told what script, line and argument is at fault and GG does NOT crash as Lua automatically prevents the function call after calling error (see attachment), it also helps a great deal with bug tracking scripts and function calls

this should also be implemented in direct call functions with luaL_argcheck and luaL_argerror as Lua does not like nil values and altho its pretty forgiving on most argtypes nil's crash the runtime, everytime!

That's odd. Whenever I've had an issue with incorrect LUA scripts it will show a prompt telling me which line is a problem, and if I click ok it still loads the text game but with that LUA script disabled, maybe it's only some commands that don't prompt?

Lua will automatically report script syntax errors and nils (non existent functions and variables) and exit the script at that point but it does not recognize or report argument errors as it does not know what arguments should be passed, that's down to the developer, lua will simply process the input and in the case of nil's it will crash, so yea it does report errors but currently not all of them

try it out, call PromptLocal or any function with a nil value and GG will crash and restart the session, add my code above and see the difference

Errare humanum est. Therefore, we must handle errors the best way we can. Because Lua is an extension language, frequently embedded in an application, it cannot simply crash or exit when an error happens. Instead, whenever an error occurs, Lua ends the current chunk and returns to the application.

assert might help to hanle errors. As example:



source: extracted from the LUA program help.

I think coding error handle for all the errors TGC had listed can take long time, and since everything is constantly changing, I guess it must be more difficult.
Anyway GG need to manage your errors, create answers for them, so they do not produce the computer crash, or at least minimized them.

3com

yes, assert or even pcall can achieve the same goal but the error function has a 'level' argument which tells Lua which level the function call was made from, using assert will report the error yes but is will report from the wrong location (ie global.lua) and not the script or function the call it was actually made from.

for example, a script myscript.lua calls PromptLocal with wrong arguments and errors, assert will report the error from global.lua and not the script the error occurred in, using error() with a level of 2 will report from the correct location "myscript.lua"

these are internal GG errors and GG needs to be able to trap them and prevent itself from crashing using the api functions that exist for this very purpose, it would not take long to error trap the global.lua file I could do it myself in a day or 2 (or 3/4 lol, call it a week) or go to the source and trap argument errors in SendMessageI/S but that would be a generic fix as its a multi-use function, best you can do there is check for nil values and prevent a crash but I would prefer a more informative solution and report argument errors from each function call, bearing in mind that a lot of non-programmers will be using the scripting system giving them direct and correct error reporting is a must IMO

those of us from a programing background kind of instinctively know where to look when something goes wrong and no error is reported, hence why I made this thread, but people new to the world of programing will quickly give up when they attempt to script and GG does nothing but crash due to incorrect function arguments, a nice little dialog telling them where the error is would be so much better

I know many of you are thinking "what the hell is this bloke on about!!" but please believe me, this is the standard for lua

That's why a good GG-Lua IDE would be great. With a strong debugger and somthing like "compiling". In other language's the debugger would complain about the missing argument.

Yes, when you start doing more complicated things in lua, GG can crash and burn horribly. It makes coding a bit of a chore. Just yesterday I must have locked GG making it restart at least 20 times during my coding, probably more. Sometimes you get a useful error, but many times you will get none and a crash or a basic error 501 type thing.

I'm used to it to some degree, even a basic typo can cause complete lock up on occasion. Better checking of the code before GG even starts to run any other game related things would be good to avoid typo's being an issue. Not a priority for me though, but certainly something for the future.

I never like GoTo, but some sort of "OnErrorCase GoTo", might help.
Anyway I would prefer some sort of "Try/catch/end try", to handle errors.
Even some sort of "GC.Collect()" for garbage collection, this might help with perfomance.

3com

Thanks for the info, much appreciated. The usual price for error trapping is a cost on performance which is why I have kept the scripts to almost assembly-like simplicity. Is everyone happy to have error trapping at the cost of a lower FPS? The best idea is a pre-compile step which can highlight the errors, but we would need a LUA Compiler/IDE at some future point for me to add such a thing, and I am not sure how to phrase that in the voting board that highlights the benefits to the majority (thus not get many votes). My current plan is a LUA GUI which should allow a great freedom of script control without actually coding. Another option would be a sort of third party compiler which could load the LUA scripts and provide warnings at edit time?

The idea of a compiler perfectly adapted to GG, with the ability to auto-complete / suggest keywords, not displease me at all.

Having the ability to test scripts outside GG, it is almost a necessity, plus a great advantage.

On the other hand, if to enjoy this function, we must submit to vote, this may take many years.

So I vote for a 3rd party compiler, I guess you need not be submitted to vote, and therefore will be much more immediate.

@ Lee
As aside note, please do not forguet about bellow code, for the next time. Thanks.



3com

@Lee, of course I understand there's an added overhead with adding all those function calls, maybe GG could have 2 global files, an error trapped global_debug.lua for use in test game and a slimmed down less resource hungry version for standalone games, much like many compilers will compile a debug build on preview and a faster non debug build on compile, as Dvader says one small typo in dev mode and GG will crash, this is all Im trying to avoid, once the script is working and error free, it no longer need strict error checking, right?

I certainly wouldn't want to slow things any more than needed. I will say I have been scripting in GG since it was first released as Reloaded. I find it annoying when you get errors with no real clues to track down, but am used to it. I just make sure I test the code often and don't go too mad in between. That way you generally know where the error lies.

I would think some way of testing the code for errors in a different program to GG would be a reasonable solution. The main thing that can cause delay in scripting is waiting for GG to run the tests, especially on a big map. That or just some checking when loading in test mode rather than in the standalone.

Saying that though, as said above, I can live with it to keep speed better, as we all know we need more not less I could make things easier for myself by using notepad+ for instance, but I always use notepad. If you can code in notepad, then you can code in anything

Yea most of the time I can track down the error or know the crash was caused because I just edited 'x' section of code but I have 15 years of programing experience, GG is punted as the easy game maker its going to be known as the buggy game maker if everytime someone typos a script the IDE crashes, I dot think FPS rates should even be considered as an visible reason to completely drop error checking, give us the option to switch between debug and normal modes in the menu or a toggle on the toolbar and job done, got trouble script or writing complex stuff and want/need error checking support switch to debug, testing framerates and game play, switch back to normal...... performance does not have to suffer at all, not in the slightest

Lua is fast, it has a reputation for being so and its the reason its used in so many games, I would be surprised if adding type() calls made a huge impact on FPS, but I could be wrong I guess, anyhow, a debug option would be the perfect solution here

any code executed within a loop consumes resources, even more if it is a continuous loop.

Sooner or later, TGC have to deal with identify and manage errors that may be generated in a script.
Out of an infinite loop, it is not much fun.

The idea of TGC creating a kind of notepad ++, 100% Compatible with GG, with the ability to test the code before using it in GG, is an idea that appeals to me.
With a LUA compiler, a kind of intelli-sense, contextual help, debugger, lighting language keywords applied to GG.

Like kidly wermer did and share here: https://forum.game-guru.com/thread/213931 .

But I guess this is a difficult project to carry out, so I opt for the more practical, ( a 3º party tool).

3com

writing a NotePad++ type editor is no big feat and I can (have done) in a matter of a couple of weeks, write my own

[href=null]https://forum.game-guru.com/thread/214776[/href]

I could add Lua to my script editor and do a basic syntax check, a spoof global.lua to catch 'some' argument errors, but it could not actually test the code works unless its run within the engine but I could make it debugger like so your scripts wont make it to the engine with typos and you get realtime reports in the script editor for syntax and 'some' argument issues, this still would not be 100% as nil values can hide in nested code, if a function call contains a nil and isn't called from the main nest and there is an if statement then preceding code is syntax checked only, the only way to check function arguments in nested code is to actually call the function, no 3rd party tool will be able to catch all errors unless given access to GG's internal lua_state which I'm guessing is only active when the game is actually running

there are many solutions, I would prefer to see a native solution within the GG IDE (like the debug toggle) as no 3rd party tool will be able to error trap 100% like you could from the global file ... that file is the key to all this, its the bridge between Lua and C++, it needs to happen there!

My hope is that the 'easy game maker' experience would come from LUA GUI panels that allow users to quickly and instantly change the behaviour of game logic without resorting to scripting. I also recognise that at some point every user wants to move beyond the easy sandbox of drag and drag and start to do some basic coding, but by then I am assuming they have gone beyond the need to have 'easy everything' and are prepared for the potential pain of scripting. If I channeled all my efforts into making the 'less easy' scripting side more robust and programmer friendly, I would be ignoring the vast majority of new users who don't want to code, just make games quickly and easily. Once we've knocked a few things off the voting board, I will add a new feature which provides full LUA debugging and 'edit and continue' functionality to the board and see if users vote for it

Even to use this "easy game coder", you need to have some basic knowledge of the language environment.
In other words, a new user without knowledge of LUA, including programming, can get lost easily in a maregmanum buttons, known as its usefulness; this could achieve the opposite effect.
As there are educational videos that help start GG, may also have tutorials on scripts GG, with practical examples to help users start using LUA.

As I understand it, this function could be achieved with an LUA editor with compiler, debugger, intelli-sense or something like that, and so on.
This helps a lot to both experts and beginners.
This should work in a sepparate window, just my thought.

3com