Sharing finditem data with other accounts

[Gemviper]

Let's say I'm running a script that performs several FINDITEM requests and ignores many items that don't meet the criteria I set, and let's say that I have more than one account running the same script at the same time, is there a way for them to share information?

example: character 1 finds something and performs an ignoreitem on it, is there a way for character 2 to share that ignore and not waste time on it? I noticed that both accounts tried to interact with the same item at the same time and it crashed one of the clients, not good.

[12TimesOver]

Have you considered just using *persistent variables to store the data so that they are available to all running scripts?

[Endless Night]

as 12x said persistent vars are probably the way to go. 

[TrailMyx]

If you can run multiple scripts in a single EUO instance, then you can easily use global namespaces. 

[Gemviper]

Thanks, I'd never heard of globals until now 

re:ignoreitem
- performance considerations? If 2 scripts share and update the same ignore list at the same time should I expect some extra latency from the code? Anything noticeable requiring some extra wait time for example?

- is there any other consideration needed within the code to use globals on an ignore list? ie: will it affect any other functions of that script?

Just wondering what surprises lay in store for me while work on a global ignoreitem list. Thanks again.

[12TimesOver]

Thanks, I'd never heard of globals until now 

re:ignoreitem
- performance considerations? If 2 scripts share and update the same ignore list at the same time should I expect some extra latency from the code? Anything noticeable requiring some extra wait time for example?

- is there any other consideration needed within the code to use globals on an ignore list? ie: will it affect any other functions of that script?

Just wondering what surprises lay in store for me while work on a global ignoreitem list. Thanks again.

Not Global, Persistent. TM's point is if you're doing everything from one script you can use Global however if you want to share values between two scripts you need to use Persistent. Just keep in mind that excessive use of Persistent vars will fill up your registry.

X

[Gemviper]

Same script, doing the same thing, being run by multiple characters. Right now each flows through the script independently, each creating their own ignore lists, but some of their actions are redundant since the other character has already done it.

example: idoc, 2 characters looting, no need for both to check every item. If character A finds a sword but its not legendary or special and he ignores it there's no need to character B to waste time on it. A shared ignore list would help where milliseconds count.

example two: resource collection(tree stump logs, dolphin rug SoS's etc). Finishing the job fast with two characters would be easier if the characters walked towards uncollected goods only, without checking things the other already has.

I'd have some use with my tailor/smith in sharing the work area too while making full suits (lrc, 70's etc). I have no clue how much is too much for the registry to handle. I've started my scripts slow and revised them to speed them up until I am happy and they feel solid.

[Endless Night]

Thanks, I'd never heard of globals until now  

re:ignoreitem
- performance considerations? If 2 scripts share and update the same ignore list at the same time should I expect some extra latency from the code? Anything noticeable requiring some extra wait time for example?

- is there any other consideration needed within the code to use globals on an ignore list? ie: will it affect any other functions of that script?

Just wondering what surprises lay in store for me while work on a global ignoreitem list. Thanks again.

Not Global, Persistent. TM's point is if you're doing everything from one script you can use Global however if you want to share values between two scripts you need to use Persistent. Just keep in mind that excessive use of Persistent vars will fill up your registry.

X

Ahh Globals  forgot all about those...    TM did mean globals  NOT Persistent, they are different... and he also meant you can share vars between scripts as long as  ALL SCRIPTS are running in the SAME copy/instance of EasyUO.    IE run two scripts in one easyuo .. not 2 scripts in two separate easyuo sessions.

Here is an example of using globals.

Script 1  - run this first

Code: [Select]

namespace push
namespace global test
set !test hello
namespace pop
halt
Script 2  - Run 2nd

Code: [Select]

display ok  !test  - Global Namespace not set
namespace push
namespace global test
display ok  !test  -  Global namespace SET
namespace pop
display ok  !test  - Global Namespace not set
halt
Notice when you run the 2nd script...  !test = N/A   but once you set the Global Namespace  !test now = Hello (what was set in Script 1)  and if you close the global namespace !test = N/A once again ..

[12TimesOver]

Ah, I see, it didn't click because I thought that the namespace variables weren't exactly working as they should in EUO thus for something like this I would use a persistent to track the data so it's accessible to any script. I typically use namespace variables simply to keep my subs more modular, i.e. so they don't conflict with whatever is already in the script they are getting slipped into.

Am I correct in saying that a "Global" variable is any variable used in the Global Namespace which is the default Namespace for a given script? But then if you mark these as Namespace "!" that they are available to ANY script running in the same EUOX.exe instance?

I still think it would be easier, maybe preferable, to use an persistent in this particular case but I also don't have the same amount of experience as you guys.

X

[Endless Night]

Ah, I see, it didn't click because I thought that the namespace variables weren't exactly working as they should in EUO thus for something like this I would use a persistent to track the data so it's accessible to any script.

As far as i know Namespace has been working fine ... I use it in a number of my scripts including the Buffbarscanner without issue

[12TimesOver]

Sorry, I should have elaborated - I know that Namespace works fine but I thought there were bugs in the way the Global Namespace was handled. I can't begin to tell you what got that in my head though. Maybe age.

[TrailMyx]

Honestly I have been using global namespaces for years without issue.  Also they are probably a bit faster in this instance because you aren't having to invoke file I/O or another system infrastructure to record the information.  Your point about filling the registry is also a good one to keep in mind.

The only time I'd use system variables is if I need to persist data from run session to run session (i.e. saving script state or baseline) 

An interesting throught about being able to actually compile EUO now is that we can actually entertain the idea of FINALLY allowing for thoughtful file I/O.  Imagine that being able to save/read files without having to invoke the command prompt!  Wozers!

Anyhow Gem, here's a tutorial I wrote a long time ago that addresses namespaces (local and global) and also read closely what Endless said as he's spot on.

http://www.scriptuo.com/index.php?topic=108.0

Am I correct in saying that a "Global" variable is any variable used in the Global Namespace which is the default Namespace for a given script?

I think you're thinking about local and global namespaces, 12X.  For example:

Code: [Select]

namespace push ; save present namespace location
namespace local test1
set !var1 123
set !var2 456
namespace pop ; restore to previous namespace

namespace push ; save present namespace location
namespace local test2
set !var1 TREX
set !var2 BURITTOSAUR
namespace pop ; restore to previous namespace

namespace push ; save present namespace location
namespace global test3
set !var1 FINGERS
set !var2 TOES
namespace pop ; restore to previous namespace

Now I have 2 variables in 3 different locations (local:test1, local:test2 and global:test3) and all of which have different values.  Variables in local:test1 and local:test2 are only available for the current running script.  global:test3 is available to all script tabs running under one UO instance.  If you are running more than one copy of EUO, then each program will have its own global namespace area.  So if you need to share data in that paradigm, you'll need to use system variables (*vars).

[12TimesOver]

Ok, I see my mistake.

Thanks much for the explanation!

X

[Endless Night]

Being as I forgot about globals and initially recommended persistent vars..  I may have pass my  ""Your a living breathing vortex of usefulness." hat over to TM for a SHORT spell   

[TrailMyx]

Being as I forgot about globals and initially recommended persistent vars..  I may have pass my  ""Your a living breathing vortex of usefulness." hat over to TM for a SHORT spell   

I honestly wouldn't mind using persistent variables except for the annoying issue where if you create it with EUO, there's no way to remove it even if you "clear" it.  If you look at the EasyUO section in your registry you'll be surprised how gunked up it is.

And thanks for the brief use of your Vortex moniker. 

I still think this picture really communicates how data is visible when using namespaces:

http://www.scriptuo.com/index.php?action=dlattach;topic=108.0;attach=6719