OK, so after full reinstall and updates the bot works for a little while then logs ou

The bot has a major problem with patrolling mobs. It will just stand there and not chase after it causing the bot to stand there and do nothing but target the patrolling mob and then eventually log out due to inactivity.

If the bot does not attack something within 10 seconds it should cancel target and move to the next hotspot. This 1 bug is causing me to baby sit my bot the most, make this priority number 1.

 

Bot started to progressively make slower and slower decisions on moving to new hot spots or targeting a new mob after a battle until it just stopped and stood there not doing anything. The speed of Battle abilities being used while fighting were unchanged during this time leading me to believe this is bot related and not to do with my machine otherwise the battle abilities would have slowed progressively also.



Download 2012-11-11 06.37VMmachine.rar from Sendspace.com - send big files the easy way



Restarting swtor and the bot has removed this problem until this slowness will begin again. Another thing making me babysit this bot. Needs to be fixed.

 

i will forward it to our developers.

 

Thanks for the reply but please forward this entire thread to your developers

 

My basic assumption is this bot is good for maybe 2 - 4 hours before you are logged out or less if you get the patrolling mob bug. The bot not attacking patrolling mob issue should be easily fixed and is a super major pain in the ass making babysitting this bot a must. You cannot leave your computer while this bot is running.

 

Bot decided to stand in the middle of 3 mobs and stood there and done nothing. Before it died I decided to move 1 step and the bot reactivated its combat routine and killed the mobs as normal. - Needs fixing.

 

Bot casts whirling strike melee attack several times while no mob even the mob that is targetted is even remotely in range, after wasting its force power will run to the mob it should be fighting and start attacking.

Consular shadow class.

 

thats the plan.

 

forward this post by chinajade, very big problem right now

http://www.thebuddyforum.com/buddy-...er-questing-useobject-corners.html#post858299

 

One thing I would like to mention to help the developers is While having these problems my settings were:

Plugins: 0 used after finding out there was a bug with lockbox
Info Dump: Log level Normal
Settings: Mount Auto detect -- Sell Item Quality Prototype -- Combat Routine WingIt
And a custom grind profile that has no errors and works fine.



I am currently testing all of these settings again but using the Default Combat Routine instead of WingIt.

 

Seemed to be having better success with the default combat routine but have not had very long to test it yet and now the login servers are down :/


One thing I have noticed about the default combat routine, it does not use Guard on my compnion like WingIt does

 

No problems at all, Deadlybot. If users report anything that can be used to make WingIt better that's good for us all. If a problem can be identified, and we get the opportunity to concisely describe the problem to a Bossland developer, we all win.

As to the log you've attached, we find this:

[01:48:20.414 D] Failed to ReadProcessMemory
[01:48:20.424 D] at GreyMagic.ExternalProcessMemory.ReadBytes(IntPtr address, Int32 count, Boolean relative)
at ..
()
at ..()
at Buddy.Swtor.Objects.TorObject.()
at .
.
()
at .
.
[
](UInt64 , HeroType )
at Buddy.Swtor.Objects.TorObject.GetField[T](DomFieldIds field, HeroType forcedType)
at Buddy.Swtor.Objects.TorCharacter.get_Health()
at Buddy.Swtor.Objects.TorCharacter.get_IsDead()
at Buddy.Swtor.Objects.TorNpc.get_IsLootable()
...<snippity-snip>...​

There were several GreyMagic errors in your log. The GreyMagic errors are caused by Buddywing not being fully hooked into the SWtOR client. They cause all kinds of wicked-nasty things to happen. All bets are off for proper bot operation once the first GreyMagic error occurs--they can cause slowdowns, erratic behavior, or outright crashes. Something bad will happen after a GreyMagic occurs--its simply a matter of time as to when. (A GreyMagic error is isomorphic to dereferencing an invalid pointer in a normal programming language).

When a GreyMagic error happens, your only recourse is to restart both SWtOR and Buddywing and try again. I know of no other work-around. Whether you choose to do that immediately, or just wait until the 'bad thing' happens is up to you.

Again, this log file has several GreyMagic errors in it. We can't expect proper bot operation until we make the GreyMagic errors go away. Perhaps, there is some settings in your VM that need to be tuned? I don't do gaming via VM, so can't help you, but know there are several others here that do.

And again, more GreyMagic errors. I've had a few GreyMagic errors over the course of time, but its only a handful in the course of months. I'd love to know why your machine so readily produces these.

Once again, we can't begin to address any other problems until we make these errors 'go away'.


cheers,
chinajade

 

I am currently using windows 7 ultimate 32bit - 4 gig of memory - 2 processors and 4 cores and 50 gig HD space for my Virtual machine. Do other use Windows xp with sp1 as the Virtual machine ?


edit: And also, these grey magic errors seem to occur alot more frequently with WingIt. Since using the default combat these errors have become noticeably less. Although the default combat logic dose not match WingIts

 

OK, the same major problem I am having using the default combat routine is the exact same as I was having with WingIt. Patrolling mobs eventually make the bot stand still casting force speed over and over and over and not moving. Please is there some code I can insert into both WingIt and the Default combat routines to make the bot move to the next hotspot if combat does not occur within 15 seconds of the bot targeting a mob ?

I am willing to test this and give feedback in return. I believe this is what this grey magic you speak of is coming from.

 

Hi, Deadlybot,

I'm really sorry you're having these kinds of problems. GreyMagic is a fundamental library used by Buddywing to access SWtOR memory. There are absolutely no corrections that can be made at the WingIt or DefaultCombat level to repair or work-around the problem. Buddywing is simply not fully hooking into, or becoming unhooked from, your SWtOR client.

If you're desperate enough, can I get you to try your BW/SWtOR setup on the native hardware (outside the VM) to see if the problem will go away?

Another alternative is to comb the forums for fellow VMware users and see if you can get one to help you. (Although, I'm not absolutely certain the problem is VMware, I've a strong suspicion that's where we should be looking).

The last alternative is to get a BWcore developer to work with you on isolating the issue. GreyMagic errors should never happen to anyone, and they may be willing to work with you to isolate the problem. Alternatively, they may just say that VMware is 'not supported', and leave it at that. If you choose this route, I'd start by contacting Tony through Honorbuddy Support, and see if he can arrange something.

cheers,
chinajade

 

This is happening right now on my native hardware outside of VMware. And again it is a patrolling mob, the bot is sitting there casting force speed over and over not moving.

So there is no way to make an if then statement to make the bot just move to the next hotspot after say 15 seconds if combat is not begun with a newly selected target ? This is the only thing right now preventing the bot from working in a reasonably stable way.

edit: Oh wait. he moved off after casting forcespeed about 10 times. Still, the problem lies in patrolling mobs.

 

Toss the log so we can have a look, please. No way to diagnose a problem, if you can't see it.

cheers,
chinajade

 

Download 2012-11-12 01.49.rar from Sendspace.com - send big files the easy way <--- log file



Casting Stealth <---- Bot window messages. While the bot is doing this it is standing completely still and it is ALWAYS targeting a moving mob -
Casting Force Speed patroling mob - walking mob whatever you like to call them.
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed



Casting Stealth
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed

Casting Stealth
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed
Casting Force Speed

 

After looking through the log myself and having no experience coding what so ever am I right in saying that it is detecting the mob, finding its position, asking your server how to get to that position, checking the mob, finding it is not there, finding its position, asking your server how to get to that position, checking the mob, finding it is not there asking the server how to get to it's new position repeat repeat repeat ? Thus creating a looping type situation ? where the bot is always thinking instead of doing ?

If this is the case can it not be recoded to do this a maximum number of times before moving to the next hotspot in a profile ?

 

Hi, Deadlybot,

Your analysis is absolutely correct, and codified by lines that look like this:

[06:34:56.282 D] Generating path to Target Position <-210.2919, -5.070118, -78.62606>
[06:34:56.332 D] Raycast path generated.
[06:34:56.332 D] Generated path to <-210.2919, -5.070118, -78.62606> (Target Position) with 1 hops.
[06:34:58.483 D] Generating path to Target Position <-210.621, -5.041191, -78.6165>
[06:34:58.533 D] Raycast path generated.
[06:34:58.533 D] Generated path to <-210.621, -5.041191, -78.6165> (Target Position) with 1 hops.
[06:35:00.749 D] Generating path to Target Position <-210.9601, -5.012644, -78.60664>
[06:35:00.799 D] Raycast path generated.
[06:35:00.799 D] Generated path to <-210.9601, -5.012644, -78.60664> (Target Position) with 1 hops.
[06:35:02.966 D] Generating path to Target Position <-211.2918, -4.99821, -78.59699>
[06:35:03.016 D] Raycast path generated.
[06:35:03.016 D] Generated path to <-211.2918, -4.99821, -78.59699> (Target Position) with 1 hops.
[06:35:05.002 D] Generating path to Target Position <-211.5886, -4.984868, -78.58836>
[06:35:05.015 D] Raycast path generated.
[06:35:05.015 D] Generated path to <-211.5886, -4.984868, -78.58836> (Target Position) with 1 hops.​

Superficially, this looks like a BW bug. The MoveTo() in line 22 of DefaultCombat's Kinectic.cs file causes the raycast path to be generated and it should follow up with a move action, but it doesn't. From this, we know that DefaultCombat is trying to do the right thing, however something is not working at a lower level.

We say 'superficially' because as long as you've GreyMagic errors in the log, BW development is going to reject any other problem reports until those errors are cleared up. As, any problems encountered can easily be attributed to GreyMagic errors. Since the errors occur so early in your log file, the failure mode could literally take any form.


One other thing to clear up...
The references to "your server". I've never been a member of the Bossland GmbH staff--I'm just a normal user like you that likes to help fellow users when time allows. Please don't mistake me for some sort of BosslandGmbH/Buddywing representative.

cheers,
chinajade