hi again!
the latest version (17e) made dpyes work indeed but broke Evade button char just jumps in one place instead of moving forward.
Yeah, same here.
DPYes 17f should fix this.
When the current input mode isnât keyboard+mouse, DPYes will not interfere with Evade â regardless of the current âEvade to cursorâ setting.
Is it possible to add a feature where in Teleport_list one can choose the color of the entry ?
Iâm playing on 17f and cannot evade.
Thank you!
Automatic launch is not working for me. I put the winmm.dll in the x64. The âStandard Installâ with running DPYes.exe works though. I am running the latest steam version.
Warning: Thread hijack
Any chance you could give me a crash course in what I need to know to debug his issue?
I donât even know what to google, need keywords, a direction⌠something.
There are numerous reports of users with this issue, yet Iâve never managed to reproduce it myself.
I made IA using IDA Pro, analyzing and hooking. Donât have any experience debugging third party applications written in C(++). Java/.Net dev here, so not my strong side.
Any help is appreciated.
EDIT: If it was not clear, Iâm replying to the windbg post from a month or two ago. Since it seems like you got things under control.
I donât know if this is the cause or even something youâre already doing, but DPYes ran into some crashing issues on character load if it tried to inadvertently check transmutes(illusions) too early. Coincidentally, this is the crash I had open in my prior WinDbg
screenshot.
The fix in that case was to wait until GAME::GameEngine::IsGameEngineOnline(pGameEngine)
To start, youâll need a (mini)crashdump from when the issue occurred, the crashdumps produced by Grim Dawnâs own Crash Reporter should be OK.
Youâll want to be using the exact same version of the Game as the dump is from (build number and Steam/GOG).
Once you have the dump file, you can load it into WinDbg
from GDâs x64
dir. This should help WinDbg
find GDâs dlls.
Once its loaded,
- In the
Threads
tab (bottom right pane in my earlier screenshot), you should be able to double click on the main thread to switch to it - Back in the
Stack
tab you should see stack frames with some symbols from GDâs dlls
Depending on whether the crash actually occurred in your hook code, GDâs dlls or the packed Steam Grim Dawn.exe
will affect how easy it is to see where (logically) the crash occurred.
Was this with KB+Mouse?
DPYes 17h should fix this bug
Auto launch works for me with GD 1.2.1.5
Can you have DebugView
(linked in OP) running and try using auto launch?
Messages prefixed with GDL
are from the auto launch and GDD
from DPYes.dll
.
It should start something like:
[5652] GDL: existCurDir=1, existParDir=0, existx64Dir=0
[5652] GDL: Load 2
[5652] GDD: Hello from DPYes 17f
[5652] GDD: DPYes compiled with MSC 194134123
[5652] GDD: Installed MSVC Runtime Version: v14.42.34433.00
[5652] GDD: Installed MSVC Runtime Build: 34433
I can confirm this happens with controller as well. Around the release of v17 is when the âEvade To Mouse Cursorâ bug happened, and itâs been persistent since. Without that option enabled, even if WASD mode is otherwise disabled, you âdodgeâ in place rather than moving. âEvade To Mouse Cursorâ has to be enabled to dodge normally.
Is this still happening for you with 17h?
Ah, apologies, I thought Iâd already upgraded, but I was still on 17f!
17h does appear to have fixed it, yes. Iâm able to dash around while âEvade To Cursorâ option is disabled in WASD movement, whether using mouse control or controller.
Donât be like me, everyone! Upgrade!
I ran DBGview.exe and when I ran Grim Dawn from steam I see neither GDD or GDL. I then ran DPYes.exe and I see a whole bunch of GDD. Using KB + mouse.
Thanks!
This is really something I should have dedicated time to learning years ago.
9 years into IAGD and still just doing trial-and-error, to see what does and does not crash
Clicking on the threads tab did not yield me much, but the initial stacktrace from the dump pointed me towards ItemAssistantHook_x64!OnDemandSeedInfo::HookedMethod+0x40
I suspect I had a race condition where I hooked GameEngine::Update() but had not yet set the global variable for this
, to access the original method pointer, resulting in a crash.
Iâve found this to be unreliable, a lot of IAGD users have this set but GD still launches as 32bit.
Ended up having to recommend adding /x64
as a launch option.