Updated the MercHelpers.cs, UpdateTarget() function - and ran through tests with my Merc - not seeing the issue now - let me know if any further issues on your end. Thanks Joe
Hey Joe, How hard would it be to make DoRandomGrind work for my shadow, but keep my shadow combat scripts intact which are using the original defaultcombat ? hmmm how can I word that better. Is there any way I can use DoRandomGrind without changing how my shadow combat scripts work right now while using Buddywings default combat ? Fuck I still am not sure I am saying what I should be in terms of how you would understand it in a coding sense. Let me try one more time. My shadow is using a modified combat routine with buddys defaultcombat and it rips shit up. How can I keep it working the exact same but have it DoRandomGrind ? Is it possible ? Is it easy for me to do ? Also the scavenging and bio ? I am going to have a look at them myself but where I could sort of understand the normal default combat and routine code and kind of fumble my way through I do not know if I could do that for yours.
In MercHelpers.cs: Called in RunAroundAndKillStuff() - Driven by the DoRandomGrind flag ScanForPlaceables() does the node-scanning it's driven by the flag up-top in MercHelpers, ScanForNodes (set to either true or false, if false, the node-scanning will be skipped in for DoRandomGrind). ScanForMobs() does the mob-finding and initiates combat. For a Bodyguard, for example, BGCombat() runs the actual combat. At a higher level: 1. Modify ScanForMobs to check your advanced class (BuddyTor.Me.AdvancedClass==AdvancedClass.SorcererShadow - or somethin like that) and call your combat routine if the adv class makes a match. 2. Add in your Combat routine/PrioritySelector of course. 3. You'd be bypassing the variables I use (TD for target distance, THP for Target Health Percent, etc) I load (I set up vars to try and eliminate most of the repeated polling that goes on - just makes more work for the app and in my opinion adds to instability) Another option for (3) - just create another void combat routine like the rest - ShadowCombat() - that would get called in (1) - using the same method I did for the others. If you've already customized your own using the Default - I'm guessing you can figure it out. If you DO create another void for Shadow Combat (which would be my suggestion ) - let me know and I'll incorporate it into the 'release set'. Thanks for the interest! Joe
Ummm Joe, I can see what you are saying in the file you are talking about but I have no idea how to code and basically have no idea what to do.
For some odd reason, ever since the last update, forcing tree 3 isn't working for me anymore. Apparently it decided to override the whole section instead -_- Win8 is being unfriendly atm. On the other hand, everything else is working brilliant. Cuts a lot of down time, and my trooper is finally healing without having a touch of the downs. I look forward to whatever else you can dish out, its a beauty.
Thanks for the feedback and comments, very much appreciate it So far as the tree - will see if I can dig anything up that will alleviate that. If not, maybe I'll PM Tony or Aevitas to see if anything can be done on the .exe side. Joe
Hi im wondering if its possible if you could look into a juggernaut routine loving the others so far.
I probably won't have any more time to play until Monday, but just wanted to let you know that last night there were many fights (especially when I was using the CombatBot) where for my Sniper Marksman she would just sit there only doing "Rifle Shot" and maybe some of the AE abilities. Even when it was doing the full rotation, I never saw it do Shatter Shot, which is a pretty big DPS drop. Still, It is nice to see a very responsive routine for Combat, tho. Attached is my log from last night. There is a LOT of starting and stopping (plus some Quest bot thrown in), but maybe it'll give you some insight. Also, can you explain how the logic of the block of If statements works for choosing which ability to cast during combat. I'm not much of a coder but I can follow logic pretty well. It seems that it's a line of If statements where if it fires off that line it breaks out of the loop and starts again. My question is what determines when to fire off one of the If statements when it has no parameters?
It's basically a 'waterfall' - or a priority list. The higher-priority-casts are above, and lower, below. As soon as it hits a spell it can cast, it will 'break out', return, and the .exe will call the combat routine again, until combat is complete. So far as the Rifle-Shot - it's related to GrayMagic and errors (Me.IsCasting gets bugged, along with a plethora of other issues at-the moment, many of which ChinaJade can't take anymore and I honestly don't blame her. The Rifle-Shot you REPEATEDLY see running is a 'forced cast' - that tries to deal with GrayMagic errors, along with a faulty IsCasting (and CanCast) flag (that has also gotten worse as of late) - it's ignoring the Me.IsCasting flag, to make sure you get 'any cast off' during that iteration of the fight. I'll look into it to see if there's anything (else) I can do on it. Basically GrayMagic (synching?) issues, that have gotten ALOT WORSE, as of late from what I can see. BuddyWing, is a Red-Headed-Stepchild - in all honesty all they're doing with it at this point is basically verifying to some point that it DOES work, even if it's crashing/hanging every few minutes. BuddyWing is still far beyond any bot out there for SWTOR from what I can see, but lately, it's almost unusable. My thinking is from a business perspective, no subscribers, not much love. But on the other end, if your product ALWAYS WORKS, maybe you'll get more subscribers. Error Example: [05:49:48.095 D] TorNpc.Name Exception System.NullReferenceException: Object reference not set to an instance of an object. at Buddy.Swtor.Objects.TorObject.() at ..[](Boolean , String , Object[] ) at Buddy.Swtor.Objects.TorObject.CallScript[T](Boolean hasReturnValue, String function, Object[] args) at Buddy.Swtor.Objects.TorNpc.get_Name() (Along with any other scans for 'magic' errors you do in your log, should be plenty of them) Sorry for the dissertation. ANYHOW. I've added a bunch of sleeps throughout the code to try and let GrayMagic 'get out of the error vortex' - will post those within a few minutes. Joe
Thank you for the dissertation. I actually understand what you are saying. I'm going to try out the updated version and see what happens.
Just posted another update to try and deal with object reference errors - was working on isolating the specific cause. Although the error seems to be 'posting as' occurring in BotMain (the .exe) - just for the hell of it - I tweaked the 'object query code' to use a variable vs. doing it dynamically - and seems to be a little more stable. SO, the update I just posted, you may want to try and download on. In short, it's code that worked fine prior to the last release, but as of late.... seems to behave a little differently - maybe due to the latest release, maybe not, I'm just trying to see what works, now. Joe
So far it is working *much* better. The only thing I run into is that you may want to put in a slight pause when you are starting the pull code when you're coming off of a vehicle. I'd say about 6-7 times out of 10 it'll try and fire Ambush off, but because of some minor movement between the dismount/crouch combo it'll abort Ambush and then continue on into the main loop code. Missing that Ambush can be a pretty large damage drop.
Just posted another update, to add in additional calls to Ambush on the pull (and I also increased the 'lag' between rotation-steps).
Geez Joe, you should take over CR making. Your work is damn flawless. BH is amazing in either spec, marauder finally doesn't look like a moron running around, and if my Jedi Guardian was a Sith Jug, I bet that would be incredible too.
Joe, thanks so much for your hard work! You're new code seems to have made the bot a lot more stable. The reduced errors finally make this bot useful and my marauder is finally slaughtering people!
