- make update URLS https - required by firefox+greasemonkey
- add build name + date/time to description of all plugins, and moved to front for main IITC
- ensure all plugins have a A.B.C. version number format - required now they append the date+time digits
- no smooth upgrade path from current 'dist' folder - so changed to 'release'. users will have to manually update this time, but will be fine fron now onwards (in theory!)
- plugins are now parsed for @@..@@ replacements
- main script and plugins have separate .meta.js files created - less web server load for update checks
- build script has variables for resource URL, update URL, etc, substituted via @@..@@ into main script and all plugins
loading dependencies just got a lot harder. External JS and CSS files
are now included directly in the file while building. This does not yet
work for plugins. I will make an emergency release soon, so at least
main works.
For now only alert windows are converted automatically. You can alert custom
HTML code like so: alert('<strong>herp a derp</strong>', true);
Main can use this feature immediately, all plugins that are advertized to be
stable may only use this once 0.7 is released.
* disable tracking for tooltips and make them behave more like regular ones
(this also stops my fan from spinning up when using the intel map)
Improvements welcome. Tooltips are currently placed at the bottom of the
element instead of next to cursor. It seems it’s either tracking or placing
it not anywhere where one would expect a tooltip. I immediately regret
having chosen jQueryUI. It’s not very flexible and has awkward defaults.
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.
* Table or not is now autodetected, removed data-tooltip attributes
* Empty table cells are now possible
* Removed duplicated \t's on some titles
* Some tooltip code cleanup
