Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

[Toffer90]

The current calendar system is designed that way though, the calendar that so many (if I recall correctly: lsd612, Joseph, you and raxo) have so painstakingly tweaked so that it more or less conforms to the eras a player is in.

Yes, but the current callendar mechanic progress the same way for a gamespeed every time you play, so there is nothing stopping a player from getting ahead or behind times which makes it alternate history, and that is how C2C should be and is also the argument I use for removing the calendar all togheter as people complain about it not being "correct enough" when it is not supposed to be "correct enough" throughout an entire game in 99.99% of the games you play.

That was a long sentence with plenty of grammatical comma and punctuation errors.... ^^

 

[KaTiON_PT]

Heh, you've changed my mind about the calendar. Thanks.

 

[Yudishtira]

As I said before it would be very hard to reduce use of month and day step usages.

It is not at all hard because "deviating from calculated turn count per era" is in fact desirable if anything and not a huge taboo to be avoided by introducing bugs.

 

[Toffer90]

@raxo2222: It is undesirable to let the dates show months before at least the year 1700 AD.

You may want to revert to the last calendar setup you made that used whole year increments in the early game.​

 

[Yudishtira]

@raxo2222: It is undesirable to let the dates show months before at least the year 1700 AD.

You may want to revert to the last calendar setup you made that used whole year increments in the early game.​

99% agree but my ten cents on this is dates should not show months before there are more than 4 turns per year. 4 turns per year can be represented by seasons. Then they should not show days before there can be more than one turn in a month. (And I would really appreciate it if they could never show February 30th...)

Ok now I realise that this is also the latest possible point to change, ie. that months/days become unavoidable/vital at these points. If the vagaries of the engine mean they have to be introduced slightly earlier, that will have to do, as later is not an option.

 

[Thunderbrd]

@raxo2222: It is undesirable to let the dates show months before at least the year 1700 AD.

You may want to revert to the last calendar setup you made that used whole year increments in the early game.​

I agree with this but vehemently disagree that it's not wonderful to have the dates as a guide to how well your progress is going in the game compared to at least some kind of competitive average of markers. Even though it may be something you have to figure out how to offset for the differences in your particular options.

@raxo2222: Is it really that hard to round things off for a while? Even if the dating system is made a touch off between different gamespeeds for doing so, it's gotta be better than introducing months and days before it's necessary to. There's a 'close enough' factor in this kind of thing!

 

[raxo2222]

@raxo2222: It is undesirable to let the dates show months before at least the year 1700 AD.

You may want to revert to the last calendar setup you made that used whole year increments in the early game.​

99% agree but my ten cents on this is dates should not show months before there are more than 4 turns per year. 4 turns per year can be represented by seasons. Then they should not show days before there can be more than one turn in a month. (And I would really appreciate it if they could never show February 30th...)

Ok now I realise that this is also the latest possible point to change, ie. that months/days become unavoidable/vital at these points. If the vagaries of the engine mean they have to be introduced slightly earlier, that will have to do, as later is not an option.

I agree with this but vehemently disagree that it's not wonderful to have the dates as a guide to how well your progress is going in the game compared to at least some kind of competitive average of markers. Even though it may be something you have to figure out how to offset for the differences in your particular options.

@raxo2222: Is it really that hard to round things off for a while? Even if the dating system is made a touch off between different gamespeeds for doing so, it's gotta be better than introducing months and days before it's necessary to. There's a 'close enough' factor in this kind of thing!

Well you saw multiple times, that I was going to use month and day integers extensively, and you were fine with it.
I even shared excel file with calendar setup multiple times.

Can't we just hide days and months, if current increment is larger than 12 months (360 days) and days if increment is longer than 30 days?

I don't know how to effectively make substeps in such way, that it delays use of month and day increments.

Also instead of 14 steps you would have like 100 steps in calendar

 

[Thunderbrd]

Well you saw multiple times, that I was going to use month and day integers extensively, and you were fine with it.
I even shared excel file with calendar setup multiple times.

If I recall, I did say there was probably a reason not to do that but that I couldn't remember quite why at the time. Now that it's showing itself why, I'm reminded why I advised against doing this.

It'd be super annoying if it's not.

Can't we just hide days and months, if current increment is larger than 12 months and days if increment is longer than 30 days?

There are deeper problems than just the display apparently - there are other places dates are displayed on the record for certain events and how those are being expressed. See complaints above that led to this discussion. Furthermore, how do you determine that increments are larger than x whatever without extensive coding to determine that and then store that determination with as little memory cost as possible? Is it really worth spending finite memory on that? I'm not saying it's that significant an amount of memory, mind you, but it's still another thing to track and record for the sake of the code making that determination. This is also an elegant and complex section of coding to make it behave as it does to selectively display the dates in the manner they do and I'm a little reluctant to introduce bug potential there. I might be persuaded on this point perhaps.

If we were to do anything coded with this, I might suggest that we create an automatic enforcement of rounding to the nearest divisor of 12 until a stated era is entered (on a game-wide level rather than by player). Even that is actually complicated as hell... the whole clock system is. Which is why the rule has always been to do things in 12 month/30 day increments until you get to where the game is taking less time per turn than either a year (in the case of months (12)) or even faster than a month(30)).

So the trick has always been to find the most accurate # of months that you have derived from your original formula (if we're using months) and divide it by 12, then round that to the nearest integer, then multiply that integer by 12 and use that amount. If you're using days, divide by 30, then round that to the nearest whole integer, then divide by 12, then round that to the nearest whole integer, then take that amount and multiply it by 30 and use that #. All this CAN go out the window once you are using turn time increments that are less than a year or month.

Basically if I were to try to use a coded solution I would enforce that the code do this on load - however, I'm not sure this is wise... not saying it isn't... just saying I'm not sure because I'm not sure if it could run into some problems. It's not commonly good practice to have your loading code correct messy XML for the sake of the sanity of the XML modder but it could be done I suppose... maybe. I'm not sure we'd be able to say that for all gamespeeds the era that this transition should take place to enhanced resolution of time tracking would be at the same point and that would then mean that the era would have to be defined in the gamespeed infos and then that would mean that it would be on game initialization that we'd have to take some time to re-establish the proper math on this stuff, rather than at mod load. Either way you're adding time to the process of game loading and initialization or mod loading. Probably not toooo noticeable but completely avoidable by taking these steps when setting up the xml.

Your foundational formula is great - it works to get the most accuracy possible. It ends up being a brilliant perfect first step. But considering that so many options and playstyles can then greatly vary results, losing that 'absolute accuracy' you've striven for to take another step to round things off is not really that much of a loss of accuracy. The time consuming part is then that these additional steps need to be taken for each increment of each gamespeed. Looking at that expense of modding time, I can't blame you for pushing back on this. But remember... I did warn this would end up super annoying. I'm sorry I couldn't remember why enough to elucidate on that at the time.


Of course, I'm reviewing this further and seeing that it would end us up with non-rounded total turn counts. Yeah, let me tell ya, when I did this a long time ago, trying to have rounded off dates to the nearest 12 AND get rounded off final turn counts was a maddening project which was why I said I'd never do it again once it was done and some damn fool came along and adjusted them again later for whatever mysterious reason... ls612 I think it was. I think there WAS a flaw in my design somewhere but if I recall it was pretty accurate at the time and I think the problem was it just drifted off accuracy as the tech tree expanded. The team reworked it when I stepped away for about a year or so early in the design process of the mod.

I dunno... I'll consider looking into your suggestion as well.

EDIT:
@Toffer90 It looks like that trick would be entirely in python. The dll appears to only manage the numerics of dates. I don't think I can pull that off from here. And my suggestion above is also wrapped up in enormously confusing coding to the point that I don't think I could pull it off either... I'm thinking I'd break this thing if I tried. Maybe we do need an option to not display the dates or the month/days that is simply in control of the player. I don't know what we could do about how the dates are saved for various events though.

 

[Thunderbrd]

That must be it, but something's not right, since I can't remember a bird withdrawing from a ship, whereas they have from my much more specialized hunters/rangers on land.

Looked into this. I still can't find anywhere that explains it. Mind you, perhaps the ships are working with more first strikes for some reason. You can't withdraw from those if you die before they are finished. You also cannot get pursuit on birds if you're working with SM and ForF, or any Flies to Move unit. If you can't pursue, your skill is completely meaningless to whether they withdraw or not (at that point it's all on their withdraw capability and check alone, though your strength may get them to the point of withdrawing faster.)

But there's nothing that would explain boats in particular having any unusual benefit that land hunters might not. Not that I could see. There still COULD be. I just can't find it after reviewing all theories I could think of. Sometimes a perfect save scenario can illuminate a problem I keep overlooking.

Yes I lost two Bandit Riders to barbs when I wasn't given any odds beforehand.

I'd definitely need a save with instructions that shows/replicates a Ruffian fighting a Barbarian. I'd love to see this so I can debug it.

 

[KaTiON_PT]

The BUG menu allows you to hide the calendar @Thunderbrd

 

[Thunderbrd]

The BUG menu allows you to hide the calendar @Thunderbrd

Well... there's that then. Maybe we should consider it a non issue and just bring this up instead. It really is a lot of priorities we must try to juggle with this thing.

 

[raxo2222]

Well... there's that then. Maybe we should consider it a non issue and just bring this up instead. It really is a lot of priorities we must try to juggle with this thing.

Yep, I preferred to use a lot of noninteger year increments and day increments, so certain constant tech rate pace means you keep hitting new eras near date target without use of multiple substeps per era (Prehistoric era has two substeps to).
That is calendar is tied to effective tech count in eras.

I think Josephs calendar was doing it differently: Turn count wasn't round and most likely you had to be faster and sometimes slower in researching techs to meet date targets on new era.
Also modifiers, that were adding to each other weren't helping too - balancing one thing meant automatic unbalancing of other thing.

 

[Toffer90]

I even shared excel file with calendar setup multiple times.

Never looked at it, sorry.

EDIT:
@Toffer90 It looks like that trick would be entirely in python. The dll appears to only manage the numerics of dates. I don't think I can pull that off from here. And my suggestion above is also wrapped up in enormously confusing coding to the point that I don't think I could pull it off either... I'm thinking I'd break this thing if I tried. Maybe we do need an option to not display the dates or the month/days that is simply in control of the player. I don't know what we could do about how the dates are saved for various events though.

Python has no idea what the turn increment is at any given time... It only receives the date string from the dll by calling "CyGameTextMgr().getInterfaceTimeStr(iPlayer)"
Then python displays that string in the top right corner of the screen...

I could try setting something up in python.

 

[JosEPh_II]

Yep, I preferred to use a lot of noninteger year increments and day increments, so certain constant tech rate pace means you keep hitting new eras near date target without use of multiple substeps per era (Prehistoric era has two substeps to).
That is calendar is tied to effective tech count in eras.

I think Josephs calendar was doing it differently: Turn count wasn't round and most likely you had to be faster and sometimes slower in researching techs to meet date targets on new era.
Also modifiers, that were adding to each other weren't helping too - balancing one thing meant automatic unbalancing of other thing.

I was just one of these "and some damn fool came along and adjusted them again" modders like ls612 (Who I thought did a lot of good fixing many bad parts of the mod, when it was desperately needed).

We all know I see things differently. And I'm just an old hack modder, with no elegance, no nice tidy formula to pick over, who flew by the seat of "trial and error" pants. And just played tons of hours in the game in different and shorter overall GS to get a "feel" for progression of time back then for every GS and every Era (less Eras too, and now too many imhpo). But none of this matters anymore now does it. Old muddy water swept downstream by the flood.

But Toffer is right about using months too early. Even his suggestion of 1700 AD may be a bit early, more like 1900 AD, (Well for my preferred GSs that is anyway). Probably doesn't work too well with these hyper long GS in the Mod now.

Have Fun Raxxo, Have Fun while you still can.

 

[Toffer90]

I could, in the relevant python code, change this part:

                szTimeText += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

to something like this:

                iYear = GAME.getGameTurnYear()
                if iYear < 1800:
                    CyPlayer = self.CyPlayerAct
                    if CyPlayer.isGoldenAge():
                        szTxt += unichr(8866) + " %d - " % CyPlayer.getGoldenAgeTurns()
                    if iYear < 0:
                        szTxt += "%d BC" %(-iYear)
                    else:
                        szTxt += "%d AD" % iYear
                else:
                    szTxt += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

Edit: {
On second thought, I want to change it so that month and day are never displayed throughout the game, only the year.
It is more performance friendly and it's ridiculous to designate a day and month to a specific game turn in a game like this.

Would this be acceptable?
If it is not acceptable then I will only change it so that months and days are not displayed before the year 1800 AD.
}

 

[raxo2222]

I could, in the relevant python code, change this part:

                szTimeText += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

to something like this:

                iYear = GAME.getGameTurnYear()
                if iYear < 1800:
                    CyPlayer = self.CyPlayerAct
                    if CyPlayer.isGoldenAge():
                        szTxt += unichr(8866) + " %d - " % CyPlayer.getGoldenAgeTurns()
                    if iYear < 0:
                        szTxt += "%d BC" %(-iYear)
                    else:
                        szTxt += "%d AD" % iYear
                else:
                    szTxt += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

Edit: {
On second thought, I want to change it so that month and day are never displayed throughout the game, only the year.
It is more performance friendly and it's ridiculous to designate a day and month to a specific game turn in a game like this.

Would this be acceptable?
If it is not acceptable then I will only change it so that months and days are not displayed before the year 1800 AD.
}

Smallest increments I used were 10 - 15 days for longest speeds.
So here same year would be displayed for 30 turns

That is you can make it never display day, but month should be displayed for increments smaller than 12 months.
Also for Transhuman/Galactic and later eras increment gets bigger.

 

[Toffer90]

Smallest increments I used were 10 - 15 days for longest speeds.
So here same year would be displayed for 30 turns

Having 30 turns within one year makes more sense than having 30 turns represent 30 specific days within a year and then the year is over.

 

[Thunderbrd]

I could, in the relevant python code, change this part:

                szTimeText += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

to something like this:

                iYear = GAME.getGameTurnYear()
                if iYear < 1800:
                    CyPlayer = self.CyPlayerAct
                    if CyPlayer.isGoldenAge():
                        szTxt += unichr(8866) + " %d - " % CyPlayer.getGoldenAgeTurns()
                    if iYear < 0:
                        szTxt += "%d BC" %(-iYear)
                    else:
                        szTxt += "%d AD" % iYear
                else:
                    szTxt += unicode(CyGameTextMgr().getInterfaceTimeStr(iPlayer))

Edit: {
On second thought, I want to change it so that month and day are never displayed throughout the game, only the year.
It is more performance friendly and it's ridiculous to designate a day and month to a specific game turn in a game like this.

Would this be acceptable?
If it is not acceptable then I will only change it so that months and days are not displayed before the year 1800 AD.
}

The 'before 1800 AD would probably be appropriate. I like it. That way Raxo gets to have his cake and eat it on this method. The only downside is that some turns might end up displaying the same year if we end up going into shorter increments in turn times before 1800 but I don't THINK we do that and I think if there's 2 lesser evils here, considering all factors, that's the one to allow. The turn COUNT is still different. Main thing would be how the save name may format over the top of the last on autosaves.

That is you can make it never display day, but month should be displayed for increments smaller than 12 months.

Never displaying the day does seem perfectly acceptable as well.

 

[Toffer90]

Main thing would be how the save name may format over the top of the last on autosaves.

The naming of saves is completely independent from the code change I'm suggesting, saves will still be named with months before 1800 AD if the calendar dictates it.
The code I will change will only affect the date display in the upper right corner of the main HUD.

That is you can make it never display day, but month should be displayed for increments smaller than 12 months.
Also for Transhuman/Galactic and later eras increment gets bigger.

There is no reliable way for python to check if the month increment is smaller than 12.

Only removing the day could be done I guess... But it would be more elegant code vise to never show the month nor the day.

@Yudishtira: Could you check if the attached file works correctly in removing months before 1800 AD without python errors, I don't feel like uninstalling PPIO at the moment as I'm in the middle of modding that modmod atm.

Overwrite the file in Assets\Python\Screens

 

[Thunderbrd]

I was just one of these "and some damn fool came along and adjusted them again" modders like ls612 (Who I thought did a lot of good fixing many bad parts of the mod, when it was desperately needed).

I liked this side of what you had done a lot and argued to try to bend the game around the calendar (since I know it's a pain in the ass to setup well) rather than to have the calendar have to bend around the game. But I think it may just be too difficult to keep an elegant solution in place and maintain pace accuracy in most cases, particularly as the mod grows and expands and evolves. But I did think you did well. I never meant for EVERYTHING to be thrown out - apparently there was more frustration and desire to do things in a different manner in a lot of realms than I had anticipated. I thought we were looking at just adjusting the approach on some numerics so that they aligned better between gamespeeds and handicaps and so on and were situated into more stable and clear ratios. Perhaps at this point you can see what I mean by that but at the time it didn't seem you were able to understand the need for this and your anger towards me for my own mistakes and what inconvenience they were going to cause you was enough to put me far away from trying to defend your efforts in the mod. That's basically all it boiled down to. I'm not saying you didn't have a right to be irritated but I'm not a perfect human being who takes said irritation without displaying my ire for it in return. I think most people do lash back when struck and both of us were guilty of that in our own ways. I apologize for my role in that. At this point all I care to do is make sure things are working as well as possible, for what's the point of moving forward into new territory without making sure what we have is a pretty good platform for new growth? I don't resent anything but I can understand why you still do and there's very little I can do about that at this point except to express my apologies for losing my own temper.

Once my efforts to create an elegant gamespeed file were dashed, I told myself I would NOT go through that effort again, it was like trying to hand grow a crystal - everything had to be just perfect and fit so many ratios of consideration it was maddening. So if this adjustment from Toffer's side can simplify this for us all, AWESOME!

EDIT: I also don't mean to bash ls612's efforts either - it was just frustrating how our focus interests were so deeply overlapped and how much disagreement and clashing this created by having entirely different priorities. I also regret how I handled a lot of that. Perhaps I should've just bowed out then rather than fight for my POV to win over. I had stepped out of things for a while and it was during this time that ls612 rose to take his position on the team so in retrospect, I suppose I had no right to try to get around his opinions on some things.