Nice one.As stated earlier on this page... yep! I'm proud to report that the bug we've been looking at is now resolved and was indeed more serious than I had imagined.

Nice one.As stated earlier on this page... yep! I'm proud to report that the bug we've been looking at is now resolved and was indeed more serious than I had imagined.
look at the pic i attached, i dont know if it was a stone axeman or maceman, sorry . .
1) There's no pic attached to your post.
2) The Axeman has already taken his turn in the save you provided.
dang it, it didnt make the right savedgame, sorry, BUT i got this error anyways, just now??
the pic i deleted also, dang it . .forgot to use the autosaved game, rather than the single saved game, drats
EDIT: Now i cant move the Thief, upper left side, without this error
Got to start a poker game now, so will be off for about 1/2 hour or so . . thx . .
EDIT EDIT: OK back
Got to start a poker game now, so will be off for about 1/2 hour or so . . thx . .
EDIT EDIT: OK back
The problem is that the fix to the bug Toffer and I were trying to work out can leave some units horrendously corrupted. If they can be split and remerged they can be corrected as this is a proxy unit recalc.
The problem is that the fix to the bug Toffer and I were trying to work out can leave some units horrendously corrupted. If they can be split and remerged they can be corrected as this is a proxy unit recalc.
However, there are going to be situations like this where you cannot do this because the unit needs some thousand turns to heal to be able to split again and other units that cannot be repaired because they cannot split or merge at all.
In essence, though the fix to the more serious underlying bug is extremely important... like more than any bug I've ever looked at before, it can also completely destroy some games in progress unfortunately, forcing units with wildly out of whack combat values like strength scores and so on to either be destroyed or split then merged and in some games this just isn't worth it (and for many AI units it cannot be done.)
My strongest recommendation therefore would be to suggest to all players that the v36 final dll should begin with a new game despite being capable of loading old ones. This is unfortunate but may be necessary for many games in progress.
Undoubtedly this explains how there was also a severe bug on the thief unit.
In summary, your game is pretty well f'd thanks to a debug to a serious problem and there's nothing I can do about it without a severely overengineered solution such as a massive unit recalculation mechanism.
But i NEVER ever split units?? i join units, but never split them??
bad news... I started a new game with latest SVN and spawned some units in WB, 2 without and 2 with the problematic tags; and then split one of each. I saved and loaded the save.
Now, any unit with armorVScombat & dodgeVScombat loose all unitcombats when a save is loaded. I mean all unitcombats are gone and the unit has 0 strength due to not having size, quality and group size unitcombats. This time around it doesn't matter if the unit merged/split before the save was made.
Sure thing. If we're lucky this will be the last revision before v36. Good job.Yeah, any games with size matters opened and saved yesterday on the revisions made would be completely bugged at this point.
However, new saves should be good after the dll I'm compiling now.
Toffer... if you would though, run your test again and make sure that there isn't something funny still being caused by those particular bugs. THEORETICALLY it should be cleared up entirely now because the reason those tags were causing trouble in particular was due to the order they loaded from the save. But there may be overall a problem in the way I'm working with unitcombat data and if they still cause some strangeness I'll need to know. Haven't had time to run the full test as you go about it with those tags.
Edit: it is not a display issue as a vulture defeated one of the 0units without loosing HP.
Just pointing out (as I'm sure you already know), you can defeat any relatively weak unit without losing HP. A better test (since I think one of the units is yours) is whether the 'combat' shows up in the in-game Combat Log.
A unit that has a 5 times less :strenght than its opponent should never win without loosing HP; so it is close enough to proof that the unit (in this case my wooden spearman, not the vulture) actually has 0as displayed and that it is not just a display issue. also my 0.8
wanderer defeated a 0
Neanderthal, so it probably had 0
as displayed.
Since this issue can be so harmful to save compatibility I'd like to continue looking further into what's actually causing this. I'll run some tests that should give me an indication of what's happening and it might answer some questions I have on this.@TB: Did a test, units with those two tags now retains all their unitcombat types but they still end up with 0after loading a save; all other unit stats from unitcombat are as they should be. I made a new game and a completely new save for the test.
At least it's progress.
Since the tags aren't used in the SVN this shouldn't need to delay v36 release unless you think there could be other problems with the changes you've recently made.
Edit: it is not just a display issue as a vulture defeated one of the 0units without loosing HP.
The Neanderthal had full strength, this I knew before it attacked and the vultures 0.6You're disagreeing with me for the sake of it. The vulture was not 5 times weaker than the spearman, and close enough is not good enough when genuine proof is easily available. The wanderer case likewise proves the neanderthal didn't have full strength, but it doesn't prove it didn't have any at all (eg. at 0.16![]()