Logger Improvements

[karaeren]

Adds ConcurrentDictionary<UInt64, bool> LoggedEntities into Encounter class

It's used to keep track of PC (players) that have been posted to the log file. On the ProcessDamageEvent function, if the source entity is a player (has a player className) and hasn't been announced yet, it will announce it as a new PC (log line=3). This is useful when the user opens the logger after they got into a zone (guardian raid etc...) and started damaging.

Example scenario: User is in guardian raid, opens up logger. The log file is like this

8|2022-05-26T14:32:41.470Z|245C5AB|21000|[바드]평타|210001|[바드][평타] 발사체 대지|243934B||17137|1|1|0|0|999982862|999999999|e49ce65f95e58f61d735b879591840ea

There is no info about 245C5AB and it's not known if it's a player or not. With the addition of this code, it'll add a log line=3 statement before this so it becomes this

3|2022-05-26T14:32:41.331Z|24248AB|245C5AB|0|Bard|1|0|0|8145ce43db22424833ed0f46c0b61289
8|2022-05-26T14:32:41.470Z|24248AB|245C5AB|21000|[바드]평타|210001|[바드][평타] 발사체 대미지|243934B||17137|1|1|0|0|999982862|999999999|e49ce65f95e58f61d735b879591840ea

Now we know that 24248AB is a Bard player.

Damage log modifiers

On damage log(8) after the modifier, it specifies known modifiers (crit, back attack and front attack). So the new structure would be:

8|[timestamp]|id|name|skillid|skillname|skilleffectid|skilleffect|targetid|targetname|damage|modifier|iscrit|isbackattack|isfrontattack|currenthp|maxhp

[karaeren]

Updated more stuff since this pr hasn't been merged in a long time @shalzuth

Phase transition

On phase transition log(2) adds phase code to explain why this log was appended. Example:

// phase transition, called because of PKTRaidResult
2|[timestamp]|0
// phase transition, called because of PKTRaidBossKillNotify
2|[timestamp]|1
// phase transition, called because of PKTTriggerBossBattleStatus
2|[timestamp]|2

HTTP Bridge

This pr also contains a lot of updates about HTTP bridge, such the removal of hard coded "LOA Details" log file, adding a message queue with try-catch, supporting the new region settings etc...

[shalzuth]

I had 2 comments - I don't think we need to have the cached entity sent to logger object. This should be handled by the GUI, no? I want to be restrictive on what items are generated into the log. This should only happen when opening the dps meter after selecting the character. And for the NPC, it will always fall into the id statement - there isn't a case where a new npc is added that already exists.

[karaeren]

I had 2 comments - I don't think we need to have the cached entity sent to logger object. This should be handled by the GUI, no? I want to be restrictive on what items are generated into the log. This should only happen when opening the dps meter after selecting the character.

For the first comment, the entity (player) name, and class name are already in the logger itself. Also, I thought it wouldn't make sense to implement the "get class from skill" function in both the logger and GUI/ACT Plugin, etc... Since the information is already there, why not just use it?

And for the NPC, it will always fall into the id statement - there isn't a case where a new npc is added that already exists.

Not sure what you mean by this. The added code only works for entities with a class name different than "UnknownClass", aka players.