this way, if you switch back to IITC, then quickly move/zoom (as often is done), unnecessary network requests are avoided
because of the change, there's no need for chat to have it's own resume hook - it already hooks into the refresh code and this is now triggered quickly
For both of them returning false will interupt the default action
'geoSearch' is called when something is entered in the search box.
The argument is the string entered in the search box
'nicknameClicked' is called when a nickname is cliked.
The argument is an object with 2 properties:
- 'event' contain the standard event object
- 'nickname' contain the nick of the user
- remove public @mentions from the faction chat channel
- add default case to chat text handling. if a new message fragment type is added, at least something will be shown in chat instead of being blank (as happened when AT_PLAYER was first introduced)
- highlight your own player name in the chat column in yellow for things you said/actions performed - similar to @mentions from other players
this fixes an issue that, in theory, could have occured with the public chat fetching and over 200 sequential skipped ([secure]) messages. the recent change to skip SYSTEM_NARROWCAST for faction chat was much more likely to trigger the same issue
also
- lighten the red colour used in public chat - was almost impossible to read before
- set the faction chat message count to 100 (it was 50, then bumpped to 200 briefly to work around chat issues)
The old system was getting too complicated to add new features to.
The new one should be easier to understand and will be explained
below. This patch should fix#140 and fix#16.
There are several places where new data requests may come from:
- chat.needMoreMessages checks if we are scrolled too far up or
there is no scrollbar. It then requests new messages.
- scrolling up
- switching the chat tab via chat.chooser
- auto refresh
- once on boot
The latter two always request both types of chat.
Faction and public are handled the same way. Public is later split
into categories. I will explain the faction chat here because it’s
easier.
It starts in chat.requestFaction. This will initialize the query to
the server for data. The exact query is determined by chat.
genPostData. There can only be one faction chat request at a time.
Clearing on map move is handled automatically in code/requests.js.
Let’s assume the data query is successful. It is now passed to
chat.handleFaction which runs some basic checks before the data is
processed and stored in chat._factionData. This is done by chat.
writeDataToHash. The hash keys are the message GUIDs to avoid
duplicates. The hash values are an array of timestamp, processed
message and other meta data.
There is only one way to render faction chat, so data is directly
handed to chat.renderFaction which immediately hands it to chat
.renderData. renderData discards the GUIDs and sorts the values
by their timestamp. It then iterates over the data to insert
date break lines and finally renders the data in the DOM. It also
does some magic to keep the correct scrolling position.
Chat data will be cleared on map move or zoom. However, the
display is not refreshed, so the old, invalid chat data is still
displayed. Only once the data query is finished the data is
rendered. The upside is that small map operations within your
local area appear to never lose their chat data. Downside is that
there’s invalid chat for some time when changing cities.
