Implementing: Discovery/POIs

[Scatman]

It was hard for me to type so much. I think I just broke my world record for longest post.

[John Adams]

Indeed. Remember who you're talking to. If your answer is less-than 1000 chars, I will not get it. I hope you didn't hurt your "important wrist" typing all that up, Scatto!


So, do you think starting with this declaration in Player.h is right?

Code: Select all

	map<int32, vector<int32> >	player_location_ids;

[Scatman]

I'd say so!

[John Adams]

Scat, here's an idea. Instead of making one map<vector<>> of zone/locations, could I actually make a Struct{} for `character_history`, of which Discovery POIs are a 'type' of, and simply load all player history into that instead? Then, I can look for history_type = 'Discovery' (enum), and current_zone_id = zone_id stored in this struct, too... to limit the iteration?

I am designing this to store all disco locIDs in a `character_history` table, that will contain far more than just locs (last death, level ups, slayer stats, etc).

Code: Select all

CREATE TABLE `character_history` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `char_id` int(10) unsigned NOT NULL default '0',
  `zone_id` int(10) unsigned NOT NULL default '0',
  `history_type` enum('None','AA','Achievement','ALevel','Death','Discovery','Kill','TLevel') collate latin1_general_ci NOT NULL default 'None',
  `history_value` int(10) NOT NULL default '0',
  `history_date` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `FK_character_history` (`char_id`),
  KEY `FK_history_zone` (`zone_id`),
  CONSTRAINT `FK_history_zone` FOREIGN KEY (`zone_id`) REFERENCES `zones` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_character_history` FOREIGN KEY (`char_id`) REFERENCES `characters` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci

something like this. When I call LoadCharacterHistory(), I could then branch inside that function based on history_type and still load map<zone_id, vector<location_id> > as originally planned... but I thought I would run this passed you first.

[Sylva1n]

if you do this you should also add what killed the player ie: which mob , or if opening a chest ( Quebecker was killed by a teasured chest.) lol

[John Adams]

char_id = player
zone_id = where
type = death
value = spawn_id (even chests are spawns)
date = when

I think we got it covered

Or we can even have type = death_combat, death_falling, death_stupidity, etc.

[Scatman]

Yeah that'd work just fine too.

[John Adams]

Scat,

I am looking through the list of `guild_event_defaults`, and aside from some of them being guild-specific, this seems like a pretty good list of all "stats" things to track for players individually, too. I don't think I want to make a table holding these constants, but maybe code them in just like our current `statistics` definitions?

I dunno. I'm fighting with myself right now whether or not to just use the damn existing world stats to hold this "history" (referring to Player PvE counters in World.h), or make a whole new thread/tables/data... hmm. But, I like this list of potential stats for players.

[Scatman]

Yeah I think that's fine to use our current stats, same thread and all!

[xinux]

Necro'ing

John FYI you know you can go into your UI\Default\POI and open up eq2_poi.xml and get every poi location & type along with coordinates.

[John Adams]

John FYI you know you can go into your UI\Default\POI and open up eq2_poi.xml and get every poi location & type along with coordinates.

Yes.