[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: various nitpicks
Preston F. Crow wrote:
> I have several nitpicky issues with the client interface (X11, not
> GTK, if it makes a difference) and the server:
> I'm doing some alchemy, and I wanted to bind a key to do the entire
> procedure so I can repeat it. I can do "`bind invoke
> alchemy;apply;get" to do most of it, but I can't figure out how to
> drop a specific number of a given item. (I don't seem to be able to
> get the drop command to work at all, let alone specify a number of
> items--there's no help on that command.) Also, I don't seem to be
> able to use apply to close the cauldron--it wants to apply the
> contents instead, and I can't specify the cauldron by name since I
> don't have it in my inventory.
I'll look at apply something (perhaps as special keyword for apply, or perhaps
some other type of command) so that you can close the container via full
> It seems that the search-items command isn't working fully, or isn't
> searching against the same text that I see when viewing the object in
> the "You see" window. The example you get when entering the command
> by itself, for example, doesn't work. Also, there is no help text
> when you do `help search-items. (Try doing a "`search-items +2" on a
> stack of rings to get some of the better ones; it doesn't work now.)
I'll have to look at what search matches against. It may just match against
the arch name - not sure.
> [Personally, I would like to have it use a regular expression library,
> at least optionally, to let you search on multiple things, or
> something like that. Probably what would be really nice is a general
> item searching mode that allows arbitrarily-complex searching,
> auto-identification (using applicable skills) and such, with a speed
> penalty depending on the complexity of the search. Hence, if you
> search for bolts that weigh less than 1.0, then your speed would drop
> far more than just searching for bolts.]
In theory, all of the above should be client side issues (the client sees what
the item names are, and can then try to apply skills and whatnot). The only
problem is some synchronization issues (by the time the server receives the
request from the client to pick up this, identify that, etc) the player have
moved to the next square and those things are no longer applicable. Since some
of that information is already available to the client (weight for example),
there may not in fact be a great default search penalty (just the actions that
you do after the item.)
The time for skill identification should probably be redone - right now, if you
use a skill to identify all the stuff in your inventory, it takes the same
amount of time (1 tick) whether you are identifying 20 items or 1 item. If you
are doing 20 items, it should take 20 times longer.
More realistically, the entire command area shoudl be redone some so command
can take more than one tick (easy to do), but also be interruptable. For
example, there could very well be a sleep command, which basically means the
character is sleeping (reduced food consumption, increased hp/sp gain), and
character sleeps until fully healed or some specific time passes. But the
character should be able to interrupt that. similar for skills - identifying 50
things should probably take some amount of time (50 ticks lets say). But the
player should be able to interrupt than, and at the same time, there should be
some form of callback from the command loop to keep processing or abort (so in
the case of identification, you get maybe 1 thing per tick, but could interrupt
> There's a bug in container weight display: If you have an active
> container and you drop it (dumping the contents), your total weight
> drops, but the weight displayed for that container doesn't.
This has already been fixed for the next version.
> There are still a few bugs related to pickup and dropping of items.
> I've noticed when doing repeated alchemy that often picking up the
> items out of the cauldron leaves the client confused, thinking that
> they're still in the cauldron (when they merge with identical items in
> my inventory). I think I've seen this in other cases when dropping
could be. The merging of stuff gets trickier - I'll look over some areas of
the code. The most likely culprit is the assumption of the calling functions
that when it calls insert_ob with some object, that object will still be the
right object when insert_ob returns - in case of merging, that is no longer the
> I would like to be able to mark items in my inventory as "invisible."
> For example, my lockpicks. Or perhaps my flint&steel/torches,
> provided I can bind a key to use them (though I usually use dark
This is certainly a client side issue. Only tricky part is keeping track of
that between plays of the client (so next time you run the program, it knows you
want to keep some items hidden.)
> Some items that could merge don't. For example, demon's heads. Also,
> identical documents, such as "practicum of Fendris." Sure, merging
> them would require doing a comparison on the full text of the
> document, but I don't see that as a huge problem very often.
What merges/does not merge may get totally revisted in 0.96 with the revamped
item code. In practicality, almost all items should merge, but the apply code
may have troubles with that as it is right now.
> I would like to see tome/grimore/manual/treatise be used to reflect
> the level of the spell, instead of randomly. Same for priest spells,
> of course.
or they could reflect the type of spells (treatise = information spells,
tome=protection, etc.) I agree that randomly is not the best way to go. One
other thing on the todo list is to add cursed spellbooks. Right now, you pretty
much should almost always apply spellbooks you find - if you have the spell, you
have just identified the book. If you don't, you may want to learn it anyways.
> It would be nice to have some store inventory filters. Mostly, I just
> want to be able to have it never tell me about spell books for spells
> that I already know. I might also like to turn off categories of
> items that I never buy (like wands).
What would be ideal is conversant merchants - don't need to be too smart, but
could still do some things. Like:
merchant: "Hello adventurer. what are you looking for today?"
Merchant "there is a wand of medium fireball at XXX, tomb of large fireball at
So you would sort of get the filtering, but also more useful information (where
the item actually is in the shop). It would do basically a simple substring
match of whatever you tell him (so +2 would show all items that have +2 bonus,
tomb would show all tombs, etc.) Such an npc would definately need some special
logic in the program itself, but that isn't that big a deal.
> I would like to see more specialized containers: scroll case, alchemy
> bag (for body parts, stones, etc.), food container (with auto access
> for eating).
New containers are generally easy to do. Special properties of the containers
are more difficult (auto eating food out of the container, or slowing down body
part decomposition in case of an icebox container, etc.)
-- Mark Wedel
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to firstname.lastname@example.org]