Code: Select all
getQuestStatus("^"..nameOnBoard.."$", groupOnBoard)
Code: Select all
getQuestStatus("^"..nameOnBoard.."$", groupOnBoard)
That might work, but I strictly use the IDs so that my waypoint files are not language dependent. The bot turns in the right quest, but the IGF that checks the quest status is where it is getting converted to a text string and the pattern matching is happening. It is the value returned from the IGF that is causing the bot to lock up on that quest turn-in.Rock5 wrote:I just thought of a really obvious solution. When you check the status of a quest on a board you have the exact name and quest group. The problem has been that "Old Friend" matches 2 quest but there is no reason why we couldn't turn the name into a pattern search, as I described before, when you know the name is exact.
That's the release version, not my internal testing version. Here's the section of code I am using now to avoid the elite Gargoylem. When I get to #64 and start harvesting the statue, the elite will notice me and locked on aggro and begin its attack. What I want to happen is to fly away if that attack interrupts the casting, but my character just starts attacking instead.lisa wrote:I had a quick look at your WP, I am guessing you mean in YH_03_Taffrock.xml.
It gets changed to normal and then later gets changed back to travel, maybe the WP where it is meant to change back is being skipped?
Code: Select all
<!-- # 59 --><waypoint x="1209" z="1323" y="2981">
__WPL:setForcedWaypointType("TRAVEL")
fly()
</waypoint>
<!-- # 60 --><waypoint x="1344" z="1327" y="3417"> </waypoint>
<!-- # 61 --><waypoint x="1628" z="1342" y="3557"> </waypoint>
<!-- # 62 --><waypoint x="1885" z="1327" y="3491"> </waypoint>
<!-- # 63 --><waypoint x="2083" z="1324" y="3237"> </waypoint>
<!-- # 64 --><waypoint x="1923" z="1279" y="3006" tag="Princess">
__WPL:setForcedWaypointType("TRAVEL")
player:target_Object(120527) -- Morfantas Statue
repeat
yrest(500)
until player.Casting == false
</waypoint>
<!-- # 65 --><waypoint x="1921" z="1296" y="3050">
print("Begin pathing to evade Gargoylem")
</waypoint>
<!-- # 66 --><waypoint x="2162" z="1314" y="3114"> </waypoint>
<!-- # 67 --><waypoint x="2423" z="1320" y="3239"> </waypoint>
<!-- # 68 --><waypoint x="2616" z="1181" y="3292"> </waypoint>
<!-- # 69 --><waypoint x="2785" z="1203" y="3393"> </waypoint>
<!-- # 70 --><waypoint x="2904" z="1313" y="3476">
print("Gargoylem should have dropped aggro and returned to his starting point.")
if inventory:itemTotalCount(241048) > 0 and getQuestStatus(425081) == "complete" then
__WPL:setWaypointIndex(__WPL:findWaypointTag("PrincessDone"))
end
</waypoint>
<!-- # 71 --><waypoint x="2652" z="1371" y="3299"> </waypoint>
<!-- # 72 --><waypoint x="2328" z="1331" y="3159"> </waypoint>
<!-- # 73 --><waypoint x="1960" z="1293" y="3009">
__WPL:setWaypointIndex(__WPL:findWaypointTag("Princess"))
</waypoint>
<!-- # 74 --><waypoint x="2430" z="1326" y="3074" tag="PrincessDone"> </waypoint>
<!-- # 75 --><waypoint x="2705" z="1325" y="3074">
flyoff()
outside = GoThroughPortal(250)
if outside == false then
error("Failed to leave the instance: Taffrock Southern District.", 0)
end
</waypoint>
Which item did I miss? I see the one I get from Saul Leighton's Bag.rock5 wrote:Thanks for the example waypoint. You just missed accepting the boundary quest from the item.
Code: Select all
inventory:useItem(241044) -- Seal of Zurhidon
RoMScript("AcceptBorderQuest()") -- Enigmatic Seal
The problem is when you are going through the list of accept or complete quests choosing which to accept/complete, you are not going to have the id because you can't get the id from the board/dialog as far as I know. Using the exact name and group is a 100% reliable way to do it and allows you to use what you actually get from the board. I thought about using the originally supplied id if an id was used but it gets complicated and you still have the same issue if you used the name "Old Friend" instead. Trust me. When I get around to it, it will work.Bill D Cat wrote:That might work, but I strictly use the IDs so that my waypoint files are not language dependent. The bot turns in the right quest, but the IGF that checks the quest status is where it is getting converted to a text string and the pattern matching is happening. It is the value returned from the IGF that is causing the bot to lock up on that quest turn-in.
Code: Select all
function getQuestStatus(_questnameorid,_questgroup)
-- Used when you need to make 3 way decision, get quest, complete quest or gather quest items.
if (bot.IgfAddon == false) then
error(language[1004], 0) -- Ingamefunctions addon (igf) is not installed
end
if type(tonumber(_questnameorid)) == "number" then
_questnameorid = GetIdName(_questnameorid)
end
if type(_questnameorid) == "string" then
_questnameorid = "\""..NormaliseString(_questnameorid).."\""
else
error("Invalid argument used with getQuestStatus(): Expected type 'number' or 'string'")
end
if _questgroup then
if type(tonumber(_questgroup)) == "number" then
_questgroup = ", " .. _questgroup
else
_questgroup = ", \"" .. _questgroup.."\""
end
else
_questgroup = ""
end
return RoMScript("igf_questStatus(".._questnameorid.._questgroup..")")
end
I'm not sure but __WPL:setForcedWaypointType("TRAVEL") overwrite the general settingfor the whole waypoint file but nothing means NORMAL in each waypoint maybe it has to do with this using a lua command isn't also the 'normal' way to do something like this mire like type="TRAVEL" in each effected waypoint at least that should work for sure or something is extremely wrong. Anyway I will test it later I must take my whole system apart because google ask constantly me if I'm a bot or not the last 2-3 days something is fishy.Bill D Cat wrote:That might work, but I strictly use the IDs so that my waypoint files are not language dependent. The bot turns in the right quest, but the IGF that checks the quest status is where it is getting converted to a text string and the pattern matching is happening. It is the value returned from the IGF that is causing the bot to lock up on that quest turn-in.Rock5 wrote:I just thought of a really obvious solution. When you check the status of a quest on a board you have the exact name and quest group. The problem has been that "Old Friend" matches 2 quest but there is no reason why we couldn't turn the name into a pattern search, as I described before, when you know the name is exact.
That's the release version, not my internal testing version. Here's the section of code I am using now to avoid the elite Gargoylem. When I get to #64 and start harvesting the statue, the elite will notice me and locked on aggro and begin its attack. What I want to happen is to fly away if that attack interrupts the casting, but my character just starts attacking instead.lisa wrote:I had a quick look at your WP, I am guessing you mean in YH_03_Taffrock.xml.
It gets changed to normal and then later gets changed back to travel, maybe the WP where it is meant to change back is being skipped?
Code: Select all
<!-- # 59 --><waypoint x="1209" z="1323" y="2981"> __WPL:setForcedWaypointType("TRAVEL") fly() </waypoint> <!-- # 60 --><waypoint x="1344" z="1327" y="3417"> </waypoint> <!-- # 61 --><waypoint x="1628" z="1342" y="3557"> </waypoint> <!-- # 62 --><waypoint x="1885" z="1327" y="3491"> </waypoint> <!-- # 63 --><waypoint x="2083" z="1324" y="3237"> </waypoint> <!-- # 64 --><waypoint x="1923" z="1279" y="3006" tag="Princess"> __WPL:setForcedWaypointType("TRAVEL") player:target_Object(120527) -- Morfantas Statue repeat yrest(500) until player.Casting == false </waypoint> <!-- # 65 --><waypoint x="1921" z="1296" y="3050"> print("Begin pathing to evade Gargoylem") </waypoint> <!-- # 66 --><waypoint x="2162" z="1314" y="3114"> </waypoint> <!-- # 67 --><waypoint x="2423" z="1320" y="3239"> </waypoint> <!-- # 68 --><waypoint x="2616" z="1181" y="3292"> </waypoint> <!-- # 69 --><waypoint x="2785" z="1203" y="3393"> </waypoint> <!-- # 70 --><waypoint x="2904" z="1313" y="3476"> print("Gargoylem should have dropped aggro and returned to his starting point.") if inventory:itemTotalCount(241048) > 0 and getQuestStatus(425081) == "complete" then __WPL:setWaypointIndex(__WPL:findWaypointTag("PrincessDone")) end </waypoint> <!-- # 71 --><waypoint x="2652" z="1371" y="3299"> </waypoint> <!-- # 72 --><waypoint x="2328" z="1331" y="3159"> </waypoint> <!-- # 73 --><waypoint x="1960" z="1293" y="3009"> __WPL:setWaypointIndex(__WPL:findWaypointTag("Princess")) </waypoint> <!-- # 74 --><waypoint x="2430" z="1326" y="3074" tag="PrincessDone"> </waypoint> <!-- # 75 --><waypoint x="2705" z="1325" y="3074"> flyoff() outside = GoThroughPortal(250) if outside == false then error("Failed to leave the instance: Taffrock Southern District.", 0) end </waypoint>
Code: Select all
<!-- # 73 --><waypoint x="1960" z="1293" y="3009" type="TRAVEL"></waypoint>
But isn't that why the _questgroup part of the function is there? To differentiate between a normal quest, daily or public.rock5 wrote:I think that would break it because if a user uses an id with getQuestStatus to avoid problems with daily and public quests with the same name, then once the id is turned into a name there would be no way for it to know which one was meant.
Okay I tested it works at least 50% of the timeBill D Cat wrote:That might work, but I strictly use the IDs so that my waypoint files are not language dependent. The bot turns in the right quest, but the IGF that checks the quest status is where it is getting converted to a text string and the pattern matching is happening. It is the value returned from the IGF that is causing the bot to lock up on that quest turn-in.Rock5 wrote:I just thought of a really obvious solution. When you check the status of a quest on a board you have the exact name and quest group. The problem has been that "Old Friend" matches 2 quest but there is no reason why we couldn't turn the name into a pattern search, as I described before, when you know the name is exact.
That's the release version, not my internal testing version. Here's the section of code I am using now to avoid the elite Gargoylem. When I get to #64 and start harvesting the statue, the elite will notice me and locked on aggro and begin its attack. What I want to happen is to fly away if that attack interrupts the casting, but my character just starts attacking instead.lisa wrote:I had a quick look at your WP, I am guessing you mean in YH_03_Taffrock.xml.
It gets changed to normal and then later gets changed back to travel, maybe the WP where it is meant to change back is being skipped?
Code: Select all
<!-- # 59 --><waypoint x="1209" z="1323" y="2981"> __WPL:setForcedWaypointType("TRAVEL") fly() </waypoint> <!-- # 60 --><waypoint x="1344" z="1327" y="3417"> </waypoint> <!-- # 61 --><waypoint x="1628" z="1342" y="3557"> </waypoint> <!-- # 62 --><waypoint x="1885" z="1327" y="3491"> </waypoint> <!-- # 63 --><waypoint x="2083" z="1324" y="3237"> </waypoint> <!-- # 64 --><waypoint x="1923" z="1279" y="3006" tag="Princess"> __WPL:setForcedWaypointType("TRAVEL") player:target_Object(120527) -- Morfantas Statue repeat yrest(500) until player.Casting == false </waypoint> <!-- # 65 --><waypoint x="1921" z="1296" y="3050"> print("Begin pathing to evade Gargoylem") </waypoint> <!-- # 66 --><waypoint x="2162" z="1314" y="3114"> </waypoint> <!-- # 67 --><waypoint x="2423" z="1320" y="3239"> </waypoint> <!-- # 68 --><waypoint x="2616" z="1181" y="3292"> </waypoint> <!-- # 69 --><waypoint x="2785" z="1203" y="3393"> </waypoint> <!-- # 70 --><waypoint x="2904" z="1313" y="3476"> print("Gargoylem should have dropped aggro and returned to his starting point.") if inventory:itemTotalCount(241048) > 0 and getQuestStatus(425081) == "complete" then __WPL:setWaypointIndex(__WPL:findWaypointTag("PrincessDone")) end </waypoint> <!-- # 71 --><waypoint x="2652" z="1371" y="3299"> </waypoint> <!-- # 72 --><waypoint x="2328" z="1331" y="3159"> </waypoint> <!-- # 73 --><waypoint x="1960" z="1293" y="3009"> __WPL:setWaypointIndex(__WPL:findWaypointTag("Princess")) </waypoint> <!-- # 74 --><waypoint x="2430" z="1326" y="3074" tag="PrincessDone"> </waypoint> <!-- # 75 --><waypoint x="2705" z="1325" y="3074"> flyoff() outside = GoThroughPortal(250) if outside == false then error("Failed to leave the instance: Taffrock Southern District.", 0) end </waypoint>
When I tested it yesterday it is like I feared through the level difference the same what goes for the warlock goes for the mage as well. He is simple too overpowered even with out staff one fireball and the mob is toast. You can capture a mop this way you have to hit him as MDD with your staff or fists to capture it when the level difference is too great.BlubBlab wrote:I tested it a bit again I must say with the a champion I have less problems but with a warlock it seems impossible to catch mobs.
For the champion I simple added than he must put a away his weapons when the level of the char is bigger than 15.
I had also add 2 checks for if some quests are. complete. besied that:
103; 205 in run into a obstacle but evading to the right was always the right choice for the bot.(haven debugged that)
115 (Nina) your other quest which makes trouble needs a moveTo that NPC running around too much.
Besides for my personal choices I added a few item use
EDIT: Maybe Bill can compare his questHelper userfunction which he uploaded with his own I suspect he uploaded an old version because ItemQueueCount was misspelled inside.
Sry about the upload of the first part I realized I had still 115 as start point I reupload it
Part 2 seems to work flawless beside stuck between 241 and 242
Part 3 added some setting for resum but the problem is for goThroughPortal it seems to work sometimes and sometimes not
Code: Select all
if((player.Level - pawn.Level) >= 10 and( player.class == MAGE or player.class == PRIEST or player.class ==WARLOCK )then
--if difference >= 20 dequip main weapon
repeat
attack()
pawn:updateHP()
until pawn.HP <= captureHP
end
By the way the rest works for me when you go through 10DQ's and had one more level up through it ( but somehow I didn't had the quest for the princess item quest I had to added it)
I've been playing around with switching to bare-hand attacks when the player / mob level difference is more than a certain amount. I would also like to disable all skills if needed, or just have a "return false" in the onPreSkillCast() to not allow the bot to use any skills and rely only on white attacks leading up to the mob capture.BlubBlab wrote:For the champion I simple added than he must put a away his weapons when the level of the char is bigger than 15.
I'll go through and see if there's any other points I can add sanity checks to make sure quests get completed. I've rarely run into any of them that have failed, but someone else might, so it's better to be prepared.BlubBlab wrote:I had also add 2 checks for if some quests are complete.
Nina always was just running around a very small area just before you get to Snoop. I've never had an issue with the bot targeting her and completing the quest. But since she is mobile, it may be best to add a movement and target command inside a quest completion loop.BlubBlab wrote:103; 205 in run into a obstacle but evading to the right was always the right choice for the bot.(haven debugged that)
115 (Nina) your other quest which makes trouble needs a moveTo that NPC running around too much.
That was one of the things that Rock added. I never noticed that it was not capitalized correctly.BlubBlab wrote:EDIT: Maybe Bill can compare his questHelper userfunction which he uploaded with his own I suspect he uploaded an old version because ItemQueueCount was misspelled inside.
Yeah, I noticed the bot can run close to the instance entrance to target some of the mobs and then get stuck behind one of the walls. I think I've fixed that in the latest upload. If not, it should be easy enough to add another waypoint to the center of that opening so it gets back out correctly.BlubBlab wrote:Part 2 seems to work flawless beside stuck between 241 and 242
The portal was never an issue for me, so I haven't needed to debug anything at that point.BlubBlab wrote:Part 3 added some setting for resum but the problem is for goThroughPortal it seems to work sometimes and sometimes not
I'll keep working on the mob capture routine to add level checks and estimate if anything else needs to be done so that you don't kill the mob before you can capture it. There's a few quests in Sascialia Steppes that need you to capture mobs, so I've got lots of areas to test this on.BlubBlab wrote:When I tested it yesterday it is like I feared through the level difference the same what goes for the warlock goes for the mage as well. He is simple too overpowered even with out staff one fireball and the mob is toast. You can capture a mop this way you have to hit him as MDD with your staff or fists to capture it when the level difference is too great.
Something likeCode: Select all
if((player.Level - pawn.Level) >= 10 and( player.class == MAGE or player.class == PRIEST or player.class ==WARLOCK )then --if difference >= 20 dequip main weapon repeat attack() pawn:updateHP() until pawn.HP <= captureHP end By the way the rest works for me when you go through 10DQ's and had one more level up through it ( but somehow I didn't had the quest for the princess item quest I had to added it)
What's the problem? Did you spell it with a lower case first letter? The problem with the bot is that there is no 100% standard for the naming of variables or functions so in various places things will be capitalized 1 way and in other places they will be capitalized another way.Bill D Cat wrote: BlubBlab wrote:
EDIT: Maybe Bill can compare his questHelper userfunction which he uploaded with his own I suspect he uploaded an old version because ItemQueueCount was misspelled inside.
That was one of the things that Rock added. I never noticed that it was not capitalized correctly.
Users browsing this forum: No registered users and 7 guests