Angband.oook.cz
Angband.oook.cz
AboutDownloadVariantsLadderForumCompetitionSpoilersComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old August 22, 2011, 21:01   #91
EpicMan
Adept
 
Join Date: Dec 2009
Location: Dallas, Texas, USA
Posts: 241
EpicMan is on a distinguished road
What about 'bane' instead of *slay*?

So "Foo of *slay* orc" becomes "Foo (Orcbane)", "*slay* demon" becomes "(Demonbane)", etc.
EpicMan is offline   Reply With Quote
Old August 22, 2011, 21:15   #92
fph
Swordsman
 
Join Date: Apr 2009
Location: Berlin / Italy
Posts: 356
fph is on a distinguished road
We could in fact take the occasion to rename
*slay* X -> X's bane
*healing* -> greater healing
*remove curse* -> remove heavy curse (seems more noob-friendly: that's what it does, isn't it?)
*enlightenment* -> greater enlightenment, or greater knowledge

Just sayin', too. Ok, but that's cheating --- I agree with d_m, we shouldn't let the doc format force decisions on game content.

I'd say let me ponder for some other days on RST's documentation, maybe there is a better way out that has eluded me. Of course anyone else, with or without previous RST experience, is free to suggest solutions. Maybe there's a clever use of "interpreted text" or "substitution directives" that I am now missing.

There's another problem that I forgot in my previous message, and that we could in fact turn into a feature to our advantage: there is already some "markup" in the lib/help files, namely, the lines starting with asterisks in text such as
Quote:
***** <pickup_always>
***** <pickup_inven>
Always pickup items [pickup_always]
Always pickup items matching inventory [pickup_inven]
If pickup_always is on, all items are always picked up, providing it is
safe to do so. If pickup_inven is on, then items matching those in your
inventory are always picked up.
If I am not mistaken, they are used to provide context-sensitive help. It would be nice to convert them to some RST-approved construct.

So in fact we're not talking really "readable TXT" + "valid RST", but rather "readable TXT-with-some-extra-interpreted-markup" + "valid RST": maybe if we design this additional markup language well we can have it interact well with RST.
__________________
Dive fast, die young, leave a high-CHA corpse.
fph is offline   Reply With Quote
Old August 23, 2011, 00:11   #93
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,882
Derakon is on a distinguished road
I'd say Enlightenment => Wizard Sight; *Enlightenment* => Enlightenment. But that's just me.
Derakon is online now   Reply With Quote
Old August 23, 2011, 08:41   #94
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 4,992
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by fph View Post
We could in fact take the occasion to rename
*slay* X -> X's bane
*healing* -> greater healing
*remove curse* -> remove heavy curse (seems more noob-friendly: that's what it does, isn't it?)
*enlightenment* -> greater enlightenment, or greater knowledge

Just sayin', too. Ok, but that's cheating --- I agree with d_m, we shouldn't let the doc format force decisions on game content.
... but in all these cases, getting rid of the asterisks would be a good move for all sorts of reasons.
Quote:
There's another problem that I forgot in my previous message, and that we could in fact turn into a feature to our advantage: there is already some "markup" in the lib/help files, namely, the lines starting with asterisks in text such as

If I am not mistaken, they are used to provide context-sensitive help. It would be nice to convert them to some RST-approved construct.

So in fact we're not talking really "readable TXT" + "valid RST", but rather "readable TXT-with-some-extra-interpreted-markup" + "valid RST": maybe if we design this additional markup language well we can have it interact well with RST.
Yes, absolutely. The goal is to have more context-sensitive help available in the game (at the moment it's only the options), so we definitely need a way to do this. Maybe we could get the game to read the RST directly, and dispense with the txt-with-markup altogether?
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old August 23, 2011, 09:36   #95
myshkin
Angband Devteam member
 
Join Date: Apr 2007
Posts: 306
myshkin is on a distinguished road
Quote:
Originally Posted by fph View Post
There's another problem that I forgot in my previous message, and that we could in fact turn into a feature to our advantage: there is already some "markup" in the lib/help files, namely, the lines starting with asterisks in text such as

If I am not mistaken, they are used to provide context-sensitive help. It would be nice to convert them to some RST-approved construct.

So in fact we're not talking really "readable TXT" + "valid RST", but rather "readable TXT-with-some-extra-interpreted-markup" + "valid RST": maybe if we design this additional markup language well we can have it interact well with RST.
The current markup language recognizes menu items and tags, both denoted by five asterisks at the beginning of the line. Menus behave as one might expect, where pressing 'a' selects menu item a, and so forth. Tags are essentially the same as HTML anchors; one can call show_file("options.txt#use_sound", NULL, 0, 0), and the file browser will pop up options.txt starting from the use_sound tag.

An rST reference can replace menu items, and an rST internal hyperlink target should suffice to replace tags. The show_file() routine could be modified to read the subset of rST we decide to use in the help files. (I hope that subset is very small.)
myshkin is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Reviving Iso-Angband, an isometric view addon for Angband Hajo Development 111 August 3, 2014 19:44


All times are GMT +1. The time now is 01:33.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.