the fact that ap and every other operations continue normally is actually interesting. It confirms that its something that happen during the d3d9->present() call, since its the only part of the code where it could visually freeze but still continue executing.

If you disable detached rendering, does ap still continue in the background during the freeze ?

yeah me and my teammate crashes like nonstop even when idle sometimes.
will try to sent a dump nexttime.

i still had no success on actually causing the freeze to happen in a controlled scenario (or at all for that matter).

a /dp containing the freeze would be a great help.

As well as knowing if autopilot continue during the freeze if detached rendering is disabled.

Better get used to having a lot crashes and wiping a lot due to players freezing on raids, doesn't look like we'll be getting a fix for that

IThen happens for me when disabled. Can't get a dump file though as the freezes, rather inconveniently, aren't causing any crashes.

Damn, if autopilot continue while frozen with detached rendering disabled, then it would mean the game doesnt actually freeze at all and that the whole problem happened completely outside of the process itself.... This would make it nearly impossible to track down without debugging the machine itself (using serial connector and low level debugger).

yea i know you cannot get a dump, thats why im hoping for someone to get me a /dp.

/dp is a code profiling system i added a rather long time ago, that keep track of how much time is spent in each part of the code, so if it was gathering data during the freeze, then this data would allow to narrow down the location of the code where the freeze happened.


I'm still trying to reproduce it on my machines but nothing i tried caused it to happen on multiple amd (hd6670, hd6850, hd7950) and nvidia cards (nvidia 9800gt, 240, 480,760). This would mean that im either not doing something specific in game that trigger it (unlikely considering how random it appear to people affected), that its driver specific (unlikely considering whitewizard updated and still get the problem) or that its a combination of software/hardware that somehow trigger it when ss is running.

How about you try out the new graphics cards, like Nvidia GTX 970+.
It's impossible for me to get a /dp since I have no clue when it actually freezes, generally whenever I jump through a wormhole I do get a major freeze.

if we can confirm that it only happen on newer gpu, i could see about buying one for the sake of testing. Altho its rather unlikely that it would be directly related to the gpu considering the d3d9 aspect of the hardware has been "done" for great many generations (and d3d9 is what we use for many reasons, one of which being that d3d10+ is not directly compatible with our engine and would mean losing xp support or maintaining both d3d9 and d3d10), suffice to say, its unlikely that its some new gpu thing thats causing the freeze, only real differences on d3d9 side that i know off between newer and older gpu are their processing speed and bandwidth.


on a side note, you mention freezing when jumping through wormholes, how long of a freeze are you talking about here ? Especially if you do not preload the textures, slight hiccup when jumping for the first time in a system is perfectly normal.

Euhm, I checked my settings, and I don't preload the textures o_O Didn't know it was disabled by default.

EDIT: I do still get random freezes though, when I did enable the preload textures, I'll try and get a freeze in a /dp command.
EDIT2: Got a freeze but crashed this time, sent ya the log.
EDIT3: /dp makes you crash?

If my client freezes on autopilot then the character misses it's destination by 3k. Autopilot doesn't work when the client freezes

Would it be helpful to know that this is happening on a tablet with no graphics card? When I came back from Japan my computer had to be shipped, and my tablet was able to single client fine, when the patch hit is when it started acting up though.

But yeah, did not know about the /dp thing, I will try that when I am next on.

dp shouldnt make you crash but if you sent the dmp that crash should be fixable.

Had a look at the crash and its pretty interesting, dp didnt directly cause the crash but dp force the gpu to complete its work right away instead of queuing up tasks (so that i can see which part are causing loads in it). So this could mean that its crashing right away on what normally cause the freeze because now the "freeze" would happen in the process instead of inside a "thread" in the driver. I'll have to do some tests with that but at least now we might have a way for a debug client to provide extra data.

edit: if you could send a few more of the dp crash from the freeze, it would help me confirm a few things ill need to know before i can write a proper debug client.

tablets have gpu too, altho most call it an apu, its just that the gpu is in the same chip as the cpu. Functionally speaking its the same, just use a little bit less power and can share some hardware with the cpu.

That's cool, I'll do that later today then.

thanks for the data, i have enough to write a beta client that should get us closer to pinpointing the freeze source. It will be released as soon as available