Keeping track of persistent data...

[KilroyIsDead]

Feel free to move this if I posted in the wrong forum...

Now I recall the day when there was that goofy *variablename and that went to the registry I believe, which I hate that.  Philosophically, stay out of my registry.  Practically it's no fun to try and extract data from when using external apps.

So then folks started writing to files and who does love the DOS flash and the sweet speed of that process.  I didn't like this either.

I then recall someone starting to exec stuff like exe or vbs files, but then you had to either code the receiver app to accept a bajillion commands or you had to concatenate the send then unbundle the concatenation at the receiver.

I always hated most of those, because it was not easy to keep track of changes and the like.

I'm a Application Architect and Database Programmer.  So I like stuff stored in relational databases.  What I did was leverage the send HTTPPost and a localhost website that interacts with a database.  I like this because I can quickly create data repositories and I have front-ends to look at the database and change settings or analyze data, etc.

As an example.  I am mostly stealing CyperPopes radar and Papua Rune Wall Mining.  No code is reused but I did use their code as my study guide.  My mining routine will find all the rune books in your pack with a keyword in them.  It will then start the day by mining all the spots in those books.  Similar to Papua.  I mine all spots the first time around.  I modified it to pick one tile in each resource grid within my reach.  Once I hit ore i log the x,y,z,tile,facet as a mineable location.  So on future visits we only mine the mineable spots.  I log all ore that is extracted (by color) as well as granite and gems.  After the first loop of the day (visiting each book and rune within) it sends me all the ores that were found and then I tell it which spots to mine that day.  I have only run this two days so far, but imagine I could analyze the data to possible determine if there is a pattern to how they spawn the ore.  But how I use the data is not the topic.

Btw, this works really well for storing different settings for different characters.

Since I like this method of persistent data and assume not everyone is sitting at home with a SQL server and IIS or the ability to code IIS.  How do I really post useful scripts? 

And besides it being less portable, what other gotcha do you think I'm in for?

[Masscre]

Dont have an answer for ya but wow that is a kewl idea for a script and alot of thought put into that. If the data could be say collected for like 5 days 24 hours a day and then maybe presented in column format that would be like a great study tool for miners and people wanting to write mining scripts.  I am curious what kind of data you would get back from the ore mined for a few 24 hour periods straight.

[Endless Night]

COuld always send it to local host.. and write an app to recieve and store to a database.  Then could be used by anyone.

[12TimesOver]

I'm with you on the relational db saves (I also work on app architecture, always nice to hear someone else refer to it as such), I hate adding data to the registry with absolutely no ability to clean it up after and I really haven't taken the time to get my arms wrapped around the file-system routines yet. It seems like we've yucked the DB idea up around here a few times, TM may have even mentioned some goodies in future releases of SUO. I like the way you're handling it, what DB platform are you using in the background, MySQL? To your point though, this isn't a method that is easily distributable as it requires a pretty high technical capacity and there are SO many variables that could impact functionality and performance that it would be next to impossible to develop a workable support model. Obviously not for the faint of heart!

As for the script, that's very similar to how the XIIxOveR Miner For Dummies works, the only difference is that I hadn't figured out the logic to only pick a single resource tile from each reachable square so, instead, it scans a grid around the toon and determines the bad verse the good tiles so that next time around it only hits one good tile in each reachable square. Different means to the same end I suppose however the ineffinciency is that each subsequent trip it continues to scan all the tiles and match them against either a *goodtile and *badtile variable thus there is upwards of 10-20 seconds +/- that are wasted at each location. Definitely something I'll be looking to fine tune as I become a better scripter. I did start playing around with the world coordinates divisible by 8, yada yada, but it's the creation of the algorithm that escapes my ability still! I'll get there eventually

How do you differ between a first round "setup" run and standard runs thereafter, just a setup flag of some type I'm assuming where #TRUE until all runebooks have been scanned then it breaks out of setup mode or something along those lines?

XII

[KilroyIsDead]

COuld always send it to local host.. and write an app to recieve and store to a database.  Then could be used by anyone.

I agree, I send mine to localhost the the webpage there puts the data in and even better pulls the data out.  But I feel that the casual script user won't have that where withall.

I was thinking about put the receiver page on my public website then others could post there as well but the internet would likely slow things down.  For a resource gatherer that might not be as critical as say in PvP waiting for the response before doing your next move/spell/etc.

The upside of that scenario is that multiple people writing data gathers data faster.

I will say this in the localhost scenario and can read-write blazingly.  I does out perform the dos write.

I like the send HTTPPost because I just return the EUO comands back and they get executed

send HTTPPost 127.0.0.1 /YaddaYadda/RetrieveLocationInfo.aspx?RuneBook= , %CurrentMiningBook , &Rune= , %CurrentRune

This returns a set of commands...
set !RuneBeenVisited #True
set !RuneBeenVisitedToday #False

set !DigPoints 2

set !DigPointX1 439
set !DigPointY1 1178
set !DigPointZ1 200
set !DigPointT1 UFGHTYA

set !DigPointX2 447
set !DigPointY2 1179
set !DigPointZ2 201
set !DigPointT2 MHJTYS

set !BestOre %ore_verite

I now know how many places and where to dig and what to possibly expect

But even cooler

I could return something like this

  ;TYUPOI = Larry's Pet ObjectID
  gosub GoResPetAtHouse TYUPOI


Because Larry was doing something else and his died, so larry logged that message; he knew to recall home with his bonded pet and wait for a sactify gump

I'd now go to an inn log out and get my tamer. Then go to the house and res Larry's Pet, hell I may even heal the pet. Log the tamer out log the miner back in and go back to the current runebook, currentrune

I think the possibilities are endless

For now it's just cool, but i think it has possibilities

12times posted while I was writing

How do you differ between a first round "setup" run and standard runs thereafter, just a setup flag of some type I'm assuming where #TRUE until all runebooks have been scanned then it breaks out of setup mode or something along those lines?

When I land at a mine spot I call research mine while is listed above
When it returns
set !RuneBeenVisitedToday #True
I set %FirstRoundComplete

Then in the SelectNextLocation routine I switch from do sequential runebook mining to doing cool stuff
Maybe I need Copper today so I can say go get me a list of copper locations and spin through those
Again the database piece helps here, because if I get an order for say verite in two hours I can inject code into the SelectNextLocation to get a verite list.  and I can do this remotely by logging into my website that can affect the database.

[12TimesOver]

Maybe I need Copper today so I can say go get me a list of copper locations and spin through those
Again the database piece helps here, because if I get an order for say verite in two hours I can inject code into the SelectNextLocation to get a verite list.  and I can do this remotely by logging into my website that can affect the database.

Now THAT is "bitchin" 

You know, the concept of this "client server" model of EUO programming just blew my mind! Probably just stating the obvious but imagine interactions between scripts run by potentially many people from many devices in many locations. You've probably already considered this but think about the abilities brought to groups of players scripting interactively with content stored in a centralized environment accessible via the puplic network.

Now THAT is also "bitchin"

XII

[delta313]

It might not be useful to a single miner, but a what about a miner guild ?

if the setup is not too hard, one member could host the SQL repository and receive data from other guild members on the same shard through HTTP requests.

Once there would be sufficient data (mining locations, mining tiles, ore types, last visit time, it could then be used by all members to optimize their mining and avoid the spots that does not provide the type of ore they want or that have been mined recently by other members.  Every guild members would need the same set of runes for that to work.....just a thought

[Endless Night]

I did start playing around with the world coordinates divisible by 8, yada yada, but it's the creation of the algorithm that escapes my ability still! I'll get there eventually
XII

This is how my miner works.  It doesnt store known good spots instead each place it visits it calculates spots (from my initial testing today it seems to work as fast as stored spot data). It also works on multi-books.

[12TimesOver]

It might not be useful to a single miner, but a what about a miner guild ?

if the setup is not too hard, one member could host the SQL repository and receive data from other guild members on the same shard through HTTP requests.

Once there would be sufficient data (mining locations, mining tiles, ore types, last visit time, it could then be used by all members to optimize their mining and avoid the spots that does not provide the type of ore they want or that have been mined recently by other members.  Every guild members would need the same set of runes for that to work.....just a thought

I'm not even thinking about mining (although that could be cool too) but rather other interactive functions supporting multiple users. For example, with a traditional Bot application there is a need for the "bot" script to receive commands usually in the form of either party messages or simply local persistent variables available only to multi UO sessions on the same machine, stuff like that. Instead, picture a Bot that is able to actively monitor the status of party members and throw heals, res's, etc while fighting without any calls by the players in party chat, etc. Or maybe something that would assist group play in Doom. Not only would monitoring of veriable value in a centralized repository for multiple people be more efficient, I would think it would be much faster than constant journal scans. Furthermore, the system could react even before you notice you need a heal or a cure, etc. Set it and forget it!

How about an interactive, realtime guild armor tracker and sorting system? Perhaps a shared IDOC coordinate repository for IDOC teams operating across multiple shards. The list goes on.

X

[Cerveza]

If you can get a group of people all running the same script, you could share the data from each char and the BOT could react according to set parameters. But... that data would have to be almost live, and sent to a central collection point (online) so the BOT could constantly read it and react to it.

Seems like that might take a little time, and be a little laggy.

I'm poisoned, My script has to send data to a website to show me poisoned, the bot has to read from the website that I'm poisoned and react.

Now it'd be cool as hell to have this, but not sure it would be practical in game. Just watching over the website would be cool, you could see the status of everyone running the script LOL.

[12TimesOver]

Definitely true. Cool in concept but perhaps Bot applicaion not the best!! Still see a number of other potentials though.

X

[KilroyIsDead]

To answer an earlier question I'm running SQL 2008

but most development I do now-a-days I keep a working copy of MySQL in the background, because my public website only has a MySQL back-end so I might be able to expose some very cursory calls and maybe enroll some of you for testing.

To Cerveza.

Yeah, I don't see the "message" as viable real-time stuff.  but who knows.  I think the UO data travels over an inernet connect (note tongue in cheek).

To res a dead pet is a background "get to it when I get to it" situation

But I absolutely see this scenario, as fun

3 stealth archers "linked" in and once player 1 does eval int (sets a last target) that goes up to the server and teh other two read it and automatically shoot the same last target.  It's just a matter of efficient database interactions and inernet through put.


Post Merge: April 28, 2009, 11:02:15 AMI guess you could just as easily send it in guild chat and then the other two read guild chat and react to that

[Cerveza]

Party Botting is very easily accomplished, and real time. That's a whole different scenario then I read above.

Group target has always been a project I wanted to play with... not that hard to do really.

Just scan journal for a party (guild?) message that starts with "TARGET" or "PASSWORD". Have the ID of the target in the statement and just use it to shoot.

[KilroyIsDead]

To the real-time of the game stuff

Since the guild/party chat went up to the OSI server and back.
I wouldn't mind testing the speed of sending the same data up and back via this new process
Part of me says that you'd work in parallel so that's an advantage
Part of me says waiting for a web request could easily take longer than a more raw packet message could be a disadvantage.

I can say that I am getting nothig work worthy done today, but I do like this discussion.

[Khameleon]

12xO seem to read your posts.... or anyone else's that appear on the same screen as your avatar.