Updated GWA2

[list comprehension]

Originally Posted by CoderAndy

@

just wanted to be sure, all the packet headers that you posted are correct ???

From minimal testing/glancing they look good, although some bots may use different naming schemes for the header constant much like gwca.

[logicdoor]

Originally Posted by CoderAndy

@

just wanted to be sure, all the packet headers that you posted are correct ???

They are correct with all updates, though I have not tested some of the lesser used ones to see if they are broken. I have compared them with Phat's and we are all aligned.

I also aligned some of the variable names, there were some mild variations and I picked the variation that is actually used in the GWA2 API (skilbar vs. build, skill use vs use skill, etc.).

I documented the changes if that's useful . I went with the previous I had (for all except "call Target" as there was an issue in Phat's file, 0x26 was correct), as those were working for me.

[Myolnir]

Hi Guys i am new to Coding but wanted to write simple code where one account is the main account which calls the targets and the other account will target the called targets and will cast some spells on it. When the target is killed the second account needs to go idle again and wait for a new target to be called.

In the gwa2 i found a useful function in the targeting section: targetcalledtarget(). But somehow it doesnt work. Does anyone has an idea how to work around it ?

Thanks so much in advance
Love the activitiy in this forum.

[smiley232]

Originally Posted by Myolnir

In the gwa2 i found a useful function in the targeting section: targetcalledtarget(). But somehow it doesnt work. Does anyone has an idea how to work around it ?

I just tested it and did work as intended. Did you test what happens if you use TargetCalledTarget() by hand? Make sure, the function is up to date:

;~ Description: Target the called target.
Func TargetCalledTarget()
	Return PerformAction(0x9F, 0x1E)
EndFunc   ;==>TargetCalledTarget

If it still does not work, you might check if PerformAction() is broken. You should have a look at 'CommandAction' then.

[smiley232]

The gwa2 I am using contains exactly what you posted and it does work for me.

[phat34]

Teqatle forgot to translate the last Spanish letter... lmao!

[spartanfbj]

I've scanned through this thread pretty thoroughly over the past few days, and I've seen some mention of debugging and developing practices that were really helpful. I'm coming back to Guild Wars mainly to fix up some bots as a hobby. My main issue is debugging without crashing the Guild Wars client.

What do you guys do to debug issues? Some type of interface between the script and the client to prevent fatal errors? I'm a developer by trade but pretty new to AutoIt scripting outside of manually fixing and improving bugs and UI's.

Edit: Realized that I had made a similar post about this a year ago that was answered by Rifle. I'd still love to hear any suggestions if anyone has any.

[list comprehension]

Originally Posted by spartanfbj

I've scanned through this thread pretty thoroughly over the past few days, and I've seen some mention of debugging and developing practices that were really helpful. I'm coming back to Guild Wars mainly to fix up some bots as a hobby. My main issue is debugging without crashing the Guild Wars client.

What do you guys do to debug issues? Some type of interface between the script and the client to prevent fatal errors? I'm a developer by trade but pretty new to AutoIt scripting outside of manually fixing and improving bugs and UI's.

Edit: Realized that I had made a similar post about this a year ago that was answered by Rifle. I'd still love to hear any suggestions if anyone has any.

Types of errors:

1. If its purely a script issue use console messages or output to the gui at every stage of a function printing important values.

2. If its a 007 error and you can reconnect potentially that is caused by performing packet based actions too quickly or malformed packets.

3. Actual gw client crashes are generally from reading/writing invalid memory regions or calling a function improperly or with wrong address.

Debug Technique by error type:

1. verbose script output to look for invalid values or incorrect logic branches while observing the bot. A lot of bots have a function "Out("message") that displays on the gui you can use.

2. Invalid packet header so check it against a known working bot or toolbox's header constants. If your using a packet not listed in those or invalid you can attach ollydbg, immunity, or x32dbg among other dynamic debuggers. Then set a break point on the send packet function that you can find using a byte array pattern from toolbox or find it on your own from tracing back the winsock send function used by the game. Once you have found the packet function right before encryption as it is fully formed minus encryption set a silent logging break point to log the registers and stack parameters to check for header, size, and content. You can also just do a normal breakpoint and manually inspect the stack. To trigger these breakpoints you take the action in game minimizing other actions if possible. Takes some trial and error.

3. Hard crashes stem generally from invalid function calls or memory access so use verbose logging of your script to find the general function or area that crashes the client. Then what you can do is look at what internal engine functions are used by that gwa2 function for example.

3.a. Now that you have some idea of the internal causing the crash you can start debugging it with a few different tools. If it is an invalid memory access being read/write you can check this using cheat engine, reclass, and many other tools to find the data structure in live memory that you are currently accessing to make sure your base address and offsets are correct along with data type. It is also worth doing an array of byte search to confirm your byte pattern is correct for finding the base pointers to the structs your having issues with in this type of crash.

3.b. If it is a function based issue it could be a few things, invalid byte pattern/address to the function, incorrect parameters or call type, in the case of hooking you may not be restoring registers properly, or finally another common one would incorrect thread context. With out digging heavily into thread context switching and process layout you basically want to hook a function that is called a lot and in the same thread as the function you are trying to call.

This is seen easily in toolbox where they hook a gameloop and all functions calls are queued up to be executed in that threads context. Sometimes it is merely enough to inject a .dll or shell code with createremotethread and call but most of the time you need to hook into a game thread for your calls to function because of things like thread local storage.

3.c. So how on earth do you test this stuff? Easiest way imo is to make a simple C/C++ .dll inject that with one goal of hooking the game thread and calling your intended function from it once with console output for feedback. This is more a testing stage but you can also save a lot of time mapping out call type, parameters, call tree, and signatures using static analysis like IDA pro or ghidra.

This is kind of a simplistic overview but in a tl;dr:

Script issues: print debug messages

memory issues: dynamic analysis like cheat engine or reclass to make sure it maps out

Function issues: confirm patterns in static analysis, call type, parameters, and build a test .dll.

I hope this helps at least a little bit.

[cortexio]

While talking to logicdoor, we noticed GetEffectTimeRemaining() wasnt working. It seems that currently it just returns the Duration of an effect. I have a fix. It's kinda messy because it uses a hook now, while it didnt need one before. So maybe there's a simpler solution, but here's mine if u need it.

Func CreateSkillTimerHook()
    _('SkillTimerHookProc:')
    _(' -> 2B C8 8B 57 0C')
    _('push eax')
    _('mov eax,[edi+0x14] -> 8B 47 14')
    _('mov dword[SkillTimerValue],eax')
    _('pop eax')
    _('ljmp SkillTimerReturn')
 EndFunc

Comment out old mSkillTimer

;$mSkillTimer = MemoryRead(GetScannedAddress('ScanSkillTimer', -3))

    $mTraderCostValue = GetValue('TraderCostValue')
    $mSkillTimer = GetValue('SkillTimerValue')   <----- NEW
    $mDisableRendering = GetValue('DisableRendering')

    _('TraderCostValue/4')
    _('SkillTimerValue/4')  <--------- NEW
    _('DisableRendering/4')

    CreateTraderHook()
    CreateSkillTimerHook() <----- NEW

    $lTemp = GetScannedAddress('ScanTraderHook', -0x2F)
    SetValue('TraderHookStart', '0x' & Hex($lTemp, 8))
    SetValue('TraderHookReturn', '0x' & Hex($lTemp + 5, 8))

    $lTemp = GetScannedAddress('ScanSkillTimer', 0x11)      <--- NEW
    SetValue('SkillTimerHookStart', '0x' & Hex($lTemp, 8))      <--- NEW
    SetValue('SkillTimerReturn', '0x' & Hex($lTemp + 5, 8))      <--- NEW

    $lTemp = GetScannedAddress('ScanDialogLog', -4)

U will also need a new case in the ASM function (same as for trader quote fix). Sorry, but it's just easier for me ^_^

Func _($aASM)
	;quick and dirty x86assembler unit:
	;relative values stringregexp
	;static values hardcoded
	Local $lBuffer
	Local $lOpCode
	Select
		Case StringInStr($aASM, " -> ")
			Local $split = StringSplit($aASM, " -> ", 1)
			$lOpCode = StringReplace($split[2], " ", "")
			$mASMSize += 0.5 * StringLen($lOpCode)
			$mASMString &= $lOpCode
		Case StringRight($aASM, 1) = ':'

And finally in GetEffectTimeRemaining() , use:

Return DllStructGetData($aEffect, 'Duration') * 1000 - (GetSkillTimer() - DllStructGetData($aEffect, 'TimeStamp'))

[cortexio]

@ , interesting ^_^ seems alot easier than mine

[deroni93]

Is anyone aware of a past or present Stygian Vale bot?

I'm about half way into building one from scratch but I'd rather not invest more time if there's already one that works.

I'm open to sharing the source if anyone wants to help finish it but I'd rather not publish something half baked.

Progress so far;

- Functional GUI and initialise (copied from the Vaettir bot, needs tweaking)
- Starts at GoA, exits outpost.
- Safely paths to quest giver, perhaps too safe, I'm not sure if it's possible to run directly to the quest giver, it sleeps for ~16s to let the group on the right move out of the way.
- Accepts quest + takes buff then moves to the safe spot
- Starts pull from the glitch location. *this needs tweaking
- Starts kill sequence once the enemies are balled, needs some refinement for sure.
- Only loots gemstones at the moment
- Attempts 4 waves, or until death

It uses the Me/A build on PvX

[ooklaba]

anyone else having issues with memory and the salvage function? errors 007 disconnects. tried playing with sleeping large amounts + ping, only solution seems to be very large amounts, which can end up taking about 3 minutes to salvage an entire inventory.

thanks.

[list comprehension]

Originally Posted by deroni93

Is anyone aware of a past or present Stygian Vale bot?

I'm about half way into building one from scratch but I'd rather not invest more time if there's already one that works.

I'm open to sharing the source if anyone wants to help finish it but I'd rather not publish something half baked.

Progress so far;

- Functional GUI and initialise (copied from the Vaettir bot, needs tweaking)
- Starts at GoA, exits outpost.
- Safely paths to quest giver, perhaps too safe, I'm not sure if it's possible to run directly to the quest giver, it sleeps for ~16s to let the group on the right move out of the way.
- Accepts quest + takes buff then moves to the safe spot
- Starts pull from the glitch location. *this needs tweaking
- Starts kill sequence once the enemies are balled, needs some refinement for sure.
- Only loots gemstones at the moment
- Attempts 4 waves, or until death

It uses the Me/A build on PvX

Check the 2019 bot thread. There was a public one that used the safe spot to farm the first few waves. I am sure it is outdated and broke now but would be fairly straight forward to update with a newer gwa2.

[ooklaba]

has anyone else experienced IdentifyItem() not working in certain areas?

doesn't crash or freeze or fail, the script simply cannot execute/stays stuck on the action.

it works fine in some areas, not fine in others.

[wolf_of_the_north]

Originally Posted by ooklaba

has anyone else experienced IdentifyItem() not working in certain areas?

doesn't crash or freeze or fail, the script simply cannot execute/stays stuck on the action.

it works fine in some areas, not fine in others.

I haven't seen it not work, but if it doesn't work in an outpost you are accessing your farm area from, you could try to travel to your guild hall/an outpost where it works and do your item processing there.

personally i like to use the gh island of the dead, it also decreases the exposure time of your bot to other players in an outpost. this requires of course that you have a separate bot guild, but it's quite cheap for the safety (i think) it provides.

Originally Posted by deroni93

Is anyone aware of a past or present Stygian Vale bot?

I'm about half way into building one from scratch but I'd rather not invest more time if there's already one that works.

I'm open to sharing the source if anyone wants to help finish it but I'd rather not publish something half baked.

Progress so far;

- Functional GUI and initialise (copied from the Vaettir bot, needs tweaking)
- Starts at GoA, exits outpost.
- Safely paths to quest giver, perhaps too safe, I'm not sure if it's possible to run directly to the quest giver, it sleeps for ~16s to let the group on the right move out of the way.
- Accepts quest + takes buff then moves to the safe spot
- Starts pull from the glitch location. *this needs tweaking
- Starts kill sequence once the enemies are balled, needs some refinement for sure.
- Only loots gemstones at the moment
- Attempts 4 waves, or until death

It uses the Me/A build on PvX

like list comprehension said there is one in the 2019 thread, it does however use the me/r version which requires some eotn pve skills and only farms the first 2 waves.