Triplex
-
Posts
46 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by Triplex
-
-
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
[patch][8402] Speeding up guild event loading
in ... acceptedOld
Posted
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.
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: