Drag/Dropper

[Kalaka]

Very simple script. Just took a look at a few things I had already helped with or had given to me, and created something new! Can use this for maybe events that drop items, IDOCs, or anything of the sort. Very fast.

It is working.. but there is one small issue, and then one question I have associated with this as well, and maybe someone can answer this. First, sometimes after dropping it in the bag a graphic of the item will remain in a random spot on the screen, mousing over this can sometimes cause crashes, minor issue so I didn't look into this much more.

Secondly, if this script is running with the particular client window being focused, it runs lightning quick.. however, if you minimize it and open a new window (firefox for example), it takes slightly longer to pick up the items.. I'm guessing this isn't an issue with this script alone though? Is there a way to get around this so it's picking it up just as fast no matter what? If the window is the focus, it's maybe .05 to pick it up, but if it's not focused, it might be .25-.5.

Thanks in advance for any responses here, and hope someone gets use out of it.

[TrailMyx]

First little thing is you can't mix event drags and exevent drops.  I added a "wait 10" between the drag/drop to help mitigate client crashes that might popup.  That just doesn't work.  Finally, with exevent drag, you need to give the stack quantity that was found by the last "finditem".

This version should always attempt one drag unless %2 = all. Try this version (untested)

Code: [Select]

start:
  gosub drag XXYYZ1 all G_2 3
goto start

sub drag
  repeat
    finditem %1 %3
    if #findkind <> -1
    {
      exevent Drag #FindID #FINDSTACK
      wait 10
      exevent dropc #BACKPACKID
      wait %4
    }
  until %2 = all && #findkind <> -1
return


[Kalaka]

I'll test that tomorrow. Maybe that will fix the small client crash issue I mentioned in the first post.. Didn't see any others besides when that would happen.

Any idea how to get it to run at the faster speed as if it was the focus window, even if it is in the background though? This would be huge if I could get that.

Edit: I forgot about the stack thing.. Not used to looting stacks of items at places.

[TrailMyx]

at some point in your scripting life, you need to take a step back from "it's gotta go fast!".   Everyone goes through it.  First is just getting it to work.  Second is getting it to work fast.  Last is getting it to work reliability.  Whenever I publish stuff, it's not gonna be very fast when dragging, but it won't crash too much.    It's been 3 years since my last client drag-related crash.  I'll take that over speed anyday.

[Scrripty]

at some point in your scripting life, you need to take a step back from "it's gotta go fast!".   Everyone goes through it.  First is just getting it to work.  Second is getting it to work fast.  Last is getting it to work reliability.  Whenever I publish stuff, it's not gonna be very fast when dragging, but it won't crash too much.    It's been 3 years since my last client drag-related crash.  I'll take that over speed anyday.

He and I differ on this.   I prefer speed AND reliability over one or the other.  It's all about compromises.  You give a bit here to get a bit there.  I have a great computer and connection, and don't write my scripts for people with slower connections.   Although I have been known to add wait variables so it's easy to change for people on slower connections.

[TrailMyx]

Actually, we don't differ at all.  I write scripts for the masses, and Twinkle McNugget writes scripts for Twinkle McNugget.   

The point is, when you publish to the masses, you must think about the lowest common denominator and make your script flexible enough to run for them.  However, if you're gonna be making a script for yourself, why not tweak it to work best for yourself?  Just keep those optimizations in mind if you do decide to release because you'll have to address stability issues in the future.

Notice that Twinkle McNugget is only at "step 2".  He'll evolve someday.... 

[Scrripty]

Actually, we don't differ at all.  I write scripts for the masses, and Twinkle McNugget writes scripts for Twinkle McNugget.   

The point is, when you publish to the masses, you must think about the lowest common denominator and make your script flexible enough to run for them.  However, if you're gonna be making a script for yourself, why not tweak it to work best for yourself?  Just keep those optimizations in mind if you do decide to release because you'll have to address stability issues in the future.

Notice that Twinkle McNugget is only at "step 2".  He'll evolve someday.... 

Or they will evolve so I don't have to.   I *did* say I put wait variables to make changing the waits easier.  Sheesh.   Writing for others is secondary to the main point of uo scripts.  My profit and ease of use. heh  One thing of note:  I've begun using a standard wait throughout my scripts, say a wait 20, and 20 would be one variable, and any waits requiring more or less time, I just do wait %standardwait + 10.  See what I mean?  So you can still just use one wait for all waits in the script, but it will work for all waits of any time amount.  This also works well for soft waits or action waits.

[Kalaka]

Interesting discussion. I understand your point TM, but in particular for this, it's important to have it fast as it can be, because there's quite the competition for IDOCs on Atlantic, which is mainly what this is for.

I'm still curious why if the window isn't the front one it doesn't run as fast? Any way around this?

[TrailMyx]

Are you running several instances of a script using multiclient?  Frankly, for fast interactions like IDOCs, I gave up on multiclienting a long time ago.  I found it was much easier to run multiple VM (virtual machine) sessions.  That minimized the crashes and also made each VM work roughtly similar to one another.  Assuming you have the processing horsepower, VMs make things MUCH easier.

@Twinkle McNugget:  I took my timing optimization to the extreme.  My drag/drop in a couple scripts actually look at the journal and sense "you must wait" statements.  When one appears, it automatically adjusts the delay by adding a little bit of delay.  After several successful drags/drops, I attempt to drop the delay to automatically optimize the delays.

[TrailMyx]

I have a WHOLE bunch of secrets in regards to IDOC looting I use in an internal version of my IDOC looter.  Knowing the dynamics of how EUO works, it's easy to throw monkey wrenches into the IDOC tools of others, including my own public looter.  

Imagine coming to an IDOC with a whole loot list and only coming away with *1* looted item.  You will if you run into my personal looter.  MUAHAHAHAAH.

[Scrripty]

@Twinkle McNugget:  I took my timing optimization to the extreme.  My drag/drop in a couple scripts actually look at the journal and sense "you must wait" statements.  When one appears, it automatically adjusts the delay by adding a little bit of delay.  After several successful drags/drops, I attempt to drop the delay to automatically optimize the delays.

I've considered this also, for say casting delays and such.  Dynamically adjusting them based on journal events and such.  I just never started, regular waits were always good enough.  And in my stuff I usually put a journal check for things like you must wait and such also.  Only for critical stuff tho.  If my scripts fail on something I just put enough checking in so they'll continue.  Critical things I wa.nt them to catch tho and do it correctly.  You shouldn't be giving away trade secrets on idocs.  I'll be writing my own to fix your issues you throw into them.

[TrailMyx]

You shouldn't be giving away trade secrets on idocs.  I'll be writing my own to fix your issues you throw into them.

I did give out one of the secrets in the Elite-version of the IDOC looter, but it's hidden in there so nobody will actually see the secret unless they've been IDOCing for years and actually compare one script in operation to another.  The rest are kept in a locked box under my pillow, right next to my .45ACP. 

[Kalaka]

Nice. VM is a great idea and I will for sure look into that.

TM: I tested your first suggested changes, and wait 10 is waaay too long for me.. 2-3 seemed to do better. Going to edit the DL attachment

[TrailMyx]

On OSI, you really need some wait.  I've found on RunUO shards, you can pretty much remove that first wait entirely.  Makes for some pretty speedy moves.  Problem then comes when you are trying to do too many things at once an you get those "you must wait" messages.  It's all about what works for your own rig and requirements.

[12TimesOver]

Moved to "Scripting Chat" as this is less of a script Submission than it is a discussion about a snippet of code, etc.

X