ScriptUO
Official ScriptUO EasyUO Scripts => Scripting Chat => Topic started by: lydaan on December 27, 2015, 10:52:22 AM
-
I'm sure a lot of you know I'm working on a mule gatherer script, and while I'm working out the kinks on my endless tinker tools sub I thought I'd start a disussion on travel subs. All this is in EUO, but the biggest problems I'm running into are UO related, and should apply to whatever you're using for scripts (unless it has built in spellcast waits and such).
First, let me describe what I believe to be an EUO limitation:
Sometimes the #ltargetid/event macro 22 0 screws up... it just doesn't target. I had a lot of problems with this in TM's travel sub, which was one of the contributing factors for me to try and make my own... At this point I'm convinced that event macro 22 0 just plain sucks, so I have a little bit of gosub travel spam in my script to compensate for when it fails. Don't think I can do much else at this point... whatever... it's fine enough... the fails are few and far between.
Second, and the crux of my issues, is cast recovery:
I've toyed with my journal scanner *a little bit* to no avail. The problem is I keep getting "You have not recovered..." which makes it loop, until it hits my *fix* which returns from the sub when "That location is blocked," is displayed. Not the best fix, but solves the problem for my script, but much slower than what I'd like. I've put event sysmessages (for debugging) just about everywhere I can think of, but have hit a wall, and want to get the other parts of my script working in the meantime, since it "works," anyway. At this point, I think the sub is failing, because of my lack of understanding of Cast Recovery, and all my mules have 0 FCR. I think that other things are making "You have not recovered..." post, making my travel sub loop.
My goal is to have as many things as possible have non-static waits, and I strongly believe that travel is one of them.... I tried #charposx/y before and after travel, but the update seems to be real slow on charpos, as I wasn't able to get that to work at all... so right now, if it hits cast recovery, it loops one time until it returns "That location is blocked."
So, here's my travel sub so far... it's a little dirty, but I think that the meat is there. Oh, and it's only recall right now... just wanted to get this working.
recover:
set %jStart #jIndex
set %manacheck #mana
event macro 15 31 ;recall
target 5s
event macro 22 0
set %jEnd #jIndex
set %closerbx #contposx + 250
set %closerby #contposy + 130
if #contsize = 452_236
click %closerbx %closerby r
set %journalrange %jend - %jstart
event sysmessage scanrange = %journalrange
for %i %jStart %jEnd
{
scanjournal %i
if you_have_not in #journal || More_reagents in #journal
{
msg wait, wut?$
msg omg$
msg I'm so stupid...$
wait %recovertime
goto recover
}
if That_location in #journal
{
wait 10
return
}
}
if %manacheck <= #mana
goto recover
wait %recovertime
}
return
Thanks all. Just hoping to start a discussion on travel subs, and what they need to work flawlessly
Lydaan
edit* posted a non working travel sub... fixed
-
you have not recovered is very annoying... you basically have 2 approaches... (1) like what you done above detect and wait or faster (2) do a search on here or on stratics you will find formulas that will tell you the recovery time based on FCR and other factors. You can use that information to create a wait sub that will examine last time a spell was caste and wait the faction of a second you need to wait before attempting another spell.
Option (2) will eliminate the "you have not recovered" msg entirely and end up with faster character spell casting... but optin (1) is far easier to implement.... :)
Option (3) is to add some FC and FCR to your character...
-
Thanks EN!
Since I FINALLY got my endless tinker sub to work well enough for my mules (ran all night on 3 accounts), I'll be looking into this before I post my miner script... getting REAL annoyed watching them cast recall 2 and 3 times before continuing.
Option (1) was fine to move on, and a good starting point I think
Option (2) is definitely what I WANT to do, and WILL do (thanks for pointing me in the right direction)
Option (3) is the ultimate goal so I get all the ore... ;)
P.S. Once I get endless tinker to not fail on my lockpick selling script (spams #property updates too fast and fails), I'll post that in it's own thread.
-
I thought I'd update this with what I did for now... will be working on scanjour/wait for journal stuff later
I could not for the life of me get scanjournal to see "fizzles," and #mana doesnt always update fast enough, so I have a few fail-safes to catch that
set %fcr 0
set %spcr 1500 - ( %fcr * 250 )
set %startcrwait 0
sub travel ;<book/back/home> <rune>
set %manacheck #mana
set %xcheck #charposx
set %ycheck #charposy
if %1 = home
{
finditem %homerunebook * c_ , #backpackid
set #ltargetid #findid
}
else
{
finditem %book * c_ , #backpackid
set #ltargetid #findid
}
set #ltargetkind 1
if %1 = nextrune
{
event macro 8 7
openbackpackwait3:
if #contsize <> %backpackcontsize
runebookopenbreak:
set %runebookwaitcnt 0
set #lobjectid %book
event macro 17 0
runebookopenwait:
if %debug = yes
event sysmessage Your Runebook # , contsize is #contsize
set %runebookwaitcnt %runebookwaitcnt + 1
if %runebookwaitcnt >= 5
goto runebookopenbreak
if #contsize <> %runebookcontsize
goto runebookopenwait
wait %genericwait
position:
contpos 150 200
if #contposx <> 150 && #contposy <> 200
goto position
set %pageclicky #contposy + 197
if %2 = 1 || %2 = 2
set %pageclickx #contposx + 140
if %2 = 3 || %2 = 4
set %pageclickx #contposx + 175
if %2 = 5 || %2 = 6
set %pageclickx #contposx + 210
if %2 = 7 || %2 = 8
set %pageclickx #contposx + 245
if %2 = 9 || %2 = 10
set %pageclickx #contposx + 310
if %2 = 11 || %2 = 12
set %pageclickx #contposx + 345
if %2 = 13 || %2 = 14
set %pageclickx #contposx + 380
if %2 = 15 || %2 = 16
set %pageclickx #contposx + 415
set %defaultclicky #contposy + 26
if %2 in 1_3_5_7_9_11_13_15
set %defaultclickx #contposx + 164
else
set %defaultclickx #contposx + 304
click %pageclickx %pageclicky
click %defaultclickx %defaultclicky
}
recover:
manarecallwait:
if #mana < 10
goto manarecallwait
spcrwait:
set %endcrwait #systime
set %checkcrwait %endcrwait - %startcrwait
if %checkcrwait < %spcr
goto spcrwait
event macro 15 31 ;recall
target 5s
event macro 22 0
set %jupdate #jindex
set %jupdate1 #jindex + 1
set %startcrwait #systime
set %closerbx #contposx + 250
set %closerby #contposy + 130
if #contsize = 452_236
click %closerbx %closerby r
jindexupdatewait:
if #jindex = %jupdate ;|| #jindex = %jupdate1 ;second one is to catch "select marked item" ... need to test more
{
if %xcheck <> #charposx || %ycheck <> #charposy
return
goto jindexupdatewait
}
scanjournal 1
if More_reagents in #journal || You have_not in #journal || %manacheck <= #mana ;|| The_spell in #journal
(
goto recover
}
set %fizzlecheck 0
poswait:
event sysmessage I was supposedly at %xcheck %ycheck | but I'm supposedly at %charposx %charposy
set %fizzlecheck %fizzlecheck + 1
if %xcheck <> #charposx || %ycheck <> #charposy
goto poswait
if %fizzlecheck > 8
(
goto recover
}
return
*edit* delted internal debug and added dependant variables
-
OK.... WTH??????
Finally got my travel sub working.... could someone please tell me why this is happening???
recover:
manarecallwait:
if #mana < 10
goto manarecallwait
spcrwait:
set %endcrwait #systime
set %checkcrwait %endcrwait - %startcrwait
if %checkcrwait < %spcr
goto spcrwait
event macro 15 31
...
if More_reagents in #journal || You have_not in #journal || The_spell in #journal
goto recover
writing my journal catch without brackets, like that causes it to just keep recalling until it hits my that_location_is_blocked --> goto return catch (which so far has been the next time...)
BUT....... >:( Writing it WITH brackets...
...
if More_reagents in #journal || You have_not in #journal || The_spell in #journal
{
goto recover
}
makes it work fine... WTH????
-
Thats strange it shouldn't make any difference..
The only times to my knowledge that you must use {} on an if... is if you have more than one line of code to execute after the condition is met or if you use an else command
ie if ... { } else { }.
-
Thats strange it shouldn't make any difference..
........ well....... >:( >:( >:(............ ONE week of head smash keyboard down..............
The only times to my knowledge that you must use {} on an if... is if you have more than one line of code to execute after the condition is met or if you use an else command
ie if ... { } else { }.
in my experience else doesn't need brackets either if it's one line....
if stuff true
do this
else
do that
BUT.... >:( >:( atleast I found another EUO bug to look out for....