Official ScriptUO EasyUO Scripts > Script Debug
Eggscavator (Medusa keys) beta
baldielocks:
This script needs some fine tuning, but it WORKS. I have a bug that I need help with though. When I do this with a timer or a 8 sec hard wait, it runs flawlessly. I found a way to make it run even faster though by using TM's journal scanner and checking for recharge.
The problem is that when I do use it (it's in this script version now), I get some odd errors. After the journal scanner returns #true for recharge, the script will loop back and try the same hole again, even though I ignored it in the plot_hole sub. If there are no valid snakes, it winds up double clicking the hole, which is BAD. Any thoughts?
--- Code: ---sub charm
gosub TM_AdvJournalSync FAIL
gosub TM_AdvJournalSync Charm
set #lobjectid %flute2
wait %lagwaits
gosub TM_AdvJournalscan CHARM Valid recharge
If #result = #false
{
event macro 17
}
wait %lagwaits
gosub TM_AdvJournalscan CHARM Valid recharge
If #result = #true
{
wait 1s
gosub charm
}
set #ltargetid %target1
set #ltargetkind 1
wait %lagwaits
event macro 22
wait %lagwaits
gosub TM_AdvJournalscan FAIL Valid don't_seem
If #result = #true
{
wait 1s
gosub charm
}
gosub worldxyztoscreenxy %xhole %yhole %zhole
click %_cursorx %_cursory
ignoreitem %target2
return
--- End code ---
Gaderian:
I find it easy in my own projects to assume I know what some logic does, but I may never go back and really scrutinize it. This leads to frustration on my part for my own work. I would guess you are down that same path with your project here... ;)
It has been a long time since I farmed Medusa keys manually - probably 8 years - so I do not remember all the rules. I am assuming that you need the flute to recharge before you can try to charm another snake and that is the 8 seconds or journal messages - is that true?
Your subroutine "charm" recursively gosubs to itself. I think this causes your "double click" issue.
Let's break down a part of your routine with comments to help see this at the end of the sub:
--- Code: easyuo ---gosub TM_AdvJournalscan FAIL Valid don't_seem ; test for a journal message and if it isn't found then rerun this subroutineIf #result = #true{wait 1sgosub charm ; here is where we rerun the routine, and once we complete it, we will come out after clicking on the target and complete this execution of the routine} gosub worldxyztoscreenxy %xhole %yhole %zhole click %_cursorx %_cursory ; which leads to this line where we click again ignoreitem %target2return
The reason why I have TM's quote in my sig is my respect for someone writing a functional recursive logic machine in the CLAW. That is something I would never try because I wouldn't think of it as a solution. Recursion is so hard to get working correctly, so anytime it can be done I am very impressed.
How about making this project more simple?
This has lots of code that with a few tweaks is much easier to follow, which means it is easier to understand what it is doing and how to modify it.
Change the code around your gosub Charm in the main loop to:
--- Code: easyuo ---Retry_Charm:gosub charmif #result = retry goto Retry_Charm
Then change Charm to return with a value when you want it to run again, which eliminates the recursive nature and will fix the double (or potentially more) clicks.
--- Code: easyuo ---;-----------------------------sub charm gosub TM_AdvJournalSync FAIL gosub TM_AdvJournalSync Charm set #lobjectid %flute2 wait %lagwaits gosub TM_AdvJournalscan CHARM Valid recharge If #result = #false { event macro 17 } wait %lagwaits gosub TM_AdvJournalscan CHARM Valid recharge If #result = #true { wait 1s return retry ; gosub charm } set #ltargetid %target1 set #ltargetkind 1 wait %lagwaits event macro 22 wait %lagwaits gosub TM_AdvJournalscan FAIL Valid don't_seem If #result = #true { wait 1s return retry ; gosub charm } gosub worldxyztoscreenxy %xhole %yhole %zhole click %_cursorx %_cursory ignoreitem %target2return clear
I still want to change the finditem statements with increasing distances. I know in my past I recommended that kind of processing to someone who wanted to check progressively further away, but I have recently done some testing on modest hardware. Many of the script speed recommendations out there are very out of date. Many go back to the pre-EUO 1.5 era - which was a different animal. I recently went to challenge some of my beliefs on how to script - I created timed tests at Luna during prime time. There were something like 200 mobile objects (players and pets) and the difference in a single finditem statement was practically the same regardless of the distance, but trying to have multiple finditem statements was significantly slower. My conclusion is that issuing the one wide range (G_20?) finditem and then looping through the data to glean what I want is 10-15x faster than doing 10 separate finditem statements.
baldielocks:
Thank Gaderian, for all your points. You are 100% correct about the ugly nature of the inside out #finditem. Caines has been working with me (bless his patience) in trying to help me code the array as you suggest. I am learning, but still haven't got it quite right yet. That is an upcoming version. I wanted to be able to make progress, so when I hit the wall on the array, I come back to the other subs and polish those.
my basic is idea is:
Find all holes within 20 tiles.
set their x, z, id and find distance.
for each hole that is <than 10, find the closest snake to that hole.
Ignore the snake.
Once all holes within 10 have been used, MOVE to the next closest outside 10. And so on.
Ignore holes that cannont be reach, as some holes can spawn in location that they cannot be clicked on.
The ting I appreciate the most about scripting, or programming in general, is the enforced humility. 100% of the errors are YOUR fault, so never assume you are right until you check it.
I'm going now to change the loops as you suggested. I did not know that I could just throw in a line and go there! that is super cool
baldielocks:
another snake reared it's ugly head (where's the pun :police:)
First, made the suggested change. I still get random clicks on the hole that I don't get with just a hard wait. That's not the issue though. At the end of the charm sub, I have ignoreitem %target1 (snake id) and ignoreitem %target2 (hole id). The snake ignore appears to work, but the hole id does not. That is why it is going back to the same hole.
baldielocks:
that last post got me to thinking. Found a hanging bracket and an extra holeid ignore! And if you ignore the same ID twice, it resets it. Bingo!
Navigation
[0] Message Index
[#] Next page
Go to full version