Single Player bugs and crashes v39 plus (SVN) - After the 20th of July 2019
- Thread starter Thunderbrd
- Start date
I'm getting this error:
@KaTiON_PT: you sure you rebuilt the dll from the most up to date source files?
Alberts added the getHasBuilding method to unit infos in rev 10860-62
Code:
Traceback (most recent call last):
File "BugEventManager", line 308, in _handleDefaultEvent
File "CvEventManager", line 615, in onLoadGame
File "CvEventManager", line 488, in gameStart
File "CvAdvisorUtils", line 70, in resetNoLiberateCities
AttributeError: 'CvUnitInfo' object has no attribute 'getHasBuilding'Alberts added the getHasBuilding method to unit infos in rev 10860-62
Thunderbrd
C2C War Dog
?
This on a cleanup after the commit failed with equally as many words. Anyone have a clue? This is new to me.
Not much I can do here til this is cleared up somehow.
strategyonly
C2C Supreme Commander
This might be a issue with the fpk's.
It could be that the save contains some kind of corruption from the problematic svn updates. Even if the game doesn't crash there could be some kind of memory corruption beeing caused by bad pointers. This could also happen in python because @Toffer90 fixed my crash problems by fixing python errors.
Indeed, they are found inside the RESMSG logs.
Resmgr.log and missing textures are displayed pink in game.
The Black Tiles problem comes up from time to time in all CivIV mods. Unpacking the art and starting the game without creating a fpk usally fixes it.
Thunderbrd
C2C War Dog
That was it! Thank you!
@billw2015 THIS is what happens when you have too many FPKs. I KNEW there was a reason we backed down from having so many. This is it. We must be able to work with fewer FPKs and for the plans you have, I think that means we're going to be required to stop storing FPKs on the repo at all if I'm not mistaken.
@All: I'm going to bring this up elsewhere but I think this may mean that we no longer have a choice but to implement the FPK live mechanism and do it very soon - and part of that will be that FPKs must be packed much larger than they are so we aren't exceeding the limit of how many FPKs we can have. Obviously, different systems encounter this limitation at different points. Used to be around 8 FPKs was too many for most.
If you aren't keeping up with some of the more technical discussions on the FPK live thread I get it. Let me summarize:
We would be moving to a new storage method. To make the transition would be extremely simple. It would require taking these steps:
1) Delete the mod in the mods folder (you can save your usersettings folder somewhere if you like)
2) Check out a new repository for Caveman2Cosmos somewhere else in the same drive (usually C) as you store your program files folder where BeyondTheSword/Mods is, just make sure you set it up OUTSIDE the Firaxis (best even outside Program Files) directory.
3) Run a batch file that will be clearly labeled as your install file.
That's it.
You will end up with a Caveman2Cosmos mod folder in the mods folder in BeyondTheSword.
You will not generally mod in that active mods folder. However, ANY changes you make in your external Caveman2Cosmos folder will immediately be reflected in your actual game mod folder as well (with the exception of art files and code, which will get updated IF you use the batch file to load the mod with updates, that will also be clearly provided for you in the checkout.
Then any updates and commits would be done through the external folder.
That would be ALL you would HAVE to know. Period. I don't think that's too complicated a system and it will resolve a number of issues and pave the way for more improvements in team methodology.
Is that pretty much the sum total of it as you intend it as well @billw2015 ?
I agree. I'm about to load the save on a debug run and see what I can figure out about it.
I'm not sure if the RESMGR log will catch the problem with too many FPKs - it COULD load everything fine but then have problems during the run with referencing the locations of the graphic files. Just sharing some theory here if you see some confusing results.
Just put fewer but bigger fpk's into the svn.
Thunderbrd
C2C War Dog
Yes, works on SVN... but...
Only svn matters at the moment.
The for the git repo unpacked art would be the best solution anyways.
billw2015
King
- Joined
- Jun 22, 2015
- Messages
- 837
Doing it now.
billw2015
King
- Joined
- Jun 22, 2015
- Messages
- 837
Taking *ages* to reupload the FPKs, 5/9 done so far (I doubled the size from 50MB to 100MB if it is still a problem I will double again, but I also heard there is a problem if they are too big?).
Interesting post related to content/FPKs/memory: FPKing files for faster mod loading times
Interesting post related to content/FPKs/memory: FPKing files for faster mod loading times
strategyonly
C2C Supreme Commander
yeppers black tiles r gone with newly packed FPK's. so far.. thx. . . SO
Thunderbrd
C2C War Dog
Right so that brings to the foreground this matter:
If we are going to move to Git for the mod team and for modding commits and keep SVN as a reporting tool to release to the public (those who are already hooked up to us there) our more common weekly updates and debug fixes, we still need to somehow ensure that modding isn't being committed to the SVN at that point somehow and from there SVN becomes basically output only.
How do we actually MAKE this transition. Do we just say, after such and such date, no further modding commits are going to be accepted to the SVN, only updates from the Git side will be placed into the SVN and you can get your updates from the SVN but no non-authorized commits to SVN after that hard established date?
Similar threads
- Sticky
- Sticky
