player defeated on load game

[Lib.Spi't]

So I have just discovered this issue with my mod...

Everything works fine, but when I save a game and then load it, it gives the 'You have been defeated' message at the bottom of the screen...

What I can't figure out is why...

Can anyone think of a reason that would cause the game to do that, be absolutely fine while playing but then when a save is loaded, something tells the game that you have lost! Even though oyu have cities and units, etc. It's like it is losing the player data or something that attaches it to the civ you are playing and your civs 'assets' like cities and units...

I just can't figure out what could do this, like if a piece of info was not being saved or loaded, wouldn't that just cause a corruption and a crash to desktop...

 

[isenchine]

Well, if it's not Python it must be the dll and there it's not easy to help you. You should know what you did last that could cause the problem. A debug dll maybe?

I myself have never experienced this defeat problem outside of map/scenarios that were glitchy.

 

[Lib.Spi't]

Yeah this is the problem I have, I cannot understand how anything I have done recently could cause this issue...

If something in the dll is properly broken, then why does it only happen on a load, usually if it is something not being saved or loaded (because it is missing a save/load function in the code) then it would just crash on load...

Instead it is just saying I am defeated, yet it still shows the units/cities etc. of my faction, so it is not failing to load the items that keep you from being defeated..

I just can't fathom what kind of a code change could cause this error on a load...

If it started the game and said you are defeated I could understand that as being something broken in the code, but that fact it only happens after loading a save game... I just can't figure out what kind of specific code change or problem could cause this to happen after a load, and not all the time...and not cause the save to Crash...

 

[mourndraken]

is it an AUtosave that you are loading ?

 

[isenchine]

Which mod are you playing? FTTW or K-F.

I see in your makefile + in the file CvGameCoreDLL.vcproj... that K-Fallout is still referenced.

Just a wild guess, but could it be that K-F is trying to open a save of FTTW? EDIT: seems unlikely since I can open a saved game but am immediately stuck in an infinite "Wait for other Civs" and can't do a thing...

Edit: plus the game insists on creating a K-Fallout folder in My Documents/My Games/... (full of BUG stuff). I never installed K-F before FTTW.

Just saw this in your file CvModName.py:

modName = "K-Fallout"
displayName = "Fallout: Tame The Wastes"

changing this, I have a FTTW folder instead and it changes nothing else, the game is still stuck anyway.

 

[Archid]

The infinite wait is typically the AI grouping and then ungrouping a unit and has been reported a few times for different mods. I saw it happening to units in my Slavery mod and I am testing out some code that seems to have resolved it. I believe that Lib used the slavery mod a while ago in his mod but don't know if it is still in there.

However none of this explains the insta-lose scenario.

 

[isenchine]

Yes, but it is stange that it happens on loading a save game at a point where the game is supposed to wait for my instruction. It doesn't even let me hit the end-of-turn button.

 

[Archid]

Yes that is odd. A debug dll would probably be required to hook into CvGame::testVictory() to see what is triggering the victory. That is only called in CvGame::doTurn, which as you say shouldn't be called on loading a save. Another thing to look at would be the value of the CVGame::m_eWinner & m_eVictory variables to see if either are set to anything other than -1

 

[Lib.Spi't]

hey guys, thanks for exploring this, I am pretty ill at the minute so haven't even been able to think about it...

Yes Archid I am still using your slavery mod, the civicprereqs are still one of my favourite features

no mourn it is a regular save that it is happening on, it probably happens with autosave too, haven't looked yet.

As to the waiting for civs thing, I get that too sometimes, it also happens when I get the 'Defeated' message too.

Here are the Gamecore files
Game Core

This is the previous version of the game, and the previous version of the .dll and game core when I think everything was fine with save games. For Comparison:
Github Alpha3

I have also attached a debug .dll

 

[isenchine]

So far, I can only say it's for sure in the dll. I can load a save game when I get rid of it!

I tried also with the python folder out but a newly created save game was also corrupt.

 

[Lib.Spi't]

wait what?!?!

How can you play or load a game without a .dll?!?

So the three big changes to this verson of the .dll were:
Resource building boost

A code snippet from Nighttinggale that stops improvements 'growing' without the needed tech.

And a code snippet from Kailric that stops weak units leaving borders.

If you compare the github game core with the new game core, using something like winmerge, you should see it all pretty easily, from memory there were not a lot of changes to add.

It makes me think that I have missed a read/write function, or something.. I just feel too ill at the moment to go chasing the answer...

 

[Lib.Spi't]

Thanks for your efforts so far guys, I really appreciate it!

 

[isenchine]

No custom dll in a mod = BtS dll loaded. Since your dll does not contain very specific code for your mod, it's not a problem (apart a dozen BUG python error messages each turn!).

Your "debug" dll gives a corrupted save as well (and no message). As I said earlier in your mod's thread, I suspect it's not a debug dll because its size is the same as a normal one.

You said "It makes me think that I have missed a read/write function, or something.. ", most probably it is the case.

I'm sorry but I will be leaving soon and won't be able to do any further testing with your mod over the weekend.

 

[Lib.Spi't]

I just compiled the debug one, I think i must have misread where it put it if that is the case... Ugh..

I will look at things again when my head stops pounding quite so hard. Thanks for the help isen, always appreciated!

 

[isenchine]

Hi Lib, hope you're feeling better!

Today, I looked at the cpp files and compared them to the "Flitz" version of January.

What I found:

In CvPlayer.cpp, the three read & write about DynTraits from RifE have changed place and are now no longer in the same order with regard to the other read/write codes. I have read repeatedly that all reads and writes must follow the same order.

I will add two things, not knowing if they are important or not (I don't really read C++):

in CvInfos.cpp, line 8203:

/*m_paiTraitCounterMod(NULL)

has been commented out. Just double check it, not saying it is wrong.

in CvInfos.h, line 2102:

	int getYieldModifier(int i) const;;				// Exposed to Python

has been modified and a second ; has been added. Seems wrong to me. Might be that a previous version was corrected in January and that afterwards an older version was taken to be changed.

Hope this helps!

 

[Lib.Spi't]

That could well make sense!

Most of the dyntrait code has been 'noted out' or otherwise disabled as we were unable to get it working right. (and flitz hasn't had the time to come at it again)

So when I added in the new resource building code, I may have added a read write function to certain files that displaced the Dyntraits ones thus causing some kind of conflict.

I am still mashed with a flu bug at the minute, but this will be looked at as soon as I feel up to it.

Everything you guys do is always a help, I massively appreciate it!

I probably would not get anywhere with this stuff otherwise. I do as much as I can, but when it comes to code my brain has a definate limt!

 

[isenchine]

Lib, attached you will find a new dll + 2 files changed:

- CvInfos.h: see my previous post, minor bug correction. However, this makes me think that you made the recent changes on top of older files, not on the stable version by flitz (9 Jan)

- CvPlayer.cpp: restored the order of the saves/writes as they were on 9 Jan; Made minor adjustments because of differences with the 9 Jan version or because of warnings in the dll: look for isenchine twice in the file. I might be wrong though, I just reverted changes of DynTraits to flitz's version.

Good news: you can now load a saved game!

Bad news: BUG is not happy with your new component: every turn, you will get a python error caused by line 146 of BugData.py (def __setitem): "TypeError: list indices must be integers". It has to do with the saves, so if you did not get that error before, it must be with the new Resource Building Boost component.
Can't help you there.

Still the dll compiler throws two warnings: one for CvPlayerAI.cpp and one for CvUnitAI.cpp. I guess it should not be a surprise to you as they don't seem new. I don't know how to deal with them.

I did not try to load corrupted saves made before: the dll probably doesn't fix them, just makes new ones valids.

If I were you, I would recompile my own dll as I had some problems to make the environment build one. By the way, I also made a debug dll which has a size of 14.5 MB. re: !

 

[isenchine]

Do you remember this thread?

Here is your CvUnitAI.cpp without warning.

 

[Lib.Spi't]

hmm interesting, I remember flitz doing some work on the super forts to fix a bug we had...

Yeah I think when it comes to the debug.dll I must be looking in the wrong place for it, or I am not selecting the right thing to get a debug or something... I honestly don't know right now, I used to be able to do it easy...

problem is my brains forgets as much as it remembers so all a bit useless really!

As soon as my head is clear of this bug I will walk through all this and see if I can achieve the same ends as you

Thanks again mate, as always your efforts are genuinely appreciated!

You are certainly earning your title oh fathomer!

 

[isenchine]

It's me again!

Hot fix for BugData error: look for isenchine in BugEventManager.py (python/BUG).

Doesn't solve a thing, just stops BugData from saving what? No idea!

You know your game: test it and see what could be missing!