Leaderboard

When we try to produce units from multiple barracks at the same time but don't have enough resources to assign the desired number of units to each barracks, it often happens that units are added to the production queue of already occupied barracks, while free barracks remain idle. This results in long production queues accumulating in fewer barracks than we actually have available, and it also locks up resources that remain reserved for those units. This week, I have been working on a mod to fix this bug in 0 A.D.'s training system. Additionally, I added an option to define the maximum number of units in the production queue. This works the same way as for free barracks: if some of our barracks have reached the maximum queue limit, new units will only be assigned to the free barracks. I'm sharing two videos showing the behavior. When producing in batches, the mod takes into account the number of occupied "slots" in the queue. That is, it does not consider the number of units produced but rather the number of assigned batches in the queue. Also, I added an alternative production system based on the standard system from AoE2, where units are assigned, as we issue the command (via hotkey or click), to the free barracks or the one with the fewest queued units. For now, this system only applies to individual units (not batches). This means we can combine both systems—producing one unit per barracks each time we issue a command or distributing multiple batches among the selected barracks when using batch production. The spirit of this mod is to offer an alternative approach to what I consider to be design flaws in 0 A.D.'s vanilla training system. Distributing it as a mod gives us the opportunity to conduct the necessary tests and receive feedback with a view toward its implementation in the next release. I want to give a special thanks to @Atrik for pointing me to the necessary game files to modify and for sharing a preliminary code to implement this mechanism. To install: unzip the content of the folder into your mod's folder. (I plan to make the .pyromod file and add it to mod.io in the future) CustomTrainer.zip AoE2.mp4 176872599_MaxQueueLimit2.mp4

Military Mess Hall says it trains heroes. It does not. The Spartan Senate doesn't say that it trains heroes.

Just was curious about your opinions. Yesterday I captured a CC and couldn't build spearmen and jav cav from it, hardly exotic units. Strictly speaking it might not be arbitrary, but when I capture from a random civ neighbor it does feel random if I then can produce the same units as in my OG buildings. "The former tenant didn't do it" doesn't really convince me.

I agree it is not smart, I also face that issue. Not exactly correct as far as I remember. AoE2 assigns the barrack based on the training/research time of queued items. So if barracks A has 1 item and barracks B has 3, next unit could still be assigned to B if A is researching a long technology.

I think it's a "bug-feature" aka limitation of current system*, but I like it and it make sens. You can think of it as representing the conquered territory not having the same capacities then your mainland ones. You can imagine that a town you occupy can't straight away produce what your mainland with it's culture and techs do. *Basically trainable units are stored in template and this later doesn't change upon ownership changes.

That works just fine, thank you @Stan` Had read your answer to Victor13, but for some reason paid attention only to this part, not understanding the "if" wasn't the condition :

Sorry forgot to note I moved the thread from "Bug Reports"

Not really, the first time itself, it showed wrong one. I tried to open again, but it was fixed to show persian structure no matter which player and respective civic icon i select.

Carthage deserves a rework, based on sources that are a little more researched than the usual superficial summaries. I don't really understand what the Numidians are doing in the civic center. These were not Carthaginian citizens, but allied troops - in other words, auxiliaries - who fought for Carthage under political agreements. Several Numidian peoples were direct clients of Carthage, so I can see why they're part of the standard roster. But not in the civic center. Slightly problematic are the Libyan lancers, who aren't necessarily at their best in the civic center. Carthage may have massively recruited Libyans into its armies, but the status of citizens for these troops was not systematic. In fact, Carthage mainly enlisted peasants from subjugated states. These peasants also worked in the fields of Carthaginian estates. Their status as peasants argues for integration into the civic center, but their status as foreign citizens argues for the opposite. I find that it also lacks mention of Libyphoenicians. They made up an important part of the Carthaginian troops and were Phoenician citizens in the other North African colonies. Libyphoenicians were known for their cavalry. In this case they could be recruited in the civic center.

no-animation.zip

These are valid error messages. (Sure not for the players) And sadly you cannot stop them from showing. https://code.wildfiregames.com/D3049

A source of frame rate drop found: attack animations. When we fight large armies, the GUI must render all of the attack animations, which is a huge task. I removed the attack animations of some units and did a fps comparison to with the attack animations and noted the results. Experimental method: 1. Mod the fps counter so that it prints out the fps value into my terminal. I then save the terminal outputs to a .txt file. 2. For each test, I ran the Combat Demo Huge map on automatic. On game start, I zoom out to my zmin (8.00 in user.cfg) and watch the units fight. 3. Kill 0ad as soon as one side lose all units. 4. Use a Python script to compute the average frame rate recorded, discarding anomalous values and the gamesetup screen etc. I did a FPS measurement and save it to a new file every time I remove an art feature (sorry Stan ). Results fpslog1.txt average fps: 76.17021276595744 fpslog2.txt average fps: 92.876254180602 fpslog3.txt average fps: 91.12413793103448 fpslog4.txt average fps: 81.94713656387665 fpslog5.txt average fps: 119.80232558139535 fpslog6.txt average fps: 188.7904761904762 file 1: Vanilla 0ad units with just my katemod. file 2: removed attack animation of just Roman skirmishers file 3: repeat of experiment 2 file 4: removed Gaul skirmisher attack animation, but kept Roman skirmishers file 5: removed some Roman and Athenian spearman animations; removed both Gaul and Roman skirmisher animations file 6: kept all above changes, replaced Roman spearman with a Mauryan spearman, then decapitated the Mauryans. Subjective observations: Experiments 1, 2, 3, 4 all had a stutter immediately after game starts, then fps rises over time. Experiment 5 was not perfectly smooth animation but playable from a first person perspective Experiment 6 had almost no lag or stutter. Units were selectable in real time without delays. Conclusions: This is consistent with my experience of Romans being one of the most lagging civ and Mauryas lagging significantly less. One big source of lag (at a GUI level) when fighting is the sudden need to render many animations. Removing spearman animation had the biggest effect on fps. A mitigation strategies: simplify skirmisher attack animation (we can't remove it completely because you wouldn't know whether they are attacking anymore); remove spearman / melee attack animation (you will not watch your spearman in battles, you just assume they are fighting ).

Hey can you take a screenshot with F2 or a picture ? In the game options you might also switch to vulkan and or disable gpu skinning

I was thinking the "Treasury" building would have these architectural motifs^ Yeah, this:

This one? https://www.inrap.fr/autour-du-temple-qasr-al-bint-petra-14910 I know it is sad that it is not possible to implement buildings who mixes terrain/biome elements, but I think it would be disappointing to not have the buildings everyone imagine or have seen about Petra.

No promises, but I'm working on that

"Sim update" is at 280 while "gui sim update" is at 200, but yea, that seems to be the problem Edit: (atleast for me)