Triplex

I tried to reimplement code that loads : guild_eventlog and guild_bank_eventlog tables. I renamed few variables, therefore patch is big. Patch is a bit tested. Unexpected behavior wasn't found. Patch adds new config options Guild.EventLogRecordsCount and Guild.BankEventLogRecordsCount. [url]http://paste2.org/p/387609[/url] Real change of this patch isn't big, just i changed the way how events are stored. Pls if you have time, test it. SQL scripts needed to run patch: -- THIS SCRIPT DELETES table `guild_eventlog` - MAKE BACKUP, if you need it. DROP TABLE IF EXISTS `guild_eventlog`; CREATE TABLE `guild_eventlog` ( `guildid` int(11) NOT NULL COMMENT 'Guild Identificator', `LogGuid` int(11) NOT NULL COMMENT 'Log record identificator - auxiliary column', `EventType` tinyint(1) NOT NULL COMMENT 'Event type', `PlayerGuid1` int(11) NOT NULL COMMENT 'Player 1', `PlayerGuid2` int(11) NOT NULL COMMENT 'Player 2', `NewRank` tinyint(2) NOT NULL COMMENT 'New rank(in case promotion/demotion)', `TimeStamp` bigint(20) NOT NULL COMMENT 'Event UNIX time', PRIMARY KEY (`guildid`, `LogGuid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT 'Guild Eventlog'; -- The reason i decided for such dramatic change is that old guild_eventlog table hadn't Primary key and -- used LogGuids from 0 to infinity -- New system uses LogGuids from 0 to number defined in config. -- THIS SCRIPT DELETES table `guild_bank_eventlog` - MAKE BACKUP, if you need it. DROP TABLE IF EXISTS `guild_bank_eventlog`; CREATE TABLE `guild_bank_eventlog` ( `guildid` int(11) unsigned NOT NULL default '0' COMMENT 'Guild Identificator', `LogGuid` int(11) unsigned NOT NULL default '0' COMMENT 'Log record identificator - auxiliary column', `TabId` tinyint(3) unsigned NOT NULL default '0' COMMENT 'Guild bank TabId', `EventType` tinyint(3) unsigned NOT NULL default '0' COMMENT 'Event type', `PlayerGuid` int(11) unsigned NOT NULL default '0', `ItemOrMoney` int(11) unsigned NOT NULL default '0', `ItemStackCount` tinyint(3) unsigned NOT NULL default '0', `DestTabId` tinyint(1) unsigned NOT NULL default '0' COMMENT 'Destination Tab Id', `TimeStamp` bigint(20) unsigned NOT NULL default '0' COMMENT 'Event UNIX time', PRIMARY KEY (`guildid`,`LogGuid`,`TabId`), KEY `guildid_key` (`guildid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- The reason i decided for such dramatic change is that old guild_bank_eventlog table used `TabId` = 0 for Money events and -- used `LogGuid` from 0 to infinity -- New system uses `LogGuid` from 0 to number defined in config.

any good news about this patch? Another point of view: It is also possible, that we have to store all guild events and only smaller part of those are sent to client. Maybe there should be another table that should store old (and not used by mangos) events... where we would move oldest guild events. Or another solution would be, that we will just add new events and when mangos is starting up, we would delete oldest and not used events. I mean something like: SELECT * FROM guild_event_log WHERE guild_id = xx ORDER BY log_id LIMIT 100; then we process the result in mangos and we will find log_id of the oldest record. Then we know minimal_used_log_id: DELETE FROM guild_event_log WHERE guild_id = xx AND log_id < minimal_used_log_id; So the log_id will grow to infinity... but we will have fast and simple code that handles them.

ok, i understand what you mean. Then core would have to handle this special situation differently ... if record has LogGuid = 0 and it has timestamp same as other records, then the first record should be the record where the sequence of LogGuids is broken like (0, 1, ...i-1, i, !! k, k+1 ...) - sequence of LogGuids with same TimeStamp value ... - k in example. If all logguids would have same timestamp, then there is no way to find out which one is first and it doesn't matter then.... I think we can assume that there won't be more than 10 guild events with same timestamp

hi, next sequence number isn;t needed, cause we can use 2 columns in the order part of select query. I mean : SELECT * FROM guild_eventlog WHERE guildid = xx ORDER BY TimeStamp, LogGuid DESC (or ascending order - i'm not sure which one would be necessary..) So the same timestamp value would not be problem, if some events happens in the same second, then we assign to that events various LogGuids.. I'm not sure if Ascending or Descending order would be better, because i didn't looked to the code... I'm just suggesting the solution. I hope everything is clear for you.

hi, i would have another solution for this problem. When loading mangos ... select all guild events (for 1 guild) from table ordered by TimeStamp column ASC. Then the first returned line will be for latest event. Now count first 100 (or how many we need) if there are 100+ records set oldest_logguid variable to logGuid - 1 of the first record(latest) (if it is 0 then set it to 100) , then delete all other logguids - 101, 102 ... If there arent enough logguids we need to start from 100 (that would be used for the first (oldest) log id record and then decrease it until 0 ... Then when we will have new guild event we just do REPLACE INTO guild_event_log (xxx) VALUES (guildid, oldest_logguid, ...) (or DELETE xxx then INSERT xxx) so the oldest event will be replaced and now we need to decrease oldest_logguid by 1 and if it is already 0 then we need to set it to 100 ... I hope my thoughts are clear for you. There is one disadvantage of this point of view, that it is not user friendly solution ... because logguid doesn't mean the place in sequence of guild_events but it is only used to keep the order. For this solution there would be useful clustered index for timestamp column - or make that column ordered and index for guild_id. We suppose that log_guid column is ordered same as timestamp column. And same thing for bank log....

Apply Aura: Force Reaction (1059) should be handled in gameobject code (check gameobject's faction relation to faction 1059). I don't have time now to test it, but i think it is not working.

no it hasn't. There are zone_only messages.

commited [7589]. Thx.

hopefully fixed in [4546]. with realmid column.

commited in [7544]. Thx. I removed realmid column, because you cannot use one character database for multiple realms.

yes, invisibility will drop flag

i don;t know if it is a good idea to backport this patch, because it works with currect dbc files. I'm not sure if those data hasn't been updated recently...

rewritten and commited in [7523]. Thx to all who helped.

no immune players can capture base in EoS by being near the tower place...

commited in [7437]. Thx

commited in [7416]. Thx

commited in [7402] thx ;-)

nice discovery , but i think it would be better to have that function somewhere in battleground system ( i mean i want it to move from player class to some battleground related class) I will check it tomorrow.

second patch commited in [6085]. Thx

commited in [5990] with some changes, pls don't post useless post like "bump", it only increases your warn level....

i agree with mirek and ambal (i thought ambal is already in team). the other one's I don't know