Upload save so @Thunderbrd can fix them.With Revision 10688 or 10689 the promotions that give double movement in forest/hill plots don't work anymore.
Upload save so @Thunderbrd can fix them.With Revision 10688 or 10689 the promotions that give double movement in forest/hill plots don't work anymore.
@ThunderbrdWith Revision 10688 or 10689 the promotions that give double movement in forest/hill plots don't work anymore.
Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.When my Drone Helicopter passed 2000 in strength it startet to count down when more XP was added. Now it is -1988.36 and is unusable until I give it another 2000XP to get back to zero i guess. Does this apply to all units?
Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen?Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.
That is you managed to cause overflow.
Either advanced start or calendar calibration sent calendar way out of whack.Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen?
Don't you want to know how come it's 10902AD? Advanced Start, or is there a 'natural' way that can happen?
@futar :
XP only gives strength x20 by Quality Ups. So how many of those have you taken, and is there no maximum (I did note the 1700HP which implies 7. That seems like too many, but I'm not familiar enough with Size Matters to be sure of that)?
How many XP has the unit received all up (more than 264 obviously, but then Quality Ups reset XP to 0)? And how did it get that many?
By "started to count down" you must mean it changed to -2000 and started to count up/down back towards zero (that's what overflows do). I just thought that needed clarification.
It appears you have mucked around and broken the mod (slightly). If you try hard enough you can do that. I'm pretty sure there's no way to stop you. I find it more fun not to try so hard.
This is just illusion - its just you being too slow compared to calendar progression on Ultrafast.It is played at fastest speed (really a test game). And with only military victory as winning condition. At this gamespeed the games advances slower relative to the year, I was in iron age at around 2019.
Which is the main way I fixed the problem in the sea travel. This is some tricky stuff trying to rig the math to work a touch differently between these two cases. I'll have to evaluate the move cost of hills and forests to see exactly how everything is adding up. This might be an XML fix at this point.
Not an XP overflow but a stack overflow on strength in general which has numerous decimal adjustments to get to the final calculation, which itself is a float. This is kinda a known lategame problem that can happen on SM that I knew about but didn't have to address until recently because games could never go this far before. I can't promise a quick fix on this.Yes, as programmers didn't thought, that someone may accumulate this much XP on single unit.
That is you managed to cause overflow.
Are you sure you are not using low graphic settings/no unit animations, and thus not seeing reskins properly?herd of horses have the wrong nif. . .
also the Nea Wanderer and Brute
more" rows 1-4 have wrong nif's also etc etc......
I've been playing all day and haven't seen a single error like SO is reporting here.Are you sure you are not using low graphic settings/no unit animations, and thus not seeing reskins properly?
Ok, I figured out what was wrong and a trick that should work for all situations.Which is the main way I fixed the problem in the sea travel. This is some tricky stuff trying to rig the math to work a touch differently between these two cases. I'll have to evaluate the move cost of hills and forests to see exactly how everything is adding up. This might be an XML fix at this point.
Ok, I figured out what was wrong and a trick that should work for all situations.
Here's the thing... the original vanilla method of establishing the move cost for a plot was to make a plot have a move cost of EITHER the XML established cost of the terrain (if there is no feature) OR the feature (including hills overriding forests). Therefore, when it came to double move, it would reduce the movement cost to half, which would be less than a full 1 cost.The whole thing seems like a terrible hack. After the change to make the movement costs additive the double moves tags should have been changed into something like ignores feature and ignores terrain movement costs tags.
What is the issue you are trying to solve with making it possible for the movement costs to be higher as the number of moves a unit has? Why not make it impossible for some units to move through instead.
Are you sure you are not using low graphic settings/no unit animations, and thus not seeing reskins properly?
yeppers checked it by mistake, thx. . . DUH!!!!I've been playing all day and haven't seen a single error like SO is reporting here.
Check your graphics options SO, make sure you don't have "animations frozen" option checked.
There is a lot of typos to fix.Minor Text syntax in the Tipps Section , when loading a save.
It's an interesting proposition, I've seen it be done in plot based games before and it added an interesting layer to that game.Why not make it impossible for some units to move through instead.
This issue came up again because youHere's the thing... the original vanilla method of establishing the move cost for a plot was to make a plot have a move cost of EITHER the XML established cost of the terrain (if there is no feature) OR the feature (including hills overriding forests). Therefore, when it came to double move, it would reduce the movement cost to half, which would be less than a full 1 cost.
Note: In Vanilla a hill or forest cost something like 1.5 movement points rather than a full 2, which is why when it was halved it would allow an extra movement for a 1 movement point unit.
Therefore a warrior with 1 movement would move 2 spaces if their first move was into a forest because they would have leftover movement points (a float value at this point) after the first plot was moved into. That would work on a hill too as long as there was a forest. And if he had double move on hills, it would work whether the hill had a forest or not. Otherwise it pretty much works like you might expect.
However, what I just had was a lot like what you just suggested and I was thinking that would work, except that since the terrain and feature is additive to get a final cost now, it would mean that the unit would need BOTH the double move on the feature AND the terrain to get the ability to move an extra space beyond like it was in vanilla. This way matches
the original math much more closely and it works in all situations I considered would need checking.
This way, moving onto a plot with a feature you have double move would thus assume that you have double move for the terrain portion of the assigned movement cost of that plot as well as for the feature's portion of the movement cost and thus 1/2(for the feature half of the overall plot equation) of 1/2(for the terrain half of the overall plot equation) = 1/4 the move cost for that plot, rather than just 1/2. Thus, this is much closer to vanilla behavior if you have additive terrain and feature costs to determine move costs for a plot. I realized I was failing to take into account the second half of the equation, the terrain half, which was overridden completely in Vanilla instead.
As you can see, if we don't get this working close to Vanilla on this, many players do complain that it is a bug, including my wife who is very attached to this working as it did. Even the complaint today was that it was behaving exactly as you said it should in your post.