| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This adds an yellow hp poison bar to the WebTiles display
("stats_hp_bar_poison") that's show when the player is poisoned and
their calculated hp after poison expires is lower than their current
hp.
|
| | |
|
| |
|
|
|
| |
For players this is displayed in a case of a crash/error/unexpected end.
For watchers the dialog is displayed regardless of how the game ended.
|
| |
|
|
|
| |
This should fix #6644 which was caused by mcache entry being destroyed
and a new one made with the same number between updates.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Player's options are always sent on the game start, by the process
itself. They are also sent to any joining spectators.
Spectators also receive their own config which is generated by running
--print-webtiles-options.
Also added a simple options module to JavaScript. Since all the options
are received on game start the code can assume that the values are
always there and have been validated by the server side code.
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 06ee7f8badf1e19f333e918a572bafb5a23317f8.
Conflicts:
crawl-ref/source/webserver/process_handler.py
crawl-ref/source/webserver/ws_handler.py
My approach here was flawed, and joining spectators could cause
glitches for the player and existing spectators.
|
| |
|
|
| |
Minibars showing on levels when player isn't there.
|
| |
|
|
|
|
| |
Previously on WebTiles spectator join everyone would receive messages
for the current game state. Now these messages are only sent to the
joining spectator.
|
| | |
|
| |
|
|
|
|
|
|
| |
The webtiles_write_menu call in formatted_scroller::jump_to could
happen before the menu was sent, which would then result in two menus
on the client side. This was revealed by the message combining
changes, because the two menus would both be in the same message and
the second would be ignored by the client before.
|
| |
|
|
|
|
| |
Idea being avoiding lag caused by TCP ACK etc. Crawl process provides
messages like always, but also sends a special flush message to the
WebTiles server that causes them to actually be delivered.
|
| |
|
|
|
|
|
|
|
|
| |
When changing level defer sending cursor until the map has been sent, so
that the correct origin coordinate can be used.
Send the map cursor with full updates (for new spectators).
Only delay sending CURSOR_MAP
Send all cursor types for full updates
|
| | |
|
| | |
|
| |
|
|
| |
For example, when inscribing an item from its description.
|
| |
|
|
| |
more information.
|
| | |
|
| |
|
|
| |
This also fixes the wielded weapon and quiver not being shown.
|
| |
|
|
|
|
|
|
| |
Previously, the message pane was rendered on the server side and its
contents were sent to the client as they were displayed in the
terminal. Now, messages are sent as separate objects. This also
necessitates special handling of more prompts and line_reader for
webtiles.
|
| | |
|
| |
|
|
| |
Not yet used on the client side.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Webtiles: Send hp and mp information to the client
- handle player message and update global player object
- send player position
- send player coordinates relativ to origin
- send player after first map draw because otherwise the origin isn't initialized
- redraw minibars if view is moved
- always rerender the player before applying the minibar
- minibars are correctly displayed if health is negative
|
| | |
|
| | |
|
| |
|
|
|
| |
Because the cell didn't get marked dirty when the monster was killed,
the change was never sent to the client.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I had to rename distance() (in coord.h) to distance2() because it conflicts
with the STL function to compare 2 iterators. Not a bad change given how it
returns the square of the distance anyway.
I also had to rename the message global variable (in message.cc) to buffer.
I tried to fix and improve the coding style has much as I could, but I
probably missed a few given how huge and tedious it is.
I also didn't touch crawl-gdb.py, and the stuff in prebuilt, rltiles/tool
and util/levcomp.*, because I have no clue about those.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Sadly, clang and gcc earlier than 4.7 insist that printf("") is bad, and the
option to disable that (-Wno-format-zero-length) doesn't work in C++ mode.
Thus, I had to split {write,send}_message() into two: one with an argument,
one without.
|
| | |
|
| |
|
|
|
|
|
|
| |
In my completely unscientific tests, this vastly improves the cpu
usage of webtiles while running or autoexploring without
travel_delay=-1, bringing it almost to webtiles-in-terminal-mode
levels (which are still somewhat higher than when running without
webtiles support).
|
| |
|
|
| |
There are no feature markers like in console though (yet).
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
See #4280. This will allow regenerating tiles out of view from the
map_knowledge, and we won't need to save the mcache anymore.
There are still a few uses of monster in the interface code, which
will have to be hunted down.
|
| | |
| |
| |
| | |
The tiles flag in scorefile entries is set accordingly.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
server is connected to the crawl process.
Crawl will still be doing more stuff behind the scenes than without
USE_TILE_WEB; but that's necessary so that if the server connects to
the process at a later point, crawl can send the necessary data.
|
| | |
| |
| |
| |
| |
| | |
This mainly means at the moment that the menu is shown as a dialog
floating above the normal layer, instead of switching to the separate
CRT layer.
|
| | |
| |
| |
| |
| |
| | |
This is just for menus using the Menu class. It means that the menu
items are laid out in html on the client side, the menu size adapts to
the window of each spectator, and scrolling is done client-side.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
This is mainly to allow trunk builds, which can have multiple
different crawl versions behind a wrapper script, so that the server
can't know in advance which client version it has to send.
Also, this will install the client data to that folder in the install
target.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
server record ttyrecs.
Crawl compiled with WEBTILES=y should now be playable
normally (i.e. indistinguishable from one compiled without WEBTILES)
when run from a terminal. (This is not yet completely the case.)
The Webtiles data is written on a Unix-domain datagram socket; the
Crawl parameter -webtiles-socket determines a path on which the Crawl
process receives control messages.
The Webtiles server then runs Crawl in a pseudo-terminal and records its
console output into a ttyrec file.
The goal of all this is of course to be able to watch Webtiles games
from ssh, and later the reverse.
|
| |
|
|
|
|
|
|
|
|
|
| |
Most rendering code is moved to cell_renderer.js into the
DungeonCellRenderer class. It can now render to any canvas, which is
necessary for rendering the monster list.
Also, fix the monster bookkeeping in map_knowledge and add a stub
monster_list module.
Finally, some whitespace fixes.
|
| |
|
|
|
|
|
|
|
|
|
| |
This currently includes feat(), and a small part of the monster
info. monster and monster_info get a client_id field which identifies
visible monsters between turns, so that the full monster data doesn't
need to be sent every turn.
This also refactors the way tile data is sent, and reduces bandwidth
usage by removing overhead and omitting x/y coordinates for
consecutive cells.
|
| | |
|
|
|
tileweb.cc now has its own header file. This replicates the public
TilesFramework interface, but the repetition seems better than having
one header file littered with #ifdefs.
|
