Seleucids

Check this out: Although there should be some kind of more visible marker for fish. Sounds like something for my GUI mod

This is what happens when somebody attempts to change simulation, by injecting commands: Some mods try to train units automatically so that economy is done automatically and the player can focus on the frontline. This is no longer a GUI level activity. It's not a GUI mod. Somebody is making some kind of questionable autoqueue mod... but the cheater made a nub mistake when formulating their command and blew their cover.

If it's not too much of an ask, can account creation date become available? I think it would really help out with many problems.

I would like to implement a feature which fetches the creation date of a user, alongside other profile items. Engine.GetPlayerProfile() gets me the total games played etc. I also want to know the age of this user. Can I just add another parameter to the query? How can I achieve this? My ultimate aim is to make a mod which assigns Chevrons to users based on age of accounts @Dunedan is the creation date documented at all? Would it be possible to let clients query it? Thanks

GUI mods which do not change simulation are little more than tweaking graphics options in the settings panel. 0AD's exposed customisation options are rather limited, but most features of the GUI mods e.g. ModernGUI would be provided by default in other games. ProGUI's automation features are no longer GUI mods. It makes changes to simulation. ProGUI is a combined package of a GUI mod and an autoqueue mod. People debate about the autoqueue part and not the panels. Note that all mod-level information reveal cheats have been patched since A27. It is no longer possible to make a cheat mod (pure js level) that reveals information, because the engine commands have been insulated. If you want to cheat, you would have to edit the engine and hopefully don't get a fatal OOS. Cheats are not as OP as you think. They are too distracting to use as your screen gets cluttered by too much information. It distracts you from your micro. Reveal map hack in A26 required you to constantly switch back and forth - less apm available for actual playing. Reveal chat baited its users into sending resources to the enemy. Seeing the trash talk in spec chat is really distracting. That's why nobody consistently used cheat methods in spite of them being so easily accessible, in A26. In conclusion, Pure GUI mods are fine but packing in some simulation changes will be questionable.

Update: Autociv 27.0.3 has been released: https://github.com/nanihadesuka/autociv/releases Features: Additional counters for total mobilisable military, melee, range, KD ratio A page in options to adjust update frequency and the counters that you want to see

Technical borders: Any mod which only changes art and audio folders are completely safe and non-cheating. Most mods that change GUI are safe and non-cheating, unless they reveal information about the enemy, which is no longer possible. The reveal chat vulnerability has been patched and no single change to gui folder can enable you to access forbidden information in A27. Real cheat mods would have to touch the simulation folder. But this comes with high risk of fatal OOS @WiseKind I appreciate your effort in writing such a long and meticulous essay

Exactly, same mechanism in terms of the code. I'm not sure to what extent was the Mauryan ram Easter egg intentional though.

I don't think it's necessary to remove this unit because it is not particularly OP and it's nice to have an Easter egg. Han capturing a Persian is a rather rare situation

This is not a bug ! Technical explanation: Han civ was pulled straight out from Terra Magna A23 and had its code fixed for a24 and A25, as a single standalone mod civ. On incorporating into A26, for balance, many features of the Han were removed. However, they didn't delete the template files; they just removed the OP units from Han production buildings. Crossbow cav and mobile boltshooter tank were examples of these. But the production buildings of other civs do not have explicit inhibition of these units, especially the Persian CC which can train all cav class units. As a result, the hidden units can be trained by capturing other civs' buildings.

This also seems fine but 10% wont make much of a difference. 30% is a better starting point. The units that die too fast are infantry and especially ranged infantry. Cavalry doesn't have this problem and therefore they don't need health increases. Note that each ranged cav has double the health of a ranged inf with more armour. Each melee cav is 60% stronger than its inf counterpart. OP. Auto-upgrade with phases might be fine.

Actually not at all. Longer to die = less death updates -> less need to call entity corpse / mirage replacements which task performance + less need to call death animations (also performance issue). There will be less stuttering as well. I think the performance issue you mean is constantly having 200 units on the screen. This will keep the fps low for longer. However, right now the min fps is the same if not even lower when you are at 200 pop, so it doesn't really change much. The quick death approach is just banning units from the map to reduce lag. In any case you can just limit max pop to 175. To summarise, rate of death has not much impact on performance.

Great, so what health values are we suggesting? Let's try: 150 health for melee inf 75 health for ranged inf Cavalry can stay as they are, for now.

I think there is nothing wrong with meatshield meta. But you can try to increase armour of ranged units as well, so that everyone is strong. All in all we just want units to live a bit longer. Right now, if you make 1 mistake, you have lost it for your team. 2v1s are especially problematic, there should be some kind of retreat possible or at least give all players enough time to wait for their ally to arrive. Meatshield or not, please please just no more vapourising units ! Suggest values please

template_unit.xml The pathfinder has been fixed for you simulation/templates/template_unit.xml 2025-03-11 15:48:17.774030190 +0000 @@ -62,7 +62,7 @@ <Anchor>pitch</Anchor> <Floating>false</Floating> <FloatDepth>0.0</FloatDepth> - <TurnRate>14</TurnRate> + <TurnRate>100</TurnRate> </Position> <RangeOverlayManager/> <RangeOverlayRenderer/> @@ -126,7 +126,7 @@ <WalkSpeed>9</WalkSpeed> <RunMultiplier>1.67</RunMultiplier> <InstantTurnAngle>1.5</InstantTurnAngle> - <Acceleration>35</Acceleration> + <Acceleration>1000</Acceleration> <Weight>10</Weight> </UnitMotion> <Visibility>

Spearman and swordsman have 3 hack 3 pierce armour. What is this joke? Units die way too quickly in this alpha (and in A26 and in A25). There is no possibility of retreating from a fight. If you retreat, you will loose everything. The amount of damage dealt while turning around and pathfinding outside enemy range is enough to kill the melee unit. Ranged units die almost instantly. The attack damage is disproportionally high compared to the effective health of units, so we see instant vapourisation of entire armies. The problem of units dying too quickly is proliferated by forge techs focusing too much on attack damage and not enough shield upgrades. For comparison, in A23, the melee units had 5 hack 5 pierce armour by default. Fully upgraded units can have up to 8. Meanwhile, the damage techs are not as strong. That allowed reasonable death rates. How do we fix this? Simple: 1. Nerf the attack damage upgrades, especially cap the T3 to +1 2. Improve shield upgrades. Increase like +1 +2 +3 each tier. 3. Increase turn angular frequency. 1000 radians per second is a good value. There is no possibility of dancing given the new pathfinder which stops the unit before it turns, plus the lag which makes dance impossible. A high angular frequency will aid unit pathfinding, prevent units from being stuck and allow retreating. 4. Default unit armour values: Spearman: 6 hack 6 pierce Swordsman: 6 hack 5.5 pierce Pikeman: 8 hack 10 pierce

https://discord.gg/qADktZxc

You can get these features in ModernGUI mod by Atrik

Lag is only observable in 3v3 and 4v4 TGs. Today I made a mod which removes the walking and attacking animation of the jav cav. I limited the animation to A23-style low arm javelin throws of the rider and completely removed the walking and idle animation of the horse. That instantly reduced a lot of GUI lag for the Carthaginians. It would seem that cavalry model and animations are a major source of GUI lag. Interestingly, camels lag less than horses because they have less attachment points. I will update you on lag after I remove all cavalry animations. Some experiments showed that having too many objects in your selection group can also be a source of stutters. Today I took over the base of a player who makes less barracks than me and I also experienced shorter durations of stutter when accessing barracks. Huge GUI crashes happen when I am trying to select a large group of units. Again, strangely, in 1v1, selecting the same group doesn't crash the GUI as much. The total number of visible units on the screen are the same in 1v1 and 4v4 situations.

This is the optimal settings for me: this.suppressionTime = +this.template.SuppressionTime / 15; this.suppressionRangeSquared = +this.template.SuppressionRange * +this.template.SuppressionRange / 5; The suppressiontime was set to 60000 by default The suppressionRangeSquared is 25600 by default

The attack detection system does not alert the player frequently enough. A whole army has been killed off-screen and I did not get any kind of verbal notification nor attack warning sound. Sometimes I rely on my allies to ping me and flare when rushed, because I get 0 warning when attacked. I found the source of the problem to be the javascript file AttackDetection.js having an attack suppression time and a suppressionTransferRange. This feature prevents spamming attack alerts by limiting the minimum time span between 2 consecutive alarms. However, these 2 values are way too long, causing the alert system to be ineffective. There should be an option to change its value or just decrease it.

siege tower op.zip Watch Otherperson spam towers sword cavs cannot take them down

Here is the deal: Improve the pathfinding of seige so they look less buggy, but: decrease some of their pierce armour. Catapults are kind of OK but Siege Towers are just insanely OP now. They are too tanky vs sword units and deal way too much damage. Without some GUI mods, it's hard to see their roots so that your units disappear into their model by overlapping.

Getting off topic, but here are the reasons: 1. Changing any simulation = OOS 2. Hugely different files in public = file hash check failure = false OOS alarms 3. How can you change the files on people's computer? There will have to be some way of updating the game. For us Arch users, WFG can just push or pacman, but then everyone has to update all the time and stable distros such as Debian and Ubuntu certainly won't update their repo in time. For Windows users like you, you have to re-download and re-install new versions, which you will find inconvenient. Solution: When game starts, run an automatic update checker to compare local files to upstream files. Basically like a separate launcher app, similar to Minecraft launchers. Then you can easily update to upstream.

Cachy OS I love necrobumping ancient threads that are older than me