Official ScriptUO EasyUO Scripts > Script Debug
Eggscavator (Medusa keys) beta
Gaderian:
Sorry that I didn't mention the extra brace. I knew that, but deleted it from the version I was working with. I found it using the ScriptUO editor and it's Tools/Syntax_Error_Check menu option.
Great catch on the toggle nature of ignoreitem.
Ignoreitem:
You could also have 3 ignoreitem lists:
1) unreachable things
2) holes already targeted
3) snakes already charmed
Anything unreachable (so likely only holes that spawn in bad locations) use no list:
ignoreitem #findid
Snakes could be found that are out of your line of sight, I would just add those to the 'snake' list, because these are mobile and could come back into range later, so when you have no more snakes found, you would want these to be come valid found objects.
Anything that is a hole that you targeted:
ignoreitem %target2 hole
Anything that is a snake charmed:
ignoreitem %target1 snake
Then you replace the hole ignoreitem reset with:
ignoreitem reset hole
And replace the snake ignoreitem reset with:
ignoreitem reset snake
You would never do a ignoreitem reset without the list parameter in the script.
#FINDDIST:
In plothole you have a test after finditem:
if #finddist > 3 || #finddist = -1
I understand '#finddist > 3', but what does '#finddist = -1' mean?
Was this supposed to be if the hole was no found ('#findkind = -1') in the 2nd half of the test?
Variable Naming Convention:
Name variables clearly to make it obvious what is preserved:
%target1 should be %targetsnake
%target2 should be %targethole
Some logical flow questions:
sub findhole
The end of this issues a recursive gosub findhole
sub findsnake
1) The end of this issues a gosub findhole - why?
2) If there is a need to reset to begin searching again, wouldn't you want to run through the logic of 'mainloop'?
sub eggs_in_one_basket
There is a finditem and a for loop, but the first time through the loop it returns. Why have the for loop?
There is findhole and findsnake subs with nested finditem statements. Suppose you want to find the closest thing, consider this structure:
--- Code: easyuo ---sub FindClosest if %0 <> 2 return #false namespace push namespace local FindClosest_ namespace clear set !SearchFor %1 set !finddist %2 + 1 ; initialize distance of closest item found set !SearchDist %2 finditem !SearchFor G_ , !SearchDist if #findcnt > 0 { for #findindex 1 #findcnt { if #finddist < !finddist { set !findid #findid set !findx #findx set !findy #findy set !findz #findz set !finddist #finddist } } } if !finddist = !SearchDist { set #result #false ; nothing was found } else { set #result !findid } namespace popreturn #result
Now you use it:
--- Code: easyuo ---gosub FindClosest %type %distance if ! #result { ; nothing was found in range or wrong number of parameters passed }if #result { ; found a valid thing to use ; you could go back into the namespace if you need more than just the #findid: namespace copy find* from local FindClosest_ ; now !findid !findx, !findy, !findz and !finddist are copied into your regular namespace } That eliminates having a lot of finditems in each of those find* subs and returns the closest one. Much cleaner.
Here is the example on how findsnake tag_snake would change to use that:
--- Code: easyuo ---sub findsnake gosub FindClosest %snakes 10 if ! #result { ; nothing was found in range or wrong number of parameters passed ignoreitem reset move 710 714 gosub findhole ; I still don't understand this statement in the original, but leaving the logic untouched } else { ; found a valid thing to use set !findid #RESULT ; we only need the ID from the snake, so no need to grab the other variables ; to follow the example in searching for the hole, you would do the namespace copy logic... }return;---------------sub tag_snake set %target1 !findid ignoreitem !findidreturn
baldielocks:
as always, good points!
FIrst, the find recursive logic. I did that because I did not think of going back to main loop! I was sorta thinking of preserving some time, but really, that is kind of illogical now. Orignally, I had the script moving back to a starting spot to restart the command, and I think that is what drove my decision to avoid going back to start.
Second, after fixing the bracket and ignore item (but not changing it to lists), the script still wound up clicking on the hole. I had to add a close cursor command to it. And if I am within 2 tiles of the hole, it still tend to double click it , which causes a reveal.
--- Code: ---;-----------------------------
sub charm
retry_charm:
gosub TM_AdvJournalSync FAIL
gosub TM_AdvJournalSync Charm
set #lobjectid %flute2
wait %lagwaits
event macro 17
wait %lagwaits
gosub TM_AdvJournalscan CHARM Valid recharge
wait %lagwaits
If #result = #true
{
wait 1s
set #targcurs 0
goto retry_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 10
gosub charm
}
wait 5
gosub worldxyztoscreenxy %xhole %yhole %zhole
click %_cursorx %_cursory
ignoreitem %target2
return
--- End code ---
Third, thanks for the catch on the egg loop. The end goal for the script is mostly stationary, with moves only when the targets (hole and snake) are out of 10 tile range. The max is 12 tiles, but I want to make sure I capture close snakes on the other side of the hole too. So, the idea for the Find_eggs is when I have done x amount of holes in a loop, to scan for all possible eggs, then restart. I will remove the return and see what it does.
Fourth, the finddist -1 is because that is what shows when you don't find and item. Again, not knowing tons of logic, I was not aware I could do two terms.
Fifth. I appreciate the array examples! I had not thought of using namespace. i am rather new to playing with that, and don't know it's full power, purpose, and scope. The documentation on helps so much. I find it funny that you named the sub find closest, because I am working on a sub for the same purpose with the same name. That's about all the resemblance though.
I can use parts of what you provided to help me get something that fits the script needs. Since snakes move so fast, so much in that area, i have found it is far faster and more reliable to find a hole, find the closest snake to that hole, then go to char. So, I have been told I will need to do and ABS calc of the snake #finddist and the hole #finddist to come up with the closest one to each other, but still within 12 tiles of ME.
Sixth. From what I can understand of the sample code, your example finds all holes within x distance of me, but I can't tell where it finds the closest. In my experience with #findid, it appears to start furthest out and go clockwise around the character. So, if I read it right, it will give me the first holes around me, but not an ordered list of closest to furthest. Closest to furthest will do several things for the script to speed it up. By the time it cycles through all the holes, all the snakes should be done, and when it re-est I won't have to worry about trying to re-charm a snake that is already charmed.
Things I don't understand from the first script sample, Find_closest.
1) if %0<>2 ; I have no clue to this.
2) set !SearchFor %1
set !finddist %2 + 1 ; initialize distance of closest item found
set !SearchDist %2 ;I think %1 is the type item, and % 2 it the desired distance?
3) I'm completely missing the point of the second code snippet.
This is the code I have been working on for the last couple days. Your seems so much cleaner.
--- Code: ---set %Search1 2 ; first search within 4 tiles
set %Search2 3
set %search3 5
;and so on
set %closestHoleID N/A
for %i 1 %holeCount
{
set %holeX %holeX . %i
set %closest ( %holeD - %snakeloc )
}
;still working on this part
--- End code ---
Gaderian:
You are correct about the purpose of the variables in my FindClosest sub (#2 in your post).
My sub for finding the closest, loops through and returns either #false (0) which means nothing was found, or it returns the ID of the closest item to you in #RESULT. You can go and get more information about it with my code example to copy info out of the namespace - which would be useful for the hole.
%0 is how many parameters are valid and passed into this sub.
%1 is the first one passed, %2 the second one, and so on...
if %0 = 2 then 2 parameters were passed and the variables %1 and %2 are valid until either the next gosub or call or set for those variables is performed.
The "gosub findhole" in the findsnakes sub... means the script will create a target for a snake which is really a hole for 1 round. I do not believe that is what you want at all. You want to restart the process.
I am attaching my version rewritten from your original post, with the changes discussed.
What is lacking is the start of the mainloop (after getting the egg and before looking for a hole to setup as a target), you want to do a calculation for an area with both a hole and a snake. This is where the combined absolute value of the relative distances between holes and snakes is important. You will move closer to that area, then do all the work you have written here.
You always check anything with if statements. Sometimes you need while, repeat/until or combine these with a timeout and validation when you exit the loop. It will add a lot to your script(s) resiliency going forward.
TrailMyx:
--- Quote from: Gaderian on May 24, 2021, 08:00:13 PM ---Sorry that I didn't mention the extra brace. I knew that, but deleted it from the version I was working with. I found it using the ScriptUO editor and it's Tools/Syntax_Error_Check menu option.
--- End quote ---
It does warm my heart to see people using this feature. Without a run-time error indicator in EasyUO, this type of error drove me crazy in my early days of scripting. Thus the feature in ScriptUO - for prevention of sanity loss.
baldielocks:
Holy cow Gaderian :o :o
Thank you for this huge boost. I never, ever expected this much help or work. I notice you left this padwan some work to do in the find_snake sub. I'm on it!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version