k776

The pledgie needs more advertising. Tweets, in peoples forum signatures, homepage news posts etc, maybe in the IRC welcome message.

Hey, My name is Kieran. I'm the Open Source Development Manager. Thanks for your interest in the game. I guess if you wanted to find the slowest part of the game, you could profile the map "Combat Demo (huge)". It has many units, and once they start fighting, not many computers will be able to keep up with it. Mine (4GB RAM, 1GB graphics) slows down from 40 FPS down to 1 FPS. I haven't profiled it myself, but the slowness may be mostly due to the path finding & line of sight calculations (including enemy proximity detection). If you want to have a go at optimizing the game in general, starting with the slowest things, that'd be very much appreciated. Regards Kieran

Incase you missed it on the page, there is a line that says: "NB! Below is not yet (2nd October 2010) updated for the latest version, so the information may be inaccurate!" Things below it, including the commands you posted, are either no longer in the game, or no longer supported.

But like I asked, they could be avoided by adding everything to the AI class? So the only thing that'd need to be unique is the AI class name? If so, this could be easily recommended in the AI scripting guides.i.e. Instead of this: MAX_HOUSES = 30; function CustomFunction() { /* snip */ } We recommend: function DummyBotAI(playerID) { /* snip */ } DummyBotAI.prototype.Max_Houses = 30; DummyBotAI.prototype.HandleMessage = function(game, entities, events, terrainAnalysis) { /* snip */ } DummyBotAI.prototype.CustomFunction = function.... That'd work ok, and prevent any collisions, right? Agreed. Once AI are set, they shouldn't be able to be changed. However..For me, it's very important to be able to have multiple AI's running during the game. Eventually, each AI would have a difficulty rating, based on the complexity of the algorithms it has to respond to user events. i.e. a map with 3 AI players, one should be able to be set to easy (DummyAI), one to medium (GoodAI), and one to hard (StrongAI) or any combination. The player would choose these in the game setup screen. See Globulation 2 (Glob2) for an example on multiple AI's in a game (it's undocumented, but in Glob2, AINumbi < AICastor < AINicowar <AIWarrush). So in summary: Instead of a setting for difficulty, the AI themselves have a rating of difficulty based on how much they can do. And the player can choose different AIs for a different gaming experience (as each will act differently).

We're currently using Paypal for donations, and a service called Pledgie (http://pledgie.com/campaigns/14160), which directs money to that paypal account. Flattr looks interesting. After the Pledgie has ended, I'll take another look. However, it does look like it's a regular payment thing, which most people may not want to get involved with.

Looks good, and describes nicely how I thought it might work myself. Nice work! The only concern I have is the mention of constants.js. If all those JS files are loaded into a global scope, constants like that would be overwritten by the next AI constants file loaded right? So everything would need to be either in the AI json file, or in the AI namespace for anything to work without being clobbered?

I think the hard drive was intact, and can be salvaged. It'll just take time. Meanwhile, we have a couple of other 3D artists doing some great work. The aim is for Alpha 4, but it'll probably be a very basic implementation, that others then can work upon.

Hey Ruben, Thanks for your donation. I have given you the special "Donator" badge on this forum, along with added your twitter account to the 0ad donators twitter list. Thanks again. Regards Kieran

There was a new civilization planned for Alpha 4, but one of our main art contributors had his computer crash, so it might be pushed back to Alpha 5. Time will tell.....

@Jeru Great. If you can add a list of any other ones you update since you made that list, and also add the version each website refers to (i.e. A1, A2, or A3) so it's easy to see at a glance, what needs updating. Then I can help out by submitting updates to the ones that haven't been done yet.

Yup, some very keen donators. Here are some stats: Total Pledged: $824.00 in 10 days Average Pledge: $22.89 Largest Pledge: $100.00 (from two people) Smallest Donation: $3 With continued advertising of the pledgie, and if we get a few more Linux Games sites doing interviews (who's in charge of advertising? i.e. who submits 0 A.D. details, if anyone, to various game sites?), it looks like we could easily hit the $3,000 target.

I had a similar issue when I first found 0 A.D. and compiled from source. The menu was slow (mouse movement took seconds to update), and disabling water and shadows had no effect, turning off full screen didn't change it, enabling/disabling S3TC had no effect either. And updating to the latest drivers that Ubuntu had for my graphics card caused screen flickers, and didn't solve the slow mouse issue. (I resolved it by buying a new computer with Windows 7, the issue on my other computer was never resolved :-()

Hmm, sounds good, except, my vote would be to go with a restful web service written in Ruby on Rails, backed with MySQL. A request hits /report on the app, stores the plain JSON plus binaries into a raw_reports table. A background job is fired off to analyze the data outside the request and record the information it find into a processed data table. A further background job is then fired off to look for patterns between similar data sets and store them in an aggregate data table. This is something I could quite easily handle, as my day job deals with such technologies and data processing techniques (albeit, I handle bank data, not crash reports, but the methods of storage would be similar). A defined JSON response would be handy. It would contain game version and date at the top level, then nested hardware attributes, along with what other sorts of data? Here is a taste of what I mean: { "version": "Alpha 3 (Cerberus)", "date": "2010-12-12T16:14:32+13:00", "hardware": { "os": { "major": "Windows", "minor": "7", "version": "7.123.4567" }, "graphics": { "model": "Nvidia", "make": "GForce", "version": "R4z3r", "revision": "4.56.124", "memory": "512" } } } Feel free to copy and add to, so we can get a final version agreed upon (cause the worst thing in a developers life is changing specs! :-().

We won't know what's in Alpha 5 until toward the middle/end of the Alpha 4 development. At that time, we'll decide what features aren't going to be done in time for Alpha 4 and push them back. If we find a shortage of work, we'll pull in some from the backlog. Since Alpha 3 and Alpha 4 are set to be very feature heavy, there is a good chance that Alpha 5 will be a short release to refine things (cleanup, bugfixing etc). Time will tell.

So you need something simple, clean, and small. Personally, to achieve that, I think it'd be good to move the minimap to it's own place, in the top right corner below the menu bar. Then increase width of the other panels at the bottom in order to decrease height. You end up with something like this: https://skitch.com/k776/rb781/0-a.d-redesign-idea Obviously it's a rough sketch (someone with better arts skills could probably blend the minimap a lot better), but the main idea is it decreases the bottom panels height by nearly half, giving more screen space. It also isn't tied to the minimap, so the panels can hide when nothing is selected, and the minimap won't be stuck about 1/4 of the way on high res screens (like mine).

I've created tickets for the things Michael mentioned: http://trac.wildfiregames.com/ticket/678 http://trac.wildfiregames.com/ticket/679 http://trac.wildfiregames.com/ticket/680 The only one I think is important for A3 at this stage (seeing as we have so much other stuff waiting to be started), is the 'run simulation' crash. If you could provide more details about it in the ticket (#680), and attach any crash logs, that'd be good.

Units themselves can't actually go outside the map, so this shouldn't be a problem. As far us (the player) seeing the edges, it's needed because of the GUI. If we stopped at the edge, the GUI controls would cover some of the map.

maximinus-thrax, make sure you compiled in Release mode (not debug) and also disable water reflections and shadow, to see if that helps. If not, you've got the same issue I did when I was using linux. Spent weeks trying to get it working. Eventually gave up and went and bought a Windows 7 Laptop :-P (which runs it really smoothly)

I can make a "Artwork" ticket type on Trac to help filter through them from code change tickets. Think that would help? Edit: There is already a "Game Art" component on Trac which helps to sort the tickets. Is there a reason Trac isn't working for you?

If you need help with the web service to collect and store the data, I can help out with that.

foesto: Close 0ad, then: * If you are using Windows, remove %appdata%\0ad\cache. %appdata% on my computer, with windows 7, translates to C:\Users\<UserName>\AppData\Roaming\0ad\cache. I believe Windows XP puts it at C:\Documents and Settings\<UserName>\Application . If you can't find that folder, do a bit of Googling. * If you are using Linux, remove ~/.cache/0ad, which translates to /home/<UserName>/.cache/0ad Then restart 0ad. There is a fix in the latest development source of 0ad for this issue, so the next release shouldn't encounter this issue anymore.

I don't see why any of these would need a certain number of units selected to work. Maybe they won't be effective without more units, but the formation should still be able to be triggered.

Did you recompile? The changes may require a recompile, so using the autobuilt pyrogenesis binaries might fail.

There is, but you need higher permissions.

I had a similar issue with Ubuntu and a fairly powerful computer. ~2.8 ghz processor, 2GB of ram should have been more than enough to at least load the menu, but even the menu was slow. I'd move my mouse and it would only update every second or so. I finally gave up, and bought Windows 7 :-P