k776

Here's my info. Hope I did it right. I manually set the shader in local.cfg before starting the game, to get as accurate info as possible: Shader: 15 FPS, 62-65 msec/frame, 170-200 msec/turn (fairly stable) VertexShader: 11 FPS, 85-87 msec/frame, 171-250 msec/turn (constant jumping between high and low) Fixed: 13 FPS, 76-78 msec/frame, 155-230 msec/turn (constant jumping between high and low) So shader has a better FPS and msec/frame, but it is beaten by fixed when it comes to msec/turn.

Mine started off as kieran776, and that's still used for my emails. But I shortend it for two reasons: 1) back then (I was 13 y/o), I didn't want people knowing my real name right away 2) no one could remember how to spell my name :-P k776 was a lot easier for people to remember. So I use k776 all the time now, with the exceptions of my email (which I kept longer to prevent spam) and forums/games that require a username longer than 4 characters

Additionally, if you've done an 'svn update', you must also rerun ./update-workspaces in build/workspaces, and recompile the game. Simply doing an svn update and this trying to play the game without recompiling will not work.

Far more active projects have made the switch from SVN to Git, like Ruby on Rails (https://github.com/rails/rails) and JQuery (https://github.com/jquery/jquery), and they coped with the work required to get people up to speed. So compared to them, the effort for us to switch to Git is minimal. We only have about 5-6 people committing at the moment. Not if we amend the documentation. The only change for someone who just pulls the code to play would be changing from a 'svn update' command to an 'git pull'. But wouldn't it be best to do that now, when the need isn't great and the amount to people who need to swtich are few, than wait till we have 2x/3x devs (maybe) and make it nearly impossible to switch? At least by doing it now, those who haven't used Git will have time to get used to it, and those new to the project won't have to worry that we ever used SVN. And I'm always available to help on the IRC if someone is lost. Significant? The mirror exists, I can commit to it right now if I needed to. All someone has to do is clone it, and they can commit too! At most, you spend 45 minutes downloading the source again, but then you're good to go. It's not significant effort at all.

I've been hosting a mirror of the 0 A.D. source code for some time now on the popular Git hosting website, Github. See https://github.com/0ad/0ad With Philips recent graphics proposal, it got me thinking that it might be a good time to migrate to using Git as our code management system. Philips changes are going to affect every player (for the better or for the worse), and I'm a strong believer that the main branch of a project (trunk/master) should always remain stable, and working, in case a user grabs a copy of that code to try. We don't want them to have a first time bad experience because of some in progress code. As Philips changes are implemented, it could be some time before all kinks in the new system are worked out. Even if Philip completes the work locally first, he won't know if it works for others until he commits it, at which point, it could then break for users when it should be working. So I proposed using a branch to keep the changes in until they were stable and tested. However, SVN is notorious for having poor branch/merge support. We need something better if we're going to do that. This is where Git comes in. The biggest issues I've heard on the switch to Git are these: * Windows users cant use it - This used to be a problem. When git first gained popularity, you needed a command line on windows to use it. However, there are a few decent tools now that work on Windows (including a TortoiseSVN clone called TortoiseGit - http://code.google.com/p/tortoisegit/). So you don't need to worry about alienating users. * Git downloads the whole history - Yes, but that can be a good thing. Taking a look at old commits or the commit log is much much quicker than it is with SVN. And at the end of the day, you only end up downloading about 20% more IIRC (last time I checked). It's not several GB to download, only about 500mb. IT also downloads quicker. From our current SVN, it takes 6 hours to do a full checkout. With git, 45 minutes. Not too shabby! * Autobuilds can't commit to the repo - This is true, and while it could be fixed, Git's 'download all history' nature would mean each autobuild would be committed and downloaded each time. Not ideal. Instead, we can easily create the binaries and upload them to Github's download page. Users simply download the latest binaries and put them in the right directory. Not difficult at all. * There is a learning curve - Sure, there always is with new stuff, but it's not by much. And I'm very familiar with Git, so I'd be here and on IRC to help with any queries. What we gain by switching to Git/Github: * Excellent branching and merging support which will be very handy for multiple devs to support multiple branches of work, and easily pull in changes made by other devs. No more time consuming patches or single person development! Multiple people could work together on the same thing! * Ultra efficient history packing (20% more, you get all 8 years of 0 A.D. commits). Getting new commits after that is super small/fast too. * Github.com is an excellent Git hosting solution. The socialness of it makes contributions extremely easy to do. An interested person simply 'forks' (github uses the term for duplicating the codebase to your own account) the code, makes the change, commits and pushes it (unlike SVN, a commit doesn't go online until you push the code) and sends us a 'pull request', a Github feature which has file change view (per file), code change view (per line) and comments (for discussion, really good for feedback on things that need improving). Overall, it'll make the contribution process for interested devs more streamlines (no more trac or tickets to have to manage, just make the code). What does everyone think? Is there any solid reason why can't at least try use Git, maybe for a week? If it doesn't work out, it should be fairly simple to make a patch of all the changes in Git and apply them to the SVN if we decide to go back to that.

I personally think silhouette2 is nicer. silhouette3 looks more like a painting on the side of a building if the unit is fully behind the building. Maybe an option to toggle between the two if it isn't difficult?

I believe thats Up Down Left Right (the keyboard arrow keys)

Not sure I like the full solid colour. So but

Wouldn't it be easier to just include the boost h/cpp files we use into the 0 A.D. source and compile them?

Brilliant! Keep committing them! Along with the ground bridges, there is going to be some pretty sweet maps coming from this.

Have a look at this: http://trac.wildfiregames.com/wiki/MacBuildInstructions I wrote it recently. Hopefully should work for others.

To me, the most important thing would be getting to a point where doing these things is easier. From what I've read, we have like 3 different renderes for shadows, 3 for water, and more.... ideally there would be just one well written one, which scales on older hardware by downscaling the quality of things. So getting something brand new to build upon would be great! I'd be happy if performance just stayed the same for the moment, though utilizing new features in graphics cards should make things faster? Then, from there I think the important ones are (in order): * Hiding changes in FOW, but using a "last known" state to display, which is updated when they next go there (#599) * Showing units hiding behind buildings (#144) * Gradual FOW peel back (#732) * Particle system in place, so that we can have: * Ground effects (flowing grass as units walk through, fires, flowing water, water falls) * Sky effects (clouds, rains, lightning, wind)

This is the new RSS feed URL. http://www.wildfiregames.com/forum/index.php?app=core&module=global&section=rss&type=forums&id=1 (it'll be shortend eventually).

Very nice :-) The pledgie only has $179.00 left before we hit our target. The community support has been great!

Thread locked. Please make a new thread in the applications forum if you wish to apply.

Hey, Thanks for your interest in the game. The best thing to do is just jump in and start coding. There is some info here: http://trac.wildfiregames.com/wiki/GettingStartedProgrammers (may be outdated) Just checkout the 0 A.D. source code, and then choose a ticket that isn't already being worked on, and go for it. Once you're done, submit a patch, and one of the devs will review it. Depending on the quantity and quality of your contributed work code, you may, in time, be asked to join our development team. If you have any questions, there is a Development and Technical discussion forum, where one of our devs would be glad to point you in the right direction if you get stuck. Regards Kieran

That information certainly looks like it'd work, so there won't be a need for a callbacks system inside the C++ code, but it's still a low level interface for JS API.So now it needs JS to parse that info and send out events as needed. You just pass the relevant information through the events system. For example, if you want to test a unit was killed really quickly, for the above information you posted (+some more info would be needed), and with a decent event system, this'd work: on('unit.attacked', function(info) { if (info.unit.health_last_turn == info.unit.max_health && info.unit.health == 0) { // unit was killed so quickly! serious threat? Chat.post("Grr!", info.attacker); } }); It's still a pretty basic example, but basically, they should be able to have access to inspect anything related to the event (so a unit who is attack send who attacked them, where they got attacked, their old health, their new health as shown in the code example above).

The new instructions use Homebrew, the old ones use MacPorts. The new doc is just a place for me to put my install instructions.When someone else confirms they work on a new laptop, I'll probably make the old instructions link to the new page.

Hopefully soon. The AI is on hold at the moment. There are a few other things that need finishing off before the AI system is worked on again. There is no difficulty setting in game. But AI will be made that are harder. They won't be in the next release though.

WOOO! It works on Mac again. Hopefully with these instructions, it'll make compiling for Mac users a lot easier :-) http://trac.wildfiregames.com/wiki/MacBuildInstructions Edit 1: Aww, so close. I can load the game and submit my user details, but when I go to play a map, I get this: http://pastie.org/1599061 Here is the profile I got from the Mac. http://feedback.wildfiregames.com/report/user/2af9e2ea0a3e9dd5ffee421a14999d79e76e7f3e Any ideas? Edit 2: Talked with Philip on IRC and it turns out the error came from toggling from full screen to windows mode. A new ticket was made to handle it later on.

You can get the latest release from http://trac.wildfiregames.com/wiki/LatestRelease If you have windows, you can also checkout the latest development version of the game and play the auto built binary, to check out the latest features.

Hey, thanks for your comments. - faster building: What do you mean by this? Do you mean the speed of which things are built? If so, the values are subject to tweaking before the final release. I would not worry about these for now. - new nations: There will eventually be 6 nations. The next nation will likely make it into the Alpha 5 release. - campaign: yup, it'd be nice. Likely to happen further down the track though. We need a decent AI first, and then the actual campaign system. - easy modification of settings: Also would be good. But we need to get to a point where the settings are set in stone, else we'd just be changing them too often

I have posted info about this here: http://www.wildfiregames.com/forum/index.php?showtopic=14488 Please try to refrain from opening multiple topics around the same thing.

I just tried to compile the game myself, got as far as opening up the game executable, and the same thing happened. The game had no GUI, it just printed some LC_* messages and did nothing. Compiling threw no errors, only heaps of warnings from spidermonkey. I also remove atlas from the update workspaces script to it could compile. Not sure what's going on here. Here is the backtrace from GDB: http://pastie.org/1597119 . It seems to hang in timer.cpp:152 (the 'fin' command never eturns to another gdb prompt). A quick search shows this file was changes since Alpha 3. http://trac.wildfiregames.com/changeset/8515 and http://trac.wildfiregames.com/changeset/8516 . All changes since revision 8000: http://trac.wildfiregames.com/changeset?old_path=ps%2Ftrunk%2Fsource%2Flib%2Ftimer.cpp&old=8000&new_path=ps%2Ftrunk%2Fsource%2Flib%2Ftimer.cpp&new=8973 However, if I revert those changes, update workspaces, and recompile, it still doesn't work, so there looks to be multiple regressions :-( P.S. I've written up a guide with some very simple and quick instructions for Mac users. http://trac.wildfiregames.com/wiki/MacBuildInstructions

Indeed. We only deleted accounts as far back as Jan 1st of this year. Anything before that remains undeleted (for now, if we get spam from people before that, we'll prune it back further, so it's still wise to post).