All Activity

It is based loosely from a Roman bronze figurine depicting a sort of gladiators, generally interpreted as Crupellarii: In 21 AD during the reign of Emperor Tiberius, two Gaulic nobles named Julius Florus and Julius Sacrovir revolted against the Roman Empire. The revolt was a result of the denial of frequent petition for tax relief and debt forgiveness among Gaulic debtors. Florus and Sacrovir managed to raise an army of 40,000 rebels, some of whom were professional gladiators. Among those gladiators was the Crupellarius, a class of gladiator that was particularly popular in Gaul. The Crupellarius was a heavily armed and armored gladiator who was typically a very tall, large, and muscular man. Florus and Sacrovir placed the Crupellarii as the front ranks of their army, where they were to act as human tanks, pummeling and bashing through the Roman ranks. Once in battle, the Romans found that their gladii and pilum (javelins) were practically useless against the Crupellarius’ heavy armor. Thus, Roman soldiers retrieved their engineering tools such as axes, adzes, and pickaxes. Using them as weapons the Romans were able to pierce the Crupellarius’ heavy armor and batter down the behemoths. Once the Crupellarii were defeated, the remaining Gaulic rebels were slaughtered.

I was just wondering what this meant or what effects this controlled.

I have to agree with sj113 here, it is a rather expensive steel-intensive unit if you take in all of the required upgrades into account. It has to give at least some benefits for it all to be even remotely worth the cost. Otherwise it will be the Seleucid Elephant Champion situation all over again, which seem to have been nerfed to oblivion, making them unsuitable for anything (in this state they can not be used neither to destroy buildings nor kill units). Just my two cents.

@Genava55 that last image, the helmets are medieval not roman right ?

Une vidéo en français sur le Cirque Maxime:

Hi @ffm2, thank you very much for the steady test results. It will be far easier to analyze them without mods on your side, no worries about playing with others using mods. I had indeed missed #7635, I understand better now. I am going to take a closer look at your latest OOS report during the week and I'll get back to you.

Yes @BeTe what you see there is the same as what is currently released (version 27.1)

I don't think so, it's very expensive and I've never produced more than 25

When will Delenda Est be on mod.io?

Yes, it is. But, has your friend tried Silver Shield Pikemen with Chariots yet? Pikes hold the line while Chariots destroy everything from afar. Each civ has some OP units. Roman infantry is very OP when used effectively. Try using the Testudo formation (switch formation usage from "Walk/Patrol only" to "No override"). Testudo keeps all your infantry swordsmen in a very packed formation, slicing and dicing any nearby enemies in seconds. Add some Centurions to the mix for extra DPS. Centurions can be upgraded from Elite swordsmen and spearmen, or trained at Forts once Marian Reforms are researched.

historical is the counter But also making sure that you dont let them mass Cataphracts

I feel like the Selucid elite cav is too op. I need massive advantage in numbers when I play against my friend. Consular cavarly dies quickly, legionaries hold the line for a while but in a straight battle I need massive number advantage with constant resupply in units.

Gladiators have evolved considerably, and the ones we know best are from the imperial period. There are a few books on the subject: Plates and descriptions: Plates and descriptions: Plates and descriptions: Bonus: I hope you find it interesting

I will try to test a couple games using the Roman heavy infantry tonight. I might even try making a sim-city with walls. Should be fun.

There is a dedicated thread for them:

Looks amazing! What would be the purpose of this building? Some ideas: Train gladiator champions (which exist as templates but are hidden from the main game) Garrison units to rank them up very quickly

@Gurken Khan, Okay, thank you very much

@real_tabasco_sauceThese are up-to-date commits, right? https://gitea.wildfiregames.com/0ad/0ad-community-mod/commits/branch/main

Here is my OOS log and the one of diagonalo. Also included are the 2 replays of us. I apologize on behalf of diagonalo that he used mods, he was not aware that we were looking for bugs. I was the only player OOS though. I was present from the setup. I was observer. I did not flare, I did not chat. There was a flare during the OOS though from Flammea which could be a hint. Ricci was not present at all. 0ad_OOS-2025-05-25.zip

Yes, I told you I do it from now on. I just had a OOS with only feldmap on.

@ffm2 You both should just test the RC without mods, instead of constantly trying to prove that mods weren't at fault for it. Replaying the game without mods is not the same as playing the game without mods.

I suggest adding left-handedness. 10 - 15 % of the population are left-handed. But the main reason would be to break up the synchronized animations. E.g. when 50 skrims attack in union. If some of them where mirrored it would look a bit more chaotic.

elexis has to add this: ffm was present from the beginning, did not rejoin everyone except ffm had the same hash on turn 1560 ffm had the same issue one match later ffm uses only 4k, feldmap and visibility mod sim state was from 3 turns later: oos_dump.txt oos turn: 1560 net client turn: 1563 sim turn: 1563 binary simstate is identical! textual simstate contains only differences in RangeOverlayManager.enabledRangeTypes local entities but both states are 3 turns too late, and its unlikely the mechanism will ever write simstate dumps from the correct turn, because the turn lengths are so short and because multiple turns are being computed in advance as far as I know. "Currently, the RangeOverlayManager is serialized" False: RangeOverlayManager.prototype.Serialize = null; The textual output showing this is a regression introduced in 9fc6c3c89769a3, pointed out in #7634 and stated to be addressed by c475cc22652528ce7014d "is definitely caused by one of your mods" pure conjecture ffm did not use riccis mods, ricci computed the same hash as everyone else but ffm! riccis hash is also computed without mods "Doing it any other way is just a waste of time, as you're all finding out now." you can be grateful if you get an OOS report at all, players reporting that is rare, you dont get many chances to identify an OOS, so if you want to dismiss an OOS report, you better investigate it first and not disregard it easily. it's possible it's caused by a broken mod but if you dismiss it without investigating it, you might be ignoring a valid report which can cause the bug to go not unnoticed but unreported for months. only difference in commands.txt besides the mods in the first line: --- commands_ffm.txt 2025-05-24 12:17:26.000000000 +0200 +++ commands_ricci.txt 2025-05-24 12:21:51.000000000 +0200 -hash cc1eb515c7554393f2a2dae2ca4770e6 +hash a763d2495ddab5956941ea577d3c6f30 another bug, not only in JS GUI but also the turn manager should not allow this: turn 3433 200 cmd -1 {"type":"stop","entities":[],"queued":false} cmd -1 {"type":"stop","entities":[],"queued":false} when ffm replays his own replay: Executing turn 1560 of 5970 ERROR: Replay out of sync on turn 1560 when I replay ffms replay without mods, also: hash MISMATCH (a763d2495ddab5956941ea577d3c6f30 != cc1eb515c7554393f2a2dae2ca4770e6) Turn 1560 (200)... So ffm did not rejoin, yet he was the only one to compute something different on turn 1560 but on turn 1563 the difference was gone already and he had this phenomenon on multiple matches. I also recommend never to release 0ad with OOS being not fixed, and therefore you should not remove 0a4bfefb1e5f40d93180690e328b11e148dec0cb but include this in the re-release and to bump the mod version in mod.json from "0.27.0" to "0.27.1". You're saying you release "0.27.1" so the mod version showing "0.27.0" seems misleading. Bumping the version should (TM) mean that due to the mod compatibility check in the lobby, 27.1 players can play in the same a27 lobby, but they can only join 27.1 games, while the 27.0 players play in the same lobby and can join only 27.0 games. A reason against doing it this that was brought up by sera was that you find yourselves unable to provide a release for all platforms and thus some players would be stuck to the old version for months (and thus would not be able to find players to play with). but if that problem was real, then you'd have the same problem with releases, not only re-releases and it doesn't stop you from releasing either. if that OOS 0a4bfefb1e5f40d93180690e328b11e148dec0cb was fixed in 27.1 and the version would have been bumped, then now you wouldnt have to investigate if it could be caused by the modifiers cache OOS. Worse: players get used to that OOS occurring and this means they will not report OOS anymore because they think its the same OOS.

Yes, I disabled all mods but feldmap now and will report once it shows up again. However: -RangeOverlayManager is not serielazed (see the Serialize function) -I was in the game from the start (no rejoin) -the binary dumps were identical

Regardless, testing of new software should be done in a blank-slate state, without any additional code. This is an established practice in software development, to better detect and isolate buggy code. Doing it any other way is just a waste of time, as you're all finding out now.