sanderd17

There's a setting for that in the gamesetup, under "more options". But I think cheats are disabled by default in multiplayer games. No, rams have the same lag. But you may have problems with your units trying to regroup in formation. Then they sometimes run back to the main group, which may be an issue if the main group is stuck after some obstacle. You may want to put your units in "no formation" mode to prevent this from happening. Apart from that, rams do indeed a lot of damage against buildings, so once a ram reaches a building, it's already too late. I think that's intentional. There were players postponing their loss by building roman siege walls everywhere, and just garrisoning units in them at random places. Now that the walls decay, such a strategy isn't possible anymore (or at least harder) Phase III is the phase that allows you to actually bring down cities. So the phase that gives you siege weaponry. If the army camps become available before that, they should have disabled siege units while in phase II at least. But I think army camps in phase II would be overpowered, as players don't have the means to bring down a building while they're in phase II. Ranks are disabled for now, to help with balancing. But this depends on how much stronger that higher-rank units actually are. If they're marginally stronger, it doesn't make sense to alter the gui for them. If the difference is big, that info might indeed be important. This doesn't sound so difficult, so if you can program a few lines, and want to help out, it's a good place to start I guess. That count is hard to explain, and can even depend on the structure. For now, AFAIK, all infantry and also ranged cavalry increases the arrow count by a constant, and buildings also have a default arrow count. If you select a building, you can hoover the "attack" icon (the sword and shield in the middle of the selection pane), there you can see how many arrows are fired per time, and how strong the arrows are. The tooltip is updated when you garrison or ungarrison units. So with a bit of trial and error, you can find out a lot. Thanks

It's going in the good direction for sure. I think the more symmetrical ones, like A3 and A15 would fit this civ better. Furthermore, arches are typical Roman, while the Hellenic cultures preferred pillars and flat ceilings. So I think A15 is the best proposal so far. But you still have a lot of options open on how you design the actual sides and the back. You can design the sides as having a roof (like the Greek barracks), or more like thick walls to walk on (like the Ptolemaic or Mauryan barracks, or your A1 proposal). You can design the back with a single level, or as a two-story building (like your A6 proposal). Also see the already designed seleucid buildings (the houses and the CC). Like there are houses with a flat roof available, if you add a flat roof as thick barrack walls, then you should try to copy that style a bit. The buildings should match well together.

You can also take capture points back from your own or allied buildings. So binding it to ctrl will be hard. I think that less choice is better in this case. It's not a standard rts feature, and people will start wondering how their enemy can take over their building, while they can only demolish it. Having it as a replacement for the normal attack is a lot clearer, as players will immediately notice that units can't demolish buildings in this game, but they can capture them. Also note that we still haven't figured out how to switch between ranged and melee attack for those units that can do both. I wouldn't like to make that part even harder. @Karamel, you say you don't want micro, but yet you add all sort of strange rules. Requiring the health to be less than 70% f.e. well cause players to micro their siege units to hurt all buildings down to 70%, and only then start the capture. By ejecting units one by one, the capturing units will be disturbed every time, they'll have to stop capturing to attack the ejected unit. I also personally don't think that any of our units are worth the micro to try to capture them. Apart from siege units maybe. So for now, I have no idea how and if we should do unit capturing or conversion.

Corpses do decay. They sink into the ground slowly, and leave some blood for a few minutes. We don't have the man power to do a more visual pleasing decay for all units. For the other things, they involve too much micro IMO. So it won't make it to the main game, but you're certainly allowed to make a mod that implements those things. It will ask some programming, and might not work out as you wanted, but the things you propose seem possible in a mod.

Apparently, it was a Windows-specific issue, and I couldn't reproduce it. It should be fixed now however.

Are you sure you have the latest version? Could you update and try again?

4 hour games? I don't think I ever played that long. Anyway, if there's suddenly a huge lag spike, and it doesn't go away again, that's normally because of the pathfinder (which is being worked on). Currently, the ai doesn't get a lot of feedback from the pathfinder, so it tries to calculate paths again and again when it's stuck. A quick and dirty solution for this is going via the developer overlay (ALT+D). Reveal the map, and enable the checkbox to control all units. Then look for where it's stuck (usually some big units like rams or elephants). If you delete these stuck units (or the reason why they're stuck), the lag should go away again. It also helps to play on open maps instead of maps with a narrow passage.

We only try to do our best. If you have a better proposal for the GUI that's both clear and historical correct, that would be nice, but we won't sacrifice clearness for a historical correct image in the GUI. And about the Iberian language, if you have better strings, that would be welcome too. But as you note, the Iberian language hasn't been deciphered for a long time, so there are only few resources.

If he uses A18, then that's before any changes to the map format were made. My best guess is indeed a corrupt zip. So either your download went wrong, or the packaging had an issue and the should repackage it.

Style apart, you should follow the U-shaped design for barracks. All barracks are U-shaped, apart from the Roman ones, but the Roman barracks need to be redone some time. Some U-shapes are very symmetrical (like the Greek and Carthagian), others are more organic, but also show a U-shape in some way (like the Gallic barracks). For the style, the Seleucids were Macedonians that conqured and settled in Persia. So architecture would be based mostly based on a combination of those two. Similar to the Prolemaics in Egypt. However, the Seleucids did find their Hellinistic values and knowledge superior to the Persian (in contrary to the Ptolemaics, who wanted to be true Egyptian pharaos). So most of the style influence should come from the Hellenistic styles, while all the materials they used should be local (so very little white stone).

Did you save the game using the same version as the version you use to load it? Also, next time, please keep your post length down. There are other sites to share large amounts of text (like http://pastebin.com )

Supporting all window managers around is hard. And not all devs have multiple monitors, or use them together for gaming. In any case, you can press ALT+ENTER to switch between windowed and full-screen mode. So that saves you the killall step.

See http://wildfiregames.com/forum/index.php?showtopic=17730 as a start The hippo has a thread, and in that thread, you can see the progress. Making the actual mesh is usually the first step. After that, it needs to be textured and animated. Apart from that, before you work on something, it's best to search through the forums first. Someone might have started but not finished the work. And also open the map editor and try to see if the animals are present. It's not always finished when they are present. Many animals in the game editor are still missing animations. I hope this helps a bit.

Welcome. You seem to have a lot of usefull skills for the development of this game, and similar mods. Do you plan on helping us out with some stuff?

It's the GUI that determines how big batches are for players. So you could do that by modifying the GUI (even in multiplayer games, as the GUI isn't synchronised). And since the AI doesn't use a GUI, it can use any number it wants. I personally don't think that batches of 2 or 3 are needed. If you don't have the resources, it's better to pop them out one by one, so they can start gathering faster. For the AI, it has the advantage that it makes it easier to assign tasks to the newly popped out units (as they come out in groups).

This is planned: http://trac.wildfiregames.com/wiki/Audio_Voice_List However, it's hard to achieve. Since ancient civs didn't own very good audio recording tools. We'll always need to guess the pronunciation. For some civs, we don't even have many written sources. Next to actually learning the pronunciation, the one doing the recording should also have access to some sort of semi-professional audio studio, and should have a good vioce. And on top of that, since not all soldiers should have the same voice (and females should have a different voice for sure), we need many recordings from different people. This has been requested many times. But it would complicate the pathfinder a lot. And you might know that we already have issues with the pathfinder (lag, inconsistencies, ...). So don't expect this feature in the next few years, even if it's one we dream of too. Too complicated for the main game IMO. Also too much micro. Maybe mods that focus more on single units could implement this. Remember that we're volunteers. Writing and producing music takes a lot of time. We're happy that Omri does such a good job at writing music. He manages to make a few new music pieces per year. There currently are already 32 pieces recorded.

Normally, bans are temporary, unless you've been banned multiple times. I've not seen the actual situation, so I can't judge it. But who was the moderator you talked to?

Well, currently, rams are auto-manned. That is, if you create a ram, the man-power you need for it is also included. Rams should indeed be very vulnerable to infantry attacks. When they can attack the ram directly, they should be able to destroy or capture it quickly. This could be done perfectly by making rams easily capturable.

The name has been changed about 7 years ago: http://trac.wildfiregames.com/changeset?sfp_email=&sfph_mail=&reponame=&new=6175%40ps%2Ftrunk%2Fbinaries%2Fdata%2Fmods%2Fofficial%2Fentities%2Funits%2Fcelt_infantry_javelinist_b.xml&old=4862%40ps%2Ftrunk%2Fbinaries%2Fdata%2Fmods%2Fofficial%2Fentities%2Funits%2Fcelt_infantry_javelinist_b.xml Though the reason or source for the change is not clear. Also notice the spelling difference between the name we use, and the names in the articles.

Null pointers are hard to fix. We need to be able to reproduce it before we can fix it. So you should give all information you can. Like does it happen every time (on every map f.e.), does re-installing the game help, ...

AI development (inside the team) is mostly done by one person at a time, and he also controls the AI-to-game API. Many of the AIs are forks from older AIs though. Like qBot was made by quantumstate, then AegisBot was based on qBot, and maintained by wraitii, and now we have Petra, which is based on Aegis, and maintained by mimo. There's a bit of documentation about the structure of the bots and the API available on the wiki: http://trac.wildfiregames.com/wiki/TDD_AI . However, parts may be outdated or missing.

We don't have a lot of experience with organising events. Our team and community is spread out over the world. We even have difficulties to find good hours to hold online meetings. I'd certainly recommend to clearly communicate to your audience about which version of 0 A.D. to use, and let it install before the workshop (as 0 A.D. is big, and installing it will take time). We always advise to develop against the SVN version, however, it's always possible we break something in the latest commit, so you should assure to yourself that there's a recent and working SVN revision in that case, and revert to that revision when needed. For the purpose of teaching things, you might also prefer a more stable version from the start. If you want to chat with us during the event, you (and your audience) are always welcome at #0ad-dev on quakenet. However, if there are a lot of connections from the same ip to quakenet, quakenet might block your ip. So it might be good to check the limits with quakenet if you want to make use of the chat. I must certainly thank you for organising this, and I hope we'll get some new contributors indeed.

Hotkeys are easy to modify in the settings. But if you have a proposal for a more standard hotkey set, that's always welcome.

I think the comment from fcxSanya was a valid one. You can't get results from grep back if you spell it wrong. And it's important for everyone who helps out here that they see the command given was invalid. The bold text also isn't agressive if that's what you mean, it's just used to highlight the difference.

Go to gui -> loading -> loading.xml. That XML file defines the gui setup for the loading screen Inside that XML file, you find different sprites being used for the loading bar. Namely: LoadingProgressBarBackground, LoadingProgressBarLeft and LoadingProgressBarRight. If you then go to the sprites (gui -> loading -> sprites.xml) and look up those sprites, you see which textures are used in the loading bar. You can either replace the textures with your own, or remove the image object from the sprite you want.