| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
.cc, moving its contents into the new stepdown.cc and strings.cc.
(The latter also got many donations from libutil.h.)
Down with stuff! Up the new flesh!
|
|
|
|
|
| |
Sometimes, they're there to emphasize a break between two sections of code,
which is good. In a majority of cases, though, they're just inconsistent.
|
| |
|
|
|
|
|
|
| |
Allows using <, >, $ etc.
Dead keys aren't handled properly (at least not in Firefox on Linux).
|
|
|
|
| |
Previously it was simply broken.
|
|
|
|
| |
And constify, lift things out of loops, etc.
|
|
|
|
|
|
| |
Make them larger when there is already text to be edited (15 characters
plus the old length of the text), and cap the maximum input length at
the buffer size (minus one for the NUL).
|
|
|
|
|
|
|
| |
It was switching to GOTO_CRT after the first line, which in tiles
changed the screen layer, hiding the first line (and everything else,
unless we were already in GOTO_CRT). That was particularly noticeable
during line editing (#7509).
|
|
|
|
|
|
| |
Looks like, unlike "target[t]ing" where a single t is used by many brits and
even some aussies, "cancel[l]ing" has double l even for a good deal of
americans.
|
| |
|
|
|
|
| |
Also remove an unused parameter.
|
| |
|
| |
|
|
|
|
| |
For example, when inscribing an item from its description.
|
|
|
|
| |
more information.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This organizes the game-specific javascript into proper modules, and
converts all messages from Crawl to JS objects. This means that the
game javascript is now loaded asynchronically, which should fix the
browser hang when starting a game.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
(Ok, ok, on Windows it's a ConsoleHandler but does basically the same).
|
|
|
|
|
|
|
|
|
| |
It's broken since 0.5 (where it "just" had a long-unfixed bug with infinite
mana), in 0.6 doesn't even compile and in 0.8 took a number of other tedious
to port blows. If no one stepped up to revive it, no one probably ever will.
DOS is an ancient coprolith, too, and can't really handle the bloat Crawl has.
As a side effect, I made *h and /h work on Windows.
|
|
|
|
|
| |
It's used only in four places, none of them can be actually triggered
currently, but might be in the future.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
There are some issues left, like incorrect wrapping in some cases, but
we can fix them later.
|
| |
| |
| |
| | |
I'm getting tired of rebasing it away from the history.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are sadly some redraw errors when there's line-wrapping involved,
especially if you're editing something not at the end of the buffer,
but these appear to be not regressions so I left them for now.
I am tempted to just brute-force it by redrawing the whole thing and
let ncurses optimize it...
|
| |
| |
| |
| | |
No direction keys yet...
|
|/
|
|
|
|
|
| |
"File:" is shown in your editor's status bar.
"Written by:" was used only for the first person who changed a file. We got
git for that now, and pre-DCSS history is so woefully inaccurate it doesn't
really matter.
|
| |
|
|
|
|
|
|
| |
I did review it manually to find places where they made sense (like some
tables), but for a massive sed job like this there might be places that
I missed.
|
|
|
|
|
|
|
|
|
|
| |
Also name some bounds checking functions less terribly and move to
viewgeom, and add new screen<->grid transforms.
Fixes issue #2215 (Fedhas targeting with messages_at_top) and is
likely to reduce the chance of future breakage with messages_at_top.
Also likely to introduce bugs.
|
|
|
|
| |
(yours truly included).
|
|
|
|
| |
It's not used anymore, and was buggy on windows console.
|
|
|
|
|
|
| |
It was always just getch_ck for our current platforms, except for
Windows tiles, which seems like an accident more than anything
else.
|
|
|
|
|
| |
At the first glance, only one place seems to use actual unchecked user input,
but it's better to be safe than sorry.
|
|
|
|
|
|
| |
Again, allowing mouseover descriptions to hide the message area while
the game is waiting for input in response to a prompt is confusing and
a bad interface.
|
|
|
|
|
| |
(you don't need to cast an X* to a void* and you don't need to cast
arguments to math.h functions such as sqrt.)
|
|
|
|
|
| |
It was using GOTO_DNGN, which could mess up with messages_at_top
or when drawing outside the view window.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issue #484.
There's still the problem that it will wrap to screen column
zero -- a region-aware version of wrapcprintf would be
required to fix this.
It's currently limited to the message window, since that's the
only region that implements scrolling. line_reader itself takes
care of printing its scrolled buffer.
This is something of a hack. It might eventually be desirable
to have some more window-like regions that all store their
content and allow scrolling; there would be some overlap with
tiles' TextRegion etc. But that would mean redoing curses
windows on top of cprintf/cgotoxy...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This should provide more clarity around the wherex()/wherey()/
get_cursor_region() confusion, which has to do with wherex()/wherey()
being screen relative in console mode and region relative in tiles.
It's still a hack, thought, and untested in tiles at the moment.
The main reason behind this is to eventually allow the line_reader
to scroll the region it's working in (see #484).
|