Modified by on Thursday, August 6, 2009 - 05:22Fri, 07/17/2009 - 06:05 — Steelclaw
383.12 Download (deprecated by 383.13)
383.13: Patch to Blight to get this!
383.13 PDB Download
383.14: Ran off with a .def file and was never seen again!
383.15 PDB Download
with a very long name found and fixed.
future crashes and weird behavior.
applications or idle down.
to shorten the client-server lag while downloading new terrain.
"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)
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:
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
Submitted:Fri, 07/17/2009 - 19:59
- 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
Submitted:Sat, 07/18/2009 - 01:41
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
Submitted:Sat, 07/18/2009 - 21:22
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.
Submitted:Mon, 07/20/2009 - 01:38
- 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):
- 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.
Submitted:Mon, 07/20/2009 - 06:40
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
Submitted:Mon, 07/20/2009 - 12:15
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.Â
Submitted:Mon, 07/20/2009 - 13:08
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:
Submitted:Mon, 07/20/2009 - 23:30
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?
Submitted:Tue, 07/21/2009 - 01:38
They seem to be all 128x128 pixels.
Ah, thanks. Â I assume they
Submitted:Tue, 07/21/2009 - 06:31
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.Â
Submitted:Tue, 07/21/2009 - 06:48
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. :)Â
Submitted:Tue, 07/21/2009 - 14:58
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. Â
Submitted:Thu, 07/23/2009 - 22:16
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
Submitted:Mon, 07/27/2009 - 21:57
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
Submitted:Tue, 07/28/2009 - 14:37
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.
I updated the info at the
Submitted:Wed, 07/29/2009 - 04:46
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.Â
Submitted:Wed, 07/29/2009 - 19:41
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:
Submitted:Thu, 07/30/2009 - 19:54
Not sure latest client versions are the reason of this, but debug logs have became pretty heavy lately:
Thanks for trying.Â The
Submitted:Fri, 07/31/2009 - 02:18
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?
Submitted:Sat, 08/01/2009 - 18:53
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
Submitted:Sun, 08/02/2009 - 21:32
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
Submitted:Mon, 08/03/2009 - 00:20
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.
The process ran out of memory.
crash_log::finish(): Terminating the process.
SetUnhandledExceptionFilter to be old filter.
Fubar!Â New client today on
Submitted:Tue, 08/04/2009 - 13:36
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
Submitted:Tue, 08/04/2009 - 20:20
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.
Submitted:Thu, 08/06/2009 - 01:19
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.
Submitted:Thu, 08/06/2009 - 01:39
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.
Submitted:Thu, 08/06/2009 - 09:14
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.
Submitted:Thu, 08/06/2009 - 16:23
Thanks!Â That's what I want to hear.
Submitted:Thu, 08/06/2009 - 21:08
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.Â
Submitted:Sat, 08/08/2009 - 18:50
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.