Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

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.
 
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
 
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

Ok... figured out what the problem is. I actually did have the right save - must've loaded the previous one you gave me earlier today the first time.

And didn't need the pic anyhow as the instructions were clear enough.

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.
 
Got to start a poker game now, so will be off for about 1/2 hour or so . . thx . .
EDIT EDIT: OK back

Hope you won.:)

Bed time (very late :crazyeye:) now for me - will be online in about 10 hours - if I can kick the wife off.
 
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.

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.
 
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.

Ok, thanks for discovering that. It indicates that there may be a way to save this thing yet. Looking further into it.
 
OK started a NEW game and the same PROBLEM exist, something has changed for the worse??

game hasn't even 50 turns yet

go to the city and take any Wanderer and try to attack that turtle to the upper right there weird stuff happening?
 
I may have solved this... not sure though. I'll test your save.

EDIT: I will want an extra day to make sure this is sorted out properly. Very strange and complex this. I thought it had been fixed based on some preliminary tests. I'm not sure it has been and I'm out of time for further testing tonight. I go back to work tomorrow so it'll have to wait til tomorrow evening to make sure this is cleared up.

There may be something I'm not understanding about Koshling's save mechanisms here but I'll figure it out sooner or later. At least I'm focused in on the spot that's causing concern now and not struggling to figure out what THAT is.
 
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.
 
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.
Sure thing. If we're lucky this will be the last revision before v36. Good job.
 
@TB: Did a test, units with those two tags now retains all their unitcombat types but they still end up with 0 :strength: after 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 0 :strength: units without loosing HP.
 
Edit: it is not a display issue as a vulture defeated one of the 0 :strength: units 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.
 
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 0:strength: as displayed and that it is not just a display issue. also my 0.8 :strength: wanderer defeated a (edit: fully healed 0 strength) Neanderthal, so it probably had 0:strength: as displayed.
 
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 0:strength: as displayed and that it is not just a display issue. also my 0.8 :strength: wanderer defeated a 0:strength: Neanderthal, so it probably had 0:strength: as displayed.

You'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:strength: it is still five times weaker than the wanderer). In all cases the absence of these encounters from the Combat Log is the conclusive proof, easily available, that you need and don't have.

It's so easy, I bet you've already checked it...
 
@TB: Did a test, units with those two tags now retains all their unitcombat types but they still end up with 0 :strength: after 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 0 :strength: units without loosing HP.
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.

I can already see some potential ways to fix it but without a deeper understanding of why it's happening, I cannot be sure such a fix won't screw up something else. So yeah, it probably is important to resolve.
 
You'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:strength:
The Neanderthal had full strength, this I knew before it attacked and the vultures 0.6 :strength: (probably different from the SVN) is exactly 5 times less than 3 :strength:
 
BUGS and SUCKS:

1. Carpenters Workshop hover over has wrong calculation or building is buged, tells me in hover over +10% production/hammer but displays acutal +2 production/hammer, in city i have +51 base production, 10% = +5,1 production not +2 production. I will see in 8 turns if it gives +10% production as displayed and so +5,1 production or only +2 so hover over display is bugged or the building calculates wrong.

Edit: Ok Carpenters Workshop building works, got +10% production form buildings, hover over is bugged then telling +2 actual. 3. Screenshot is ok dont wonder of 47 base production, my golden age timed out looks ok.

Also after production overflow (After you build a building same turn) hover over is displaying buildings to give +2 productions when they just give +1 (Look Actual display), dont know if you can fix that.

2. Maybe change: Building Flint Quarry needs obsidian in city vincity and stone in city vincity should better be obsidian in city vincity and requires stone empire wide resource, dont needed to have stone in city vincity and only very few citys will have both in city vincity. They can bring the needed stone to the city and it will be worked with the obsidian.

3. Pushing tourism back to classical sucks, there are wonders in prehistoric era that will expire with sedenary lifestyle that give you tourism, its fun to build these as first civ, you cant make mutch gold from it only a bit and its crime rising and problems making, hard to get a bit profit from it, with the early civic is -60% gold and you can make only 2-4 gold from it because you need more anti crime buildings that have high maintenance cost. That should be changed back as it was. Worked good, making more interesting gameplay.

4. Also after the gold calculation bug is fixed dont touch the gold production to mutch, that will help the AI alot to survive and play better. Player that want a harder time can game on Deity.

Edit:
Same acutal hover over bug here in slave display, looks like it counts always +1 to mutch telling actual +3 when it should be +2 here... screenshot 4

5. My Rogue is doing pretty well capturing montezumas scouts and trackers and enslaving them, is ok for me but pedia is telling unit cant capture enemy cities or units, so change the unit or the pedia. Maybe problem from the special promotions figth and flight? Or because these special promotions to the unit giving them alot of capture ability. Screenshot 5

6. Still no wildboars spawning in north america from pig resource.
 

Attachments

  • Civ4ScreenShot0038.JPG
    Civ4ScreenShot0038.JPG
    278.1 KB · Views: 36
  • Civ4ScreenShot0039.JPG
    Civ4ScreenShot0039.JPG
    273.2 KB · Views: 42
  • Civ4ScreenShot0041.JPG
    Civ4ScreenShot0041.JPG
    271.9 KB · Views: 49
  • Civ4ScreenShot0042.JPG
    Civ4ScreenShot0042.JPG
    353.4 KB · Views: 50
  • Civ4ScreenShot0043.JPG
    Civ4ScreenShot0043.JPG
    365.8 KB · Views: 57
Back
Top Bottom