Monday, October 23, 2017 - 05:48

Horizons: Client 383.12

    Modified by on Thursday, August 6, 2009 - 05:22

    Client Build: 383.12 and 383.13 .. and 383.15

     

    383.12 Download (deprecated by 383.13)

    MD5sum: 8f8f80cc47f0afb32f3ed14307e63764

    SHA1sum: 0303b020a35cda13b179e303164693cd89b9c58a

     

    383.13: Patch to Blight to get this!

    383.13 PDB Download

    MD5sum: 30caf6a9cf505297ae2809cae31f72af

    SHA1sum: b03d3691af886c8e494d49eed234c70f17cb37ac

     

    383.14: Ran off with a .def file and was never seen again!

     

    383.15 Download

    MD5sum: c910c81324a1b845e975c44cdcde6b85

    SHA1sum: 2204bbb04bc01720bdf4051c389fe443b3314366

    383.15 PDB Download

     

    Fixes and Changes

    • Memory leaks in proptree found and fixed.
    • Message decoding no longer triggers an exception and stackwalk.
    • More memory leaks in proptree found and fixed.
    • Memory leaks in saveui found and fixed.
    • Buffer overrun in equipment window when right-clicking an equpped item

    with a very long name found and fixed.

    • Uninitialized buffer in sound manager causing crash when sound is disabled found and fixed.
    • More uninitialized buffers in sound manager found and fixed, may prevent

    future crashes and weird behavior.

    • The client will release the cpu above 60FPS, allowing the CPU to be used for other

    applications or idle down.

    • The number of terrain layers requested at once while downloading terrain has been reduced

    to shorten the client-server lag while downloading new terrain.

    • Dragon flight behavior above the max fly height has been changed to prevent "The Rift Jump".
    • 383.13: UI change to display an item's minimum and maximum level requirements if any.
    • 383.15: Possible crash point fixed: unloading a partially built sector may cause a crash.
    • 383.15: Character position updates are now sent when your character is moving, not every half second.

     

    Issues Known But Not Fixed In This Build

    • Loading terrain while the client window is minimized will crash the client.

     

     

    Issues Discovered During Testing

    • Attempting to selling a plot crashes the client. (fixed in 383.15)
    • The owner biote id for each sector isn't saved properly. The file terrain_info.def will show

    "int ownerID = 0" for almost every sector generated by the 383.x clients.

    (Fixed in 383.15)

    Incorrect build environment caused client to require a version of msvcr8.dll that may not be present on all supported platforms. (Fixed in 383.15)

     

     

     

     

    Regression Tests Passed

     

     

    Note: The purpose of comments added to this page is for feedback for this client build only.

    Comments that do not fit this purpose may be moved or deleted (with no penalty nor ill-will

    towards the author of the comment).

     

    Note 2: This client has gone to Blight as build 383.13.

     

    Note 3: 383.12 had a UI addition and was (will be) released to Blight as build 383.13, hopefully on

    Jul 21. A copy of this client can be obtained (once it is released) by patching to Blight and making

    a copy of the following files:

    • istaria.exe
    • encryption_client_lib.dll
    • pt_lib.dll
    • ptps_lib.dll

     

    Note 4: A zipped up PDB file for 383.13 is available. Download and unzip istaria.pdb to the same

    directory as istaria.exe. When the client crashes, the crash reporter should generate a stack trace

    with more useful information. This PDB file is only for 383.13.

     

    Note 5: Due to the impact of not being able to sell plots with the 383.13 client, a new build (probably 383.14) with the fixes in "Issues discovered during testing" may be pushed directly to Blight in a day or two.

     

    Note 6: 383.15 available for testing. This one should work.

    Short test: first impressions

    - 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

    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. 

     

    A few things

    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.

     

    Further testing

    - 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

    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. 

     

    Cache system

    First thanks for the very clear explaination of the queue system. Smile 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:

     

    Tiny files 

     

    .

    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

    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. 

     

    PDB file

    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. :) 

     

    Tiny files

    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. Tongue out 

     

    .

    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

    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

    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

    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. 

     

    istaria.pdb

    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.

     

     

     

     

    Debug logs

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

     

    Debug Logs 

     

    Thanks for trying.  The

    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 

     

    x.13 or x.14 on Blight?

    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

    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

    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

    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

    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.

     

    *headdesk*

    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.

     

     

     

    383.15 Available!

    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.

     

    It works.

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

    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.

     

    yay!

    Thanks!  That's what I want to hear.

     

    Wait?

    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. WinkTongue out

     

    ec_nomem

    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