Rune-based ID

[PowerWyrm]

Playing the current master on linux and since this seems to be an ID case, I'll post it here. Character found an un-IDd ring that boosted dex and stealth upon wearing. And after trying to hit an enemy the ring reveals itself to be a Ring of the Mouse and the game informs that "You have learned the rune of enchantment to damage".

The problem is that that damage enchantment is not visible in the ring after ID. It just says Ring of the Mouse <+2, +3>. Character info gives correctly -5 to melee and the dagger used correctly does no damage.

You won't see the enchantment until you've also learned tohit.

[spara]

Playing the current master on linux and since this seems to be an ID case, I'll post it here. Character found an un-IDd ring that boosted dex and stealth upon wearing. And after trying to hit an enemy the ring reveals itself to be a Ring of the Mouse and the game informs that "You have learned the rune of enchantment to damage".

The problem is that that damage enchantment is not visible in the ring after ID. It just says Ring of the Mouse <+2, +3>. Character info gives correctly -5 to melee and the dagger used correctly does no damage.

[d_m]

Last I played GCU, it didn't have enough colors to render all the monsters correctly. Has anything changed?

GCU has been able to render all the colors for many years now, but you do need a correctly-configured terminal (e.g. one that can support TERM=xterm-256color).

I don't think that GCU should dominate over other front-ends, but I do think it still sees a lot of use. (GCU the only way I play Angband, for example.) I would strongly argue against dropping support.

If we need to do things that would "break" GCU, I think a more fundamental UI split between GCU and other display ports would make more sense instead of removal.

[PowerWyrm]

Potions of slime mold juice don't ID on use.

[PowerWyrm]

Angband 4.0.5:
- torch 6 gold
- lantern 564 gold
- shovel 66 gold
- pick 176 gold

Rune branch:
- torch 1 gold
- lantern 24 gold
- shovel 24 gold
- pick 50 gold

This is because normal light and digging bonuses don't account for price anymore. Probably should.

[PowerWyrm]

Player knowledge is now transfered to objects on walkover (see move_player). However, it's not transfered when the player is moved to another location (by use of monster_swap -- teleport, recall...), so you have to manually move away and back to the square to get knowledge of what's under the player. Probably should.

[nikheizen]

Last I played GCU, it didn't have enough colors to render all the monsters correctly. Has anything changed?

I get the full range of colours when running through cygwin on windows (with mintty), but limited colours when running on ubuntu (using konsole).

[Pete Mack]

Last I played GCU, it didn't have enough colors to render all the monsters correctly. Has anything changed?

[debo]

I am serious... and don't call me "can you".

Well, only semi-serious. I just think that GCU is not worth supporting because it's probably quite rarely used and it requires weird workarounds and special cases in code. Admittedly, I'm probably very biased because I'm 'maintaining' and/or 'ruining' ToME 2.x. Just to be clear: I'm not saying we shouldn't have ASCII (my preferred interface, in fact) -- I'm just saying that supporting playing inside a terminal window (as opposed to spawning a new window) doesn't seem worth the complexity to me.

GCU is the only way feasible way for people to play Angband variants on things ilke termcast.org so that other players can watch and learn from them. A fair number of folks still do this. I started with the thick clients, and I like GCU a lot better.

[Derakon]

I actually considered for a while the idea of replacing savefiles with a complete record of all game commands, and on reloading have the game just run through them up until the current point. This is in some ways the correct way to handle saving and reloading; the problem is that it is very fragile to code changes. But having this as a part of the savefile is perhaps a good option.

I don't think this is the correct way, exactly: they're two separate things. You want an encoding of the game state as a save file, because replaying the game each time you load could get prohibitively expensive even for a relatively simple game. But having the ability to record and replay your actions is also valuable.

If you do decide to look into this, you might want to take a look at what tool-assisted speedrunners do. They make speedruns of classic videogames using emulators that are coded to record their actions, and they make heavy use of frame-by-frame play and rewinding to make their speedruns "perfect" (effectively turning an action game into a puzzle game). The savestates (a.k.a. savefiles) they use encode not just the current emulator state, but also the steps taken to reach that state, so they can be used to replay the game from power-on, but usually you just imprint the emulator with the state encoded in the savestate instead.

Some emulators are prone to "desyncs", which means that the actions stored in the savestate do not reliably result in the correct game state. This is usually due to the emulator not being properly deterministic.

[Nick]

I'm not saying you're wrong or that these aren't benefits, but I would guess well in excess of 90% of the player base does not need or even notice these features. They shouldn't be thrown away for no reason, but supporting them does add cost to supporting the game in general.

Agreed, and I think you'd need an overwhelmingly compelling reason (like literally no-one used terminals any more).

It would be nice if there were a better general-purpose remote-play/record/playback functionality than using a terminal. Something smarter than full-screen recording but more flexible than terminals.

Yes, and really that shouldn't be too hard now.

I actually considered for a while the idea of replacing savefiles with a complete record of all game commands, and on reloading have the game just run through them up until the current point. This is in some ways the correct way to handle saving and reloading; the problem is that it is very fragile to code changes. But having this as a part of the savefile is perhaps a good option.

[Derakon]

The "playing inside a terminal window" thing provides actual signifincant benefits:

<snip>

I'm not saying you're wrong or that these aren't benefits, but I would guess well in excess of 90% of the player base does not need or even notice these features. They shouldn't be thrown away for no reason, but supporting them does add cost to supporting the game in general.

It would be nice if there were a better general-purpose remote-play/record/playback functionality than using a terminal. Something smarter than full-screen recording but more flexible than terminals.

[Cold_Heart]

The "playing inside a terminal window" thing provides actual signifincant benefits:

1) playing on a remote headless box via ssh/telnet/whathaveyou from whatever device that you can get an ssh client on (crapdroid? windows phone? a toaster? a potato?)

2) using whatever terminal emulator with whatever features you want

3) interoperation with whatever terminal tools you want (tmux? how about ttyrec? and take it a step further and termcast?)

And to me, a GCU frontend is a very, very large part of what makes a roguelike a roguelike.

[AnonymousHero]

You can't be serious, can you.

If anything,

1) GCU is the main interface
2) any features that can not exist in GCU interface can go die in a fire

I am serious... and don't call me "can you".

Well, only semi-serious. I just think that GCU is not worth supporting because it's probably quite rarely used and it requires weird workarounds and special cases in code. Admittedly, I'm probably very biased because I'm 'maintaining' and/or 'ruining' ToME 2.x. Just to be clear: I'm not saying we shouldn't have ASCII (my preferred interface, in fact) -- I'm just saying that supporting playing inside a terminal window (as opposed to spawning a new window) doesn't seem worth the complexity to me.

[Cold_Heart]

Kill GCU. Seriously, kill it. There's no rationalizaton for what GCU does. Kill it. KILL!

You can't be serious, can you.

If anything,

1) GCU is the main interface
2) any features that can not exist in GCU interface can go die in a fire