All Activity

Bom dia ou tarde; -Finalizámos a Primeira fase ,da Primeira versão do mod, (a arquitetura) a primeira quota de facções já está fechada: 65 em todo o mundo. (Proporemos mais futuramente). -Agora estamos com as unidades (primeiro as americanas), aqui fica uma antevisão: Tupí Tiahuanaco Mapuche Desculpe-me pelas inconvenièncias*

Alpha 27 - Rivers Medium map - 1 vs 5 AI very hard - On a 13 years old Linux box with a passive Nvidia GPU. Long time since I played or posted! Loving the new maps and general smoothness of the game I thought this June would be a good time to launch a Persia vs the Empire. I struggled just a bit: Being located on the Island, they kept pourring me from both sides: conquering here meant being slaughtered there! The 5 AI managed to trade like Wall Street boys on illicit substances being walled from all competition They threw 12k units at me: 1.700 Champions, 382 Sieges and 16 Heroes! They used tons of long range sieges which Persia has not -- and I had forgotten how to use rams in packs.

Hello. When I select Single-player → Load game, the following error appears. Assertion failed: "m_fileSize >= off_t(minFileSize)" Location: archive_zip.cpp:446 (ArchiveReader_Zip::ArchiveReader_Zip) Call stack: 0054880C 00555DEF 003D3CD0 005BD09E 005BCAFC 004FDB2E 0050063C 00500A1D 005062F5 005057F7 00518FEE 00519359 00544597 00528544 0051953F 0050BF84 004FF4E9 00501BB4 Hello. When I start a new game from Single-player → Matches and try to save, I get the following error: Assertion failed: "m_fileSize >= off_t(minFileSize)" Location: archive_zip.cpp:446 (ArchiveReader_Zip::ArchiveReader_Zip) Call stack: 0054880C 00555DEF 003D3CD0 005BD09E 005BCAFC 004FDB2E 0050063C 00500A1D 005062F5 005057F7 00518FEE 00519359 00544597 00528544 005 1953F 0050BF84 004FF4E9 00501BB4 0054935F 00253189 002522FC 0025535C 002586A7 002410D5 I've tried uninstalling the game, redownloading it, and reinstalling it, but I get the same error. How can I fix this? Please help.

That's just Atlas and the actor editor. @trompetin17 is rewriting it using the engine GUI.

This is actually not a problem. Both galaxies are empty enough so that an actual collision between stars or planets is extremely unlikely. The most plausible case is erratic trajectories of bodies and formation of some new constellations. More immediate threats: 1. Aggressive military actions destroying internet cables or causing electricity cuts or killing the players in real life 2. Wxwidget failure or bugs (already totally borked on Wayland). We should have switched to QT 3. Microsoft windows doing something funny and all windows players can't run game anymore

We keep having an eye on the rating disputes and take action if necessary.

What!?

The death of this game has been a long time coming and is truly inevitable. First, the heat death of the universe, something difficult to precisely calculate, will happen in roughly 10^106 years, which I doubt 0 AD will survive. Even if we prepare for that, there is the more immediate problem of the sun depleting its hydrogen reserves in approximately 5 billion years. Unless our team develops proper technology to survive in space, I think 0 AD will fail. In a similar vein, the Andromeda Galaxy's collision with the Milky Way in 4.5 billion years may pose a serious risk to the survival of the community. For these reasons, I regret to say that 0 AD is doomed.

Hey guys, I'm back with more news about my WorldRising project! I've created new resources and they're now functional! They are: bone, water, leather, clay and faith. Here's how to collect each of these resources: Water and clay can be found in the wild. Bone is passively created in hunting lodge buildings. Leather is produced in the primitive tannery. Faith is generated in ritual stones. In addition, I've implemented many new technologies, including new units such as the priest, archer and hero. I've re-textured many units and improved the textures of buildings. However, I've had some issues implementing certain technologies, such as promoting units when completing a specific technology or increasing the civic center limit by +1. I've also had trouble editing animals, even using existing models, due to issues with the skeleton. The same issue occurred when trying to implement flags on buildings. (If anyone can help me, I'd be very grateful!) I've now completed the Stone Age with all buildings and technologies. The Polished Stone Age is 60% complete and I will soon begin the Copper Age. Stay tuned for photos!

@Lopess do you have any update on those ships? Where can I find the ones you made?

You can play through my battle skills campaign for now. If you pass every level, I think you will win every fight with the AI.

I've been seeing so many people reporting players who leave rated games on this forum in the post dedicated to it. However— and maybe it is just me who does not see what action has been taken— but it seems to me that no action is being taken on the reports.

I don't think it will die. A lot of players likely wait for more popular mods to be available for a27 to jump back in. It's just been too long since the last major release. Also, a good way to improve the gameplay is to add more Maps and scenarios while we wait for an official campaign.

In the end, I think this is not a bug but a nice hidden Easter egg feature.

The turn period is actually scaled by network latency and computation time. By default, without latency (against AI), a turn is truly 0.2 seconds. However, as soon as the game is networked with real humans in different countries, it is much longer. This is not even excluding small freezes and pauses which prolong the turn time. During latency, a turn can be as long as 0.4 or 0.5 seconds and that is enough for a focused human to issue a command. There are European players and American players in your game, so the network latency is huge there. If the game was paused or frozen by lag, it's possible to queue up more than 1 command in one turn. In the laggy A27.0, I was able to queue up 11 commands into one turn, so 3 actions in one turn is not a problem.

We really should show troops jumping onto enemy covered rams, hacking away at it. lol

@Atrik i think he's talking about garrisoning into a ram, not onto a ram to kill it.

The replay does not start from turn 0 and can't be replayed sadly. This happens on late joins. As real_tabasco_sauce said, the turn length can vary highly. In the oddity_detector the duration of the turn is computed, but not logged for replays (which could help a lot in those cases). Although it could vary for spectators again in comparison to the players. They can delay or speed up, so the players have less lag. A indicator for lag (or pause) is when more players than one have lots of commands during a turn. The reaction to garrison the ram is one a normal player would anticipate and focus on, so a fast reaction seems plausible. Same turn could also be for fast ungarrison and garrison. This is the case here. There is also some variance to see: turn 6776 is a ungarrison and 8 turns (1.6 in game seconds) later a garrison command is send. Ram attack interval is 1.5 seconds. Then turn 6793 is ungarrison and 6802 is garrison (9 turns). Turn 6776 sends the same command twice, which a program wouldn't (if it's not extra programmed to mix in slight variances to hide itself). Does someone else have the complete replay? With this doubt in mind you could check other games of Zekromus. I plead for not guilty.

A lot of players do this trick : Garrison rams in a building (fort most likely but possible to make it from workshop) Ungarrison them on approaching siege, then just after they land a hit, garrison them to safety. It's annoying because you have no way to react fast enough to kill the trickster ram. You can still : Surround your own rams with enough soldiers so that the opponent rams won't be able to unload too close to them. Surround your own rams with melee on stand-ground stance (need less then for 1 but also less safe for you own rams, you might be able to kill enemy rams though). Give up on ramming the fort and find an alternative (catapults, capture the fort, ignore the fort..). The odds that your opponent use anything else then the default garrison hotkey to do this are extremely low.

metadata.json commands.txt

A turn in a 4v4 can be quite long, so there may have been more time than you expect for these inputs to be entered. however it is a bit fishy. Maybe screen record part of the replay to see what this looks like? Or maybe give the replay so we can watch it.

His average time per move for this part of the game was 1.43 seconds, which seems completely human, further pointing to his innocence. Average time per move for the entire game (except the end) for all players: Zekromus (1628) 0.98 sec King_Okocha (1498) 2.38 sec jimo (jimo) 3.49 sec Decger (1623) 1.52 sec Atrik_III 0.91 sec jbc (1532) 0.93 sec acaradeperro (1274) 2.36 sec RangerK (1588) 1.92 sec These stats are so interesting. I've never dug into a game file before. It would be cool to show avg time per command in the stats at the end of a game.

Turn 6766 → 22:33.2 Garrisons 0.2 seconds after attack. Turn 6784 → 22:36.8 Garrisons 0 seconds after attack (at the same time). Turn 6799 → 22:39.8 Garrisons 0.6 seconds after attack.

Player 8 was yours truly. Player 1 was Zekromus. 1) garrison of the unit happens the very TURN AFTER the attack. Too fast for human reaction, right? Because I think a turn is 0.2 seconds. Can anyone confirm? turn 6766 200 ... cmd 8 {"type":"attack","entities":[11066,11525,11526,11529,11740,11741,11742,11744,12119,12389,12973,13259,13261,13264,13265,13266,13269,13270,13271,13276,13437,13438,13439,13440,13495,13517,13518,13519,13625,13627,13653,13654,13655,13656,13710,13711,13712,13750,13771,13841,13842,13843,13971,13973,14059,14060,14061,14620,14621,14632,14633,14654,14714],"target":12240,"queued":false,"pushFront":false,"allowCapture":false,"formation":"special/formations/null"} end hash-quick d0874eabce12f2f4dd5b62dd37b0d99b turn 6767 200 cmd 1 {"type":"garrison","entities":[12240],"target":10148,"queued":false,"pushFront":false,"formation":"special/formations/null"} end 2) garrison of the unit happens 3 turns after the attack on the unit. 0.6 seconds. turn 6799 200 cmd 8 {"type":"attack","entities":[11066,11526,11529,11740,11741,11742,11744,12119,12389,12973,13259,13264,13265,13266,13269,13270,13271,13276,13437,13438,13439,13440,13495,13517,13519,13625,13627,13653,13654,13655,13656,13710,13711,13712,13750,13771,13841,13842,13971,13973,14059,14060,14061,14620,14621,14632,14633,14654,14714],"target":12240,"queued":false,"pushFront":false,"allowCapture":false,"formation":"special/formations/null"} end hash 144bce974a7c9b445307dceabbc89631 ... turn 6802 200 cmd 1 {"type":"garrison","entities":[12240],"target":10148,"queued":false,"pushFront":false,"formation":"special/formations/null"} 3) but then there's also this. Garrison of the unit happens in the SAME TURN as the attack on the unit. turn 6784 200 cmd 1 {"type":"garrison","entities":[12240],"target":10148,"queued":false,"pushFront":false,"formation":"special/formations/null"} ... cmd 8 {"type":"attack","entities":[11066,11525,11526,11529,11740,11741,11742,11744,12119,12389,12973,13259,13261,13264,13265,13266,13269,13270,13271,13276,13437,13438,13439,13440,13495,13517,13519,13625,13627,13653,13654,13655,13656,13710,13711,13712,13750,13771,13841,13842,13971,13973,14059,14060,14061,14620,14621,14632,14633,14654,14714],"target":12240, ======================= Probably #3 precludes the possibility of a script. Amirite? If so, then it was a coincidence - three times in rapid succession, the moment I attacked, he made the independent decision to disappear? One of you experts please help me with this. I'm 100% certain about all this, but just in case my cheating allegation was false, here you go:

100 Food