Work in progress

[X-Drop]

Merry Christmas!


Aggro Check 0.5 (BETA)
Released 12/26/2005

---

[EDIT 02/17/06]
Aggro Check 1.0 thread

---

The script is an Aggro Checker. Very clean looking display shows what your character's current level will aggro in any given area. Will be able to automatically display current area when Tiny Terror releases the next version of Lunar. For now, you have to manually select the area.

---

List of Regions completed,

• Ronfaure
  
• Zulkheim
  
• Norvallen
  
• Derfland
  
• Kolshushu
  
• Qufim
  
• Fauregandi
  

---

All these areas were compiled by hand. And yes.... it was incredibly boring.

Currently, I am learning PHP and MYSQL to compile all the data for me. Looking foward to having this script done when Tiny Terror releases the Lunar update.

[me3you2]

You might want to look at this post from the windower forum.
ffxi.archbell.com/forums/viewtopic.php?p=8181&highlight=#8181
Might make getting info about the mobs a little easier.

[Onitaru]

personaly I'd like to see aoa area of aggresion.

[X-Drop]

personaly I'd like to see aoa area of aggresion.

I have a pretty good idea of how to create a script like that. A text based script would be easy but to do a graphic based script with onscreen cones and circles of aggro, I would need a PixelCheck() command to display the AoA graphics for each mob. Another problem would be collecting game data from all mobs in your field of vision without TAB'ing through all the mobs constantly. But, lets just see what new commands we get to play with when Tiny Terror release the next version of Lunar.

[TinyTerror]

Holy shit, this blows my mind. Tell me what you need to make this better and I will make it happen.

[X-Drop]

Just promise me that after the holidays, you will try and add a FFXI.player_GetArea() command. The script allows the user to select any area once it's up and running, but it definetely needs to display the right area when its loaded via an in game macro.

[TinyTerror]

It's already in the code, and will be in the next release.

[X-Drop]

Me3you2,

You might want to look at this post from the windower forum.
ffxi.archbell.com/forums/viewtopic.php?p=8181&highlight=#8181
Might make getting info about the mobs a little easier.

Thanks man. I finally got it all to work.... and it's a really nice setup. But even better was discovering the PHP language. I had no idea before.

I was up all night reading through the tutorials on PHP so I could understand its syntax better. I can now look at the .php files and kinda get an idea of what's going on in there. But what I need is better info than those simple tutorials are offering. I just haven't found any really good docs for PHP that show me what I'm looking for. But I'm downloading some stuff off Bit Torrent, so I should have more books than I know to do with soon.

I already figured out that I can't use the Alla database for Aggro Check. They generalize the monster's level as the range found thoughout Vana'diel rather than the level range found in each area. I don't think I can use Mystery Tour either, because I can't even view their source info for the web pages. However I found Somepage.com to be just right!

Ultimately I believe I can use PHP to parser Somepage.com's monster database and have that info stored in my local database. Then I can just cut/copy/paste that info into my Lunar script. Still though, I need to do alot more reading before I can pull that off. For now I'll just have to manage with compiling the monster data myself....

[TinyTerror]

Yeah, PHP or Perl are good for parsing stuff. Perl especially. I dont know too much perl, but my room mate swears by it. He has a perl script that scrapes a bunch of anime torrent sites, cleans up the output, filters out garbage anime from a list, grabs a description from animeinfo, and puts it all in an easy to read list. I imagine you could do much the same thing with somepage's mob database. Also, do you know SQL?

[X-Drop]

Yeah I know SQL just about as well as I know PHP....lol. I just downloaded a ton of e-books though. I'll be reading up on PHP and SQL throughout the holiday season.

Perl however, I haven't the slightess clue about. I figure you must have a really good graspe of Perl, huh? I read a thread where you hinted at creating a Perl scripting plugin for Windower. I don't know about that Perl, but man, your decision to go with Lua was a great choice. I would have eventually learned how to use a Perl scritping language, but I practically walked in and just started writing when I found Lunar.

Great job man! I just still can't understand why we don't have more activity on these forums!?! Look at all the current threads over at Archbell with ppl fooling around with those restricted macros, attempting to make loops and such. All that can be done with ease here with Lunar, plus you can add graphics to your heart's content.

[TinyTerror]

Heh, I like the activity levels the way they are. I tried to keep a low profile with Lunar on the windower forums because I feel that it isnt quite ready for mass use yet. Anyone who has used it knows it still crashes and has some other problems.

I actually don't know any perl. I also don't know much Lua believe it or not. I've spent all of my time messing with Lua's back end code, and almost none actually writing scripts. In fact, I wouldn't be suprised in the slightest if you could out code me in Lua.

[nebula]

Tiny, you know what would be really cool? if you added support for like sqlite or something, i think i've seen libs and source for extending lua for it *shrug* jes a thought

ohoh and for regex >.>; string.find is rather limited

[TinyTerror]

Yeah, I know there are libs for it. In its current state, the lua code that I use would be really easy to patch or add on to. The problem is that Lunar's strength is also it's weakness. I intentionally left most of Lunar's power intact. It can read and write to any file on your hard drive among other things. The one thing I took out was the ability of the user to load binary libraries. I did this with the intention of making it impossible for lunar to talk to the internet in any way. Adding a database client of any kind that can talk to a remote DB adds some of that functionality back. How easy would it be for someone to make a really popular script for a few months, and then silently slip in some code that harvests personal info and sends it to an offsite DB? I need to find a way to make Lunar safe for people who won't or don't know how to check scripts they download for foul play. Until then, while it would be really cool to add SQL, or networking stuff in, I have serious reservations about doing so.

Ninja edit: If anyone would like patches or addons to be made for the underlying Lua code in Lunar, let me know. There are a lot of cool patches out there.

[nebula]

sqlite is a local db only >.>

About SQLite: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.

www.sqlite.org/
www.nessie.de/mroth/lua-sqlite3/

and and rexlib, i'm a perl kiddy, too >.>

lrexlib.luaforge.net/

if you still wanna shy away from sql, how about xml support? it would prolly be over the head of most people, but it would be rather useful as a means to store information

www.keplerproject.org/luaexpat/index.html

as far as patches go, the continue one is cool >.> where would one look for patches? there a repository somewhere other than that wiki?

and tell me if you jes don't want to add more module support >.> and i'll stop pestering, heh, but especially for stuff like x-drop's aggro checker, a sql db that he could distribute with the script would make things alot more efficient and allow him to add more info and do more with it

[X-Drop]

Ooooh, more brain food..... thx Nebula.


I really like what I was seeing in those links. Here are a couple snippets that stood out for me,

• Internal or temporary databases
  
  For programs that have a lot of data that must be sifted and sorted in diverse ways, it is often easier and quicker to load the data into an in-memory SQLite database and use queries with joins and ORDER BY clauses to extract the data in the form and order needed rather than to try to code the same operations manually. Using an SQL database internally in this way also gives the program greater flexibility since new columns and indices can be added without having to recode every query.
  
  
• Serverless
  
  Most SQL database engines are implemented as a separate server process. Programs that want to access the database communicate with the server using some kind of interprocess communcation (typically TCP/IP) to send requests to the server and to receive back results. SQLite does not work this way. With SQLite, the process that wants to access the database reads and writes directly from the database files on disk. There is no intermediary server process.
  
  
• Single Database File
  
  An SQLite database is a single ordinary disk file that can be located anywhere in the directory hierarchy. If SQLite can read the disk file then it can read anything in the database. If the disk file and its directory are writable, then SQLite can change anything in the database.