Leaderboard

Seleucid walls based on that article on the fortress on mt Karasis (corner-body masonry details)

Really not. (but that is also because I had a different PC back then) I find 300 is too high to play with (ain't fun no more). I myself prefer 100~150. (roughly the same amount I had with AoK.

Yes Lion Enjoy the Choice

If only the host would calculate the data, that would mean he has to send the entire state to all other players every turn. And the gamestate can be huge. A zipped OOS log (which contains the game state and is compressed) normally has a few hundred kB, up to even MB. Since a turn in multiplayer takes 500ms, that would mean the host has to be able to send at a speed of at least 16Mbps for one opponent. And 112Mbps to support 8 players (these are way above the normal speeds for regular customers). Only to have the data arriving 500ms later at the clients than at the host, so giving the host half a second more reaction time. Next to that, it would also give the host the ability to cheat by modifying the game state. So non-synced gameplay isn't really an option. Threading would indeed help, but the simulation should always stay in one thread, to guarantee determinism. Other things (like rendering or AI) can be split off to different threads.

http://wildfiregames.com/forum/index.php?showtopic=15796 I'm not a developer, so I can't give you more detail on how far this has progressed. Since everybody is working on this in their spare time only, it is hard to say when the problem will be solved.

Radagast made it possible though. See the modding section

You can delete a object with "fn + backspace" in mac , btw Im in osx and develop must over atlas if you need something let me know

The walls are perfect. Not sure about the fortress though. Do you have any documents supporting that fortress design ?

After testing: unfortunately no Would be a nice feature to have though.

Hi Radagast, 0 B.C. looks promising! To start collaborating in the best way you may want to submit some of the 0 B.C. patches and attach them on a trac ticket. You may start to do it for patches that fix bugs or add features that should be common in both 0 B.C. and 0 A.D. (some 0 A.D. features are listed in GameplayFeatureStatus, GSOC_Ideas or other wiki pages, existings tickets or already discussed and approved on the forum). Then the patches can be reviewed and eventually merged in 0 A.D.. Some patches may take a bit of time before being reviewed and merged. This way both projects could benefit.

Just some 0 A.D. related input on the paper: the selection size can be increased by changing the value of MAX_SELECTION_SIZE in binaries/data/mods/public/gui/session/selection.js, and the game is under GPLv2+ (or any later version clause). Apart from that quite interesting read.

Hey! I am one of the authors of this paper. I'd be happy to answer any questions about Castle. fcxSanya is right about the general idea behind the system. The idea is to use video games to establish covert communication channels that are hard to detect. This WIRED article did a good job of explaining the ideas behind our system: http://www.wired.com/2015/04/app-hides-secret-messages-starcraft-style-games/ There's more to come from Castle! We're specifically targeting making Castle a Tor pluggable transport by the end of this year. A little note on the relationship between 0 A.D. and Castle: 0 A.D. is our go to game for demos. While we have Castle working over other big titles, we cannot release that code for legal reasons. However, we do not recommend using Castle over 0 A.D. in the real world, due to the lack of encryption and authentication of the move communication channel. The good news is, Castle is highly adaptable and can be moved over other RTS-games in about a day, if required.

When this issue is fixed, your problems should be solvable: http://trac.wildfiregames.com/ticket/3208#ticket It won't be hard to fix it I think, so anyone willing to try is welcome.

That's for two reasons: 1. Overshooting a balance task. Quite often, a balancer focuses on something that's OP or UP, and fixes that, but goes too far with it, and doesn't have time to investigate new strategies (that should still work, but that shouldn't always work). 2. Adding new features. Every feature added and even some bug fixes (like fixing the infinite chase issue) severely changes the balancing of the game. A19 won't be balanced very well either, as building capturing is completely new (and that determines gameplay for a big deal). It's hard for us to come up with a lot of new strategies, and compare them to each other to see which ones are OP or UP.

I do not understand how it is possible that a group of volunteers in their spare time have developed this great game, best game of strategy and being found even in alpha stage, very complete with great gameplay, great graphics aspects and fun for everyone. I compare them with other games that have professional staff and many means which you have to pay and do not become nothing good, strategy games today in my opinion are in decline, but 0AD is exactly what I missed at fault, it is the perfect strategy game. I would like to encourage all developers with this project and thank them, and for us players we should collaborate with donations as far as possible from each. Thanks.

We wouldn't be able to buy a lot, and I don't think players would actually benefit from it. Players would benefit more if someone could actually work long-term on some difficult part of the code.

Note that it is currently possible to impersonate other players by sending network messages (commands) on their behalf, and that is something that should be fixed. There is a TODO in the server code about that. I think that would be a reasonable place to start.

Game balance changes from version to version. In A16, the only way to win was by going for a rush, and the first one to rush his opponent won. That was even worse than the current situation, since successful rushes meant that nobody ever reached town phase, and thus a vast amount of artwork was never seen. Over-compensating isn't that strange, and we tend to go towards an equilibrium I think (as far as no new features are added, like capturing).

The best donations you can make is actually donating your time. You can try to fix bugs or annoyances you see (be it in the graphics or in the code), or even go further and make new stuff (again, either graphics or code). Money donations are welcome, though of less value. We would need a lot of money to actually hire someone, and only hiring a single person usually involves a lot of paper work, so we tend to lose more time than we win. We also need money for some resources (like the server hosting some stuff), though that's just maintaining a pretty fast computer with a good internet connection. So not that expensive either.

Mention it to the moderators and they should be banned if your report is confirmed. More advanced host tools will most likely come at a later point.

Hello av93, the pathfinding development is coming along. When it's in better shape I will make a public announcement to make players test it, to fix possible bugs before inclusion to the game. If you don't have news, it doesn't mean it is stalled, it just means trying it right now would be a tad disappointing!

New a game, reproducible. I played on a saved game from a version before 16548.

If you protect your computer that's enough protection Our network model is made so that only the player commands are send. From those commands, a deterministic game state is made, and every few turns, the states of the different players are compared. Thus the state of other computers can't be altered directly from the network, but only by commands which are validated locally. And as a result, modifying the game state on other computers is practically impossible. Though having "unintended cheats" (valid commands that aren't meant to be valid) is always possible, it can be fixed quickly when we notice one. The only thing we can't prevent however, is data leaking. Since the entire game state is on the computer, and all data can be read without any part of the game noticing it, the game can be visualised completely, even when some parts should be fogged or otherwise unknown.

Thanks for the votes, it just get updated and alpha 18 will be in Ubuntu 15.04!

Note: the corresponding Trac ticket: #3164

If you want to see Alpha 18 in Ubuntu 15.04, you may vote (mark that it affects you) and comment here. (Unrelated, you may also want to do the same with Unknown Horizons game here).

We'll discuss this further soon. I've made some better columns for seleucids. Overall the texture you made is quite good, I'm going to touch some values and probably make it 2048*1024 to have some more room for more stuff

Ignoring most of your post, but I have to answer to this part: Commits including code you contributed (full listing): r15150, r15677, r15699, r15868. There are some patches on trac that were applied (and are in the above listing), or they did get a review and weren't improved and thus aren't going anywhere, or the ticket was just invalid. Yes, commits can be reverted, but patches can be improved before they are committed and as can be seen you didn't do that. Code contributions (patches) say more than long forum posts and judging from yours your demand for source access, the demand for getting an answer in less than 8 hours, and the above rant some 3 months later is presumptuous at best.