User Details
- User Since
- Apr 14 2021, 11:46 AM (101 w, 4 d)
Fri, Mar 24
Thu, Mar 23
Wed, Mar 22
I will probably redo this in a way which couples the resource supply with the health, instead of spawning the resource on death. Otherwise you would be able to burn down a forest with D4973 and still be able to collect the wood, which makes no sense.
get it out of the queue since it's WIP
Sun, Mar 19
Sat, Mar 18
I just tested this again I I can still say that I don't see *huge* problems emerging with these values. Units tend to push each other away from resources a bit more, but the normally find a better position quickly, so no endless loops.
This could be further reduced by increasing <MinimalForce>0.3</MinimalForce> up to <MinimalForce>0.35</MinimalForce> or even higher.
Wed, Mar 15
Mon, Mar 13
I tested the unit_pushing demo and I think it looks better. Only when building units took a bit longer to find a good position - but no endless loop as far as I could see.
point taken
Does this make sense gameplay wise? I occasionally do help my allies got build a forward cc for example.
Sun, Mar 12
up
Sat, Mar 11
Could you describe a bit more how specifically it's useful?
sooo ... any more opinions on this?
update heavy warship.
half the current modifier.
Adjust tootip to be very vague
works on windows as well. no more black spots.
Mon, Mar 6
Sun, Mar 5
How about we go for <BatchTimeModifier op="mul">0.8</BatchTimeModifier> / slightly worse then half the current effect
Sat, Mar 4
sure might also be enough. I basically want to hear more input on this and just picked the removal as a discussion starter.
Sat, Feb 25
Fri, Feb 24
Paraphrased comments from elexis:
There are two problem with the design of this path:
- biome is a setting / component of random maps - this this patch intermingles the rm component with actor changes that are also present on other maps, which is not great.
- The patch uses the filenames of biomes to decide when to switch the actors/ textures - this is very bad from a mod perspective. E.g. if you want to make your own random map that uses a custom "winter" -like biome you can't easily use this feature. You would have to copy and change all the actors as well, which is major work.
Conclusion: Better to make this a clearly separated component/ mapsetting e.g. mapActorVariant that just matches a generic string instead of a filename. e.g. winter or winterVariant. Then a modder can just use that string in the map setting to get the benefits and doesn't have to copy + change all actors.
Other thought from me:
Are there any other potential variants besides winter?
Feb 20 2023
update:
- betterize the iber wall check: actually pass the positions of the other player and calculate if there is enough space
- very soft deprecate the rmgen2 base placement.
more comments
Feb 19 2023
I forgot to mention the change from sortAllPlayers() to getPlayerIDs() IDs in some places.
see D4946 for the reasoning.
the cleanup in D4670 may still be done in the future
Feb 14 2023
Jan 25 2023
Should I test it ?
Jan 9 2023
Dec 2 2022
general opinion seems to favor D4697
still think this is a fun idea, but probably better if done in a mod
need a better implementation from someone who knows more of UnitAI
abandon for now
Oct 25 2022
teasmPosition[i] leads to map generation failure, since you removed the for loop.
I think it could be solved by the inlines, but maybe you have a better idea?
Oct 24 2022
Oct 19 2022
I still very much like to include this (and last time I tried the map it looked great).
Oct 16 2022
something like this should fix the wrong assignment
I generally think it is good to move the function (and rewrite it/ I like the new pattern) but it fails at some points it seems.
Oct 14 2022
Just for my personal knowledge: Is there a correct place to store non gui civ data? Or why is civ.json only for the gui?
Oct 13 2022
the last drafts in the forum look good (with columns sorted by function), but that would require much more work.
Oct 11 2022
Looks good and cleaner as the version before. Only thing is that this is now civ-specific data that is not stored alongside the other civ-specific data, but rather in the naming convention.
On the other hand the civ data is already not stored in one place. Not sure if @Freagarach has a strong opinion on what the right place to store such information would be.
As everyone here seems to like this change: I will look at this again in the next time and see if it is a good idea to commit it as it is now (or if it needs more work)
Oct 5 2022
now that we have rP27122 (which do look really good btw!)
@wowgetoffyourcellphone should we revisit this idea but with civ specific designs?
Or do you want to commit the designs you made?
Sep 28 2022
alright, build looks better now.
- reminder to myself: delete the approach variants on commit
fix the tooltips
Sep 27 2022
checkrefs
Sep 1 2022
Aug 31 2022
Aug 29 2022
I would say it is a precursor to that
Aug 22 2022
yes and no. It does not help when you one shot a unit, but from what I've seen it looks a bit better when two larger groups of units fight against each other (as UnitAI normally also tends to target the same unit) or when you attack/ capture a building.
Aug 21 2022
problem: changing the prepare time leads to bad animation glitches.
The only way to get nice looking animations (without changing the c++ part) is adding the delay to the repeat time, as there the animation is correctly adjusted to the time.
This means that the units would attack at the same time at first, but then slowly get out of clock (until they find a new target).
idea seems good, just doesn't work like this
yeah, as the description says, it's an old patch and WIP.
Just wanted to get opinions if that (trees heaving health an using the sinking animation) is something worth to pursue.