Yves

Toggling breakpoints works, and I see the thread information, but the step and continue commands don't seem to work and I don't see the callstack. That's probably too much work for me because I don't use eclipse . I thought I'd make a codeblocks plugin first, but figured out that a webserver and a Web-GUI is probably easier and better.

Do you mean the multiplayer? We don't have a multiplayer lobby yet, you have to know the IP-address of the host to play multiplayer games.

Yes, that's correct. Actually I haven't yet understood how debugging multiple threads exactly works in Visual Studio or GDB. Maybe I should try to figure that out as a next step. At the moment I don't know a way to stop other threads instantly, but it should be quite easy to stop them when they call the next function.

The new version is ready along with documentation on the Wiki. http://trac.wildfiregames.com/wiki/JavascriptDebugging It's still WIP but should work well enough to use it for developing the UI.

../../../source/scriptinterface/DebuggingServer.cpp:745: error: redefinition of ‘void CDebuggingServer::Step()’ ../../../source/scriptinterface/DebuggingServer.cpp:269: error: ‘void CDebuggingServer::Step()’ previously defined here DebuggingServer.cpp doesn't even have 745 lines. It looks like you applied the patch twice and the contents are twice in the file.

The bad news first: the weekend is over and the new version is not yet ready for release. The good news is that the new threadsafe design is basically completed and I think It's a solid base to improve upon. Many major bugs of the last version are fixed and all features are implemented again. A new feature allows listing all registered threads and getting information about them. That way it should be possible to display the current position in a file. The output looks like that: { "ThreadDebuggerID" : 1,"ScriptInterfaceName" : "GUI","ThreadInBreak" : true,"BreakFileName" : "gui/pregame/mainmenu.js","BreakLine" : 139 } I would like to spend a few more hours to get this version more stable and write some documentation before I release it.

If a building is so heavily under attack that you don't make any progress building it, you should consider attacking the attackers. They will stop attacking it soon or they die. I don't see what the problem is. The only problem I see at the moment is if the foundation can get damaged and repaired endlessly without spending more resources. That doesn't make sense.

Hmm yes I think you are right (after checking the code more closely). About the question my opinion is that a building should require the maximum health to be completed. 1. It's clear for the player when a building will be built. 2. It's more logical. It shouldn't be possible to complete the build after a herd of elefants has run over the construction site by just one hit of a hammer (to use an extreme example). 3. I think it's better for games with wonders like in AOK. If the enemy is close to completing the building of a wonder and you can damage it severely, it's a benefit for you even though you didn't completely destroy it.

In Reply to: http://www.wildfireg...77 I'd test the persian architecture tech now. I'm quite sure that it doesn't work as expected anymore after that patch. The idea for increasing health by tech was to increase the health relatively. If your building had 100% before researching the tech you get 100% after that and your HP increased. If you got 50% health before researching the tech you'll get 50% after researching it. Btw. I think it's a bad thing that we aren't able to post in the Design Committee thread. It's unnecessary and confusing if people have to create separate threads to make a comment or tell their opinion.

The buildings look cool, but probably they need some more color variation. They shouldn't be painted like a rainbow, but I think a litte bit more color would be good.

The progress is quite good at the moment, but the change to a thread-safe design is quite a lot of work. I hope I can get it done this weekend.

I know too little about that at the moment. I assume that the features of the webserver we are using (called mongoose) are quite limited. Events triggered by the webserver would be handy for breakpoints to avoid polling from the browser, but I'll keep that for later because it's not essential at the moment. It don't think it would help in the case you quoted. I was talking about ingame information.

I strongly encourage you to use SVN or GIT. GIT is just another version control system like SVN and we will probably change to GIT in the next months. Maybe SVN is better for you at the moment because there are more people here who use it and can help if you have problems and I'm not sure if the GIT mirror will stay stable all the time in the next months because of the migration. It's quite easy to use if you just use it to update the game and it does not necessarily require you to build the game from source (there are prebuilt binaries created regularly). You can get to whatever version you like whenever you want! If you find a bug in the engine and someone fixes it, you'd have to wait up to 4 months until the next alpha release or you can get it nearly instantly using SVN/GIT.

Yes, that should be possible, but I'll concentrate on the more critical issues (like crashes) first, if that's OK. I wanted to put everything into a wiki article yesterday, but had some track problems. The problems are solved now, so I'll do it together with one of the next patches. I'll see what I can do. I thought with the current system the client code could search through the variables to display them in a userfriedly way... but probably it's good to have both options available. I think it would be quite difficult to develop the UI without having access to the debugging server. I'm sure we can figure out where the problem is quite quickly if we do it step by step on IRC. Looking forward to checking it out... but I'll try to get these crashes fixed first. The problem is that triggering a breakpoint essentially means pausing execution of Javascript code and also pausing the c++ code that called the Javascript code. If it's the main thread you paused, there are no render()-calls anymore and whatever you pass to LOGERROR will only be rendered when you continue the main thread. Maybe we could call some rendering functions inside the breakpoint handler directly, but that's a lower priority at the moment. I think that could be caused by some strictly forbidden things I do concerning multiple threads. I've thought about that this morning on the train and think It's probably not as complicated as I thought. I'll try to fix that first.

I think the only thing missing before a basic debugging UI can be completed, is a way to find out where the program is currently halted. For the moment this will be the only new feature I'm going to implement for the debugger (if the UI developers don't find anything else that's required). It should be relatively easy to write a function that returns filename and linenumber of that location. The debugging UI will have to poll for that information, I don't think it's possible to push data from the webserver (at least not with our very lightweight and limited mongoose server). I think with that stage (including the feature mentioned above) the following should be technically possible: Having a list of available file names Opening files from that list Setting breakpoints graphically by clicking on a source-line Single stepping Detecting where a breakpoint/step is triggered and displaying the correct file with an icon (or similar) at the correct line Displaying the callstack when a breakpoint is triggered Displaying variable content in a hopefully user-friedly way (maybe by searching the variable array for a variable with the name of the currently hovered word and having the array available as raw data if it's something more tricky). This part could be quite tricky if we want to get it perfect (resolving array elements and such things). After implementing this last feature I'm going to concentrate on the threading aspects and hopefully I can make that stable what we currently have. Please tell me if you think there are any other essential features for the first version.

That's strange. Did it build without errors and do you execute the pyrogenesis_dbg executable?

I can confirm this on Windows. I'll try to figure it out and edit this post or add a new one when I know more. EDIT: I forgot to initalize a boolean variable. Apparently it becomes false by default on Linux but not on Windows. There was also another problem with an uninitialized jsval which should be solved now. This version is now tested on Windows and Linux. A known Issue is that it crashes when exiting the game, which I think is related to using Javascript contexts in multiple threads and will require some more thinking. Here's the updated patch: javascript_debugging_WIP_v.0.5.diff

I've always used the example from the first post for testing. Maybe there are some issues I haven't discovered yet with other files and lines. http://127.0.0.1:9000/ToggleBreakpoint?filename=gui/gamesetup/gamesetup.js&line=1481 Start the game. there should be a yellow warning message on the upper left corner that the javascript debugging is enabled. Enter the URL in your browser to toggle a breakpoint. Select "Singleplayer->Matches" Now the UI should "freeze" because the breakpoint callback is called and loops until you continue/step. The breakpoint will be triggered multiple times. You can either remove the breakpoint and call Continue once or call Continue multiple times. As you see it only stops one thread which is one thing that could cause issues. Good I thought we could do it similar to 0ad/source/tools/profiler2.html. It uses a local file which can be opened in a browser, modified or placed wherever you want. Why would we need to provide the index.html via webserver?

The next version is ready and you can now examine variable content at runtime. New functions Both functions are only available when the execution is halted because you have triggered a breakpoint or used step after triggering a breakpoint. Getting the callstack http://127.0.0.1:9000/GetCallstack It will return something like that: ["keywordTestOR","annonymous","testFilter","initMapNameList","selectMapType","__eventhandler31 (selectionchange)","initMain","onTick","__eventhandler28 (tick)"] keywordTestOR is the innermost function which got called by an annonymous function, which got called by "testFilter" etc... Getting all variables from a stack frame. http://127.0.0.1:9000/GetStackFrame?nestingLevel=0 If you look at the function above (GetCallstack), nestingLevel=0 would point to the innermost stackframe (keywordTestOR). Native functions as "__eventhandler31" don't return any data. Other modifications I've uncommented the most annoying LOGERROR calls that spammed the screen. EnumJsFilesPreExec returns a slightly different output format (I hope that's better). javascript_debugging_WIP_v.0.4.diff

No I don't think more than once per second makes sense. I was just talking about intervals of 0.1 seconds to make clear what I mean. If it's not significantly more than 100 µs it shouldn't be a problem. I think we can remove the code to calculate the play-time entirely and set the interval to 1 sec.

OK, this version should work for the bundled version too. Credits go to Philip for helping me with the pointer to jsval conversion. javascript_debugging_WIP_v.0.3.diff

It doesn't look like you've done anything wrong with the patching. Please try compiling just DebuggingServer.cpp with the same options as I did (maybe you have to adjust some library directories): g++ -g -Wall -DDEBUG -DLIB_STATIC_LINK -DUSING_PCH -DWITH_SYSTEM_MOZJS185 -Wno-switch -Wno-reorder -Wno-invalid-offsetof -Wextra -Wno-missing-field-initializers -Wunused-parameter -Wredundant-decls -Wnon-virtual-dtor -Wundef -fstack-protector-all -D_FORTIFY_SOURCE=2 -fstrict-aliasing -fno-omit-frame-pointer -fpch-preprocess -msse -fvisibility=hidden -I/usr/include/nspr -I/usr/include/js -Winvalid-pch -include "../../../source/pch/scriptinterface/precompiled.h" -I/usr/X11R6/include/X11 -I/usr/X11R6/include -I/usr/include/X11 -I../../../source/pch/scriptinterface -I../../../source -I../../../libraries/valgrind/include -c ../../../source/scriptinterface/DebuggingServer.cpp -o ./DebuggingServer.o EDIT: I've figured out why it happens, but not yet how to resolve it. If I use the bundled version of spidermonkey, I get the same errors.

I have created a new version which also changes the part of code that can cause the compile error mentioned above. In addition to that it implements the new command "step" to step a single line after you have set and triggered a breakpoint. http://127.0.0.1:9000/Step javascript_debugging_WIP_v.0.2.diff

Yes at the moment it's only enabled in debug builds (#ifdef DEBUG). It should definitely not be enabled in release builds for reasons like performance, security and stability. No I haven't. Yes that's an important note. It doesn't seem to be possible to use 3th party tools that are designed for other Javascript embedding applications like Firefox. Thank you, that would be awesome! If you have time, please check if the format returned is OK or if I should change anything so that once you start you don't have to worry about these things. I thought it could be something similar to source/tools/profiler2/profiler2.html regarding the technologies used, but you're free about that.

Have you ever wanted to step inside a Javascript function while tracking down a bug with a C++ debugger? Did you miss the ability to single-step through Javascript code to figure out how something works? Well, I did. I planned to look into the AI a bit and there were a lot of situations where I wished I had the same tools as with C++. Another recent situation convinced me to try figuring out how it could be realized. EDIT: I've put the outdated information below into a spoiler. Get the most up to date information and the newest version of the debugger from this wiki article (or read the whole thread). http://trac.wildfire...scriptDebugging javascript_debugging_WIP_v.0.1.diff