Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Fri, Feb 17, 2012 at 3:10 AM, buginator buginato...@gmail.com wrote: 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. I've fixed up the lint tool, and will be adding code to detect such errors in it. 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. What? Surely the bug reports will be harder to read when they are full of meaningless warnings. If the script writer wants to ignore said missing function, then they can NOP the function in question. This slows down processing of events *significantly*. And then I add a new event, and all old scripts start to produce warnings. Some scripts will then contain a few functions of real code, and dozens of no-op functions. Ugly. We definitely should be warning/throwing out errors on all missing triggers or events. Triggers, yes. Events, no. So far, the debuggability of javascript seems not much better than that of wzscript, maybe integrating a QScriptEngineDebugger would help there. Feel free. I do not see the need, personally. if we still want to stick with JS Not doing that is such a stupid idea at this point, I don't really know how to respond. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Sun, Feb 19, 2012 at 11:08 AM, Per Inge Mathisen wrote: On Fri, Feb 17, 2012 at 3:10 AM, buginator wrote: 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. I've fixed up the lint tool, and will be adding code to detect such errors in it. Are you talking about be00eb4577603c56416005380d017177075130a4 ? While testing like that is good, it don't really work unless you use it... 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. What? Surely the bug reports will be harder to read when they are full of meaningless warnings. LOG_WARNING only displays when compiled in debug builds, not release. That means we can have instant feedback, not waiting for a separate tool to be run. When we make builds for release, then those are not shown. If the script writer wants to ignore said missing function, then they can NOP the function in question. This slows down processing of events *significantly*. And then I add a new event, and all old scripts start to produce warnings. How would it be significantly slower, all the function does is NOP, and there shouldn't be any major overhead in that. Adding it to the 'list of functions that are not used in game' is hardly more trouble than remembering to update the external tool to check for the new event/trigger. Some scripts will then contain a few functions of real code, and dozens of no-op functions. Ugly. You can put the ones that aren't used in one (or more files, perhaps splitting them on what they are used for, like attack, defense, structures, and so on...) file and just include that in any script that don't need to override that. We definitely should be warning/throwing out errors on all missing triggers or events. Triggers, yes. Events, no. Events are equally as important as triggers. In both cases, the game fires / calls it, and if not found, it means that it was either a bug (which the LOG_WARNING would have found in real-time, not wait for reports from the field or using the external utility which may or may not find the issue), or expected behavior, since it is unused. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Thursday, 16 February 2012 at 8:42, 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). 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? So far, the debuggability of javascript seems not much better than that of wzscript, maybe integrating a QScriptEngineDebugger would help there. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Thu, Feb 16, 2012 at 2:49 PM, Christian Ohm chr@gmx.net 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. 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. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
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
