All Activity

@phosit @Vantha @hyperion @real_tabasco_sauce @Player of 0AD @Stan` @wraitii @Itms @anyone

We had siege that wasn't OP. Catapults were weaker and it took forever for them to bring the Fortress down. That is without repairing it. The trebuchets in AoE2 will bring the Castles down easily. Fort's job is to slow down the enemy, and give you the advantage. Fort shouldn't stop the push, only delay it.

This just enhances the historical inaccuracy that siege engines shouldn't be used preferably for destruction, but for capture. Of course, the problem is OP siege, but when people bring it up, then some jump to say that they “don’t understand the game “ and “things are balanced”, which completely misses the point of being inaccurate, thus counterintuitive. I could make melee infantry fly and make a perfectly balanced game.

works also bettr with 10 units, keptan spock and ferengi shuttles. and sailor moon...

Something that could improve the AI is if ranged units keep their distance, I just mow them down with slow infantry with the Spartans, and should have a way harder time. Edit: I seem to remember this was the case in the first AoE...

Backlog milestone to my understanding is because on trac you couldn't have no milestone assigned. So no milestone and backlog are defacto the same. Personally I prefer no milestone to backlog, tho looks a bit awkward if there are only a few with no milestone. Anyway I treat them the same.

more than 15 unit military inside = impossible to capture ! Defense is the easiest way in war, siege are so OP so it is not an issue.

This is where I think Delenda Est has an advantage, in that the capture mechanic is clearly defined and localized. With capture out of the picture for the vast majority of buildings, you can do things like adding HP to Fortresses, adding special techs that increase that HP further, add more crush resistance, etc. Capture bar limits these possibilities, leaving you with balancing the balance of previously balanced capture system.

commands.txt @user1 My lobby name: tesla2402 Opponents name: deivv Closed the server in middle of the rated game.

commands.txt @user1 My lobby name: tesla2402 Opponents name: Bokluk Closed the server in middle of the rated game.

commands.txt @user1 My lobby name: tesla2402 Opponents name: Natz Closed the server in middle of the rated game.

Update: Managed to make a food.chicken specific resource and the UnitAI component to read the specific resource type to play the chicken specific animation: For testing purpose chicken is a single gatherer only and only 10 food. UnitAI code line modified:

Ah, I missed the script you posted before, and it wasn’t clear to me what you meant by “root degree”, you meant polynomial. Your formula is, for p>T, P=T+(p-T)^1/H, where P are the effective capture points, p the capture points to modify, T “threshold points” (what would be my C) and G is “diminish strength” (what would be my S). So, you have 2 independent parameters and a region condition, and I have 3 independent parameters, and no region condition. The issue is, your formula will still be visually non-linear, because you calculate effective capture points in two different regions, while I calculate only one effective rate, making the observed behavior linear. Another problem your formula has is that your T is not that intuitive as a normal/fast discriminator as my C (that’s why you have to use T=90 when P=3000, while I use C=300 when I want my threshold to be around there). Of course the advantage of your equation is that it’s easier to understand just by looking at it (and maybe easier to implement, depending on how rates can be directly handled).

Thanks but that formula is too hard to work with as it has too many parameters. The root degree I'm proposing only take 1, and produce a perfectly customizable and predictable diminishing return. We're not trying to revise capture again, just have a tool to make it less likely to instant capture certain buildings. You can already add capture resistance that seems to be subtracted from every capture attack. But that's obviously not going to help our case. Yes! No idea why it's set so low currently

I'd say "Must Have"s and "Release Blocker"s should have the next release as milestone. The others should be backlogged.

How's this going? I'd be happy to help, I'm quite into mythology. I like the name. My (I hope small) criticism is that Leonidas and Alexander are too historical, seem out of place, I'd keep it mythological, after all Greek mythology has five ages: Gold, Silver, Bronze, Heroic and Iron, and it seems to me you'll be concentrating on the Heroic Age. There are plenty of heroes and demi-gods to take from. Also, Pan is a god, he's the only Greek god that, according to tradition (or misunderstanding), died, 2000 years ago. Very different from the monsters that actually died all the time. Atlas is not a friend of men, nor a god, but a titan being punished. In the Odyssey (https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0136%3Abook%3D1%3Acard%3D44) it says “Atlas of baneful mind”, and of course there’s the Labours of Hercules story where (on some versions) when he arrives to the garden of the Hesperides, he finds Atlas holding up the sky, and asks him for help to get the golden apples in exchange of holding the sky for him for a bit, and when Atlas returns with the apples he betrays Hercules and tells him he doesn’t want to hold the sky anymore, but titans apparently are not so bright since Hercules tells him basically “ok, but hold it for me for a bit so I can adjust my cloak, if I’m going to stay here holding the sky after all”, to which Atlas agreed and Hercules just walked away. In any case, clearly a wicked being holding the sky not out of the goodness of his heart. Regarding his classification as a god, well, maybe that’s closer than anything, since titans would be deities, and “Deities, Men and Monsters” doesn’t have the same ring to it, I guess.

commands.txt @user1user cangrejoariel(1182) hosted a game and we played for 37 mins, when he realised he started losing he immediately quit without resigning. My in game name is Slendy (1150). pls ban such people, they dont understand consequences and this takes all the fun out of the game

My experience: 1100-1200 players: I can win against them. Most of them are slow and have a disastrous micro. Some are just fake rated, and most of them quit without resigning. But I know good players at this level. 1300 players: I'm probably able to beat them, with hard fights, they usually play TGs (like me), which make them way better in growing a city and a army. 1400, 1500: never played 1v1 against them, but it's a very variable rating. I saw some 1400 players which are worse than 1300 or 1250 players (the same for 1500 players), probably of a "rating farm" (winning only against 1100-1200). I'll end this part here. I'm not considering rushes because I think they turn any of these ratings into mere decoration. 1600 players: they are strong, and can easily destroy me lol 1700+: the same as 1600 Just a note: I'm between 1200 and 1300 (by the time, I'm 1300 at lobby), and this is just my experience. Rushes can kill me easily. I think this is the best way to understand these rating levels. Final: The problem are, as I said, the "rating farmers" - they host games that are only in their side, using maps that they can play without even watching (blind) - but, anyways, they don't play TGs and they don't pass the 1600 rating. That's is a truth, as 0 A.D. lobby is not a lichess.org lol

As an alternative, perhaps we could add a capture defense boost (technically a capture attack addition or a multiplier) for specific buildings, like the CC and fort. Also, we could change the default hero contribution to capture point regeneration (currently +1, which is negligible).

Ok, I see why you want exponential decay, it’s not that you want a fixed minimum capture time (hard cut-off), but a diminishing return, to softly adjust capture times for faster cases. That can also be done with no need to split the capture in linear and exponential parts, you just need a formula that modifies your capture rate to have this exponential behavior, but capture behaves linear all the way. Maybe this is what you meant by “not visible”, it’s just that in your original description that wouldn’t have been possible. This took me a bit because capacitor equations are not that appropriate for this, but what would work is R=r*(1-D/(1+e^((C-r)/S)), where R is your corrected rate, r is the rate as it is right now, D what percentage you want it to decrease for larger rates, C the rate that would indicate what is normal and what is fast, and S how sharp the correction is (more or less, the width around C where it mostly happens, for then to stabilise according to D). Then, for D=0.5, C=300, and S=100 (I’d fix it at C/3), you get these values (with C fixed, D and S can be tweaked to get different things): r=100 -> R=94 r=200 -> R=173 r=300 -> R=225 (the function scales nicely, if C=3000 and S=1000, then r=3000 -> R=2250) r=400 -> R=254 r=500 -> R=280 r=600 -> R=314 (stabilising at 50%, which can also be changed). I know that some people are scared of (simple) equations, but again, no one does the math, one gets an intuition, and what is good about this is that it does what you want, while keeping what one sees linear.

Good catch, I'm suprised you could notice it from replay at x2 speed. I took the video while developing and there was a math flaw at the time. The formula I went for in the end is simpler using root degrees to also avoid any asymptote, which make it very safe if you input low values. Again, check https://gitea.wildfiregames.com/0ad/0ad/pulls/8892 if you want to go into details. The new capture regeneration system reward garrisoning stronger units. Would be a shame to remove it now with this. Also still don't think putting a hard cap is any good compared to diminishing return.

The rate cap I propose should be after accounting for regeneration, if that's possible. The only effect should be to stop captures faster than a certain minimum time (given, of course, by the total capture points divided by this effective rate cap). But in your video it is visible, and it should be, that's the point. It goes from 4000 to 2000 points between 0:13 and 0:25, average of 167 points per sec, and then from 2000 to 400 between that and 0:39, average of 114 points per sec, which is 32% slower, and could be frustrating when one had an early estimation on how much it would take.

I don't like it that much either, but given that we do want to nerf specifically the faster captures, maybe this could be the lesser of evils. Somewhat, we cannot fix it with current balancing tool without impacting the normal capture, so maybe introducing a new one is necessary. I've set rather safe values for the PR, that should have noticeable impact only for the worse cases.

I was referring to the fortress. I agree that more points would be good. On the last point, I don't recommend adding an additional point of complication to a mechanic that is already complicated, as you mention in your OP. I agree with the other stuff, especially the need to nerf the high volume capturing scenario and not the small volume. To clear up some confusion about the nerfs that I introduced ahead of R28: by increasing the default regen rate, we essentially increase the number of units needed to achieve the "high volume" capturing scenario. At the same time, you are punished less for having an empty CC, giving you time to garrison it. I don't say that its perfect, but its better now, and in my games I see people go for siege more often.

Probably something to do per-case. Backlogging seems to be worse case to me. Maybe if the issue seems important we could add arbitrary milestones. Also I don't know if it's somewhat impolite but maybe assigning members that have skillset and bear interest in the area that the issue touches, could nudge some to pick up the issue.