why alpha 24 is not nice ?

[wowgetoffyourcellphone]

11 minutes ago, Imarok said:

I know I'm totally irrational about this, but I loved watching the elephants putting wooden beams on buildings with their trunks.

Yeah, I don't understand the argument against them having this ability. If it looks "weird" for an elephant to do this on their own, then just add a driver? 

[nani]

19 minutes ago, wraitii said:

Can you clarify? We didn't change anything in terms of command delay, so I don't understand why you experience 'slower' visual feedback on A24.

36 minutes ago, nani said:

I send a command to build or attack and have to wait to actually see them do it before doing another command as sometimes they don't do it. I know it all very ambiguous but I can't seem to describe better.

21 minutes ago, wraitii said:

Can you also explain this further?

48 minutes ago, nani said:

Example:
-  1 (select group) key  vs   Ctrl + 1 key (make group)
-  H (halt) key   vs   Space + H (place house with autociv mod)
- Any similar to the two above

I don't think the solution is to create hotkey modifiers + Engine.IsHotkeyPressed as in all previous alpha it was just working fine and allowed you to create any combination possible. (Also this would create implicit state making possible unexpected sideffects)

 

[wraitii]

7 minutes ago, nani said:

I send a command to build or attack and have to wait to actually see them do it before doing another command as sometimes they don't do it. I know it all very ambiguous but I can't seem to describe better.

It'd be good if you could get a more consistent description because it sounds _very_ broken, but we've not really had reports of anything like that except from you as far as I recall. Maybe try playing and recording your screen/input?

7 minutes ago, nani said:

-  1 (select group) key  vs   Ctrl + 1 key (make group)
-  H (halt) key   vs   Space + H (place house with autociv mod)

Ah, yeah, that problem. Indeed that will trigger H if you drop space before H. TBH this is really my fault, I did not anticipate that this would be a problem, and I guess I'm lucky in that I don't personally experience it using control groups (I guess I naturally drop the # first).

I'll fix it for A25, but in the meantime the best advice I can give you is to avoid conflicting/ambigous hotkeys or train your brain to drop the letter first.

7 minutes ago, nani said:

I don't think the solution is to create hotkey modifiers + Engine.IsHotkeyPressed as in all previous alpha it was just working fine and allowed you to create any combination possible.

The reason why I changed this was that there was unexpected behaviour in A23: for example if you pressed Ctrl, then D, then 'Ctrl' hotkeys remained active, but his did not happen if you went "D then Ctrl". There were a number of related oddities.
Unfortunately in fixing that I assumed that 'retriggering' hotkeys when releasing a key was the most logical behaviour, when it probably would have been better to not do that.

[chrstgtr]

1 hour ago, wraitii said:

It'd be good if you could get a more consistent description because it sounds _very_ broken, but we've not really had reports of anything like that except from you as far as I recall. Maybe try playing and recording your screen/input?

Quote

This happens. Units seems to randomly not listen. It seems to happen with shift commands for me. 

[wraitii]

2 minutes ago, chrstgtr said:

This happens. Units seems to randomly not listen. It seems to happen with shift commands for me. 

Do you use the default formation feature (or formations in general)? It's the one thing I could see interplaying badly in some situations.

[chrstgtr]

1 minute ago, wraitii said:

Do you use the default formation feature (or formations in general)? It's the one thing I could see interplaying badly in some situations.

It has happened when I had default formations on and off. I randomly get idle units now when I never did before. 

[wraitii]

K, well it'd be great if you could upload the replays next time that happens, because so far the only somewhat related issue we have documented is #6046, but that's actually too many orders, not the reverse

[Sundiata]

5 hours ago, Imarok said:

I know I'm totally irrational about this, but I loved watching the elephants putting wooden beams on buildings with their trunks.

5 hours ago, wowgetoffyourcellphone said:

Yeah, I don't understand the argument against them having this ability. If it looks "weird" for an elephant to do this on their own, then just add a driver? 

Yea, admittedly, if the elephant would just be paired with a mahout, I wouldn't have such a problem with it. My problem is just with autonomous animals. I've proposed giving it a mahout myself, several times if I'm not mistaken, and it seemed like such a simple, straightforward fix, but was never done.

Can we all agree to give it a mahout?

 

4 hours ago, wraitii said:

It'd be good if you could get a more consistent description because it sounds _very_ broken, but we've not really had reports of anything like that except from you as far as I recall. Maybe try playing and recording your screen/input?

3 hours ago, chrstgtr said:

This happens. Units seems to randomly not listen. It seems to happen with shift commands for me. 

You know, I've noticed the same thing and it can cost you units. Like retreating from enemy area, a certain number of your units will break off and start fighting enemies on the way. Like they just stop and reassign themselves to the nearest enemy. Especially when you have a large group, some of them maybe get a little stuck behind other units, and it just seems to cancel whatever order you gave them. 

.

[chrstgtr]

41 minutes ago, Sundiata said:

You know, I've noticed the same thing and it can cost you units. Like retreating from enemy area, a certain number of your units will break off and start fighting enemies on the way. Like they just stop and reassign themselves to the nearest enemy. Especially when you have a large group, some of them maybe get a little stuck behind other units, and it just seems to cancel whatever order you gave them. 

 

I had forgotten about that, but yes I've noticed some units not retreating. I don't know if it is the same thing or if they were hit during their retreat which caused them to break command. Same with units walking off to attack when near the border, but I think those occurrences were the result of the known issue where towers shooting arrows outside their range

[Stan`]

Replays are welcome

 

[andy5995]

On 25/02/2021 at 8:56 AM, Nescio said:

Siege engines were removed from them at the explicit request of someone who pointed out they were only slightly more expensive than arsenals but much more effective.

Perhaps rams only could be readded to the army camp, I don't know how that will affect balance, it needs testing, as do other things.

 

A ticket I just opened (6084)

I wonder if it would be a nice or interesting feature if buildings could have an extra attribute set. For example, a Roman military camp could only produce siege units if it is fully garrisoned, or the speed of unit production were based on how many units were garrisoned in the building (i.e. unit production is faster if fully-garrisoned, half the speed if half-garrisoned).

I don't think it would be a good idea for all buildings, but maybe it would be a good compromise for units such as the Roman military camp?

[feedtalefour]

To have a mod apart from 'public' that contains all balance changes in a25. All new development is done there then the files are replaced before release. get-vidmate.com instasave.onl

Edited March 3, 2021 by feedtalefour

[thankforpieOfficial]

On 25/02/2021 at 2:46 PM, chrstgtr said:

HP bonuses don't have to impact champs. We should be able to exclude those. Or just adjust their HP lower so it doesn't have as large of an impact. For example, most (all now?) champs are only available in p3. So a HP bonus from p1-->p2-->p3 shouldn't impact a p3 unit's HP.

Regardless, this was only one suggestion. I also like the idea of changing defensive constructions to be less op.  I still like giving phasing HP bonus, but it isn't super necessary. 

Overall, I like the balance changes. Based on what I currently know, I wouldn't change much in terms of unit stats. 

Yes. Ptol bonus is still nice, now. Just less significant of a difference than before. 

And free houses with ptol is just one example of how I think civs should be modified to be more different. Other possible reversions would be something like

1. giving celt their building pop bonuses
2. giving siege factories only to mace
3. keeping worker else for mauraya (and maybe giving it building abilities back)
4. I like walls/towers for iber
5. I like cav health bonus for persia/sele (so I would take this away from other civs)
6. I like kush pyramid bonuses
7. I like rome camps and would give it siege again to make the difference more pronounced
8. I liked skirati exp. bonuses for sparta and I think this was nerfed too much 
9. Carth and athens could use better differentiators imo
   1. carth champs from temples might be a fine strat with champs being a more viable strategy. I haven't tested this
   2. athens basically is no longer unique in any way?

while i agree that civs should be different from each other, making ptoles and especially celts op again is not the way to go

these two civs were much stronger and more often picked than rest. it was not uncommon to play 4v4 game with only 4 civs, 2 of them being brits and gauls

Edited March 2, 2021 by thankforpieOfficial

[chrstgtr]

1 hour ago, thankforpieOfficial said:

while i agree that civs should be different from each other, making ptoles and especially celts op again is not the way to go

these two civs were much stronger and more often picked than rest. it was not uncommon to play 4v4 game with only 4 civs, 2 of them being brits and gauls

Then other civs should be improved and given bonuses that are actually helpful instead of something like walls that no one uses. The ptol and celts bonuses themselves weren't OP as much as other civs just didn't have useful bonuses. 

Also, celts and ptol were used a lot bc they of their unit composition (e.g. slingers and camels) bc those units were seen as OP as easiest to mass with celts/ptol. Those units should no longer be seen as OP and thus those civs should no longer be the only civs used. 

[faction02]

On 01/03/2021 at 11:16 PM, chrstgtr said:

This happens. Units seems to randomly not listen. It seems to happen with shift commands for me. 

 

On 01/03/2021 at 9:51 PM, nani said:

I send a command to build or attack and have to wait to actually see them do it before doing another command as sometimes they don't do it. I know it all very ambiguous but I can't seem to describe better.

If you shift-click a path leading a unit to go outside the map (in the black area) as you might do when you explore around your territory, the unit will stop at the border for a while, wait a bit, before moving to the following rally point. 

Is it possible that the same mechanics apply in different cases which could explain why units might seem to not listen whereas they are simply "waiting"?

 

[wraitii]

8 minutes ago, faction02 said:

Is it possible that the same mechanics apply in different cases which could explain why units might seem to not listen whereas they are simply "waiting"?

Yes, anytime a unit cannot path somewhere (typically > runs into units) it'll take some turns to find a workaround path, in which it might not move. For A25 it should be less long as the turn length will be reduced in MP. It will also be improved if I end up merging Unit Pushing.

Edit -> that being said, I don't know if that's the problem here.

[faction02]

22 minutes ago, wraitii said:

Yes, anytime a unit cannot path somewhere (typically > runs into units) it'll take some turns to find a workaround path, in which it might not move. For A25 it should be less long as the turn length will be reduced in MP. It will also be improved if I end up merging Unit Pushing.

Edit -> that being said, I don't know if that's the problem here.

Nice! 

I have tried to generate some actions that I thought could also be interpreted as "clicking outside the map" before queueing other actions afterward but I am indeed going nowhere with that. Thanks for your answer

[chrstgtr]

There seems to be another bug where units get stuck on the corner of buildings that requires me to micro around it. Seems like this could be the problem here too. But the corner building issue never seems to fix itself on its own. 

5 hours ago, wraitii said:

Yes, anytime a unit cannot path somewhere (typically > runs into units) it'll take some turns to find a workaround path, in which it might not move. For A25 it should be less long as the turn length will be reduced in MP. It will also be improved if I end up merging Unit Pushing.

Edit -> that being said, I don't know if that's the problem here.

 

[Imarok]

On 04/03/2021 at 4:58 AM, chrstgtr said:

There seems to be another bug where units get stuck on the corner of buildings that requires me to micro around it. Seems like this could be the problem here too. But the corner building issue never seems to fix itself on its own. 

 

If you have a replay of it happening please create a ticket and upload it there.

[andy5995]

This video shows a lot of rams bunching up around houses, not destroying the houses and ignoring a nearby CC. Seems as though they are a bit confused trying to destroy the tower.

 

This was a game me and Jammy played against the AI. The rams around the houses are the AI, enemy combatants. I'm blue, the houses are mine.

 

Video and replay attached.

2021-02-26_0002.zip

Edited March 6, 2021 by andy5995

[wraitii]

I've sen that one before. I think the problem is rams target the tower. Then they fail to reach it. So they look for a new target... Which happens to be the same tower. Endless loop  I'm not entirely sure if the loop is in UnitAI or the real AI or both though.

[captBluesky]

On 01/03/2021 at 1:11 PM, wraitii said:

It'd be good if you could get a more consistent description because it sounds _very_ broken, but we've not really had reports of anything like that except from you as far as I recall. Maybe try playing and recording your screen/input?

Ah, yeah, that problem. Indeed that will trigger H if you drop space before H. TBH this is really my fault, I did not anticipate that this would be a problem, and I guess I'm lucky in that I don't personally experience it using control groups (I guess I naturally drop the # first).

I'll fix it for A25, but in the meantime the best advice I can give you is to avoid conflicting/ambigous hotkeys or train your brain to drop the letter first.

The reason why I changed this was that there was unexpected behaviour in A23: for example if you pressed Ctrl, then D, then 'Ctrl' hotkeys remained active, but his did not happen if you went "D then Ctrl". There were a number of related oddities.
Unfortunately in fixing that I assumed that 'retriggering' hotkeys when releasing a key was the most logical behaviour, when it probably would have been better to not do that.

I've actually complained about this on several occasions both in Lobby and on #0ad-dev. This is what I call the multi-sampling of the mouse (and possibly kb) inputs.

 

This evident when the game is heavily loaded and update rates bog down. (lag but not graphics lag).

 

Ideally, as soon as a player selects a destination/command for a group of units (chop wood, build structures etc) the mouse data (button states and mouse position) should be recorded *once*, and stored for subsequent use in the mod js for that command.

But what seems fairly obvious to me is that several routines are going back to the mouse interface and asking for mouse button state, and position over and over. In 23b it was bad in heavily loaded games. In 24b it is far worse. Now it appears that not only is the js code multi-sampling the mouse IO (not an SDL issue Stan), it is re-sampling the mouse raw data for *each unit in the group selected for the that command*. That is evident in the case of *unit spreading*.

If you push the operations rates (like you need to, to stuff as many commands in unit time as possible)  you can end up with a group of units spread out in a fan pattern (across the map)and stopped/idle instead of converging on command destination. Again, evidence that for each unit in the group the code is going back to raw mouse data and sampling raw mouse data. And of course since the player had long since moved on to the next command, the js code is seeing a moving mouse position and a different position for each  unit.

[nani]

11 minutes ago, captBluesky said:

I've actually complained about this on several occasions both in Lobby and on #0ad-dev. This is what I call the multi-sampling of the mouse (and possibly kb) inputs.

 

This evident when the game is heavily loaded and update rates bog down. (lag but not graphics lag).

 

Ideally, as soon as a player selects a destination/command for a group of units (chop wood, build structures etc) the mouse data (button states and mouse position) should be recorded *once*, and stored for subsequent use in the mod js for that command.

But what seems fairly obvious to me is that several routines are going back to the mouse interface and asking for mouse button state, and position over and over. In 23b it was bad in heavily loaded games. In 24b it is far worse. Now it appears that not only is the js code multi-sampling the mouse IO (not an SDL issue Stan), it is re-sampling the mouse raw data for *each unit in the group selected for the that command*. That is evident in the case of *unit spreading*.

If you push the operations rates (like you need to, to stuff as many commands in unit time as possible)  you can end up with a group of units spread out in a fan pattern (across the map)and stopped/idle instead of converging on command destination. Again, evidence that for each unit in the group the code is going back to raw mouse data and sampling raw mouse data. And of course since the player had long since moved on to the next command, the js code is seeing a moving mouse position and a different position for each  unit.

That sounds very plausible (Engine.IsHotkeyPressed) is used very much in gui/session/ for interface

[soloooy0]

things that should change in the A24
the Iberian ship needs to create fire damage
the Iberian castle needs + 1,000HP
the archers are op, they need a major nerf
the Romans should have the castrum with siege and take away the workshop
The civs only with a battering ram, I don't see it useful either, the workshop could be made in castles
default formation produces troop suicide
heroes needing bonuses: agis II and chandragupta
the Athenians should have some champion in phase 2, or all the Hellenes the stoa
phase up, you have to give bonus to units again

[captBluesky]

OMG, what have they done to my Romans?!!

 

Cat's don't seem to target soldiers anymore.

Ships are now laughably impotent and can easily be dispatched by archers (really?), while ships garrisoned with cats do nothing against their attackers in return.

Roman champ cav seems to have lost all its tech upgrades, and now are easily dispatched. **about the only defense Rome had against ramSpam was fast, tough champ cav. That's gone now.

Rome still has no defense against long range ground units (archers, slingers) save for seige, which now is so fragile as to be nearly useless. **Romans need mercenary archers/slingers option (like other factions do).

Rome had strong walls, and strong buildings ("had" being the operative word), which helped offset horde attacks.

It only took a few games against the ai horde attacks to realize just how badly nerfed Rome had become in 24b.

 

24b seems to cater to the spam-fast-and-hard crowd (the celtic-only wonder boyz). Romans had been very strong, but range disadvantaged, slow (to build), and structurally expensive. But with engineering techniques, they could hold, and gain territory. No longer. With their camps they could project power that offset other limitations. Now even that capability has been emasculated.

 

Non-spamming type thinking seems to have displeased the prior celtic-horde old-boy network. In 24b that sort of inappropriate thinking appears to have been corrected, preserving the status quo.

I'm sure we'll read and hear how all this was *necessary* and clearly a *fair* change, if we  would only be reasonable and accept the mandates imposed on us by our black hooded masters. And that any descent is indicative of some kind of character flaw of anyone who would dare criticize these changes.

 

For those who might rebel against what is clearly tyrannical conspiracy, I suggest the following..

We, the oppressed, should mandate that everyone involved  in pushing our beloved developer team to implement this ludicrous perversion of Rome (and other factions I fear) be made to play only the Roman faction (and no other) for the duration of 24b, until version 25 arrives. I  mean, since all these changes are fair, balanced and just, they should have no objection and gladly accept this edict as a token of good will and to promote 0ad social cohesion.

 

Note:

My comments are in no way intended to disparage the development team. Those folks work very hard for low pay ($0.00), and are about the kindest, most agreeable folks (except for wraitii, but he's still ok) I've ever encountered.

Please drop some kind words on the wildfire team!