sanderd17

Hmm, I didn't know it was bugged, so didn't fix it specifically. But it could indeed be fixed as a side effect. If it's still bugged, please report it back to us, so we can find where the issue is.

Both would work: Ally and MutualAlly. But they have different meanings. Ally gives the bonus to all your allies, MutualAlly only gives the bonus to your allies of whom you're also an ally.

We have a few contexts that are separated (f.e. the GUI js files can't access functions defined in the simulation directly, and the AI is also restricted to its own functions). But apart from that, most functions can be called across files indeed. JS doesn't care if it's split up in all different files, or if everything is in one file (on the web, everything is often put in one file to reduce the loading time). So we have to put our own meaning into it.

Zooming is done via the scroll function of the mouse. So if you use a touchpad with two-finger scroll enabled, and there's something else on the touchpad next to your index finger (a different finger, some grease layer, another part of your hand, ...) it can interpret dragging as scrolling, and zoom instead. If you use a touchpad with a dedicated scrolling area (f.e. the right side of the touchpad is used for scrolling), then you should avoid moving over that right side.

An online map editor (as being able to edit the map online) will be very hard to implement. We'd basically have to port our entire game to the browser, which won't happen soon. But I would like having some "mod repo" available, where mod-makers can just upload their mods, and players can download them from an in-game menu. Perhaps with some voting system and comments etc. A map can also be packaged as a simple mod, so could also be downloaded from there.

@super, the main reason this isn't implemented yet is because we don't like the micro management. For every attack, you would need to select if you want to kill our enslave, and after the attack, you have to lead your slaves to safer places to work. That happens while you're very busy with the battle. If you can find something that requires less micro management, you may be able to convince us to implement it.

@AtlasMapper, it's currently a bit hard, as without modifications to the game, you need to enter the coordinates manually into the map XML file. There's also no example in-game yet, but there's one here: http://trac.wildfiregames.com/ticket/3814 As said in the release announcement, it's not yet complete. It's missing an easy way to add the paths, and it will also give problems with multiplayer for now. If it would be completely usable already, it would probably be our main feature.

@jarnomodderkolk, we have not seen any significant performance improvement by going to 64-bit, and we don't need the extra RAM (unless something goes horribly wrong). So we chose the option that's compatible with most computers: the 32-bit version.

@BrynnOfCastlegate is doing these videos. But I'll have to disappoint you, and say that the current release won't have a video. Mainly because not a lot changed on the graphics side, so there's not a lot that a video would help to showcase.

It looks like an old translation mistake after all: https://www.transifex.com/wildfire-games/0ad/translate/#pt_PT/public-gui-manual/37364827?qt=cima

Just got time to test it. It compiles correctly and seems to work (though I didn't go through all menus, and didn't play a game yet). But there's again a problem with the translation of the manual. The pt_PT translation spits the well-known error ERROR: Invalid tag 'cima' at 8445 in '[font="sans-bold-18"]Manual ... I don't know if this is worth fixing and re-packaging(best only locally, to not pull new translation mistakes). But I would urge anyone out there to test the RC, go through all menus, test if settings work, play a game, ... Only that way a good release can be made.

No specific plans, but things always change, and some things have serious implications for balancing. F.e. fixing the chase-bug caused cavalry to become a lot powerful, while that wasn't intended.

@BlazingHeart, maybe you can check out some youtube videos? And I can also give you a bit of courage: balancing still changes quite often. So if you're good at one version, it could be that when playing the next version, you have to learn the optimal strategy again. So new players do get more chances. Though the next release (A20) doesn't differ a lot from A19 according to avid MP players. Perhaps A21 will be more like your taste.

The code is available for anyone to try, see this: http://trac.wildfiregames.com/ticket/3414 And I'm sure trompetin17 would like input on it, though the focus should now be on committing the new code to the main repo, and adding new features to it afterwards.

Here's some WIP stuff: https://wildfiregames.com/forum/index.php?/topic/19722-wip-atlas-ui-changes/

Nice idea, but maybe it's better to wait with that for the new Atlas UI trompetin17 is developing. Then you'll certainly have better-fitting screenshots

I like the suggestions here for a pre-build map with lots of buildings but few resources (or only resources far away from the base). That would mean you'll first have to capture some buildings (f.e. two markets or a dropsite near the available resources) in order to start resource generation. Note that maps also have the possibility to disable certain templates. In this case, you could disable the farm field template, to force players to get out of their base quickly. The AI probably wouldn't know what to do though, but it could make a fun multiplayer.

There's some nice eyecandy you can find under the actors. Like small plants (waterlilies, grass, ...) or things to help build the feel of your map (like a broken handcart, skeletons, ...)

I think you're having issues with actors. Actors are just models, and have no effect on gameplay (so only used for eyecandy; tree actors are handy to decorate impassable places). While entities are actors with different statistics, so they have gameplay consequences. They're also shown in different lists: actors and entities. But most importantly, to select actors, you need to hold the ALT key. Treetops are separate actors (the tree model is normally split in 2 parts), so I guess you're just having treetop actors there too.

This is intended behaviour, it's meant to be sure that the selected animation matches the props. It would be silly if an archer would start chopping a tree with a bow and arrow. However, it's also mildly annoying that the name selection is passed on to prop actors. F.e. the farm field has a few variations of plants, but once a variation is chose by its name, it's chosen for all plants on that field. So on the one hand, it's intended behaviour that we can't change without breaking all unit animations. On the other hand, it's also slightly annoying.

As said before, it's possible via multiplayer (you don't even need someone to join the game), but when you launch the game from the command line, it's also possible to immediately start on a certain map with certain player assignments. And an all-AI game is possible that way too. See the readme: http://trac.wildfiregames.com/browser/ps/trunk/binaries/system/readme.txt

Trompetin17 is still working on atlas, albeit slowly. But it's almost finished, and is planned to be one of the first things to commit after the release (so we get enough time to test it for the next release)

Missing numbers are normal, every time you delete something, it leaves a hole. The game can handle this, as it happens constantly: units die, trees get chopped down, ... So that shouldn't be a problem. Though I do think that the map reading code expects entity numbers to be sorted from low to high.

Terrain updates being slower is caused by the new pathfinder. The new pathfinder does more pre-computations for the things that are rather static (so certainly for the terrain profile, but also the building/resource obstructions). This causes pathfinding itself to be faster, but when these static things do change (which is what happens in Atlas), it causes a slowdown. The ideal solution would be to not process the pathfinding calculations until the simulation is started in Atlas (or until you request the passability overlay). But this is not yet done as trompetin17 is working on a new Atlas UI, which would alter the communication between Atlas and the simulation (so affect how Atlas can stop passability computations). However, for some reason, I also find Atlas rather slow when doing other actions (like just panning and zooming). While those actions are not too slow in the main game.

Is it possible you manually edited the XML? From a first look at the error message, it expects the entity to not be in a list anymore, but the entity is still there. I think this could happen when you have different entities with the same id. So one gets processed, and there's still one left in the list. Though the message should certainly be more descriptive (f.e. mention the entity as you say). It's not related to placement of entities (when loading the map, valid placement isn't even checked; you can even put something on coordinates that are outside the map). The easiest way to debug this would indeed be to share your map, or make a minimal example map where this happens. Then we can try to make the error a bit more descriptive.