sanderd17

Oh, and file size would also change in your case (if you resize the map). But perhaps you can only calculate it after transforming the map.

No, the map size is encoded as the 12th to 15th byte in the file, but it should match the number of blocks.

@AtlasMapper, I've never tried it with a cross ethernet cable. Can you reach other ports with that configuration you have (f.e. a web server). Otherwise you should probably have a router in between (doesn't matter if that router is connected to the internet or not). @Money93, can you describe what steps you followed to determine the ip address, and to connect (please as detailed as possible, f.e. say which ip address you put into which textbox on which computer).

@Imarok did you modify the game in some way, or install a mod?

Yes, the local IP ... though being refused may have different causes. Like a firewall on the router or host.

The lobby (aka the chat where you meet other players to set up a game) doesn't support LAN games, but the main game does support LAN. You only need to meet players in another way (which shouldn't be hard, since LAN is local), let the host host the game (via Multiplayer -> host game) and let the others join the game by inputting the host's IP address under Multiplayer -> join game.

The meaning of the different bytes are explained as comments in that script I linked. The first fixed number of bits are some metadata, then you get a huge block of terrain heights, and then a huge block of terrain textures. And I guess that's all.

The map format is binary, so unless you want to edit it with a binary editor, you'll need to at least have a script to do some conversion.

Archers currently give a bonus to ships: extra arrows. So you won't see them on the deck to shoot, but they do make the ship more powerful. It's similar to how buildings become more powerful. And ships can use these arrows when moving. The game dates between 500 B.C. and 1 B.C., and only includes civilisations which were at their heydays in that time (so Samos, Miletos and Crete have a much older culture, and lost important by that time). So the Greece civilisations we try to include are the ones from Classical Greece (and not complete Ancient Greece): https://en.wikipedia.org/wiki/Classical_Greece Where Athens and Sparta were the main civilisations (the Thebans were originally also planned, but later on excluded in favour of more diversity in the game). At that time, the terms Ionian, Dorian, ... were mainly cultural terms. When comparing it to the current day f.e., you could say that the USA, Great Britain, Australia, Cannada, ... all belong to the Anglo-Saxon culture now. But although they are culturally bound, it wouldn't make a lot of sense to put them into one faction for a game.

It should be quite trivial to make a mod that has that behaviour, even without altering the simulation (so you would still be able to play against other players who just use the regular commands).

Meshes, textures and animations can all be found in the art directory: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art Note that our animation model uses a "skeleton" that requires certain names from your animation bones. It allows to reuse animations across different meshes. Maybe it would be nice to animate the musk ox? As next to an ugly texture, it also has no animations so far: https://wildfiregames.com/forum/index.php?/topic/20583-musk-ox-model-texture-enhancement

You would need to modify both: the pmp (which holds the terrain) and the xml (which holds the entity positions). An example of such a script modifying a .pmp file can be found here: http://trac.wildfiregames.com/browser/ps/trunk/source/tools/mapcompatibility/a18_to_a19.py , though that one is more simple. It's used to convert from A18 compatible maps to A19 compatible ones. For that conversion, the height scale was changed (making the resolution of the height smaller, but allowing higher mountains), so I only needed to half (or double) the height. In the comments, you can see how the pmp file is structured. Though to resize a map, you will need to alter different parts too (like the map and file size, and the texture definitions), which may or may not be trivial. Also note that a map should always be square. Other info may be found here: http://trac.wildfiregames.com/wiki/PMP_File_Format Though as said, it won't be simple to achieve.

That's what happens now, they get expelled from the structure, or killed if there is no valid space where the units can be placed. But killing shouldn't happen often on land, but it would happen if ships could be captured in plain sea, and also happens when ships are sunk. In any case, as the game is now, the units never convert to the enemy. Now about the thread in general In my original patch, I even disabled attacking buildings for units. I found it very unrealistic that a few units would just be able to destroy a structure like they do. But anyway, players can now chose to either capture or attack, and the choice ultimately depends on the defence of your opponent. If he garrisons his important structures, it will probably be easier to destroy them, otherwise, capturing would give you more advantage. So it is a strategically important choice you need to make, and we're making a strategy game after all. I do understand that there are some problems with it, and there are some nice suggestions offered here (I particularly like the aura to protect siege engines). But I'm not very good at balancing the micro game, so I won't (f.e.) make a decision on what buildings should be capturable. Though I do still have something l don't like about capturing: That's when players use the capture-and-delete tactic. They don't want to take over the base, but they want to deal economical damage to the opponent. And because the opponent can't defend all buildings, first capturing the undefended buildings, and deleting them when you own them becomes faster than destroying them through the attack command. Another problem with delete is when players delete their buildings just before they lose control over it. Removing the "delete" option isn't possible either. When you've gathered all trees or mines in an area, there's no reason why you shouldn't be able to delete that storehouse, and use the space to build something else. Certainly in dense maps this is often necessary. So my choice is now leaning towards a "slow delete" or "deconstruction" model. Where the player can choose to delete any building he owns (even if he lost almost all his capture points), but where it takes time to delete the structure. Adding yet another unit command to "deconstruct" buildings sounded like it was very bloated (another hotkey taken, other units occupied with certain tasks you don't want, ...). So I opted to keep the delete button, but just make it slower. In the mod below, when you press delete, a timer will start that will continuously take health from the structure, until it's destroyed. But if the structure gets captured or reconverts to the territory owner, the timer stops. It's still very early and unbalanced, but it should give you an idea. I think that this will make the capture vs. attack choice even more strategically, and I hope you like this change. To install the mod, unpack it in your mods directory ( http://trac.wildfiregames.com/wiki/GameDataPaths ), so you have the path mods/structureDestroy/... And then enable the mod in the game by going to "Tools & Options"->"Mod Selector" (don't forget to save your changes). structureDestroy.zip

By all means, go for it. There are a number of animals that would improve a great deal by having a better texture. Try to keep the texture size reasonable though, and make optimal use of the image surface. The design doc advises 128 or 256 px for units (though that may be based on slightly older specs). So I'd guess that would be the same for an animal (as they aren't too different in size or in needed detail). Thanks for wanting to work on this.

Those settings are only useful for scenario maps (where the player can't chose the settings). They used to set the defaults for Skirmish maps, but since the game remembers its settings, that's not used anymore. We're testing A20 now, so the release date depends on the issues we find. It should be a matter of days to test it, include the translations, package it and upload it. There's only one real water level, if that's what you mean (so you can't make a lake that's higher than the sea). But you can change the height of that water level in the environment tab in Atlas. Resizing in Atlas really messes up your map. It just clips the terrain to the smaller size, or it just extends the map with empty terrain. It should be possible to scale it with a script, though this will be a bit dangerous, as the steepness (and thus the passability) of the tiles is guaranteed to change in the process.

Hmm I can still find my replays under ~/.local/share/0ad/replays/0.0.20/... What flavour of Linux?

For which OS are they outdated? And you're right that it will be hard to reproduce (and impossible if we don't have the exact map as you used to play). It will probably be a valid bug (the AI shouldn't error out on an unusual map layout), but as we don't even have the opportunity to test if our fix works, it will be pretty hard to fix.

When reporting a bug like this, it's best to include the replay in your post, so that we can reproduce the issue and see where it went wrong. Though this bug doesn't seem to be related to your actions, but to the AI (something went wrong in its attack plan). You can find the commands.txt under the replays (see http://trac.wildfiregames.com/wiki/GameDataPaths where to find them).

Just come on our #0ad-dev IRC channel, and someone will probably answer (the channel is mostly active during European evening though).

It looks very nice. We're currently in string freeze and feature freeze (though feature freeze only counts for code AFAIK). So it should still be possible to commit it, if you don't change the strings (like the tooltips of the building), but only update the model. In two days we should move to a complete commit freeze though. See this page for the current status: http://trac.wildfiregames.com/wiki/ReleaseProcessDraft

I do like your maps, certainly the visuals. And I think, when they're balanced, they would be suited to be included in the main game. At least in A21, as we're already finalising A20. But I would ask you to drop by on our IRC channel sometime. It would help discussing the map, and speed up putting the map in the main game.

There is a ticket for this already: http://trac.wildfiregames.com/ticket/3837

Parallelization would indeed help, but it won't be feasible on such a small part as the pathfinder. Note that the pathfinder and unitmotion code has to be deterministic (needs to calculate the same path on all computers in a networked game). So if unit A and B both want to move to position (x,y) in the same turn, the pathfinder must have some preference (f.e. give the unit with the lowest id preference). When parallelizing it, there's no preference anymore, and it all depends on OS scheduling. Next to that, the pathfinder is also rather memory heavy (it has passability maps for different unit classes, and evaluating all nodes is also memory heavy). When parallelizing something, you have the problem that you need to copy a lot of data around to the different threads. So it's better to not do it on memory heavy. I see more promises in splitting off the AI to different threads (which already has a good separation of memory, so it can't modify the simulation directly but only by giving commands). Or the parallelization of not components of the game that don't have to be serialised. Like the 3D rendering, or the GUI rendering. @sarcoma, your memory issue is probably a valid bug, but one that's very hard to debug. We probably also still have some memory leaks, but it's hard to distinguish a small memory leak from valid increase in game data when the game becomes bigger.

Drivers (especially graphical drivers) can be a problem. Both for compatibility and speed. But perhaps you can look at the profiler to see where the bottleneck is (press F11 in-game)

@wackyserious, what sort of performance problems do you have? Is it rendering, or other components (f.e. pathfinding or obstruction calculation)? You can check it by opening it in the main game (Atlas isn't really representative) and pressing F11. You can see the computation time per component per frame (so the longer the computation, the more that component is responsible for lag).