This should make PS marginally slower on really old browsers,
marginally faster on modern browsers, neither of which should be
remotely noticeable.
The intended actual impact is to make it easier to maintain
(`battle-dex` is clearly the wrong place for polyfills) and easier
to reuse outside of PS.
All sound stuff is now handled directly by BattleSound, using the
HTML5 audio API.
The main complicated thing we do with sound is loop music with an intro.
This is unfortunately not supported by ANY sound library out there
(I had to manually add support for it myself to soundManager!)
https://github.com/scottschiller/SoundManager2/pull/13
In the end, I don't think the existing libraries out there actually
give us anything I care about.
This will prevent us from needing to maintain two search engines in
the future.
The new DexSearch doesn't have too much in the way of new features so
far, but it does show filtered things in categories, and list illegal
results in-filter even after sorting.
These are really minor differences, though; the main thing is just that
its architecture should make it much easier to maintain, and in
particular, to add more filters.
`style/STYLING.html` is now a guide of generic CSS classes that can be
used by bots and chat plugins.
CSS classes that can be used by bots and chat plugins are now in a new
`battle-log.css` (previously just a section of `battle.css`)
Several PS styling patterns (specifically, `message-log`, `option`, and
`blocklink`) have been refactored into CSS classes, so that they can
be used by bots and chat plugins (why yes, I do plan on using 2/3 of
them in the log viewer).
Past CSS has been super messy. This refactor tries to make it neater
by adhering to these rules:
- Instead of trying to use e.g. `.setmenu button` selectors (to save
`class=` on every individual list item), give up and just put
`.option` directly on list items. This drastically cuts down on all
the hacks necessary to have `.button` work inside `.setmenu`.
...That's it. That's the only change. It massively cuts down on CSS
complexity. It does slightly complicate the DOM, which I'm not a _huge_
fan of, but CSS unpredictability is nearly impossible to catch and
debug, so it's massively worth it.
This adds the BOM to all HTTP pages as per the HTML5 spec and ensures
all pages use UTF-8 as their meta charset (which is still kept for
compatibility with older browsers).
* Use SockJS' timeout config option
This sets timeouts on connections to 5 minutes, matching the server's
heartbeat interval to close sockets that shouldn't be open anymore.
* Update SockJS client to v1.4.0
This fixes an issue where SockJS would parse the entire HTTP response
received as JSON, not the response's body alone.
- Tooltips work in replays now
- Calculation is better (correctly handles more corner cases)
- Explanations are better (better messages for Magic Room etc)
- Tooltips for sidebar pokemon
- Support "locking" tooltips with long-click / long-tap
- Can copy/paste from locked tooltips
- Increased font size
We now just use JSON.parse and JSON.stringify - it's supported by all
browsers supported by the client.
Tools.safeJSON has also been moved to Storage.safeJSON, since it's not
used in replays at all.
jslider was incredibly buggy, and most likely the cause of the problems
with the teambuilder on mobile, and required some pretty ridiculous
hacks, and leaked memory.
We're now using HTML5 sliders, like we are with the volume controls.
HTML5 sliders aren't supported by IE9, but they're supported by most
other browsers PS cares about. If not, well, they won't look too ugly
probably...
The biggest change is probably that the meta charset tag is now in the
first 1024 bytes, making the page actually valid HTML.
In addition, everything has been unindented, and some extraneous tags
have been removed.
This doesn't support setting accounts up for Google login: that still
has to be manually done via the database by setting the email field to
`username@gmail.com@`, where the second `@` denotes that it's using
Gmail login.
If the email field does end in `@`, `getassertion` will note this by
sending `;;@gmail`, to convey that the server is expecting a Google
login token rather than a password.
Upon receiving `;;@gmail`, the client will replace the password box will
with a Google login button, and then send the resulting Google login
token to the server in the `password` field. The server will validate
the "password" using the Google server libraries, and otherwise handle
the login as normal.
Note that Google login requires various features that a paranoid person
might disable; most notably 3rd-party cookies.
FixesZarel/Pokemon-Showdown#3394
Removed redundancy from code
Moved to tooltips file
Reduced code
Reduced code
Reduced code
Reduced globals to 1
Minor error corrections
Added filename to index.template.html
This also adds a cached learnset format to teambuilder-tables.js,
which replaces and is slightly smaller than learnsets.js and also
has slightly better performance.
This is a large collection of changes that greatly improve past gen
support in the teambuilder.
- Tier lists are now compiled separately from each gen (build-indexes
is really slow about this, which isn't particularly surprising),
as well as for Doubles.
- Learnsets are now compiled separately from each gen. TODO: make an
optimized learnsets.js with gen 1-2 support for client.
- Types in the pokemon list now account for old gens.
- Abilities no longer display in the pokemon list in gen 1-2
- SpA/SpD are replaced by Spc in the pokemon list in gen 1
Also included: A small optimization to the number of DOM nodes for the
teambuilder display, which should improve performance.
The teambuilder is now running on search.js! Not all new features I'd
like to be in are in, but we've now reached feature parity, and most
of the bugs I found during testing have been fixed.
New in search.js is on-demand DOM loading, which basically means
much faster performance because instead of trying to load every single
row of e.g. the pokemon list at once, we just load the part that's
visible, and load the rest only when you scroll it into view.
Also new in search.js is a dexsearch-like feature, replacing the old
details-search system. The new filter system is simpler and more powerful
and has the same API as /dexsearch, although not all the more advanced
dexsearch features are supported.
On-demand DOM loading makes teambuilder loading pretty much completely
instantaneous. There are other small differences in how selection of
pokemon/items/abilities/moves works, but it should overall make more
sense.
When loading a background, we use Color Thief to get a six-color
palette from the image, for use on the main menu buttons.
Only hue and lightness are extracted.
https://github.com/lokesh/color-thief/
Backgrounds are now stored in localStorage in the current origin,
rather than the prefs origin. This allows faster loading, as well
as different backgrounds for different origins, which other
servers should like since it means their backgrounds get seen
at least once before possibly being replaced.
Special thanks to Joim for the base code.
Data (teams and prefs) are now always stored in localStorage in the
`https://play.pokemonshowdown.com` origin. Data storage at a low
level has been mostly rewritten for this, and moved to storage.js.
Tools.prefs has been renamed Storage.prefs, although the API
Tools.prefs(prefName) is still available, and recommended for
battle.js (because storage.js isn't available in replays). All
other pref functionality, such as setting prefs and saving prefs,
should only be used in Storage.prefs.
If the browser blocks third-party cookies in a detectable way,
data is instead stored in the local origin.
As a final safety measure, prefs/teams are mirrored in the local origin
in case third-party cookies are blocked in an undetectable way.
This refactor also replaces the 'init:loadprefs' and 'init:loadteams'
events with a new load tracking system that's basically a simplified
implementation of Promises, documented in the comments for
Tools.makeLoadTracker().
This malware is probably no longer around, and even if it is, the
rest of the file has been changed enough that the previous
workaround probably doesn't work anymore, anyway.
In particular, the header comment was cut down from 2KB to 1KB.
Sadly still not within the spec requirement of 512bytes to the
meta charset, but closer!
Font Awesome 3 -> 4 was a backwards-incompatible change, so this
update is pretty invasive. I tested everything we use it for and it
still works, though. Including supporting both Font Awesome versions
in battle.js.
