Various troubles, Re: [CF List] Server 1.3.0 oddity...
Mark Wedel
mwedel at sonic.net
Wed Jul 10 23:03:23 CDT 2002
I'm just going to reply to all the questions in one message.
Kevin R. Bulgrien wrote:
>
Why does the server complain about map files or overlays not being
>
in /var/crossfire/maps when I log in? The maps are supposed to be
>
in usr... not var... right?
>
>
Everything seems to work ok even though it complains...
>
>
Then, other messages like this show up from time to time... Right now
>
I see a complaint about a store that I just entered...
The server will produce a lot of debugging messages. There is unfortunately
no clear way to know if the error is really a problem or something put in for
informative purposes.
Overlay maps really are not being used for anything right now. They will
probably get used much more with the new world maps. I need to look at the code
more, but they may also get used to replace the non per player unique map stuff
- those are currently saved in a format that is unique.
>
Whereas the ? Name and Weight tabs in the "you see" window are resizeable,
>
the ones in the inventory window are not...
This is intentional. There are some more complicated issues in making those
resizable (whether or not all the tabs should get updated). There also seems to
be some issue of gtk automatically changing the size back again at some point,
but perhaps that is fixed in the more recent issues of GTK. This generally
doesn't seem to be a very big issue.
>
..configure properly detected that makedepend did not exist, but then this
>
happened...
>
Not having makedepend is not critical, but I'll update the makefile to more
gracefully deal with cases where makedepend does not exist.
>
crossfire-client-sounds-1.3.1-realtime.1.rpm package confuses
>
me. The sound files are installed to /usr/share/sounds/crossfire, but the
>
cfsndserv task expects them elsewhere, and spews errors . The sound
>
files really should be in /usr/share/games/crossfire/crossfire-client/sounds...
I believe a new RPM has been rolled that fixes this problem.
>
I noticed that pattern matching was changed with this release...
>
>
Well, it has really changed...
>
>
If there are "five stoneaxes" in the inventory, 'drop five stoneaxes'
>
says "nothing to drop".
>
>
'drop 5 stoneaxes' drops five of everything you have five of...
>
OUCH!
>
>
'drop bows +1' drops bows, not just the +1 bows...
>
though the bow -1 is not dropped...
>
>
Oops ... looks like we went to a minimal match on the regular
>
expression or something...
>
>
'drop daggers' drops all daggers except, for example "throwing
>
daggers"... (I would not have expected it to drop the them, so
>
that is ok.)
The pattern matching for 'drop' happens on the server. There is a bug in the
1.3.0 release that results in the bad matches when you use a drop with a number
greater than 1. This is fixed in CVS.
the issue with bows you describe has been around for quite a while. There is
some 'oddity' in that the function that does this, item_matched_string, does
return different numbers depending on how good it thinks the match is. However,
nothing currently uses those, so the default is basically that very loose
matching happens.
The first rule to note is that all matching is against the start of the
string. Which is why 'drop daggers' won't match against throwing daggers.
The second thing to note is that if the first X characters in the parameter
you give match the first X characters of an object in your inventory, it will be
returned as a loose match. X in this case is the length of the shorter of those
two names - thus, the drop bows +1 matches against 'bows' in your inventory.
There is probably room for improvement. First thing would probably be to not
use the shorter of the two strings being compared, instead, also compare against
the length of the string passed, so the bows +1 does the right thing.
>
>
2)
>
>
Also there is a persisting problem from older releases of the the
>
client...
>
>
Right-clicking an item to drop it, gives messages like:
>
>
There are only one clubs.
>
>
Sure there are, and I wanted you to drop them silly... It seems
>
the only fix here is to drop out of the client and restart it...
>
When this happens, it is not possible to drop anything with
>
a right click.
Just hit the right click again, and it should work.
What is happening is that sometime during play, you are probably hitting the
number keys. the client is holding those as the number of items to drop, so
that value can be held for a very long time. When you try to drop something,
whether successful or not, that count is reset to 0
In the GTK client, you can see what it things the drop/pickup count currently
is - it is displayed in the upper right portion of the inventory pain.
>
>
3) GTK Client
>
>
How on earth do I lock inventory items? I can't see anything in help
>
that gives me a clue... I am sure there is supposed to be some way
>
to do it because there is a lock/unlock option on the inventory...
shift left click on an item in your inventory.
>
>
4)
>
>
What is the "Count" field for?
See note above. It is basically for dropping/picking up less than the total
quantity of something. Eg, you may have 1000 platinum, but only want to drop
500 of it - setting the count to 500 will do just that.
>
>
5)
>
>
Why does the menu selection "Client Spells just dump a bunch of
>
"Spell:" messages on the console session... Nothing else, just that.
I beleive this is reserved for a future enhancement.
>
>
6)
>
>
Is there a point to the menu functions under Action? I guess the
>
pickup's make sense, but why would I click cast, then have to take
>
my hand off the mouse to type in the spell. I must be missing something?
No big reason - I think some of them where to make them more available to new
players who may not know about cast, or who, or whatever else. They are only
really 'shortcuts' - the command they send to the server is the same whether you
do it through that menu or through typing in the command yourself.
>
>
7)
>
>
What does the 'E' key do?
examines the object below you. Generally speaking, pretty useless as you
don't care what is below you. This is basically the same thing as left clicking
on the object.
>
>
8)
>
>
Experienced segmentation faults whenever I tried to save configuration
>
options... Oddly, the options did not relate to the values in the user
>
option file. Permissions were correct. Manually edited the file with
>
vi, and segmentation faults quit happening... Changed a few 0's
>
to 1's...
>
>
It is unclear why this started happening... the client had never been
>
installed on this system before, so the user did not have a pre-existing
>
saved configuration. It had created the file itself, but then was in a
>
state where is seg faulted when the user tried to save new settings.
No clue on this. The save routine appears to do the right thing when itcomes
to making sure the file is opened correctly and whatnot. Would probably need to
see core file to really know what is going on here.
More information about the crossfire
mailing list