/// <summary> /// WaitTimer by Nesox /// Simple behavior that forces hb to wait until the timer runs out. /// ##Syntax## /// WaitTime: time in milliseconds to wait. eg; 15000 for 15 seconds. /// Important: this does not have a QuestId attribute and therefor you have to put this inside the body of an If tag!!! /// </summary>
Not a normal enchant.. If you read my previous post, I was trying to make it complete the Death Knight starter quest to use Runeforging.
CombatUseItemOn Runs to Location. Gets attacked by target. Stands still does nothing. Using correct item tags and NPC tags. HP Set to default 100. Target has 275HP. CustomBehavior File="CombatUseItemOn" QuestId="13961" ItemId="46722" NpcId="34503" NumOfTimes="1" HpLeftAmount="100" X="199.5051" Y="-2877.793" Z="92.33674"
NoControlVehicle Error is occurring c:\Users\Robert\Desktop\HonorBuddy\Quest Behaviors\NoControlVehicle.cs(62,5) : error CS0103: The name 'QuestId' does not exist in the current context c:\Users\Robert\Desktop\HonorBuddy\Quest Behaviors\NoControlVehicle.cs(114,19) : error CS1660: Cannot convert lambda expression to type 'TreeSharp.Composite' because it is not a delegate type c:\Users\Robert\Desktop\HonorBuddy\Quest Behaviors\NoControlVehicle.cs(114,27) : error CS0103: The name 'QuestId' does not exist in the current context c:\Users\Robert\Desktop\HonorBuddy\Quest Behaviors\NoControlVehicle.cs(114,68) : error CS0103: The name 'QuestId' does not exist in the current context c:\Users\Robert\Desktop\HonorBuddy\Quest Behaviors\NoControlVehicle.cs(115,51) : error CS0103: The name 'QuestId' does not exist in the current context Unable to compile CustomBehavior for tag: <CustomBehavior File="NoControlVehicle" NpcMountId="34430" TargetId="34478" SpellId="46714" VehicleId="34430" TypeId="1" /> Debug Log says: [3:32:46 AM:511] System.Exception: Unable to create instance of UserDefinedObjective at Bots.Quest.QuestOrder.ForcedCodeBehavior..ctor(String file, Dictionary`2 args, XElement element)
I'm discovering that the behaviors that shipped with Honorbuddy 2.0.0.3740 differ significantly from Natfoth's in the arguments they take. I'm not certain if the actual behavior is different or not. I'm still in the process of documenting the shipped ones, and CombatUseItemOn is one I've done so far... [wiki]Honorbuddy Custom Behavior: CombatUseItemOn[/wiki] Don't know if you are using Natfoth's or the shipped ones, but everyone should be aware there are differences between the two sets. I hope to have all the shipped ones documented in a few days--sorry for the delay with it. cheers, chinajade
here's a fix for the 2 behaviors that won't compile with the newest version http://rapidshare.com/files/442352223/Behaviors_fixed.rar
I have a problem with the "BasicInteractWith" as soon as it reaches the CustomBehavior step in the QuestOrder it gives me the following debug code Code: [20:16:20:760] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.ThrowHelper.ThrowKeyNotFoundException() at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at Styx.Bot.Quest_Behaviors.BasicInteractWith..ctor(Dictionary`2 args) in c:\Program Files (x86)\HonorBuddy\Quest Behaviors\BasicInteractWith.cs:line 27 --- End of inner exception stack trace --- at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType) at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at Bots.Quest.QuestOrder.ForcedCodeBehavior..ctor(String file, Dictionary`2 args) at QuestBot.Actions.ForcedBehaviorExecutor.a(OrderNode A_0) at QuestBot.Actions.ForcedBehaviorExecutor.b.a() at TreeSharp.Composite.Tick(Object context) at TreeSharp.PrioritySelector.a.b() at TreeSharp.Composite.Tick(Object context) at TreeSharp.PrioritySelector.a.b() at TreeSharp.Composite.Tick(Object context) at Styx.Logic.BehaviorTree.TreeRoot.b() [20:16:20:761] Cleared POI
Got a bunch of custom behaviours not compiling with the latest HB. Was working fine beforehand. Any ideas?
V1.0.0.8 - Updated scripts to work with the new Args system again. Will work with HB 2.0.0.3956. - Updated many of the scripts for small errors, Navigation problems, and various other fixes. - Added a TalkNow script which will just active that messages already on the screen for a few object/item scripts. The Wiki will need an update to reflect the new changes. Read Changelog. Hope you guys enjoy these behaviors, I will be rewriting them now using more secure methods will keep you guys posted.
Natfoth, can I get some php examples please? (and what I need to change in my profiles that you recommended - ie: doing it the "old" way?)
i think you should keep the syntax explanations in the files. Those comments about all arguments the behaviour uses, where helpful.
V1.0.0.9 - Hopefully fixed GameObject - Added a basic Escort NPC behavior: Should engage in combat if the npc enters combat also. - A few more small fixes Code: int npcID; if (!GetAttributeAsInteger("NpcId", true, "1", 0, int.MaxValue, out npcID)) Logging.Write("Parsing NpcId in Escort behavior failed! please check your profile!"); This is the new way to handle Args within the profile. The args will show up the same on the behavior that has not changed. But this new system allows you to lock the args into place for more secure profiles. Let me explain what each one does. Code: "NpcId" This is the arg name that shows up on the profile such as Code: NpcID="1231" Code: true The next thing is a BOOL, this will tell us if the arg is Required or if the user is able to leave it out. Things such as NPCID that are essential should always be True. Code: "1" This is a string that will tell the user what they should put in the value if they put in an invalid arg. Kind of like giving them a hint. In this case I tell them it has to be a number by saying 1, but in other cases such as a name it would be "Natfoth". Code: 0 This is the min value that the Arg will accept. If the user puts in another less the script will error out, stop HB, and post a message saying what your default should be. Code: int.MaxValue This is the same above but the max. When doing a NPC, Object, or Quest. This should be the MaxValue. If this is something such as BehaviorType that I use in my Vehicle scripts they can only put a value of 3 since there is only 3 options. If you need any more help I can post more if needed.
Arg Types Code: GetAttributeAsBoolean GetAttributeAsFloat GetAttributeAsInteger GetAttributeAsSpecificString GetAttributeAsString GetXYZAttributeAsWoWPoint GetXYZAttributeAsWoWPoint Examples: Code: int npcID; if (!GetAttributeAsInteger("NpcId", true, "1", 0, int.MaxValue, out npcID)) Logging.Write("Parsing NpcId in Escort behavior failed! please check your profile!"); Code: WoWPoint location; if (!GetXYZAttributeAsWoWPoint("X", "Y", "Z", true, new WoWPoint(0, 0, 0), out location)) Logging.Write("Parsing location in Escort behavior failed! please check your profile!"); Code: int TypeID; if (!GetAttributeAsInteger("TypeId", true, "1", 0, 3, out TypeID)) Logging.Write("Parsing TypeId in NoControlVehicle behavior failed! please check your profile!"); Code: int questId; if (!GetAttributeAsInteger("QuestId", true, "1", 0, int.MaxValue, out questId)) Logging.Write("Parsing questid in NoControlVehicle behavior failed! please check your profile!"); QuestId = (uint)questId;
Kick, I didn't realize what you were asking at first. But the RunMacro code has the first generation of the new argument handling. You can take a peek at v1.2 here: [wiki]Honorbuddy Custom Behavior: RunMacro[/wiki] Consider the following behavior code fragment: PHP: public MyBehaviorConstructor(Dictionary<string, string> args) { // Report anything the profile writer provided that we aren't interested in -- // This can be problems with case, spelling, or outright confusion as to what // attributes should be provided to this behavior. CheckForUnrecognizedAttributes(args, s_recognizedAttributeNames); // Check all the parameters before returning -- // We don't want to "nickel and dime" the profile writer with error messages. This // pattern reports all failed entry criteria before returning. _isAttributesOkay = true; _isAttributesOkay = _isAttributesOkay && GetAttributeAsString(args, "Macro", true, "", out _macro); _isAttributesOkay = _isAttributesOkay && GetAttributeAsInteger(args, "NumOfTimes", false, "1", 1, 100, out _numOfTimes); _isAttributesOkay = _isAttributesOkay && GetAttributeAsInteger(args, "WaitTime", false, "1500", 0, int.MaxValue, out _waitTime); } public override void OnStart() { // If the profile writer didn't provide our full entry criteria for attributes -- // Stop the profile here with a message. if (!_isAttributesOkay) { Logging.Write(Color.Red, "Stopping Honorbuddy. Please repair the profile!"); TreeRoot.Stop(); } else { // Real behavior work goes here -- // ... } } private bool _isAttributesOkay; private bool _isBehaviorDone; private string _macro; private int _numOfTimes; private int _waitTime; private static Dictionary<String, Object> s_recognizedAttributeNames = new Dictionary<String, Object>() { { "Macro", null }, { "NumOfTimes", null }, { "WaitTime", null }, }; Things to note include: Just make the appropriate Get*() calls for each type of argument expected, you shouldn't do any logging, as the Get*() methods do all the needed logging. This reduces maintenance and cut-n-paste errors by preventing spelling or identification problems with the behavior or attribute names. In the constructor, be sure to call CheckForUnrecognizedAttributes() right up front. This reports error messages against attributes that the behavior doesn't recognize--usually caused by spelling or capcase problems on the caller's part. Sometimes, its just outright confusion--such as supplying a Location where a X-Y-Z are expected. Unrecognized attributes are not considered fatal, and are ignored. However, an error message is logged to let the PW know there is a mis-match between what he provided, and what the behavior expects. The Get*() methods do not throw exceptions in the constructor (nor should they for improper user input). You shouldn't either. Detecting whether or not the behavior should proceed is handled right up front in the OnStart() method. If the arguments were not parsed correctly, TreeRoot.Stop() is called. What all this does is make a Profile Writer's (PW) life much easier. If the PW mis-spells, mis-capitalizes, or provides an attribute that is unrecognized, he is told so in explicit terms which Attribute is in offense. If a PW provides a value that is out of range (say an Integer should have been on the closed interval [0..100]), he is told so explicitly. In the logged message, the behavior and attribute are clearly identified along with what was seen, and what was expected. If the PW fails to provide a required attribute, he is told so explicitly. If the provided data is malformed (say, an integer of "--234.56"), the PW is told explicitly with the behavior and attribute properly identified, along with a confirmation of what was seen, and what was expected. For things like points (co-variant data), if the PW specifies them incompletely (say an X and Y, but omitted Z), the profile writer is told exactly where the problem lies. No more guessing. No more looking at 'compile errors', or 'exceptions'. Clear messages are logged whenever a PW fails to meet a Behavior's entry criteria. For the CB developer, writing behaviors is simplified: Argument handling now is really as simple as the example shown above. Eliminates cut-n-paste errors that were present before. These types of errors were lieing to the PW as to what behavior was having problems, or what attribute was causing offense--no more. I am flattered that the HBteam took the code that was placed in some of the Wiki behaviors. If I'd known this was going to happen, I would've provided adequate documentation to go with it. My computer gave out a couple of days ago, and I'm expecting the replacement to be here this week. (This is also why I haven't been on IM--my temp computer won't handle it with my other things going on. ) I'll try to get proper documentation for these methods to the HBdev team shortly, so it will be available for CB developers in the next drop. cheers, chinajade
V1.1.0.0 - Added Quest Log Completion and Accepting Behaviors. When using these you must go by what order it is within your quest log. Sort of an inconvenience right now, but it will allow us to do these quests for the moment. I will come up with a system to auto read which order it is this weekend. - Updated a lot of the behaviors to use Navigator.MoveTo rather then the older system - Added a UseItemTargetLocation behavior for those pesky quests that require you to use an item and target a spot while not in a vehicle.
Does the core team merge these behaviours into the official release? i run a diff against both yours and the official behaviours and while many files exist in both parts, they differ a lot
All of my behaviors go into the bot when I update them, Like the next release will have this set in them. I update them faster then the HB releases is why they differ hehe. But both will work
natfoth - I was asking about the code to put inside of profiles (if you updated with anymore arguments), not the code that you have in your CB's. Also, you said I was doing things the "old way" in my profiles, which I didn't know if you were talking about my profile itself, or the CB's I was using (KaZ made some of them. I'm not KaZ ) ie: PHP: <CustomBehavior File="UseGameObject2" QuestId="11965" ObjectId="188163" NumOfTimes="1" X="2615.225" Y="5268.674" Z="43.543" /> <!-- Works, Natfoth's UGO --> does combatuseitemon work now? If so, is it still like: PHP: <CustomBehavior File="CombatUseItemOn" QuestId="11590" ItemId="34691" ObjectType="NPC" MobId="25316" NumOfTimes="1" RangeWanted="10" HpAmount="2500" CollectionDistance="100" X="3412.103" Y="6102.03" Z="66.76636" /> ignore the rangewanted, kaz and i were testing stuff. we changed hpamount from the old arg
ahh ok, Here is a php code for CombatUseItem as an example Code: <CustomBehavior File="CombatUseItemOn" QuestId="24616" ItemId="49944" NpcId="37953" NumOfTimes="1" HpLeftAmount="110" X="-2254.046" Y="1481.799" Z="-19.35919" /> and here is an example of one of the new "UseItemTargetLocation" Code: <CustomBehavior File="UseItemTargetLocation" QuestId="25766" ItemId="55972" UseNPC="1" NPCID="34938" DoUntilFinished="1" UseNPCLocation="1" WaitTime="6000" X="571.4476" Y="1084.42" Z="117.2758" /> and then Code: <CustomBehavior File="UseItemTargetLocation" QuestId="13880" ItemId="46352" WaitTime="6000" MoveX="2537.937" MoveY="-1285.944" MoveZ="120.8914" TargetX="2537.937" TargetY="-1285.944" TargetZ="120.8914" /> Both are the same script but depending on some of the args the rest of the args will change. The wiki will probably be updated soon to reflect the changes to make it easier to see all of the differences.
i think interactwith.cs is having issues to get it working Not sure i should post it here or..hb bugsubmiter?
