change portal level number shadows, so they simulate a solid outline
added self to Contributors
Merge remote-tracking branch 'upstream/gh-pages' into gh-pages

Conflicts:
	style.css
Merge remote-tracking branch 'upstream/gh-pages' into gh-pages
Weak Portal Plugin

At a glance high level indicator of portals in disrepair. Opacity is
used to denote how much it's hurting. (Bright means needs the most
attention.) Factors in current energy, missing shields, or missing
resonators. Red means it needs attention. Orange means the same thing,
except that it's down at least one resonator.

I realise this is in opposition to game convention where dim == almost
dead, but I tried it that way, and it just made no sense to me to do it
that way. The whole point is a high level way to quickly identify
portals that most need repairing. If opacity isn't done this way your
eyes are most drawn to the portals that least need your attention.
fix indenting
add debugging/console capability to devices where it is not available or easily accessibile
Merge branch 'gh-pages' of github.com:breunigs/ingress-intel-total-conversion into gh-pages
add example for decay message JSON (see #137)
Description Added

Description added to plugins readme
Added jQuery UI tooltips
Added missing space between 'span' and 'title'
fix indenting
fix typo
* The jQuery UI js/css file is now taken from ajax.googleapis.com instead of code.jquery.com
* 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
warn when chat message didn’t make it but the server actually send a response
properly check if portal details are available
rework chat handling completely

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.
Add resonator re-render logic
Resonator will re-render if it's level/energy/distance changed
Bring portal to front after resonators re-rendered.
Merge pull request #142 from saithis/tooltip

Added jQuery UI tooltips; fixes #42; patch by saithis