k776

Provided you have tested it as much as you can on mac, linux, and windows, and found no issues, go ahead and commit when you have a few hours afterward to fix up any issues that the team finds.

Very nice :-) I don't have time to work on the one I started, so I'm glad someone did.

Sure, but it would be handy if the debug server provided a URL which listed all current breakpoints... /GetAllBreakPoints , and in simple JSON: [{file: ..., line: ...}, {file: ..., line: ...}]

This thread is public but only reply to it if you have the skills needed to contribute something useful. Any posts that don't add anything to the thread will be deleted! The game is getting to a point where the speed is really killing us. We need to find ways of speeding up the game, and doing so within the next release or two. Lag causes players to give up and leave. We need to start attracting fans to play regularly. So the point of this thread is to discuss, collect, and action on ways we can actually speed up the game. Found a really slow part of the game? Post where it is and some ideas for improving it. Working on something to speed it up? Post about it an get feedback early. This is now top priority for all developers. Other work can continue, but you should be working together to get the game faster. Communicate, collaborate, contribute.... Here are some ideas/tickets to get things started. Finish developing the new path finder - http://trac.wildfire...com/ticket/1756 The new pathfinder is designed to be faster and give closer results between long range and short range path finding. CCmpRangeManager optimisation - http://trac.wildfire...com/ticket/1707 Implement an Octree - http://en.wikipedia.org/wiki/Octree Rewrite the AI base system in C++ - AI are very slow. From what I understand, several systems are implemented in JS when they would be much faster in C++, e.g. building placement needs to copy data from C++ to JS and then loop over the data. Move as much of the AI system to C++ for speed. If we keep the javascript AI system then a fairly simple improvement is to make the entity collection updates use the heirarchy of entity collections to save significant work. boost::unordered_map is potentially faster than std::map in some situations. This is now serializable so should be very easy to change (it won't even break multiplayer sync because it serializes as a std::map). I don't know if there are any situations currently where this would help though. (Except for CCmpRangeManager, but the proposal in the ticket is better for that). Here are things which could be done but hopefully won't need to be. This is just a list we can come back to near when we release if we still need to improve: Disable the ability to have arrows hit units other than the one they targetted, this would save looking up entities near to the arrows hit location.

Fixed.

Nicely done. I played around with it for a while and couldn't get it to segfault which is good. I've updated the JS debugger UI to work with the latest implementation, and I've added thread information and stack trace display to it. https://github.com/0ad/javascript_debugger

Ah, ok, interesting. Well, that in mind then, I'm fine with it going either way.

Quick note: The design committee is for decisions that the rest of us can't decide on. You don't go to them for every decision. Each design committee thread should be able to link back to a public discussion in the technical discussion forum (like this one) as proof that discussion took place, got no where, and that the design committee needs to get involved. Back on subject, I think it could depend on the building type. Maybe we add the option into the XML. RequireFullConstruction or something. for e.g. a farm could be built damaged, and you'd only get the % of resources from the % of health it had when it finished building. Same for walls (they build with reduced health). However, some things like towers and wonders make sense to be 100% health. Now, that said, the decision we'll probably go with I think is having 100% health, because eventually, when we add buildings rising up out of the ground during construction, we don't want a half risen building suddenly turn into a fully risen one. It also makes sense that if your enemies are able to keep hitting your construction, you shouldn't be able to complete it at all. So my vote goes toward requiring 100% health to complete a building.

Ok, I have a very crude web UI here: https://github.com/0...script_debugger You can set breakpoints, step, and continue. There wasn't a endpoint to see if a breakpoint has been hit, so the step/continue controls always show. More feedback in the game would be good. When I set a breakpoint, there is no warning the game that it got applied. And it should print before it hits the breakpoint to say "Breakpoint reached", else the game just freezes with no apparent reason (not obvious that it hit a breakpoint). Now, for bugs: I tried calling the /GetCallstack endpoint and I get a segfault. I tried setting multiple break points and I get a segfault. Here is the "bt full" for the segfault when hitting a breakpoint and trying to call /GetCallstack: http://pastie.org/5634255 Here is the "bt full" for the segfault when setting multiple breakpoints and hitting the first one: http://pastie.org/5634267 and http://pastie.org/5634270

I compiled the patch and hit a breakpoint and stepped through successfully :-) So nice work. For the UI, for speed, a single data endpoint would be good. Something that returns the current breakpoint (and it's null if the program hasn't hit a breakpoint yet), as well as the stacktrace all in one call. That way, when I make a request to /Step or /Continue, then I can poll /Status (or /GatherState or whatever name really) and it returns all data in one request for quick parsing. Possible? Edit: Can you also please make sure you keep the first post up to date with callable end points and some basic [clipped] result examples. I'm hoping to get started on something basic after work today. A form to submit a break point, and poll every few seconds to see if a breakpoint is reached, displaying current breakpoint and the stack trace. Finally, a way to send commands to the game. e.g. POST a JS command like "unit.state" which evaluates in the context of the current breakpoint, so we can change something, run continue and see if it worked. It would be a nicer way of checking local vars than printing them all.

Ah, ok. I'll have to look into how it does it.Edit: Oh yup. That looks very doable. Attempting to compile the game in debug with the patch. Will let you know where I get.

Yves, I'm very keen to help with the UI on this. What would be nice is if, in your path, when you hit the root path (http://localhost:9000) it would load an index.html file (which can be blank for now). That way I know which file to modify. Then I'll link in JQuery from googles JS CDN and get to work implementing some buttons which execute the url asynchronously and then updates the page with results.

LOL. I suppose. Maybe just unit count then? First there, but if enemy comes around with two units, they capture it?

@myconid: It really should use chained conditionals to prevent mixed settings. if (preferglsl && gentangents)

I wrote a long reply but my browser went backward and erased it :-@ So I'll be quicker this time. Sheep and goats auto converted. Vision range based on the sheeps, not the capturing unit. And when multiple players are withing range of the sheep, capturing takes into account total unit power/strength, and when that is equal, total unit count, and when that is equal, the first player to get to the sheep.

Yes, that is what we should do. Replace SpiderMonkey with Webkit's JS engine and UI engine... I'm willing to redo the entire GUI in HTML/CSS/JS, but I don't know C++ to integrate the webkit engine into the game.

I wonder what the margin was. It would be awesome if IOTY showed the % of the top 5 votes. I notice Overgrowth may have won, but it couldn't win twice... :-) Someone should find out why Overgrowth is so popular... What was our previous position? 3rd? So we have improved :-) Another year of development, a new path finder, more graphical improvements, improved gameplay, and we're in the running for 1st place :-)

Find the latest one. If it is split into folders, it's the folder with the highest number, and than the commands.txt in that. Right click the commands.txt file, check the properties, and the created at or last modified date should line up with the time you played the game that gave you the JS errors.

I'm not getting involved in this discussion unless it reaches the Design Committee. However, I will say this: We will not be supporting two packages. It's maintenance nightmare. So whatever conclusion we reach, it's either everyone gets it or everyone doesn't.

Please file a bug report at http://trac.wildfiregames.com/newticket and if you can attach the commands.txt of the game that made it occur to the new ticket, that'd be good.

There are some leaps and bounds with Google Chromes OpenGL support. They made a demo FPS which played pretty smoothly. But yer, it'd be a lot of work, wouldn't be cross-browser compatible, and the moment it got popular, it'd struggle to keep up :-)

Done. SF description has been edited.

An interesting idea, but it doesn't work with our free, open source approach to game development. We run donation campaigns from time to time which have been quite successful in the past. Also, finding people to actually do the work is difficult. No one wants to give up their full time employment to work on 0 A.D. for a few months of funded development... For now we'll stick with open source and part time contributors. Thanks for your suggestion though.

Have we cross posted this to ModDB yet? :-)

Looks like the cursor has a bug giving it a black box behind it.