1.29 Semi-public beta

Originally posted by tao

2x1GHz MDD. And in my current game, the temporary lock-ups happened only twice in the Ancient Age. No "problems" afterwards.

Maybe this bug only shows up on dualies?
 
Originally posted by sirromdivad
Anyway, I have notice Txurce's problem -- after moving all the units the "continue" button flashes slower than usualy, and scrolling the map is slow and choppy.

Has anyone experienced this in a game that wasn't GOTM related?
 
Originally posted by Brad Oliver


Has anyone experienced this in a game that wasn't GOTM related?

Yes, I've noticed it during some of my beta_1.29_1 games; however, I don't think I've noticed it w/ the beta_1.29_2 patch.

What I do notice w/ the latest beta patch (and prior) is that the ironclad has no fx sounds. The frigates and galleons can be heard when given the order to "sentry," but they still make no sounds when manually moved.

The only thing I can think from my side is that maybe my sound isn't set loud enough, I'll test this. But, I thjink I play at a normal sound level.
 
Originally posted by Brad Oliver


Did it ever happen with 1.21f or g?
I've seen it with 1.29b1 and 1.29b2 on normal single play games and GOTM. [Correction] I have no note of it happening on 1.21, and when I reported it here originally I didn't indicate that I'd seen it before.

Usually I quit and reload and it's OK for a while, then it returns. I've tried pausing and running top to see if there's an obvious memory or cpu problem at this point but never seen anything. So I suspect it's display related, as the display process is suspended when you pause. I'll set up a MacSSH session into it from my other Mac (OS 9) and run top to see what changes when the slowdown next occurs. Is this likely to help, and are there any special top settings that could provide more info?

G4/350 Sawtooth, Jaguar - various versions, 1.12GB RAM and lots of disk.
 
Originally posted by Brad Oliver


Did it ever happen with 1.21f or g?

No, I've never experienced it w/ 1.21f or g, IIRC. Its very obvious, and I'm sure there would have been a thread about it here in the mac forum.

<G3/333 --- 10.2.6 --- 512MB RAM>
 
Originally posted by dojoboy


Yes, I've noticed it during some of my beta_1.29_1 games; however, I don't think I've noticed it w/ the beta_1.29_2 patch.

Well, I have now. :(

The "delay_bug" is currently taking place w/ this posted save file.

See it here! Live!
 
Originally posted by dojoboy


Well, I have now. :(

The "delay_bug" is currently taking place w/ this posted save file.

See it here! Live!
It's certainly a bit slow on my system, but I haven't played the Earth map before, so I have no way to compare it. I've also never seen that many cities go up in flames all at once, so I wonder if it's just that it's trying to animate an awful lot of smoke :eek: . Have you tried backing up and seeing what happens if you wind up the entertainments budget before this turn?
 
Originally posted by AlanH
I'll set up a MacSSH session into it from my other Mac (OS 9) and run top to see what changes when the slowdown next occurs. Is this likely to help, and are there any special top settings that could provide more info?

Yes, if it happens again and you have SSH set up, ssh into the Civ3 Mac and type "top" to get the pid for Civilization 3. It's the number in the first column.

Then, while still in the shell, type this:

sample pid# 20 -file civ3sample.txt

Replacing "pid#" with the actual pid number you got from "top". This command will run for 20 seconds, give or take, then terminate.

That'll spew a text file called civ3sample.txt that you can e-mail to me at bradman@pobox.com. This should tell me where it's spending its time.
 
Will do. I have MacSSH all set up.

I looked at Dojoboy's .sav file just using top, but it didn't seem to be doing anything special for me. I suspect extreme animation overload due to lots of revolting cities.

I notice on my G4/350 that, during .sav file loading, when there seems to be intensive computing going on and the progress bar sticks at 37% for a long period, the cpu utilisation doesn't go above about around 35%. But once the screen is active it shoots up to 60-70%, even though there are not many active units fidgeting on-screen and nothing else visible is happening, and the onscreen units fidget *very* slowly. This is not specifically during the exceptional hangups, just in normal operation.

The time between animation updates for each figure in my current practice game is 6 seconds. This is the same whether I zoom the map or not, and seems to be unaffected by sound on/off settings. And opening and updating the Sound dialog, or toggling the grid takes a long time and seems very hit and miss - the shortcut keys don't seem to be detected a lot of times. Does the game fidget every unit on the map at the end of the turn, even if there are only a few visible on-screen?
 
Okay here it is again, w/ only one city in disorder. Also, when I saved and quit, the application crashed. Log below:

Date/Time: 2003-06-04 08:36:22 -0400
OS Version: 10.2.6 (Build 6L60)
Host: Tom-Herrings-Computer.local.

Command: Civilization III
PID: 375

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbb0dff9d

Thread 0:
#0 0x90073c48 in mach_msg_trap
#1 0x90005f90 in mach_msg
#2 0x90229cf8 in SwitchContexts
#3 0x902245a0 in YieldToThread
#4 0x9022a158 in YieldToAnyThread
#5 0x001b6d48 in MusicEvents__Fv
#6 0x001a9a54 in MacYield__Fv
#7 0x001a5b10 in PeekMessageA
#8 0x00216348 in flush_timer__6JGLSysFv
#9 0x002645fc in flush_timer__Fv
#10 0x00265e04 in close__4TimeFv
#11 0x002e1b54 in stop_timers__Fv
#12 0x002f7cdc in control_game__Fb
#13 0x002cb148 in run__13Civilization3Fiib
#14 0x003885fc in WinMain
#15 0x001b5048 in main

Thread 1:
#0 0x90073c48 in mach_msg_trap
#1 0x90005f90 in mach_msg
#2 0x901489f0 in __CFRunLoopRun
#3 0x90180f58 in CFRunLoopRunSpecific
#4 0x94d9c1c0 in _ZN10HALRunLoop9OwnThreadEPv
#5 0x94d911b0 in _ZN9CAPThread5EntryEPS_
#6 0x90020d48 in _pthread_body

Thread 2:
#0 0x9003eaa8 in semaphore_wait_signal_trap
#1 0x9003e8c4 in _pthread_cond_wait
#2 0x90232754 in TSWaitOnSemaphoreCommon
#3 0x9023b550 in TimerThread
#4 0x90020d48 in _pthread_body

Thread 3:
#0 0x9003eaa8 in semaphore_wait_signal_trap
#1 0x9003e8c4 in _pthread_cond_wait
#2 0x90232754 in TSWaitOnSemaphoreCommon
#3 0x90247ecc in _Z15AsyncFileThreadPv
#4 0x90020d48 in _pthread_body

Thread 4:
#0 0x9003eaa8 in semaphore_wait_signal_trap
#1 0x9003e8c4 in _pthread_cond_wait
#2 0x90232754 in TSWaitOnSemaphoreCommon
#3 0x90233094 in DeferredTaskThread
#4 0x90020d48 in _pthread_body

Thread 5 Crashed:
#0 0x91fd5a38 in SetMovieVolume_priv
#1 0x9023b180 in CooperativeThread
#2 0x90020d48 in _pthread_body

PPC Thread State:
srr0: 0x91fd5a38 srr1: 0x0000f030 vrsave: 0x00000000
xer: 0x20000000 lr: 0x001b6b14 ctr: 0x920212c0 mq: 0x00000000
r0: 0x00000074 r1: 0xf0488df0 r2: 0xbb0dff19 r3: 0x09d2065b
r4: 0x91fd5984 r5: 0x00000074 r6: 0x1db7f800 r7: 0x00000000
r8: 0x4be5e480 r9: 0x09d2065b r10: 0x91fd5a14 r11: 0x920212c8
r12: 0xa1f712c8 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000
r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000
r24: 0x00000000 r25: 0x00000000 r26: 0x00000000 r27: 0x00000000
r28: 0x0003be33 r29: 0x0267e7e0 r30: 0x0003be32 r31: 0x00000002

delay_bug2
 
Dojoboy: Does the slow behaviour and/or crash on quit happen again if you reload the .sav file you sent?

Brad: When I loaded up Dojoboy's latest .sav file I only saw what I'm now used to as sluggish end-of-turn behaviour - poor response to keyboard shortcuts, and slow, jerky animation, as described in my previous post. The animation frames seemed to update at around 8 second intervals with this file, but it's much further along, with more civs and more cities and units than my previous example where I was counting about 6 seconds per frame.

However, I have produced a 20-second sample output as you suggested, and uploaded it here. Let me know if you need any more info.

I tried saving the game and quitting and it behaved normally - no crash. I didn't play any turns. So either it doesn't happen after a reload without playing, or there's something different about Dojoboy's system and mine.

I'll look out for an abnormal condition on my system and get you a sample file as and when that happens.

One interesting observation: I have been running OpenOffice.org to build a spreadsheet model of the game opening moves, and it appears that whenever I start up a Civ3 session I lose X Windows and its running apps. :(
 
Originally posted by AlanH
Dojoboy: Does the slow behaviour and/or crash on quit happen again if you reload the .sav file you sent?

No, the game responds normally upon reloading. Memory leak?
 
Originally posted by dojoboy


No, the game responds normally upon reloading. Memory leak?
That's what I'm thinking. 'Specially now you've reported a crash.

Have you tried it with the sound effects and music switched off? I realise that may totally ruin your game experience :cry:, but it might give Brad more clues.
 
Originally posted by AlanH
Will do. I have MacSSH all set up.

While playing GOTM20 I was seeing the end-of turn slow-down, and it got to a cycle time of about six seconds by 1000 BC. I could avoid it completely by keeping one unit active instead of fortified as Txurce suggested earlier. Then I end the turn with two space-bar hits - one to end the active unit's turn and the second to end mine.

After I'd completed my QSC and spoiler chores with the game paused I was about to take a sample using SSH as suggested by Brad. I resumed the game and Bingo! It was cycling the "Return or space" message at about 30 seconds intervals. So Brad now has a bunch of sample files to play with. The problem was still curable by activating one fortified unit. I saved, quit and reloaded, just to see if the slow-down would go away, and it did. First reload of the game - OS X and Brad's Civ3 port are soooo stable! :goodjob:
 
Top Bottom