What needs fixing before we release v35
- Thread starter Dancing Hoskuld
- Start date
Dancing Hoskuld
Deity
I should probably check why the cost of settlers is 0 rather than what they should be - but that can wait to v36 as it will probably have a big effect on game play.
Dancing Hoskuld
Deity
I am going to be away from my modding computer for awhile. Not sure how long. This means I can't any more for this release.
strategyonly
C2C Supreme Commander
What needs to be done yet, everyone??
Thunderbrd
C2C War Dog
Got one more optimization to do (for you 
) and there's a couple of known bugs I can't personally solve lurking so I worry about those becoming a bigger issue if released with them. But not much I can do about it so I'll just go after the optimization issue and call it good on my end if we're there... oh... that would mean the next dll will officially be the 35 civ dll and I'll include a 50 civ dll with the next update for those who still wish to play on that.
) and there's a couple of known bugs I can't personally solve lurking so I worry about those becoming a bigger issue if released with them. But not much I can do about it so I'll just go after the optimization issue and call it good on my end if we're there... oh... that would mean the next dll will officially be the 35 civ dll and I'll include a 50 civ dll with the next update for those who still wish to play on that.
Dancing Hoskuld
Deity
If we are going to the 35 dll then the folder Sevo_FacesOfGod in my modules folder needs to be removed. Removing it breaks saves but so does moving to the new dll so lets do it all in one go. Someone else will need to do it as I am "on the road" and don't have access to the SVN from here.
Thunderbrd
C2C War Dog
I'll do it since it'll be on the same commit.
strategyonly
C2C Supreme Commander
Yeah because ALL my games are with the 50 dll right now, and i really dont want to AGAIN make a new game yet, at least for another 20-30 days or so.
@ DH given up on the Temp Boss?
Thunderbrd
C2C War Dog
I'll be taking my time before the next dll upload... I've got some more issues I've decided I want to work on - I'm thinking some more delays may exist there and with patience I may be able to disseminate some outstanding underlying bugs still. Not advocating releasing before I've delved into those so give me a bit yet.
darkedone02
The Suggestor
After playing tons of games on this mod but not hit towards the modern era at all because of how much the game lags up on me to the point where it takes minutes to load per turn. I wish for more and more performance increases and optimization and the cease of several issues that could cause performance problems, so that I can actually go though the modern era with at least 2-3 minutes per turn instead of 6+ minutes.
So far I've seen going though the updates on the svn, besides buttons and icons. they are going forth what I've just talked about, which is great. I can go though the modern era/future era in RoM:AND with 2-3 minutes, which is great so far... now I wish to see the same in this mod.
So far I've seen going though the updates on the svn, besides buttons and icons. they are going forth what I've just talked about, which is great. I can go though the modern era/future era in RoM:AND with 2-3 minutes, which is great so far... now I wish to see the same in this mod.
Tbh I am not sure why you go for a savegame breaking thing like that. It will barely reduce turn times as most of the computing intensive algorithms depend more on the square of the total number of cities or units than the number of players. And those mostly depend on the map size in late game (which is where it matters).Got one more optimization to do (for you
You will save memory, but mostly from bad storage formats or too many graphics styles.
Wouldn't it be better to keep the 50 civs but start to reserve the top 10-15 slots for special players (like you could split animals and barbarians and similar things)?
That way the savegame format would still be intact which it has now been for such a long time.
Thunderbrd
C2C War Dog
Actually I think that's a great idea except for a few things:
1) Many of us are already playing and using the 35 civ dll and I don't want to break those saves for them either (and supporting both is ... unpleasant.)
2) I'm not sure how that would work... Currently for the 50 civ dll the define set is:
Code:
#define MAX_CIV_PLAYERS (50)
/********************************************************************************/
/** REVOLUTION_MOD END */
/********************************************************************************/
#else
#define MAX_CIV_PLAYERS (cvInternalGlobals::getInstance().getMaxCivPlayers())
#endif
//TBANIMAL - the project really starts here
#define MAX_CIV_TEAMS (MAX_CIV_PLAYERS)
#define MAX_PLAYERS (MAX_CIV_PLAYERS + 1)
#define MAX_TEAMS (MAX_PLAYERS)
#define BARBARIAN_PLAYER ((PlayerTypes)MAX_CIV_PLAYERS)
#define BARBARIAN_TEAM ((TeamTypes)MAX_CIV_TEAMS)Would you agree? Or do you think I'm not seeing this quite right and you see another approach?
3) You're right though that I've been wondering if the amount of memory saved would be worthwhile. I get some MAFs on 35 civs even now and then so the whole thing about mem problems adding up over the course of the game and requiring an occasional restart that's always been taking place since Vanilla CivIV is always going to be an issue and if there's not going to be much gain from the 35 civs rather than 50 then it doesn't seem necessary at all. However, if a game actually does manage to get over 35 civs then it's going to be a nightmare in terms of processing and our UI doesn't do well with it either and a game that actually had more than 35 civs in play at once could be fairly ridiculous on even the largest map size we still support.
4) I suppose that our cutting down the number of civs and their graphics has helped in the way I was hoping to with this quite effectively already but I really don't know to what extent.
5) Honestly it strikes me that there must be some explanation why we've lost so much of our memory roof - apparently we used to be able to use a lot more memory before crashing out than we can now and I'm at a loss to understand how this took place (wondering if it might have something to do with multi-threading?) So really a better programmer taking a look into that issue would probably do a lot more than this attempt would.
Anyhow, please continue to share your thoughts as I mull this over further.
JosEPh_II
TBS WarLord
T-Brd, seriously, how much coding has your Combat Mod, Promotions, and Size Matters Options added to the Mod? They are not simple little xml files now are they? While Multi-threading probably does have an impact too, so too do these. It all adds up, my friend.
C2C has pushed the limits time and again but it's not going to be allowable forever. It's almost there now, imho, to the point of significant diminishing returns on each new addition to the mod. The civ count clean up re-opened some usable space, but that is being used up quickly in constant new coding, graphic, and xml content addition.
JosEPh
Thunderbrd
C2C War Dog
T-Brd, seriously, how much coding has your Combat Mod, Promotions, and Size Matters Options added to the Mod? They are not simple little xml files now are they? While Multi-threading probably does have an impact too, so too do these. It all adds up, my friend.
C2C has pushed the limits time and again but it's not going to be allowable forever. It's almost there now, imho, to the point of significant diminishing returns on each new addition to the mod. The civ count clean up re-opened some usable space, but that is being used up quickly in constant new coding, graphic, and xml content addition.
JosEPh
I don't think that would diminish how much ram the game can access before it causes an MAF as that's included in how much ram the game is accessing. Make sense? The question I'm having is not what's eating up ram - it's what's limiting how much ram we can use? Sure, between the two it becomes a pinch of a problem but I'm thinking that theoretically if we can figure out why our limit has reduced we may also be able to figure out how to expand it - we crash out here far before most systems would, by their hardware specs, reach any limit. And it's something I find rather mysterious and would point to as a larger problem than anything to do with the size of the content of the mod itself, both coded and stored.
JosEPh_II
TBS WarLord
Have you been following the AND discussion of Trade Routes and their impact on performance? Might be some clues there.
JosEPh
JosEPh
Thunderbrd
C2C War Dog
Link me to it if you would please.
I guess anyone not closely following the forum will have no idea that this even exists so likely most players of C2C will currently run 50 civ dll games.
This is how I think it is:
MAX_CIV_PLAYERS is supposed to be the maximum amount of normal players.
MAX_PLAYERS is supposed to be the amount of player slots needed (for data storage), which is all normal players plus the special players, currently only the barbarians so plus 1.
BARBARIAN_PLAYER is the ID of the barbarian player slot and since that is 0 based that is MAX_PLAYERS - 1, the last slot, which is currently equivalent to MAX_CIV_PLAYERS.
Unfortunately there is no guarantee that all the loops and arrays use the right define (you could check though of course).
The main reason that savegames with different numbers for MAX_CIV_PLAYERS are incompatible is that there is a large amount of reads and writes in savegames for arrays of size MAX_PLAYERS (just search for all references to MAX_PLAYERS and you will see). That is of course fixable by writing that number in the actual savegame and using that number to read the proper amount. But that is also a lot of work given the number of occurances.
More appropriate but even more work would be to make the number of players dynamic and only store information about players that are actually in the game (so less memory used if there are less players in the game and no looping all the time over non existant players).
As I wrote in my last post I don't think the number of civs active does have a large influence on the turn times compared to the number of cities (there are even some calculations which will be cheaper if the cities are split up among more players).
Nonetheless it would not be too hard to avoid spawning more by checking the few code places that actually spawn those players and make sure they don't if there are already 35 or whatever.
Why would multi-threading influence memory usage much (if at all)?
Without having more information about the exe code it is hard to say what causes the early memory limits. It might be anything from some large graphics with bad management to memory fragmentation.
There is the possibility of using an additional process for a part of the data (and processing some of it) with the disadvantage that that requires the somewhat slower interprocess communication whenever you need data from the other process (which also tends to be asynchron).
Thunderbrd
C2C War Dog
Most, yes, but I've been getting a number of the bug reports on the 35 civ dll so it's not been ignored by all.
Perhaps for now I should support both for a while until it's been settled what we should do. This next portion makes me wonder if you're not 100% spot on as to what should be done. If we can adapt the 50 civ dll and make more room for additional Non-Player civs beyond Barbarian in the process, that may be the best way to go.
And if the memory wouldn't be much benefited to cut it down as I was thinking it might from previous discussions I've been reading then I don't mind leaving the 50 civ dll as our core.
Interesting breakdown. That makes total sense and I wouldn't have thought of the 0 slot offsetting things like that but since you mention it... yeah. That would make MAX_CIV_PLAYERS the ID cap and MAX_PLAYERS the loop cap - makes perfect sense. I'm still getting used to these 'starts with 0 not 1' situations in coding at times.
That would suggest that we may be able to get away with an unchanged MAX_PLAYERS number despite changing the MAX_CIV_PLAYERS (the offset value making up for the difference) without messing up compatibility with at least the 50 civ dll version? Would take some testing to ensure that of course.
The error message that comes up when you try to load a game that's incompatible in this manner is so immediate (and shuts down the game in a heartbeat) that I would seriously wonder if we'd even have anywhere in the code that we could work with that would take place before the error check - I don't think the save even attempts to load so I'm thinking the exe makes a preload check we can't get to. I may be wrong. Mind, I'd personally have no idea where to add such a read/write into the savegame file itself either. You'd have a better idea of that I'm sure.
Now THAT would indeed be ideal in the extreme! It's mind boggling it wasn't setup like this in the first place (then including a limit perhaps but still...) Caching room for so many players that don't even exist in the game seems a terrible waste!
I'm sure it has next to nothing to do with turn times. And yeah cities and unit counts would have a lot more to do with that. But overall allocated memory? MAFs have become an increasing issue here and I was hoping this would assist to diminish those.
Yeah, I think it's more the pre-allocated memory I was looking to cut down on.
I only suggested it may as that's when we started seeing the overall maximum memory usage decline. Since I have no concept of what could be reducing the maximum memory usage I was merely suggesting a possible issue with something I equally don't know much about but could see a timing correlation in. I've no other reason to suspect the multi-threading in particular.
Interesting. At least you HAVE a few ideas as to what it could be. You're doing better than I already
Just sucks when we're, as Joe pointed out, already adding a lot of new mem usage and at the same time the maximum usage is declining somehow. Bad recipe for disaster no? There's still so much I'd like to add and this phenomenon is disturbing to those eventual goals like multi-maps etc...We may need some of that sort of thinking to achieve some of the larger long term goals if we are ever to do so.
JosEPh_II
TBS WarLord
That is possible in which case we would just have to fool the exe into thinking there are always 50 players while in reality there are less.
Similar threads
