Long wait times between turns

[xienwolf]

With the time I have available lately for code, it'd be nearly a year for the rewrite.

 

[civ_king]

figure out how to do it and put it in chunks, also put a hold on adding stuff

 

[far_wanderer]

Not intending to offend, Xien, but even on my relatively powerful system (3.2ghz processor, 8gb ram) the turns into the 400s have about a 30s lag. I like the shiny feautres too (and am jealous of the coding) but at some point isn't it better to focus on improving what exists to the maximum before adding more?

Though if we're talking like a three month long code rewrite I suppose most people in the forums wouldn't be patient with that for a speed upgrade... hmmm.

With the time I have available lately for code, it'd be nearly a year for the rewrite.

Speaking as one of those "people in the forums" I would be relatively okay with a lack of new features for a while. That's assuming bugs keep getting fixed and it's not "the dev team vanishes for a year" . People who crave constant additions now have FF+ to go to. Some stability for a while could also do a lot to encourage mod-modders to stretch their skills a bit more, since it would be less of a scramble to constantly stay up to date.
And I should note that I say that as someone who isn't inconvenienced by long turn length.

 

[Iceciro]

I'm slowly helping on the "new features" front too, as are the other mod-modders.

I just feel like this late in the games development cycle, at some point the OOSes and slow turn speeds should get priority. Maybe a full year is a little much for me to ask for, but look at how long we've waited for patch C considering some stuff is broken in B, but been (relatively) patient about it. (Not that Patch B is unplayable, but that some stuff is just disconnected in Patch B.)

 

[WarKirby]

but look at how long we've waited for patch C considering some stuff is broken in B, but been (relatively) patient about it. (Not that Patch B is unplayable, but that some stuff is just disconnected in Patch B.)

This is mainly because vehem and xienwolf have been on hiatus with various issues, and hings like fireball supply/onUnitKilled are beyond my expertise to fix. I've been doing what I can though. the Patch C changelog is 81.57% my work.

 

[Iceciro]

Wasn't intended as a dig at you guys or anything - just a statement.

 

[xienwolf]

I think Kirby mostly meant that the long delay on C isn't a sign that big things are coming, but rather a sign that NOTHING is happening for the most part. Not new additions nor bugfixes nor speed enhancements.


To be clear on my timetable I gave: I ALWAYS tweak the code to be faster/better while I am working on other things. It is while doing those tweaks that I realized how I can speed things up to a (possibly) great extent. Some of that work I can do piecemeal, and I most likely shall while writing code, but lots of it would be an INSANE drudgery and lots of repitition. The timetable of a full year accounts for me getting massively bored with the whole process and stopping for a long time, but optimistically has me coming back to it repeatedly and finishing the entire thing.

Additionally, all of this code re-write would focus on areas of the code I am already quite familiar with, and might completely miss gigantic slowdowns in sections of the code which I haven't been to yet. New features aren't generally a "Look what I can do!" event, they are more of a "What is in this file? Ooh, this could be done so much better if..." type of situation. Or a "You know, this aspect of the game is completely lacking, and would handle better for the AI/faster for the humans if we..." This second one is what led to my concept of the Aspects system for controlling changes to tiles in the same manner as we control changes to units (Promotions) or cities (Buildings)


Also note that a lot of the "unfinished additions" which people sometimes complain about or highlight when comparing mods are actually just pieces of a much larger code overhaul, and it is being done in parts because it is either a massive rewrite with lots of potential bugs to check out, or it is an in-depth new concept which takes time to implement with AI support. These get stuck at partial completion when unexpected complications arise, or other issues become critical.


So yes: From a non-Coder perspective you can say "Just stop doing anything new and make the current stuff work," but for most coders I would hope it is obvious that making stuff work REQUIRES new additions in 85% of cases, especially when the reason it doesn't work is because it is only partially implemented. And from a realistic perspective: I code to make an enjoyable game (I want it to work), but I also code to learn how to code (I want to push myself). And as with everyone in the world, where I devote freetime depends on what inspires me, so when I see potential for a nice new feature, it is near impossible NOT to add it.

 

[Iceciro]

Understandable - at the end we're sorta at your mercy anyways, as far as what gets into the code and what doesn't, unless some of us get down and learn the DLL (and in any case we'd have far to go before we could make it do the backflips that you can). Just sorta a "my one-half cents" comment on my part.

And yeah, I can definitely see not wanting to devote huge gaps of time to unchallenging, boring, repetitive changes over large sections of code.

 

[hbar]

I would say that the late game turn time is drastically improved from 050. I do have a small complaint though, one that recently forced me back to base FfH. Every time I move a unit, I get a tiny, half-second 'hang' as it changes tiles. This gets really annoying, and if anyone can give me a hint on how to reduce/avoid it, I would give you a pretend cookie.

BtW, Xienwolf, I heard that you are taking the quals. If I am not too late, let me give you a small piece of advice. If they have free donuts, avoid them! The sugar is great for the first 90 minutes, but this is a 4 (6? 8? 12? 48?) hour test, and you will crash.

Hey, I said small. The donuts killed my brain on my first try, and avoiding them helped me pass my second.

 

[xienwolf]

Spending too much time on the forums and building the nursery was what helped me just miss passing the quals this time through. Though if they offered donuts I am sure they wouldn't have helped I just figured they would be sadistic enough to require cylindrical coordinates on anything, so didn't spend the extra time to remember such a bastard system.

As for the moving, do you have quickmoves enabled?

 

[WarKirby]

half a second on a move doesn't seem bad, I don't see how you could consider it unplayable based on that. Most humans can't accurately count half a second because it's such a short time.

 

[hbar]

Ha! I am not most humans And I never claimed to be accurately counting, just approximately...anyway, its not unplayable, just irritating enough to push me away. I'll be back

I don't have quick moves turned on, I'll try that and see if it helps. And cylindrical coordinates always make me think of this.

 

[readercolin]

if you don't have quickmove and stackmove and stack attack on... it gets to be ALOT of time reaaaal fast. Of course, i haven't played without those in well over a year... but...

-Colin

(though... i do hate how stack attack has the stupid idea that I WANT to waste my highly promoted hero as cannon fodder first... grr...)

 

[xienwolf]

I tweaked Stack Attack earlier to place lower value on attacking with the Hero unless he can win. At least it SHOULD have affected Stack Attack, because it was the function that the AI uses to decide which unit to attack with first from a stack. If it still sacrifices Hero units in stacks against impossible odds, let me know and I'll tweak it more.


So, lag on moving without Quickmoves on... that means you click and there is a pause before the movement animation begins? I would assume you don't mean the time taken for the actual movement animation.

 

[hbar]

I click and the unit starts moving, and as it crosses the boundary between tiles it lags for a half-second or so. I believe that it is only the last tile if the unit travels more than one, but I can test that to be sure. This happens regardless of map size, turn count, number of units, etc., and it happens for every unit of every civ I've tried.

 

[xienwolf]

Odd that it happens mid-animation. I wouldn't expect anything to hold up the ani once started, only to prevent it starting immediately.

 

[Tarquelne]

I haven't looked to check, but that sounds a lot like the sort of lag or "hitch" seen when a python spell req. is buggy. Not necessarily a spell that the unit can use - just any spell.

So at least in some cases it's python related.

 

[Milaga]

Odd that it happens mid-animation. I wouldn't expect anything to hold up the ani once started, only to prevent it starting immediately.

This same thing started happening to me. I think it was after one of the patches I have quick moves on, but it's not about the moving, it's about the animation. The same delay is present if you fortify a unit. The animation starts, lags for about a third of a second, then resumes. I tried setting DynamicUnitPaging and DynamicAnimPaging to 0 in CivilizationIV.ini just in case but it didn't have any effect. I thought I started having this problem back in one of the 0.50 patches but I guess I never posted about it.

Thanks for all the the replies, Xien. I try not to make requests of any of the development teams (since they are doing this voluntarily) but rather suggest changes that might help others enjoy the endeavor more. My instinct is telling me that there was something more on top of just having more civs and more units in each civ.

I was hoping there might be some low-hanging fruit that could speed things up. I too had to go back to FfH since by midgame even a standard sized game is unplayable. It sounds like you are already picking said fruit as you work on other things.

 

[xienwolf]

If Tarq is right, and it is one of those "infinite python errors" then ensure you have Show Python Exceptions enabled (or Hide PyExceptions disabled, can't remember which way it goes) so you see them popping up.

 

[hbar]

; Set to 1 for no python exception popups
HidePythonExceptions = 0

It does not seem to be a python exception. I'm about to test to see if quick move helps.