maroder

What biome was this? The amount of fish (and hunt + berries) are intentional quite variable depending on the "time of the year".

noted : https://trac.wildfiregames.com/ticket/6892

Mod note: This game is focused on simulated ancient warfare. Please refrain from going way off topic with current politics. That just ruins any discussion.

That would work.

Main concerns are: 1) the center menu overlaps important aspects of the designs ; 2) color mismatch between the dark menu and a very light background. From the vanilla backgrounds in combination with this menu, I would say: the kushite one looks quite nice as it is the seleucid one has ok placement, but a bit hard contrast the carthage one is ok color wise but would need some adjustments to the placing of the two soldiers (one a bit more down and to the left, the other one a bit more to the right) the hellenes one has the least compatibility - the colors are quite different and the center menu overlaps basically all the people. They would need to be shifted quite heavily to either side and then it would still be a rather large contrast. So generally I think 3 out of 4 could be adapted to work "ok" with this menu design. The more general question is: Does it make sense design wise to use two completely different art styles in the main menu? One 3D rendered and one digitally drawn? This also only plays a role if this shall ever be included in the vanilla game ( which is questionable, since design changes are very much opinion based and I can guarantee that not everyone would like that ). So I don't actively work on making the old backgrounds compatible right now. Sure, one could greatly reduce the number of buttons and get rid of the center menu all-together. But one of my goals with this design was that every button is present, that is present in the vanilla menu - So maybe the first question would then be: Why are there so many buttons in the vanilla version Might work; Although if you put exit & scenario editor also to the left, there is not much symmetry left. It also might become quite crowded on the left side with the minimal resolution of 1024x768.

I'm gonna think about it Thought about it and no - I'll stick to the current horizontal layout. The downwards expanding submenu feels right to me.

Some random points: Start page has 4 different hover effects and there are more variants in other places red old style buttons need to go tooltip background transparency (only used sometimes) may lead to hard to read tooltips radio button are of the old theme, same for drop down arrow ai options icon color button borders come in variants some enabled buttons lack hover there is an issue when expanding the menu in-game full screen pages like match-setup shouldn't have inset window borders/decorations As for incomplete, well, the in-game game controls are untouched as of yet. 1) Mostly done, I tried to unify it a bit more 2) replaced. I feel like the current buttons may be a a little bit to hard to see tho, so maybe they need to be adjusted in the future. 3) adjusted 4) radio buttons replaced, dropdown arrow not yet; I don't mind it that much (I thought about using google's Material icons, but that would require switching from GPL2 to GPL3 if I'm not mistaken) 5) TODO 6) Half way adjusted - still different borders but more similar themed now. Feels ok for me. 7) Which ones? / Still an issue? 8) Should be fixed? Not sure what the original problem was. 9) Done In-game: True, there are some changes in this version tho. Sometime in the future I would like to redo the HUD, but too much work right now.

SVN users: there is now a release candidate version for A27 - see first page for screenshots. Here is the download link: https://api.mod.io/v1/games/5/mods/1965214/files/3658747/download (you have to manually download & install it) Feedback and bug report welcome - maybe I will have time to update it again for the official launch of A27.

ah my bad, I read too quickly. You also need to line "autoResearch": true, in the tech json, so that it actually gets researched. See e.g: https://github.com/0ad/0ad/blob/6ed56a0f237f42b552da5efb1fe05102f82d7159/binaries/data/mods/public/simulation/data/technologies/civbonuses/han_population.json#L3

iirc those values you found determine the AI difficulty. But generally that sounds like a nice idea for a mod to test how that would play out You may want to look at https://code.wildfiregames.com/D4250 and there specifically at the file " binaries/data/mods/public/simulation/data/technologies/special/turbo_match.json " You basically only need one auto-researched tech file, that changes the appropriate values I.e. for you goals you would need: { "value": "Cost/BuildTime", "multiply": 2}, { "value": "ProductionQueue/TechCostMultiplier/time", "multiply": 2} instead of 0.5 and "affects": ["Unit"], instead of "affects": ["Unit", "Structure"], (and the same can be done for the capture rate ect... -> See how it's done in other techs https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/simulation/data/technologies)

current WIP:

reading the discussion on the diff, that one seem generally accepted. Fine by me.

Feedback wanted for some last minute potential bugfix/ balance changes: catapults can't see what their firing at: https://code.wildfiregames.com/D4962 Han upgraded cc seems a bit op: https://code.wildfiregames.com/D4961 (not directly related to the community mod, but I thought this might be the most efficient place to get some feedback)

https://code.wildfiregames.com/D4961

my two cents: hard no for infinite arrow speed

I'm gonna think about it

No, that part was relatively clear to me, I'm rather thinking about how to handle the sub-menus. I.e would you want them just on the right hand side as it is the case with the current menu? Because that would look a bit unbalanced imo. On the other hand, one could possibly still have a drop-down, that just overlays the button beneath it. Not quite sure how that would look like.

sure the berry placement can be annoying and could be improved (but I also don't think that its game deciding). true. although procedural maps can/do also feature different levels of randomness and it seems to me that what some people want is _no_ randomness. So even if we get https://code.wildfiregames.com/D4053 committed, it seems like that would not satisfy what some of the mp people want?

ref: This topics keeps coming up but I'm still unsure how many people would really like such a "plain" map. (The balancing options are a good idea regardless, I'm only talking about this "no hills - everything absolutely the same" kind of map). At the end this description doesn't sound like a random map to me and more like a scenario map - specifically the option to choose the specific position for each player.

https://github.com/0ad/0ad/blob/b7267709ceceba0f789746199ad7b4cdc16d587a/binaries/data/mods/public/simulation/templates/units/han/champion_chariot_academy.xml#L9 are you sure you have disabled all mods?

Indeed, it's too late for a27 now, but a28 will feature different placement options for mainland (and potentially other maps as well)

The problem when moving them to the bottom is that you can't have a drop-down menu anymore. And a drop up menu looks bad imo. So moving them closer to the top might be an option, but unless you make them smaller as in @guerringuerrin's example, this quickly looks unbalanced (And I do prefer that these buttons are big, since they hold the most important functionality)

Should be possible with some extra work (one would need to implement a specific timer first) but I agree with @vv221 that this might be a bit too much. Changing every time you go back to the main menu seems nice but iirc it should do that already if you go to any fullscreen gui page ?. I.e. if you go back from the gamesetup/ the replay page / the mod selection it should change. I am not sure if it is desired that it also changes when you just have a small window on top of the main menu and you can still see the current background. (E.g. when opening the options) I think in that case we would certainly need a slow fade out / fade in.

The answer is that it's complicated and depends on: The capture strength of your units, the capture points and the capture regeneration of the building, which is influence by the type and number of units garrisoned inside of it. (Also a number of techs may influence the result) If you are super interested, I recommend to look at this file: https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/simulation/components/Capturable.js But imo there is no way you will be able to accurately calculate during a game how much time it will "exactly" take. I would recommend to try it, see how fast the bar is going down and then decide if it's worth it to commit to the attack or rather retreat.

ah my bad, it's been a while since I tried it