Re: [crossfire] NPC Help

[Kevin Zheng]

On 2/19/22 5:59 PM, Preston Crow wrote:
If I attack an NPC by standing next to it and attacking with something 
like 'use_skill one' (or applying a sword and shift-arrow in the 
direction of the monster), then the NPC will clear the unaggressive flag 
and call monster_npc_call_help() to alert nearby monsters.  This is in 
server/attack.c: hit_player() at about line 2072.  If I attack the 
monster by running at it, then the code in server/move.c: push_obj() at 
about line 481 does not call for help.


Is that intentional?

Also, in mosnter_npc_call_help(), it uses object_set_enemy() but does 
not clear the unaggressive flag, which doesn't seem to make the NPCs 
move and attack me in my testing.


Is that also intentional?


I remember looking nearby in that neighborhood of code, and so my guess 
is probably not. There are a lot of code paths that should result in a 
monster calling for help, so my guess is that there is some code 
duplication that makes this happen inconsistently.


(If I remember, I was looking at how monsters that are asleep, when 
attacked through a certain code path, call for help...)


If you have a fix, I would welcome it to be committed.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
IRC: http://crossfire.real-time.com/irc/index.html
Discord: http://crossfire.real-time.com/discord/index.html
Project Site: https://sourceforge.net/projects/crossfire/
Wiki: http://wiki.cross-fire.org/
Website: http://crossfire.real-time.com

Re: [crossfire] Default hp/sp for exits

[Kevin Zheng]

On 2/18/22 10:54 AM, Nicolas Weeger wrote:

I expect there are maps where the exit target is zero in one of the two
coordinates.  Since doing a mix of default and specified coordinates is
probably a bad idea, I would have the server convert a single -1 to a
0.  I would then only need to search through the maps for any exits with
a slaying field but not hp or sp, just in case there are any 0,0 exits
on purpose.


That can easily be checked automatically if needed.

Note that this is the current behaviour - if one coordinate is -1, then it'll
be replaced by the default map enter x/y one (again, see enter_map()).


I believe Preston was pointing out that existing maps, that have one of 
hp/sp set to zero, will not have a hp/sp field (because object_diff() 
will remove them), but will change to -1 after the change.


I suspect there are few exits where one of the coordinates to go zero, 
but it would be good to do a search and fix them up in case.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
IRC: http://crossfire.real-time.com/irc/index.html
Discord: http://crossfire.real-time.com/discord/index.html
Project Site: https://sourceforge.net/projects/crossfire/
Wiki: http://wiki.cross-fire.org/
Website: http://crossfire.real-time.com

Re: [crossfire] Duplicators that self-destruct

[Kevin Zheng]

On 2/15/22 8:11 PM, Preston Crow wrote:
I would like to have duplicators that self-destruct after use.  I would 
use the 'hp' field, but it's already set to one in the archetype, so I'm 
thinking of using the value.  I have it working on my server:


     }
*    if ( op->value ) {**
**    --op->value;**
**    if ( !op->value ) {**
**    object_remove( op );**
**object_free_drop_inventory(op);**
**    return;**
**    }**
**    }*
     if ( count <= 1 ) break;
     --count;

That works.  I'm using it in apartments to remove goldfloors and leave 
everything pristine, especially where it's buildable after things 
trigger.  Is there any issue with my pushing this change? Would a 
different field make more sense for this (perhaps 'sp')?


A couple other fields that come to mind are 'food' and 
'generator_limit'. As long as it's not being used for something else in 
the type you're working with though, it should be fine.


Just double checking because I don't have diff context, this is only 
being applied in the type code for duplicators, right?


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
IRC: http://crossfire.real-time.com/irc/index.html
Discord: http://crossfire.real-time.com/discord/index.html
Project Site: https://sourceforge.net/projects/crossfire/
Wiki: http://wiki.cross-fire.org/
Website: http://crossfire.real-time.com

Re: [crossfire] File format

[Kevin Zheng]

On 1/12/22 7:42 PM, Steven Johnson wrote:

I was curious how each format would look when using actual crossfire data.
So, I made this webpage to show it! 
https://shjohnson314.com/cf/format-compare/ 



I show the following side-by-side: Current, YAML, XML, JSON, TOML
using an example of formulae descriptions.


Thank you, Steve, for putting this together.

I think your arguments preferring YAML or XML over JSON are compelling.

I'm not very familiar with the parser libraries that are available for 
YAML or XML parsing. I would find it useful if someone could comment on 
choices for C or C++ and Java YAML and XML parsers.


(Java, because Gridarta is written in Java.)

Is there an analog to XSD validation for YAML?

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
IRC: http://crossfire.real-time.com/irc/index.html
Discord: http://crossfire.real-time.com/discord/index.html
Project Site: https://sourceforge.net/projects/crossfire/
Wiki: http://wiki.cross-fire.org/
Website: http://crossfire.real-time.com

Re: [crossfire] Custom items & monsters on maps

[Kevin Zheng]

On 8/1/21 7:46 AM, Preston Crow wrote:

On 2021-08-01 05:15, Nicolas Weeger wrote:

I wonder if instead of setting custom values for items & monsters
on maps, it wouldn't be better to create artifacts (with a 0 chance
of being generated) and use it in maps.


The rationale I can see is that it makes it much easier to balance
items/ monsters (since artifacts will give all available
items/monsters, instead of needing to check all maps for custom
items).

It'll also allow changing items the players possess (which is not 
currently possible with custom items).


I think the advantages for balancing outweigh the inconvenience.

It would also help to have a global table of artifacts, so that new 
artifacts can be balanced in the context of existing ones.



One limitation though is that artifacts can only have names in the
 form "item of artifact", whereas custom items/monsters can have
any custom name.


This is a technical limitation that can be fixed or worked around, for 
example, by utilizing the "custom name" field (currently only used for 
player-given custom names) or by adding a new field.



I think both the naming restriction and the added complexity of
making custom items in maps makes this a bad idea.  For major
end-of-dungeon loot items, I can see it making sense, but not as a
general requirement.


I agree that the tools for editing archetypes are pretty much 
non-existent, and the tools for editing custom items (Gridarta) is 
pretty easy to use. I don't think this is a reason for not doing this, 
but rather, we should focus on improving the tools: either adding this 
to CRE, or adding that to Gridarta.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Cleaning arch

[Kevin Zheng]

On 6/6/21 3:34 AM, Nicolas Weeger wrote:

I propose to remove the arch/dev directory totally.

It contains old scripts that probably no one remembers, faces that weren't
used in decades and are in wrong perspective, things like that.


Hearing no objections, I think it's safe for you to go ahead and do 
this. If we find out we're missing anything, we can always revert from 
history.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Finding maps and their location, moving around

[Kevin Zheng]

On 5/30/21 12:37 AM, Nicolas Weeger wrote:

I think one issue in the game is that many maps aren't easy to find or even to
know that they exist.


I agree this is a problem, but don't have good ideas on this right now.


For some, quests could be added so the player at least knows the map exist and
is reminded to try to locate them. May be be "chaining" quests, that is when
you complete one quest, some NPCs start giving hints on other quests?


Maybe we should spend some time making random NPCs in taverns and the 
like more talkative. Right now the dialog system encourages giving 
individual NPCs dialog, when what we really need is for random people to 
offer advice once in a while.


Other quest starting points are in library books; when I read the book, 
I start a quest encouraging me to go looking. We should have more 
quests, and more starts.



Once found, it'll be the same issue when the player wants to find again the map
- even if s.he remembers approximately the location, it's a pain to find
again...

I added a long time ago a "GPS"-like system, that enabled to get back to one
specific spot in the world map, but it isn't available anywhere. Should this be
activated so players can easily find again some points in the world? Should we
add "rough" maps that would guide players towards some location?


Could you explain how that GPS system works?

What I've been thinking about this is to have a sort of Rhyzian amulet 
that can be set and reset. So, once a player finds something interesting 
on the world map, the could program (call it "imbune" or something) 
their amulet to point back towards their location.



Should we invent some form of permanent portal, that a player could build in
her/his apartments, then add destinations by being at the desired spot in the
world maps? Something like town portal, but more permanent... Of course
there's always the issue that it probably needs to be a high-costing item that
would be really useful for low-level players... :s


I don't like the idea of permanent portals. In my opinion, the 
teleporters in the apartment and guilds are already a bit much. Players 
should take advantage of means of transport that do exist, like the 
carts, ships, and dragon hangers. Maybe a good walk here or there.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Finding maps and their location, moving around

[Kevin Zheng]

On 5/30/21 12:15 PM, Nicolas Weeger wrote:

Could you explain how that GPS system works?

What I've been thinking about this is to have a sort of Rhyzian amulet
that can be set and reset. So, once a player finds something interesting
on the world map, the could program (call it "imbune" or something)
their amulet to point back towards their location.


It works exactly like that :)

You first 'reset' it to a specific origin, then when applied it'll tell you your
position relative to that origin.

So eg '10, -13'.


I think this sounds like roughly what we want.

I think it would be more user-friendly if, like the Rhyzian amulet, the 
GPS just told the player which direction to move in.


I think it could also use a new name, because GPS (and Galileo, GLONASS, 
Beido, etc.) is a relatively recent invention.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] [PATCH] Add follow command for non-DMs, allow following into permanent apartments

[Kevin Zheng]

Hi there,

The three patches attached here enable the 'follow' command for non-DM 
players. It allows players to follow each other, including through exits 
and permanent apartments.


When two players are on the same tiled map, this code simply calls
player_move() in the direction of the player being followed. If the
player being followed moves through an exit, that the exit object is
copied to a new field in the player structure. The follower then moves
to the exit (instead of the player) and applies the exit once on top.
This means that gates, check_inv's, and other forms of blocked movement
will still continue to be effective.

This patch reduces the possibility of abuse by requiring players be in 
the same party in order to follow each other. If the followed player 
leaves the party at any point, players can no longer follow them.


Patch 2 allows followers to follow into unique maps such as permanent 
apartments. This allows players to visit each others' permanent apartments.


I welcome your feedback and discussion about these changes here, or on 
the SourceForge tracker:


https://sourceforge.net/p/crossfire/patches/400/

Regards,
Kevin
From f0c24d6d2ec3a7a3b38977e2c45b8b6edadc446c Mon Sep 17 00:00:00 2001
From: Kevin Zheng 
Date: Sat, 14 Nov 2020 11:55:29 -0800
Subject: [PATCH 1/3] Enable 'follow' command for non-DMs

The 'follow' command allows DMs to follow players by teleporting to them
when they move away. This patch reworks this command so that ordinary
players can use it to follow each other, including through exits,
without teleportation (and thus violating the map security model).

When two players are on the same tiled map, this code simply calls
player_move() in the direction of the player being followed. If the
player being followed moves through an exit, that the exit object is
copied to a new field in the player structure. The follower then moves
to the exit (instead of the player) and applies the exit once on top.
This means that gates, check_inv's, and other forms of blocked movement
will still continue to be effective.
---
 common/player.c   |  5 +++
 include/player.h  |  2 +
 include/server.h  |  2 +
 server/c_wiz.c| 32 
 server/commands.c |  2 +-
 server/server.c   | 95 +--
 6 files changed, 110 insertions(+), 28 deletions(-)

diff --git a/common/player.c b/common/player.c
index e8c68880..6e5a7da2 100644
--- a/common/player.c
+++ b/common/player.c
@@ -46,6 +46,11 @@ void clear_player(player *pl) {
 }
 if (pl->unarmed_skill)
 FREE_AND_CLEAR_STR(pl->unarmed_skill);
+
+if (pl->last_exit != NULL) {
+object_free(pl->last_exit, FREE_OBJ_NO_DESTROY_CALLBACK);
+pl->last_exit = NULL;
+}
 }
 
 /**
diff --git a/include/player.h b/include/player.h
index c4fd6a06..84ecf362 100644
--- a/include/player.h
+++ b/include/player.h
@@ -188,6 +188,8 @@ typedef struct pl {
   * but we will have to get password first
   * so we have to remember which party to
   * join. */
+struct obj *last_exit;   /**< Last exit used by player or NULL */
+
 party_rejoin_mode rejoin_party;  /**< Whether to rejoin or not party at login. */
 charsearch_str[MAX_BUF]; /**< Item we are looking for. */
 uint32_t  mark_count;  /**< Count of marked object. */
diff --git a/include/server.h b/include/server.h
index 81361b07..db1e771a 100644
--- a/include/server.h
+++ b/include/server.h
@@ -9,4 +9,6 @@ void player_map_change_common(object* op, mapstruct* const oldmap,
   mapstruct* const newmap);
 void login_check_shutdown(object* const op);
 
+bool can_follow(object*, player*);
+
 #endif
diff --git a/server/c_wiz.c b/server/c_wiz.c
index eaf0acb4..f0bd7c9c 100644
--- a/server/c_wiz.c
+++ b/server/c_wiz.c
@@ -1982,8 +1982,6 @@ void command_nowiz(object *op, const char *params) { /* 'noadm' is alias */
 CLEAR_FLAG(op, FLAG_WIZ);
 CLEAR_FLAG(op, FLAG_WIZPASS);
 CLEAR_FLAG(op, FLAG_WIZCAST);
-if (op->contr->followed_player)
-FREE_AND_CLEAR_STR(op->contr->followed_player);
 
 if (settings.real_wiz == TRUE)
 CLEAR_FLAG(op, FLAG_WAS_WIZ);
@@ -2689,11 +2687,16 @@ void command_style_map_info(object *op, const char *params) {
  (unsigned long)(objects_used*sizeof(object)));
 }
 
+bool can_follow(object* op, player* other) {
+// Only allow follow from same party.
+return !(other->ob->contr->party == NULL || op->contr->party != other->ob->contr->party);
+}
+
 /**
  * DM wants to follow a player, or stop following a player.
  *
  * @param op
- * wizard.
+ * Player follower
  * @param params
  * player to follow. If NULL, stop following player.
  */
@@ -2702,7 +2705,7 @@ void command_follow(object *op, const char *params) {
 

Re: [crossfire] IRC channel move from Freenode to Libera?

[Kevin Zheng]

On 5/26/21 12:59 PM, Rick Tanner wrote:

In my view of the recent events, I would ask for reasons as to why the
Crossfire project should stay on Freenode.

It is also my view that #crossfire should move to Libera in early
June-2021 as a tentative timeline.


I would support a move to Libera for similar reasons.

Fortunately, with the exception of the Discord bridge, this seems to be 
like a change where we can just pick up shop and put it down elsewhere.


I think it would be best if we could pick a date for an official move. 
That way, discussion doesn't need to proceed on two different channels.


It is May 30th when I'm writing this; is June 5th long enough for 
everyone who wants to be on IRC to move to Libera?


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Git for arch, maps, server, and client

[Kevin Zheng]

Hi there,

I'm pleased to announce that all of the repositories hosted on the 
Crossfire SourceForge have been migrated to Git. Starting now, all new 
commits should be made to Git. These repositories are located at:


https://sourceforge.net/p/crossfire/_list/git

The SVN is now in read-only mode and will no longer be updated.

When committing to Git, please follow our Git commit policy:

1. To preserve linear history, no merge commits in 'master'. When
  merging branches into 'master', rebase the branch against 'master'
  and then do a fast-forward from 'master'.

2. Commit messages begin with a short, one-line summary, followed by a
  blank line, followed by more detailed explanatory text, if necessary.
  Lines are wrapped to approximately 72-ish characters.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Git for arch, maps, server, and client

[Kevin Zheng]

On 5/5/21 9:30 AM, Mark Wedel wrote:
  It looks like write (commit) access can be removed from the SVN repos 
in sourceforge while still letting them exist.  I'd suggest that be 
done, just to prevent any accidental commits (someone forgot to update 
their paths or whatever else).  Plus, it can be used to make sure no one 
commits anything while you are moving things over.


Thanks for the suggestion. This wasn't going to be so easy, because 
there were other subfolders in the repository that weren't part of this 
migration. Looking at the repo now, however, the only sub-directories 
left are jxclient, metaserver, and sounds.


If we also go ahead and migrate these over too, we can go ahead and make 
the entire SVN read-only after the switch.


If there are no objections, I will also go ahead and migrate jxclient, 
metaserver, and sounds.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Git for arch, maps, server, and client

[Kevin Zheng]

Hi there,

Some months ago I proposed switching the arch, maps, server, and client 
repositories to Git. Since feedback on the mailing list was positive, I 
think now is a good time to make the switch.


- If you have SVN checkouts of the arch, maps, server, or client
  repositories, get Git and clone the Git version from:

  https://sourceforge.net/p/crossfire/_list/git

  If you are running a server that tracks one of these repositories, you
  should probably update those, too.

- Before UTC Saturday 2021-05-08 22:00, please continue committing to
  SVN as usual. I will be manually keeping the Git up to date with SVN,
  so it may be a bit slow keeping up. Please do not commit to Git during
  this time.

- At UTC Saturday 2021-05-08 22:00, I will update these Git repositories
  from SVN one last time. Future commits in these repositories should go
  into Git. SVN will continue to be used for the repositories that
  haven't switched. The migrated repositories will still continue to
  exist in SVN for a while, but should not be committed to. Hopefully
  nobody gets confused by the fact that there are two repositories. At
  some point, perhaps we should delete these repositories from SVN.

I'd like to tentatively suggest this policy for commits going into Git:

1. To preserve linear history, no merge commits in 'master'. When
   merging branches into 'master', rebase the branch against 'master'
   and then do a fast-forward from 'master'.

2. Commit messages begin with a short, one-line summary, followed by a
   blank line, followed by more detailed explanatory text, if necessary.
   Lines are wrapped to approximately 72-ish characters.

Comments and feedback is appreciated, as is your patience while we make 
the switch.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Plugins

[Kevin Zheng]

Hi Nicolas,

On 4/11/21 4:11 AM, Nicolas Weeger wrote:

I'd like to move some plugins to the server "core" itself, possibly with
option to disable the relevant code at startup (and if required, disabling/
enabling by a DM, like plugins).

The rationale is that the plugin code adds some overhead, and having code
dynamically loaded isn't that important, I think.


I'd agree with merging the plugins in with the core.

To clarify, I don't think there's appreciable performance overhead, but 
there is a lot of overhead having to shim all server calls through 
CFAPI. This makes it difficult to use functions and data structures in 
the server.



I'm thinking of converting the city bells plugin, then the city life one.


I think this is a great way to get this started.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] 'get' and 'drop'

[Kevin Zheng]

On 1/17/21 10:22 AM, Nicolas Weeger wrote:

I'd like to rework 'get' (and 'take' and 'drop' (and 'dropall') to be more
consistent.

Syntax for both could be (samples with get):
- 'get all' or 'get *' => all items

- 'get part of name' => all items matching 'part of name', like now

- 'get *magic' => all known magic items ; same with '*cursed', then item types
('*armour', '*weapon', '*ring', ...). This is possible with pickup modes, so I
don't see why it shouldn't be possible with the simple command. 'dropall'
already implements that

- 'get #n' => the n-th item below the user or in the container. Could work
when dropping from a opened container too. 1-based because players aren't geek
:)


This seems reasonable; no objections from me.

I'd also like to mention that I don't actually use these commands much, 
preferring to click in the GUI. I don't think these changes would affect 
me much at all.


Thanks,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Sounds

[Kevin Zheng]

On 1/17/21 1:38 AM, Nicolas Weeger wrote:

The "sounds" repository contains various sounds for use with the clients.

Unfortunately many don't have a proper license attached (especially the old
ones).

I therefore propose to remove files with an unknown origin, to (re)start with a
clean state.


I think this proposal seems reasonable. This might also be a good 
opportunity to improve the quality of the default set of sounds.

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Git for arch, maps, server, and client

[Kevin Zheng]

On 1/14/21 7:04 PM, Robert Brockway wrote:
Please consider these repositories read-only at this point, because I 
will be mirroring them by hand from SVN.


Does this means that SVN history will be retained?


Yes, of course. The SVN history was imported and currently synced to SVN 
using git-svn. The 'new' Git repositories have commits still labeled 
'CVS' from a long time ago.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Git for arch, maps, server, and client

[Kevin Zheng]

Hi there,

Based on IRC and private conversations, it seems that many current 
developers and contributors would prefer to use Git. Therefore, I'm 
proposing to migrate the arch, maps, and server to Git.


Some arguments in favor of Git:

- Non-committing contributors can more easily create bite-sized,
  reviewable patches using Git.

- Forks would preserve revision history, making it easier to re-
  integrate changes. Currently, forks tend to start from a source
  release and changes subsequently diverge.

- Fast branching and tagging.

Some arguments against Git:

- It's difficult to understand and use. Fortunately, Git seems to be
  pretty popular these days, and there are many resources for beginners.

- Non-linear history is confusing. I'd like to propose that Crossfire
  maintain linear history by enforcing fast-forward only commits to
  master.

- Large initial clones. Currently, the initial clone of the server is
  24 MiB, the maps 91 MiB, the archs 26.7 MiB, and the client 14 MiB.

- Loss of monotonically-increasing revision identifiers. Sorry.

For a preview of what this might look like, I've pushed 
crossfire-server, crossfire-arch, and crossfire-client repositories to 
SourceForge:


https://sourceforge.net/p/crossfire/_list/git

Please consider these repositories read-only at this point, because I 
will be mirroring them by hand from SVN.


I appreciate comments and thoughts about the proposed migration.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Crossfire 1.75.0 release

[Kevin Zheng]

Hi there,

I'm pleased to announce that Crossfire 1.75.0 is available.

This release brings many changes, fixes, and improvements to the server, 
maps, and clients.


The server now uses Python 3. If you run an existing server, you may 
need to use the cfdb_convert utility to convert some databases into a 
format used in Python 3. Briefly:


$ cd /var/crossfire/
$ cfdb_convert --auto

Since GTKv2 is now EoL'd, this will likely also be the last GTKv2 client 
release that uses Gtk+ 2.


Stay tuned for a separate announcement about the JXClient 1.75.0 release.

Thanks to all of the contributors who made this release possible.

If you run a server, you will need the 'crossfire' and 'crossfire-maps' 
release tarballs. Sounds are now distributed with the crossfire-client 
release and installed by default.


Checksums for the release follow:

SHA256 (crossfire-1.75.0.tar.gz) = 
0441832166f6eece9d64a8a724b149b2fe279cfdd0e63f478c2aaf958f17b605
SHA256 (crossfire-client-1.75.0.tar.gz) = 
f9e320650292e0dae1236c1d14396bf5818428ee5ea23865a9849d203e4368a7
SHA256 (crossfire-maps-1.75.0.tar.gz) = 
dda1bb9bf6477791b643ad78dac615bb038bf2bc795eb1eaf353ac7eabba75d9


Regards,
Kevin



OpenPGP_signature
Description: OpenPGP digital signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire 1.75.0 release engineering

[Kevin Zheng]

On 1/2/21 11:40 AM, Preston Crow wrote:
I have a change to track per-skill high scores that I was meaning to put 
in.  Should I do it now, or wait until after the release? (I've been 
running it on my server for a while.)


Would you mind attaching the patch here? If it's not so big, it would be 
a fun addition to 1.75.0.


Thanks,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Crossfire 1.75.0 release engineering

[Kevin Zheng]

Hi folks,

I am thinking about cutting a 1.75.0 release in the next couple of days. 
I would like to coordinate a full server/maps/arch release as well as 
releases for both the GTKv2 and JXClient.


This release is a good time for those running servers to switch to 
Python 3, before some major code rework in the server.


This will also be the last GTKv2 client using Gtk+2, since Gtk+2 is now 
officially EoL'ed (future GTK client releases will use Gtk3).


I would certainly appreciate an extra set of eyes testing the server 
Python (after the Python 2 migration) and checking the GTK client builds.


Thanks in advance, and happy 2021.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Python 3 conversion for trunk server users

[Kevin Zheng]

Hi folks,

With Python 3's end-of-life nearly upon us, it is time to make the great 
leap and switch to Python 3. Thanks to the work of many others, the 
switch now is relatively small.


Those who are running servers tracking trunk: after r21626, you should 
run cfdb_convert on existing databases. Some additional details about 
cfdb_convert are in the commit message, copied here:


 This Python 3 utility converts Python 2 bsddb 'shelve' databases to the
 default Python 3 'shelve' format.

 Server operators running existing servers should convert existing
 databases after switching to Python 3. Running cfdb_convert with the
 '--auto' flag in the 'var/crossfire' directory will automatically
 convert a list of standard databases with known names.

We anticipate minor fall-out from existing scripts that still use Python 
2 syntax, or result in run-time errors due to semantic changes in Python 
3. Please report them here, or on the list, so that they can be fixed as 
quickly as possible.


Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Archetypes collection changes proposal

[Kevin Zheng]

Hi Nicolas,

Thank you for working on this. As we've discussed, this code is already 
running on Invidious and seems to be in working order.


I think this is ready to be committed to trunk.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Speech bubbles for NPCs

[Kevin Zheng]

Hi there,

This attached patch, along with the attached archetypes, adds speech 
bubbles to monsters and NPCs.


Speech bubbles increase discoverability for interesting dialog. In 
Crossfire, there are many NPCs and monsters who have no dialog, and so 
trying to chat up every single NPC is a bit tedious.


I think a change like this makes the game more fun to play.

Regards,
Kevin
commit 8b7b28cd058be80ea4326cb53157272d50b8d548
Author: Kevin Zheng 
Date:   Sat Nov 14 10:59:20 2020 -0800

Add build protection

Keep track of the builder's name for player-built tiles. Prevent
destroying or building over other players' tiles.

diff --git a/server/build_map.c b/server/build_map.c
index 1d89cb68..e3228104 100644
--- a/server/build_map.c
+++ b/server/build_map.c
@@ -32,6 +32,15 @@
 #include "sproto.h"
 #include "tod.h"
 
+static bool is_build_owner(object *pl, object *item) {
+const char* owner = object_get_value(item, "build_owner");
+if (owner != NULL) {
+return (strcmp(owner, pl->name) == 0);
+} else {
+return true;
+}
+}
+
 /**
  * Check if objects on a square interfere with building.
  *
@@ -45,11 +54,15 @@
  * @return
  * 0 if new_item can't be built on the spot, 1 if it can be built.
  */
-static int can_build_over(struct mapdef *map, object *new_item, short x, short y) {
+static int can_build_over(object *pl, object *new_item, short x, short y) {
+struct mapdef *map = pl->map;
 FOR_MAP_PREPARE(map, x, y, tmp) {
 object *ob;
 
 ob = HEAD(tmp);
+if (!is_build_owner(pl, ob)) {
+return 0;
+}
 if (strcmp(ob->arch->name, "rune_mark") == 0)
 /* you can always build on marking runes, used for connected building things. */
 continue;
@@ -84,7 +97,7 @@ static int can_build_over(struct mapdef *map, object *new_item, short x, short y
 
 /* If item being built is multi-tile, need to check other parts too. */
 if (new_item->more)
-return can_build_over(map, new_item->more, x+new_item->more->arch->clone.x-new_item->arch->clone.x, y+new_item->more->arch->clone.y-new_item->arch->clone.y);
+return can_build_over(pl, new_item->more, x+new_item->more->arch->clone.x-new_item->arch->clone.x, y+new_item->more->arch->clone.y-new_item->arch->clone.y);
 
 return 1;
 }
@@ -979,6 +992,12 @@ void apply_builder_remove(object *pl, int dir) {
 return;
 }
 
+if (!is_build_owner(pl, item)) {
+draw_ext_info(NDI_UNIQUE, 0, pl, MSG_TYPE_APPLY, MSG_TYPE_APPLY_BUILD,
+  "Can't destroy something you didn't build.");
+return;
+}
+
 /* Now remove object, with special cases (buttons & such) */
 switch (item->type) {
 case WALL:
@@ -1114,7 +1133,7 @@ void apply_map_builder(object *pl, int dir) {
 new_item = object_create_arch(new_arch);
 SET_FLAG(new_item, FLAG_IS_BUILDABLE);
 
-if (!can_build_over(pl->map, new_item, x, y)) {
+if (!can_build_over(pl, new_item, x, y)) {
 draw_ext_info(NDI_UNIQUE, 0, pl, MSG_TYPE_APPLY, MSG_TYPE_APPLY_BUILD,
   "You can't build here.");
 return;
@@ -1144,8 +1163,11 @@ void apply_map_builder(object *pl, int dir) {
 LOG(llevError, "apply_map_builder: invalid material subtype %d\n", material->subtype);
 break;
 }
-if (built)
+if (built) {
 object_decrease_nrof_by_one(material);
+// set owner name
+object_set_value(new_item, "build_owner", pl->name, 1);
+}
 return;
 }
 
Object speechbubble
face speech.111
end
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Speech bubbles for NPCs

[Kevin Zheng]

On 11/26/20 12:39 PM, Kevin Zheng wrote:
This attached patch, along with the attached archetypes, adds speech 
bubbles to monsters and NPCs.


I attached the wrong patch. The right one is attached here.
commit 300ed7b84bca652912e2f6b557ab1556383263fc
Author: Kevin Zheng 
Date:   Sat Nov 7 12:45:58 2020 -0800

Add speech bubbles

diff --git a/socket/request.c b/socket/request.c
index aaf82548..c1759c70 100644
--- a/socket/request.c
+++ b/socket/request.c
@@ -1210,6 +1210,18 @@ static int check_probe(int ax, int ay, const object *ob, SockList *sl, socket_st
 return got_one;
 }
 
+static int annotate_ob(int ax, int ay, const object *ob, SockList *sl, socket_struct *ns, int *has_obj, int *alive_layer) {
+int got_one = check_probe(ax, ay, ob, sl, ns, has_obj, alive_layer);
+if (QUERY_FLAG(ob, FLAG_ALIVE) && ob->msg != NULL && ob->type != PLAYER) {
+archetype *dummy = try_find_archetype("speechbubble");
+if (dummy != NULL) {
+got_one += map2_add_ob(ax, ay, MAP_LAYER_FLY2, >clone, sl, ns, has_obj, 0);
+(*alive_layer) = MAP_LAYER_FLY2;
+}
+}
+return got_one;
+}
+
 /*
  * This function is used to check a space (ax, ay) whose only
  * data we may care about are any heads. Basically, this
@@ -1409,7 +1421,7 @@ static void draw_client_map2(object *pl) {
 
 /* if we added the face, or it is a monster's head, check probe spell */
 if (got_one != old_got || (ob->head == NULL && ob->more))
-got_one += check_probe(ax, ay, ob, , >socket, _obj, _layer);
+got_one += annotate_ob(ax, ay, ob, , >socket, _obj, _layer);
 
 /* If we are just storing away the head
  * for future use, then effectively this
@@ -1420,7 +1432,7 @@ static void draw_client_map2(object *pl) {
 del_one += map2_delete_layer(ax, ay, layer, , >socket);
 } else if (ob->head == NULL) {
 /* for single-part items */
-got_one += check_probe(ax, ay, ob, , >socket, _obj, _layer);
+got_one += annotate_ob(ax, ay, ob, , >socket, _obj, _layer);
 }
 } else {
 if (layer != alive_layer)
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Archetypes collection changes proposal

[Kevin Zheng]

On 10/7/20 3:22 AM, Nicolas Weeger wrote:

I've made good progress, with a global skeleton on which to add more files to
read (right now I read .face & .png files).

Right now, partial collect process takes approx 10s. It'll probably take more
at the end, 'cause of more file processing.


Is this code somewhere that we can take an early look at?


I'll just freely troll (to vent some frustration :)), but I have to do really
similar stuff for many structure types (faces, archetypes, treasures,
artifacts, and probably more), and frankly, I'm really tempted to
"accidentally" switch to C++ just to reduce that duplicated code by using good
old std::map<>...


I would support code changes that reduce duplication and make code more 
maintainable.


On the other hand, I'm not sure I have the same in-depth understanding 
(I like to tell myself) of C++ as I do C. If something inevitably 
breaks, I'm not sure I'd know how to fix it. I've run many C++ programs 
in a debugger to figure out what's going on, only to find that some 
constructor or destructor caused a segfault. I have a vague 
understanding of C++ name mangling, but am not sure I could fix a broken 
C++ build.


Perhaps all that's needed is some C++ education on my part.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Archetypes collection changes proposal

[Kevin Zheng]

On 9/16/20 2:38 AM, Nicolas Weeger wrote:
> To simplify, I'll call "assets" everything that is in the "arch" repository: 
> archetypes, pictures, faces, animations, treasures, artifacts, and what ever 
> else I'm missing ;)

Do maps have a place here, as well?

> The goal: make it easier to add or replace existing assets for contributors, 
> simplify assets distribution, and make it easy for server admins to 
> add/remove 
> extra or "official" assets.

These sound like good goals to me.

> My proposal:
> - have the server recursively browse "data" directory to find all assets
> - browse in a deterministic manner (sorted case-sensitive, depth first)
> - allow override of defined assets (thus the need to have a deterministic 
> browsing pattern)
> - remove the requirement for "collect"
> - keep the "collect" mechanism to consolidate assets in big files easy for 
> distribution - have it work for non official assets too

To keep things simple, why keep the collect mechanism? Couldn't we put
the "official" assets into a big ZIP file, and teach the server how to
open ZIP files like ordinary directories? Scan the index, create sorted
case-sensitive depth-first order, etc.

> One big drawback is that the server startup will probably be slower, and the 
> code more complex (to handle overriding).
> 
> I think that's an acceptable drawback, but that's subject to discussion ;)

`make do-collect` on a cold cache on my dated computer, with an SSD,
takes 6.3 sec. I imagine it could be a bit slower for those with
spinning magnetic media. This seems acceptable for a video game, and
particularly for a server that's supposed to be long-running. But, we
should still profile, see what's slow, and try to make this faster.

What would your strategy be for a change like this? One interim
strategy, just to keep everything working, could be to invoke the
current collect process at server start via fork/exec, read in output
via loader, then start. Then merge the steps until they become one.

Regards,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] unaggressive monsters

[Kevin Zheng]

On 9/6/20 7:53 AM, Preston Crow wrote:
> I'm trying to create some monsters that aren't aggressive until they see
> combat near them.  I've taken a regular monster and added 'unaggressive
> 1' which makes them stand there as expected, but they don't notice
> fights around them, only when they are attacked.
> 
> What do I do to make them more trigger happy, but content to stand still
> and chat most of the time?

How close are these unaggressive monsters to the monster you attack?

When an unaggressive monster is attacked, it calls
monster_npc_call_help() in server/monster.c. It currently has
help_radius set to 3, so monsters too far away will not notice.

Is this consistent with what you observe?
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Mapbuilding issues

[Kevin Zheng]

On 8/27/20 1:20 PM, Preston Crow wrote:
> I'm trying to build a map, and I have a button that triggers when a
> player moves onto it as expected, but it doesn't trigger if the player
> appears on top of it because it's the starting square on the map.  I
> also can't get a button to trigger on a bed to reality when a player
> returns to the map, which I assume is the same thing.

Thanks for the observation. I think this is a server bug. I can probably
take a look next week.

Cheers,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Permanent Experience

[Kevin Zheng]

On 8/14/20 12:32 PM, Preston Crow wrote:
> I'm interested in changing the server to replace tracking of permanent
> experience with tracking of total experience.  This would work out to be
> almost exactly the same, except it eliminates any rounding.  For
> example, if you had some skill (say hiding) that always gave out 1xp at
> a time, you would never be able to have permanent experience exceed 50%
> of the high-water mark on current experience (or whatever percentage
> threshold you're using).
> 
> I have this working on my Crowcastle server, but I want to clean up the
> patch a bit before pushing it, and I want to check if anyone has any
> objections to this design change.  I'll have it so that if it loads a
> character with perm_exp, it will adjust it up to the total_exp value
> that gives the same effective perm_exp, so it should be a transparent
> upgrade.

I'm not very familiar with how permanent experience is currently
tracked, but it sounds like you're familiar or have worked it out.

Would you mind briefly explaining how the current system works?

Thanks,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] r21264 broke the server build

[Kevin Zheng]

Hi there,

It looks like r21264 broke the server build for several of us. The
offending part of the diff is:

diff --git a/common/map.c b/common/map.c
index 724cbccc..7175f3d0 100644
--- a/common/map.c
+++ b/common/map.c
@@ -652,6 +652,21 @@ static void load_objects(mapstruct *m, FILE *fp,
int mapflags) {
 continue;
 }

+/*
+ * Generators normally start with a speed_left of -0.1.  They
+ * trigger as soon as they go positive, then get 1 subtracted from
+ * their speed_left.  If asked to randomize the times to avoid
+ * waves of monsters from identical generators, we set the
+ * speed_left to a random value between -0.6 and +0.4, so the
+ * average is still the same.
+ *
+ * Note the comparison is tricky, as it has to be cast exactly the
+ * same way it's set in arch.c:first_arch_pass()
+ */
+if ( settings.generator_init_time_random && QUERY_FLAG(op,
FLAG_GENERATOR) && op->speed_left == (float)-0.1 ) {
+op->speed_left = (cf_random() % 10) / 10. - 0.6;
+}
+

Specifically, there's no settings.generator_init_time_random.

Did you mean to have this change in a separate commit?

Thanks,
Kevin
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Minor issues

[Kevin Zheng]

On 8/9/20 1:08 PM, Preston Crow wrote:
> In configure.ac, it is looking python2 instead of python-2.7.  On my
> system it fails to detect with python2, but with a check for python-2.7,
> it works.  I'm not an expert on autoconf, so I don't know if there's an
> easy way to check for either.  (Of course, moving to python 3 would make
> all kinds of sense, but that's another topic.)

This seems to have something to do with the pkg-config name for your
Python 2 installation. pkg-config can be instructed to check both by
changing [python2] to [python2 python-2.7].

Enough things have changed that replacing python2 with python3 will get
you a working build with Python 3. It's the scripts that still need to
be converted to Python 3.

> In common/init.c, things break badly if someone adds a field in the
> middle of include/global.h.  This can easily be fixed by assigning
> specific field names, though that would move us up to a minimum of C99.

The code is already C99; that's fine. Patch welcome.

> With gcc 10, you get multiple definition errors on shutdown_flag.  This
> should be declared extern in the .h and also declared in one C file.

Patch welcome here; it's only not already there because I don't think my
Clang warns about the same issue?

> I'm happy to push commits for the second two issues, but I don't trust
> that my fix for the first one wouldn't break things for other people. 
> (I'm not sure if I have permission to push, though.)
If not, a patch to the mailing list (here) is welcome.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] The problem with Valkyrie

[Kevin Zheng]

On 5/10/20 3:53 AM, Robert Brockway wrote:
> On Fri, 8 May 2020, Kevin Zheng wrote:
> 
>> I'm currently exploring the least painful way to resurrect can_use_range
>> without leaving a large portion of the population unable to use wands
>> and rods.
> 
> Fantastic thanks.  Anyone with can_use_range=1 in the character file
> would presumably be safe right?

Right, but the real trick is to make sure that existing characters don't
suddenly lose the ability to use wands and rods.

I think the right thing to do might just be to set can_use_range for all
player archs (in arch/player), just like can_use_weapon and
can_use_shield, and then make the code changes to support using
can_use_range again.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] The problem with Valkyrie

[Kevin Zheng]

Some initial investigation reveals that can_use_range, can_use_bow, and
can_use_ring have not applied to player characters since July 2002, with
the introduction of body parts for player characters. If any of these
flags are set for players, they are not honored nor saved.

can_use_weapon, can_use_shield, and can_use_armour continue to be used
for deity weapon restrictions.

I'm currently exploring the least painful way to resurrect can_use_range
without leaving a large portion of the population unable to use wands
and rods.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] The problem with Valkyrie

[Kevin Zheng]

On 5/8/20 9:38 PM, Robert Brockway wrote:
> This has bothered me for a while so I've changed Valkyrie on my server.
> I've allowed followers of Valkyrie the Turning path only.  I intend to
> block their access to rods, staves and wands but that isn't working
> right now.  I've set can_use_range 0 in the Object Valkyrie archtype but
> it isn't getting inherited when a test character converts to Valkyrie as
> I thought it would.  I am a few months behind head on SVN so will update
> and retest.

Allowing only the turning path doesn't block non-turning magic items,
correct?

Weapon restrictions aren't new and if I remember correctly, work for
other gods. If you'd like, I can take help you take a look at why
can_use_range isn't being copied correctly.

Another possibility is that can_use_range is actually copied, but just
not respected when inside a 'force' object. You could check this by
opening the player file in a text editor.

Let me know if you'd like some help taking a whack at this.

Regards,
Kevin

P.S. I appreciated the story!

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Various adjustments

[Kevin Zheng]

On 5/8/20 9:15 AM, Rick Tanner wrote:
> I see no help file exists for fix_me, but I found this in the ChangeLog:
> 
> fix_me command added - basically just calls the fixme function.  Can be
> useful if you that your characters weight is for some reason incorrect.
> Another commit added "Add sum_weight() call to fix_me command so that
> players weight is properly recalculated"
> 
> Looks to me that fix_me should remain accessible to players?

I agree. Ideally, we would not need a fix_me command, but until all the
bugs are squashed, I think this should be available to players.

> As for forget_spell - I have heard from players they use that to keep
> their spell list short, or to get rid of low level spells (i.e., cause
> light wounds when they have cause critical wounds) that are no longer
> used. Otherwise, I am not sure why one would use this command.
> 
> From my testing, forget_spell was available as a player. It is listed as
> a dm_command though on the wiki and as best as I can tell should be a DM
> only ability? lib/wizhelp/forget_spell

I added this command. I initially designed it for DM's (as an undo for
learn_spell), but agree that it's useful to players.

I'm not sure if this could be abused; you could repeatedly learn and
unlearn low-level spells. But what would that give you?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Proposal: retire MAX_OBJECTS and object allocator

[Kevin Zheng]

On 3/10/20 9:56 PM, Mark Wedel wrote:
>  Not sure if still the case, but at one time, performance of allocating
> thousands of new objects individually increased lag (when loading new
> maps).  So doing it in blocks of 500 or whatever was faster.  At one
> point I had put in option to do individually allocation, simply for the
> reason above - if using a memory debugger, that block of objects failed
> to work.

Allocating one object at a time does make mapfile_load() slower (all
numbers in us):

x CF Object Allocator
+ 1 object per calloc()
+--+
|  x+  |
|x xx  x  x*x  x+   +  + + + +   ++|
|  |_A_M__|   |___A_M_||
+--+
N   Min   MaxMedian   AvgStddev
x  10 16154 17814   17309.5   17148.7 579.95633
+  10 17560 20576 19169   19021.9 1033.7963
Difference at 95.0% confidence
1873.2 +/- 787.548
10.9233% +/- 4.71741%
(Student's t, pooled s = 838.178)

This measurement was made with n=10 loading /world/world_105_115 with a
warm disk cache, with a newly started server each time so that memory
fragmentation hasn't occurred. Time elapsed was measured with a
monotonic clock.

It looks like 1-object-per-alloc increases the median by 2 ms. For tiled
world maps, at worse case 5 maps are loaded at a time, for a total
additional latency of 10 ms, or about a 11% increase.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Proposal: retire MAX_OBJECTS and object allocator

[Kevin Zheng]

Thanks, Mark, for the review.

On 3/10/20 9:56 PM, Mark Wedel wrote:
>> The object allocator allocates OBJ_EXPAND objects at a time and manages
>> its own free list. It is faster at allocating many objects at once, but
>> defeats memory debuggers and mitigation techniques. It also does not
>> return unused memory to the operating system.
> 
>  Not sure if still the case, but at one time, performance of allocating
> thousands of new objects individually increased lag (when loading new
> maps).  So doing it in blocks of 500 or whatever was faster.  At one
> point I had put in option to do individually allocation, simply for the
> reason above - if using a memory debugger, that block of objects failed
> to work.

I have not measured the latency loading maps. I'll measure this and
hopefully get back with some results.

>  Minor nit - even free() on a memory object does not return it to the OS
> - it tells malloc that block of memory is available again, and on a
> future call, malloc will re-use it, though you can get fragmentation
> (malloc may decide to use that memory for something smaller than an
> object).
This may be true for some allocators, but not jemalloc. Now, not all
allocators are jemalloc and that might be important to consider.

In jemalloc, unused dirty pages are kept around for re-allocation but
eventually "returned" to the operating system via madvise(...MADV_FREE).
top confirms that the server's resident memory can drop below its peak
resident memory when no swapping takes place. The jemalloc statistics
show the number of madvise() calls.

Linux appears to have gained MADV_FREE since 4.5, but I'm not sure if
the standard library allocator uses it.

>> object_free2() adds freed objects to a free list that is reclaimed at
>> the end of each server tick. It cannot immediately free object memory,
>> because some callers expect to be able to query it for FLAG_FREED to
>> detect object removal.
> 
>  querying for flag freed was always a bit buggy (it sort of relies that
> the given object won't get re-used, which works because the program is
> singled threaded and these freed objects will be last to be allocated
> when new objects are needed again).
> 
>  Also, as noted above, since memory is not returned to the OS, only the
> allocator, having crossfire itself keep a freelist makes perfect sense -
> it is going to need those objects again at some point, and objects are
> the main use of dynamic memory.   If the program did something like was
> in one state where it needed a bunch of malloc'd items, and did
> something with them, no longer needed them, but then needed a large
> amount of memory for a different object type, freeing them would make
> sense, because in that second allocation, it could re-use that freed up
> space.

I suppose this boils down to how much slower calloc() is compared to
grabbing from the internal freelist, and whether free() returns memory
on enough supported operating systems or not.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Proposal: retire MAX_OBJECTS and object allocator

[Kevin Zheng]

Hi there,

After experiencing MAX_OBJECTS-related excessive swapping on Invidious
that allowed Saromok's souped-up goblins to poison and kill my
character, I've decided to take another look at memory management.

I may be missing some historical context for why things are the way they
currently are in Crossfire, so I welcome feedback on what these proposed
changes might do or not do.

The rationale for each change is included in each patch, but reproduced
here for convenience:


Subject: [PATCH 1/2] Retire MAX_OBJECTS

MAX_OBJECTS has probably outlived its usefulness. It was previously "no
hard limit," only serving to trigger map swapping immediately after
loading a map, if the number of used objects exceeded MAX_OBJECTS.

At worse case, MAX_OBJECTS causes an O(n^2) search and O(n) swaps, where
n is the number of maps in memory. This happens immediately after
loading a very large map. The server takes O(n) to search for the map
with the smallest remaining timeout and swaps it, and does this n times
or until enough memory is freed. If the other maps are small, this does
not free much memory and causes the "performance hit" mentioned in the
comments. This was observed on Invidious, where the server experienced
delays of up to 700 ms immediately after loading a large map due to
excessive swapping.

Removing MAX_OBJECTS does not significantly change the server's
allocation pattern because the server never frees memory (it maintains
an internal free list) and because maps are swapped out based on timeout
at the end of each tick anyway.


Subject: [PATCH 2/2] Retire object allocator

The object allocator allocates OBJ_EXPAND objects at a time and manages
its own free list. It is faster at allocating many objects at once, but
defeats memory debuggers and mitigation techniques. It also does not
return unused memory to the operating system.

Rewrite object_new() to always allocate memory using calloc(). This will
incur some memory overhead since an object struct does not fit perfectly
into a nice allocator slab size.

object_free2() adds freed objects to a free list that is reclaimed at
the end of each server tick. It cannot immediately free object memory,
because some callers expect to be able to query it for FLAG_FREED to
detect object removal.


These changes were tested locally (mostly by running a character around)
with 1) clang -fsanitize=address, which did not report any errors, and
2) with Jemalloc statistics enabled (see attached, jemalloc.out).

As expected, after the change, the allocator bin seeing the most
activity was 768 bytes (struct object is 656 bytes on x86-64).

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
From fe2480277fa6e78db591fac3787a5779cb4a01f4 Mon Sep 17 00:00:00 2001
From: Kevin Zheng 
Date: Mon, 9 Mar 2020 09:54:01 -0700
Subject: [PATCH 1/2] Retire MAX_OBJECTS

MAX_OBJECTS has probably outlived its usefulness. It was previously "no
hard limit," only serving to trigger map swapping immediately after
loading a map, if the number of used objects exceeded MAX_OBJECTS.

At worse case, MAX_OBJECTS causes an O(n^2) search and O(n) swaps, where
n is the number of maps in memory. This happens immediately after
loading a very large map. The server takes O(n) to search for the map
with the smallest remaining timeout and swaps it, and does this n times
or until enough memory is freed. If the other maps are small, this does
not free much memory and causes the "performance hit" mentioned in the
comments. This was observed on Invidious, where the server experienced
delays of up to 700 ms immediately after loading a large map due to
excessive swapping.

Removing MAX_OBJECTS does not significantly change the server's
allocation pattern because the server never frees memory (it maintains
an internal free list) and because maps are swapped out based on timeout
at the end of each tick anyway.
---
 include/config.h | 41 -
 include/sproto.h |  1 -
 server/c_misc.c  |  3 +--
 server/monster.c |  2 +-
 server/server.c  |  1 -
 server/swap.c| 53 
 6 files changed, 2 insertions(+), 99 deletions(-)

diff --git a/include/config.h b/include/config.h
index 4eb2ef92..7752c22a 100644
--- a/include/config.h
+++ b/include/config.h
@@ -336,8 +336,6 @@
  * DMFILE - file with dm/wizard access lists
  * LOGFILE - where to log if using -daemon option
  * MAP_ - various map timeout and swapping parameters
- * MAX_OBJECTS - how many objects to keep in memory.
- * MAX_OBJECTS_LWM - only swap maps out if below that value
  * MOTD - message of the day - printed each time someone joins the game
  * PERM_FILE - limit play times
  * SHUTDOWN - used when shutting down the server
@@ -427,45 +425,6 @@
 /** Default time to reset. */
 #define MAP_DEFAULTRESET   7200
 
-/**
- * MAX_OBJECTS is no hard limit.  If this limit is exceeded, Crossfire
- * will l

Re: [crossfire] Proposal to move server/lib/ files to arch/

[Kevin Zheng]

Thanks to those who chimed in with feedback.

Committed in r21127 and r21128.

This changes how release tarballs need to be generated. Specifically,
when creating the source release tarball, there needs to be a
server/lib/arch directory containing those moved files.

I realize that `make dist` has been broken for some time. Once I manage
to fix `make dist` this manual step should not be needed.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Proposal to move server/lib/ files to arch/

[Kevin Zheng]

Hi there,

I'm proposing to move these non-generated files in server/lib to arch:

artifacts
attackmess
formulae
image_info
materials
messages
races

Logically, the information here belongs with archs, since if the archs
change these should change too. Moving them to arch, where they belong,
should also discourage server tree divergence with those who are running
custom maps/archs, so that it is easier to run with the same server.

These will still only be installed along with the server build, but the
server build already requires a symlink to the arch directory.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Trouble building Windows client

[Kevin Zheng]

On 1/21/20 9:06 PM, Nathaniel Kipps wrote:
> On a side note, has anyone devised any clever ways to do benchmark
> tests of the client's rendering speed, or full end-to-end latency
> testing of client-to-server communication? I think such was once
> talked about on IRC, but it was some months ago.

Nothing clever, but there is now:

--profile-latency Log command acknowledgement latency to stdout
--profile-redraw  Print map redraw times to stdout

This was used to measure the major server latency improvement committed
not too long ago.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Trouble building Windows client

[Kevin Zheng]

On 1/21/20 5:09 PM, Nathaniel Kipps wrote:
> On Tue, Jan 21, 2020 at 7:21 PM Kevin Zheng  wrote:
>>
>> That's interesting. That means there's definitely a bug somewhere. In
>> the meantime, we can work around by providing a debug build!
>>
> 
> Are there any "partial debug" options I should try (since I notice a
> little stuttering with the main debug build)?

Build "RelWithDebInfo" in CMake. Make sure to make clean.

> Any guidance on how it should be packaged for an "impromptu" release?
> I suppose a zipfile is much easier to build than a full installer
> package.

A zip file with the binary and the runtime files is fine, like the
previous release.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Trouble building Windows client

[Kevin Zheng]

On 1/16/20 8:39 PM, Nathaniel Kipps wrote:
> In a bizarre twist, a debug build makes the issue vanish. I simply
> cannot reproduce it once the CMAKE build type is set to "Debug". For
> the adventurous, a copy of the debug build can be found here:
> https://drive.google.com/file/d/1QobJhgkMLkBtq4uYhU8G72B2PEbWxYRR/

That's interesting. That means there's definitely a bug somewhere. In
the meantime, we can work around by providing a debug build!

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Trouble building Windows client

[Kevin Zheng]

On 1/6/20 3:40 PM, Nathaniel Kipps wrote:
> I find it most interesting that the issue only manifests once I remove
> the binaries from the build environment, and execute them elsewhere.
> This indicates to me that I'm missing something simple, and that it's
> not just a regular bug.

That is an interesting observation that I didn't realize before.

>> try re-building with debugging symbols
> 
> Some quick googling shows that this may be as simple as setting
> "CMAKE_BUILD_TYPE" to equal "Debug". Shouldn't be to hard to try.

That should be right.

>> getting a backtrace from the crash
> 
> Since the client doesn't actually crash, just behaves anomalously, is
> there an alternate way to get a backtrace? Perhaps some function in
> windbg that may help?

This, I don't know. What compiler did you use? If you used MinGW's gcc,
then gdb should be available as well.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Trouble building Windows client

[Kevin Zheng]

Hi Nathaniel,

On 1/6/20 3:47 AM, Nathaniel Kipps wrote:
> When the built client is run in it's own development environment,
> everything is fine. But, when I pull the binaries, DLLs, and
> supporting files out into another environment, such as a test machine,
> the Preferences window no longer opens. There's no error, or message
> in the console, no indication of problems, just that the dialog does
> not actually appear.
> 
> If anyone has any input, that would be much appreciated. Also, if
> anyone wants to try it for themselves, feel free to grab a rolled up
> package here: 
> https://drive.google.com/open?id=14ej1Hw37mxABcd60ZD7ULL5AKNmelTU_

Rick has reported a similar issue, and I remember experiencing it before
as well. There's no doubt there's a real issue somewhere.

Unfortunately, it will be some time before I get around to getting my
Windows build set up again. In the meantime, could you try re-building
with debugging symbols and getting a backtrace from the crash?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu
XMPP: kev...@eecs.berkeley.edu
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Questions about archetype files

[Kevin Zheng]

Yes. Here, there are nested objects. Every "Object" has a matching
"end", and so the first example is an "Altar of Valkyrie" containing a
Python "pray_event" that gets triggered when a player prays.

Hope that helps,
Kevin

On 4/8/19 9:19 AM, Bob Tanner wrote:
> Working on a project and I’m parsing the .arc files for crossfire and I
> finding some files with entries I cannot understand. 
> 
> I’d like to know if there’s a reason for these entries or if I need to
> change the code that is parsing the entries to handle these side cases.
> 
> Couple examples.
> 
> gods/altars/altarvalk.arc
> 
> Object altar_valkyrie
> name Altar of Valkyrie
> other_arch Valkyrie
> type 56
> face altarvalk.111
> no_pick 1
> level 100
> arch altar_valkyrie_pray_event
> end
> end
> Object altar_valkyrie_pray_event
> title Python
> slaying /python/gods/altar_valkyrie.py
> type 116
> subtype 1
> end
> 
> Is the double “end” necessary? Bug? Typo?
> 
> Another example
> 
> ground/temp_summon_fog.arc
> 
> Object temp_summon_fog
> name fog
> face fog.111
> animation temp_fog
> type 67
> move_type fly_low
> no_pick 1
> is_used_up 1
> resist_fire 100
> resist_electricity 100
> resist_confusion 100
> resist_acid 100
> resist_drain 100
> resist_weaponmagic 100
> resist_ghosthit 100
> resist_poison 100
> resist_slow 100
> resist_paralyze 100
> resist_turn_undead 100
> resist_fear 100
> resist_cancellation 100
> resist_deplete 100
> resist_death 100
> material 1
> changing 1
> blocksview 1
> weight 10
> value 1
> speed 0.5
> arch event_destroy
> name GenerateFog
> title Python
> slaying /python/Moving_Fog.py
> end
> end
> 
> The double ends seems to happen with the “title Python”.
> 
> Any help would be appreciated.
> ---
> Bob Tanner mailto:tan...@real-time.com>>        
>   | Phone : 952-943-8700
> http://www.real-time.com, Linux, macOS      | Fax   : 952-943-8500
> Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378
> 
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> 


-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Improving IRC availability with a chat bridge

[Kevin Zheng]

On 1/31/19 9:47 PM, Mark Wedel wrote:
  I should probably transfer ownership of crossfire to someone else - I 
haven't had much time to work on it lately, and seems unlikely that I'll 
find time anytime soon.  But that wasn't really the question here.


I nominate Rick, who has been a pretty essential part of the project for 
many, many years.


  It is hard to argue about making the game (or chat channels) more 
accessible to more people.  There are a few thoughts here:


- Move chat to another system that is more widely used/available, with 
the understanding that it still needs to be accessible to linux users.  
So if there is a web interface, probably acceptable.  If the only thing 
is a windows program, probably not.


I imagine many of us (myself included) who have gotten quite accustomed 
to IRC, and would prefer to keep it.


- Set up a gateway.  As noted, this could have issues related to 
freenode policy.  One thought there is to change the topic to clear 
state that there is a gateway being used.  I'm not actually sure how 
messages would get attributed when moved between the 2 chats - I'd 
imagine there may be a forwarding agent string involved.  And handling 
of private messages would need to be carefully done (if one replies to 
the forwarding agent privately, you probably don't want to that appear 
to all the users on the other chat system)


From my understanding, it seems like Freenode would permit bridges so 
long that it's clear that users are clearly and prominently notified 
that the bridge exists; I have participated in other channels on 
Freenode that very clearly state that they log chats publicly, for example.


--
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] GTKv2 Client 1.73.0 release

[Kevin Zheng]

Hi folks,

Crossfire Client GTKv2 1.73.0 is now available for download from 
SourceForge. Most notably, there is no separate distfile for sounds; 
sounds are installed by default if SOUND is enabled.


A Windows build is not available at this time.

**Added**

- Pass player and server name to client scripts

**Changed**

- Add text for blessed items in inventory views
- Client window stays hidden until after player selection
- Install sound files when SOUND is enabled
- Show open containers in unlocked inventory view

**Fixed**

- Enable sound with older (< 0.25.3) versions of Vala
- Fix delayed weight limit update when strength attribute changes

Regards,
Kevin

--
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Plan for GTK Client 1.73.0 release

[Kevin Zheng]

Hi folks,

I'm planning on tagging and releasing version 1.73.0 of the GTK Client 
in a couple of days. There aren't many changes, but enough to give 
package maintainers a new version:


**Added**

- Pass player and server name to client scripts

**Changed**

- Add text for blessed items in inventory views
- Client window stays hidden until after player selection
- Install sound files when SOUND is enabled
- Show open containers in unlocked inventory view

**Fixed**

- Enable sound with older (< 0.25.3) versions of Vala
- Fix delayed weight limit update when strength attribute changes

If you use the GTK Client, please give current trunk (which will become 
the 1.73.0 tag) a whirl to catch issues before the release.


Regards,
Kevin

--
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[20646] server/trunk/server/player.c

[Kevin Zheng]

Sorry, my fault. On this note, the C99 "//" comments, inline, atoll(), 
and probably other stuff need to be changed to be strictly ANSI C.


On this note, can we have a temperature check on requiring C99? C99 is 
more convenient to use in places, especially where it improves 
readability and typechecking inline functions vs macros.


It's also not that much work to get this back in strict ANSI C.

If I remember correctly, it was the MSVC C compiler that needed C89 last 
time this issue came up. Has the situation on Windows changed?


On 1/4/19 1:42 PM, Nicolas Weeger wrote:

Hello.


That change will break strict ANSI C conformance, as you can't declare
variables except at the start of a block. Here "turn" is declared only when
assigned.


I'm fine with that change, of course, but then we should clearly state that
ANSI C is no longer relevant :)



Best regards


Nicolas


Le samedi 29 décembre 2018 05:42:49, Crossfire CVS repository messages. via
Crossfire-cvs a écrit :

Revision: 20646
   http://sourceforge.net/p/crossfire/code/20646
Author:   partmedia
Date: 2018-12-29 04:42:48 + (Sat, 29 Dec 2018)
Log Message:
---
Clean up

Modified Paths:
--
 server/trunk/server/player.c

Modified: server/trunk/server/player.c
===
--- server/trunk/server/player.c2018-12-29 04:42:41 UTC (rev 20645)
+++ server/trunk/server/player.c2018-12-29 04:42:48 UTC (rev 20646)
@@ -3007,7 +3007,8 @@
  }

  /**
- * Player gave us a direction, check whether to move or fire.
+ * Move player in the given direction. Can be called by a client through a
+ * movement command, or by the server for some other reasons.
   *
   * @param op
   * player.
@@ -3017,8 +3018,7 @@
   * 0.
   */
  int move_player(object *op, int dir) {
-int pick;
-object *transport = op->contr->transport;
+object *transport = op->contr->transport; //< Transport player is in

  if (!transport && (op->map == NULL || op->map->in_memory !=
MAP_IN_MEMORY)) return 0;
@@ -3029,7 +3029,6 @@
  return 0;
  }

-/* peterm:  added following line */
  if (QUERY_FLAG(op, FLAG_CONFUSED) && dir)
  dir = get_randomized_dir(dir);

@@ -3036,8 +3035,6 @@
  op->facing = dir;

  if (transport) {
-int turn;
-
  /* transport->contr is set up for the person in charge of the
boat. * if that isn't this person, he can't steer it, etc
   */
@@ -3044,7 +3041,7 @@
  if (transport->contr != op->contr)
  return 0;

-/* Transport can't move.  But update dir so it at least
+/* Transport is out of movement.  But update dir so it at least
   * will point in the same direction if player is running.
   */
  if (transport->speed_left < 0.0) {
@@ -3057,7 +3054,7 @@
  if (op->speed_left < 0.0)
  op->speed_left = -0.01;

-turn = turn_transport(transport, op, dir);
+int turn = turn_transport(transport, op, dir);
  if (turn != 0)
  return 0;
  } else {
@@ -3076,7 +3073,7 @@
  } else
  move_player_attack(op, dir);

-pick = check_pick(op);
+int pick = check_pick(op);


  /* Add special check for newcs players and fire on - this way, the

This was sent by the SourceForge.net collaborative development platform,
the world's largest Open Source development site.



___
Crossfire-cvs mailing list
crossfire-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crossfire-cvs

___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire



--
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] encrypting the connection

[Kevin Zheng]

On 10/21/2017 12:10, Mark Wedel wrote:
> On 10/20/2017 05:22 PM, Preston Crow wrote:
>> Would it make sense to encrypt the connection between the client and
>> the server?  I'm particularly concerned about the sending of passwords
>> in plaintext, as they're probably the same as other user passwords in
>> most cases.
>>
>> It would be fairly simple to wrap the server side with stunnel, but
>> without built-in client support, this wouldn't do any good.
>>
>> I've never used openssl or similar libraries, but that would seem like
>> the right approach.  I doubt that the added overhead would cause
>> latency or cpu load issues.
> 
>  One issues is that most servers are unlikely to get official SSL
> certificates, thus having self signed ones, so while encrypted, you'd
> still have the problem on a 'non verified' connections.
> 
>  Also, the way crossfire buffers and sends data may not be ideal (it
> basically writes the data to the OS as it is generated, and lets the OS
> combine the data into larger packets).  That may not be ideal for
> encryption or compression.  And since non encrypted connections have to
> be maintained for clients that don't support it, the number of encrypted
> connections may not be that high for quite a while.

It's certainly possible to wrap things in STARTTLS. An implementation
for the client and server that can be disabled at compile time would
certainly be welcome.

>  As you note, the real issue is with the password. I can't think of much
> else in the connection anyone would really care about.
> 
>  And one issue with the password is that it is stored on the server,
> plaintext IIRC.  So if the server is compromised, someone could grab the
> password and if able to associate with the real person (probably due to
> server logs) could try to use it elsewhere.

Currently the passwords are hashed with crypt() on Linux and in
plaintext on BSD and Windows (due to a legacy #ifdef). There are
eventual plans to get them hashed with scrypt() or bcrypt() on all
platforms with a path for migration.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Spellcasting skills definition

[Kevin Zheng]

On 09/14/2017 06:03, David Hurst wrote:
> To try and make some progress on this front I created a visualisation to
> see what these changes might look like. Take a look here
> <https://public.tableau.com/profile/david.hurst6129#!/vizhome/CrossfireSpellsVisualisation/Spellassignmentdashboard?publish=yes>.
> I focused on only the spells that can provide exp, I can load the other
> skills if there is a strong desire to see the impact. As mentioned I
> don't think there is a particularly significant effect by using
> consistent spell schools definitions but i'm open to your feedback.
> The data i'm using is available here
> <https://docs.google.com/spreadsheets/d/1OIq3cIOpQoU9EZLkq8njLqY9GXqsVJ4TkYzUe_5IpKg/edit?usp=sharing>.
> 
> As a reminder the proposed schools are:
> Evocation - Spells that create things (physical damage, food, strengthening)
> Sorcery - Spells that remove energy (cold spells, poison, draining?,
> depletion?)
> Pyromancy - Spells that add energy (fire, lightning, light)
> Summoning - Spells that call and control monsters (golems, pets, etc)
> Praying - Spells gifted by channeling your gods wishes through prayer

I believe this discussion came up on IRC, but how do you see training
experience in the new spell organization to work?

The current classifications are a bit arbitrary but it seems that each
spell school has a good balance of spells.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire Client 1.72.0 is available

[Kevin Zheng]

On 08/19/2017 04:59, Preston Crow wrote:
> What would be really cool is a command-line option to start a client
> script, especially if it could be used multiple times for multiple
> scripts.  (I normally launch two.)

Maybe like a login.rc file that gets read as soon as the character
enters the game?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire Client 1.72.0 is available

[Kevin Zheng]

On 08/18/2017 20:28, Preston Crow wrote:
> The "cleanup" of command line options seems to have removed almost all
> of them, including many useful ones.  There isn't even an option for
> selecting the server anymore!  I really need the mapscale and iconscale
> options for high DPI displays--those have also been removed from the UI
> settings.

Sorry about that; I'll work on adding them back.

In the meantime, edit ~/.config/crossfire/client.ini

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire Client 1.72.0 is available

[Kevin Zheng]

The 1.72.0 client build for Windows is now available on SourceForge:

https://sourceforge.net/projects/crossfire/files/crossfire-client/1.72.0/

Some network issues were fixed between the latest snapshot and the
1.72.0 client, so you should upgrade when convenient.

Hash: SHA256

SHA256 (crossfire-client-1.72.0.tar.bz2) =
2e863f09be0d5480708e031afb212361f58f6827a68120ffef075b94406d73a5
SHA256 (crossfire-sounds-1.72.0.tar.bz2) =
b41fbac33cbffb6850bbe497ac4d1bcbf5e514073e288f4b00af0c10e99c1d62
SHA256 (crossfire-client-1.72.0-winx86_64.zip) =
cd3ef354d5222598e94b82cfefa0cb4fffd8557fc825ca5250f59df053743365

Precompiled pixmaps will not be provided for this release.

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090



signature.asc
Description: OpenPGP digital signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire Client 1.72.0 is available

[Kevin Zheng]

On 08/14/2017 08:16, Matthew Giassa wrote:
> ‎Seconded. Why overhaul the build tool chain in use? What gain is there?

The original reasons were better support for parallel builds, out of
source builds, and Windows builds. Yes, Autotools technically supports
all of these features. But the CMake build files are a lot shorter than
the Autotools ones.

At one point we had both build systems co-existing, but Autotools
started lagging and breaking. Since nobody was willing to maintain it it
got axed. We're happy to resurrect it if you step up as maintainer.

If you have strong opinions you should have voiced them in May 2014 when
CMake supported landed.

If you don't even play I don't see how this impacts you. If you play,
but use a package from your OS, I don't see how this impacts you. If you
really want to use autotools you can keep using an older version of the
client, so I don't see how this impacts you.

Cheers,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Crossfire Client 1.72.0 is available

[Kevin Zheng]

Hi there,

Crossfire Client 1.72.0 is available for download on SourceForge:

https://sourceforge.net/projects/crossfire/files/crossfire-client/1.72.0/

Be sure to try out the improved sounds, available for download in a
separate tarball.

**Added**

- Display numerical stats on HP, mana, grace, and experience bars
- Fade music in and out
- Highlight applied items in the inventory icon view
- Speed up Pixmap rendering using Cairo
- Update metaservers

**Changed**

- Clean up command-line arguments
- Enable smoothing by default
- Move music directory to *share/crossfire-client/sounds/music/*
- Reduce default logging verbosity. Run with '-v 0' to show all messages.
- Replace autoconf/automake build system with CMake
- Save client settings in .ini format
- Set default layout to *gtk-v2*
- Update UI dialogs
- Update sound effects
- Use XDG-compliant directories for configuration and cache files. Users
who wish to keep their configuration files need to manually move them to
the new location. For Unix-like systems, the new location is
*~/.config/crossfire*.

**Removed**

- Remove old metaserver (metaserver1) support

**Fixed**

- Fix potential socket buffer overflows
- Fix various protocol-related bugs
- Hide character selection window reliably after logging in
- Update build for Windows

Regards,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090



signature.asc
Description: OpenPGP digital signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Ideas for balancing tweaks for next release

[Kevin Zheng]

On 07/30/2017 14:08, Preston Crow wrote:
> I like your thinking on this.  You have a place for monsters, but didn't
> put any on the list.  I've been playing on Metalforge recently, and I've
> found pixies to be worthless monsters.  They seem to usually have wands
> but never use them.  I seem to recall they used their wands at one point
> in the past, making them randomly dangerous.

Glad these ideas are being discussed.

I do want to point out that I'd like to hold off major changes until
this release gets out the door. We're still shaking out some last issues
and I really don't want to delay this any more than it already is.

I'm shooting for getting this out the door on or before the weekend of
August 12th. Releasing isn't that hard but it takes a couple of hours to
sit down and get everything done. We should really work on automating
this going forward.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Kevin Zheng]

On 06/23/2017 05:37, Rick Tanner wrote:
> Would/could/will the planned release include an .exe version of the GTK
> client for Windows?

It's been a while since I've tried to build the GTK client on Windows,
but I'll remember to give it a shot.

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Release proposal

[Kevin Zheng]

On 06/22/2017 22:30, Robert Brockway wrote:
> About 18 months ago I sparked a discussion about an expanded Crossfire
> world I was developing.  Well I went away and did that but wasn't
> willing to host it on a VPS (Linode, Digital Ocean) as the size of the
> world made this quite expensive.  So I decided to wait until until my
> home was connected to the Australian National Broadband Network (NBN). 
> Well that's happening on June 29.  So, sometime in the next few weeks
> I'll launch the expanded world running on my NBN link.  I'll update my
> expanded world with the new release before going live with it.
> 
> The expanded world is 1000x1000 maps with the 'old world' (original
> world maps) positioned dead centre at 485-514 on each axis.
> 
> As much as possible I've been automating the world building.  I hope it
> offers different game play to keep people interested.

I think this could offer something to players who want to try something
new. Is the new world compatible with the standard server and client?

I remember some complaints from the Galactic Mileau folks that it was
hard to get recent versions of the client/server running a custom world.
Are there changes that would make this easier for you?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Release proposal

[Kevin Zheng]

Hi there,

It has now been 3 years since the last release. Since then we've
accumulated a decent amount of fixes and improvements.

To make it easier on packagers, and so that more people might benefit
from these changes, I propose getting the ball rolling on cutting a new
release.

If there are no objections I'll get the ball rolling on this next week.

Thanks,
Kevin

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090



signature.asc
Description: OpenPGP digital signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] compiling sour ce

[Kevin Zheng]

On 10/17/2016 20:26, Ruben Safir wrote:
> CMake Error at CMakeLists.txt:43 (install):
>   install TARGETS given no RUNTIME DESTINATION for executable target
>   "crossfire-client-gtk2".
> 
> 
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> 
> cmake_minimum_required(VERSION 3.6)
> 
>   should be added at the top of the file.  The version specified may be
> lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Configuring incomplete, errors occurred!
> See also
> "/home/ruben/src/crossfire/client/trunk/gtk-v2/src/build/CMakeFiles/CMakeOutput.log".

Could you provide more context? Perhaps OS/arch and CMakeOutput.log?

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] A funny thing happened on the way to the new maps

[Kevin Zheng]

On 04/01/2016 19:20, Robert Brockway wrote:
> Anyway I've been having fun building a new world over the last few
> months. I modified the 'land' utility a little and have played a lot
> with different land forms.  My modified version is called 'bigland' and
> allows for the creation of quite large land forms.  I've written a
> script which calls bigland and records the parameters used in a file so
> they can be reproduced later.
> 
> I've created a new world running on my server which is 1000x1000 maps. 
> I started small but gradually made bigger and bigger land forms.  There
> are reasons I went and built a world this big that I can go in to later.

Sounds interesting. Any chance your server is online so I can take a
look at your new maps? I'd love to hear more about your 'interesting'
game dynamics with a big world (and lots of mice).

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Qt experiments

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/25/2015 04:43, Nicolas Weeger wrote:
 I'm experimenting with Qt (core only, no graphical stuff for now)
 for the server, and would like to share that.

Sounds interesting. Anything to remove Winsock and #ifdef WIN32!

 I can either work on a specific branch in SVN, or in trunk, as
 people want.

For the time being, I'd prefer a separate branch.

 And yes, if things don't work too badly, I fully intend to submit
 that as a patch for use in regular trunk.

I'm excited to expunge Winsock.

Best,
Kevin Zheng

- -- 
Kevin Zheng
kevinz5...@gmail.com | kev...@kd0lgh.mooo.com | PGP: 0xC22E1090
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVYyTcAAoJEOrPD3bCLhCQTBAH/3/A6OrQLZU7XGp+Xl3QBkbQ
WZylAptyTM9hRMbC6xCEZTZLcbGkHuW+pvJtZjO1b0sxUW/fsJznMEqfplH6ZwKV
/ZWCGEZH/YRuF4fkiFNeu6Zg96DwJSjAT/GkX4RdoeLD7aqoerkvYtFW1Y85Kt4N
J5YAE+bGTDDT1HUuww+Djz73QMMFVQ43ku+0rQB3nuiqWKLfrvDLSPqObvyjhhWR
O2f7tgVy28ojvw8B1CwvW6O8PMxrtGxymfYJaYq58Lq47qlIcWIFUcbkdt+aVFTA
/QxCtfMMfos0fGNlrtDTSXvSeq7G3nVCtjotDbyPTbc2nXiawrwRg88Zos/weZk=
=fFfY
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Version bump request?

[Kevin Zheng]

On 12/27/14 18:38, DraugTheWhopper wrote:
 Now that some more time has passed with (I assume) more mainline
 changes, is there a chance of cutting a new release again? Wouldn't hurt
 to have a Windoze release this time too, since it looks the last one may
 have been at 1.60.

The latest release is 1.71.0, available from SourceForge. For some
reason the JXClient is stuck at 1.60, I'm not sure why.

We haven't been keeping up with Windows builds for various reasons.
Windows support in the GTKv2 client has greatly improved since the last
build. You can find some experimental client binaries here:

http://partmedia.users.sourceforge.net/

They're not official because they're missing important pieces; in this
particular client build it's because metaserver support is missing.

 More thoughts: What is the current dominant client? I heard someone say
 once that GTKV2client had fallen by the wayside in favor of JXClient,
 but I hope that's not the case, as I much prefer the cfclient layout,
 etc. Has any thought been given to using GTK vs QT? Are there any
 thoughts on portability to Wayland/Weston?

Both are well-supported. We generally point Windows users to the
JXClient, but soon this will change.

Best,
Kevin Zheng

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@kd0lgh.mooo.com | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Shop prices overhaul

[Kevin Zheng]

On 12/02/2014 01:48, Mark Wedel wrote:
  If you are going to reduce the importance of bargaining, is there any
 reason to just not remove it all together then?  The passive skills were
 always a little odd (passive skills being those that the player just
 automatically uses without any effort, and likewise, can't really focus
 much on improving them).

My intent is to keep bargaining around but re-implement it as
interactive haggling. That way, it's no longer a passive skill.

  I'm not quite sure how interactive haggling will work out - it will
 seem like someone would pretty quickly figure out how it works, write a
 plugin to the client to just do the work and get maximum value, at which
 point, one asks why not just skip all those steps and just give the
 player the best price to start with.

Getting the details worked out will be difficult, but I don't think
having it abused by a few players will prevent it from being useful to
others. Randomizing well and making things probabilistic may help.

  One thing to be absolute sure to check is that it is never possible for
 a character to sell something for more than they can buy it (eg, buy for
 100, sell for 101), because that clearly breaks the game.  In fact, even
 doing it equal would probably break the game.

I'll be careful to make sure this doesn't happen. At the moment, there
are additional calculations made after the charisma/bargaining
adjustment; the 0.5 ratio here is further decreased later on.

  I'd personally rather that instad of shop_buy_multiplier() having a
 hardcoded formula that is used, that is instead stored in the stat_bonus
 file, and if not set there, perhaps fill in the array based on that
 formula.

The issue with using the file is that existing servers will not reflect
the changes without admin intervention. And, it seems that anyone who is
willing to modify the file might as well change the function.

This approach doesn't seem to be new; plenty of calculations are
delegated to Python scripts in the maps. If an admin is willing to
customize the bonuses, changing a function doesn't seem difficult.

  I'm not sure how many people actually use the stat_bonus file, but all
 the code is there so it is a pretty simple matter to just keep using it
 - at also lets player admins adjust things more easily (with the formula
 as is, it is pretty much impossible to adjust things - at least with the
 old compiled in arrays, one could change those to get different behavior)

Same thing here: the calculation is split off into a function of its
own, and with documentation should be straightforward to edit. Playing
with different formulas may seem cumbersome, but it seems that being
able to manipulate the formula directly is more useful. Having numbers
without a formula makes analysis and future changes more difficult, and
of course may just be a premature optimization.

That said, using the stat_bonus is straightforward as well; I simply
need to evaluate the function out and stick it in a file. Server admins
will need to merge changes in manually.

Thoughts?
Kevin Zheng

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@kd0lgh.mooo.com | PGP: 0xC22E1090
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Shop prices overhaul

[Kevin Zheng]

Hi all,

At the moment, Crossfire's shops aren't particularly useful. For
medium-level players, prices seem unreasonable, while new players can't
afford to buy from shops at all. Old players with high charisma and
bargaining, on the other hand, don't notice a huge discrepancy.

The attached patch attempts to fix some of these issues:

Charisma and bargaining now only affect the shop buy price, with
multipliers ranging from 2x for new players to 0.5x for very advanced
players. This is consistent with rogue-style shopkeeper greed but still
better than the existing situation. Bargaining is now significantly less
useful; the hope is that in the near future it is replaced with
interactive haggling.

The sell price is clamped down to 0.5x base price, subject to additional
shop specialization and greed. This sell price is mostly better than the
existing prices, and at the very least prevents high level players from
buying and selling for a profit.

Comments, questions, clarifications, or hate mail?

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kevinz5...@gmail.com | kev...@kd0lgh.mooo.com | PGP: 0xC22E1090
From 57871a24be5dd89f0c3778fd01472f4bae1523c2 Mon Sep 17 00:00:00 2001
From: Kevin Zheng kevinz5...@gmail.com
Date: Fri, 28 Nov 2014 18:57:03 -0600
Subject: [PATCH 1/6] Overhaul shop prices

Adjust charisma and bargaining price multipliers and apply them only to
buy prices, capped at 50% base value. Fix sell multiplier at 50% base
value, subject to additional shop specialization and greed.
---
 server/shop.c | 122 --
 1 file changed, 68 insertions(+), 54 deletions(-)

diff --git a/server/shop.c b/server/shop.c
index b817bc4..776b248 100644
--- a/server/shop.c
+++ b/server/shop.c
@@ -75,17 +75,17 @@ static const char *const coins[] = {
  * @param flag
  * @return
  */
-uint64_t price_base(const object *tmp, const int flag) {
+static uint64_t price_base(const object *tmp, const int flag) {
 const char *key;// Temporary place to hold key values
 
 // When there are zero objects, there is really one.
 int number = (tmp-nrof == 0) ? 1 : tmp-nrof;
 uint64_t val = (uint64_t)tmp-value * number;
 
-bool is_ident = (flag  BS_IDENTIFIED) || QUERY_FLAG(tmp, FLAG_IDENTIFIED)
-|| !need_identify(tmp);
-bool is_cursed = !(flag  BS_NOT_CURSED)  (QUERY_FLAG(tmp, FLAG_CURSED)
-|| QUERY_FLAG(tmp, FLAG_DAMNED));
+const bool is_ident = (flag  BS_IDENTIFIED)
+|| QUERY_FLAG(tmp, FLAG_IDENTIFIED) || !need_identify(tmp);
+const bool is_cursed = !(flag  BS_NOT_CURSED)
+ (QUERY_FLAG(tmp, FLAG_CURSED) || QUERY_FLAG(tmp, FLAG_DAMNED));
 
 // Objects with price adjustments skip the rest of the calculations.
 if ((key = object_get_value(tmp, price_adjustment)) != NULL) {
@@ -162,6 +162,33 @@ uint64_t price_base(const object *tmp, const int flag) {
 }
 
 /**
+ * Calculate the buy price multiplier based on a player's charisma.
+ * @param charisma Player's charisma
+ * @return Buy multiplier between 2 and 0.5
+ */
+static float shop_buy_multiplier(int charisma) {
+float multiplier = 1 / (0.38 * pow(1.06, charisma));
+
+if (multiplier  2) {
+return 2;
+} else if (multiplier  0.5) {
+return 0.5;
+} else {
+return multiplier;
+}
+}
+
+/**
+ * Calculate the buy price multiplier based on a player's bargaining skill.
+ * The reciprocal of this result can be used as a sell multiplier.
+ * @param lev_bargain Player's bargaining level
+ * @return Buy multiplier between 1 and 0.5
+ */
+static float shop_bargain_multiplier(int lev_bargain) {
+return 1 - 0.5 * lev_bargain / settings.max_level;
+}
+
+/**
  * Adjust the value of an item based on the player's bargaining skill and
  * charisma. This should only be used if the player is in a shop.
  * @param val Base item value
@@ -170,52 +197,29 @@ uint64_t price_base(const object *tmp, const int flag) {
  * @param flag Additional flags to use while determining value
  * @return Adjusted value of item
  */
-uint64_t price_adjust(uint64_t val, const object *tmp, object *who, const int flag) {
-float diff;
-int lev_bargain = 0;
-int lev_identify = 0;
-int idskill1 = 0;
-int idskill2 = 0;
-bool approximate = flag  BS_APPROX;
-bool no_bargain = flag  BS_NO_BARGAIN;
-
-/* ratio determines how much of the price modification
- * will come from the basic stat charisma
- * the rest will come from the level in bargaining skill
- */
-const float ratio = 0.5;
-const typedata *tmptype = get_typedata(tmp-type);
+static uint64_t shop_price_adjust(uint64_t val, const object *tmp, object *who, const int flag) {
+const bool approximate = flag  BS_APPROX;
+const bool no_bargain = flag  BS_NO_BARGAIN;
+int lev_bargain;
+float multiplier;
 
 if (find_skill_by_number(who, SK_BARGAINING)) {
 lev_bargain = find_skill_by_number(who, SK_BARGAINING)-level

Re: [crossfire] [PATCH] Crossfire client linking fails in trunk

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/12/2014 03:12, Tolga Dalman wrote:
 Actually, the current `configure` script already adds
 -std=gnu99 or some variant thereof behind your back. While
 getaddrinfo(3) is a POSIX extension, it is still relatively
 portable. On Windows, this issue is taken care of with a few
 preprocessor definitions.
 
 What configure script ?? I just did
 
 $ mkdir build; cd build; cmake ..; make

The `configure` script from Autotools, not CMake.

 Yes, replacing std=c99 by std=gnu99 defines the necessary POSIX
 extension macros and, thus, fixes all errors.

If the code compiles correctly using -std=gnu99, then use it. While
portability is definitely a desirable, it's probably better done along
with some other massive change (i.e. GIO networking).

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJT68VnAAoJEOrPD3bCLhCQLG4IAKmxxcI6c1X14iG3iGqkn0XB
7nTchsmUiDdM0wyhxxUOAjdw0GG6Hx474yR1nh1wZwQkmiVHYxQbGV7fpVrGnPXx
IouDiTBH2ZSlmfxVZVMrXhwUy3bmcaXTTZHG07jCMduQvsZZFg7pa7mm5gz9qg/3
zFegVmm/sPLLxUNR8ClqFLNEXZB1VXCmgtT8t2rCmoe7qCcnUc7Rq0Gqp0coEVt7
GoHWlsvTsawwcUTSoU5wJzv9gKwmflW0xD0wZ/hEBhxW3lpOfT2OK9fpfMdxyYly
ggYbKL2+6aqqsygg+FwvGYYGdKtCkIFEymXVyCsoZlxH4aKgOQ8Tnz/f1Ald5yo=
=jguB
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Game change proposals

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/05/2014 14:37, Nicolas Weeger wrote:
 Finally had time to make a small POC of a mini-game related to
 lockpicking :)
 
 On the top, your picks. Bottom, the lock components to pick (left
 to right).

It's difficult to tell where each section ends; in the final version
it might be useful to highlight the current segment.

 Aim: use the picks in the correct order to pick the 5 lock
 components.

Sounds reasonable.

 Obvious improvements would be better graphism, and chance of
 breaking a pick if you use the wrong one! And of course removing
 the hints :D

How would breaking a pick be represented in the game? Will there be a
separate item for each pick depicted, or will breaking a pick cause
the single lockpick item to be destroyed/damaged?

 Would thid kind of minigame be fun for CF?

Yes, if used sparingly. I would not want to go through this entire
process when picking every single lock. But, this would make sense
when picking an important lock.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTuZmqAAoJEOrPD3bCLhCQ0sAH/3GdAJhDAtXg/ZZr1SRq9kOk
2TbnSPcdtJcaBEEVUVkwmhgY3YenBoEDUUFJ1lZAo7u+anV8oKvfsLYz89neb/10
sQYJgzMsbYxlPcsCupTpbuN7w5rTrmkpoT+ZiCBxIupRHkwauqAVI55h3pzCFRsh
GajlKLimqpYvleYrIqCNyx9BneP4k/6Q2u3yFeKrOlpH3MgPw1BPx12MWkXCyXA5
imWdfTrCayvCOqwWsWfK80liz2WNxxJgUQ66SQd5/Ga0k1YR5kbqnCtqGq9QniA4
T4YKxY9fa5ASyZUfTgCdMNAM0d4xFvLlosrHpVs2C3ThETPyQdlpGRTi+AmFJns=
=8JEC
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire should use Git

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again,

First, a few responses:

Many of the reasons I mentioned do extend to most DVCSs, and this is
the fault of my own (thinking that Git == DVCS).

I'll concede that Git has a fairly steep learning curve, although I'll
assert that it is harder to use a pneumatic drill than a hammer. I
learned Git after SVN and it was not a big problem for me.

I believe the most compelling reason to use a DVCS is that it makes
contributions easier. About a year ago a common complaint about my
patches were that too many changes were lumped together in one patch,
making it hard to review. While I could have used Git or Hg to make a
local repository, I did not think that was worth the trouble.

Next, an adventure:

I've taken the liberty to install and attempt to learn Mercurial.
Since I am brainwashed by the Git world, please correct me if I'm wrong.

My current workflow involves putting all non-trivial or multi-commit
projects in a separate branch. Then I dangerously reorder, squash,
and otherwise mutilate my local branch until it can be laid on top of
the SVN trunk, where I dump back the linear history.

If I used Hg, this would likely involve making many copies of the
repository (since each branch is an entire checkout) for minor
changes. Since I make extensive use of the Git staging area, I would
wind up using `hg record` (an extension) very often. I would also end
up maintaining patch sets using message queues (another extension), in
order to clean up my changes before committing. In addition, it would
be impossible for me to rebase my commits, which means that every
branch would require its own merge. If you take a look at my commits,
most have been squashed versions of local branch work.

I advocated Git because we should use the VCS that I'm most familiar
with. It works with the workflow that I'm most comfortable with. I
welcome anyone familiar with Hg to reeducate my current workflow. If I
am the only developer that makes use of such a workflow, then I
apologize for being selfish and greedy.

Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have
a good Hg bridge (Git's fault). If I keep my current workflow, then
I'd much rather stick with SVN and play with local Git branches.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTnJS1AAoJEOrPD3bCLhCQvq8H/RvwMBwd3N1F13IXM6URjAiE
TVMQ/eFf3XjKq9048NOd64YTCsCRyBKZt7PUOVlaUnaIRAcblwMyGLWuvwIlQOwZ
CImrQi+66YkeKoFB5GEH9bCLDhHzDNQu2GsZVNTnTF/AUeYpJdiwiOlaJMqpVKyh
lhdzCNJNR2GAe/aT7HdDnlq/Z/CIvngpWQqc++WaLQLmoYvw0gqWWM5yGxiAzo+l
+vR24q0LxSTvtAc1E8mLX15eQx3Z+8Q0/Dbdd0TT78AX1DDMH2teAkumWcuRGDot
IMM6c9DofKvEL2B0I2Y15tH6RFYhzpcexKssP8h5zFAuFMBMbcY2QszvHy63jbY=
=rfsf
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire should use Git

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/13/2014 18:03, Rick Tanner wrote:
 My questions on going with a distributed revision control has to
 do with how does all these changes in a branch make it back to the
 main code base?
 
 Perhaps I'm asking who brings in all the changes from the
 branches to the main code base?

I expect that branch maintenance and integration will remain pretty
much the same. Developers who choose to publish topic branches should
ultimately merge in changes when the code is ready.

Contributors who wish to make changes should make local commits and
generate patch sets. Contributors wishing to make extensive changes
can seek the help of a developer with commit access.

Keep in mind that it is not necessary to work in topic branches; the
current workflow can stay the same. I expect that more people will use
and publish branches, though.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTm4n8AAoJEOrPD3bCLhCQB9YIAL740CWrMriZ2Vi3JokSESxa
CG7qAecR2ELrD61FpDiLY04g2fAZdAMDoxPzeRX4i3mY+uwaWrzdie74/J8ufqB5
6aFyB0YEXHXr07CFFyRJWa09FXuPXgVZxzYU4vFLCkUspBujVdGmUbrsZdLHFxvR
qAxGSNhFVQyKUQvfJBrbu+mitJK2x2b15sigZOticKHfnkEQNCE3UKjBFM314QgQ
ps++0nusn1nQX9MrP5tl/gJV3ScfRZW81Eh6GkAcZPANlsajK4Hlrw88S3t/6l24
Q5oDEJE19XdrCkzwNLPpQhlQ9lvfTi/0/xGB9+jmWAZ9K3kx0UIcxZu3guAPT1A=
=6Axm
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Game change proposals

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/12/2014 13:35, Nicolas Weeger wrote:
 What about mini-games?
 
 For instance, instead of a mere lockpicking, you actually have to
 use the picks in the right order in a limited time to pick a lock -
 if you fail, you trigger the traps, of course.
 
 [bonus points to who knows the old game I'm getting inspiration
 from :)]

I like mini-games, and if there were more mini-games I would play
Crossfire a whole lot more. My schedule no longer allows me to sit
down for 4 hours straight hacking through a dungeon.

I think short pickup multiplayer mini-games would be best. A handful
of single-player games would be good, too.

 What about changing alchemy (including the jeweler etc. variants)?
 
 For each formulae you start with a ~3% chance of success. You
 succeed? Get 3 to 5 points. Failure? Get 0-1 point (failure is a
 valuable lesson, after all :)). Capped to ~90%. And maybe not
 giving global experience.

I'm not sure, I'd need more time/discussion to decide. Currently a lot
of ingredients are difficult to come by, so I'm afraid this will make
alchemy too unattractive. This would at least help fix the issue of
out-of-game knowledge of recipes, though.

 What about random (ie player-dependant) parameters? You have more
 success during certain hours, or outside vs inside, or...?

YES! There should be a certain spot in the world where producing a
certain recipe yields extra. Or, certain (hard) recipes should depend
on the phase of the moon. Really, this would encourage alchemists to
go explore the world for once instead of sit in apartments all day.

 Then reduce the dropped items. I mean, so much junk!

Yes, and make more useful items appear once in a while. This will
probably require balancing, too.

 Then, slowing (a lot) combat, making it more tactical. Instead of a
 zillion monsters, some hard to defeat monsters, where you can use
 all your skills and items, and attempt various combinations.

Yes, although I'm not entirely sure how to go about it. Many games
that have combat involve clicking the enemy you want to kill, killing
it, and then moving on to the next. I'm not sure if this suits Crossfire.

 Then various effects on weapons: stun, knock back, confuse, slow,
 etc.

And certain special attacks that take time to recharge, perhaps. But
this would definitely make other spells more useful.

 Reduce the zillion elemental attacks to a lower number (6? 8?),
 other things are side effects.

This would make handling special attacks easier.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTmfq+AAoJEOrPD3bCLhCQpekIAIxj7AeJDa0MJhKCumPKZW7Z
WHCFHlobVDLqeeHXSDWTRC+n07gRowEs2TEvRpmSntFw6WJGGp0H5Mbq/OGijKt2
PhXKR9/ZZgW4ViBOxqW/Qc9bzZswYKgSVA99skMVfrIAu2QHAhpJ7T6Cb46Sujwc
MrTgEt80V7s2smbzndLE5Mw8rqWJgWBJfnEWhm67OkTM5cYQnzxkQzL70GETjR0p
ryLOfPE3Hnd1/unPPO0SH61nS1OJ6dvk84d92TrkbDRr1UbveqqlbFk00OxvSJlr
zUUkhHOcptgXTgW0JLMRoj0hf9GPQuuLwIItVrLtCkc+ECoVx+oZ7iOUBx6TTd8=
=SmBt
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7

[Kevin Zheng]

Hi Tolga,

Sorry for the very belated response.

 On 04/26/2014 08:50 AM, Tolga Dalman wrote:
 With Python 2.7, we have the opportunity to cleanup some very old Python 
 conditional stuff. This way we should be able to replace cjson by the 
 Python standard library JSON implementation. What do you think ?
 
 attached you can find a patch for the existing Python scripts could look like.
 It is completely untested, however, it can be seen that the change itself is
 really non-disruptive.
 
 Comments ?

Unfortunately for some reason after applying the patch the dialog system
no longer works. I'm not exactly certain why, and I won't be able to
provide many details since I'm not good with Python.

You can test the patch on your local server by talking to Milton, who
works at the north gate house in Scorn.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/24/2014 01:48, Mark Wedel wrote:
 Beyond that, there was a separate ticket/discussion about the need to
 have perl for the server on windows to collect the archetypes.  To me,
 that isn't a big issue, but so some it is, and if that is an issue, I'd
 then think requiring additional libraries would fall into that extra
 pain.  It could also make binary distributions harder

I was working on that ticket but kind of dropped the ball on it. I don't
see the Perl dependency as a problem, either, but I understand that it
_may_ be troublesome on Windows.

I am also considering moving the archetype collection scripts to the
arch directory, any thoughts on this?

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

. Recently, several important bug
fixes were made, and few new features were introduced.

I am in favor of switching to the standard fixed-sized integer types.
It is trivial to make the appropriate definitions in a separate header
file for systems that do not already have these types.

 I'd note that a lot of the goofy, ugly, or odd code exists because 
 maps expect it that way.  Which is to say, some functions could 
 potentially be made cleaner and simpler, but to do so would require
 examining every map and making changes to some number (and 
 depending on exactly what construct is being used, being able to 
 detect those automatically might be hard).
 
 I had in mind the networking, event processing/server loop, and 
 plugin codes.

Even then, some specifics would be useful. What are you suggesting for
networking or the server loops?

Personally I'd like to go back in time and get rid of plugins, but that
is an entirely different discussion. It will involve a *lot* of work for
not a ton of appreciable player benefit.

 I'm all for fixing some of that, but it falls into the category of
  a lot of work with no direct/end user effect.  For programmers, 
 there is cleaner code, but for players, things worked (or should 
 work) exactly the same as before.  So those types of changes tend 
 to be somewhat low priority just for that reason.
 
 I agree, though, my contribution will certainly be in the coding 
 area. I leave the game play and game content creation to the experts
  :)

At the end of the day, if you believe that certain changes are worth
your time making, please send a patch. The recent cleanups were made
because I wanted them and nobody objected to them.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/22/2014 11:19, Juha Jäykkä wrote:
 It would be nice to sit down and come up with a roadmap. I've
 been doing so much 'cleanup' work lately because I didn't have
 anything specific in mind to work on.
 
 What happened to that rebalancing-related roadmap from a few years
 ago? Did it ever get finished? I must admit I have not even logged
 on to a Crossfire server for years, which is pretty sad.

Probably not, although I wasn't around back then to be able to tell. A
lot of things, including experience tables, spell levels, player
stats, artifact properties, item prices, weights, and more still need
a lot of balancing and tweaking.

Unfortunately, the only balancing that I am capable of performing is
for object weights. Simply copy real-world values in :D

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTVvrNAAoJEOrPD3bCLhCQxgMIALz3IR7llW0arn/QUfOdoxsA
5j5UxoUzuUMuY/txtcxhDcibr9CIXDYswEOcL5YqYoLZo2lJ5cGnXVnB8BYZYniC
41NBlvFyKBsOm/S0Frpk0fRSHZ1ajVCJ7f2xsmsZOnjjDrPuqrERbzl9xDTbGbw+
gUWY+gtv9qvVw1hviosXFZ7DF/IOh8V9Su7+6JPAkb0WbS+cMq87T4IWcCfvYt+t
6M8zJwNduVefKc+iA/mRPTahrUkd/6iCmXhsAamq1zFPr+Wl/gQ1GGVnrdQkGvTE
hJZTAC6QmK8Y3mN4rb4Elm61RqvNqisjIbuXW33+N8dw7UwRWBZub4lguBbEst4=
=ZKV5
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/21/2014 01:23, Mark Wedel wrote:
  Going back to to the original thread - certainly win32 is used, and I
 also do sun/solaris.

Solaris support seems like a good idea to keep.

  I think some of that might be sound code for the client - though even
 on linux, it seems that the sound 'standard' changes every 5 years or so.

Sound support is now handled by SDL_Mixer, which works well with OSS,
ALSA, PulseAudio, and the myriad of sound systems there are. Most, if
not all of the platform-dependent code there has been removed.

 Changing C standard is certainly something worth discussing - C99 would
 be reasonable (in my mind) - C11 may be a bit too recent - while it may
 be widely supported, it might also mean that certain users would be
 forced to upgrade their compilers (and perhaps other parts of their
 system) faster than they really want.  But it also really comes down to
 features - What C11 (or even C99) features are out there that would be
 of benefit to crossfire?  I'm not familiar enough with the different
 standards to make any assessment on that.

C99 has many new shiny features that I would really like to use.

- Intermingled declarations with better locality of reference
- Exact-width integer types (we try to hack around this right now)
- New boolean data type (hacked around with our TRUE/FALSE macros)
- Variable length arrays (may be useful in future)
- Inline functions, to replace some macros in use
- New style comments (trivial, but useful)
- New library functions like 'snprintf' (used for quite some time)

Of course, right now the blocking issue is compiler support,
specifically from Microsoft. Both GCC and Clang support C99, except for
a few floating point operations, and so do a number of popular compilers
(Intel, maybe more).

 C++ has been touched on some.  I'd add that there are going to be more C
 programmers than C++ programmers, just on the basis that to know C++,
 you need to know C.  So by switching to C++, you may very lose some
 number of current or future potential developers.

Personally, I prefer C simply because I don't know C++ (yet). Aside from
greedy selfishness, I don't think a (partial) rewrite in C++ will be
useful. C++ has nice features, but our aging code has done fine without
so far.

  So echoing some previous comments, I think gameplay should drive more
 new features.  I also think it would be helpful to express what the
 benefits of the changes are.

Right now there's no pressing feature that requires C++ in order to
implement. As far as I can see (which isn't very far) C is fine for the
job. Of course, I don't know what job this is, which means...

 In terms of roadmap, I think there were some out on the wiki.  But like
 most volunteer based projects, trying to stick to any such roadmap gets
 difficult - people tend to work on what they want to work on, and it may
 or may not match something on the roadmap.

It would be nice to sit down and come up with a roadmap. I've been doing
so much 'cleanup' work lately because I didn't have anything specific in
mind to work on.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/21/2014 04:20, Tolga Dalman wrote:
 My impression about crossfire right now is that the development in
 the server and client code is pretty dormant for the last few years.
 At the same time, however, I notice some increased activity towards
 cleanup work. I want to take this impetus as a reason to contribute
 by myself.

More help with Crossfire is always welcome.

 Two reasons are holding me currently up to contribute, in fact: 1.
 There is no roadmap or vision. Admittedly, crossfire runs pretty
 fine for ages now, nevertheless, I do see some open issues. 2. Parts
 of the code is crufty and even messy. To be honest, I'm scared off 
 fixing issues I find in the code because of this.

Having a roadmap or vision is a good idea. Right now mine is to make
sure the game works on my operating system and keep it that way. My
other vision is to make Crossfire more fun, but without any
crystallization that's not very productive.

I have many, many open issues with Crossfire, but I haven't considered
them important enough to dedicate substantial work to them yet. I'd love
to hear your issues so we can start discussing and working on those
right now.

 1. Define clear requirements for the crossfire server code (this
 might apply to the client as well). From this thread, I found out
 that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32.
 What I'm still missing is the versions. Something like this would be
 nice: - For Linux I would just define the use of GCC 4.6 or higher, 
 binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would
 require Visual Studio 12 or higher - ... Naturally, these
 requirements should be testable by the developers. Practically, these
 items are added in the README file and perhaps published on the
 crossfire web site.

The problem with drawing a bright line is that somebody is inevitably
left on the other side. Many working groups have drawn a standard called
C99; we do not have to rigidly adhere to it, but instead of requiring
specific versions of a specific toolchain, we should write portable code
reasonably within a particular standard.

 2. With the platform requirements above given, C99 and/or C++11 can
 be assumed. Even if we decide not to use any C++ at all, I would
 suggest compile the code with a C++ compiler for reasons of
 portability.

I've seen recommendations to compile C using a C++ compiler. However, if
you refer to Bjarne Stroustrup's authoritative book he admits that
certain incompatibilities exist. C++ is no more standard than C, and C
is just as (maybe even more) portable as C++.

 3. With defined platform and compilers, cleanup and janitorial work
 can start. This includes, e.g., the use of standard types (like bool
 or uint32_t), standard functions (like calloc), removal of various
 autoconf checks, etc.

I'm in favor of doing this in the mid-term. We already have a nice
collection of compatability macros that can serve as a crutch for
compilers we do not obey C99.

 4. Modernize architecture and replace existing components.

I'm not exactly sure what this means. I also see no point in replacing
components that have been in service and aren't breaking. I see no harm
in rewriting code, but it'd be a lot more productive to focus on making
the game more fun than fixing what isn't broken.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/19/2014 03:46, Tolga Dalman wrote:
 1. What platforms are still relevant ? Beside Linux and BSD, I found 
 references to these OSes:  win32, hurd, hpux, ultrix, osf1, sgi,
 sun, vax, ibm032.

Right now, there are many people using Windows, Linux, BSD, and OSX.
Most recent development took place on Linux and BSD.

While it's hard to imagine someone running a Crossfire server on VAX or
an IBM032, I don't think it's necessary to go in and explicitly pull out
support. I highly doubt those platforms still work _with_ current
support, because nobody has been able to test.

Crossfire tries to be portable, so a good goal would be to remove
conditional compilations from most of the source code. In an ideal world
every portable project should run on any semi-compliant system with
appropriate libraries installed.

 2. What C standard is relevant ? Moving towards C99 or even C11 would
 allow large portions of cleanups (standard functions, types, language
 constructs, etc).

I think moving to C99 is a good idea, but right now the blocking issue
seems to be Visual Studio, which is used to build the server on Windows.
It'd be interesting to find out how much C99 VS supports.

 3. What about the use of C++ (2011) ? It is clearly possible to
 smoothly convert existing code to C++ which allows better maintenance
 of the code.

That looks like a long-term goal, because I don't see that happening
until more stuff is cleaned up. As Nicholas mentioned, there isn't a
pressing need for C++. That, and I don't know C++ :D

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Building crossfire 1.71.0 server fails without arches

[Kevin Zheng]

Hi Kari,

On 04/13/2014 05:14, Kari Pahula wrote:
 Crossfire 1.71.0 server is unbuildable without the arch directory.
 Here's what happens in lib/ directory (from make -d's output):
 
 In short, install-data-local requires smooth, which requires
 .collect-stamp, which gets created with touch.  Then smooth's rule
 decides that smooth needs to be regenerated since .collect-stamp is
 fresher than smooth, making the build fail since there's no arch
 directory.

Thanks for going through all the trouble to figure out what's wrong. It
is indeed a missing dependency-tracking file ('lib/.collect-stamp') in
the distfile. I must have missed it when creating the tarballs.

 This would work if there was a lib/.collect-stamp with a correct
 timestamp included with the server package, but there isn't.  I could
 suggest that it wouldn't be a dot file since it wouldn't get waylaid
 so easily then.  But this part would, IMHO, work even better without
 using a stamp file at all.  The collect.pl script generates a fairly
 limited set of files and you had listed them already in the
 Makefile.am file itself.  I'm not sure how make -jn friendly the
 current code is, either.

The current archetype collection process is hackish and fails when
running with multiple build jobs. I was thinking that the collection
process should be moved out of the server build process altogether.

 I ran into this while packaging 1.71.0 for Debian.  I worked around it
 by calling touch -t 197001010101 lib/.collect-stamp before building
 the server.

This workaround also works for packaging on FreeBSD. Do you think I
should roll a new tarball with '.collect-stamp' included?

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Bug tracker group searches

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/13/2014 00:02, Rick Tanner wrote:
 Open Tickets:
 
 !status:closed-wont-fix  !status:closed-rejected  
 !status:closed-out-of-date  !status:closed-postponed  
 !status:closed-accepted  !status:closed-remind  
 !status:closed-works-for-me  !status:closed  
 !status:closed-duplicate  !status:closed-invalid  
 !status:closed-fixed
 
 Further info on the syntax: 
 http://www.solrtutorial.com/solr-query-syntax.html
 
 I could use some guidance on how to reconfigure the fields though 
 for the new search terms.

These would be useful for me:

New - status:open
Progress - status:analyzed || status:feedback-needed || status:patched
Suspended - status:suspended
Closed - status:closed

Feel free to rename them to whatever makes more sense.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTSrTkAAoJEOrPD3bCLhCQP88IAISN0+WvCUtRnK5+HqXwUU7R
AjzHCQ2OTsRfDkqZyY/2iHQiK9NfUoBC10lX10TaIGz+BpG+k+1p38Al9SUorEVq
rcrBoyWvZ3sgeJZ/if7B0Ui5/LMkiZz1OqmweIY3BqKah5V40kIc3x0tWKTRAXLW
mr9YaVQysfN0owFuLXxNqkJYAzNz1qHgtDvJ7rhdw+ATlCBxle+21xdW2fMjvGXw
bC7G76b8aj2s6SjM/gHVjam+1vMDoGuoXl92q/+mBZ4MKELBkgR83+G0HJ+R7w5K
006pfUa/YOBLjUYFPb/gRlrcxvcBLUIuXShfC8pZReQxUiSDwxWa04hjQ1zT0jo=
=GD4q
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Bug tracker group searches

[Kevin Zheng]

Hi there,

Since the bug/feature/patch trackers switched to the new tracker states,
the group searches have been left unchanged. To make these states more
useful, I would like the following searches:

- New (bugs that are open)
- In progress (feedback, analyzed, or patched)
- Closed (but NOT suspended)
- Suspended (but NOT closed)

In addition, the milestones should be updated:
- 1.11 and 1.12 should be closed
- 1.x_next+trunk should be removed
- Add milestones for 1.72.0 and 1.71.1?
- Maybe re-open the 2.x milestone for really-distant changes?

Somebody with bug tracker modification permissions should make these
changes. The current milestones/searches are meaningless/broken anyways.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] Crossfire 1.71.0 Released

[Kevin Zheng]

The Crossfire Development Team is pleased to announce the 1.71.0 release.

Highlights in this release include:

- Per-character keybindings in the GTKv2 client
- Fixed sound support in the GTKv2 client
- Retirement of the 'crossfire-config' build parameter dumper
- New pixmaps for many objects, including jewelry and more
- Faster server input parsing
- Many, many, many bug fixes

For a complete list of new features and bug fixes, please see the online
ChangeLog on SourceForge.

Availability:

Crossfire is available on SourceForge (and its various mirrors).
http://sourceforge.net/projects/crossfire/files/

Binary packages are not yet available and will be released when they are
ready.

'crossfire-client-1.71.0.tar.bz2' contains the source distribution for
the client. If you want to play, this is the only piece you need.

'crossfire-client-images-1.71.0.tar.bz2' contains client images and
graphics.  This prevents the client from having to request image data
from the server. It is optional but recommended if you have a slow
Internet connection.

'crossfire-client-sounds-1.71.0.tar.bz2' contains sound effects. This
has changed since the 1.70.0 release. Of course, it is optional.

'crossfire-1.71.0.tar.bz2' contains the server source distribution as
well as pre-generated archetype and image files. If you are running a
server, you need this.

'crossfire-1.71.0.arch.tar.bz2' contains the unpacked archetypes and
pixmaps.  This is only required if you are planning to make changes to
game objects and is not needed to run a server or play the game.

'crossfire-1.71.0.maps.tar.bz2' contains the map distribution. If you
are running a server, you need this.

Checksums:

MD5 (crossfire-1.71.0.arch.tar.bz2) = 284a269840492e45761ea786a86e48ec
MD5 (crossfire-1.71.0.maps.tar.bz2) = 71b9d6da7c2d547de0695808e319cfa5
MD5 (crossfire-1.71.0.tar.bz2) = bc58e01b1266785e85c58f6710ccc13f MD5
(crossfire-client-1.71.0.tar.bz2) = a32b9a3cb42f65820c5a9193dcfa56d5 MD5
(crossfire-client-images-1.71.0.tar.bz2) =
91e9ad93276be1565d190fccdcfb810d MD5
(crossfire-client-sounds-1.71.0.tar.bz2) = 3c9b8045231d4f861986b76b1bfde328

Kevin Zheng
April 5, 2014
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Version bump request?

[Kevin Zheng]

On 03/31/2014 01:47, Mark Wedel wrote:
  There used to be a schedule, but any such process requires that the
 person making the release have time to do it.  Also, on some of those, I
 got people asking on why I'm doing a release then vs in a month, and
 that time based releases didn't make much sense, which sort of made me
 disinclined to do such time based/scheduled releases.

A release schedule might be useful for things that are frequently
updated in small pieces, such as arches and maps. To keep it in sync
with the major/minor release cycle, only bump the 'micro' revision.

That said, it would have limited usefulness because most people who run
servers stick to a single revision or simply follow trunk.

   In theory, anyone can be given release admin privs, and there isn't
 anything that prevents anyone from making a release (there are not any
 secret/private tools that I use).  I'm pretty sure I wrote a wiki doc on
 the release process that describes all the steps.

Here they are:

http://wiki.metalforge.net/doku.php/crossfire_release_guide
http://wiki.metalforge.net/doku.php/crossfire_release_cycle

  Now clearly, it does make some sense that releases be coordinated - if
 you have 5 people each making releases based on what they seem
 reasonable, the release process could become a real mess.
 

 Right now the code seems stable and no massive changes are being
 planned. Is cutting a release feasible in the next week?
 
  Are you volunteering to make the release, or are you asking the person
 that typically makes releases (me) if I can make a release?

I'd gladly volunteer to work on release engineering.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] 'svn:externals' pointers to stable/next/latest

[Kevin Zheng]

Hi there,

A while ago I wrote to the list regarding the removal of svn:externals
from the client source directory in Subversion. Now I would like to
point at a few remaining external references in the repository.

The 'stable', 'next', and 'latest' folders in the root were set up as
links to other parts of the repository. In my opinion this is confusing
and has outlived its usefulness, and should be removed.

The 'next' branch currently points to 1.12.0, and is not documented on
the wiki. 1.12.0 is ancient and only in active use on Metalforge. The
name is misleading.

The 'stable' branch currently points to 1.70.0, which makes sense.
Keeping this seems logical. This makes updating a server checked out
from the branch easy, although its usefulness still seems limited.

The 'latest' branch contains a single pointer to gridarta, which
probably deserves its own top-level external reference. According to the
wiki, it's supposed to point to the trunk directories, but those paths
never change so there it's only there for convenience.

I'd like to know whether or not there are still people using these
links. If not, I'd like to get rid of them.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Version bump request?

[Kevin Zheng]

On 03/28/2014 10:56, DraugTheWhopper wrote:
 Right, so assuming that this email gets to the intended place
 [crossfire], here's a request: is there any chance of getting a new
 official upstream release? So the story is as follows: I do no coding or
 developing, but know enough about Linux to run Debian Testing. However,
 the current upstream version of CF is 1.70.0, which as of a week ago, is
 about two years old. If i understand correctly, all trunk improvements
 since then are not in any official upstream release, therefore never get
 packaged for Debian, and so are not seen by the casual people who merely
 apt-get dist-upgrade occasionally. Is there a chance a version 1.70.x
 could be released periodically, or is there a 1.99 that could be
 packaged separately, or should someone just start packaging nightly
 builds as crossfire-client-unstable? Please pardon my ignorance and
 correct me as necessary.

Yes, I think it's about time that we cut a new release. Even something
as minor as 1.70.1 would be good, because it would mean that the
*many* fixes and improvements are accessible to package users.

It might not even be a bad idea to cut a minor release every year or so
on a schedule, because there's really not a lot of release engineering
that has to be done.

Right now the code seems stable and no massive changes are being
planned. Is cutting a release feasible in the next week?

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] New bug tracker states

[Kevin Zheng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

I've just noticed that the new bug tracker states only appear in the
Support Requests tracker. Each tracker must be updated individually
in order for the new states to apply across all trackers.

Thanks,
Kevin Zheng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS2pw+AAoJEOrPD3bCLhCQ6CMH/35JgIUtG1Ba2o/15mgDACw/
XTLC4GRyz/qKz4jjDqQEdVww6T27O/18TltS8E4LmrhXfhEl/Z/NIUvSg1ABw6t9
5E2BiDtdSiM5/pI3ZD2aS9pzm31ev366M3t1clCDmIAZUwour6DYNwyVz6KNBr4Q
0qIMaZ7RV6WxpANSHpUXFRGoZpZHIh3culB3kkZHZTEDmyiZd0rDKlzvEBtDyQpF
BCyfRZBkT2RszflL7giZZPItZNiDytlu6JfwNqcA1CLWpHzExdw9kPYHg+8zFsFu
UXuZ5YsUnUChw0tdab8fzFuW0evmKDwHKmUOCgLMZ5WjgWcUblwXfqwO7Po5IqI=
=hkVl
-END PGP SIGNATURE-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

[crossfire] New bug tracker states

[Kevin Zheng]

Hi there,

The Crossfire bug/patch tracker on SourceForge uses states to keep track
of the state of a bug report/patch. In order to make it more useful, I
propose removing several states and adding new ones to clear things up.

The first state should still be open, meaning that it was just
submitted, is unread, and very likely needs feedback from the sender.
This means we can remove unread.

Next, there should be analyzed. The problem is understood and a
solution is being sought.

Next, feedback. Further work requires additional information from the
originator or the community—possibly confirmation of the effectiveness
of a proposed solution.

Next, patched. A patch has been committed, but some issues (e.g.
confirmation from originator) are still open.

Next, suspended. The problem is not being worked on, due to lack of
information or resources. This is a prime candidate for somebody who is
looking for a project to do. If the problem cannot be solved at all, it
will be closed, rather than suspended. This should replace
pending-wont-fix.

Finally, some of the closed states are ambiguous and should be removed.
closed-postponed, closed-remind, and closed-accepted are prime
candidates because they are redundant. cloed-wont-fix is the same as
invalid, so remove that too.

These changes should apply to both the bug and patch tracker, and
probably the feature request tracker as well.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 1/2] Keybindings: multiple changes

[Kevin Zheng]

On 11/03/2013 13:56, Mark Wedel wrote:
 The KP_name seem to depend on if numlock is on or off, so in theory
 can go, but at same time, I suspect would apply to non sun keyboards if
 numlock is off.  That said, hitting numlock is not hard, although
 perhaps a warning in the client could be added (Your numlock key is off
 - movement via the keypad will not work until you turn it on) type of
 thing.  I believe there is some way to get that status with gtk.

In my opinion, the client should only accept the arrow keys when the
number lock is off. That said, I don't see a reason to change this now
since it really isn't broken.

  Not specific to that, but I suspect people playing on laptops/notebooks
 lack the numeric keypad, and just using the 4 direction keys is limiting
 (there are probably circumstances where you really need to move or fire
 diagonally)

I'm a regular user of the NetHack-style layout. It was working before
the new patches were introduced; somehow it seems to be in conflict with
the arrow keys. I'll be looking at how to fix it.

  I suspect some of that is command history is a more recent feature and
 keybinding was never added for it (there are probably lots of commands
 which could use keybindings but are lacking them)

But new users will probably find arrow keys more intuitive. There should
be a way to spoon-feed new users key commands without annoying
experienced players.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 1/2] Keybindings: multiple changes

[Kevin Zheng]

On 11/03/2013 11:15, Arvid Brodin wrote:
 I think this is a problem with my code. 
 The default Nethack-style bindings look like this (from common/def-keys):
 
 Logically that means they should work if no modifier keys are pressed, or with
 Run pressed. (Are you saying they work with Fire pressed as well?)

I've cleared out my old key bindings and have the client running from
defaults. The NetHack style keys don't work in normal mode, but do
when CTRL is pressed.

 Anyway, this needs to be expressed with two keybindings in my code: one with 
 no
 modifiers (called None in the keybindings dialog), and one with the Run 
 modifier. My code ignores the 'N' here since it means no flags and only 
 looks 
 at the 'R' - which of course breaks things. I will figure out a solution.

I'll try to break them down into two bindings for each command. But this
seems cumbersome and bloated, and deserves to be fixed.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 2/2] Character-specific keybinding files

[Kevin Zheng]

On 11/04/2013 23:35, Mark Wedel wrote:
 Now a fair question to ask is whether the client should support old
 server versions or not - IMO, if having support is not hard, it should,
 but if making it work would be really difficult, then probably not. 
 Although, in that case, the client should see that limitation and print
 a message saying 'server to old - use an older client on that server' or
 the like.

Considering the small group of players we have, in my opinion it's worth
providing backwards compatibility. Metalforge and Invidious have been
the de facto public servers, and I imagine that many players have
invested significant time on both.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH] Fix keybinding bug when connected to server-1.12

[Kevin Zheng]

On 11/04/2013 17:41, Arvid Brodin wrote:
 As the subject says.
 
 The patch should apply to client trunk rev 19091.

Committed in r19094, thanks!

 Also, please do not modify the patches when applying them since 
 it messes up any patches that I have queued. If something should 
 be changed, tell me what and I'll generate a new one.

Point taken.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 0/2] Work on keys.c and the keybinding system

[Kevin Zheng]

On 11/02/2013 18:21, Arvid Brodin wrote:
 I think we should still remove the functionality that allows one 
 to rebind the modifier keys, for two reasons:
 
 * It doesn't seem to work. Try it out on rev 19089 - the bind is
   successful (when you press the bound key the corresponding Run/
   Shift indicator lights up), but as soon as you press a direction
   key, the Run/Fire modifier is lost, and you only get a normal 
   direction press.

This seems like a very compelling reason to me. I vote that we go ahead
and make the change.

 * Patch #2 introduces character-specific keys files. It would be
   nice to take the opportunity to change the format of that file
   in the same go, to correspond with the Ctrl and Shift keys (so
   C for Ctrl, instead of todays R for run, etc).

Yes, this change makes sense if control keys can't be rebound.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 1/2] Keybindings: multiple changes

[Kevin Zheng]

On 11/03/2013 08:50, Arvid Brodin wrote:
 I see what you mean - suddenly there's a lot of noise in the keybindings
 dialog. What I did was to remove all bindings that I don't use, and it feels 
 OK now. Perhaps that'll work for you as well? If you try it and still hate
 it, tell me and I'll see what I can do. :)

It's not too bad. Since most of my personal key bindings are applied
with the ALT key, I can just sort the list by modifier.

 I will also submit a cleaned-up version of the common/def-keys file. There 
 are some obvious clean-ups and some maybe: 
 
 - 3 bindings of 'a' to apply (to handle different shift state and modifier 
   states). Replace with a single binding of 'a' with Any flag.

In hindsight, there are some issues with setting the directional keys
with the Any flag. I usually bind ALT-B to 'cast burning hands', but
it conflicts with the 'Any' definition of a NetHack-style direction key.
Perhaps the 'Normal' checkbox should come back?

 - 2 of 'e' to examine (shift state). Replace with single binding of 'e'.

There should just be one examine command, examine. I think it should
be bound to normal and CTRL.

 - What's the difference between the take and the pickup commands? (',', 
   '@')

The 'pickup' binding should probably go. In NetHack, '@' toggles
auto-pickup, but Crossfire's 'pickup' command requires an argument.
Perhaps it was left over from a long time ago.

 - How often do we get new players who use Sun Type 4 Keyboards? Perhaps these
   could go? (17 bindings.)

Admittedly, not that often. Binaries aren't even being built for modern
Sun machines (with normal keyboards).

 - Is there a difference between rotateshoottype - and rotateshoottype -1?
   Also needs modifier flags cleanup (A/N/NF).

Not exactly sure, they *seem* to do the same :p

 These I don't really know about:
 
 - I've never seen the Nethack-Style key layout before. Also, they don't seem
   to work in conjunction with the Fire modifier (only N and R). Does the fact
   that that bug has never been fixed mean they aren't used at all, perhaps? Or
   do people just fix that when they start to play?

I've always used NetHack style keys, and they've been working fine all
the time. After the update some interesting things are happening, which
I'm working on investigating.

 - Arrow keys... I *really* like the feature of command history and the 
 prevkey/
   nextkey that is available. But these are not bound by default, so perhaps 
 they
   aren't used as much as they could be. On the other hand, using the arrow 
 keys
   for this (and not for north/south etc) requires an immidiate help text 
 whenever
   a new character is started, to explain how to move.

Thing with Crossfire is that we don't have a pop-up-on-your-screen
tutorial at the beginning. And if players start by using the arrow keys
(based on intuition), they probably won't discover the other ways to
move, either.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 2/2] Character-specific keybinding files

[Kevin Zheng]

On 11/03/2013 13:36, Mark Wedel wrote:
  Just a question - is there any way to set up 'global' keybindings (eg,
 those that apply to all characters)?

This does seem useful. One possible idea to throw around is to make the
key bindings window tabbed, one for per-character and one for global. If
there's a conflict, prefer the per-character binding.

Of course, this is easier said than done.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [RFC 2/3] Misc keybinding fixes and changes

[Kevin Zheng]

On 11/02/2013 11:04, Arvid Brodin wrote:
 That's something of a tall order. :) It's a lot of work learning how
 _one_ client works; learning two clients and then trying do do only
 changes that benefit both (and doesn't break any) of them could be
 very limiting. (Is the Windows compatibility broken on the gtk client?)

Maintaining the Windows port of the GTKv2 client is difficult. Nicholas
tried to build a Windows version from trunk, with limited success.

 Are there any code dependencies between jxclient and the gtk client? 

No, not that I am aware of.

 I noticed the gtk client code is split between the folders common/
 and gtk-v2/. I found references to something called the x11 client
 in the code, and I assumed that that was an old client that had since
 been removed. It was apparently called cfclient, later renamed 
 crossfire-client-x11. If this has been removed, perhaps it would be a 
 good idea to merge the common/ folder into the gtk-v2/ folder?

You've probably noticed that the sources in common/ are built into a
shared library. The intention was to share some code between the several
different versions of the client (X11, SDL, OpenGL, GTKv1, GTKv2). Now,
it seems a little unnecessary (unless someone decides to bring back
another client).

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [PATCH 1/2] Keybindings: multiple changes

[Kevin Zheng]

Committed in r19090.

To the best of my knowledge, Crossfire doesn't have a formal patch
review process. By the time everyone reviews it, bit rot will have
already set in. Best to commit it now and fix issues later if needed.

On 11/02/2013 18:24, Arvid Brodin wrote:
 * Show all keybindings (incl default ones) in both 'unbind' and the 
 keybindings
   dialog. (Should reduce confusion for new users.)

I almost want to say that I miss the old behavior. If feasible, I'd
really like to see a show non-default bindings only checkbox.

Cheers,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [RFC 2/3] Misc keybinding fixes and changes

[Kevin Zheng]

Hi there,

On 10/30/2013 20:06, Arvid Brodin wrote:
 As a new player, I found this to be a usability problem. Everyone knows what
 the Control key is, but what's the Run key? I think the reason Shift and Ctrl
 were called Fire and Run is that it is possible to rebind them - i.e. if you 
 want some other key to act as the Run modifier, you could
 
 'bind runkey1

I wasn't aware that this feature even existed. If it isn't present in
the JXClient, I'd say it's safe to take it out.

 - and press a key to act as the Run modifier. (Actually I'm not even sure this
 worked; I never tried it - and I'm pretty sure it requires the run_on state 
 to 
 be kept in the server, since key repeats won't work if you bind Run to, say, 
 'r', and press that after the direction key... hmm. So it might be in the way
 of better handling of repeating keys.)

Probably not, repeating keys should be handled more elegantly.

 I realize this change might not be liked by everyone, so feel free to shout 
 out
 in that case (RFC = Request For Comments). But it did seem like a pretty 
 unique
 and not very well advertised feature, so I chanced that it could be removed.

You have my vote to take it out. Input from others would be helpful.

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] [RFC 1/3] keys.c: Style fixes

[Kevin Zheng]

On 10/28/2013 18:15, Arvid Brodin wrote:
 Use consistent coding style throughout the file.

Committed in r19089, with minor changes. Thanks!

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire