odds are they are going to tell you to not install to your desktop read 1 of the many compiler error threads in the support forum.
Yup. No desktop. Put on c:\Games delete wingit, install new one from SVN, delete compiledassemblies. blah blah. should be able to find the basic help steps. Or read in guide the sneakymans.
The issue where the Sniper continuously crounches still persists. I think it would be high time to try to fix this since it has been an issue for a long time. / Regards coldIRONy
Found an issue with the Sith Assassin Madness spec where it does not properly detect the "Shocked (Force)" buff on the target and so spams Discharge, instead of just using it to debuff the mob. This is using the current revision #684. I was able to fix this for my toon, by using Code: Cast("Discharge", dischargeWhen => !BuddyTor.Me.CurrentTarget.HasDebuff("Shocked (Force)")), but that's bypassing the mirror system. Also, I don't see any reason for requiring stealth to use maul in the pull section or during combat. Its not a requirement as the only thing that's needed is to be behind the mob to use it. Maybe its in there for another reason? I removed the stealth restriction in both the pull and combat section and its working wonderfully. Thanks for the work everyone has done here. This routine works beautifully. Log attached:
My BH Mercenary Arsenal (dps) is in love with ya! i just logged in the forum just to thank you! you made my char. moves and attack more flawlessly again! after the update on 09/08/12 THANKS AGAIN! now to farm credits again! YAY
Assassin Harnessed Darkness So I noticed the assassin advanced darkness does not have "Harnessed Darkness" buff built in. I wanted to add this buff so that I could tell the bot to only use lightning when harn dark has 3 stacks "heals while attacking" I added the buff to MirrorData.cs under Code: private static AbilityPair[] InquisitorConsular_AbilityPairs = { ... new AbilityPair(new Assassin("Induction"), new Shadow("Circling Shadows")), new AbilityPair(new Assassin("Harnessed Darkness"), new Shadow("Harnessed Shadows")), new AbilityPair(new Sorcerer("Lightning Barrage"), new Sage("Psychic Projection")), ... private static AbilityPair[] InquisitorConsular_BuffPairs = { ... new AbilityPair(new Assassin("Surging Charge"), new Shadow("Shadow Technique")), new AbilityPair(new Assassin("Harnessed Darkness"), new Shadow("Harnessed Shadows")), }; Then I modified Darkness_KineticCombat.cs Code: public static Composite AssassinDarkness_ShadowKineticCombat_Combat() { ... //Rotation Cast("Force Lightning", forceLightningWhen => Me.HasImpliedMirrorBuff("Harnessed Darkness", 3) && MyTarget.Range <= Global.Distance.Melee ), Cast("Wither", witherWhen => !MyTarget.HasMirrorDebuff("Wither") || Me.MobCountAround(Global.Distance.MeleeAoE) >= 3),//name could be wrong Cast("Shock"), ... Now lightning does occaisonally fire, but unfortunately most of the time it does not and my logging shows Field effcharges does not exist, and points at my cast force lightning line (log attached) View attachment 2012-08-05 05.06.txt I've triend impliedmirrorbuff as well as Me.HasMirrorBuffStacks, but I'm not having much luck with either. If you have any tips or ideas, it would be much appreciated. I can also hop on irc if needed. Bob
Hiya, UncleBobby! The AbilityPair to the InquisitorConsular_AbilityPair and InquisitorConsular_BuffPair tables in MirrorData.cs is spot on. I'll try to get that change folded in as soon as the current thing I'm working on finishes up. The other piece you probably are looking for is Me.HasMirrorBuffStacks("Harnessed Darkness", 3). The ImpliedMirrorBuff takes its name from the boolean implication operation, and its use is not obvious, but a frequent pattern for CC writing. Although a frequent pattern, it doesn't sound like what you seek, but HasMirrorBuffStacks() does. The exceptions in the log you provided (and btw, THANKS for the log!), are not normal. You are simply asking if you have a buff on yourself, and its throwing an exception. This is a problem in either the BWcore or SWtOR client, and not much you can do about it. These are the kinds of things we have to work around all the time. There is an alternative way to write those functions that may prevent aggravating the problem. Although what is there is correct, and shouldn't be aggravating the problem in the first place. I'll try to give this a little deeper look in a bit, but I wouldn't hold my breath for success. Apoc recently (within the past week) mentioned he had repaired a number of these type problems, but I guess there are still some outstanding. Hope this sets you on the path. Neo93 has been incredibly busy lately with personal things. But, if you come up with a set of changes you like to fold into a CC, he's the person to run them by. cheers, chinajade
Problem with global value? Hey guys, it looks like something weird is going on with global value Distance.Ranged. I started messing with it because for some reason my jedi consular was stopping 3 miles away from the mobs and not attacking. Best I can figure is that it is a distance problem since he would attack in 'closer' situations and also consistently pre lvl 11, so I modified the max range. Code: public class Distance { /// <summary> /// Maximum range for interaction with targets for melee. /// This value should also be used for cleave-style AoE attacks. /// </summary> public const float Melee = 0.35f; /// <summary> /// Some melee AoE spells are effective at greater than melee distance, but less than range distance. /// Examples include:<list type="bullet"> /// <item><description><para> * Jedi Knight's "Awe" / Sith Juggernaut's "Intimidating Roar"</para></description></item> /// <item><description><para> * Jedi Consular's "Force Wave" / Sith Inquisitor's "Overload"</para></description></item> /// </list> /// This is NOT a 'cleave range', use <c>Distance.Melee</c> for that. /// </summary> public const float MeleeAoE = 0.8f; /// <summary> /// Maximum range for interaction with targets at a distance. /// </summary> public const float Ranged = 1.8f; //Note: Default value 2.8f } Now notice I only changed the value from 2.8f to 1.8f but now the character is running into eskimo nose kissing range which doesn't seem logical compared to the other numbers for aoe and melee. Any ideas? Bob
I've never seen a 'range' problem like you describe. It sounds like you've got other problems going on. You might want to check your settings file for that toon, and make certain the PullDistance is set to 2. Can you toss a log that shows the problem? cheers, chinajade
Under the heading of "It took long enough": The TakeCover/Crouch system has been completely rewritten. Its unbelievable the amount of work it takes to simply get Crouch working properly. The final solution involves a wicked state machine, and 400 lines of code. The new algorithm simplifies to: Prefer Take Cover If Take Cover fails, try Crouch If Crouch fails, close some distance to the target and start with Take Cover again If we make it within melee distance to the target (never happened in any of our testing), just keep trying to Crouch between attacks. In addition to that, we handle the glitchy cases: There are certain spots on the terrain that cannot be TakeCover/Crouched. The ability says we succeeded, yet the buff is never acquired. We detect this situation, and move closer to the mob and try again. There are certain situations where SWtOR says we have Line-of-sight to the target, but the ability claims we don't. We detect this, and move closer to the mob to try again. If the mob moves out of range or gets knocked out of range by one of our explosive attacks, we move closer and reapply TakeCover/Crouch. If a mob hides behind an obstacle due to pathing glitches, we move to line of sight and reapply TakeCover/Crouch. We also test for Line-of-Sight after crouching to determine whether action is needed. This corrects those situations where a mob is slightly elevated, and our crouching too close to the dias on which it stands breaks line-of-sight. Without corrective action, the mob can hit us, but we can't hit the mob. Another example is a box/barrel between us and mob that is LoS-okay while standing, but LoS-impaired once we crouch. Dozens of other conditions like those listed above. There is one glitch remaining. It looks like this: the toon will TakeCover/Crouch, but every time it tries to use an ability, a "Cannot See Target" message will show up on the screen. From a programming viewpoint, this situation is not detectable (the EffectResult return code from the ability use is 'Unknown', which is unactionable as its returned for many things--okay or not). Since the situation is not detectable, we cannot determine that corrective action is needed. We have looked at all kinds of alternative ways to detect this situation, but have come up empty handed. <sigh> Fortunately, in about a week's worth of testing, this situation occurred only about 5 times. The new implementation has much testing on it--Agent and Smuggler both to level 10 about a dozen times, and spot testing a level 25 Sniper. Not all crouch-using classes/specs have been explicitly tested. Yet, despite this there may still be bugs. We had to work around all kinds SWtOR glitches/bugs involving LoS and terrain. We've hooked the new functionality into all the CCs that were using "Crouch". We left the old code in place, but commented out should you run into trouble. After a while, if the Community verifies it works satisfactorily, we'll delete the commented out code. You can find the new functionality in WingIt changeset #686. Take your time and test it--don't be in a hurry. Please report back your success or failure, so we know what further actions to take. cheers, chinajade
oh noes Sorry my friend, I didn't have a log file for that incidence because it came out to 80mb seemed a little excessive for uploading. In the end I changed the method away from the global value and to use the same schema as the basic profile. Changed from: Code: public class SorcererMadness_SageBalance : MirrorRoutine ... { return new PrioritySelector( ... CreateBTPS.MoveWithinRangeAndLoS(target => MyTarget, Global.Distance.Ranged), CastOnGround("Death Field", deathFieldOn => MyTarget.Position, deathFieldWhen => Me.ResourceStat >= 100), { To: Code: public class SorcererMadness_SageBalance : MirrorRoutine { ... #region Convenience methods private static float EngagementRange(TorCharacter target) { return (RangeAbilityReady(target) ? 1f : Global.Distance.Melee); } private static bool RangeAbilityReady(TorCharacter target) { return (Me.IsMirrorAbilityReady("Force Lightning", target) && Resource >= 30) || (Me.IsMirrorAbilityReady("Shock", target) && Resource >= 45); } #endregion public static Composite SorcererMadness_SageBalance_Pull() { ... CreateBTPS.MoveWithinRangeAndLoS(target => MyTarget, range => EngagementRange(MyTarget)), CreateBTPS.StopWithinRangeAndLoS(target => MyTarget, range => EngagementRange(MyTarget)), So far this has been more reliable than the previous method for me. If I have a free opportunity I will revert these changes and switch the global range for an uploadable log. If you want to test it, simply change the value of your global range in Global.cs from 2.8f to like 1.8f and use a range class like consular. Does he/she eskimo kiss every npc? EDIT: forgot to include the character settings for that alt: Code: <?xml version="1.0" encoding="utf-8"?> <CharacterSettings> <SellItemAtLeastQuality>Premium</SellItemAtLeastQuality> <EnabledPlugins> <Value>Auto-Equip</Value> <Value>Use Lockboxes</Value> </EnabledPlugins> <TrainWhenNewAbilitiesAvailable>false</TrainWhenNewAbilitiesAvailable> <LootNpcs>true</LootNpcs> <LastProfile>F:\Games\Star Wars-The Old Republic\SWTORMaestro_Standard_v1.1.6_core_v1223\Buddywing\BuddyWing older\Repositories\kicks-swtor-scripts\trunk\Republic\10-50\Dark\[R - Dark] 10-17 Coruscant [Kick].xml</LastProfile> <MountName>Longspur STAP</MountName> <PullDistance>2</PullDistance> <AutoSelectMount>true</AutoSelectMount> <LootChests>true</LootChests> <LootProfessionHarvestables>true</LootProfessionHarvestables> <Top>8</Top> <Left>1388</Left> <Width>525</Width> <Height>896</Height> </CharacterSettings>
I can get you to replicate this 100% of the time. The error is based on the fact that when the character is standing they are able to see the target. But when they crouch, they are no longer able to see the target as they no longer have LOS from their head to the target. Easiest way to get this error is target something when you're on the lower edge of a ramp and the target is on the top of the ramp about 5 feet back on the platform/level/whatever. You can shoot at them while standing, as soon as you crouch, you're no longer able to see the critter... Rinse/repeat.
Hi, Xanathos, Thanks for the feedback. Then there are two situations that cause the problem at the bottom of a ramp. In both cases SWtOR tells us we have LoS on the target when we crouch, but we don't. The only way to detect the problem is to check the EffectResult returned from the ability: Case #1: EffectResult of TargetViewBlocked is returned when the ability is used. This is detectable and we correct for this. Case #2: EffectResult of Unknown is returned when the ability is used. This is not a detectable situation, and we cannot correct for this. So, it sounds like you're saying the new code is ineffective for you? The handful of times Case #2 happened for me, it was always on open terrain. Could you tell your class, spec, specific location (by area, not coordinates), and which ability was in play where this occurs? If you could uncomment lines 219 through 227 of Movement.cs, and toss me your log when this happens, it would help chase the problem. As it goes, I guess we'll have to revert the code if more people report this. As I stated in the previous post, Case #2 is undetectable from a programming viewpoint. The SWtOR client is lying to us--telling us we have LoS to the target while crouched when we don't. I'll keep thinking about alternative detection mechanisms, but so far have come up empty handed. My highest level Sniper is 25. In the mean time, I guess that means I'll be leveling my Sniper to 50. <sigh> This may take a while as much of it will have to be done manually, and I really don't have the time for that. cheers, chinajade
Hi again, Bobsyuruncle, Thanks for the meaningful information! While working on the crouch stuff, I discovered a bug in MoveWithinRangeAndLoS. It was corrected in changeset #686. If you get the time, would be so kind as to tuck your changes to the side, and try changeset #686? Hopefully, the repaired MoveWithinRangeAndLoS solves your problem. I'd prefer finding and fixing the general problem for everyone instead of the various specs. thanks! chinajade P.S. - With respect to this other problem report... Changeset #686 also has a fix to that exception you were seeing wrt/HasImpliedMirrorBuff() and HasMirrorBuffStacks(). We re-wrote the functions to avoid aggravating the SWtOR client. I didn't see the exceptions in any of my testing, but that doesn't mean anything, because they weren't there for me before, either. Hopefully, the changes will move you down the road a little further.
The new code is working great... I have run into this issue a couple of times but I just run the bot forward a little and all is fine. I'll try and keep track of the coords that it is happening at, tho. One thing I can say is try some testing on Taris. There are plenty of uneven level areas where you are shooting up at the target and get your LOS clipped when you crouch down due to a ledge or whatnot. Otherwise, this is fantastic so far...
From here... Thank you for identifying the oversight! These changes have been folded into WingIt changeset #687. cheers, chinajade
In WingIt changeset #688, I've restored the use of ApplyGuard for the tanky-type classes. ApplyGuard does not keep a toon from mounting. The problem occurs when the settings file for that toon is missing a <MountName> entry. The correct mount name may be shown in the GUI, but if the settings file doesn't have a corresponding entry for <MountName> it doesn't matter what the GUI reports. Internally, Buddywing only works from the contents of the settings file. To repair it, just delete your settings file and allow BWcore to re-create it. You might want to double-check that the recreated file contains a valid entry for <MountName>. I've asked Aevitas to eyeball the code and see if he can figure out how the settings file gets into this state. I had the same problem on a Sniper. cheers, chinajade
With WingIt changeset #693, I believe the last of the Sniper TakeCover/Crouch problems have been solved. Please provide feedback to let us know any issues remaining. Alas, the SVN checkin was mishandled, and the comments describing the changeset were dropped. Sorry. cheers, chinajade
CJ, I'm attaching my modified .cs file so y'all can walk through it and see what I've changed. Feel free to use any or none of it. Some of my notes from it: I swap Shatter Shot with Explosive Probe in BehaviourType.Pull because it seems to be better to just open with Shatter Shot to get your target with the debuff pretty much every time then get the benefit from Explosive Probe. I've got it set that it only uses Shatter Shot if the target doesn't have the debuff, as then it is wasted energy. Evasion changed from Global.Health.OhShit to Global.Health.Low as it is more effective to get the 100% dodging going at a higher health value. By the time the OhShit value triggers the chances of survival are already pretty nil. It would be different if BW used a health pack at the same time, but it doesn't. So you need to trigger it a bit sooner. I've survived more fights when it triggers at Low then I have when it triggers at OhShit. Countermeasures moved up and changed so it triggers when Shield Probe triggers. This works out great so that not only do you get the Shield Probe benefit, but you immediately get the aggro dump from Countermeasures. The way it is coded by default it only fires when you're in a group and 100% fires when it gets to that line while in a group. That's not very efficient and means that it is triggering when it's not needed. At least this way it is triggering when you've taken some damage which means that you're going to be on someone's aggro list. You can ignore my Cover Pulse change... I drop it down to 1 just because I don't like even a solo guy being in melee with me. Plus, it's saved my butt MANY times by popping that solo Elite/Boss/Whatever away so that my companion can pick aggro again. Even if not, the 2-3 shots of damage that you get into a solo melee mob is worth the usage. Plus the refresh is fairly fast. I dropped all of the extra bits from Adrenaline Probe as they were mostly wasted. It'd only trigger based on the Buff calls and by the time it triggered I'd have pulsed from 70 energy up to 80 energy so I would only get about 20 energy out of the Buff over time with maybe one final 10 point pulse after my next ability. With how I've got the rest of my energy %'s it hardly ever even triggers with it being at a flat 65 energy call... And I'm shooting constantly. Series of Shots is my friend. When it does trigger now I get more out of the Buff then I would before. Shatter Shot has been fixed to use the correct debuff call. If nothing else you should fix this in the base .cs file. It is Armor Reduced not Armor Debuff. The rest doesn't have any major changes other then some energy use changes. I'm using MOX at this point to do realtime DPS parsing so that moving forward I can fiddle with the energy values and try to eek out some extra DPS. Side note... I changed my movement.cs file so it never tries to do Take Cover and only just Crouches. The reason for this is that a good percentage of the time diving into cover just caused more problems then it was worth. I'd end up aggroing more mobs, or I'd end up without LOS from having rolled so far, etc. Seems to be really problematic during tough fights inside when the bot rolls off to the other side of the room. So far it's working perfectly with it only pulling Crouch. Again, let me know if you have any followup changes or comments. I will continue to tweak things on my end to try and get things better.
