- Lag seems to have been a bit reduced while loading the terrain. Still there though, but it will need to be tested longer to really appreciate the difference.

- FPS cap at 60 doesn't really seem to work:

- This build seems to have slightly better performances than the previous one. I need to test it on a slower computer to really appreciate the difference.

- No crash, but I don't think I have tested long enough to get one. :-p

Whoops. Okay, corrected the change description. The implementation indeed does not cap FPS.

The main loop will sleep() for 1ms if it detects that less than 16.7ms has elapsed since the last iteration.  A fast machine will indeed get higher than 60FPS, however, its cpu utilization will go down from pegging a core at 100%, which is the goal of the change. 

First of all I think its great you do this Ranq, its very much appreciated.

Now a few things I notice after playing 5 hours with the client atleast.

- Monsters seem to have huge delay in moving, sometimes it takes a while before the monster shows up death or shows hes nearby. I also notice gliding corpses.

- Another thing I notice is that my loot windows have quite some delay, I nearly start to think that the network thread is a lot slower?

- So far no crashes, a friend of me also has the new client and had 1 crash but she said it wasnt like the ones she used to have, this one was not as bad, as in not causing her whole PC to reboot like the other client did.

Currently my FPS is 30, and no terrainrequests while testing.

Will update when I notice anything else.

- I have noticed the same delay with the loot window yesterday (on Island of Elnath and Dralnok's Doom if it can helps).

- I got only one crash, after around 2 hours of play (and after porting to Bristugo if I remember well):

crash_log::open_maura(): Successfully started crash log at 07.18.2009 21:58:00.082.
crash_log::on_crash(): Exception caught from thread 0x00000840 (2112) on 07.19.2009 02:00:37.413.
   _____
  /     \
 /       \
 | R.I.P.|
 |       |
 |       |
~~~@>-+-~~~

The ACCESS_VIOLATION hits! The ACCESS_VIOLATION hits! You die.

c0000005h (ACCESS_VIOLATION)
The thread tried to write to the virtual address 0x00000000 for which it does not have the appropriate access.

You died in...
spanish_inquisition::perform(): Symbolic information is not available.
EAX=00000000
EBX=1C0821C0
ECX=00004000
EDX=00000000
ESI=42B82658
EDI=00000000
CS:EIP=0023:748B72D7
SS:ESP=002B:0018B950   EBP=0018B954
DS=002B   ES=002B   FS=0053   GS=002B
FLAGS=00210206

ADDRESS   FRAME     FUNCTION/FILE;LINE
748B72D7  0018B954  (unknown)
                    (unknown)
748B7344  0018B974  (unknown)
                    (unknown)
004D6353  21B0D92C  (unknown)
                    (unknown)
019E6A94  00CBAF98  (unknown)
                    (unknown)
00C3B3DA  00C3B3E0  (unknown)
                    (unknown)
25FF00CB  85D825FF  (unknown)
                    (unknown)


crash_log::on_crash(): Successfully finish maura, and start minidump

crash_log::on_crash(): Successfully finish minidump

crash_log::finish(): Terminating the process.

SetUnhandledExceptionFilter to be old filter.

 

- For lag, I still think I have a bit less, but it's hard to say. Maybe knowing the meaning of the "v" and "q" in TerrainReqQueue would help.

I'll see if I can get a .pdb file.  That *might* help the crash reporter figure out what functions are at the addresses in the stack trace (instead of "unknown").

As for the q and v, those deal with the terrain system.  

When each sector is loaded, a version request is sent to the server.  The server responds back with a version.  If the version matches the one that the client has, then the client proceeds to load the sector from the world cache.  The number of queued version requests is the number before the "v".  Version requests are pretty low overhead and get processed quickly.

If a sector version response from the server does not match the version that the client has, the client will then request new terrain for that sector.  Terrain comes down in layers.  The number of queued layers is the number before the "q".   Terrain layer responses trigger a whole slew of other activities, such as building the LOD tiles for the terrain.  These responses are somewhat intensive and will probably cause hitching as well as a good deal of network lag.

That reminds me.  Do you have any tiny .png files in your world cache?  Tiny being under 1KB.  Windows file search will allow you to specify size thresholds  if you enable the advanced mode.

After some more playing today and yesterday it seems that both the loot and corpse lag were a onetime problem, I haven’t noticed both of them again.
 
I had no crashes either, but that is also for the 383.7 client, as I always dual log. Maybe I’m being lucky so far.

The windows, such as guild or /who and lots more are still slow though.
 
Another thing I do notice, this is not 383.12 specific as I always had it with any build is that the graphic seem to hang when the window loses focus. All other parts of the game seem to be working though, when the window becomes active again it sort of catches up with all what has happened, very rapidly. 

First thanks for the very clear explaination of the queue system.  And yes, this is sometimes very intensive with several different versions in a row and 40-50 layers in queue. It happens often while flying through large areas. And you have to deal with lag until it's fully loaded... this can take a while.

For the tiny .png files, I found several of them in my cache folder, from 140 octets to 937 octets:

 

Hanging window:  I've noticed that too.  Try full-screen on a dual head system.  That's all kinds of f'd up!  I don't know what causes that though.  It should be fixed, but that's low priority.

Tiny PNG files:  Are those, by any chance, not 128x128px? If so, what dimensions do you see?

They seem to be all 128x128 pixels.

Ah, thanks.

I assume they decoded properly too?

Under certain circumstances the client can generate strange sized LOD tiles (especially 0x0px), which will cause a crash when it then tries to load such tiles as a texture. 

Client 383.13 should appear on Blight later today.

This is essentially the same as 383.12, with additional fields in the item

properties window.  Any bugs found in 383.12 are in 383.13 too.

Please grab the zipped PDB file at the top of the page and drop the

unzipped PDB file in along with the 383.13 build of istaria.exe.  This

will enable the crash reporter to include function and class names

in the stack trace -- which means more useful information for me. :) 

I can open them all at least. But they are mostly fully black pictures, with some variations sometimes.

Shouldn't the .pdb file be patched on Blight? You may have more accurate reports than only with the few who are visiting this page.  

Client 383.13 is now on Blight!

If you've been able to crash 383.12, please "install" the PDB for 383.13 and try to crash the client again.  The PDB will enable more detailed crash reports.

Re: Black/blank terrain LOD tiles:

Figures as much.  Something strange happens that causes the tiles to either be completely blank or improperly sized.  I don't know what causes that yet. Hopefully more detailed crash dumps will help.  Those tiles can be safely deleted.

So far I noticed that my client is crashing atleast as much as the previous one. Sadly nothing useful in the MAURA file. (Using client 383.13)

I will use PDB from now on.

383.13 seems to work fine for me on XP playing on Order.  The Spells/Forms/Techs lists are much faster now and don't bog down like they used to after repeated uses.  One of those memory leak fixes must have done the trick.

The only issue I still have is after several hours it will get choppy hitting the disk cache and will eventually crash on a port.  I haven't yet had one of those random instant crashes out of the blue with no performance degradation first.

No login or connection problems, save for my own cable company randomly deciding to reset my cable modem.

Drev

I updated the info at the top.

Two new bugs, one is a crash when selling plots back to the community; that has been fixed.  The world cache has incorrect sector owner info.  That has also been fixed.  Both fixes aren't in a release build yet.

If your world_cache\<shard>horizons\terrain\terrain_info.def file has a lot of lines with "int ownerID = 0", you'll probably have to nuke it when the next build comes out.

Some of the crashes may be a result of the client passing around the wrong ownerID.  Here's hoping. 

I added the istaria.pdb as described in the instructions and using v383.13. 

However, it doesn't seem always contributive when a crash happens. Here are the 3 last crashes; they all happened after a while in game (2 hours) and nearly always after a recall:

crash_log::open_maura(): Successfully started crash log at 07.25.2009 16:29:26.863.
crash_log::on_crash(): Exception caught from thread 0x00000d1c (3356) on 07.25.2009 19:22:58.639.
   _____
  /     \
 /       \
 | R.I.P.|
 |       |
 |       |
~~~@>-+-~~~

The ACCESS_VIOLATION hits! The ACCESS_VIOLATION hits! You die.

c0000005h (ACCESS_VIOLATION)
The thread tried to write to the virtual address 0x00000000 for which it does not have the appropriate access.

You died in...
spanish_inquisition::perform(): Symbolic information is not available.
EAX=00000000
EBX=1CDFFA60
ECX=00004000
EDX=00000000
ESI=2D44CF80
EDI=00000000
CS:EIP=0023:72E772D7
SS:ESP=002B:0018B950   EBP=0018B954
DS=002B   ES=002B   FS=0053   GS=002B
FLAGS=00210206

ADDRESS   FRAME     FUNCTION/FILE;LINE
72E772D7  0018B954  (unknown)
                    (unknown)
72E77344  0018B974  (unknown)
                    (unknown)
004D6743  1CA0F224  (unknown)
                    (unknown)
01A46A94  00ACAF98  (unknown)
                    (unknown)
00A4B3DA  00A4B3E0  (unknown)
                    (unknown)
25FF00AC  85D825FF  (unknown)
                    (unknown)


crash_log::on_crash(): Successfully finish maura, and start minidump

crash_log::on_crash(): Successfully finish minidump

crash_log::finish(): Terminating the process.

SetUnhandledExceptionFilter to be old filter.

======================================================================================= 

crash_log::open_maura(): Successfully started crash log at 07.25.2009 21:55:07.419.
crash_log::on_crash(): Exception caught from thread 0x00000938 (2360) on 07.26.2009 00:58:42.386.
   _____
  /     \
 /       \
 | R.I.P.|
 |       |
 |       |
~~~@>-+-~~~

The ACCESS_VIOLATION hits! The ACCESS_VIOLATION hits! You die.

c0000005h (ACCESS_VIOLATION)
The thread tried to write to the virtual address 0x00000FFC for which it does not have the appropriate access.

You died in...
spanish_inquisition::perform(): Symbolic information is not available.
EAX=733B0C7A
EBX=00000000
ECX=FFFFFFFF
EDX=000000FF
ESI=00000FF8
EDI=FF000000
CS:EIP=0023:00BB7761
SS:ESP=002B:0018DA18   EBP=000003FF
DS=002B   ES=002B   FS=0053   GS=002B
FLAGS=00210216

ADDRESS   FRAME     FUNCTION/FILE;LINE
00BB7761  000003FF  (unknown)
                    (unknown)


crash_log::on_crash(): Successfully finish maura, and start minidump

crash_log::on_crash(): Successfully finish minidump

crash_log::finish(): Terminating the process.

SetUnhandledExceptionFilter to be old filter.

 

=======================================================================================  

 

 

 crash_log::open_maura(): Successfully started crash log at 07.29.2009 21:58:51.653.
crash_log::on_crash(): Exception caught from thread 0x00000344 (836) on 07.30.2009 00:55:05.862.
   _____
  /     \
 /       \
 | R.I.P.|
 |       |
 |       |
~~~@>-+-~~~

The ACCESS_VIOLATION hits! The ACCESS_VIOLATION hits! You die.

c0000005h (ACCESS_VIOLATION)
The thread tried to read from the virtual address 0x0000001C for which it does not have the appropriate access.

You died in...
EAX=39A9E5AC
EBX=33D3E02C
ECX=00000000
EDX=33D3E02C
ESI=05E5E3EC
EDI=0CB90750
CS:EIP=0023:00D81910
SS:ESP=002B:0018DC04   EBP=3F0B1578
DS=002B   ES=002B   FS=0053   GS=002B
FLAGS=00210206

ADDRESS   FRAME     FUNCTION/FILE;LINE
00D81910  3F0B1578  ?getChildCount@igGroup@Sg@Gap@@QBEHXZ+0h
                    (unknown)
01A1BC94  00DFD9E8  (unknown)
                    (unknown)
00DFA10A  00DFD9E8  ?internalQuickSort@?$igTDataList@P6AXPAVigAttr@Attrs@Gap@@PAX@Z@Core@Gap@@AAEXHH@Z+14Ah
                    (unknown)
00DFA10A  00DFA110  ?internalQuickSort@?$igTDataList@P6AXPAVigAttr@Attrs@Gap@@PAX@Z@Core@Gap@@AAEXHH@Z+14Ah
                    (unknown)
25FF00DF  B54025FF  (unknown)
                    (unknown)


crash_log::on_crash(): Successfully finish maura, and start minidump

crash_log::on_crash(): Successfully finish minidump

crash_log::finish(): Terminating the process.

SetUnhandledExceptionFilter to be old filter.

 

 

Not sure latest client versions are the reason of this, but debug logs have became pretty heavy lately:

 

Thanks for trying.  The crash log is still lacking the information I need -_-.

On the bright side, I did find a few possible places where there could be trouble.  Here's hoping one of those actually fixes the crashes you experience.  (The fixes haven't gone out yet.)

As for the debug logs, I have no idea if there's anything extra there.  I just rotate them out. :p 

After the update, the client splashscreen shows the client as being version 383.14.1, but the fpswindow shows 383.13. 

Which is correct?

*edit* Figured it out myself.  The version.txt does say 383.14.1, but the client executable is still in fact 383.13.  The ownerID in the terrain.def is still getting set to 0.

Whoops.

A *slightly modified* version of 383.13 went out without my fixes in place.

The build number in the fpswindow is the one you should go by.  The one in version.txt isn't strictly correlated with a build number.  Would you like to run 9999.1234.wheee? :p 

Here's a new one.  Finally had a sudden crash with no degradation in performance first.  Oddly I was just standing still out in the middle of nowhere.  Well, actually it was in the Valley of Tolroth but before the skeleton spawn area.

crash_log::open_maura(): Successfully started crash log at 08.02.2009 19:18:11.531.
crash_log::on_crash(): Exception caught from thread 0x00000574 (1396) on 08.02.2009 21:51:17.765.
   _____
  /     \
 /       \
 | R.I.P.|
 |       |
 |       |
~~~@>-+-~~~

The EC_NOMEM hits! The EC_NOMEM hits! You die.

e0000000h (EC_NOMEM)
The process ran out of memory.

crash_log::finish(): Terminating the process.

SetUnhandledExceptionFilter to be old filter.

Fubar!  New client today on Blight.  I can't start it at all.  Tried web launch, standalone launch, batch file.  Zip nada nothing. 

Went into console and ran the batch file to see if there wa an error.  Returned an error saying it was unable to start the executeable.

Went back and replaced it with the 383.13 client and got in okay. 

The new one is supposedly 383.15, but I couldn't confirm that in game.

Running XP SP3 on and AMD 3800+ X2 w/2 gigs of RAM, Geforce GTX260.

Others on blight currently saying same thing, have to used older client to get in.

I think this is not constant: the v383.15 runs properly with my Windows 7 computer (launcher or batches).

However, it refused to launch and had the same symptoms as Drevar's on my Windows XP SP3 laptop. Rolled back to Live client, it was working properly again.

Found the problem.

Microsoft snuck in an update to the vc8 runtime environment around mid July.  All the builds since then required a new msvcr8.dll that was only available with either a manual update or by installing ie8.   The way that dll depenencies get resolved with vc8 and newer compilers requires a version check too. 

I've since figured out how to make istaria.exe use the latest available msvcr8.dll available on the host it's running on, so there should be no future problems.

For those coders out there:

Make sure   _USE_RTM_VERSION is defined in your project properties for the compiler.

Please try out 383.15 (updated post).  Unlike the last couple builds, this one should actually run, even if you haven't installed IE8. 

If there's nothing horribly wrong when compared to 383.13 or 383.12, I'd like to get it pushed out to Blight soon -- mostly because of the plot sale fix.

I installed both v383.15 and new .pdb on my Windows XP laptop and it runs properly now. 

Your IE8 thing seems strange as I have IE8 on this machine, Windows is up to date (I just have a bug with the installation of Silverlight) and the old version of v383.15 didn't work. Anyway, it works now.

Thanks!  That's what I want to hear.

Maybe you should wait for more feedbacks before pushing it to Blight though... I think you know first hand how nasty this client can be. 

Got hit with an ec_nomem crash in the new 383.15 client.  That leak is still in there somewhere.  Maura file shows nothing besides the actual error.

I was out on the border of the ED/Staging Grounds and frontier southeast of Harro (28555, 23836) looking for Thornwood treants on Order.

I don't know if it is related to minimizing or moving focus to other windows that causes it (I play in windowed mode), but it is usually when I get that bug (or at least notice it) of the client endlessly accumulating system memory, even standing perfectly still..  There was no performance degradation, simply, BOOM to desktop.

edit-a few hours later another one.  These are the only crashes I am getting now, running out of memory.

Drev