RebornBuddy Forums
Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
[PAID] [Fly][N-QB]Time-Lost Proto Drake Farm[Maffyx]
- Thread starter Maffyx
- Start date
-
- Tags
- 23-sept-2015 author bors breath brunn bugs buy date distance fall farm future ground hotspot/spawn http://i.imgur.com/ffkfwfw.png http://www.gettyimages.ca/corporate/licenseagreements.aspx#rf http://www.wowhead.com/item=44168/reins-of-the-time-lost-proto-drake http://www.wowhead.com/npc=32491/time-lost-proto-drake included information item kill license location locations mob navigation necessary[/] northrend obtained original pathing patrol picture plan plans product profile proto-drake ravine reins spawn storm support thread time-lost tricky ulduar village
Way to go man.
My night campers got results this morning. Woke up with a Vyragosa alert in wow. Ingame combat log says I killed, but no loot. Upon further inspection HB log says it couldn't generate a path to looting area.
Sugestion:
Since this has happened to more people, and okay ofcourse you can always contact a GM to get loot, but still, could you please edit the profiles to make use of Findle's Loot-A-Rang when this item is in your inventory?
http://www.wowhead.com/item=109167/findles-loot-a-rang
Why do you even care if you got the mounts if it was banned? I don't understand.
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
Resubmitted the update for approval:
[TD="bgcolor: #CCFFFF"]Waiting for Code Approval[/TD]
| 1.3.6 | Release |
| 12/10/2015 11:19:16 PM |
[TD="bgcolor: #CCFFFF"]Waiting for Code Approval[/TD]
View attachment dk_nothing 1900 2015-12-11 08.48.txt
To clarify: It's almost as if my character was glued to the spot he was standing on. Manually changing the way your character is facing while the bot is active, is impossible. The bot will change back the way it was facing in a very spiky & glitchy way.
To clarify: It's almost as if my character was glued to the spot he was standing on. Manually changing the way your character is facing while the bot is active, is impossible. The bot will change back the way it was facing in a very spiky & glitchy way.
Last edited:
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
I'm sorry to hear that, really strange how it's only happening to you!
I took a look at the log and it can't navigate to Vyra, so I'm assuming it's trying to melee it as the pull? Is this a fresh install, and do you have any other characters than a death knight to test this with? The bot will try it's hardest to face the target to pull it, but if it can't navigate to it, it will just stand still and rotate.
Try using another class and let me know what happens!
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
Lol well the other guy got his with a Rogue, so we'll see how it goes! Good luck!Allright, my daycampers are busy now. Rogue and Druid, both melee though
View attachment dk_no_target1444 2015-12-11 22.27.txt
Dk didn't target again during the night shift. Had a vyra spawn.
And yes it's a clean install... afaik Dk's can do ranged pull right ? The above code from HB log looks really buggy. The profile bugs even before he tries to pull, cause he even struggles with targetting in the first place.
PS: made my druid spec moonkin so he's ranged now. OP, do you advise people to use ranged classes to camp?
---
edit: My daycampers got a result! Rogue made a Vyra kill at Brunnhildar village! Didn't loot though (still got to get all my chars that loot-a-rang. My rogue is melee so here's the log how he made that kill. Looking at the log my rogue did a lot of failed attempts to engage combat before he decided to use Shriken Toss (ranged).
View attachment rogue_4136 2015-12-12 07.28.txt
Sugestion:
Can you add a default (ranged) opening attack for each class that overwrites the default combat routine? That way the characters don't have to struggle trying to find a melee route first, during which time Vyra/TLPD will fly only further away. Having a (ranged) default opening attack will probably prevent some of the current bugs from occuring again. (pretty sure this is possible!)
Also:
It might be a good idea to remove the code that forces your character to face a certain way during idle camping. Based on several monitored camps, I've got a feeling this is interfering with the code that's being used to face Vyra/TLPD when a spawn occurs.
Looking forward to hearing from you Maffyx. Still very much appreciate all your effort.
Dk didn't target again during the night shift. Had a vyra spawn.
Code:
00:28:10.977 D] Exception was thrown in BotBase.Root.Tick
[00:28:10.979 D] Buddy.Coroutines.CoroutineUnhandledException: Exception was thrown by coroutine ---> Buddy.Coroutines.CoroutineUnhandledException: Exception was thrown by coroutine ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Bots.Grind.LevelBot.(Bio-RV/x{IlUN/sZv:va8\[`!.***************()
at Buddy.Coroutines.Coroutine.X/HZG\&!y^<j0"FoFj|3a#)nr.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Bots.Grind.LevelBot.biw2l\[\\vG\]DtTqLD\&~Rr6Uz\*.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Bots.Grind.LevelBot.$eT"!\*Rp<=<2dwO{B>S\]`~ef.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at r}UI NHt?l%^g{f)5!g`_Q\,f0.)8w;/VjSQ#i:%)\[O#80<;P(p'.j<9KXP"\.\]9NvBN#FLTR=P!\[F.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CommonBehaviors.Actions.ActionRunCoroutine.guXAW bT@el_lb24C4C<Q}\,z.\\Bg1t9RU/zD`2;d7(;iU!W@O'.MoveNext()
--- End of inner exception stack trace ---
at Buddy.Coroutines.Coroutine.************(Boolean )
at Buddy.Coroutines.Coroutine.**********(Boolean )
at Buddy.Coroutines.Coroutine.Resume()
at CommonBehaviors.Actions.ActionRunCoroutine.Run(Object context)
at Styx.TreeSharp.Action.RunAction(Object context)
at Styx.TreeSharp.Action.<--kodOWNA$D6(mC|oPsucvH%.MoveNext()
at Styx.TreeSharp.Composite.Tick(Object context)
at Styx.TreeSharp.PrioritySelector.TflHAPmHugr3yv="B`Y_0-_g.MoveNext()
at Styx.TreeSharp.Composite.Tick(Object context)
at Styx.Common.HookExecutor.Run(Object context)
at Styx.TreeSharp.Action.RunAction(Object context)
at Styx.TreeSharp.Action.<--kodOWNA$D6(mC|oPsucvH%.MoveNext()
at Styx.TreeSharp.Composite.Tick(Object context)
at Styx.CommonBot.Coroutines.CoroutineCompositeExtensions.Lo(xT'"s\&Ddmb {:O7GF\*1Gd#.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at r}UI NHt?l%^g{f)5!g`_Q\,f0.)8w;/VjSQ#i:%)\[O#80<;P(p'.xxl31itI{e<#7z\,UY#Nc\.\*Vt".MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CommonBehaviors.Actions.ActionRunCoroutine.guXAW bT@el_lb24C4C<Q}\,z.\\Bg1t9RU/zD`2;d7(;iU!W@O'.MoveNext()
--- End of inner exception stack trace ---
at Buddy.Coroutines.Coroutine.************(Boolean )
at Buddy.Coroutines.Coroutine.**********(Boolean )
at Buddy.Coroutines.Coroutine.Resume()
at CommonBehaviors.Actions.ActionRunCoroutine.Run(Object context)
at Styx.TreeSharp.Action.RunAction(Object context)
at Styx.TreeSharp.Action.<--kodOWNA$D6(mC|oPsucvH%.MoveNext()
at Styx.TreeSharp.Composite.Tick(Object context)
at Styx.CommonBot.TreeRoot.(Bio-RV/x{IlUN/sZv:va8\[`!.************()
at Styx.CommonBot.TreeRoot.*******(Action , String , Boolean )And yes it's a clean install... afaik Dk's can do ranged pull right ? The above code from HB log looks really buggy. The profile bugs even before he tries to pull, cause he even struggles with targetting in the first place.
PS: made my druid spec moonkin so he's ranged now. OP, do you advise people to use ranged classes to camp?
---
edit: My daycampers got a result! Rogue made a Vyra kill at Brunnhildar village! Didn't loot though (still got to get all my chars that loot-a-rang. My rogue is melee so here's the log how he made that kill. Looking at the log my rogue did a lot of failed attempts to engage combat before he decided to use Shriken Toss (ranged).
View attachment rogue_4136 2015-12-12 07.28.txt
Sugestion:
Can you add a default (ranged) opening attack for each class that overwrites the default combat routine? That way the characters don't have to struggle trying to find a melee route first, during which time Vyra/TLPD will fly only further away. Having a (ranged) default opening attack will probably prevent some of the current bugs from occuring again. (pretty sure this is possible!)
Also:
It might be a good idea to remove the code that forces your character to face a certain way during idle camping. Based on several monitored camps, I've got a feeling this is interfering with the code that's being used to face Vyra/TLPD when a spawn occurs.
Looking forward to hearing from you Maffyx. Still very much appreciate all your effort.
Last edited:
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
The targeting seems to be a problem with the CR, can't really do much about that on the profile side, seems like Singular doesn't like DK's that much! DK's should be able to range pull, however I don't know what settings you have in that regard with the CR. What addons and plugins are you running?
I would advise people to use ranged classes, just so it has a better chance at tagging/killing the mob first before other people can react.
That's good that something else is killing it, but Brunnhildar Village should have been able to loot it since there isn't a huge drop off anywhere. But again if the bot thinks it can't make it then it will just blacklist it. Unless it fell off the cliff off to the left then it should have been okay to loot. Hard to tell without seeing what happened.
I'll definitely write in a default pull for each class to be safe, I was thinking about doing that earlier but assumed the CR would handle it, but now I see that it is necessary.
I don't have any code that makes the character face a certain way, that is out of my control and is something that is probably related to the CR. This may be why it's not killing it right off the bat since it may be trying to correct its facing and messing up spells/target directions.
I'll work on the class spells right now and will change some other stuff.
Much love, thanks for the reply 
Looking forward to the edits!
Not using any plugins btw, just a fresh install of HB, nothing else.
Edit: my monk just made a kill + loot on his own at Brunhildar Village, atleast that class is working I'd say!
Edit: wow, I have good news and bad. Good news is that my DK made a kill on his own (at Brunnhildar Village) after I decided to spec him unholy. Bad news is that he had pet out, and the pet made most of the damage which prevented any loot to be awarded to the player (me), meaning I couldn't loot it. Direct player damage is necessary for a mob to be lootable.
View attachment dk_petkill1816 2015-12-12 23.12.txt
Sugestion:
Add a piece of code that dismisses any pets and/or guardians for the classes that have these.
Looking forward to the edits!Not using any plugins btw, just a fresh install of HB, nothing else.
Edit: my monk just made a kill + loot on his own at Brunhildar Village, atleast that class is working I'd say!
Edit: wow, I have good news and bad. Good news is that my DK made a kill on his own (at Brunnhildar Village) after I decided to spec him unholy. Bad news is that he had pet out, and the pet made most of the damage which prevented any loot to be awarded to the player (me), meaning I couldn't loot it. Direct player damage is necessary for a mob to be lootable.
View attachment dk_petkill1816 2015-12-12 23.12.txt
Sugestion:
Add a piece of code that dismisses any pets and/or guardians for the classes that have these.
Last edited:
umshakalaka
Member
- Joined
- Jan 10, 2011
- Messages
- 362
Any chance to make it fly around in the location instead of staying on the ground?
Literally no real player does that (since you can get attacked by opposite faction too easily) + once it happened trying to fly through the ground for me with like 4 other people around, looked extremely bad and got me few bot related whisps in a matter of seconds...
Edit:
doing it right now too, it looks retarded...
We are stuck! (<6820.159, -1791.789, 937.6555>)
We are stuck! (<6818.607, -1793.2, 939.8497>)
We are stuck! (<6822.268, -1792.333, 939.6744>)
We are stuck! (<6819.974, -1791.911, 937.6982>)
We are stuck! (<6819.91, -1791.462, 937.7094>)
We are stuck! (<6820.707, -1790.23, 937.8533>)
We are stuck! (<6820.052, -1791.612, 937.5953>)
We are stuck! (<6818.44, -1791.049, 937.9783>)
We are stuck! (<6820.134, -1791.507, 937.8761>)
We are stuck! (<6820.285, -1791.822, 937.7951>)
We are stuck! (<6820.654, -1793.858, 939.9596>)
We are stuck! (<6819.924, -1791.894, 937.8492>)
We are stuck! (<6820.34, -1790.506, 940.1595>)
We are stuck! (<6821.824, -1791.159, 940.1728>)
We are stuck! (<6820.176, -1791.645, 937.6468>)
We are stuck! (<6821.501, -1791.466, 939.7054>)
We are stuck! (<6820.13, -1791.721, 937.7148>)
We are stuck! (<6820.062, -1791.841, 937.6692>)
We are stuck! (<6818.789, -1792.923, 938.9538>)
We are stuck! (<6819.195, -1793.102, 938.9816>)
We are stuck! (<6819.078, -1793.917, 938.2844>)
We are stuck! (<6821.703, -1790.371, 939.8798>)
Literally no real player does that (since you can get attacked by opposite faction too easily) + once it happened trying to fly through the ground for me with like 4 other people around, looked extremely bad and got me few bot related whisps in a matter of seconds...
Edit:
doing it right now too, it looks retarded...
We are stuck! (<6820.159, -1791.789, 937.6555>)
We are stuck! (<6818.607, -1793.2, 939.8497>)
We are stuck! (<6822.268, -1792.333, 939.6744>)
We are stuck! (<6819.974, -1791.911, 937.6982>)
We are stuck! (<6819.91, -1791.462, 937.7094>)
We are stuck! (<6820.707, -1790.23, 937.8533>)
We are stuck! (<6820.052, -1791.612, 937.5953>)
We are stuck! (<6818.44, -1791.049, 937.9783>)
We are stuck! (<6820.134, -1791.507, 937.8761>)
We are stuck! (<6820.285, -1791.822, 937.7951>)
We are stuck! (<6820.654, -1793.858, 939.9596>)
We are stuck! (<6819.924, -1791.894, 937.8492>)
We are stuck! (<6820.34, -1790.506, 940.1595>)
We are stuck! (<6821.824, -1791.159, 940.1728>)
We are stuck! (<6820.176, -1791.645, 937.6468>)
We are stuck! (<6821.501, -1791.466, 939.7054>)
We are stuck! (<6820.13, -1791.721, 937.7148>)
We are stuck! (<6820.062, -1791.841, 937.6692>)
We are stuck! (<6818.789, -1792.923, 938.9538>)
We are stuck! (<6819.195, -1793.102, 938.9816>)
We are stuck! (<6819.078, -1793.917, 938.2844>)
We are stuck! (<6821.703, -1790.371, 939.8798>)
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
Sorry to hear about the pet issues, I suppose I should make a note on the forum/store that this needs to be done via the CR. Even if I implemented a code to turn it off, it would most likely be turned back on by the CR.
Can I get a full log of this? I need to see where in the profile he resets to to be able to get back to this. What do you mean fly around the area? Just get to a spot and hover or actively move around? What would you like to see here? I'm trying to think of how it would work though, the character would have to land before casting anything. Unless we turn the setting on that casting dismounts automatically?
Would you mind posting a log of this action as well? Just more data helps perfect this thing.
Also:
| 1.3.6 | Release |
| 12/10/2015 11:19:16 PM | 12/11/2015 4:25:49 AM |
[TD="bgcolor: green"]Approved[/TD]
Last edited:
Maffyx
Active Member
- Joined
- Feb 13, 2010
- Messages
- 1,078
That's frustrating, I'm working on a major release atm, hopefully it will be more successful at killing and looting this damn thing.