Only if you also remove subdued animals. Not joking.
It seems to me that it scales in the opposite direction... or that it really shouldn't scale at all given that more time to hunt means you get more animals to work with. We've normalized the spawning rates somewhat so that it's not completely overwhelming and lethal to hunters trying to pack the wild with as many spawns as you'd see over a long game on a short game. I know that the cost to achieve thresholds are scaled, but with the added animals you get on a longer game, it seems already naturally scaled.
I do Not want subdued animals removed! That would be a Major step backwards for the Mod.
Um yeah. That's definitely never going to happen. As someone said once, this game is almost more about the animals than anything else.
If animal density falls with increasing game speeds, then it should roughly balance while individual animals would be worth more.
Only somewhat. It used to be severely different, more according to the actual time ratio different, but as stated, the game suffers at both extreme ends when this is done, so the scaling is also probably too extreme since you WILL get a lot more animals on a longer gamespeed. Hunters certainly get more powerful while they still matter on longer gamespeeds since they have more time to collect XP.
The problem reported was "I can't move my subdued animal". Reason was "because subdued animals can't reveal the map", your solution was to remove the bNoReveal from all subdued animals. If the problem was "I can't move my Archer", reason "because it is on a one plot island" your response would have been to remove all water terrains! The bug in this case was how did the unit get into such a situation in the first place. The solution is to get an escorting unit there to reveal the map in the normal way. Removing the bNoReveal means that you can set your subdued animals to explore because of a bug in the attack mechanism that means even on RuthlessAI etc
Oh... yeah that's definitely wrong. I mean it's annoying that they can't do it when they are part of a group that can, and maybe a solution in the code could be made for that but just removing that bool in the XML is just... wrong.
Also,
@Dancing Hoskuld : I have recently seen the issue you were talking about when we brought up that conversation where you were saying a unit in a stack moves onto a plot, reveals a unit there, then the rest of the units can't move in. I'm not sure how to fix that because here's what's happening:
1) The order for the stack to move is given.
2) The head unit on the stack moves first then each unit after that in a sequence according to how the selectiongroup was setup.
3) The first unit gets there and part of the move is to update visibility on that plot and the plots around it. It resolves this before the rest of the units get to move in. And for many reasons, this is exactly how it needs to be and would create unfathomable complexities in other systems if it waits until all other units in the stack are on the plot before updating visibility.
4) That first head unit that moved now legally sees a non-hostile animal or unit, an enemy unit but not one set to ambush (and that unit may not even realize you see him now). Now that the animal or whatever is revealed, since its not an ambushing unit, there's not an automatic battle - they share the space legally because it's the status they were in when the pre-existing foe unit was revealed.
5) The rest of the stack, however, is not so lucky. They have had the threatening animal or whatever unit revealed and must attack it if they are to move onto the plot their leader just moved to. Particularly if they cannot attack, this means they are unable to now move onto the plot.
6) Obviously this also means that the head unit did complete its move and probably doesn't have any movement left over to launch an attack.
Now, enabling a same tile attack from the head unit at this stage is impossible because we really don't want to get into the business of breaking the rule that if you cannot move any more you also cannot attack. So... I'm not entirely sure how this should be corrected. Vision rules have enhancements for seeing units on the same tile in many cases, so it's only once they are officially IN the plot that they legally SEE the unit and at that point they've already moved and been charged the movement.
At the least, any resolution to this effect is going to be SUPER complex. It may just be that if you want to protect against this possibility, that you might need to ensure you have a few escorts or this is a danger you face.
I'm open to suggestions, but a lot of ideas could seem like good ones here and be very bad ideas considering the VAST complexity of movement rule issues, particularly in the timing of events and how many functions can play into managing this sort of thing.