ScriptUO
Official ScriptUO EasyUO Scripts => Script Debug => Topic started by: baldielocks on July 21, 2010, 10:17:30 AM
-
~edit. Incorporated below changes. Could use a debugger if anyone is willing. At work for another 8 hours.
Set up: must have (currently) gorgon lens made from bright blue scales (from living medusa). Must have helmet and gorget slots filled with items that can accept charges.
;===========================================================
; Name: Gorgon lens charge scanner
; Author: Baldielocks
; Version: 1 Beta
; Easyuo Version : 1.5
; Client Version : 7.0.7.3
; Purpose: Scans gorget and helmet slots for lens charges, applies more if needed and in pack.
; Special Thanks:
; Trailmyx for his gump wait and offset click subs and ideas. And for SUO utility and the site!
; Twinkle McNugget for advice and his ignore item sub.
; Just Another Face for advice on logic writing.
; Massacre for finding my first bug
; Cervesa for the pointer on sub writing.
; Changelog: Beta version 1, 21 July 2010 :
;Corrected flow issues and logic as identified by Cervesa and JAF and everyone else in the thread.
; Info. Must have perfect lens in pack (made from birght blue medusa scale).
; I inserted a hard pause in the script to avoid unintentional loss of lenses by beta testers.
; Remove or comment out if it works smoothly.
;===========================================================
-
This is not your current problem but could be a later problem.
gorgonlens:
finditem %gorget
gosub scan %gorget
finditem %helmet
gosub scan %gorget (should be %helmet)
goto gorgonlens
halt
-
I am trying to code a gorgon lens charge scanner. If gorgon is not in #property, script will charge the item.
For some reason, it is not detecting it. Ideas, suggestions, denigrating remarks on my coding skills?
set %lens VTO ;currently only detects lens from live medusa (bright blue scale)
event sysmessage set gorget / necklace for charge scan
set #targcurs 1
while #targcurs = 1
wait 1
set %gorget #ltargetid
event sysmessage set helmet / glasses / earring for charge scan
set #targcurs 1
while #targcurs = 1
wait 1
set %helmet #ltargetid
gorgonlens:
finditem %gorget
gosub scan %gorget
finditem %helmet
gosub scan %gorget
goto gorgonlens
halt
sub scan
;%1 = item to scan id
event property %1
if gorgon || charges notin #property
{
finditem %lens C_, #backpackid
if #findcnt = 0
{
display out of lenses, halting
halt
}
set #lobjectid #findid
set #ltargetid %gorget
event macro 17 0
while #targcurs = 1
{
wait 1
}
event macro 22 0
gosub gumpwait waiting_gump 203_121
gosub OffsetClick 268 184
wait 15
return
;---TM's offset click sub
sub OffsetClick
set %tempx %1 + #CONTPOSX
set %tempy %2 + #CONTPOSY
click %tempx %tempy
return
;---TM's waitgump sub
sub GumpWait
wait 10
set %timedelay #SCNT
loopwait1:
if #CONTNAME = %1 || #CONTNAME = %2
return
if #SCNT > %timedelay + 7
return
goto loopwait1
return
I believe this line
if gorgon || charges notin #property
Should be like this
if gorgon notin #property || charges notin #property
JaF
-
sub scan
;%1 = item to scan id
event property %1 ; also here you do not have %1 declared so the script does not know what to do with it
if gorgon || charges notin #property
-
It's in there mass...
gosub scan %gorget
so %1 = %gorget
Though I usually convert them in the sub so I know what they are....
sub whatever
set !gorget %1
-
sub scan
;%1 = item to scan id
event property %1
Wait 20
if gorgon || charges notin #property
{
finditem %lens C_, #backpackid
if #findcnt = 0
{
display out of lenses, halting
halt
}
Event property Takes time to Return a Result.. Your trying to read the properties of the item and continuing on before the item has returned those properties.. or at least that will happen commonly though perhaps not every time. You can use a simple Wait to increase your odds that #property has updated but it's not bullet proof.
-
Thanks all! Hey I'm still learning! But making progress. Thanks for catching the %helmet! That will save some problems. And will work on declaring the carry over variables in all my scripts.
Wrote this pretty fast, so did not refine it yet for release. (was actually fighting medusa when I wrote it lol, gotta love even the non-elite the whammy assitant).
So, to summarize, change the order as JAF suggested, and add in a wait as Alpha suggested.
-
What Alpha described is due to your ping / lag. If you have no lag then event property will generally return without issues. However as a general rule it is a good idea to put in a short wait to account for any lag and to let the event property command actually process before jumping to the next line of code.
Cerv is also correct of course! I was typing basically the same thing Cerv typed and hit post and saw that there was a new reply, Cerv beat me to the punch! lol
JaF
-
In my experience, if the property is updated in the client, which most things are if you have been logged in for a minute or two, you can event property them instantly. I just took out all the waits in my plant tender, and it scanned 127 plants in 302 seconds with no waits by the event property. Its scanning things that need to have their info updated by the client that you need to watch for. Like house signs... Or characters that recall in next to you... scanning their armor with no waits for the info to update could come back with wierd results. But scanning things that are on your screen and have been there and their info has been updated by the client.... you're good to go. Thats been my experience. If you're running around scanning things, you're gonna miss stuff because it hasn't updated to the client by the time you scan it. If you're scanning your own armor, just close and open your paperdoll, and the info should be updated by the server. Then you can scan it as much as you'd like.
-
Baldie,
The way I understand it is this: (and I may be absolutely wrong, anyone who knows any different than this please post)
if gorgon || charges notin #property
The natural way to read that statement is.....
If gorgon or charges notin #property
DoSomething
the OR statement is described in EUO docs as follows:
%a || %b Or If either one of the values evaluates as true, the expression is true.
I read that to mean that basically the value on the right and the left of the || command have to be FULL values. As if they were two totally seperate lines.
In other words your code would read like this:
If gorgon
do something
if charges notin #property
do something
Do you see the problem now? If gorgon is not a full statement... if gogron, what?
So the correct way to make it perform the function you want would be
if gorgon notin #property || charges notin #property
do something
That would read on two seperate lines like this:
If gogron notin #property
do something
If charges notin #property
do something
Hope that helps! Again, if anyone knows that it functions any differently please post and explain, because I may have it all wrong also. But thats the way I handle the && and || statements.
Oh yeah I realized i forgot something. The IF at the beginning of the line is implied to follow every || &&. Thus you dont need to type the IF all over again following a OR / AND command.
JaF
-
Incorporated all suggestions. Thanks everyone. If only I could test it at work. Anyone willing to try? Just need an item with charges, and without. Put a safety pause in scipt to avoid losing charges should this not work.
-
one limitation i see currently is inability to select one or either or both gorget / helmet. Think this would be a good addition? Gonna add a menu anyway, so these checks would not be an issue to include.
-
Got it to detect reliably. BUttttttt. I can't get it to target an item in paperdoll. Any tips?
-
Here's a clue... Your paperdoll is a container. ;)
-
Exevent drag it to your backpack, then do your think and drop it back on your paperdoll? :) I'm not sure.... I'd have to look too.
-
thanks c!. drag from PD is not the best solution, if you are actively fighting. That might be bad. Will try container option later today
-
Search for the id of your arms/gorget inside the paperdoll container and set it's id to #ltarget and target it? I don't know if that would work or not, I don't do anything that needs that kind of functionality and haven't read your script to see. Too much other code to look at. :) I'm starting to feel TM's pain when people ask him to look at stuff. hah
-
I had the targetting right, but not the container to search in. Will fix after work. Got three days of scripting ahead! Yay!
-
Here's a clue... Your paperdoll is a container. ;)
Pretending I aint sherlock, what if I need more than one clue? I think i need a trail of freaking breadcrumbs. I understand what you infer, but have no CLUE ( :P ) as to how to target it still. been reading up in documentation. That is hit or miss, because there is sooo much.
The finditem is working well, and accurately detecting charge state. Should I use #findbag to detect the paperdoll?(still at work, so cant check on my own).
-
It's not what you look for, it's where you look for it....
-
It's not what you look for, it's where you look for it....
>:( . To quote my kidz. MEANIE HEAD. *looks under paperdoll* Hey, ummm, did you know they are VERY anatomically correct?
-
Certainly you are getting close to discovering what is
Hidden in the clues.
Are you getting tired of my posts?
Really?
I think if you just paid some attention it would all become
Deliciously clear.
-
too broke to pay attention. :P
seriously, considering all options and thinking out of the box though.
-
Okay, I get this part
finditem %gorget , #charid
gosub scan %gorget
finditem %helmet , #charid
gosub scan %helmet
goto gorgonlens
But still stumped on this part. I can FIND it there, but how do you make it TARGET there? is there a variable associated with it? (runs off to documentation)
}
set #lobjectid #findid
set #ltargetid %chargeditem
event macro 17 0
set #targcurs = 1
repeat
wait 10
event macro 22 0
until #targcurs = 0
}
Orrr, change to click location?
-
EUO is pretty picky about what types of items it deals with ;)
-
One thing: event macro 17 is last object. If you're using a scale, I'm assuming that you're getting a cursor to use on the item. You don't set the cursor to 1, you wait for the cursor to become 1 after using the object with event macro 17. And there's a command for that. :)
-
Here's a clue... Your paperdoll is a container. ;)
You seem to be having some problems wrapping this idea around your head........ think about it... how do we deal with containers? If you had a container on the floor, how would you drop something in it? Stumble onto one little tiny tiny piece of code, and listen to Twinkle McNugget's last suggestion and your most of the way to your destination :)
JaF
-
I am having a problem, but not in the way you imply JAF. Thanks for stepping in to try to pull my head out of the sand though! Might need more than three it seems at this rate.
Since this is a combat situation, removing items from PD is dangerous (you only need to recharge gorgon lens because you are currently fighting medusa). I need another way around that, as I cant see myself releasing a script that could get you killed. I currently use 3-4 charges per medusa, and suspect that others do as well. This and a companion script will greatly reduce the danger of statues.
As to handling containers, I think I finally got a decent handle on that:
find and set %stuff in pack
find and set %boxonground G_ ,
findcnt || findkind to verify in G_ radius.
If true,
then drag %stuff
dropc %stuff in pack to %boxonground.
Since the items I want to charge are in a container, and I get that, the only way to directly target something in it SHOULD be target last (like when we used to steal from paperdolls), or a click with target cursor = 1 at contposX Y or finditem X Y. Thats where I am having issues.
@Twinkle McNugget. Thanks for the reminder. I guess I should be using the target command then? default is 2 seconds, unless an argument (is that the right term?) is added (3-5 being the most common)? target 5s (5s is argument, correct?)
There's also event macro 25 0, wait for target, that could be used as well. Not sure if you would have to use event macro 28 0 (wait) in conjunction though. I never coud get that to work right in the client.
-
All of that typeing and you didn't catch it.... hmmm
-
Waits for targets are all pretty much personal preferfence just remember that euo forces you to wait that amount of time before the script will continue so having long target waits like 5s isnt always a good thing, it depends on the situation really.
-
ONe najor drawback here is that I cannot leap into UO / EUO to experiment. Still a ways from being able to forecast results from memory. But I am working on it still!
-
Here... when you target something make sure to set it's type.
findItem %whatever C , #charID ; finds whatever type in your paperdoll
if #findCnt > 0 ; if it's not there then skip this part
{
set #ltargetID #findID ; now your setup with #ltarget for doing stuff
set %target #ltargetID ; not *needed* but I like it
set #ltargetKind 1 ; HERE YOU GO... make sure that's set correctly@!
do stuff
wait a bit
do more stuff
etc......
}
-
Thanks C for that. Now, for more explanation, cause THAT's apparently my weak spot ( in this discussion, got plenty more to explore!)
LTargetKind Values
Setting Object Class
1 Object
2 Ground,Mountains,Caves
3 Resource: Tree,Water
Note: Not setting #LTargetKind (usually to 1) is by far one of the most common mistakes made when scripting. Simply put, every time that you use Event Macro 22 you must always make sure #LTargetKind is set properly or you will most likely have sporadic targeting problems.
So that's why everyone does that? GOtcha. Now, do peeps / monsters count as objects for this as well?
-
So that's why everyone does that? GOtcha. Now, do peeps / monsters count as objects for this as well?
They sure aint Ground, Mountains or Caves! Heh... or resources, tree's or water for that matter....
-
Here... when you target something make sure to set it's type.
findItem %whatever C , #charID ; finds whatever type in your paperdoll
That line in Cerv's code example is what I, and Cerv were trying to get you to understand. Your finditem statement needs to define where to look for the item. In this case it is looking for the items in a container... yes your paperdoll is a container. So you would set it exactly like Cerv pointed out:
Finditem %item C_ , #charidThis tells the script to search for what ever your %item has been defined to, Inside a C_ (Container) , and the container happens to be #charid... your paperdoll.
Finditems are defined here for your reading http://wiki.easyuo.com/index.php/FindItem (http://wiki.easyuo.com/index.php/FindItem)
JaF
-
I am having a problem, but not in the way you imply JAF. Thanks for stepping in to try to pull my head out of the sand though! Might need more than three it seems at this rate.
Since this is a combat situation, removing items from PD is dangerous (you only need to recharge gorgon lens because you are currently fighting medusa). I need another way around that, as I cant see myself releasing a script that could get you killed. I currently use 3-4 charges per medusa, and suspect that others do as well. This and a companion script will greatly reduce the danger of statues.
As to handling containers, I think I finally got a decent handle on that:
find and set %stuff in pack
find and set %boxonground G_ ,
findcnt || findkind to verify in G_ radius.
If true,
then drag %stuff
dropc %stuff in pack to %boxonground.
Since the items I want to charge are in a container, and I get that, the only way to directly target something in it SHOULD be target last (like when we used to steal from paperdolls), or a click with target cursor = 1 at contposX Y or finditem X Y. Thats where I am having issues.
@Twinkle McNugget. Thanks for the reminder. I guess I should be using the target command then? default is 2 seconds, unless an argument (is that the right term?) is added (3-5 being the most common)? target 5s (5s is argument, correct?)
There's also event macro 25 0, wait for target, that could be used as well. Not sure if you would have to use event macro 28 0 (wait) in conjunction though. I never coud get that to work right in the client.
Hmm, not quite... read my post above, then take a look at this code from a pot chugger script I wrote.
sub disarm
{
finditem %lhandtypes C_ , #charid
if #findkind <> -1
{
set %lhanded #findid
set #lHandID %lhanded
wait 2
event macro 24 1
}
finditem %rhandtypes C_ , #charid
if #findkind <> -1
{
set %rhanded #findid
set #rHandID %rhanded
event macro 24 2
}
wait 20
}
return
display ok disarm exited without return
This code finds the items I defined earlier in the script called %lhandtypes. It finds them in the C_ (container) , #charid (paperdoll)
it sets a %lhanded to the #findid
then it sets the #lhandid to the %lhanded (which is the #findid)
it waits 2
then it uses the event macro for disarm.
goes to the next line and searches for %rhandtypes ....... etc etc etc.
also, a tip I learned a long time ago, is when trying to debug your code to see if your subs are exiting correctly with the return, put in the display line after the return. If for some reason the script jumps over the return line, you get a display popup telling you that your sub (helpful to define what sub) exited without a return
Hope this is starting to make more sense...
Listen closely to Cerv and his hints... he is more often correct than mistaken :)
JaF
-
it does, it really does. If only I could experiment, would really understand. Am a kinesthetic learner by nature. Thanks JAF and Cerv!
Will have more questions once we can use EUO again.
-
>:(
Still having targetting issues. As review, I want to target either a neck or helmet slot that had gorgon charges, and recharge it when it reaches 0. My issue is getting the lens targetted on the item in the paperdoll.
gosub TM_AdvJournalSync LENS 100
set %lens VTO
finditem * C_ , #charid
For #findindex 1 #findcnt ;just for Twinkle McNugget. Ignore anything not currently holding a charge.
;Obviously, you would want everything fully charged before fighting medusa.
{
if #findkind = -1
break
event property #findid
if Gorgon_Lens_Charges notin #property
ignoreitem #findid 1
}
gorgonlens:
gosub TM_AdvJournalScan LENS VALIDADVANCE crumble_you_are_no_longer_protected
If #result = #true
{
finditem %lens C_ , #backpackid
if #findcnt = 0
{
display out of lenses, halting
halt
}
}
set #lobjectid #findid
finditem * C_ , #charid ;onnly gorget and lens should be left in paperdoll
For #findindex 1 #findcnt
{
if #findkind = -1
break
event property #findid
if Gorgon_Lens_Charges notin #property
{
set #ltargetid #findid
set #ltargetkind 1
event macro 17 0
target 3s
event macro 22 0
ignoreitem #findid 2
}
ignoreitem reset 2
wait 10
if #contsize = 291_99 && #conttype = generic_gump
{
menu text euoedit3 problem detected, please report to baldielocks on scriptuo.com
halt
}
}
goto Gorgonlens
halt
-
Im on my cell in the docs office but browsing your code it looks like your wait 10 there should be a wait 20 and be moved inside the if statement with the actual targetting... you dont want to wait when executing a script unless necessary.. I even find ways to utilize the time in a wait to execute code sometimes. Theres no reason to perform a wait right after targetting unless you are performing another action that requires a wait. Sometimes Ill just set a timer for the wait timer and check that timer when another action néds to be performed, that way you are really using your time better and spéding up ur script.
-
wow, that is AWEEESOMMEEE :o *scampers off to sliem quester to change timers*
As to the wait 20 vice a wait 10, why would that be? I have seen that in some scripts you also use a wait 5 after find item. should I incorporate that too?
-
wow, that is AWEEESOMMEEE :o *scampers off to sliem quester to change timers*
As to the wait 20 vice a wait 10, why would that be? I have seen that in some scripts you also use a wait 5 after find item. should I incorporate that too?
If I ever used a wait 5 after a finditem, it was an accident. No reason to do that.
-
Here's what I do for things like yours now. At the top of your script you'd need to "initialize" or set the variable %timer to #systime. Or "set %timer #systime". That way your first run of the script has a variable to compare the while statement below to. Also, findkind is outdated. You should really be using #findcnt. #findcnt is reliable because if you find the item, it's > 0. If not, It's 0. Easy. Anyways, doing the timer like this allows the script to continue to execute, but waits the appropriate time before allowing the action to happen again. Does that make sense? So instead of forcing a wait AFTER an action, you can do all manner of others things, and before the action can happen again, it checks to see if the wait is up or not FOR another action to be able to take place. Allows you to do all sorts of things in between waits. Like calculate stuff. Or check for overweight... or whatever really. Anything you can think of. I hate wasting time, and also like to optimize things to their fullest. I'm gonna go through the PVM Dexer eventually and do this with ALL waits, so the script will be more responsive than a script of that size should be.
For #findindex 1 #findcnt
{
if #findcnt < 1
break
event property #findid
if Gorgon_Lens_Charges notin #property
{
while %timer > #systime
wait 1
set #ltargetid #findid
set #ltargetkind 1
event macro 17 0
target 3s
event macro 22 0
set %timer #systime + 1000
ignoreitem #findid 2
}
ignoreitem reset 2
if #contsize = 291_99 && #conttype = generic_gump
{
menu text euoedit3 problem detected, please report to baldielocks on scriptuo.com
halt
}
}
-
Thanks Twinkle McNugget! really appreciate it. Gonna work it in and see if that helps the targetting issue. Been considering a single click on findx , findy as a work around.