Build with and without the new flag.

macOs 10.15.7 + working copy rP25928

• Applied the patch without valgrind being installed.
• Also installed valgrind via Homebrew (small problem, but solution No.10 worked for me from this link) and applied this patch.

Alright then.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

All SendGetBoardList needed to be handled got handled.

I suppose the bigger problem is that there isn't really a design plan/idea for how the civs should play and how many bonuses, unique techs a civ should have

Therefore this should be fixed first. Unless there is a real need don't change things until this is sorted out.

It'd be great but who knows how long it will take for someone to go out and make it. There is this https://trac.wildfiregames.com/wiki/Design_Document#PlayableCivilizations, but it doesn't detail anything for gameplay in generic.
Until then, I think it's fine to start adding a base of bonuses/techs just to differentiate civs more than by only their architecture.

And I agree that boni like additional pop for storehouses etc as we had in the past are preferable as they are also apparent to non (semi-) pro players and as such make more sense to use for the "differentiate civs" purpose.

The Britons can be given the structure population bonus and this woodcutting bonus moved over to the Mauryas maybe or just gotten rid of.

making the addition of it to that file out of scope for this revision

According to wraitii valgrind didn't really work for him on macOS

https://wildfiregames.com/forum/topic/56568-petra-having-problems-with-fishing-on-maps-with-water-available/?do=findComment&comment=454690

open trade card from top menu
switch to observer, go back to player, missing buttons

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Improve the buildingAI situation

In D3646#180948, @Stan wrote:

Mmmh there is no #ifdef in [source/lib/sysdep/os/osx/ocpu.cpp]

Eyeballed, didn't find more => meh

I suppose the bigger problem is that there isn't really a design plan/idea for how the civs should play and how many bonuses, unique techs a civ should have

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Optimalisation.

Economy bonus not only affects the early game but the late game, which is not the intention in a good rush civilization and weak late game.

I think we're also looking at this very differently. A ''rush'' civilization for me is one that has wide-open options and opportunities for early and sustained aggression. The weak late game part doesn't refer to them being directly inferior to other civs but just simply lacking as many late game options. Otherwise, we create civilizations that are only seen in 1v1s and vice versa for only strong late game civs.
So in this case a wood bonus allows the Britons to more quickly get a stable and fields for war dogs/cavalry, or a stronger slinger rush as they can afford to have more on stone from the get go. And then the Britons can have an 'inferior' late game by missing cavalry upgrades, having weaker siege, and being reliant on infantry (Probably missing an inf armor upgrade too as they'd have better wood eco and thus would be able to field a bigger army). So in a 1v1s late game, the opponent can counterplay their strength and force them into playing suboptimal units but in team games their infantry is already accompanied by supporting units. This way they're still focused on the early game but aren't a crutch in late game.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Use a set.

In D4273#182025, @borg- wrote:

In D4273#181983, @ValihrAnt wrote:

Britons/gauls must be a rush civ, so there may be a bonus for that, like, brit can build fortress and barracks on neutral territory for example.

For a rush civ, an early economy bonus is the most important thing. I don't see any value that being able to build a barrack in neutral gives early on. It's why the Mauryas and Ptolemies like to play extended early aggression much more than other civs.

Economy bonus not only affects the early game but the late game, which is not the intention in a good rush civilization and weak late game.
I really don't find it fun for all civilizations to have basically the same economic bonuses. Macedonia may have bonus expansion/capture rate, roman siege units, brit/gaul in rush, athenas could create a new slave for each house built.

Are more creative bonuses that help to highlight the characteristics of each civilization.

You mean after inserting erease code rP25634

@wraitii
'screenshot0001.png' was successfully taken after I rebuilt 0ad with your patch applied. Is there currently anything more I could help you with? Like anything with Python?
BTW, can I use this patched & rebuilt version for further testing also of other stuff, or should I then rather revert your patch (i.e. back to latest svn and rebuild/compile)?

In D4117#182027, @wraitii wrote:

In D4117#182026, @Ceres wrote:

@wraitii In the summary, you started with "Compile with this". While this might be obvious for you and other devs/experts, I am not sure whether I have to really compile (again). I did not compile again, as I have a working svn version of 0ad already.

You do have to compile again, after you applied the patch. Then it should work.

In D4117#182026, @Ceres wrote:

@wraitii In the summary, you started with "Compile with this". While this might be obvious for you and other devs/experts, I am not sure whether I have to really compile (again). I did not compile again, as I have a working svn version of 0ad already.

You do have to compile again, after you applied the patch. Then it should work.

@wraitii In the summary, you started with "Compile with this". While this might be obvious for you and other devs/experts, I am not sure whether I have to really compile (again). I did not compile again, as I have a working svn version of 0ad already. So I only did 'svn up', then applied your patch, and continued with the commands your provided for the console. All went fine until the map got tilted (by SetCameraData), so one can see it nicely from high above. However, the next command to take the screenshot failed. I took one manually that also shows the error message in the console.

In D4273#181983, @ValihrAnt wrote:

Britons/gauls must be a rush civ, so there may be a bonus for that, like, brit can build fortress and barracks on neutral territory for example.

For a rush civ, an early economy bonus is the most important thing. I don't see any value that being able to build a barrack in neutral gives early on. It's why the Mauryas and Ptolemies like to play extended early aggression much more than other civs.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

"army is undefined" still happens. Minor tweaks

@Freagarach Oh my bad - I was really stupid! Sorry to you and @wraitii that I used the wrong patch to report here. I need to pay more attention... sigh

while doing it you could merge branches

In D4216#179134, @Freagarach wrote:

I was thinking we might just want to pass the requirements we want to te researchManager and let that handle trying to research.
E.g. instead of calling researchManager.researchTradeBonus, we call researchManager.tryImprove which not immediately tries to improve, but adds the req. to a list that the manager will try to research on its next update?

@Angen I think this ^ could be done.
E.g. the tryToImprove will add it to a list which gets parsed on update in researchWantedTechs. With the following remarks:

In D4216#179138, @Freagarach wrote:

I guess the advantage of leaving the exact specs (i.e. modif) in the hands of the researchManager is that there are no modifs scattered throughout PetraAI's code. The disadvantage would be that for every modif you want to use you need a function in researchManager.

In D4117#181969, @Ceres wrote:

user@Debian:~/0ad$ arc patch D4177

mh, this diff doesn't change UnitAI, so I'm not entirely sure why you had a problem in UnitAI?

Adding @genava55 as he might have some input.

Britons/gauls must be a rush civ, so there may be a bonus for that, like, brit can build fortress and barracks on neutral territory for example.

For a rush civ, an early economy bonus is the most important thing. I don't see any value that being able to build a barrack in neutral gives early on. It's why the Mauryas and Ptolemies like to play extended early aggression much more than other civs.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

I think I fixed the error in defenseManager.js (army is undefined). Only Petra error in incrementBuilderCounters for structures/kush/camp_noba with count < 0 and unknown type in garrisonManager undefined for Athenian Hoplite id 13212 inside Barracks id 12541 remain.

Ah, this implies code changes? Well, then I'm lost. 😊

@Ceres the [hack] in the title implies that its not meant to be applied for production use and also I have no idea what kind of c++ wizardry is going on here. So can't help you here.

@marder @wraitii
I have some warning messages about hunks when trying to apply this patch to me freshly up'ed svn:

@marder Ok, thank you!

In rP25789#53964, @Ceres wrote:

Which manual step do you mean?

ok then I don't have any more remarks, its definitely already an improvement.

In rP25789#53963, @wraitii wrote:

In rP25789#53962, @Ceres wrote:

Could a map thumbnail be automatically generated in the game? Or is it possible to have thumbs automatically generated whenever a map/texture is updated in the repo?

Both are possible futures, but at the moment there is really no convenient way to do it. You must go through at least one manual step, which makes this annoying.

Which manual step do you mean?

In rP25789#53962, @Ceres wrote:

Could a map thumbnail be automatically generated in the game? Or is it possible to have thumbs automatically generated whenever a map/texture is updated in the repo?

This seems like a good idea 👍

You also have the ability of foresight! ;) I don't know if I'm supposed to review your patch, but let me tell you that for me it works very nicely. Thank you! :)

Well, for the time being, I would like to keep it as it is. In fact, I realised that changing the look of the tooltip itself would not help. One would need to change the area where a tooltip is to be expected, e.g. by a different background colour or something eye-catchy; this should be consistently used throughout the game, though, I guess, else it would not be nice. Further suggestions are very welcome. AFAIK it, I can later further edit this patch in this regard, i.e. also after it has been implemented, right? Or should I then better start a new one - to have the implemeted one as basis for a new diff?

Could a map thumbnail be automatically generated in the game? Or is it possible to have thumbs automatically generated whenever a map/texture is updated in the repo?

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Fixing lint warnings. The names in the leaderboard are all lowercase, resulting in duplicate names. Adding toLowerCase() might solve the problem, but I haven't added it. I want the names to be displayed in the correct case.

Yeah it's because freetype ft2build.h is named freenode2/ft2build.h only on macOS

In D4108#181953, @Stan wrote:

Interesting so it picked the homebrew version instead of the local one. It's a bit strange the game compiled with no header change though.

Interesting so it picked the homebrew version instead of the local one. It's a bit strange the game compiled with no header change though.

In D4108#181951, @Stan wrote:

You probably have a version somewhere @Langbart see if you can find it in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

You probably have a version somewhere @Langbart see if you can find it in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

To be honest I don't think every civilization needs to have a generic economics bonus.

Switched the bonus from the Gauls to the Britons

Apply the patch and compile the game

Yes, macOS 10.15.7 with rP25923.

Run the game with a user report and check that freetype version is correct

userreport_hwdetect.txt in my /Users/picus/Library/Application Support/0ad/logs folder says:

In D4274#181934, @wraitii wrote:

I think you're doing redundant work on INVALID->Player when then entity spawns, which is bad as that's quite slow already.

Yeah, I think I need to go through that message on all the components one day.

works. rP25923+D4274, I can no longer get a negative number for the number of resource gatherers in the top panel.

I think you're doing redundant work on INVALID->Player when then entity spawns, which is bad as that's quite slow already.