sanderd17

A mod will most likely only work with a certain version of the game. So it's best to use a version control system to develop it on par with our changes. And then, when we release a new version of the game, you can also release an easy-to-install mod zip for that version. F.e. you can use git as a version control system, and upload it to a repo in github, where all testers can download it. And as niek says, try to keep your mod as small as possible, only include files that you actually changed. Only the mod.json file is needed to load your mod, and contains the mod description.

We try to interfere as less as possible in mod design. So no, there will be no team member taking this task. It would also be considered very rude to just take someone elses model and cut the original creator off.

For current balancing, our units seem to be too cheap to capture, or actively convert. While automatic converting is a bit strange. Are you really going to invest time of an expensive unit (a priest or champion) to capture a unit that only costs 10 food and trains in a few seconds? Before making conversion possible, we should have more expensive untis, or some other way to make units scarce (and important to convert). Just making them more expensive on resources is probably not viable. But I have been thinking lately. We could disable training of women from all buildings, but every house could give a few women for free on completion. That way, women are scarce as you can't produce any more of them. When they are dead, or converted to the enemy, they are gone. In any case, the gameplay dynamics of conversion aren't known yet, and should be discussed within the complete picture.

The current pathfinder already makes a difference between moveable and unmoveable obstacles. The long range pathfinder doesn't even consider moveable obstacles (since it plans a long time ahead, and anything moveable would probably already be changed by then). But even with non-moveable obstacles, the pathfinder still tries to guide the units to the closest reachable position. Which is a heavy calculation that it shouldn't do if the formation centre is following a more reasonable path.

The formation process is actually: first move the formation center along the pre-calculated route, then let all units walk to their new formation position. But the biggest issue with the formations is that the pathfinder doesn't understand that formations have a size that's bigger than their obstruction. So if a formation walls along an obstacle (like along a shore), then the pathfinder keeps the formation center next to the shore, which causes half of the units trying to reach unreachable positions. If units can stay in their formation positions, calculating their next position is a rather simple calculation, and would be even faster than without formation, as the long-range calculation only needs to be done once for the formation. So the pathfinder should estimate the width of a formation, and see how it can avoid most obstacles for a certain route.

Yes, the old pathfinder could use priorities in terrain (thus could prefer roads). However, it had many problems. Like being generally slow, and also the many inconsistencies between the short and long range pathfinder. So we opted for a redesign that should make the pathfinder simpler and faster. For that, priorities and roads were abandoned. This article explains the new implemented optimizations in a rather easy way: http://gamedevelopment.tutsplus.com/tutorials/how-to-speed-up-a-pathfinding-with-the-jump-point-search-algorithm--gamedev-5818 . It also explains why roads are hard, but not impossible, but I would prefer to first get a working version in game, and only add roads afterwards (when someone wants to work on that).

The problem with the Mac keyboard is that their key labeled "delete" actually gives the "backspace" command. And that the delete key is thus missing from the keyboard. I'm not sure what other keys we support instead of delete.

Did you try something like cmd+backspace? Or whatever funky modifier keys Macs have.

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.

Just letting traders walk back and forth between random markets would be easier. As you can just use the regular trading command in that case. The only thing I'm concerned about is ownership. I assume the traders would belong to gaia, and I'm not sure that gaia traders can trade with player-owned markets. So you probably need to modify something there. To depend more on the traders, I think you should disable the farm field. When you place only a few fields on the map, even food becomes scarce, and you need trade to get some resources.

We try to keep us to civs that got in contact with each other, between 500 BC and 1 BC. Starting from the Roman and Hellenic civs. So mostly centered around the Mediterranean.

There's a lot of artwork that would go to waste when joining the gaul and brit civs again. There are village-phase buildings like houses and barracks made specifically for one of those two. So if they shouldn't be available as a pre-game choice, we'd miss that artwork. When I joined, the situation was actually backwards. A scenario could use the celt or hele civ, but it couldn't be selected for random maps. Of course, that created problems because the celt and hele civs were never properly tested, and were sometimes released with bugs. It's because of those bugs, and the exceptions they always needed in the code, that the generic civs were removed.

You mean productionQueue? Or some other queue?

Yes, we've seen it too. And it's a very strange error. We currently have no idea where it's coming from (and since it's in the graphics part, it's hard to reproduce). But it also doesn't hinder the game a lot.

Yes, that is correct. I'm glad it worked

You can rename the wormhole_skeleton.xml to wormhole_skeleton.xml.backup to test. The engine will load all *.xml files in that directory, so if you add a .backup to it, it should be invisible for the engine.

Hehe, I like the idea of some tetris, snake, 2048, ... in the pause screen (even without highscores). As for the mechanics, I guess a pause should always be allowed if all players want it. So limiting it to twice per player might be too low.

I think it is because an error happens somewhere, and the music thread keeps going while the main thread is waiting for you to resolve the problem. Can you try to run the game from the console, and see if it hangs with an error?

You can go ahead, and make your ideas concrete. Like redesign how the pause page looks, how players can "agree" to each other's pauses, when pauses get refused, ...

When you make a mod, it's better to not copy all files to your mod. If you load your mod together with the public mod (0 A.D.), then the mod manager will automatically prefer your files over the public files, but fall back to the public files when the files are missing in your mod. By only copying the file you modify, it's easier to maintain. Else you'll have to keep up with all changes we do, which can be hard on your own. And as you may notice, the version you're working on is already outdated. The current version uses {civ}_infantry_... instead of athen_infantry_... This is so that buildings can still produce units when captured, but don't give access to units from the enemy civ. Finally, that crashlog line is a very annoying thing. It means we can't see where the actual problem is. But I expect it's still caused because openOffice left some files in the directory that can't be read (like a backup document). The best thing (since you're only started) would be to delete everything, and start over with a clean mod of only the files you modified.

Last 10 days, we did 50 commits to the game. Sometimes fixing small bugs, sometimes adding new features. New units can be added if it doesn't complicate the gameplay too much, or if it's really needed for balancing. Which I doubt for now. Well, thanks to capturing, balance is completely lost now. So we probably will switch between a few rush-only, turtle-only or boom-only games in the next versions. Which is why balance comments on A18 are sadly of low value now. That's just because it's laughable. We all want some humour. Stats are simply defined in XML templates. F.e. the stats of generic spearmen are defined here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/template_unit_infantry_melee_spearman.xml Thanks to inheritance, you don't have to define stats for every unit. You can define generic stats for infantry, a bit more specific for melee infantry, even more specific for spearmen, ... I do advise you to work on SVN, else your work will be outdated by the time you want to publish it.

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.

Option 1: no. it doesn't work when multiple mods want to do the same thing (the file gets overwritten again, and you lose your stuff Option 2: as you say, it's ugly Option 3: again, conflicts AFACS, it's impossible to solve this issue correctly in your mod, we probably need to discuss it and change somewhere else.

Consider, yes, but not put a lot of work in it It's not made uncontrollable on purpose. So if you like to fix it, just go ahead.

The Mauryan warriors should be rather good against buildings (as elephants are only partially siege units, and supposed to be worse against buildings than f.e. rams). But with building capturing in, the whole thing around attacking buildings has to be revised. So it could be possible that we make the warriors have a very strong capture attack, or that they don't have a capture attack, and keep their strong crush damage. But in both cases, they need to be revised in some way.