bb_

I believe this link helped me fixing that: https://ask.fedoraproject.org/en/question/44627/setting-permanent-path/ EDIT: not actually working just add PATH=$PATH:~/0ad/arcanist/arcanist/bin/ to .bash_profile and export that PATH iirc https://unix.stackexchange.com/questions/42146/changing-an-environment-variable-like-path-forever

In the buildInstructions (the page with the dependencies) there are commands below to download and build svn (subversion), we highly recommend using this when making changes. When that is done (and that might take a while) you can search in the svn folder to the brit_blacksmith file and make the changes in there. Then when doing svn diff (or whatever it is on windows) you can see what you changed. By putting that on phabricator we can start reviewing (there is also an option to use arc and avoid the svn diff stuff)

Not yet but not too hard to fix, Hannibal_Barca suggested the same this week in lobby, have been working on an implementation.

Gaia strikes again along the sides of the river. Players: West: mord (athen), SarhaElda (gaul), PricipalityOfZeon (mace) vs East: bb (sele), juniormaster (mace), pablek2 (mace). Spoiler below gives a short summary: Replay below: commands.txt

That is in mainmenu.xml L537-542 (and read the comment above).

Has been so long since I played widelands, (should have been like the first year of highscool XD). Nice to see the project is still alive, sadly the newest version is not in the fedora repo anymore, so to participate i would need to build from source :/

For the window name and icon, perhaps https://code.wildfiregames.com/D768 will be any help. The main-menu code is in gui/pregame/mainmenu.* (js has the code, xml the layout)

there already is a idle worker "flag", in the right-bottom corner of the minimap there is a button selecting an idle worker. when the button is greyed out there are no idlers, when it is coloured there are idlers. When selecting units, there is a selection ring around the footprint of the unit. When selecting differnt types of entities simply use shift click on the wanted entities and then ctrl + click to make it a group. Using shift +num is selecting the currently selected units and the specified group, but does NOT add the currently selected units to the group. One should use ctlr+shift in order to do that. sometimes big units like elephants and rams get stuck in a forest due to a short pathfinder bug (one can get those out by ordering very small movements out of the forest), further formations are mostly bugged and indeed get stuck often.

(and pushing onEntityRenamed messages)

10: dunno if there is a better solution than putting the - on all productionqueues... 11: the values are multipliers indeed so 1.5 == +50% and so 0.5 == -50% 12: a) attackBonus *= bonus.Multiplier; a gate would get 4* bonus 13: for some reason the code is a bit strange here if (bonus.Classes && bonus.Classes.split(/\s+/).some(cls => !cmpIdentity.HasClass(cls))) continue; so the target should have all classes b). (usually a " " is taken as a logical "or", i might write a patch for this...)

Not exactly computing a new path, since the hierarchical pathfinder has the reachable areas stored, so the only thing to check is if the realTarget and the pathTarget are in the same reachable area (and that is fairly cheap).

One could say that trade is broken: if one has got a trade route of 62 gain (with all ups, not civ bonusses), this trade is better than celtic farming (with all ups + rotary mill). I agree capping isn't a good solution (for the same reason as above). (For beating corrals with trade one needs 200+ gain...) Also letting traders trade between cc's isn't a solution since that is nothing else than capping. A (better) solution would be to take in the gain calculation the amount of traders using the same markets, so more traders using the same market would result in lesser gain per trader. I guess this isn't a 100% clean solution since many markets could be build together (and I am against a mindistance). Maybe every market should take all traders from markets in a certain range into account when calculation it's gain. The amount of traders from a market could be calculaed as the amount of traders that have visited the market the last minute or so. (This would nerf short trade routes a bit hard maybe, so one should have a weight factor on the traders what is the gain/distance.)

@aaron03: Hi and welcome, we always like to welcome new contributers to the project. Have a look at our programming guide to get started, there are some links how to get the latest version (svn), starter task and submitting patches. Also feel free to join us on IRC if anything is unclear, or you might have other question about the game or java.

Please don't take it too far off topic (search some general question forum or make a new topic for more questions). Anyway, it is currently impossible to order units to run, running is only triggered when units flee or chase, but again this cannot be user ordered, only UnitAI auto behaviour triggers it (f.e. being attack in passive stance).

2-I guess you mean the percentages in the armour stats, they are the percentage of damage absorbed by the armour and they should be equal to (1-0.9x) *100%, in where x is the value left of the percentage.

Indeed the percentages set are* the percentages traded and so the percentual income for that recourse from the trade. So if you set food to 43%, 43% of all trade income will be in form of food. * It is actually a chance function on every trip the trader decides what he will trade that trip, and if there is a 43% on food the chance of choosing food is 43/100. Following by theory of big numbers it follows that 43% of the trips will be done with the food resource,

I am not principal against allowing farms/corrals but I think there is a better solution by distributing (random) amounts of resources from time to time to each player (in equivalent amounts to each player). We could ofc set that the amount of f.e. food would be higher (on average) then the other resources. There is some code for this in #3102. This would give each player a "solid" income and decide himself where to spent it on. By allowing fields/corrals I guess everyone will simply spam them (as being giving resource + being a "wall") and thus less profitable tactics in game. I don't see why self trade is not allowed in current state, seems to work fine here, nor I would like it seeing disabled.

The approach in #252 is less clicky then with an upgrade feature, with upgarde you need to click manually if you for switching per (group of) unit(s) and indeed need to keep track of which unit is in which state. The #252 patch is based on order so a player can give an order for a specific type with an hotkey and the unitAI/attack component will decide themselfves which attack is best (based on DPS/range) when there is no forced order. So one does not need to keep track of units in "attack states" but he can press a hotkey per time he gives an attack order.

Archer to melee is possible with ticket #252, pikemen to swords not. (but it will not be implemented in vanilla a21)

Here a selection of my recent 1v1 replays: replay_bb.zip

Not yet see #252 (and #4000 for this issue too)

Well the patch won't work since trampling was designed there as an aura and the aura's got moved to .json files in the mean time. Also trampling might need an own component (which copies a lot of the aura code). So it would need a rebase and partial rewrite.

yes, but it is very outdated #995

True regicide is not in A20 but will it is in current svn (so it will be in next release)

On which OS are you working and which version of the game do you have?