On Thu, Feb 16, 2012 at 9:23 AM, Per Inge Mathisen <> wrote: > A script should not get a warning for every event it does not > implement. If you want to warn about misnamed timers, this function > needs an additional bool parameter that is not set for events. If you > want to warn about misnamed events, then we could check for functions > named event*() but not in the set of defined events on load (could be > a job for lint, but not sure if that is the right tool for the job > anymore). > > On Thu, Feb 16, 2012 at 2:49 PM, Christian Ohm <> wrote: >> It looks to me that change adds a warning if we call any undefined >> function. I noticed this behaviour already when I used a wrong function >> name, and it took a bit to find the problem, since the game just >> silently ignored that line. If the script calls a function that doesn't >> exist, why would we ever not want to know about that? > > Because we have lots of events being called (and more being added all > the time) that not every script should be forced to implement just to > make the warnings disappear.
Eh ? You are inviting bugs then, as can be seen by 001ef35faf1. The codebase is still firing off events and if it isn't in the script then it should be yelling that it can't find it, otherwise you open up a can of worms, making pretty much all bug reports much, much harder to see if the problem is in the codebase, or if it just happens to be a script that didn't implement said "missing" function. If the script writer wants to ignore said "missing" function, then they can NOP the function in question. We definitely should be warning/throwing out errors on all "missing" triggers or events. >> So far, the >> debuggability of javascript seems not much better than that of wzscript, >> maybe integrating a QScriptEngineDebugger would help there. > > When wzscript triggered a crash or assertion, you would not know from > which line or even file the error came from. Now you get a nice > backtrace. That is the difference between being able to debug and not. > Wzscript itself has the same "debugging" capabilities as the current JS scripts, spam printf's/asserts in your code. The issue with WZscript was in the back end, and how the interpreter was created with rudimentary recovery/error reporting. In my fastplay conversion to JS--which did fully work, doing a 1:1 conversion from WZscript, I noticed how poor the debugging capabilities we had with qtscript were, which is when I tried to get QScriptEngineDebugger working, but I quickly found out it had the same limitations with the way we are using qt & handling the update draw calls. If we really want a good debugger, then, at this time the only option I see is go with a external script engine (V8 along with the debugger that is available for that--if we still want to stick with JS) Oh, I know that Qt will be using V8 soonish, but that still won't fix the issue mentioned above. _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
