Seleucids

New update: Additional camera settings: These are configurable options that are normally hidden from the settings interface, presumably because it might confuse new players. However, I personally found these camera settings to be essential for players improve their micro. In short: Scroll speed changes how fast your camera pans around the map when you press WASD. The value is the speed of the camera in m/s and the default was 120. I personally use 620 so that I can quickly move myself around my base. I allow up to 1000 but that's a bit too crazy for me. The zoom options control your altitude from the map. Default minimum is 50, but if you have a high resolution screen, you can still see content clearly for up to 10 or even 8. FOV = Field of view

In theory, Kushites are one of the most OP civs: Early game: Free healer for exploration and healing your cavs / archers after rushing Booming and eco: The size of storehouse is very small, so that they can be squeezed into clearings inside forests for ultra efficient woodlines. The pyramid might help as well but it's a bit expensive. However, archers walk slowly and have low angular frequency, which does slow down resource gathering. In phase 2 you can make mercenary skirmisher inf, which is useful. Booming with cav is also an option. Early pushing: you will rely on archers and a mix of melee infantry. They are a bit weak unless you have significant numbers of cav and skirmisher infantry (40+ jav units in total). However, the pikeman wall + archer sniping is op if you can micro well. You can also do Blemmye merc raiders. Late game: elephants + pikes at the front. Champion archers + jav cav at the back. Sniping with champion archers is OP. If you are dishonourable, you can spam champion cavs with Nastasen hero. The only imperfection is that champion swordsman can only be trained from temples - you can't spam them. However, in practice: Every time I play Kushites, something goes wrong. Either I get rushed hard or my teammates fail or somebody disconnects. I've had very few successful games with them, but when they are not cursed, they outshine every other civ: https://youtu.be/FpMxIPT42Qw

A demo video of Petra_Extreme against Petra on Mainland. This time it didn't make 130 women. I think yesterday's incident was caused by Coastal Ranges map or some other weird settings.

Hi, I downloaded version 7 of your bot and test played it against Petra on very hard random settings. A few observations: The bot makes all women in the early stage, up to a third of its population. This gave the bot very good eco compared to Petra but very weak against rushes. The bot still makes the same mistakes of using women to mine and infantry to farm. The bot loves cavalry and its eco is mainly cavalry focused. The bot wins against Petra but with a very low KD. Dropsites are not placed close enough to the resources. Point one can be improved by changing the target number of females. Normally, in a 200 pop game, 55-60 women is the sweet spot. Even in 300 pop games, assuming you use all women to farm, no more than 65 women is necessary from my experience. Point 4 is a result of point 1: the bot always fights outnumbered battles. Point 5 can be improved by decreasing the maximum acceptable distance between res and dropsite.

When I was spectating a game, I got an error message It was nothing fatal, the game could continue as usual. But maybe it's something worth attention.

If you don't think this is broken... For most civs, there is 0 counter to this madness. At the very least, remove these extra bonuses for Seleucids etc to make other civs playable

This varies from map to map, but generally the civs which have strong early game are the most dangerous. Since the AI also does 0 micro, the unit dps is the dominating factor here, which means we are looking at a civ which can combine jav + swords. This makes Romans the top of the list. Spartans and Gauls are also strong. Normally the AI shouldn't be allowed to reach late game, but if it does, the civ with the best champions win. Elephant civs are probably the best? Then Macedonians and Iberians have the best champion lineup.

Profanity issues aside, one important rule to not ruin your game: No more than 10 champ cav units per person

Steak before 0ad, not during, otherwise you make a mess on the keyboard I find that drinking Actimel while playing improves my performance. Kefir also helps

I understand the difficulty. Perhaps it would be a good idea to separate these civs out into 1 civ per mod. This makes debugging easier. Currently, there are 30 civs sharing files and folders with each other. Some errors are intertwined and one mistake in a file caused chain reactions the screwed up the whole thing. If we separate the civs, it would be easier to isolate bugs and imperfections, e.g. missing buildings / units. @Hulla can give us some expertise on Dacian units.

Furthermore, this civ needs some more balancing and content. 1. No stables available 2. Only CC can train ranged units. No ranged units in barracks 3. Only 1 hero 4. Need more cavalry where appropriate. Dacians are the most wanted civ according to the crowd feedback that I have seen, so it would be really useful to fix this civ first, out of the dozens of civs in Endovelico.

I am trying to fix the Dacian civ in the Endovelico mod. I forked their repository and made changes within my fork, and now Dacians are a playable civ in this repo: https://github.com/Yekaterina999/Endovelico However, there are still non-fatal error spams while loading the map and during gameplay: ERROR: CCacheLoader failed to find archived or source file for: "simulation/templates/structures/epir/wallset_stone.xml" ERROR: Failed to load entity template 'structures/epir/wallset_stone' ERROR: Invalid template found for 'structures/epir/wallset_stone' ERROR: JavaScript error: globalscripts/Templates.js line 174 ERROR: CMapGenerationCallbacks::LoadScripts: Failed to load script 'maps/random/rmgen-common/wall_builder.js' ERROR: CCacheLoader failed to find archived or source file for: "art/actors/props/special/common/garrison_flag_daci.xml" ERROR: CObjectManager::FindActorDef(): Cannot find actor 'props/special/common/garrison_flag_daci.xml' ERROR: Failed to find matching prop point called "projectile" in model "art/meshes/structural/daci/cc.dae" for actor "structures/dacians/civic_center.xml255" ERROR: Probable infinite inheritance loop in entity template 'structures/xion/barracks' ERROR: Failed to load entity template 'structures/xion/barracks' ERROR: Probable infinite inheritance loop in entity template 'structures/xion/barracks' ERROR: Failed to load entity template 'structures/yuez/barracks_empty' ERROR: CCacheLoader failed to find archived or source file for: "art/textures/skins/skeletal/no_spec.png" ERROR: Failed to find matching prop point called "projectile" in model "art/meshes/structural/daci/fortress.dae" for actor "structures/dacians/fortress.xml255" ERROR: CCacheLoader failed to find archived or source file for: "art/actors/props/units/shields/pelta_triballi.xml" ERROR: CObjectManager::FindActorDef(): Cannot find actor 'props/units/shields/pelta_triballi.xml' ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/portraits/units/celt_support_trader.png" ERROR: Failed to find matching prop point called "projectile" in model "art/meshes/structural/daci/stone_tower.dae" for actor "structures/dacians/defense_tower.xml255" ERROR: Failed to find matching prop point called "garrisoned" in model "art/meshes/structural/daci/cc.dae" for actor "structures/dacians/civic_center.xml255" ERROR: Failed to find matching prop point called "projectile" in model "art/meshes/structural/daci/cc.dae" for actor "structures/dacians/civic_center.xml255" The last few lines are caused by lack of prop points in the model for garrisoning and projectile. You must add enough prop points so that we can see arrows being shot and garrison flags. The first few lines are caused by bad wall definitions in other civs, not just Dacians. Furthermore, this civ is lacking an emblem, unit icons and unique unit models. The buildings are pretty much in place; we are only missing a stable and a civ-special building. @Duileoga @Lopess

Today I encountered this error after running a system update. The solution was to rebuild the libraries and the game and it will be fine again.

As a frequent TG host, here are my limits: General use of swear words - fine, but don't spam too much Insults - if directed at a playing player, I will warn you to stop. If that player asks for ban and you still don't stop, then I will ban. Spam - I will kick if your messages prevent us from playing. Come again and I ban. Political chat: I will remind you to keep it in spec chat. I don't really care what you say in spec chat as long as it does not distract the players or jeopardise the server session. Cheating: I will pause and ask you to explain your cheat mechanism then ask you to turn it off. If you refuse then we will re withdraw the cheater. Although cheating is impossible in A27. So far I've only banned two people from my game, one for spamming, the other for insult + spam + impersonation.

I'm afraid I didn't see you at all in March, so I thought you were inactive sorry

I think you can try to account for lag by scaling the threshold with the game's simulation rate. Also I think the default chat message could be rephrased a bit so that it sounds less accusative, e.g "Oddity detector detected %player sent %number_of_inputs commands at turn %turn, we suspect this may be automated, but could be caused by natural factors, so please calm down. ". You can also consider limiting the recipients so that not everyone in the room freaks out. The mod caused some drama today and ruined a TG that I was hosting:

No, I just named it after Dunedan, because he was the author of the post on Gitea. I don't know how to name it otherwise, but it was a great fix What about offloading hashing to another process? I'm reading up on C++ multiprocessing and in theory, we can dump the time-taking subroutines (especially void functions) to other processes.

I am looking at other possible changes to the engine that can improve its performance while staying compatible with the public lobby. Intel has provided a nice investigation and useful advice: https://www.intel.com/content/www/us/en/developer/articles/technical/identifying-the-frame-rate-bottleneck-in-0-ad.html In light of this article, I think there are 2 potential improvements at hand: 1. Remove garbage collection where possible. 2. Implement the mathematical calculations in C++ in the engine, then expose them as functions to the Javascript mods. This morning, I implemented point one by removing the GC steps from simulation2.cpp. Normally, at some point in late game, you stutter when selecting barracks or units, or there is a small sudden freeze caused by GC. Now with the GC removed, the stutters and freezes are even less (ofc, with all previous patches included). There was no OOS with anybody. Regarding point 2, I will need to conduct some experiments: 1. Dry run a Javascript and a C++ maths script that do identical calculations (for example, integrate arctan(x) dx over some finite domain). Compare the speed of the compilers. Some users claimed that C++ performs 250 times faster than Javascript at integration, but that remains to be tested. In an integration race against Python, C++ performed ~100 times faster. 2. Implement all functions in globalscripts/math.js into C++ engine functions and just call them whenever needed. I am not sure how slow the interfacing is, so the final products need to be tested. Pathfinder is also a big source of lag so maybe i can migrate that to C++ instead.

I would like to share some engine changes that I made locally to A27-0 release. Feel free to apply my patch and rebuild for better performance / more features. Core changes: 1. Turn off Nursery Heuristic (Dunedan's performance patch) which greatly increases fps in fights. 2. Does not write config strings to mainlog.html but prints out in console instead. This shortens the mainlog by a lot of spam, especially if you use Autociv and / or ModernGUI 3. Prettier console with less transparent background, better cursor, larger fonts etc 4. Prints out every step of the handshake process when joining / hosting a game. This allows you to see why you can't join someone or who is the "unknown player" that failed to join you. The "unknown player" often freezes the host and ruins the game as the host doesn't know which username to kick. 5. Network warnings if the ping is more than 200ms. The default warning time is scaled with turn time, so sometimes the game might freeze due to bad conn but still you couldn't tell who was the cause. sevda.diff

I see, I expected the Ptols to be at the bottom with Carth. This is because of their discounts on the prices of buildings. Carth is also not a boom civ and you spend less when going for mercs. Also in your leaderboard for each civ, there is a huge spread of skills between the players controlling these civs. If chrstgtr or Stockfish decide to boom with Han and Carth, they might be a lot higher up the list. I am not sure if that will affect something. We are talking about from 1300 - top 1. Actually map matters a lot. Density of woodline is a huge factor.

Thanks for the analysis. Could you share the script that you used to produce these results? I am surprised that Ptol can appear on the list. I also didn't expect Celtic civs to be here.

You can develop your eco and rush at the same time. the 90 women at home farm and gather wood; 40 cavs harassing at the front, then you'd have 3 barracks popping out spear inf to mines. Eventually you reach 70 inf + 40 cav combo and your enemies are weak. Now you can decide between push or max yourself out by deleting 40 of your women and replace with champs

Batch offset=0x0 len=0x8 on queue 0 (aperture: 0.0Mb, 0.0Mb VRAM only) BO: addr=0xffffeffeffff0000-0xffffeffeffff1fff size= 8KB handle=00009 capture=1 vram_only=0 name=workaround BO: addr=0xffffeffefffe0000-0xffffeffefffe0fff size= 4KB handle=00010 capture=1 vram_only=0 name=trivial-batch ERROR: Present result: -4 (VK_ERROR_DEVICE_LOST) Assertion failed: "0 && ("Unknown present error.")" Location: SwapChain.cpp:348 (Present) Call stack: (0x64193ca71123) binaries/system/pyrogenesis(+0x8dc123) [0x64193ca71123] (0x64193ca5adff) binaries/system/pyrogenesis(+0x8c5dff) [0x64193ca5adff] (0x64193ca5b00c) binaries/system/pyrogenesis(+0x8c600c) [0x64193ca5b00c] (0x64193ca5d14f) binaries/system/pyrogenesis(+0x8c814f) [0x64193ca5d14f] (0x64193c7d84a7) binaries/system/pyrogenesis(+0x6434a7) [0x64193c7d84a7] (0x64193c7d39fc) binaries/system/pyrogenesis(+0x63e9fc) [0x64193c7d39fc] (0x64193c6bd37d) binaries/system/pyrogenesis(+0x52837d) [0x64193c6bd37d] (0x64193c2629e7) binaries/system/pyrogenesis(+0xcd9e7) [0x64193c2629e7] (0x64193c26878e) binaries/system/pyrogenesis(+0xd378e) [0x64193c26878e] (0x64193c256e59) binaries/system/pyrogenesis(+0xc1e59) [0x64193c256e59] (0x7ded310278ce) /usr/lib/libc.so.6(+0x278ce) [0x7ded310278ce] (0x7ded3102798a) /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ded3102798a] (0x64193c261345) binaries/system/pyrogenesis(+0xcc345) [0x64193c261345] errno = 5 (Error during IO) OS error = ? SwapChain.cpp(348): Assertion failed: "0 && ("Unknown present error.")" ERROR: vkWaitForFences(device, 1, &fence.value, VK_TRUE, std::numeric_limits<uint64_t>::max()) returned -4 (VK_ERROR_DEVICE_LOST) instead of VK_SUCCESS Assertion failed: "false && "vkWaitForFences(device, 1, &fence.value, VK_TRUE, std::numeric_limits<uint64_t>::max())"" Location: SubmitScheduler.cpp:157 (WaitUntilFree) Call stack: (0x64193ca71123) binaries/system/pyrogenesis(+0x8dc123) [0x64193ca71123] (0x64193ca5adff) binaries/system/pyrogenesis(+0x8c5dff) [0x64193ca5adff] (0x64193ca5b00c) binaries/system/pyrogenesis(+0x8c600c) [0x64193ca5b00c] (0x64193ca5d14f) binaries/system/pyrogenesis(+0x8c814f) [0x64193ca5d14f] (0x64193c7d3e82) binaries/system/pyrogenesis(+0x63ee82) [0x64193c7d3e82] (0x64193c76c690) binaries/system/pyrogenesis(+0x5d7690) [0x64193c76c690] (0x64193c76cb4d) binaries/system/pyrogenesis(+0x5d7b4d) [0x64193c76cb4d] (0x64193c7d771f) binaries/system/pyrogenesis(+0x64271f) [0x64193c7d771f] (0x64193c7d230d) binaries/system/pyrogenesis(+0x63d30d) [0x64193c7d230d] (0x64193c6c46bf) binaries/system/pyrogenesis(+0x52f6bf) [0x64193c6c46bf] (0x64193c7609cc) binaries/system/pyrogenesis(+0x5cb9cc) [0x64193c7609cc] (0x64193c2629e7) binaries/system/pyrogenesis(+0xcd9e7) [0x64193c2629e7] (0x64193c26878e) binaries/system/pyrogenesis(+0xd378e) [0x64193c26878e] (0x64193c256e59) binaries/system/pyrogenesis(+0xc1e59) [0x64193c256e59] (0x7ded310278ce) /usr/lib/libc.so.6(+0x278ce) [0x7ded310278ce] (0x7ded3102798a) /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ded3102798a] errno = 0 (No error reported here) OS error = ? SubmitScheduler.cpp(157): Assertion failed: "false && "vkWaitForFences(device, 1, &fence.value, VK_TRUE, std::numeric_limits<uint64_t>::max())"" ERROR: vkQueueSubmit(m_Queue, 1, &submitInfo, fence.value) returned -4 (VK_ERROR_DEVICE_LOST) instead of VK_SUCCESS Assertion failed: "false && "vkQueueSubmit(m_Queue, 1, &submitInfo, fence.value)"" Location: SubmitScheduler.cpp:193 (Flush) Call stack: (0x64193ca71123) binaries/system/pyrogenesis(+0x8dc123) [0x64193ca71123] (0x64193ca5adff) binaries/system/pyrogenesis(+0x8c5dff) [0x64193ca5adff] (0x64193ca5b00c) binaries/system/pyrogenesis(+0x8c600c) [0x64193ca5b00c] (0x64193ca5d14f) binaries/system/pyrogenesis(+0x8c814f) [0x64193ca5d14f] (0x64193c7d3832) binaries/system/pyrogenesis(+0x63e832) [0x64193c7d3832] (0x64193c7d39cc) binaries/system/pyrogenesis(+0x63e9cc) [0x64193c7d39cc] (0x64193c6bd37d) binaries/system/pyrogenesis(+0x52837d) [0x64193c6bd37d] (0x64193c2629e7) binaries/system/pyrogenesis(+0xcd9e7) [0x64193c2629e7] (0x64193c26878e) binaries/system/pyrogenesis(+0xd378e) [0x64193c26878e] (0x64193c256e59) binaries/system/pyrogenesis(+0xc1e59) [0x64193c256e59] (0x7ded310278ce) /usr/lib/libc.so.6(+0x278ce) [0x7ded310278ce] (0x7ded3102798a) /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ded3102798a] (0x64193c261345) binaries/system/pyrogenesis(+0xcc345) [0x64193c261345] errno = 2 (Error during IO) OS error = ? Redirecting call to abort() to mozalloc_abort Segmentation fault (core dumped)

When I enter / exit fullscreen mode, there is a chance that the game will crash with the following error: ERROR: vkWaitForFences(device, 1, &fence.value, VK_TRUE, std::numeric_limits<uint64_t>::max()) returned -4 (VK_ERROR_DEVICE_LOST) instead of VK_SUCCESS Assertion failed: "false && "vkWaitForFences(device, 1, &fence.value, VK_TRUE, std::numeric_limits<uint64_t>::max())"" Location: SubmitScheduler.cpp:157 (WaitUntilFree) Call stack: (0x57ea709f19e3) binaries/system/pyrogenesis(+0x8da9e3) [0x57ea709f19e3] (0x57ea709db6bf) binaries/system/pyrogenesis(+0x8c46bf) [0x57ea709db6bf] (0x57ea709db8cc) binaries/system/pyrogenesis(+0x8c48cc) [0x57ea709db8cc] (0x57ea709dda0f) binaries/system/pyrogenesis(+0x8c6a0f) [0x57ea709dda0f] (0x57ea70754742) binaries/system/pyrogenesis(+0x63d742) [0x57ea70754742] (0x57ea706ecf50) binaries/system/pyrogenesis(+0x5d5f50) [0x57ea706ecf50] (0x57ea706ed40d) binaries/system/pyrogenesis(+0x5d640d) [0x57ea706ed40d] (0x57ea70757fdf) binaries/system/pyrogenesis(+0x640fdf) [0x57ea70757fdf] (0x57ea70752bcd) binaries/system/pyrogenesis(+0x63bbcd) [0x57ea70752bcd] (0x57ea70644f7f) binaries/system/pyrogenesis(+0x52df7f) [0x57ea70644f7f] (0x57ea706e128c) binaries/system/pyrogenesis(+0x5ca28c) [0x57ea706e128c] (0x57ea701e4767) binaries/system/pyrogenesis(+0xcd767) [0x57ea701e4767] (0x57ea701ea50e) binaries/system/pyrogenesis(+0xd350e) [0x57ea701ea50e] (0x57ea701d8bc9) binaries/system/pyrogenesis(+0xc1bc9) [0x57ea701d8bc9] (0x7cb43dc278ce) /usr/lib/libc.so.6(+0x278ce) [0x7cb43dc278ce] (0x7cb43dc2798a) /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7cb43dc2798a] errno = 11 (Try again later) OS error = ? Redirecting call to abort() to mozalloc_abort Segmentation fault (core dumped) I am on CachyOS Linux, Plasma Wayland. This also happens sometimes when I try to run a second instance of the game.