ScriptUO
Official ScriptUO EasyUO Scripts => Scripting Chat => Topic started by: Alpha on March 03, 2011, 09:17:11 AM
-
Ok.. so the problem I'm running into is how to determine when the #property variable has actually updated (or not) AFTER performing the "event property" command. If I'm running through the #findindex of a bunch of similar items I cannot simply check #property bc I don't know if it's actually Changed (or if it's still display the LAST item's info) if that makes sense. If #property could be written too I would simply set it to X or something perform my "event property" but other than simply adding a hard wait after that command how do you guys go about it? I guess I'm looking for the equivalent of a "Sub GumpWait " basically. If that's clear as mud I'll go dig up what I was using & post it etc.
-
Not sure what your doing... but normally the order of operation is:
find the item
event property #findid
then do your checks... like
if THIS in #property
It looks like you want to store all the info from the #property and compare it to the next item?
-
Are you thinking that it executes the if BLAH in #property before it actually updates in the variables? Interesting idea. I have never noticed an issue there. If you do what Cerveza said, the info is typically there in all of my experiences.
-
He's running a property on items whose #property haven't updated from the server yet. The problem is that you get nothing back when you do a property on these types of items. There is no real gumpWait for this type of action. The best thing to do period is avoid use of #property in these situations if you can. There's ALWAYS a way to do it without #property. And if there's not, you shouldn't really use it in your situation. Post code. Someone will be able to help you I'm sure. The only real times I can think of when info wouldn't be updated is on the run. You can run into this while trying to event property people/items while running through town right after logging in. Or while pvping. Most property information wont update while you're moving either. You need to stop for a split second for it to update. This was a lag fixing measure imo. You don't feel the lag of downloading that info to your client if you're not moving. If it does it on the run tho, you get lag spikes constantly while running around lots of people/buildings.
-
ah.. i see
good example of why that happens.
I had a preventative measure in a couple of my scripts for this. if i event prop an item and get a N/A or whatever i drag and drop and item back into my pack. then i can read all the items in my pack again.
-
Hmmmm......
He's running a property on items whose #property haven't updated from the server yet
I'm not clear on what you meant with that statement. All I can come up with is Items that were recently spawned / crafted ? If that isn't the case are you trying to say that "event property" takes time before it actually updates the #property value? (that's the way it works as far as I can tell but the time is sooo small I haven't tried measuring it.
Ok.. here's a quick example of something I've done a ton & I don't quite know why it doesn't work. This is just a quick snippet I wrote to lockdown my plants etc.. but when doing ~1600 ish plants I inevitably have to run this x 2 to get them all though I'm not sure why it misses stuff. The only thing I can think of atm is that if #property is still Displaying info from plant #1 when it should be displaying #property for plant #2. Then effectively it would register plant #2 as locked down even though it isn't & skip the lockdown part. Anway... just a timing issue with event property etc I think. I didn't know about the moving aspect of it though which makes alot of sense (player scanners & such not functioning in certain cases)
Finditem QLI ;--Should be a bowl of dirt unless I changed it for some reason lol.. can't check atm.
set %wait 1 ;---Increase this if you find yourself running the script more than 1x. 5/10/15 etc
For #findindex 1 #findcnt
{
set %plants_remaining #findcnt - #findindex
event sysmessage Number Remaining %plants_remaining
event property #findid
wait %Wait
If Locked notin #property
{
Msg I wish to lock this down$
Target 2s
set #ltargetid #findid
set #ltargetkind 1
event macro 22 0
wait 15
}
}
Display OK Your Almost Done. Run it again to make sure heh!
halt
Anyway.. hope that makes it more clear... THX.
-
Your problem isn't your event property. You need to look at some better scripts for better examples of what to do. The CLAw parses thousands of items without missing an event property, I've written scripts that craft and evaluate thousands of items with it. Probly a good example of how to use event property in there.
-
Ok ive encountered this sort of thing many times before. Only way to counter it is if you know something about the property string you should be recieving... Hopefully something at the end of the string that you always will see. You then check for that existing in the property string and loop until you get it.
-
What you want to have in an event property sub is a check for a keyword found in the item you are looking for.
With just about every item in the game for instance you can just check for the word stone in the property to check if its updated.
-
The problem he's having is obvious in the code above guys. heh
I'm a bit rusty so Pray enlighten us...
-
@ ManW / EN .....
Yea I'm aware of how to check that #property has actually returned a value usually by looking for a specific word or checking that the string length is greater than 1 etc.. but This method doesn't work when your dealing with multiple items that are all exactly the same. I've based all this on the assumption that "event property" Takes time to update the #property Value & that I have to account for that in my scripts but it just occurred to me that the needed waits could be built into the event... hmmmm Anyway here's where I was having the prob.
Ex...
Item #1 #property Value =
A Vibrant Plain Prickly Pear Cactus Plant$Weight: 1 Stone$Locked Down$
Item #2 #property Value =
A Vibrant Plain Prickly Pear Cactus Plant$Weight: 1 Stone$Locked Down$
The Strings are exactly the same.... So after performing the event property on Item #2 how do you know when the #property Value is actually updated for Item #2 & is no longer showing Item #1 ?? Hmm... lemme see if I can actually break event property intentionally...
START:
event property X ;---Invalid ID simply to clear #property to $
set #strres 0
str len #property
If #strres <> 1
pause
event property #lliftedid
set #strres 0
str len #property
If #strres < 2
pause
set %cnt %cnt + 1
event sysmessage Count = %cnt
goto START
OK... Well It looks like I can't get event property to mess up in over 1000 events so It's gotta have all the necessary waits built into it. I guess that answers my question heh. This way when dealing with multiple identical items I can simply assume that #property is up to date after performing an event property. I was thinking it would be like gumps where you can easily be displaying info from your LAST gump if you don't have the appropriate gumpwaits to insure your NEW gump has had time to open etc.. Anyway Thx . Oh & Twinkle McNugget I do realize the timing issue in the lockdown script is probably the wait 15 being too small to prevent a spam message, but the last time I'd tried it It worked in 1 try with that. I usually don't bother posting here though unless I've already tried fairly hard to solve the problem myself though.
-
It's absolutely the wait 15. I was sure someone would catch it. Funny. You cannot try to do it too fast, or you'll skip some plants. It's that simple. Timing in EUO is EVERYTHING. 90 percent of all the stuff you do will require precise timing. You didn't understand what manw said, and he was correct, you absolutely can wait for the property to update by checking it like the code below. Probly not the best way, but it sure is A way. I'm pretty sure that #property resets itself when you call it, so you're wrong in that it DOES work with lots of items with the exact same names. There are waits built into an event property, hence why I said you should try to avoid using it as much as possible. It's a slow function to call. You're still not understanding it, but you'll get there. The built in wait for event property is just that, a built in wait. It does NOT wait for the property to completely update, it just waits to SEE if it will update, and if it doesn't, it moves on. I've seen all of these situations happen at some point, most happen in different situations. In yours, you can pretty much assume the #property info will update correctly and on time because you're standing still on screen with all your plants and all the info will already be updated to the client before you run your script.
event property #findid
set %timer #sysTime + 1000 ; This timer would need to be played with.
while plant notin #property || %timer > #sysTime
wait 1
if %timer < #sysTime
; Re property the item?
If you put that inside your #findindex loop, it might help you understand better. There's a few other ways to do it tho. You do know to hit F6,F7,F8 to step line by line through a script correct?
-
Yup yup, Twinkle McNugget be right :)
-
Twinkle McNugget Said:
I'm pretty sure that #property resets itself when you call it, so you're wrong in that it DOES work with lots of items with the exact same names.
Ok I'm not quite sure if I understand that fully. Is what your saying that when I perform an 'event property' the #property Variable will be 1st Wiped clean & 2nd be updated with the #property of the item? Since you were discussing additional error checking to make sure #property has updated I know the 2nd step can apparently Fail / Take too long but can the 1st step Fail? (the wipe) I'm still unsure of how to tell if #property has updated when you use "event property" on 2 identical items back to back. The return strings in #property will be EXACTLY the same so after you perform the 2nd "event property" do you just assume it's correct? can it fail etc? If I could clear the #property Value then it would be easy but without performing a "event property" on an invalid object etc #property will still contain the value from the last time etc. Hope that makes it more clear. I know simply adding hard waits can accomplish what I'm trying to do I just didn't know what the RIGHT way to do it was.
Ex...
event property %plant_1
;--#property = A Vibrant Plain Prickly Pear Cactus Plant$Weight: 1 Stone$Locked Down$
event property %plant_2
;--#property = A Vibrant Plain Prickly Pear Cactus Plant$Weight: 1 Stone$Locked Down$
Your code snippet makes perfect sense IF the act of 'calling' event property will clear the #property value 100% of the time. Then it's just a matter of checking to see if it's updated yet. I just didn't realize that it potentially worked in that manner & that #property would still be displaying the value from the last object..
-
What Twinkle McNugget was saying as I understand it is that yes... when you are standing in one place and not moving about the steps one and two happen without a hitch. I have had to move an item in my pack once or twice because properties were not showing in the past and then it is fine from then on.
He was trying to make the point that as you run around or do other things that may produce lag, event property still updated just as fast but the UO client does not always show the items properties fast enough to be updated in an event property. An example is in my intruder alert script. If i am moving around a lot or running and come across a NPC, it triggers the alert because even thought the name is in my ignore list, the property was slow showing and easy uo read the item type before the property on it was updated in the UO client.
In your case, Twinkle McNugget was saying that since you are standing in one place, there should be a lot less lag and things should update in a speed that is not an issue. It should be clearing 100% of the time. If you are watching the variables though, it looks the same. It never goes blank and then reloads... it just switches to the next which is identical instantly. no lag should equal 100% accuracy.
I do not think you got your answer that you were seeking though. I am not sure if you can set an event property to N/A in between each scan to see evidence of the change when scanning each item. In your case, you are standing still. So in this case, Twinkle McNugget was saying that you are not moving and basically should not be experiencing a delayedrepresentation in event properties as described above. Therefore, properties should be accurate.
Try:
event property #charid
wait 20
set #property N/A
halt
and see if the event property changes.
That may or may not be 100% what the gist was but that is what I got when skimming through the posts. :) Twinkle McNugget please jump in and further clarify if I unintentionally misrepresented any information.
I also gathered that your event message is possibly conflicting with your lock down message because there is not enough between messages which could cause a possible timing hitch. I have never tried mixing the two as exevent messages tweak me out, despite only being client side. I just feel like GMs would see it somehow in the journal etc. That is a diff story.
-
A good example for me is with my IDOC hunter. Generally, you should always get a #PROPERTY back from a sign, but there are times when you are walking around WITH THE MOUSE (right click) that #PROPERTY comes back N/A. So to fix this, what I do is force the character to stop (mouse click 0,0) and re-do the event property. When you aren't moving, the #PROPERTY shows successfully. (this is why everyone likes my IDOC hunter because I handle all those signs that are "skipped" by other scripts)
A caviet to this is when you lock in your movement (always walk or left-click -> right-click) and move that way, event property magically starts working without issues. Never tried to understand that dynamic, but I adapted to it and continued. So I'm not certain the issue is actually lag because moving with right mouse depressed can bork the event property, but moving with autowalk lets event property work correctly.
--- Added
Also, there are creatures that never return a #PROPERTY. Try it on an Orge. ;)
-
Awesome... That helped alot... It explains why my "People Detector" does fail on certain blue NPCS occasionally bc the event property doesn't update so it assumes the worst. I'd always though it was simply a timing issue of recalling out of an area before #property could update or some such, but it could easily be the movement aspect . Hmmmm... going to have to play with it now.
Thx guys.. lol I'm sure I can come up with many more "How to's" that turn into 2 page answers heh.
-
It's pretty simple to write scripts to test this, run this and you'll never come back with a response because #property will update correctly, along the lines of the way you're doing plants. That's doing event property on 2 items as fast as it can possibly go with no error on my machine.
set #lpc 9999
finditem #charid G
event property #findid
if #charname notin #property
event sysmessage #property , Hello
event property #backpackid
if backpack notin #property
event sysmessage #property , Booya
Now run this code below, and run around luna and watch the text fly. As you're running, you wont get updates to #property and it will visually show you. It's pretty simple to test. The second you start moving with right click, you get no updates to most properties until you stop. It just makes sense that its a lag reducing measure if you think about it as if you were a network programmer trying to solve client lag issues running through lots of items that are trying to update a lot of info on a small pipe. The second you start moving off screen the info stops updating. I'm sure if you increase/decrease your update range you'll notice a difference in when you start/stop updating info too.
finditem IS G
event property #findid
if #property = $ || #property = n/a || #property =
event sysmessage #property , NoName