Moderator: MacroQuest Developers
Yeah thatkaz wrote:the only way to fix these without using detours would be for instance to write a 2nd program with its own interface window that you typed into and that tried to read eq's memory and show you what you wanted.
Freeze, or deathly lag out EQ for the second or so the memory reading takes... Like GrabIt for D2 except you would need to find an external way to do it since it also uses hooks and DLL Injection.kaz wrote:the problem there is that mq reads all that data while in a detour so its access is sync'd but if you tried to access that data from say a 2nd program you'd have memory consistancy issues to deal with.
true, but that has nothing to do with the SMURFING CODE! the detour injection happens where you can easily figure out and add one line of code to make your command a part of MQ and then simply understanding the way the structs are together so you can make it do things. same with adding variables. If you wanted to make it still work in MQ then that can be said as easy (i htink maybe) as well, simply type in yer /command then hit a character code that doesn't exist in font (alt+b) I don't know hwo EQ handles it but there is apossiblility there is now a 0x01 after /command, so the 2nd party app searches for the text in teh box and fins /command + 0x01 and vwalla, you have a "working" mq thing. *sighs*Lifewolf wrote:all custom mq commands rely on the use of detours