- User Since
- Feb 2 2020, 6:02 PM (21 w, 6 d)
Fri, Jul 3
I'm not too sure about this change, seems too specific to be actually useful. Sparta already has issues with its population limit and special techs like this alleviated this problem a bit, even though not often used.
I like it costing only metal, makes a lot more sense. I'm not too sure about the total cost, it might get tricky (especially as ptolemy) to play without extra mines. That said, it's overcompensated by spam and military colonies for map control, so I think this is a positive change overall.
Thu, Jul 2
Different players have different play styles. Not everyone is interested in competitive multiplayer. Many people are perfectly happy with single-player vs the Petra AI.
The point is that these phase stat increases strongly favour a particular play style, punishing players wanting to explore different strategies.
Actually the technology requires the town phase (as is the case for the rotary mill).
I think this will increase imbalance between heroes instead of putting them on the same level, unless other factors are considered in the same patch like bonuses, combat prowess, etc...
Fri, Jun 19
Looks good to me!
I agree with keeping a relevant stone cost for other civilizations, it really helps since you can use the initial resources you wouldn't be able to use otherwise.
Thu, Jun 18
Wed, Jun 17
Or a local aura that gives units or structures an additional armour level, making them harder to destroy?
Or a local aura that reduces the armour of enemy units by one level, making them easier to kill?
Tue, Jun 16
How about a local aura that makes structures harder to capture?
Sun, Jun 14
Sounds like a good idea. I'm hesitating between 10% or 15%, other opinions welcomed.
IIRC, @ValihrAnt disliked the idea of keeping a high metal cost due to map imbalances.
Not sure if related to the scope of this change, but it would also be good to be able to bind keys that (I, currently) are not able to, for example Tab and CapsLock. What's strange is that I looked at the codebase and there are constants for handling these keys but they can't be used for hotkeys.
I agree that Caratacos (or even Maximus FWIW) bonus is not really a big of a deal.
Sat, Jun 13
There's not much to say on my end before playtesting it, contact me whenever you want to do that.
> Anyway, I can undo that change, if you think that's better, or halve the metal cost as compensation.
Actually it is: we know from ancient authors it was quite common for armies to erect palisades around their camps in enemy territory.
In general, I agree with this change.
How about keeping the stone at 300, but reducing the wood cost to 200 or 150?
About the pyramid cost change, I'd like to see it reduced a bit, currently kushites are deemed the most underpowered civilization by the majority of players.
I like that it has a considerable cost, in both wood and metal, also that it may help transition from a fanatic rush to farms, since you are gathering mostly wood and metal at that stage.
I agree with this change
Fri, Jun 12
Well, some animals would make sense to be hunted, e.g. bears. Most do not make sense though, and I think the experience loot is a minimal incentive that although not sufficient for the irritation on having to kill those at least works and makes more sense.
Since wood cost has been reduced for wood barracks civilizations maybe we could make it 100w 150s for the stone barracks civs? Otherwise I think we're nerfing the stone barracks civilizations, except for those that can make slingers in p1, since you won't feasibly use those resources in p1.
Thu, Jun 11
I also like the spear cav damage increase, currently javelin cavalry can outmicro spear cav without a significant advantage in numbers (which many expect to favor the spear cavalry).
Sun, Jun 7
May 9 2020
May 8 2020
For smoothly changing tree density dependent on distance to area and/or height I suggest to use a painter rather than a constraint ;)
This constraint is not deterministic since the random number is rolled in .allows.
That means if you use this to paint trees on an area and do this over and over again you will get increasing densities though that was nowhere specified by the user.
May 3 2020
Well, the question is, do we have intention to have these implemented? If yes then I'm fine with this change, otherwise we should remove all the unimplemented stuff we have in-game right now.
We could. current plan was to add a keybinding so you can click anywhere on the minimap or map to do the ping.
May 2 2020
This is great! Can we add a keybinding to ping on the center of the current camera view?
May 1 2020
So speaking about creating lots of vectors causing perf impact, those could also become the same temporary vector and use the set method to change the coordinates.
Style fixes for tests
Style fixes for tests
Style fixes for tests
Is that correct? The map has |mapSize| tiles which makes |mapSize+1| vertices on the heightgrid.
The values returned by a Placer should be locations of tiles I think and then if a Painter like the HeightPainters operate on vertices of tiles, its their responsibility to work on all four vertices of the given tile.
So actually seems correct then to go from 0 to N-1 making up for N tiles.
Apr 30 2020
One thing to notice though, is that as the game currently stands, units can perfectly estimate the position of their target, i.e. perfect "ballistics".
One thing to notice though, is that as the game currently stands, units can perfectly estimate the position of their target, i.e. perfect "ballistics". This patch introduces an option to change that behaviour from the templates.
Apr 29 2020
I like the idea of ballistics inclusion, one issue I find often is that chasing units with ranged units (e.g. skirm cav against archer cav) is very inefficient while it shouldn't in terms of gameplay.
Well I guess best way to test there are no errors is to add unit tests for those cases and fix the code :)
Remove redundant initializer
Properly handle map edge
I performed some tests on gear normal for 8 players, times are in seconds and retrieved from the map logger:
Handle floating radius properly for DiskPlacer
Ok, I performed the style fixes, I'll make some profiling and testing and we should be good to land.
Apr 28 2020
Removed the map boundaries condition, this is in effect already for the actual map grid boundaries. For circular maps we allow points outside the map range but inside the map grid boundaries
As an additional remark, I suspect RandomMap.inMapBounds needs to be refactored to exclude points outside map disk range when map is circular.
I am not sure why the build has failed, it says there was a segmentation fault in the compiler?
Style changes to DiskPlacer tests
Constrain point iterator inside map boundaries
I am not sure I'd like to add the iterator helper to the scope of this changeset, I refactored the code to be similar to what you shared though.
Add tests for DiskPlacer, refactor iterator
Apr 27 2020
Add to credits
@Angen Did it work?
Include file context
Apr 26 2020
We only allocate now when cloning the point to fill the area. Also check map boundaries with RandomMap.validTile
Check map boundaries and clone the vector properly
Avoid allocating on every tile scan
I am not sure about this change, balancing heroes is a hard task: other factors are as or more relevant than health, e.g. walk speed: in regicide having a cavalry hero is much easier to protect, cavalry heroes can be used to harass unsuspecting farmlands and escape easily, etc...
Apr 16 2020
If the win condition is to kill all units and structures, this looks like a worthy improvement to avoid foundation placement abuse (e.g. a player with a lot of wood can place outpost foundations and delay his defeat considerably), with a safe worker (e.g. with hill abuse) can delay much by cancelling an outpost while having another and placing somewhere else and so on.
Mar 26 2020
Feb 24 2020
If its easier, one could also just upload replays and perhaps a link to the mod.
Feb 2 2020
Again doesnt state whether that were 2 1v1s or 8 4v4s.