Discovery POI's

[John Adams]

I've been thinking about this for some time, on and off. How will be best handle those areas players run into and gain XP (or whatever) for discovering the area. We've talked before about this being scripted with LUA, but unless there is some compelling reason do to so, could we not just make it a function of the server?
I was thinking of 2 tables, minimum. 1 would be the table of locations themselves, their names, locations, message to send to client, and reward - maybe other info if needed. The second would be character_locations, which would track which location the player has already visited. An alternative to this would be to stack location IDs into a blob field in the character_detail record; either way is good for me.
I started thinking about this again, oddly, when I was muddling over how to handle the "fog of war" on our in-game maps... which blew my mind, and I had to start thinking of something else before I died.
Nothing I am looking to have working immediately, just random thoughts I must log before I forget, again.
http://eq2.allakhazam.com/wiki/Category ... overy_POIs
This looks like a short list of the POI's. I'm sure there's a better source out there (eq2maps?) but I haven't looked for it yet.

[nyquist]

Hmm, for POI's I think that sounds good. Sadly, I don't think there would be any way around a not-so-nice location check to see if you are actually at a POI (i.e. iterating through each POI every so often to see if you are there)...what data type would be best for the MySQL table holding all the POI's that a character has visited?
MySQL doesn't have any array support does it? (unless you count strings, since they are character arrays...)
Also, the Fog of War might be a big 2D array of bools saying if you have or haven't seen that chunk of the map before (this is probably the case, because upon logging in after running a path through a previously undiscovered area, the discovered path seems to be very blocky, if my memory serves me right)
Edit: Also, I think that we should do as you said and check out the EQ2Maps' POI's. I think that would be accurate enough for our needs so long as we make sure we can differentiate between random NPC/Quest locations and actual POIs. Considering their naming/coloring scheme, this would hopefully be quick and accurate.

[LethalEncounter]

I've been thinking about this for some time, on and off. How will be best handle those areas players run into and gain XP (or whatever) for discovering the area. We've talked before about this being scripted with LUA, but unless there is some compelling reason do to so, could we not just make it a function of the server?
I was thinking of 2 tables, minimum. 1 would be the table of locations themselves, their names, locations, message to send to client, and reward - maybe other info if needed. The second would be character_locations, which would track which location the player has already visited. An alternative to this would be to stack location IDs into a blob field in the character_detail record; either way is good for me.
I started thinking about this again, oddly, when I was muddling over how to handle the "fog of war" on our in-game maps... which blew my mind, and I had to start thinking of something else before I died.
Nothing I am looking to have working immediately, just random thoughts I must log before I forget, again.
http://eq2.allakhazam.com/wiki/Category ... overy_POIs
This looks like a short list of the POI's. I'm sure there's a better source out there (eq2maps?) but I haven't looked for it yet.

I don't see a problem with that as long as the first table has a field that optionally allows someone the ability to specify a LUA script that is called when the POI is first visited. It would be optional, but I could see a use for this if you want to have an event play out instead of the standard exp/message. That was why I was going to strictly use LUA, but your way seems easier to use.

[John Adams]

Good call, LE. I started thinking about how many LUA scripts we'd need to write to maintain all those locations, and started to panic. While there's still some data entry, doing it in a table will make maintenance or modification much simpler.
As to nyquists comment; that's a good point. But the server is likely to be under a load of one kind or another when players are moving about. When a zone loads, it's "Discovery" points will be loaded too (speculating) and if the players current coords/grid matches, then bing! Discovery. But only if you do not already have that discovery in your records.
There's lots of data I/O and server loops going on, and we're only just beginning to add stuff like this. I trust LE knows how to manage these, so I am not too worried.

[John Adams]

what data type would be best for the MySQL table holding all the POI's that a character has visited?
MySQL doesn't have any array support does it? (unless you count strings, since they are character arrays...)

Oh, regarding this... "blob" data is probably best, though I guess plain "text" would be ok, too. Seeing how other emulators do it, you could build an array inside one of these fields like this:
12|133|139|155|200|etc...
Where each element is the ID of the POI you have visited. Clunky, but it works. Either that, or we have the character_locations [intersection] table which has them laid out in record form:
char_id, POI
1, 12
1, 133
1, 139
1, 155
1, 200
1, etc
Either would work, and I am not sure one or the other is less efficient, honestly.

[LethalEncounter]

Good call, LE. I started thinking about how many LUA scripts we'd need to write to maintain all those locations, and started to panic.

I was originally going to add them to the Zone LUA scripts whenever I got around to creating this script type. This would mean that only 1 script per zone would be needed. This script file would also allow you to customize a particular zone more so than putting certain parameters into a table. For instance, say you want to do a certain event at midnight (gametime) every day for certain zones. If you tried to implement this using events inside of a table it would get very complex and still not be as configurable as a LUA script.

[John Adams]

I don't know, man. Perhaps it is my lack of knowledge in your area of expertise, but I feel we're off-loading so much stuff into text files... having a list of locations in LUA, presuming they are loaded at zone startup, is no different than loading the data from the DB, is it? Or is it about server utilization, that it's faster to read/setup zones via script than to pull from a DB and iterate through it all?
Sorry I don't know more about that aspect. There are some things in the current LUA system that I feel could be in the DB, too... but I didn't want to have you kicking my ass for not mentioning it sooner

[LethalEncounter]

The LUA implementation is pretty quick as it is not reading the files every time it needs to use it. Once the file is loaded it is stored in memory until it is used so that we aren't wasting a lot of time reading files. Once the POIs are read in they will also be stored in memory, so the performance aspect of reading it from a DB or a file isn't really important. I was going to add LUA commands to add a POI, but we can do it via the DB. It doesn't matter to me.

[John Adams]

Just so you understand my hesitation on doing so much in LUA (and this is one man's opinion), editing a database entry is much easier than editing a script from a remote editors point of view - say a web editor for remote admins and such. Obviously it's probably not that big of an issue for a local admin to open a text file vs open a DB table. The second problem I have is finding the data. Burying things in thousands of scripts is harder to find what you're looking for than inserting rows into a searchable table.
But like you, I will take it either way, and whatever makes the most sense, and most importantly is the easiest on our solo developer. I don't have to like it, I just have to make it work. And I'm good with that.

[Image]

Maybe just add a command that tries to add a POI to the database? If it already exists it just ignores?
I am kind of split on this, it would be nice to have POI's through quests because I could eventually setup quest scripts that only certain people get POI's for...

[nyquist]

The more I think about it, the more I want to lean toward LUA scripts for POIs. Because POIs are important for quest updates, NPC action/triggers in general, and discoveries, and it would be quite convenient to be able to do all of that from LUA to begin with.

[John Adams]

Good call, LE. I started thinking about how many LUA scripts we'd need to write to maintain all those locations, and started to panic.

I was originally going to add them to the Zone LUA scripts whenever I got around to creating this script type. This would mean that only 1 script per zone would be needed. This script file would also allow you to customize a particular zone more so than putting certain parameters into a table. For instance, say you want to do a certain event at midnight (gametime) every day for certain zones. If you tried to implement this using events inside of a table it would get very complex and still not be as configurable as a LUA script.

/nudge

Now that Scatman has implemented "zone scripts", I would like to revitalize this discussion so we know which direction to go. I will work with whatever implementation Lethal decides is best for the World code to process; be that LUA script entries for POI's, or a few extra DB tables to ID and track POI's.

Talking with Scatman, we are both kinda leaning towards going SQL with these entries, rather than LUA. BUT that's just opinion and not a demand. For us, it's just easier to manage the data in a table, vs trying to find specific entries listed sequentially in a text file. We're not opposed to LUA, because it does work fine. The bottom line is server performance and ease of implementation where it makes sense. So either/or is fine with us.



Open for discussion

LUA Implementation: We'll need the coordinate and radius of the location, along with a location ID to "record" the discovery in a character table (character_poi, character_locations, character_discoveries, whatever works best). Simply, a PK, char_id, location_id.


SQL Implementation: We'll store the locations in a `zone_poi` table (or `zone_locations`), and that table will have a field for PK, location ID, x, y, z, radius, discovery_xp, text, and anything else that we discover we need.

Note: The only difference here is where the location data is stored and retrieved.


Either Implementation: This data is only loaded when the Zone is active, all locations are loaded at zone start-up and monitored on a cycle (al la SetPlayerProximityFunction). When a player breeches the location boundaries, World needs to check if the player has already "discovered" this location and if so, only flash the location name on the screen. Otherwise, flash the name, any special text, and ding + xp to the `character_poi` record.


Storing Character Discoveries: There are literally thousands of POI's to discover throughout EQ2 - and custom servers could have many more. We have a couple of options, with the only critical consideration how it impacts server performance. We can create a "character_locations" table to store the data with references to a location_id and char_id, and the table could grow to thousands of rows (just like spells, items, skillbars, etc - so it's nothing we are not familiar with). Another concept I have seen in other Emu's is a blob "array" as I mentioned above; entries in a single blob text field with a delimiter - like 1|13|156|199... etc. World would read this value and explode the data into an array and sift through it as needed.

I do not think World will suffer in surfing the array, but I am concerned about loading it from the DB - in either concept - everytime a player zones. This I will need LE's expertise on. Consider someday possible zone populations in the 100's, server with 1,000 players, and all that loading of data.


Those are just some cursory thoughts. Please, let's discuss (again) and finalize this design.