Re: [crossfire] Remove or keep contact email addresses from map headers?

[Mark Wedel]

On 6/16/23 10:37, Rick Tanner wrote:


Hello,

While working on numerous maps, I have noticed that some map authors (and/or 
map editors) included a contact email address in the map header.

Nearly all of these addresses are no longer valid. For instance, some are University 
(College) addresses. And, many are from people I have not "seen" online in many 
years.

Given the different methods of communication we now have available - IRC, 
Discord, and the mailing list -- those are the preferred ways to reach out to a 
map author for questions, comments, discussion, etc. instead of direct emails 
to the author.

Does anyone have any concerns in regards to removing the email addresses from 
the map headers?

If there are no issues or concerns, I will take care of updating all the maps 
to remove this content. To give this discussion some time, I would look at 
starting to make this change in 2023-July.


 I was thinking when I just saw the subject 'how many of those e-mail addresses 
still work, and even if they do, is anyone looking at them'.

 I think that with the fact everything is in publicly accessible source 
control, people can always use that to see the original creator (or at least 
importer) of a given map, as well as who has modified it recently.  That is 
probably just as useful, if not more useful, than the info in the map header.

 Even if someone does want the old information, they can always look for it in 
the source history (look at the old version when it still exists).

___
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] Happy New Year :)

[Mark Wedel]

On 1/3/22 11:04 AM, Nicolas Weeger wrote:

Happy New Year everyone!

May 2022 be The Year Of Crossfire On The Desktop :p


 That is a little old - shouldn't the focus be on mobile now? :)

___
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] Localisation

[Mark Wedel]

On 9/17/21 10:28 AM, Nicolas Weeger wrote:

Hello.


I'd like to overhaul the translation / localisation system. So searching good
ideas & suggestions & comments :)


 so the reason that I added the name_pl many years ago is that in English, 
there were various 'one off' cases that were not easy to handle.

 Before, logic was basically:
 - Most plurals just need an s added (sword -> swords)
 - If it ends in y, tends to need to be replaced by ies (ruby -> rubies).  I 
think there might have been a flag to handle that.

 But there are other words where this logic is not sufficient (die -> dice is 
one that comes to mind - I think there were some others which followed yet 
different rules).  So in the end, it became simpler on the code side just to have 
a different field with the plural name, instead of the code itself having to do a 
bunch of stuff to make a proper plural.

 I think the other cases where things became complicated are more complex names, 1 
foo of bar -> 2 foos of bar, which became yet another case (and now once again, 
rules for the first name have to be covered - ruby of greatness -> rubies of 
greatness.

 I'm not quite sure what using the library, and adding to add in gender field 
and special fields, etc, is a simpler solution - it in fact looks more 
complicated - from a person making arches (who may not be much a programmer), 
having {en,fr,de,...}_{name,name_pl} seems simpler.  It becomes 'Oh, I know the 
proper German plural for this name, so I just need to add a de_name_pl with it 
to the arch and are done, and do not need to thing about gender field, special 
fields, etc.
___
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] Git for arch, maps, server, and client

[Mark Wedel]

On 5/5/21 10:44 AM, Kevin Zheng wrote:

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.


 I think that is a good idea - it makes more sense to me that everything under 
the project is using the same source code control system, vs some using git and 
others using SVN.

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

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

[Mark Wedel]

On 5/4/21 11:45 PM, Kevin Zheng wrote:

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.





- 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.


 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 doing this work.


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

Re: [crossfire] Handling massive loot

[Mark Wedel]

I totally agree that my proposed fix is a pretty big hammer to fix the problem, 
but it is a simple way to do it.

It might not be that hard to add some logic (even on the server) of something 
like like 'repeat last command until successful/complete'.  So you could do a 
dropall, and it drops 10 items/tick, and keeps doing so until there is nothing 
more to drop.  Same for pickup (though in that case, there would be a change in 
behavior, as you would have to sit on the space until nothing is left to be 
picked up, and this might be non obvious if you have different pickup modes set 
(value density), because there might still be a bunch of items on the space, 
but nothing that matches the pickup criteria.

Now this actually works reasonably well - at each players tick turn, the socket 
can check if the player has issued any new command - if so, it executes that, 
thus breaking the sequence of repeating the command.  To me, it would be really 
annoying to do something like 'drop all', and be frozen with no way of 
interrupting it until everything is dropped, which could be many seconds if the 
limit/tick is low.

As far as trees/linked lists - I was thinking more on how things are organized 
on the map, not queuing things up to dropped.  If map spaces were trees instead 
of lists, it is possible that the finding matching object to merge would be 
fast enough that dropping lots of objects would not be an issue.

In fact, I don't actually think that the time go through the inventory to find 
matching items to drop/pickup is the issue - I think the actual issue is the 
time to insert them into their destination.  So in case of a pickup/dropall 
that happens over several ticks, just having the exact same logic now (looking 
at source for object that matches criteria) is probably fine, and there isn't 
any need to build a temporary list of objects that match the criteria.

Building a temporary list has potential problems - mostly make sure it stays in 
sync, making sure it is properly cleared/initialized each time (if there is 
some bug where it isn't cleared, such that the player does a dropall, does 
something else that changes inventory, and does the dropall again, if the 
server thinks this is a continuation of the existing dropall because something 
wasn't cleared, good chance you are going to get some odd behavior)


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

Re: [crossfire] Handling massive loot

[Mark Wedel]

I should just add, after the above:

TLDR: simplest short term solution is limit pickup/drop to X items/action 
(tick).  X could be a setting, so one can play around to what seems like a good 
value.  This would require fairly minimal change to the code (just the pickup 
and drop logic to track how many have been dropped that tick, and then return 
once it hits the limit)

The game could then display something like 'you have picked up/dropped all you 
can right now', and player than has to repeat that action on the next tick.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Handling massive loot

[Mark Wedel]

So I had thought that in an ideal rewrite, there is 1 thread per map, and 1 
thread per player (and maybe a few others that do stuff in the background).

That keeps things relative simple - you just have per map and per player thread 
locks - if the thread has the lock, it can do whatever it wants.

This also helps crossfire use multiple cores of the cpu.

For maps, it makes the most sense, because right now, one slow map slows the 
entire game down (be that someone dropping a pile of items in a store, or some 
map with lots of spell effects).  Each being contained to its own thread (map) 
means that people on that map see the lag, but other players don't.  And 
certain map operations (load/save) are also known to take a while.

To me, it makes more sense to let the system library deal with thread 
scheduling vs implementing some scheduler within crossfire itself.  Threads are 
a fairly cheap resource, and crossfire still would not need a lot of them.

Nathan is correct in that the problem is that until the drop (or pickup) 
command completes, the server is not doing anything else.  The approach he 
presents would also work (and not require threading) - building a list of items 
to drop, and dropping X of those/tick (X could be more than none).  But he is 
also correct that depending on how much stuff is on the square affects 
performance.  Dropping 1 item on a space that has 1000 items already will be 
slow, and dropping 20 items on a space that is completely empty may be pretty 
fast.

One way this could be handled is tracking the number of objects on a space, and if that 
object count is >X, disallow dropping of more items there ("this area is overflowing 
with stuff, and you just can't find an area to drop that %s")

There is still the problem with pickup - and when going through cleaning out a 
dungeon, the players inventory can get quite long, especially since there tends 
to be many variations of an item.  Limiting pickup to X items/tick helps out 
here, but could also be annoying, as you move over a space, not everything is 
picked up, move back, move off again, notice not everything is picked up again, 
repeat as needed.

Some of the problem as noted above is just the sheer number of items - while 
having lots of variation is interesting, having 5 different types of swords 
with minor variations, and then those 5 swords could have slightly different 
artifact (of Lythander, etc) values, and add that they could then also have 
different +magic values, and those 5 swords can turn into 100 variations of an 
item, which increases the item count when dealing with merges.

Linked lists are also not particularly efficient when dealing with having to 
search them - using something like a tree (organized on merging criteria) could 
greatly speed up the insertions if it is well balanced, though can be a bit 
less efficient when walking it.

Another thought would be rather than dumping items onto the linked list of the 
space and marking that it needs to be sorted, there is in fact a different 
linked list there contains the 'incoming' items - by the fact it exists means 
those items on that incoming list are not sorted, and need to get added/merged 
to the normal list.  But this type of deferral gets complicated - you now have 
to deal with the case where the player wants to pick up an item they just 
(mistakenly) dropped - there are now 2 lists to look for.

In some ways, not merging items on the ground actually makes sense - things 
don't automatically group together in real life, so having a space with '10 
arrows, 3 swords, 4 arrows, ..' actually makes some sense.

IIRC, another performance issue (hack) was for the shop menus, where it 
basically would use the merging logic to generate a more concise list, but when 
people go unload 1000 items into the shop, it means that the logic it uses 
(making a new list, copying objects onto it, etc) is not very efficient.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Handling massive loot

[Mark Wedel]

On 3/22/21 11:58 AM, Nicolas Weeger wrote:

Hello.

One issue that happens is server delays when dealing with big loot.

For instance a player selling some thousands rods can stuck the server for
some seconds... Or even dropping many items on a big pile can be quite slow.


So to handle that correctly, I was thinking of changing the server code like
that:

- split data/commands reception and processing - have one loop that reads from
the socket, put commands in a waiting queue, then another function later
processes those commands

- for commands like pick/drop/examine, enable them to work on multiple
processing loops instead of a single. So for instance the command would drop
100 items, then store its status, put itself back on top of the command
waiting queue, and exit - this way the server can process something else.


Being multi threaded would help some things out.

It has been a while, by my recollection is the drop (and pickup) problem is 
that these are in fact handled by the server, eg, 'drop all' is done on the 
server, dropping everything of matching criteria.  And likewise, pickup all is 
done on the server, so slowing down the command processing from the client 
doesn't help out.

It is also my recollection in that the reason this is slow that each time an 
object is moved (ground to player or vice versa), it has to check the 
destination for duplicates to merge them (otherwise, you could have 20 
different entries for silver coins).  This becomes an O(n^2) operation, so when 
dropping a few items, it is pretty fast, but when dropping a stack of 100 
different items, that takes a lot of time.

There are a couple ways to deal with this:
- A thought I had a while back is once a space gets too many items on it, items 
fall over to neighboring spaces - this would reduce the upper threshhold over 
that operation (never too many items to examine on a space), but this could 
basically result in an entire shop being filled to a level of 25 items deep.
- For items going to the floor, marking the space as needing 'merging' later on 
could be done (one could even imagine something like a shop keeper standing on 
the space as this merging is done, preventing players from interacting with it)
- For items going into the players inventory (they step onto a pile of junk), 
deferred merging could be done, but would result in new items getting send to 
the client, and then and update down the road that the new item does not exist 
and in fact item X has a different quantity.  I'm not sure how visually that 
works out.
- Maybe limit the number of items picked up at once, even with pickup all, to 
something like 25 or other number where performance is still reasonable.  This 
makes it harder to clean up everything in the dungeon, but is somewhat more 
realistic (you can only pick up stuff so quickly).
- I can't remember if the gold insertion when selling a bunch of items is 
intelligent.  That is to say, if you sell 100 items, does is calculate the net 
proceeds and inserts it once (intelligent) or inserts the coinage 100 items 
(1/each item, keeping in mind that there could actually be several different 
coins being inserted for each item).  So changing that (deferred gold updating) 
could also have some benefit.

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

Re: [crossfire] SVN history issues

[Mark Wedel]

On 2/17/21 6:56 PM, Nathaniel Kipps wrote:

On Tue, Feb 9, 2021 at 12:33 AM Mark Wedel  wrote:


   The images may be recoverable - this presumes that the initial import to CVS 
didn't result in corruption, but rather the CVS -> SVN conversion resulted in 
corruption.  If the image in questions are in the actual crossfire-arch 
distribution, versions exist on sourceforge for download that predate the SVN 
conversion, so it may be possible to download one of those arch distributions and 
just copy over the pre-corrupted images into the current arch tree and recommit.


I'm not terribly worried about the images being permanently lost. What
I'm more interested in is if it's possible to "fix" the history so
that it's easier to browse in the future. And, if so, is it easier to
fix it while we're using SVN, or once we move to Git?


 Unless someone has a backup of the CVS repo, I think the CVS commits/rename 
information is now lost (I looked, and don't have a CVS backup).
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] SVN history issues

[Mark Wedel]

On 2/5/21 8:52 PM, Nathaniel Kipps wrote:

Recently I was rooting through SVN history, trying to trace some old
facesets and PNGs, when I found a few anomalies. Maybe someone with
more experience than me is able to determine:
* Can these be fixed retroactively?
* If so, is it easier to fix them in SVN or Git?


 You assessment below on the causes is likely correct (going back to CVS repo).

 I think at the time of the CVS->SVN conversion, the CVS repos were still 
active, with the idea being that if anyone wanted to see the earlier history, they 
could still go back to the CVS repo.

But it looks like the CVS repos disappeared - going by how many years since, 
probably not unreasonable.

 It is also worth mentioning that the CVS repo on sourceforge was not the first 
repo.  I sort of recall a CVS repo hosted elsewhere, and before that, it was an 
RCS repo on the maintainers (my) machine.

 I suspect the commit messages may be completely lost - I checked my local 
system to see if maybe I had a backup of the CVS stuff repo itself, but I 
couldn't find one.

 The images may be recoverable - this presumes that the initial import to CVS 
didn't result in corruption, but rather the CVS -> SVN conversion resulted in 
corruption.  If the image in questions are in the actual crossfire-arch 
distribution, versions exist on sourceforge for download that predate the SVN 
conversion, so it may be possible to download one of those arch distributions and 
just copy over the pre-corrupted images into the current arch tree and recommit.




The first issue is that at least one time in the past, a number of
files were moved or renamed, but instead of tracking the change, it
was treated as a large number of deletions and new files. The instance
I found was r1487, in which mwedel renamed most or all of the face
images. This was presumably done under CVS, and the broken history was
passed into SVN. This is certainly not a catastrophic problem, as it's
not too hard to continue tracing the history of the file, but it's
certainly annoying.

The second (and more severe) issue is that a lot of old PNGs have
become corrupted. An example would again be r1487, where it appears
that all the old images are broken, and all the new ones are fine.
Thanks to some folks in IRC, we determined that the *older* images
have been corrupted by insertion of extra CR symbols, as though
something was trying to convert the file from LF to CR/LF. My best
guess is that the PNGs were tagged wrong in CVS, then during the CVS
to SVN conversion, the accidental CR/LF conversion was done on the
PNGs. Supporting this theory is r13991, in which anmaster comments
"Fix incorrect svn properties ... that could in worst case result in
corruption."

Anyone have any thoughts on whether fixing these is possible, and if
so, how much effort might it require?

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



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

Re: [crossfire] Game play thoughts, ideas, ramblings :)

[Mark Wedel]

 In general, I agree with much of what you say, and will only discuss points where 
I have something to add or differ.  I reference different versions of D here, 
partly because that is what the game is seemingly based on, but also because 
looking at what other have done may be useful

Scattered content: I agree with this, and will note that while information on 
some maps may have hints provided elsewhere, then it becomes the question of 
'How was I suppose to know I had to talk to X to find out about this?'  And 
there is something of a fine line between having enough hints vs so many that 
it becomes over advertised.  I guess other games make this a little easier by 
making NPCs that have something useful to say be highlight or something.

Random maps, from my recollection, really were meant as something of a filler, 
as well as ways to have some variety - the final map may be set up, but the 
path to get there varies.  But really deep random maps more seem to be a way to 
get lots of items.

Game rules/races/classes - agree here, some attempts were made in the past in the past 
to add differentiation, but one problem is that the game is largely hack and slash, and 
that mage ends up behaving a lot like a fighter in order to regain sp.  I think some 
thought would have to be given on what changes may be necessary to let someone play as 
a pure spellcaster.  That concept exists in D because they are part of a party.  
In crossfire, where they may be on their own, how does that exist?  And how to balance 
all of this.  One thing D did was give spellcasters OK damage cantrips that 
they can cast at well - maybe something like a 0 sp magic bullet spell.

The attribute system also follows the D where the bonus from stats gets a lot better 
as they go up (at 24 -> 25 is a lot bigger bonus than a 14->15).  D basically 
changed that to a linear system - in such a system, letting characters raise stats now and 
again as they level (and make weapons that improve stats) less an issue.

Items: Some games behave as crossfire (every item that the monster had drops) 
and other only drop a subset.  One thing that makes crossfire worse is that 
there are so many variation, and a lot more things are killed.  So you don't 
get a stack of 10 short swords from killing 10 goblins, you get 5 normal ones, 
2 -1, 1 +1, a few different 'shortsword of X' where X is different, etc.

Spells: Agree there are too many.  Being able to do something like 'cast 
fireball of radius X' would be one way to reduce the number of spells, as 
small/medium/large variations go away.  X would depend on level of the caster, 
and perhaps keep gong up, so at level 100, you could cast massive fireballs.  
Maybe as balance, if radius is large, damage goes down, but how to exactly 
balance is hard.

One of the elder scrolls games allowed one to make custom spells (I'm think 3- 
morrowind), and that did not show up in subsequent games.  But I quickly 
learned how you min/max spell creation, so I sort of think adding it to 
crossfire would create a new set of balancing headaches.

The fact that there are a huge number of spells is what led me to create 
different spellcasting schools - it just seemed a bit over powered that one 
would get access to hundreds of spells (this sort of relates to the skills).

Going to stricter classes above, if one made it not possible to learn new 
spellcasting skills, one could differentiate classes some by each having a 
unique spellcasting skill, and the spells for each skill is different (there 
would be some overlap, but not every one would have fireball).  This could 
allow for more balance spellcasting classes, which at the same time are 
different.

Skills could probably be revisited - some may not be interesting enough to 
really warrant keeping around - some were also made when character level == 
effective level for skills, so how to level them was not a concern, but 
leveling them where you have to earn experience in the skill is a problem.

Resistances & attacktypes: There probably are too many.  And some are more 
effect than damage.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Server code structure

[Mark Wedel]

On 12/10/20 9:06 AM, Nicolas Weeger wrote:

Hello.


The server code is currently divided in libraries, but without a clean
separation IMO.

For instance why is "rod_adjust" in server and not in "common"? (forcing users
of common to declare a stub)


Should we just decide to put all code together and forget the 4 or 5
libraries, or on the opposite try to really separate things?


I was planning (someday :)) to tackle the events system, and move it to
common, probably, that could help separate the logic - event "item_created"
that the server could hook for rod adjustment. This would enable to remove the
various stubs.

But if we decide it's ok to keep libraries separate, that's fine by me too :)


 Now days, it may not make that much sense.  Back when crossedit existed, it used 
the common to deal with the loading & saving of maps and archetypes, and more 
or less, stuff not related to that was in the server directory.  But crossedit is 
long since gone.

 At this point, some of the directories (socket, random_maps, etc) make sense 
in that it puts all the related code in one place.  But common is a bit of a 
mix.  Its a somewhat tricky balance - common was originally related to the 
load/save logic (and actual common things, like object handling, etc).  But 
then you get the case of having the logic to load the data file, doesn't it 
make sense to have the logic that uses that data to be in the same file, and 
then it becomes less clear where that line between common and server is.

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

Re: [crossfire] Graphism, tiles, size, and such

[Mark Wedel]

On 11/11/20 12:59 AM, Nicolas Weeger wrote:

Hello.


I've been thinking about game graphics, and I'd like to share some questions
and thoughts.



Monsters like the hill giant (I can also think of the ArchAngel, the
Retributioner, some dragons too) have an incoherent size IMO. They are 1x2 in
tiles, but that only reflects their height, not their "planar" size.

So I'm wondering:
- should we keep that behaviour
- should monsters be only tiled squarely (eg 1x1, 2x2, etc.), and we adjust
the sprite to reflect the height
- should we allow sprites to overflow on top of another sprite, so the height
would appear (the hill giant would then be 1x1 with a 1x2 sprite adjusted to
its feet)

Other ideas?


 I think when things were changed a while back so that image size & footprint 
of the creature were not tied together, making hill giants 1x1 footprint (and other 
similar tall creatures have a square footprint) was either done or investigated, 
but not done or reverted back.  For players, higher density monsters tends to be an 
advantage (those AoE spells hits more targets).  I can't remember if there might 
now have been some map breakage by changing this, and monsters could now wander to 
places they were not envisioned going, etc.

 There are also some other cases where monsters should be rectangular - wyverns 
come to mind.  But there really isn't good support for going from a 1x2 
monsters to a 2x1 monster as it changes direction.





Another thought was wondering about making 48x48 (or 64x64?) sprites.

32x32 seems quite small with current resolutions...

I'm not saying to redo all sprites, but maybe clients could handle resizing
from 32x32 to 48x48 when required or directly use a 48x48 sprite. This would
allow to slowly rework some tiles as we feel it, introducing more details.


 The gtk client at least supported resizing the images used for the map and 
inventory.  As resolution has gone up (a 25x25 map at 32 pixels/image is only 
800x800), bigger images could certainly be done.  I'm not sure the correct size 
- whether 128x128 would be best, and then scale down would be best way to 
future proof for a while?  Disadvantage is size.




Been also idly thinking of changing players to be eg 3x3 tiles, so we could
have really small monsters (1x1 tiles). But that would be quite a change... In
this case, maybe on the opposite sprites could stay 32x32, or even go down to
16x16, but eg players would be bigger anyway.


 Multispace players will likely require lots of work (does every map now need 
to expanded, because otherwise that 3x3 player won't fit down those small 
passage or through small doors?) but things like what space does a spell leave 
the player from?  How about incoming spells, and does the player end up taking 
more damage if many 4 of his spaces are hit by a spell (I sort of recall this 
was the case for monsters)

 But I suppose it depends on what is the minimum reasonable 'unit' for most 
things to me.  For small monsters, I wonder if it would be easier to let small 
creatures share a space - instead of the 'is there something alive on this 
space', instead each creature could have how much of the space they use.  So 
small creatures might only use 25% of a space, so 4 of them could be on the 
same space. Though I'm not sure how you deal with what image is used for each 
of those creatures.

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

Re: [crossfire] Archetypes collection changes proposal

[Mark Wedel]

 This idea seems reasonable.  The original collection dates back to a time when 
hard drives were much slower (and amount of memory in systems was less, so 
likelihood of that data being cached was low)

 Like Kevin, I'm not sure if there is still need for collected archetypes - the 
tar file could just be distributed as is now, and have it unpacked as part of 
the install.

 At least for the .arc files, in theory, I think a 'cat */*.arc > 
everything.arc' would more or less work - archetype files can currently have more 
than one archetype.

 The issue is the png files - those can not be simply combined - some form of 
container would be needed, whether that is zip, tar, or custom format currently 
used.

 One advantage in the past was that having large files was more efficient if 
you wanted to compress them, but that isn't an issue now days.


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

Re: [crossfire] Various adjustments

[Mark Wedel]

On 5/8/20 11:41 AM, Kevin Zheng wrote:

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.


 IIRC, main issue is when picking up or dropping lots of stuff, and I suspect 
there is probably some interaction with containers that reduce weight of things 
inside of it.

 fix_me (which maybe should really be called fix_weight?) has to go through 
every item in the players inventory to calculate things correctly.  As such, if 
player has tons of stuff, it is not most efficient, though this was probably 
more an issue when computers were much slower and fix_me took a measurable 
amount of time.  And I think some of the issue is one wouldn't want to call 
this function everytime an item is picked up or dropped, because if someone is 
doing a dropall or has pickup mode all on, this could get called hundreds of 
times in one tick.

 It might be interesting to measure how long it takes now on a character with 
lots of items to run this.  One thought is to just call this every Xth tick or 
something  if it is sufficiently fast on current hardware.




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?


 I thought you got literacy experience each time you learned a spell (though 
could be mis remembering).  As such, anytime you found a spellbook, if you 
already knew the spell, you forget it, and then re-learn it from the spellbook 
you found, gaining a little more literacy experience.  I'm not sure if that is 
really an abuse, though if that is intended (or lack of better term), probably 
some better interface to do that would be desired - an option to read (consume) 
the book for some amount of experience if you already know the spell.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Various adjustments

[Mark Wedel]

On 5/1/20 1:54 AM, Nicolas Weeger wrote:

Hello.

Been playing some lately, and I noticed a few things I'd like to change.


I think the following commands should be made DM-only, if needed adding the
player to affect:
- fix_me
- forget_spell
- printlos


 I think the rationale for forget_spell is that if players learned a spell they 
don't want to know for some reason, they should be able to forget it.  But I'm 
not quite sure why they would want to (try to keep the spell list shorter).  
But I imagine it could be used for abuse - forget spells that you fine 
spellbooks for, so that you can re-learn the spell and get exp?

 Other ones seem reasonable.




Moving in diagonals should cost more than moving horizontally or vertically ;
ok, that one is potentially a major change, but it makes it faster to move in
zigzags than plainly straight...


 It shouldn't be faster to move in zigzags than straight - you are covering 
more distance, but going NE, NW, NE, NW, NE, NW should not get you due north 
any faster than if you just did N, N, N, N, ...

 The one danger I can think about changing this is if it affects other things, 
like spells.  This could first of all perhaps result in odd spell propogation 
(may depend on the spells, though I think in most cases the spell just moves to 
next space and ignores any cost to do so).  But this could cause odd effects to 
the players trying to move out.  For example, a character may be able to outrun 
a spell effect if they are heading due north and the spell is also heading due 
north, but may not be able to outrun it if they head NE (since each space is 
costing more movement) if the spell can also move NE without that extra cost.

 I'm not really sure, but something to think about/investigate.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] Monsters balance

[Mark Wedel]

On 5/1/20 2:01 AM, Nicolas Weeger wrote:

Hello.


Monsters balance (and game balance in general) is a big topic obviously :)


I think right now monsters aren't really balanced, with big gaps in terms of
difficulty (how long it takes to kill them, how dangerous they are for players)
versus experience they give versus rewards they provide, and such.


 Totally true. I tried to balance them somewhat at one point, but it is a big 
task, and hard to get right.  Also, because some monsters have vulnerabilities, 
they still become easy to kill if the players know to use the right 
spell/weapon against them.


So I was thinking along the idea of making monsters more like players in terms
levels.


Basically: for various "types" of monsters, define a level 1 prototype, and
leveling rules. Then using that generate monsters of various levels.



For instance, with totally random numbers that would need to be adjusted :)

For undead, decide that zombies are level 1, with eg 4 hp, dam 2, they give
100 exp. For each undead level, add 3 hp, 1.5 dam, 2 armour, and 500 exp.

If ghosts are level 5, then they have approximately 16 hp, dam 8, armour 8,
giving 2100 exp.


Of course this wouldn't be a hard rule, it could be changed and altered, but
it could make monsters more interesting.

It also doesn't take into account armour/weapons/spells, or hp regeneration,
of course.


 I always sort of thoughts that if you say monster level should be roughly 
equal to player level (though maybe not, so you tend to have swarms of monsters 
in crossfire), you would want things like HP to be on par, eg, a level 5 
monster should have roughly same HP as level 5 player.

 My thought for that is things like spell effects - PvP was really deadly (or 
getting caught in a friendly spell if that was enabled) because monsters used 
to have lots more HP the players, so spells had to do a lot of damage to be 
useful.  But it then meant if the monsters had the same spell, it killed 
players.




Exp itself is a big topic too. It really depends on how many monsters we want
players to kill to level up. Should it be a zillion monsters? A few hundred of
around the same level? Could one or 2 really though give enough exp to level
up?


 The fact is that there tends to be lots of monsters piled in the game.  While 
it may make sense for there to be fewer monsters vs swarms you just kill by the 
dozens as you run through them or hit them with spells, changing all the maps 
to reflect that is a big change.

 Rather than monsters, it may be better to think about time to do so.  Is 30 
minutes/level (up to some level, like 20) a reasonable time?  So it takes 10 
hours to get to level 20?  Then you start looking at how fast you kill them, 
etc.

 It could make some sense that for dungeons, most of the trash monsters are 
worth very little experience, but the final end monster is worth a lot - more 
than it should be worth from a pure monster perspective, but that basis is more 
of 'this is the reward for getting to the end'.  And one can then make a better 
guess on how long it would take a player of the appropriate level to get to 
that point.

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

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

[Mark Wedel]

On 3/11/20 11:08 AM, Kevin Zheng wrote:

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.


 I thought it was be slower, but for modern hardware, that is not very much 
(going back to the system that had 16 megs of memory, its CPU also run at 25 
mhz I think, so ignoring architectural differences, still clearly a lot 
faster).  Given those old system were maybe 100 times slower, that mean loading 
the map would take 200 ms, and given tick time hasn't really changed, that 
means lag.

 However, even in current architecture, this really isn't a problem - since 
objects are never freed, eventually the game gets to a point where it should 
enough have objects on the free list that it doesn't need to allocate objects 
very often.  So after the server first starts up, things may be sort of slow 
until it sort of reaches that point.

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

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

[Mark Wedel]

On 3/9/20 11:24 PM, Kevin Zheng wrote:

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.


 Crossfire goes way back (30+ years at this point), and the power/abilities of 
those machines back then were much more limited.  I think back then, the 
computer I was using had 16 megs of memory.  As such, things like memory 
consumption was much more a concern, and while memory usage has gone up (more 
stuff stored in the object, larger maps, etc), it has not gone up at the same 
pace as computer power has gone up.  So a lot of those old assumptions are no 
longer true.



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.


 This totally makes sense - as alluded to above, at one time, memory was 
constrained and one wanted to make sure crossfire did not use so much memory as 
to cause paging on the system it was running on.  In theory, MAX_OBJECTS would 
get tuned by each administrator, based on how much memory their server had, but 
I think that rarely happened.




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.


 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.

 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).



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.


 I suspect additional overhead should be pretty trivial, assuming the allocator 
is decent (and realistically, not much an issue anyways)



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.

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

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

[Mark Wedel]

On 3/1/20 11:01 AM, Kevin Zheng wrote:

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.


 It makes sense.  In an ideal world, some of those files would get broken apart 
and be located with the relevant archetype (artifacts, formulae come to mind), 
like the treasures entry was, and then collected.

 The races was always a bit of a hack - it was put in as an easy way to set a 
group of races (eg, all undead) without going through and updating all the .arc 
files - in theory, that file should be redundant if all the race entries for 
the .arc files are set right, but I suspect there is more to it than just that.

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

Re: [crossfire] abil_burning_hands.arc face is spell/Cone/spell_burning_hands.base.111.png?

[Mark Wedel]

 Face names are unique.  The collect script goes through the arch directory, 
collecting all the .arc files, .face, etc.  It then builds the lib/bmaps file - 
if you look there, you will notice that there is no path in it.


 That file basically provides a mapping of face name to face number.  So if 
something uses foobar.111.png, the game looks to see what number it is.


 The client does not have the arch directory - rather, the server has a file 
with all the faces.  When that file is generated, it just collects all the .png 
files into one file (for speed) - once again, the path information is not needed.


So for your script, what would probably make sense is to parse the 
lib/bmaps.paths - that contains the full path names.


I'm not quite sure how the editor does it.

Also, it is not allowed to use the same face name for 2 different images - I'm 
not quite sure what will happen - I think collect may complain, but otherwise, 
it may depend on the order the directory tree is walked.



On 06/05/2019 02:21 PM, Bob Tanner wrote:
Trying match a face to the abil_burning_hands.arc and I do not understand the 
logic.


$ cat spell/Ability/abil_burning_hands.arc | grep -i face
face spell_burning_hands.111

My python code looks for the face in spell/Ability/spell_burning_hands.111.png
but it’s not there. Manually looking around I find the face in 
spell/Cone/spell_burning_hands.base.111.png


Given I have spell/Ability/abil_burning_hands.arc and "face 
spell_burning_hands.111" how do I know to look in spell/Cone for 
spell_burning_hands.base.111.png?


How does crossfire do this itself?

Take the face and search the filesystem for a match?

---
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



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

Re: [crossfire] Questions about archetype files

[Mark Wedel]

On 04/16/2019 12:38 PM, Bob Tanner wrote:

Got another question.

Is the name attribute not required?

Just 1 example I found.

The Dragon Guild object does not have a name field?


 If name is not set, it uses the name from the Object field.  So it is not 
required.




construct/town/dragon_guild.arc

Object Dragon Guild
face dragon_guild.x11
type 66
no_pick 1
move_block all
client_type 25012
end
More
Object dragon_guild_2
name Dragon Guild
face dragon_guild.x11
type 66
no_pick 1
move_block all
x 1
end
More
Object dragon_guild_3
name Dragon Guild
face dragon_guild.x11
type 66
no_pick 1
y 1
end
More
Object dragon_guild_4
name Dragon Guild
face dragon_guild.x11
type 66
no_pick 1
x 1
y 1
end


---
Bob Tanner| 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



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

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

[Mark Wedel]

On 02/18/2019 03:56 PM, bill billy wrote:

 > Anyone else have any thoughts on the archive/history length?

I personally think it should be unlimited. IMO to base a limit on time would 
prevent long term threads and to base it on the number of posts (i.e delete 
after 100 or even 1000) could cause important conversations to be forgotten.
Neither the mailing list, irc or the forums have such limitations so I'm just 
not sure why there should be one for Discord.


 Unlimited seems fine to me also.  Partly because trying to limit it to 2 
months may be difficult - whoever is logging it may purge those after 2 months, 
but if some other service is searching the web, finds them, it could cache them 
forever, and really be beyond the control of the initial logging service.


 It also seems to me that someone could take a chat log and post it someplace 
else outside of any logging service.  Is that against the terms, and what could 
one really do about it.  It does seem to me that occasionally this happens - 
someone cuts/pastes from IRC and sends it in an e-mail or bug report to provide 
context, and those last forever.  Though I may be confusing that with other 
projects - not 100% sure that has happened with #crossfire.


 Certainly worth noting somewhere the the chat is being logged, so it is not a 
surprise to anyone.

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

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

[Mark Wedel]

 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.


 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.


- 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)


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

Re: [crossfire] encrypting the connection

[Mark Wedel]

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.


 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.


 So what may make sense would be for the client to instead do an md5 hash or 
the like of the password before it sends it to the server.  This removes the 
above problem (server only has the hash).  The server actually doesn't really 
care - it just cares that the password that the client sends matches what it has 
stored away, so the client could encrypt it, hash it, whatever, and as long as 
the client is consistent, server is happy.


 To deal with legacy (non hashed passwords), the client could try to send the 
hashed password first for login.  If that fails, send the raw password.  If that 
works, prompt the user, asking if they want to switch to a more secure password 
measure, at which point the client just send the request to change the password.


 The only issue here is that once a client switches to a hashed password, you 
can't go back to a client that doesn't support it.


 This still isn't quite as good as encryption, as if that hash is compromised 
(packet capture or server compromise), it would let the person access that 
crossfire account.  And since people may be likely to use the same password on 
other crossfire server, this then gives them access to those others.


 One possible way to mitigate that would be that the client add some data to 
the hash based on each server, so every server would have a different hash, even 
with the same plaintext password.  The one issue here is that whatever is used 
most be consistent (if you used hostname, and it changed, that wouldn't work). 
And while the client could just randomly choose something and store it away, you 
have an issue if you are on a different computer, loose that special key, etc.


 (btw, with all of the above, I'm not saying that encrypting the connection is 
a bad idea, but that still doesn't fix the issue of the server having a copy of 
a plaintext password.  The server itself could of course md5 hash the passwords 
on its own, so that the plaintext is only stored in memory (briefly) during 
authentication.  Way back when, the server would crypt the passwords, but that 
wasn't very secure at some point, as a computer could full decrypt all 
combinations in not much time)



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

Re: [crossfire] Oldest character still in game

[Mark Wedel]

On 09/27/2017 10:16 PM, Robert Brockway wrote:

Hi all.  Just occured to me that this might be a fun question to ask.

I have a character that I started playing in 1995, Lars the Northman. Lars still 
survives on my server although he's been a dedicated DM character for a long time.


FWIW Lars has progressed through various changes in the game.

So how old is your oldest character, in real-world time?

Can anyone beat Lars at 22 years?

I understand that Crossfire was started in 1992, 2-3 years before I started 
playing it.  I guess that means that the oldest possible character would be 25.


 This got me curious.  Looking on my system, I find a character with the last 
modification date of Aug 9, 1997.  That is in a players.bak directory, so I had 
probably copied those as a backup at some point (I wonder how many hard 
drives/filesystems that file has migrated across)


 There isn't any way to tell when it was created, though I suspect it was when 
I first got involved, which I think was 1994.  Though I've not actually played 
that character in a long time, so I suppose it depends on 'still in the game' 
really means.


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

Re: [crossfire] Spellcasting skills definition

[Mark Wedel]

On 08/21/2017 05:49 PM, David Hurst wrote:
As stated, i'm trying to enhance the messages that players receive when learning 
spells. To make this more engaging I wanted to have a clear picture of what we 
all think these spellcasting skills represent. As a starting point I presented 
this list as a definition of what is *currently *in place:


Evocation - Spells that 
remove energy (cold spells, poison, draining?, depletion?)
Sorcery - Spells that create 
things (physical damage, food, strengthening)
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


You can check the above links to see what spells are currently available for 
each skill. I don't think the spells that are in the wrong place are not even 
remotely going to cause balance issues. Large bullet moving to sorcery is not 
going to break evocation which currently has all of the cold spells to level 
with including icestorm at level 1. Ball lightning moving to pyromancy isn't 
going to wreck evocation.


Having said that, I had this thought as I was writing the text for evocation and 
it dawned on me that I have no idea what evocation actually is. Ruben pointed 
out (and I agree with him) that the current spells don't line up very well with 
historical definitions of evocation and 
sorcery . As far as I can tell it would 
be straightforward to flip all the spells in the two skills over so that we have:


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


 The definitions can be hard to map, because in dungeons of dragons, things 
like fireball, lightning bolt, and almost all damage spells are in the 
'evocation' school (they have different and more schools, so there isn't a 1:1 
mapping)


 As Leaf noted, in the past, there was some issues with balance in schools - 
sorcery didn't have enough damage spells, so was hard to level.  Note that there 
also isn't any reason that there can't be some overlap in those skills - 
certainly the reason that there was pyromancy in addition to evocation is all 
the fire spells got put in evocation, it would have been an overly good skill. 
And in some cases, I think there is basically the same spell (with slightly 
different name) in multiple skills.


  I'm not sure if you are looking for definition only, or if you plan to move 
some spells to different skills.  If the former, it will probably be hard to 
really come up with too good a definition that covers everything for the reasons 
above (this spell matches pyromancy definiton, why is it in evocation, etc).


 If you are going to move spells around, you could also rename the skills if so 
desired at that point to have better mapping (not that I necessary have better 
ideas for new names).  I think summoning is the most well defined and clear cut. 
 But there are also some spells which got dumped into sorcery as it was 
basically the catchall for anything that did not fit evocation, pyromancy, or 
summoning.


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

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

[Mark Wedel]

On 07/30/2017 10:22 PM, Kevin Zheng wrote:

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.


 My experience in the past is most of the time is finding out something was 
done but some part missing with respect to the release (eg, a file not added to 
the makefile so it ends being in the source repo but not the tar files built)


 It used to be that 'make archive' was all that was really needed - it would 
make the tar file, then uncompress it, run configure in that new directory, run 
the make, make install, and verify none of that got an error.  That's about as 
automated as something can get.


 The one thing that could be improved (though I don't thing SF supports this) 
would be doing that after every commit (or once a day or something), so if a 
file is added but missing from a makefile or whatever, it is found at that time, 
and not when you go off to make the release.





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

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/25/2017 08:18 AM, Matthew Giassa wrote:

My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though?  What is the minimal unit/"tick" of time the server uses?


120 ms is the tick time.

 However, spells (unfortunately), do not move that simply.  If one takes a cone 
(simpler) that is cast to the right, it becomes


 / (a)
-- (b)
 \ (c)

 So on the next tick, when a moves more, it adds an object in the same 
direction (upper right) as a, as well as an object directly right.  Object b 
creates 3 new objects (in directions/spaces a,b,c), and c creates another one in 
c direction as well as b.


 A nice side effect of this is that something in the middle of the cone takes 
more damage at the edges, becaus there are more damage causing objects in the 
middle.  But it means that for an even modest sized cone, it can be a lot of 
objects (there is some merging logic, but a lot of these can not be merged.


 A better approach, would be that when that cone is cast, an invisible object 
is put on the map at the origin point that records various import details 
(direction, how long, etc). Then, each ticket, it just extends the cone to the 
next space as needed, inserting only the objects as needed on those new spaces. 
Then, the number of objects used would match exactly the number of spaces the 
object is on.


 Merging may not be possible, because of different durations (the first fire 
effects would burn out before the second.  Though this could perhaps even be 
handled by recording that information in each effect, eg, a fire object may 
contain data saying it does 20 damage and burns out in 8 ticks, but within that, 
says 6 damage burns out in 5 ticks, so that for the last 3 ticks,the spell does 
14 instead of 20, etc.


 But none of that is a trivial change.

 I'm not quite sure why the bandwidth would go that high - the map information 
is tried to be done efficiently (only send changed data, and each map space 
isn't a huge number of bytes).  However, I suppose if the fireball is killing a 
bunch of creatures and burning up a bunch of objects, the map is actually 
changing considerably.




Finally, does the server employ any sort of compression when sending out
this data, or is that impractical in such a case?


 I think this was investigated, but never done.  One has to make sure that 
adding the compression does not add more latency, which may mean that there are 
many small chunks of data compressed.


 Note also that bandwidth used is going to be pretty directly related to the 
size of the map - a 25x25 is going to use up about 4x the bandwidth of a 13x13 
in highly dynamic content, simply because it has that many spaces.




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

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/23/2017 04:56 PM, Rick Tanner wrote:

On 6/23/17 10:02 AM, Matthew Giassa wrote:


Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a test load (i.e. a few users/players)?


Disk space needed for (trunk only) source content:

arch = 124M
server = 39M
maps = 549M

After compiling the server:

arch = 124M
server = 163M
maps = 549M

I have some stats in regards to server resources. This is with Ubuntu
16.04 with 6 players running around various maps.


 Disk space (and memory use) is pretty minimal for modern systems - the game 
goes back 20+ years, and while it has grown, it hasn't grown as much computer 
resources has.




From my observations...

crossfire-server requires 30.0 MiB of RAM to run when idle according to
the server host System Monitor.

Each player connected uses an additional ~3 MiB of RAM/ea just to move
around and interact with the game world.

When a player with hundreds (or thousands) of items in their apartment,
guild maps, et al. first enters such a map, RAM utilization jumps
dramatically. At the moment, I don't have a way to quantify these numbers.


 There is a sizeof command you can run, that dumps the sizes of various objects.

IIRC, each object was ~500 bytes (sizes can also vary based on 32 bit/64 bit or 
other factors).  A world map (50x50) perhaps has 5000 objects on it (2/space), 
but pretty easy for apartments or guild halls to easily exceed that.




Each player requires/uses about 10 KiB/s of bandwidth. Some maps with
lots of spell casting and monsters (i.e., Tower of Demonology, Hanuk)
causes this to spike as high as 10MB/s or more while that map or spell
effects are taking place. In a recent test session, I missed tracking
total bandwidth sent and received.

Highest use of CPU appears to be calculating damage from spell effects
(especially comet and meteor) and/or magical attacks (dragons and large
lightning or large ice storm, etc.)


 Yes, this is a problem with how the spells propagate - one spell can easy make 
hundreds or perhaps thousands of objects.  That in itself may not be bad, but 
the insertion of each object and interactions with other objects chews up that 
cpu time.


 The other issue is that the game is only single threaded, so a massive spell 
burst (or loading a big map) slows everything down.  20 years ago, multi cpu 
(now core) systems were pretty rare, now they are commonplace.  However, making 
the server multithreaded isn't a simple change.


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

Re: [crossfire] Release proposal

[Mark Wedel]

On 06/22/2017 09:06 PM, Kevin Zheng wrote:

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.


 No objections from me.  I have to admit that I've gotten sidetracked on other 
projects and really don't spend much time on crossfire anymore.  I should 
probably transfer the admin/ownership rights in sourceforge to you or someone 
else that is more active than I am.



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

Re: [crossfire] m7 output like this?

[Mark Wedel]

On 08/31/16 11:18 PM, Rick Tanner wrote:


Does anyone know how to make the m7 output/dump of the server in this
fancy of HTML format?

http://www.metalforge.net/spoiler/index.html
http://www.metalforge.net/spoiler/Arrow_of_Assassinating_Trolls.html

I could not figure it out with information I found.


 I don't see any scripts, etc, with the crossfire server directory itself to 
generate those.


 The -m7 dump will generate most of that data (eg, exp, difficult, skill, etc). 
 However, it only generates data for which recipes exist to make it.  The main 
table listed also contains ingredients which you find (do not make), and which 
are not dumped by -m7.


 So there must be some scripts that someone wrote to generate that, but they 
don't appear to be part of SVN



___
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

[Mark Wedel]

On 04/ 2/16 11:27 PM, Robert Brockway wrote:


One of the main issues is that to open such files, a popen (instead of fopen)
was necessary, so this littered the code with checks based on if the file was
compressed, it had to record if the file was compressed (so when it saved it,
it saved it as compressed), and also dealt with the potential of of many
different compression methods (compress, gzip, bzip, now xzip, etc).  It was
removed to make the code cleaner, which is a good thing, and at the time, the
given size of maps (and other data) wasn't large enough to be a concern.

Also, at the time, it allowed all files to be compressed (archetypes, player
files, etc).  Certainly allowing it only on map files would be limit the
number of places that code would be needed.  Other assumptions could be made,
like if compress is set in configure, then assume all map files to be opened
will be compressed, and all map files saved will be compressed (thus, do not
need to record at time of reading if the file was compressed and what it was
compressed with).


What I was thinking about was quite a bit simpler.  Try to open the uncompressed
map file as normal.  If that fails try to open the same file in the same
directory with extension .xz compressed with the xz algorithm (or subsitute
another similar compression algorithm to taste) while keeping all temp files
uncompressed.


 That is more or less what the old code did - however, there was the potential 
of several possible compression method used, so it would have to try .xz, .gz, 
.Z, etc.


 With availability of compression libraries, if this was to be redone, that 
logic might be different - instead of calling popen, if the server found a .xz 
suffix, it runs it through the xz decoder.  However, it still has to record that 
the file was in fact compressed when it read it in, so it needs to write it out 
compressed.


 Doing it with a library is certainly better - I have to imagine the overhead 
of running an external program to do the compression could not have been great.




The editor would need to know about that too of course.


 That might have been another reason the old compression logic was removed - 
possibly the java editor did not support it.  Back with the old C editor, it 
used the same function to read the maps as the the server, so if the compression 
was supported, crossedit would also support it.  That certainly does not exist now.





Fair point, but you are sort of an edge case on this, which is to say, a
feature really only one person would probably use.


If 1000x1000 maps became standard in the game (or at least a supported ad-on) it
could be common.


 True, for certain cases (eg, those where the cost of 100 GB of storage is 
significant because of hosting costs).  Or I guess if someone is running all on 
an SSD, it may not be particularly large, so chewing up 100 GB of it with map 
data may not be ideal.




I wonder if it is possible to do it with a plugin using Mapload or Mapenter:

http://wiki.cross-fire.org/dokuwiki/doku.php/server_plugin?s[]=events#hooking_to_global_events


If so the uncompressed map could be cleaned up by Mapunload or Mapreset.


 Maybe - it is possible that these could be done outside, eg, before the map is 
loaded, it decompresses the map file so that the uncompressed map file exists. 
However, I'm not exactly sure the timing of those functions - for MapLoad, it 
would have to be done before any work on loading the map is done, and I suspect 
(though could be wrong and am too lazy to look at the code now), that event may 
be generated after the map is loaded but before anything is done with it (thus 
scripts could make certain changes to the map or do other special 
initialization).  Likewise, the MapUnload may be done before the map is 
unloaded, so global events could do certain cleanup.


 However, I would expect performance to be worse in this case, even if 
possible, as basically it would have to call an external program to decompress 
the map into a new file, and then the server reads in that file.  That triples 
the I/O - now granted, it probably all remains in the file cache, but certainly 
less efficient than just decompressing it as it is read in.




Back to the mega map, one thing that was thought of back in the past was to
unify the scale.


When I was considering what to do with my new world a few months ago I went
through the archives and found a discussion on this topic.  I felt there were
some good argument against having buildings at the same scale as the bigworld
map.  In particular there was a concern about the ability of characters to see
the buildings properly.  This seemed like a strong argument to me.


 It would certainly make relations of buildings harder.  However, in some ways, 
it would also make buildings easier to find - on such a huge world, it would be 
pretty easy to miss a castle in the now much larger forest, etc.  On a single 
scale, you'd probably find the castle wall - may 

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

[Mark Wedel]

On 04/ 2/16 09:49 PM, Robert Brockway wrote:

On Sat, 2 Apr 2016, Mark Wedel wrote:



I presume the 1000x1000 maps are 50 (or some other size) spaces/side?  Or is
each map 1000x1000, but you have some smaller set of maps being tiled together?


Yes I'm using 1000x1000 maps, with each map being 50x50.  While I'd been reading
C and Python code I'd come to suspect there were implicit assumptions that the
world tile maps would be 50x50.  Yes this could be fixed but I found it easier
just to stick to the existing standard.


 I would hope that there are not any such assumptions (the relevant sections of 
code could just look at the maps and see how big they are), but that of course 
doesn't mean that such things don't exist.  Certainly the generic tiling logic 
doesn't have any size assumptions, because I believe there are some other maps 
(non world) which are tiled, and those probably are not 50x50.


 I suppose doing a 'grep 50 ...' would see if anything hard codes in the value 
of 50.


 As cpu power and memory increases, some assumptions made when things were done 
may no longer be true.  each map being a 100x100 tile (while having 4 times the 
number of objects) would probably be fine on current hardware, in both cpu and 
memory standpoint (going way back, I remember when 16 MB of memory was a good 
amount of memory0




It's worth noting that the name of the new world is Quadra and I've layed the
tiles out in a directory tree to avoid the issues of having too many files in a
single directory.  So the map tile for maps 117,117 on my new world is:

/worlds/quadra/117/117/tile

I've written a script which take the tiles generated by 'land' or 'bigland' and
sets the tile paths correctly.  I have special plans for the edge maps which are
worth their own post some other time.


 Yes, 1,000,000 files in one directory (depending on filesystem) may not work 
well.



As far as compression goes, at one time, the server did support map (or
really, all file) compression.  However, the typical size of an entire


Any chance it could be put it back in, even as an optional component enabled in
the config?


 I don't remember the details (I'm not the one that removed it), but it was a 
config file option.


 One of the main issues is that to open such files, a popen (instead of fopen) 
was necessary, so this littered the code with checks based on if the file was 
compressed, it had to record if the file was compressed (so when it saved it, it 
saved it as compressed), and also dealt with the potential of of many different 
compression methods (compress, gzip, bzip, now xzip, etc).  It was removed to 
make the code cleaner, which is a good thing, and at the time, the given size of 
maps (and other data) wasn't large enough to be a concern.


 Also, at the time, it allowed all files to be compressed (archetypes, player 
files, etc).  Certainly allowing it only on map files would be limit the number 
of places that code would be needed.  Other assumptions could be made, like if 
compress is set in configure, then assume all map files to be opened will be 
compressed, and all map files saved will be compressed (thus, do not need to 
record at time of reading if the file was compressed and what it was compressed 
with).





installation was small enough on current hard drives, there really wasn't much
point to it (even 100 GB isn't that big for modern systems).  Also, some


I am looking at hosting my server in Linode or a similar service but I find the
cost of 100GB hosted is more than I want to pay on going to run a game server.

I could cut the world down to 500x500 maps and add the rest back when the cost
of storage drops but I'm hoping not to have to do that.


 Fair point, but you are sort of an edge case on this, which is to say, a 
feature really only one person would probably use.





newer filesystems (ZFS for example) support compression, eg:

NAMEUSED  RATIO
export/home/crossfire  18.0G  2.09x


FreeBSD?  Few will be using ZFS on Linux I think and I'm not trusting my data to
Btrfs just yet :)  There seems to be a FUSE option for on-the-fly compression
but there are concenrs about stability.  Other than that I think Linux users
have few options for on-the-fly compression but happy to hear about options I
may have missed.


 ZFS on Solaris.  I've not looked at the state of other filesystems on linux - 
I would have thought that there would be other transparent compression methods 
for linux, but could be wrong.




If we applied the map compression in the application it would work on any OS
that the game runs on.


 I think there was some added complication to that compression logic when the 
server was ported to windows, but may be misrembering.  But as noted above, this 
wasn't a widely used feature, which was why it was removed (I don't recall 
anyone at the time caring it was removed).




I compressed a few random tiles from my new world and got compression rations
ranging from 6:1

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

[Mark Wedel]

 I presume the 1000x1000 maps are 50 (or some other size) spaces/side?  Or is 
each map 1000x1000, but you have some smaller set of maps being tiled together?


 With map tiling, things can move to adjacent maps even if players don't move 
to them.  The game doesn't really distinguish between objects, and just as you 
wouldn't want an arrow to stop at a map edge, same goes true for monsters.


 What should eventually happen is that maps with no players on them will get 
swapped out.  However, what probably also happens is that maps that are still in 
memory are touching the other maps, keeping them active, so this never happens 
(at least in the case of mice which keep multiplying).  One could have a monster 
that just wanders and moves to a new map, but it would eventually get swapped 
out if nothing else is keeping the map it is on active.


 As far as compression goes, at one time, the server did support map (or 
really, all file) compression.  However, the typical size of an entire 
installation was small enough on current hard drives, there really wasn't much 
point to it (even 100 GB isn't that big for modern systems).  Also, some newer 
filesystems (ZFS for example) support compression, eg:


NAMEUSED  RATIO
export/home/crossfire  18.0G  2.09x

 (that is all my crossfire stuff - sources, binaries, etc, so size is reduced 
by 50+%)


 Also, I'm not aware (though may have missed it) of client side map caching. 
But even if that did exist, at least as far as the protocol goes, transmission 
of map data is much more efficient in the protocol that the method used in the 
map client itself.  In the protocol, its probably around 6 bytes/map object 
(with some additional overhead to note the space, darkness, and a few other 
attributes).  Where as in the map file, a pretty minimal object is something like:


name grass
x 5
y 5
end

 Which is going to be 20 bytes.


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

Re: [crossfire] Qt experiments

[Mark Wedel]

 Just my one slightly relevant data point on Qt:

 The few times I compiled Qt for Solaris, it was a lot of work.  Its been a 
while now, but some of this was the large number of dependencies to install 
before compiling Qt, but Qt itself had some oddities.


 That said, the number of people running the server on solaris is near 0, and I 
don't think it even compiles right now due to changes/removals of various checks 
from configure (in most cases, there was a reason behind why those checks where 
put in the configure scripts in the first place).


 But my thought is that if some new platform (non linux/bsd/windows) shows up 
and someone wants to run the server on it, from my experience above, using Qt 
may be as much a hindrance as a help.


 And while there is some amount of platform/OS specific code in crossfire, it 
is fairly minor and probably a fair amount of the remaining bits could be 
cleaned up.  The computer world is much different now than it was 20+ years ago 
(when there was a dozen different varieties of unix, POSIX standards were not as 
complete, etc).


 My personal philosophy when I had time to spend time on crossfire was to try 
and keep the dependencies that the server needs to a minimum, simply because in 
many cases, the environment where the server would run had a more minimal 
installation or were a loaned resource such that it wasn't easy for the person 
running the server to install additional dependencies.



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

Re: [crossfire] Shop prices overhaul

[Mark Wedel]

On 11/30/14 11:00 AM, Kevin Zheng wrote:

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 shops (and economy) in crossfire have many problems, many have been 
discussed before, so I won't restate them, but I think any change is just going 
to be one piece of the puzzle.




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.


 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).


 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.


 I do think that having stats  skills affect buy price is a good improvement - 
high level players tend to have more money than they can do anything with and 
never buy anything, so therefor, don't really see the advantage.




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.


 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.


 For those not looking at the patch, it appears to be that the character will 
get best price if their charisma is 30 or they have maximum bargaining level (or 
some combination in between (level 20 bargaining and 25 charisma would appear to 
do it also)


 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.


 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)


 Otherwise, looks good to me.

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

Re: [crossfire] Game change proposals

[Mark Wedel]

On 07/ 6/14 11:57 AM, Bloody Shade wrote:

I also found it a bit hard to identify where each section ended, which made the
minigame a little confusing in the beginning.

I'm also worried about the frequency of this and other minigames that might
arise from these changes, while they can be fun when used in very specific
situations, otherwise they just compromise immersion by forcing you out of the
main game focus.
Much like how modern games are plagued by quick time events, which are anything
but a good thing, and I'd hate to see crossfire fall to the same trap.


 I know some other games have an idea of you can either play the minigame (at 
which point it is largely player skill and the character skill makes it easier), 
or a quick 'use character' skill type thing which is probably less prone to 
work, but also very fast (and in the case of failures, lockpicks break)


 From the initial description, it sounds like each pick has 2 ends, and the 
player also has to choose which end to use.  I also wonder if that complication 
is worth it - each pick having a single end so no rotation is necessary would 
seem to keep the game the same, but make the interface/play simpler (an as an 
aside, it would seem like this type of thing would need some client support, and 
I could certainly see a client basically breaking apart the lockpick into its 
two halves, rotating one of them, and when the player clicks on one, determines 
which pick that is and if an orientation change is needed)


 Of course, with all that talk, I then wonder how long until someone makes a 
'lockpicking plugin' for the client which just figures out everything on its 
own.  Though that becomes more a player choice thing, as with enough plugins, 
the game can play itself.


 One other question - in the example you give, there are 5 components that need 
to be picked.  Presuming lockpicks need to be found/bought, if the character is 
lacking one of the picks, are they just out of luck?




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

Re: [crossfire] Game change proposals

[Mark Wedel]

On 06/14/14 02:17 PM, Nicolas Weeger wrote:

Hello.



   I'm not familiar to the original game, but I'd be careful with anything
that is too time sensitive.  I'd also like a better idea of what you
envision.  Is it something like there are 10 (or 20) different lockpicks
in the game, and the character has to use them in the right order?
Presumably, the lockpick skill should still come in to play in some way
for this also (amount of time to pick the lock, or perhaps some amount of
not needing the precise lockpicks or something)


Something like that, yes - you need to use the correct lockpicks in the
correct order.

So you could have special doors requiring a special lockpick found in a
special place.


 Makes sense - would the lockpicks be consumed (or perhaps break) on failed 
attempts?  That might be another way to limit special door access - yes, you can 
pick it, but the lockpicks themselves are rare and/or expensive, so may not be 
worth it just for the sake of doing it.




   That is a big change, and probably fairly simple to do - most other games
do this (those creatures may be attacking you with axes, but you don't get
all those weapons when you kill them).  Likewise, even of the items that
are out there, one could reasonably ask do we really need the number of
different swords out there that vary by a minor detail.  I know some games
do this, but that is more related to skins (this sword looks cool) - with
the way crossfire is, that really isn't the case.


I was thinking of adding a second treasure list to monsters, which contains
items to drop at death.

Would need to figure how to make steal work, though.


 I had thought of the second treasure list - the problem, is you could get a 
case where the creature is firing arrows at you, but drops something completely 
unrelated.  Other games do that (often getting items completely unrelated to 
what the creature is using), but IMO, it is nicer if what is dropped matches 
what the creature had.


 I know sometimes in crossfire you are fighting something and getting hit by 
some wand attack, and I think 'I want to kill that creature to get that wand'. 
With the proposed system, that might not happen, but would be nice to have a chance.


 So perhaps what could be done is the existing treasurelists modified with 
something like a 'drop_chance' value - if the item is generated, that represents 
that chance that the item actually drops.  At treasure creation time, the item 
could get marked with a flag based on that (I think FLAG_NO_DROP might already 
exist)


 That chance may be low, but at least you have a chance of getting what the 
creature is using.  For stealing, I think only allow items that will drop when 
the creature is killed to be stolen works, so that also fixes that problem.







   That would be good, but is also a major change - the vast majority of
maps would need to be refactored (maps with gobs of monsters would just be
unplayable).


Yes. On the other hand, it'd make for a nice map review :)


 Right - in some ways, it makes sense to do a bunch of big changes at one time 
for that reason - while reviewing maps for monster density, can also review them 
for doors, etc.







   Seems reasonable, though than in itself creates yet different issues (if
a player can use a weapon effectively enough to constantly keep a monster
stunned, probably makes for an easy combat)


Then the monster isn't that high level, is it?


 I guess it depends exactly how those chances work.  Is it a level comparison + 
random factor?  or you do the attack and it happens?




Or make it so the time the player needs to launch the stun attack is longer
that the actual stun.


 Yep - some games also have other melee related stats (fatigue, adrenaline, 
etc), and one could imagine that the special attacks cost more fatigue, and 
fatigue only really recovers out of combat - so you could enter combat, do a 
flurry of special attacks, but after that, are basically just left doing normal 
attacks or something.




   Agree - most of those are side effects.  The trickier part on some of
those is whether resistances should exist and how to then factor them in -
the number of attacks and number of resistances sort of go hand in hand.
While one could certainly come up with different logic to handle those,
that solution may just be more complicated.

   Note that if you did all the above changes, that is some fairly radical
changes to the game (attack rate and item drop). Though perhaps the second
comes from the first - if combat is a lot slower, that would then suggest
there are a lot fewer monsters, which should then mean a lot lower item
drop.


Yes, radical changes is what I'm thinking of.

There are a zillion hack-and-slash games. So maybe we should try something
different?


 Maybe - that has always been a bit of challenge - trying to figure out exactly 
what crossfire is or should be.



___
crossfire mailing list

Re: [crossfire] Crossfire should use Git

[Mark Wedel]

On 06/14/14 11:30 AM, Kevin Zheng wrote:
snip

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.


 True - a DVCS certainly makes it easier to have/make multiple unrelated 
changes and make them available as individual patches (presuming good practices 
were followed and the developer remembers to check them in their local repo 
separately).


 I also think DVCS is also better if one is making really big changes that will 
take a while to do, because of the better branching, local commits, and merging 
- for something like SVN, you would pretty much need to make your own branch, 
which then also shows up in the main repo.




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'm not at all familiar with git, so I'm 100% how to compare the 2.

 I'm not 1005 sure why you would need many copies of the repository - there is 
nothing that prevents making a clone, making one set of changes, doing a local 
commit, making another set of changes, doing a local commit, and repeat as 
necessary.


 The only reason you would need many copies of the repository is if you were 
making different changes to each one - you could still do that with hg, but that 
seems like a somewhat odd way to develop code.


 Note you can reparent with mercurial quite easily - presuming there is a 
common parent, it is just a matter of doing 'hg pull newparent'.  You can 
likewise do the same with the push, but you need to be up to date relative to 
the parent (mercurial will make sure this is the case).


 All that said, at work, we use the cadmium extensions which provide some nice 
features like 'recommit', which collapses all the commits in the branch into a 
single delta which can be pushed later.  I'm not sure how available the cadmium 
tools are.  But whether people use extensions or not for mercurial doesn't 
matter much - those extensions are local to them, and the main repo doesn't 
really care.  So people can use whatever extensions work best for them.




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.


 The problem is that if I took that attitude several years ago, we probably we 
be on mercurial.  Crossfire is a community project, so has to meet the needs of 
many developers.  While SVN is pretty limiting, one thing it has going for it is 
that it is quite simple to use - non hardcore developers can understand and use 
git without much problem - from many of the other posts I've seen, that is not 
true with git (and mercurial for that matter).  So having something simple and 
easy to use has lots of advantages, with limited disadvantages (main one being 
that SVN is not a DVCS)




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.


 IMO, that may just be the simplest way to go - I understand it is more pain 
for you, but there is a fair amount of pain to switch what VCS crossfire uses (I 
did this one before) - aside from the different commands people need to know, 
everyone also has to point to the new repo, you have to make sure there are not 
any outstanding commits, etc.


 Plus, from the other people that replied, there clearly was not an unanimous 
chorus of everyone agreeing to a move to git - granted the number of replies was 
limited, but if anything, seemed to be more opposition to it than those in favor.


___
crossfire 

Re: [crossfire] Game change proposals

[Mark Wedel]

On 06/12/14 11:35 AM, Nicolas Weeger wrote:

Hello.


I'd like to change various things in the game, to make it funnier (IMO) in non
combat aspects. So here are random proposals.



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'm not familiar to the original game, but I'd be careful with anything that 
is too time sensitive.  I'd also like a better idea of what you envision.  Is it 
something like there are 10 (or 20) different lockpicks in the game, and the 
character has to use them in the right order?  Presumably, the lockpick skill 
should still come in to play in some way for this also (amount of time to pick 
the lock, or perhaps some amount of not needing the precise lockpicks or something)


 Of course, lockpicking and doors in general could use a bit of a revamp - too 
much is 'you must do the dungeon in this order, meaning get key A, which lets 
you get key B, etc'.  let those doors be pickable - perhaps they have really 
nasty traps if you don't use the key, or perhaps they are just really tough.


 This might require redesign of some maps (treasure room near the start that is 
protected by a locked door may not be a good idea), but would make more sense.


Another easy thing would be to have most chests locked - the player could bash 
them open, but might destroy the items inside.









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 don't mind so much the global experience, and I still like the idea of the 
alchemy skill itself having a level (until you get to level 10, some recipes may 
just not be possible).  But tracking individual recipes and bonus for each seems 
like a fine idea.


 It might also be reasonable that common/simple recipes are globally known (or 
are automatically learned at certain levels), so that the alchemy recipes out 
there are for rare and unusual items.  Otherwise, playing only with in game 
knowledge always seems very difficult.




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


 Totally reasonable for different things - one could certainly imagine that 
scribing at a desk should be easier than out in the wilderness.




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


 That is a big change, and probably fairly simple to do - most other games do 
this (those creatures may be attacking you with axes, but you don't get all 
those weapons when you kill them).  Likewise, even of the items that are out 
there, one could reasonably ask do we really need the number of different swords 
out there that vary by a minor detail.  I know some games do this, but that is 
more related to skins (this sword looks cool) - with the way crossfire is, that 
really isn't the case.


]

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.


 That would be good, but is also a major change - the vast majority of maps 
would need to be refactored (maps with gobs of monsters would just be unplayable).




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


 Seems reasonable, though than in itself creates yet different issues (if a 
player can use a weapon effectively enough to constantly keep a monster stunned, 
probably makes for an easy combat)




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


 Agree - most of those are side effects.  The trickier part on some of those is 
whether resistances should exist and how to then factor them in - the number of 
attacks and number of resistances sort of go hand in hand.  While one could 
certainly come up with different logic to handle those, that solution may just 
be more complicated.


 Note that if you did all the above changes, that is some fairly radical 
changes to the game (attack rate and item drop). Though perhaps the second comes 
from the first - if combat is a lot slower, that would then suggest there are a 
lot fewer monsters, which should then mean a lot lower item drop.



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

Re: [crossfire] Crossfire should use Git

[Mark Wedel]

 Whenever these discussions come up (this is probably the 3rd or 4th 
iteration), the general response is 'we should use the VCS that I'm most 
familiar with'


 So on that basis, I'd vote for mercurial (use it at work) or SVN (crossfire 
already uses it)


 All that being said, for the amount of commits crossfire gets, I'm really not 
convinced a distributed VCS is worth the effort.  It is certainly useful for 
really big projects, or if making lots of changes such that you want to be able 
to do intermediate commits.


 To me, the only really compelling reason for a DVCS is that all the data is 
local, so you can do things like diff, history, etc, and still get data even if 
the master gate is down.


 I don't think it will make much difference in terms of maintaining branches - 
all systems I've seen have problems once branches drift apart - at some level, 
manual merging is possible.  Its been a while, but I seem to remember that even 
for SVN, there was a pretty simple way to do that.  The main problem (in 
general) with branches is people just generally don't want to do the extra steps 
to backport, even if the steps were pretty trivial.


 I'm really not convinced that a bunch of branches are desirable thing - 
whenever extra branches have shown up in SVN, they basically just languished, 
and I don't think it was because of the VCS, but rather there are not so many 
developers that your going to have 10 people working on the trunk and 8 playing 
on a branch - rather, everyone just works on trunk.


 Conceivably, this can be useful if working on a private branch, but a DVCS 
really doesn't help prevent merge hell if the branches drift too far apart 
(conflicts still need to be resolved by hand), though I suppose with a DVCS, 
they would need to be resolved less often vs trying to use SVN.


 mercurial at least can pull from a SVN repo, as it sounds like GIT can, but 
the issue is the push.  I have no idea if git and mercurial can play well 
together (if the repo was mercurial, can git do most things it needs to do or 
vice versa).



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

Re: [crossfire] Crossfire server code cleanup/janitorial

[Mark Wedel]

Few general notes on this:

My idea if using new functions provided by libraries (if they exist) and include 
local copies if they don't is that often times vendor provided functions may be 
much better optimized that locally included ones.


 Also, for some functions (like strlcpy), it may be a trivial exercise to 
include a local copy of equivalent functionality.  But for others, like 
snprintf, it might be hard, but a simple replacement of non equivalent 
functionality is easy, like:


sprintf(buf, ...)
if strlen(buf)  buflen { oops, we have a buffer overrun }

 which isn't great, but could still be better than an alternative of just using 
an unprotected sprintf.


 I do tend to agree with the comment that given crossfire is C code, using a C 
compiler would seem to be the best tool to use to compile it.  That said, if it 
happens to compile with a C++ compiler, or changes are trivial to let it do so, 
great.  But I'd just put the responsibility of making sure it compile with C++ 
belongs to those who want to compile with C++, not all developers.


 I will also note that crossfire actually does a fair amount of floating point 
- all the speed and speed_left is floating point, the just simple 
addition/subtraction.


 The plugin logic has pluses and minuses - the ability to right plugins that 
register themselves is good, but the entire dynamic loading adds a bit of code 
complexity and another place for errors.  But also, at one time, the python 
plugin was optional, so you could run the server without necessarily having 
python  its development libraries installed.  But IIRC, at some point, it was 
decided that enough scripts and other stuff require python it should become 
standard - since it is known it will always exist, whether having it be a 
dynamically library that is loaded makes sense is debatable.




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

Re: [crossfire] Crossfire server code cleanup/janitorial

[Mark Wedel]

 Going back to to the original thread - certainly win32 is used, and I also do 
sun/solaris.


 I'm not sure if there is any conditional code based on platforms in crossfire 
- if there is, I would think most could be removed through proper configure 
checks (that code may predate the conversion to autoconf).  I suspect in the 
case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, 
no one would care.  But without knowing specific areas, support for those might 
also be part of support for other platforms (something like a #if defined(irix) 
|| defined(sun) ) or the like, so just removing irix doesn't do much.


 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.


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.


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.


I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - 
while there is lots of crufty code in crossfire, you'd really want to look and 
figure out how all the classes interact and so forth.  Otherwise, you may just 
end up with a C++ version of crossfire which is fundamentally the same, just 
written in C++.


 I'm always a bit concerned about rewriting stuff just for the sake of 
rewriting - while it may find (and fix) some existing bugs in the code, almost 
certainly more new bugs will be introduced.


 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.


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.




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

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

[Mark Wedel]

On 04/13/14 08:36 AM, Kevin Zheng wrote:

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.


 In theory, make dist should collect everything that is necessary (that said, 
all too often things tend to fall through cracks which are discovered at release 
time).





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.


 It is part of the build process because it is needed for the server to run.

 However, I'm not quite sure why we never did something like this in the 
Makefile:

 if [[ ! -e arch ]]; then
  echo No arch directory found - skipping collection
 else
  normal collect logic
 fi

 I suspect there is probably some makefile magic that could be done to fix the 
'gmake -j4' type issue - something to say that that single command is used to 
generate this file, so don't run multiple versions at same time.  Or perhaps at 
least for the lib directory, something that just explicitly disables 
parallelism, since nothing is really built in that directory.


 All that said, the collect logic isn't great - it doesn't have any way to know 
if the files in the arch directory have changed, so in that case, the server 
admin has to know to run an 'make collect' by hand if they know the files have 
change.


 There is also some different situation here from SVN vs releases - in SVN, 
there is no precollected files, so by definition, a collection will be needed - 
which is not the case for official releases.





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?


 I don't think it is worth the effort - I'd perhaps just put out a notice like 
'the lib/.collect-stamp file is missing.  Before compiling this release, do a 
'touch -t 201401010101 lib/.collect-stamp' and all will be good.


 That is such a simple workaround that it shouldn't be any problem.  For anyone 
making official binary releases, this won't be a problem in the release - just 
the packager will have to know this step.



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

Re: [crossfire] World generator (land.c) questions

[Mark Wedel]

On 02/11/14 12:56 PM, Rick Tanner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


snip

seed (-s) = ??

Random number used to generate the fractal? Is there a min and max
value that can be used?  Does higher numbers provide more land or more
water or neither? Higher or lower numbers for more jagged coastline or
more rounded coastline and islands?


 This is just used as the seed for the random number generator.  It does not 
directly affect the output of the maps in any predictable way.


 The main purpose of the seed is that if you use the same seed, you will get 
the same map (presuming size and other parameters are the same)




land (-l) = ??

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither? Higher or lower numbers
for more jagged coastline or more rounded coastline and islands?


There is a min value (11) which is enforced at run time.  Not sure if there is 
an actual max value that makes sense.  Basically, based on the size of the map 
(overall spaces), this randomly makes land number of spaces randomly lower or 
higher.  The default is 30.  Note that this is run also based on passes (-n).


 Note that each additional pass of land (-l), the the altitude amount will 
likely be less.  So if you do something like -l 20 and -n 4000, it will make 
make steep cliffs and the like.  Conversely, something like -l 2 -n 10 
will still have a lot of variation, but in general should be smoother (more 
rolling hills than cliffs)





passes (-n) = Make lakes and ocean trenches. General note - it works
better to have more passes, but each pass doing less work - this
results in more consistent lakes and ocean trenching. Found this
summary in either the write or source code.  No questions here.


 Note that passes and land (-l) play with each other.  The default (npasses = 
40, land=30) means ~12 million spaces will be modified.  However, 1500x1500 
is 2.25 million, so it means that on average, each spaces will have its altitude 
modified 6 times - sometimes positive, sometimes negative.


But the thing to keep in mind here is that the total number of spaces modified 
is -l * -n.  Note that the comment above is directly from the source, but 
applies to wpasses (-p)





wpasses (-p) = ??

What is this?

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither?

water (-w) = ??

Is there a min and max value that can be used?  Does higher numbers
provide more land or more water or neither? Higher or lower numbers
for more jagged coastline or more rounded coastline and islands?


 -p  -w work the same way as -n  -l, but instead of increasing altitude, it 
decreases it.


 On a simple bases, if land total (-l * -n) is a lot bigger than water total 
(-p * -w), you should get more land, and a lot more mountain peaks and so forth.


 If the opposite is true, the land should be flatter and you will have more 
water.

 Note that the land program is very simple and not realistic.  For example, if 
the finished altitude of a space is 0, then it is water, otherwise land.  And 
the type of land is based on the altitude of the space.  Which means you won't 
get high mountain lakes (quite common on earth), high prairies (low altitude in 
land.c is grassland), etc.




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

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

[Mark Wedel]

On 11/ 4/13 05:34 AM, Arvid Brodin wrote:

On 2013-11-04 07:38, Mark Wedel wrote:

On 11/ 3/13 03:03 PM, Kevin Zheng wrote:

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.


  True on both accounts.  Having per character keybindings take preference over 
global ones would be the correct approach.  However, in an ideal world, both 
are visible, so one could easily see the conflict and make adjustments.

  Note that it appears this patch introduces a new bug, as posted on the forums:

Posted: Sun Nov 03, 2013 6:51 pm
Post subject : Compatibility with new character-specific keybindings?
 I updated my trunk client to the newest version (r19093), which has the 
character-specific keybindings as a feature.
When I logged into Metalforge with the new client, absolutely no keybindings 
work (not even the default ones). Any keybindings I try to create go to a 
(null).keys file and do not persist to another login.
When I log into netarbeiter (1.70.0), my keybindings work fine.

Does this mean the newest trunk client is incompatible with the 1.12 branch? Or 
am I doing something wrong?
--

  I suspect the issue is that metalforge is running old code, which predates 
the new character login logic.  As such, the client never has a character name 
of which to load keybindings for (and I haven't looked, but depending on where 
the load actually happens, perhaps never load them at all.


The names of the characters are returned from the server as a response to
AccountPlayersCmd (if I understand correctly), then stored in
character_choose_window until play is started with a character, whose name
is then stored in cpl.name and is used for loading and saving the keys
file. If the name of the chosen character is NULL, that would be passed to
strdup().

No check is made since I assumed that it is not possible to start game play
without having a list of characters to choose from.

I just tried to login at metalforge and the game is instantly started with
the character dwarf the dwarf... I.e. the whole login process is skipped?

Can anyone describe to me how this works? (I can't test any more now, need
to get to work...)



 metalforge is running an older version of the server, so yes, all of that is 
skipped, and the server does not support the protocol command for the client to 
get a list of characters available to the player.


 So what you see is how it works - you enter the character name, and then 
password, and that is the login process.


 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.


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

Re: [crossfire] Use of svn:externals in client code on SVN

[Mark Wedel]

On 11/ 4/13 04:41 PM, Kevin Zheng wrote:

Hi there,

Crossfire currently uses svn:externals to sync protocol definition
headers between the server and GTKv2 client. While this has its merits,
overall I believe it is confusing, cumbersome, and harmful.

 From the SVN Book [1]: An externals definition is a mapping of a local
directory to the URL—and ideally a particular revision—of a versioned
directory. In Subversion, you declare externals definitions in groups
using the svn:externals property.

My guess is that the original intention of using them was to ensure that
the client protocol headers would always remain in sync with those in
the server. However, here are some issues:

  - The svn:externals property must still be modified manually
  - Copy/paste/merge is faster, less confusing, and works outside of SVN
  - Client sources locked to server, JXClient proves unnecessary

Further, there are several disadvantages to using them as well:

  - It only works with SVN - hinders future migration (if ever)
  - Confusing for people not familiar with SVN
  - Slow, try running `svn up` from the root and wait
  - Breaks `git svn`, which pacifies the impatient Git users

I propose that we go back to manually tracking the protocol headers
between the client and server. They are not updated that often, anyways,
and still need updating with the use of svn:externals. We can continue
using svn:externals in /latest, etc.

[1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html


 That is fine by me.  And before the externals was set up, my method of sync 
wast just a cp from one directory to the other.


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

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

[Mark Wedel]

On 11/ 2/13 08:14 PM, Kevin Zheng wrote:

On 11/02/2013 11:04, Arvid Brodin wrote:



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).


 But to me, there is very little reason to merge them - the common area vs the 
specific graphic area are pretty well abstracted apart.


 And while right now there might only be one graphics client that uses it, if 
they get merged, that pretty much would mean that would always be the case.


 In terms of history, early version of the client only had X11 client support - 
the fact it was separated made it possible to have different GUI clients at 
different times (gtkv1 vs gtkv2, and I think there was a gnome client at some 
point).


 Now whether there will ever be new graphics system ever added the the C client 
(vs java), who knows, but off the top of my head, I could think of several 
platforms where a native GUI client could be written, and who knows what changes 
may show up even on the unix desktops which might bring forth a new client with 
new toolkit.


 If there are specific issues or problems trying to be addressed by merging 
them together, that would be good to hear (and perhaps could be fixed without a 
merge).  But just merging them for the sake of merging may not be good long term.


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

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

[Mark Wedel]

On 11/ 2/13 04:31 PM, Arvid Brodin wrote:

Today, keybindings are saved as ~/.crossfire/keys. That means you
cannot have different key bindings for each character.

This patch changes that so that keybindings are saved as
~/.crossfire/character-name.keys. So if your character is named
Leopold, the keybindings are saved to ~/.crossfire/Leopold.keys.

When play is entered with a character, the client tries to load
keybindings in the following order:

~/.crossfire/character-name.keys
~/.crossfire/keys
client_libdir/def_keys

If none of the files are found, it instead uses the default built-
in keybindings.


 Just a question - is there any way to set up 'global' keybindings (eg, those 
that apply to all characters)?


 From my reading above, which may not be correct, it suggests that once it 
finds a matching keys file, it won't go to the next one (so if you have a 
foobar.keys file, it will load that and won't load anything you have set up in 
keys).


 I'm not sure how prevalent it is, but I know for myself that I have some 
keybindings that would apply to all characters, and it would be a bit of a pain 
to re-enter them each time a new character is created (now I suppose this can be 
done as a manual process of having a template file that I manually copy over as 
I make new characters)


 That said, certainly have per character keys file is also a good thing, since 
a lot of things are per character.


 My only thought here is that it loads up ~/.crossfire/keys regardless, but 
values in char name.keys override any settings there, and in the bind window, 
have an option for the keybinding which is something like 'global (all 
character)' option.



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

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

[Mark Wedel]

On 11/ 3/13 06:50 AM, Arvid Brodin wrote:
snip


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


 Some of those still can apply for later sun keyboards (using a type 7 here). 
Since later keyboards are USB, they work fine on PCs also.


 I suspect the F ones can certainly go.

 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.




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?


 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)




- 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.


 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)


 Certainly help text could be updated.  I wonder if they could be bound to page 
up/page down by default (for keyboards that have that - see notebook issue 
above) - this way, they will still apply in keybindings for all users, so people 
could rebind them to other keys as they see fit.


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

Re: [crossfire] Key repeat and keybindings

[Mark Wedel]

The protocol has improved since those were put in.  The client should be
able to better watch the number of acknowledge commands and send or not
send commands as appropriate.  Note per my previous mail, the next
enhancement that would be nice would be for the server to look at all
commands, and in addition to having priority, there could be something like
'cancel are north commands', such that when the key is released, that is
sent to the server and the server does just that.  That said, even this
gets tricky - you don't want to cancel the a single command that was sent,
which might mean the client has to know if multiple commands have been
sent, and which ones.


If the client waits for the acknowledgements before sending the repeat, isn't
there a risk that we handicap players with a high network latency? If the
acks are sent from the server immediately upon reception of the command,
perhaps this wouldn't be so bad in most cases. If the ack is sent after the
command has been executed, it would be a big problem.


 This is what the 'command window' property controls (comc/ncom protocol 
commands)

 Basically, the client won't send another command to the server if more the X 
commands are outstanding (have not been processed).  The problem here is just as 
discussed for other issues - the client is not smart in what command 
should/should not be sent (that apply healing potion may be a bad one not to send)


 The default for the command window is 10 IIRC, which means that the client can 
have sent up to 10 outstanding commands to the server.  In general, that number 
is too high, but can be easily set in the client.


 Note that this command acknowledge did not exist for a while in the protocol - 
the run_on/fire_on predate the existence of that feature.






This reduces the server having to remember more state.

In terms of what commands should repeat and what should not, this could
probably be an option in the keybind menu, eg, 'repeat?' which notes if the
command should be repeated or not.  Probably also allow it in the
keybindings itself, because for some commands, there may be desire to
repeat them in certain circumstances and not other (apply immediately comes
to mind in certain cases, like eating a lot of low value food, but not in
others, like using exits)


This is a great idea! It would also solve the problem with deciding whether
to cancel a queue of commands or not - only on releasing the key of a
repeating command should a reset queue command be sent to the server.


 And more specifically, rather than clear the entire queue, it would be 'clear 
the queue of the command that was just repeating'.  You could have a very real 
case of a character moving in some direction and the player hitting another key 
to do something without releasing the movement key (if fire_on is removed, it 
could be something like holding down the up arrow, so north is getting repeated, 
and then player sees a monster, hits shift so arrow is fired, and then releases 
the up arrow (player is waiting for monster to approach) - in that case, you 
don't want to lose that the player fired north.




I'd certainly say it is worth it to post it or upload it to sourceforge on
the tracker.


Which is the preferred method? I'm used to sending patches inline in emails;
the sourceforge tracker is new to me.


 If you think the patch is ready for inclusion (vs say demonstration code), 
then I think the tracker is the right place.  It should be pretty simple - it 
just lets you upload a file after you create the item to track.


 This is especially good if the patch is long, as sending it to the entire list 
may be a bit much, yet at the same time, more than one person may want to look 
at it.


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

Re: [crossfire] Key repeat and keybindings

[Mark Wedel]

On 10/25/13 04:59 PM, Arvid Brodin wrote:

On 2013-10-24 07:19, Mark Wedel wrote:

On 10/23/13 06:53 PM, David Hurst wrote:

Hi Arvid,


Hi!

[]


A lot of this has to down how keys are handled, at least on x-windows.

If you could down the control, shift, or other modifier keys, a single
event is generated - that the key has been pressed, and another event is
generated when the key is released.  This is all done in the x-server - at
a level beyond the client.

For other keys, autorepeat kicks in.  So if you hold an arrow key, the
x-server is generating numerous key press/key release events, which the
client then sees and takes as different key presses.  Best I know, there
isn't an easy way to know if multiple key presses are a result of
autorepeat or if the player is actually pressing and releasing the key (as
a side note, for myself, for things like search, I would just hit the s key
5 times to know how much I'm searching)


I did a test of this. In the client key press events are handled by keyfunc()
and key releases are handled by keyrelfunc() (both in gtk-v2/src/keys.c).
They are not x-server events but rather GDK events. I added a simple printf()
at the beginning of each to see what kind of events are generated for
different keys.

For Ctrl, the result is as you say:

key pressed: Control_L held key generates no new events key released:
Control_L

For auto-repeating keys though, there are no release events between the key
press events:

key pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key
pressed: KP_2 key pressed: KP_2 key pressed: KP_2 key released: KP_2

So keeping state for each button would be easy. It's also easy to see if a
key is actually pressed several times vs being held down. (Maybe focus in/out
can make things a bit more difficult, but not a lot, I guess.)



 Interesting.  So I'm guessing that gtk must capture some of the events.  If I
run xev, I do see key press/key release events for the keys.

 But even in the above example, it potentially means a more complicated setup,
in that the client (or something) has to keep track if the release events has 
occurred.


 Note that focus can mess things up.  Start running and then have the client 
lose focus - your character will continue to run, even after you release the 
keys.  However, this is more a special case I'm not too concerned with.





Given this background, run and fire are handled differently, since these
are modifiers - when the client gets that the key is pressed, it just sends
the appropriate fire_on or run_on to the server, and when key is release,
send fire_off/run_off.


And here of course lies the problem: which commands should be of the type
start/stop, and which should be of the type do once? It would be pretty bad
if one sent a command to drink a potion and the PC drank _all_ potions of the
type because the key was held too long. But other commands - search, disarm,
run, maybe fire? - may be better suited as start/stop?

It could be as simple as adding a few new start/stop type commands to the
server - walk (without attacking), search, and disarm, to begin with? - and
updating the client to use them. Assuming the client key handling is in
place, of course.


 I'd really prefer this not be in the server, and instead be in the client. 
the fire_on and run_on are really pretty terrible hacks as is, and I'd rather 
not add more of them.


 The protocol has improved since those were put in.  The client should be able 
to better watch the number of acknowledge commands and send or not send commands 
as appropriate.  Note per my previous mail, the next enhancement that would be 
nice would be for the server to look at all commands, and in addition to having 
priority, there could be something like 'cancel are north commands', such that 
when the key is released, that is sent to the server and the server does just 
that.  That said, even this gets tricky - you don't want to cancel the a single 
command that was sent, which might mean the client has to know if multiple 
commands have been sent, and which ones.


 This reduces the server having to remember more state.

 In terms of what commands should repeat and what should not, this could 
probably be an option in the keybind menu, eg, 'repeat?' which notes if the 
command should be repeated or not.  Probably also allow it in the keybindings 
itself, because for some commands, there may be desire to repeat them in certain 
circumstances and not other (apply immediately comes to mind in certain cases, 
like eating a lot of low value food, but not in others, like using exits)







I've done some coding on the other, related issue of key
combinations/modifiers and key bindings.

Today the client is extremely flexible: you can actually re-bind the run,
fire, alt and meta modifier keys! Is this a popular feature?


 Not sure, although I could imagine depending on keyboard layout, etc, there 
may be desire to do so.




Also, it is unclear how

Re: [crossfire] Key repeat and keybindings

[Mark Wedel]

On 10/23/13 06:53 PM, David Hurst wrote:

Hi Arvid,

I have discussed these issues in some detail in the IRC channel. I believe I can
answer your questions and propose solutions, sadly I lack the talent to make any
changes.


 There are a few things that we are both annoyed with though. One is the key

press handling. If I walk by holding a direction key, it seems key repeats are
queued so that the PC continues to walk long after the button is released.
Usually into a trapped door...
 

 Similarly with search: hold down the search key to make a thorough search of

the immediate area (say, 4 x 5 searches), and after the key is released, and
additional 2 x 5 searches or so are made before the PC can do anything else. The
delay is a couple of seconds and makes the client feel really sluggish. This
usually happen when something horrible shows up, like a sweet little girl.
(She killed me. Oh, the shame!)

This is client side effect. The client will store up to 10 commands before
'overflowing' and ignoring further commands. For very slow actions this is very
noticeable. When a player starts running the client will continue to send
running events (i think this is actualy server side, sorry beyond my knowledge)
until an interrupt is sent to stop. The solution I have discussed was that the
client should queue commands as long as they are the same action as per the
current system, however, if an alternate action is pressed it should interrupt
the queue and immediately do this action instead. I believe it was added to
someones to do list right down the bottom but I agree that this seems to be a
really powerful aspect of crossfire which adds a laggy or delayed feel to an
otherwise rapid paced game. I suggested this might be a client setting that
users can set a preference for.


 A lot of this has to down how keys are handled, at least on x-windows.

 If you could down the control, shift, or other modifier keys, a single event 
is generated - that the key has been pressed, and another event is generated 
when the key is released.  This is all done in the x-server - at a level beyond 
the client.


 For other keys, autorepeat kicks in.  So if you hold an arrow key, the 
x-server is generating numerous key press/key release events, which the client 
then sees and takes as different key presses.  Best I know, there isn't an easy 
way to know if multiple key presses are a result of autorepeat or if the player 
is actually pressing and releasing the key (as a side note, for myself, for 
things like search, I would just hit the s key 5 times to know how much I'm 
searching)


 Given this background, run and fire are handled differently, since these are 
modifiers - when the client gets that the key is pressed, it just sends the 
appropriate fire_on or run_on to the server, and when key is release, send 
fire_off/run_off.


 As you can imagine, for other keys, it can't use this same approach - the 
arrow key will generate constant press/release events - while the client can 
ignore them, that probably isn't desirable either.


 You can actually change the amount of commands the server/client buffer - this 
is in the config window - if you are playing on a lan, dropping it down to 1 or 
2 is probably fine.  The reason that might not be good on WANS is that if the 
server is far away, the character may end up not doing anything as it hasn't 
receive commands for it because of the time it takes for the data to go back and 
forth.


 Another complication in all this is that how many actions the character gets 
isn't constant - it may move slower if it has a lot of equipment on, could move 
faster with different spells, etc, so it is a little harder to keep it all in sync.




Basically, yes I agree with your concerns and questions that this aspect of
crossfire could be improved and I believe the current bottleneck is simply time.
The age old #crossfire response: sure, code it.


 Yep - and given this isn't just a simple fix, such code is more difficult.

 The proposal to fix it would be for the server to inspect all commands from 
the client as it gets them.  Right now it is a FIFO - if the server inspects 
them, certain commands (drink healing potion) could have higher priority than 
other commands.  This also allows something like 'ignore all commands up to this 
command' to basically flush the queue - in that way, one could interrupt things.


 However, when to interrupt and when not still isn't an easy problem.  It may 
simple enough - if I'm holding the north key down, then when I press the east 
key, have it drop any queued up north commands and just start moving east.  But 
suppose I'm on a map (saw a town) and know I want to go 5 north and 3 east, and 
press those keys individually - as noted above, there is no easy way for the 
client to know that is the case vs keys being held down.




In the short term I found it very valuable to understand how the client works, I
have changed the way I make key pressed to minimize 

Re: [crossfire] Sound support on GTKv2

[Mark Wedel]

On 09/ 2/13 09:53 AM, Kevin Zheng wrote:

Hi there,

A big element missing from Crossfire is sound. While sound support has
existed for quite a long time, it has consistently failed to work on
newer installations. In addition, sound files have remained untouched
for many releases. I intend to fix this.

A quick glance through the client sound sources show that a great deal
of effort has been put through to make it work with several major sound
systems out there. While supporting many sound systems is good, it has
become overly cumbersome and makes the source hard to work with.

For this reason, I propose that sound support should be discontinued for
every system except for SDL_mixer. SDL_mixer is a high-level library
that supports ALSA, OSS, and many other lower-level sound systems.
SDL_mixer also supports OGG, which enables us to use a higher-level
sound format other than the raw PCM file we use today. Hopefully this
will make sound contributions easier, too.

I would like to be able to start working on the code changes in the very
near future. Questions/comments/hate mail?


 I have no objection, but at the same time, since most of the code is #ifdef if 
the sound system exists, there isn't as a compelling reason to remove the old 
ones vs just adding a new one, and making it first choice if multiple options 
are found.


 I can't remember all the history of why all those other sound systems got 
added support - it seems that SDL has existed for near as long as the client 
has, so I don't know if it has limitations on certain systems.


 Of course the problem is also whether to target SDL 1.x or SDL 2.x - not sure 
how much the API has changed.  Clearly 2.x would be desired long term, but short 
term, I'm not sure how many people would be running SDL 2.x, so if only that was 
supported, it might remove sound support for a lot of people.


 OTOH, sound was never a key part of the game, so if certain people do not have 
sound support, it would hardly be the end of the world.


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

Re: [crossfire] Race inconsistency for gnome

[Mark Wedel]

On 05/11/13 12:02 PM, Nicolas Weeger wrote:

Hello.

The gnome archetype is defined as having a race of gnome, but in the
lib/races file it is defined (and reset by server) as dwarf.


So I guess one should be fixed, which one?


 Further digging may be necessary - if the gnome race is not used in any spells 
(or is not the enemy of any god), making the player race gnome may be more of an 
advantage, unless there is some backstory for why gnomes never offended anyone. 
 But having it be dwarf would just seem odd.


 The races file is actually a bit of a hack - IIRC, it was originally done way 
back when as an easy way to tweak races (single file to modify, instead of 
needing to go into all the different arch files and do a collect).  Perhaps more 
an issue back in the old days when a collect may thrash the disk for several 
minutes, but all it does now is create confusion, as it redefines something in 
the archetypes.


 Of course, now it is used for other things, like summoning lists, so is not 
really easy to remove.





I admit to not knowing, maybe the easiest fix is to let the race as gnome,
there are other monsters with it anyway.


 The more interesting and harder fix would be to be able to do racial 
heirarchies.  EG, you could have 'good humanoids' or the like which include 
gnome, dwarf, elf, etc, so it is easy to just include that in an enemy list.


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

Re: [crossfire] Ice melting spell

[Mark Wedel]

On 05/ 1/13 12:27 AM, Nicolas Weeger wrote:

Hello.



One thing I've been thinking would be nice is a pyro spell for melting ice,
a bit like there is a earth to dust spell. Messing around with flints
(specially the humorous bit about mistakenly lighting the flint with
itself, and burning it completely up) seems somewhat, er, medieval.


Maybe a warm spell? Which wouldn't give any experience, probably, to avoid
abusing it :)

And with a probability of warming too much and destroying items in the ice.


 One can already sort of do this with things like burning hands or other fire 
spells - just be sure to put the ice cubes at the edge so they get a minimal 
amount of fire, which the reduces chance of burning up.


 Of course, there is still a fairly high chance of them burning up even in that 
case (just like with flint  steel).


 Ice cubes could in theory melt on their own - give each a speed, and some 
amount of hit points or the like (perhaps based on how much damage resulted in 
them being put in ice in the first place, eg, a dragon breath is going to be 
pretty big block of ice), and when it runs out of hit points, it is melted.  So 
if players want to wait, they could do so.


 One problem there is that some items should basically get ruined even in that 
case - while the scroll may not burn up and turn to ashes, it getting soaked 
with water would likely ruin any writing on it.


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

Re: [crossfire] Reorganizing dist files on SourceForge download page

[Mark Wedel]

On 04/25/13 07:00 PM, Kevin Zheng wrote:

On 04/25/2013 15:28, Rick Tanner wrote:

On 4/24/13 11:16 PM, Kevin Zheng wrote:


I've noticed that the files available from the project's
SourceForge download page have become very haphazardly organized.
I think that it's time for someone to consider tidying things up
a bit.


Just to make sure, do you mean this page?

https://sourceforge.net/projects/crossfire/files/


Yes! Sorry for not making that clear...


 So when 1.70.0 was released, you can see that all the files (server, client, 
maps, etc) were placed under the crossfire-1.70.0 - it was a while since I did 
that, but I think some of the reason is as you describe - it makes sense for all 
the files for a release to be under one directory.  I also think it might of had 
something to do with how sourceforge presented the information, and it was 
simply more work to put each one in its own directory.


 However, I didn't have the motivation to go back and fix all the other entries 
- if a CLI to the directory structure is available, probably not that hard (a 
few mkdirs here, a few mvs there), but if it all has to be done by the web 
interface, sort of an annoying process.


 Removing the crossfire- prefix on the directory name could be done - I don't 
feel strongly one way or the other on that.  I would say that the names of the 
actual tar archives may make more sense to rename, eg, arch-1.70.0.tar.gz, 
maps-1.70.0.tar.gz, etc.  The only issue with that is for sites that mirror it 
and don't put it in an appropriately named folder.


And it may make sense just to always/only do the archives in bz2 format, as that 
has been out long enough that it would seem unlikely that systems are lacking 
that ability


 The CrossfireEditor (crossfire-editor folder) is the gridarta based editor - 
the crossfire specific version vs the daimonin specific one.  IIRC, the reason 
that was in a different folder is that its version numbering is different.  I'm 
not sure the best way to handle that - putting in an editor-0.9 in the 
crossfire-1.70.0 directory just seems sort of odd from a numbering standpoint.


 I believe the main reason the windows client  server were in separate 
directories is that the packagers of those were different people, and thus the 
timing of their release did not always correspond to the release of the other 
files.  But I don't think there is any reason the maintainers/REs of those files 
couldn't put them in the same version directory.


 More likely, it is more history - back when each component (arch, client, 
server, sounds) had its own directory, having a directory specific for windows 
or linux rpm files made perfect sense.  But if we are moving to putting all the 
files for a given release in a single directory, then the windows and linux rpm 
files should be put in that same directory.



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

Re: [crossfire] Keeping capitalization consistent in maps

[Mark Wedel]

On 03/19/13 01:39 AM, Otto J. Makela wrote:

On 2013-03-19 05:18, Kevin Zheng wrote:


Proper nouns should be capitalized, but Arena Guard appears
capitalized. On the other hand, ticket vendor is not capitalized.
Where do we typically draw the line between a generic noun and a proper
noun?


There is also a long-standing problem that there are objects which are
keys and objects which are Keys. Same with swords and some other
categories.

This of course comes up with the command line commands like drop.



 For normal objects (swords, keys, etc) I would say they should all be lower 
case.

 Normal English would dictate that things like Arena Guard, ticket vendor, etc, 
should all be lower case, since as noted, they are not proper nouns.


 OTOH, if other conversations refer to these NPCs, it would be nice to give 
them a proper if a particular one has to be talked to, eg, 'talk to arena guard 
John'.  Otherwise, if there are 5 'arena guards', but only the 'Arena Guard' 
holds a conversation, that just gets confusing.




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

Re: [crossfire] Time delay in maps

[Mark Wedel]

On 03/19/13 09:55 AM, Kevin Zheng wrote:

Hi,

I'm trying to implement time delay in one of the maps I'm working on.
Unfortunately, I have no idea how to approach this. I suspect I have to
do something in Python, but I've never done this before, either.

Basically, a magic ear will activate a connection, which needs to start
a timer. When the timer runs out, it should activate a different
connection that opens a door.

Any suggestions?


 In the past, people did things like this with clever use of boulders, 
connected spike traps, etc.  I'm not sure if there is any simple way to do this.


 The way it works with boulders is that first connection (magic ear) activates 
the spikes under the boulder.  IIRC, you can set the speed of the spikes, so can 
control the timing to some extent.  The spikes push the boulder onto a button 
which then activates the next step (could be another set of spikes with another 
boulder).  The initial spikes, button, and boulder are in a hidden 1x2 room so 
that the boulder can only get pushed onto the spikes.


 Now if you want this to reset in some time, you then need a set of spikes 
beneath the boulder to push it back to its original location (and some logic to 
lower those initial spikes).


 Or you could do with this with a script - I'm not sure the details, but I'd 
certainly imagine something like having the script tied to some normally 
inactive object that is linked to that ear.  On magic ear activation, the script 
updates the speed of another object to be non zero, and based on the speed and 
speed_left value and pretty precisely set a time.  When that second object gets 
an action, it runs a different script/pushes a different button.


 This could probably be done in one object by toggling the speed - one just has 
to also design that script to behave properly if it gets activated multiple times.

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

Re: [crossfire] Shortening experience bar for GTK2 client

[Mark Wedel]

On 09/15/12 12:56 PM, Kevin Zheng wrote:

Greetings,

The GTK2 client has an experience bar at the bottom left corner in the default
layout, right underneath the HP, Mana, Grace, and Food bars. As your character
levels up, your experience increases (duh) as well as the experience needed
for the next level. Both these numbers are shown next to the experience bar.

I level up, the experience bar becomes wider as the experience numbers
increase. At some point it is wider than everything else and starts eating up
unnecessary space. This isn't a problem on a big screen beacuse there's lots
of space, but it's annoying on a 1024x768 screen. I don't want to switch
client layouts, either, so here are some of my ideas:

1) Show exp with suffixes. For example, show 10K instead of 10,000, 10M
instead of 10,000,000, and so on. Drawback: can't see small exp increments

2) Show remaining exp instead of total exp. Drawback: counts backwards

3) Show difference between current exp and next exp level. When level up,
start counter at zero and end at next exp stage. Drawback: confusing.

Any ideas?


 A couple thoughts I have:  Show as a percentage how close/far you are to next 
level - that sort of duplicates the bar itself, but probably gives a higher 
level of refinement than try to guess where you to next level.


 Changing the layout for the exp might help - instead of the experience numbers 
being to the left (or right) of the bar, which results in the formatting 
problems, add another row and put them below the exp bar.  However, if you are 
really tight for space, that extra row for that may not work out either.


 Or possible do approach number 1 (exp with suffixes), and add a tooltip to the 
exp bar that gets updated which shows actual values, so if you really want to 
see the exp total, you could.


 The core stats window also shows experience, so one can always see how much 
one is gaining on that, even in small increments.  But I could certainly see 
that folks may have the protections tab selected instead to see when spell 
effects andthe like run out.


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

Re: [crossfire] Client GTK2 - Buffer overflow

[Mark Wedel]

On 09/ 4/12 06:55 AM, Otto J. Makela wrote:

On 2012-09-04 03:27, Karla Stenger wrote:


snip

Also also, the distance metric works somehow strangely with this client,
as occasionally when you use identify type skills you will end up
identifying objects which are farther than the 1+8 nearest squares.
Eg. this seems to happen pretty often in Raffle, where there is a fence
between you and the objects, but you still are able to identify items.


 I can't comment on the other issues right now, but the above one is not/can 
not be a client issue.  All identification is done on the server (only part the 
client plays is to send the command to the server).


 However, latest SVN has increasing area based on skill level - if level =4, 
only the space you are standing on is identified, up to level 16, you get the 9 
spaces, up to level 64, you get 25 spaces (effectively radius 2), and above 
that, you get 49 spaces (radius 3)


 So what you are seeing is expected - you should see the same thing with the 
java client, or any other client.


 Note that it is possible (I haven't looked at the other clients) that other 
clients are intentionally limiting the range - eg, only identify the 9 spaces.


 Note also that the ranges are based on skill level, so if you are high level 
in one skill, but low level in another, that high level skill will identify a 
larger area.

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

Re: [crossfire] Quest-based leveling?

[Mark Wedel]

On 03/18/12 02:39 PM, Nicolas Weeger wrote:

Hello.


I'm wondering whether it'd be nice or not to have some main quests, maybe
related (like Scorn's nobility quest), that would enable a player to level
through them.


The idea being that instead of leveling, one would do the quests, and level
almost like a side-effect.


Of course that'd require quite some work to rebalance things, and write many
quests.

Especially since one can imagine quests forbidding to do others, variations,
and thus.



How does that feel?


 Many other games do include experience as a reward for quests.  That doesn't 
necessarily make it a good approach (nor bad), but does imply that others have 
thought of it and considered it an OK approach.


 What is not clear from the above (and some followups suggest this confusion) 
is whether these exp reward are in addition to the exp one gets from killing the 
monsters, disarming traps, etc, or if this is basically replaces the way a 
characters gets experience.


 If this is additional reward, then this in some ways makes the game easier - 
you are getting all the same experience as before, and now get more when that 
experience is associated with a quest.  So this in some ways makes things easier 
(how much is hard to say).


 If this is a replacement, then I think this is more complicated - one has to 
make sure there are enough quests (or the quests are repeatable) to be able to 
gain sufficient exp.  It also means that maps which are do not have a quest 
really just become places to hunt for items/gold.


 A middle approach could be taken - the exp one currents gets from killing 
monsters and other tasks is reduced by some amount (exact amount hard to say) 
because a character now gets exp from the quests.  The amount of reduction and 
the reward for quests would likely be determined based on the targeted mix for 
quest vs non quest exp.  For example, if the target is 50% quest, 50% non quest, 
then exp from monsters, etc is reduced by 50%, and the reward for the quest is 
50% of a level (presuming 1 quest per level - 25% of 2 quests per level, etc).


 I'm presuming (but could be wrong) that in all cases, the reward is some 
amount of exp, and not a percentage of a level.  Otherwise, a player that holds 
easy quests until late in the game gets potentially a lot more exp for 
completing those quests.



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

Re: [crossfire] GTK client compilation issue w/ newer autotools

[Mark Wedel]

On 02/15/12 01:22 AM, David McIlwraith wrote:

Hi,

Thanks. Seems that is the case here. X libraries are not listed in the
gtk+-2.0.pc file for some reason.


 There isn't a lot the client can/should do in that case.

 One can set LIBS environmental variables to add extra libraries that are 
needed - I think in this case, that is probably the correct fix (well, workaround).


 While the client configure script could look for these other libraries, there 
is reasonably likelihood that it will break in various cases - if gtk+ adds 
another library dependency in the future, or if there is an extra one on some 
system.





Regards,
- David McIlwraith2c93e...@gmail.com

On Wed, Feb 15, 2012 at 3:16 PM, Mark Wedelmwe...@sonic.net  wrote:

On 02/14/12 04:49 PM, David McIlwraith wrote:


Hi,

X_LIBS does not appear to include libX11 with bleeding-edge auto*
tools; I am not sure if this is an issue with the client source itself
or a problem elsewhere. Nonetheless, on svn r16896 (up-to-date local
ArchLinux [x86_64] system), configure.ac must be modified such that
-lX11 is added in a similar vein to Xext. Noting that I have not
encountered this issue before when packaging the client, I am unsure
as to where the problem lies -- does anyone have any insight here?



  Does pkg-config exist on the system (it may not - it seems like every few
years yet a new method of determine package information comes out).

  It would be interesting to see what 'pkg-config --libs gtk+-2.0' comes back
with - that should provide the libraries that gtk+ needs.  For example, on
my solaris system, I get:

pkg-config --libs gtk+-2.0
-R/usr/lib -lgtk-x11-2.0 -lsecdb -ltsol -lgdk-x11-2.0 -latk-1.0
-lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lXext -lXrender
-lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgio-2.0 -lXfixes
-lcairo -lX11 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lpthread -lglib-2.0

  Note that -X11 (along with a bunch of other X libraries) is there.

  If pkg-config is not listing those libraries, I would suggest some problem
with the distribution related to pkg-config not reporting correct
information. If that information is there, and for some reason the configure
is not using it, that would require more investigation.

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



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

[crossfire] Crossfire release

[Mark Wedel]

 It's been quite a while since there has been a crossfire release, so it seems 
about time for one.


 So I'm thinking that in a couple weeks time, packing up what is there as a 
release and putting it up on sourceforge.


 There are a few reasons for this announcement:
- If there is code/changes that are ready for commit, it gives you time to get 
those committed (a complaint in the past was someone missing the deadline by a 
few days and has to wait for the next release)


- To be aware of this upcoming release, and _not_ to commit large untested 
changes.  Making a release where the code has had little real world testing 
tends not to be good.


- To focus on bug fixes/stability improvements for the next few weeks.

 Since a couple weeks is vague, I'll just say end of the month.  That does not 
mean the release will happen on March 1, but it could, so just take that as a 
deadline.


 Any concerns, questions, issues, let me know.

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

Re: [crossfire] Patch proposal: unidentified generic faces

[Mark Wedel]

On 01/21/12 12:13 AM, Nicolas Weeger wrote:

   Is the way you see doing this is that the archetype contains the
unidentified values?  I'm just curious as to how the unidentified
name/face is determined.



If I implement like the patch suggests, the archetype will contain in the
name, face and animation fields the unidentified values. And there will be
keys for identified_name, identified_face, identified_animation (and
related values like speed).

The object_give_identified_properties() function, called from identify()
and some other places, would ensure those identified_ values are copied over
to the item when needed.


So we'd alter archetypes to be unidentified by default.


 That sounds like it would work out fine.

 I didn't look at things closely, but one thing I would suggest would be 
identified/unidentified entries for value of the object.  Right now, I believe 
the code just says unidentified value is some percentage of base archetype 
value, which I don't think is great.


 The complication here is that when an item is granted additional properties 
(for example, pluses added to the sword), the treasure code uses the base value 
to determine the new value, and stores that new value away (in ob-value) - so 
to rework that is a bit more effort, so a simpler thing may just to add an 
'unidentified_value' to the archetype, and the code can just use that when asked 
for price.


 Another reason to have values coded in is if one is really trying to obscure 
the object, one needs to obscure the value.  Otherwise, in the example of 
potions where the face is the same, one could get the estimated price of two 
unidentified potions, and get different values, and potentially be able to 
figure out what the potion is from the value given.  If the character has no 
idea what they are, then they should get the same value for all potions.


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

Re: [crossfire] Patch proposal: unidentified generic faces

[Mark Wedel]

On 01/18/12 02:26 PM, Nicolas Weeger wrote:

Hello.


I've been playing with having items hide their real face unless they are
identified.

So for instance potions would keep their generic face when not identified.


 In the distant past, potions used to work that way - generic face until 
identified.





Here's a patch that makes that behaviour.


Right now it's only the face (and animation-related parameters), but I was
thinking of doing that for the name too. So eg unidentified skill scrolls could
have a generic blank face and name until they are identified.


 Yes - this makes sense.  Using key/value or other abstraction vs coding in 
those values makes a lot more sense.  I suspect that is the reason that skill 
scrolls do not work that way - when they were put in, the code was not modified 
to hide their names.





Would that behaviour change be ok?


 Fine by me.




The code relies on key-values containing identified properties (see
common/item.c:object_give_identified_properties for more details).


 Is the way you see doing this is that the archetype contains the unidentified 
values?  I'm just curious as to how the unidentified name/face is determined.



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

Re: [crossfire] Acid and cancellation

[Mark Wedel]

On 12/29/11 08:36 AM, Nicolas Weeger wrote:

Hello.


Right now acid and cancellation will permanently alter an item, decreasing its
magic (acid) or setting it to 0 (cancellation).

For bad items (weapons with -1 for instance), this is nice because you can
recover items.


For good items, this is really bad, because you just lose some power on the
item.


This can of course be the correct behaviour, but it's always painful for
players to  have equipment thus damaged :)


If this should be changed, one fix could be to store the magic as a
key/value, and add items to restore that value.


 This has been an issue for a long time (and discussed in the past with many 
different proposals).  I'm not sure the ideal situation - acid damage equipment 
is probably much harsher (or happens much more often) than it should - 
especially given the fast pace of the game - before you realize what the rust 
monster is doing, all of your equipment may be at -4.


 Certainly storing the original magic value of the item would be easy enough to 
do, and one could think of ways to allow it to be repaired - go to armor shop 
and pay some amount of money, etc.  So I certainly think that is a good idea.


 I also wouldn't be adverse to somehow recording when last acid damage happened 
and throttle it back so the player has a chance to react.  If they choose not 
to, their equipment may still get a bit damaged, but if they at least have a 
chance, that would be better.  I always consider it better for players to be 
able to experience things in game and learn from them, but as is, with some acid 
attacks, the learning cost can be very high.


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

[crossfire] plugin versioning

[Mark Wedel]

 It seems to be not that unusual that out of date plugins in the installed area 
result in system crashes.


 Now I've made a fairly simple change (not yet commited) that checks what the 
svn version was of the compiled plugin against that of the server, and if they 
don't match, it doesn't load the plugin.


 The nice bit here is that for old plugins, they will lack this symbol, and 
also will not get loaded.  As that is another potential problem - a plugin that 
used to exist (and thus was installed), but has been renamed, is no longer 
active, etc.


 The one thing I'm not sure of is if any plugins exist from outside the source 
tree, in which case them having the right svn version would be an issue.


 I've also thought about adding in some other checks - sizeof(object) as when 
the plugin was compiled vs the server, and perhaps sizeof of player, map, etc. 
But these would seem to be much more developer scenarios - dev has made changes, 
but not done a commit, so svn number is unchanged.  In those cases, the dev 
should hopefully be aware of what they have done.  And the problem is that 
simple size checks may not be all that foolproof - if for example, I remove one 
field from the middle of the object structure, but add a new one to the end, the 
sizeof(object) may be the same, but the fact that the positioning of a bunch of 
interim fields has changed will result bad behavior.


 I'll commit this change in the next day or two, unless I hear of some reason 
not to - the plus side is that it is a pretty trivial change, and 
removing/disabling the logic from the plugin loader would be pretty easy if 
there are issues.


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

Re: [crossfire] Graphism perspective

[Mark Wedel]

On 11/19/11 01:27 PM, Nicolas Weeger wrote:

Hello.


I'm wondering what perspective we want to have in the game.


Right now, for monsters themselves, it's quite incoherent:
- some are top/bottom/left/right
- some have the vertical line not vertical
- some have yet other things.


 There are a few potential different thoughts on this - one could take any/all 
of these as what should be done:


- What looks best
- What perspective most of the monsters/images currently have
- What is easiest to draw

 Probably some others.  I suspect the mix is because different artists decided 
to draw them in their own style.


 I also suspect that the slanted ones might have been a result of isomorphic 
tileset/display - those at a tilt would look proper if the walls/overall map had 
that same perspective, but not the flat display of crossfire.


 I note that the bears as an example have issue with lighting - from the README 
in the arch directory:


Light should generally come from the right side, so the left side of
buildings should be darker or shaded, as needed.

 But the bears have the light coming from the left, so their right is in shade. 
 That is easy to fix - just flip it (so it faces left), but does illustrate 
that adding shadows to objects make it a bit harder to do different faces - for 
creatures with no shadows, like the ape, it is very easy to do a left/right 
facing - a simple flip, and it is done.


 While not really clear, I always took it that the bottom (south) of the map is 
closer to the viewer.  Thus, creatures going north (away) should have a back view.


 I'm a bit old fashioned, but my vote would be the vertical access is vertical, 
not at a slant.  But I prefer the look like they are 3D, and not flat - as 
examples, the bear and ape are what I would describe as 3D looking, where as 
highangle and dave appear flat.  That may just have to do with the graphics 
themselves, but this could also extend to other objects.


 For example, a lot of the equipment could have a very flat look (symbolic), 
but I actually prefer the look that they are 3d.


 The problem I see with vertical access 'exiting the screen' is that all one 
should see in that case would be the top of most peoples head - not very exciting.


 It's also odd because things like town are clearly not a true top down 
perspective - if that was the case, all one would see is the roofs of the shops, 
and not the front.  So while the game is top down, the viewing direction clearly 
isn't quite like that - it is more that one is at a 30 or 45 degree angle to the 
south and looking into the town, dungeon, whatever.


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

Re: [crossfire] Multilinguism support

[Mark Wedel]

On 11/12/11 01:04 PM, Nicolas Weeger wrote:

Hello.


I've rewritten part of the i18n support the server had, to make it easier to
figure what message is used in the source.


When you need to find a string, to display or use in a buffer, please use

i18n(who, English version of the message, with the %d placeholders);


This will enable to write translations in various languages, through the
message.code files.


 Thanks - this makes reading those files much easier.

 Random question - could draw_ext_info_format() just default to using i18n() to 
passed in strings, or would that just be too costly since a lot of text may be 
automatically generated of which you can not have translations (shop listings, 
spell lists, etc).


 And thinking about it, that may not work very good if a string has already 
been translated and is coming from a different source (player chat, object msg, 
quest, etc - see notes below).


 OTOH, given those sources would be well known in the code, I then wonder if a 
new flag could be added, something like NDI_NOTRANSLATE to just tell the routine 
not to translate it.


 My only thought here is that if all the strings in the source are eventually 
translated (which I think would be the goal), then the use of i18n() just 
becomes extra work.  I would presume that by default, if a proper translation 
can not be found, the message would then fall back to english also.


 The one optimization I could see here is require that all message strings are 
English (as is the case now), and have i18n() just returned the passed in string 
in the language setting is English.  It appears (at a cursory glance) that if a 
user specifies English as their language, there language will get set to 
English, and while the locale file for english is empty, a call to bsearch would 
still be made, at which point it would fall back to default.



I plan on thinking about archetype, map, quests and various translations, too
:)

Any idea or suggestions welcome, of course.


 For archetypes/maps, I think the way to go would be msg_lang, endmsg_lang, 
eg, msg_fr/endmsg_fr, msg_de/endmsg_de, etc.


 A nice effect of having the entire msg blob be localized is that any @match 
could also be localized to the correct language - having a question be localized 
to French by expecting an English answer would just be odd.


 If one wanted to carry on, name_pl_lang could also be added.

 I'm not sure what to do about python scripts, since presumably the text is in 
the python script - while the i18n() would work just fine, since the scripts are 
in the map tree, having the localized strings in the server is a bit of a 
mismatch - I'm not sure if there would be some way to have the localized strings 
in the script itself (based around some standard framework, each script has the 
translation table declared in itself).


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

Re: [crossfire] skill/class cost table

[Mark Wedel]

On 10/24/11 09:58 AM, Nicolas Weeger wrote:


   As an aside, I'm thinking of setting up an arch  server branch for this
(the maps really should not need changing on this).  My main thought is
that this is going to be a pretty radical change in how things work for
players, and so servers probably need some time to adjust (and probably
some time is needed just to balance this out before going live on
servers).

   Now I could work to make it so that both skill systems are available in
the same code base, and by tweaking config values, you get one or the
other, but long term, this is a big enough change, there is no way both
can be supported. And in many ways, cleaning up the code now makes sure
the code gets cleaned up, vs putting it off to some point in the future.



IMO, either make that server private, or ask Meflin and use his server. There
are enough empty servers on the tracker right now, no need to add another one.



 Also, feel free to ask for help, of course :)

 That is one reason I'm thinking of doing a different SVN branch - that makes 
it easier for others to work on and test this.


 But in this somewhat incomplete state, I really don't want to put this into 
the main branch, in case it takes a while to complete, and I don't want to break 
folks currently running the main branch while this works goes on.


 The only real downside of a branch is making sure that changes in the trunk 
make their way to the branch.


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

Re: [crossfire] exp loss changes

[Mark Wedel]

On 10/16/11 02:12 AM, Nicolas Weeger wrote:

   One way to work around this is that if a character has an exp loss, and
permanent exp is in place, when they regain it, some of it goes to his
total.



I think perm exp can be used for two goals:

- enable even really unskilled or unlucky players to level up even if they die
a lot ; in which case increaseing perm xp at each chance is indeed a good idea

- be a safety net for players wanting to try dungeons, so that even if they
die they aren't too penalized anyway ; in this case I'm not sure increasing
perm xp is such a good idea


 The second case is probably a tough one - I suppose it depends on what 
percentage perm exp is set to, as well as what percentage is lost on death, but 
I suspect for most servers, the perm exp isn't going to help out on a single 
death, as it would take several deaths before you work down to your perm exp total.


 One area where perm exp comes into use now is hard to advance skills.  The 
permanent exp will protect some portion of experience in those skills.  For 
example, you get exp in some skill, and you may die a bunch of times before you 
advance it again - the perm exp protects at least some portion of that.


 In my new system, that doesn't really apply anymore - since skills don't have 
exp, you don't need to protect those skills (and with AP, hard to advance skills 
have sort of a different meaning)




But anyway however this is adjusted, it can be changed later if needed :)


 One could certainly have 2 tunables here - maximum exp loss percentage, and 
percentage of new exp that is always added to new total.


 So one could have a server with perm exp at 50%, but only 25% for amount added 
to new exp.  So on death, 75% of exp gained after that point goes to work off 
the exp loss, and only 25% goes to increasing the total.  Or other server admins 
could set that to 0% added to new exp - you have to work off all your death loss 
before you get any more.


 I think the only gotcha here is that if percentage added to new total is 
greater than max loss, you would get in the situation that as the character 
regains exp, his current exp_loss would exceed what the limit should be based on 
his new total.


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

Re: [crossfire] skill/class cost table

[Mark Wedel]

On 10/16/11 02:06 AM, Nicolas Weeger wrote:
snip

2) Skill Scrolls get removed, and characters know all of those skills.
However, skills start at level 0, and must be increased to level 1 before
they are usable.  For example, a knight character starts out at with fire
magic at level 0.  He can use 8 AP to increase it to level 1, and now use
it as a level 1 skill.  My basis for this change is several:  The vast
majority of skills are things a person would know to do (anyone can pick
up an axe, or try to make a sword - they might be very poor at it, but
could do so).  Also, I see the starting skills in the existing system as
the way to create the classes - fighters don't start with magic skills,
not everyone starts with praying skill, etc.  But with skills costing
different costs, that is what really defines the class in the new system -
a fighter will be a better fighter because the fighting skills are fewer
points for them than the mage.

Also, skill scrolls really just created a short term limitation - once a
character got enough money, which typically wasn't too many levels, they
could go out and buy all the different skill scrolls.


Only thing I see is meditation, which is (in the current system) restricted to
the monk.

If you give that skill to everyone, even at a 100 AP per level cost, I'm sure
people will use it for the regen benefit.


 I see meditation as an ability (see below) that only monks would get. 
Meditation would be an ability not linked to any skill (as it doesn't advance 
with levels).


 There would be other abilities tied to specific races.  For example, wraith 
touch would be only for wraith, and tied to unarmed combat.  Clawing would be 
for dragons and also tied to unarmed combat.  There are probably some others out 
there.


 Note that this could get extended - one could add abilities that only certain 
classes get just to add some more color to the game.




3) Abilities may be things that need to be learned/bought.  Abilities are a
lot like spells but for other skills.  For example, the ability to do
triple shot would be an ability, and that might be something the character
needs to go out and learn (ideally by quest, but perhaps also by random
scrolls).  I haven't really thought much about all the possible abilities
- ideally there would be 10-20 per skill (and evenly distributed out so a
character gets one every 5 levels or soemthing).  For crafting feats, the
recipes could like abilities in some context - knowing how to make certain
items.  For combat skills, special attack moves.  Spellcasting already has
spells.


Seems interesting, yes. For spells, something like increased range, or why not
having the fire all around you instead of a cone be an ability too?


 Actually, you can do that right now - just fire in direction 0.

 For spells, since there are already a lot of them, I'm not as concerned about 
tweaking them.  But for many of the other skills, abilities need to be determined.


 As examples, some that come to mind off the top of my head:
 For weapons, some ability that hits all enemies around the character
 For certain weapons, maybe special slowing, paralyzing, etc, attacks.
 For thievery, something like backstab for extra damage, bypass dodge, etc.

 Just like spells, the list could be endless.  But some of my idea here is that 
this also adds things to make the skills more interesting.  Just as right now, 
spell skills would not be that interesting if you just got a few spells to start 
and all that happened as you went up level is the damage went up slightly, so it 
would be with other skills.  Spell skills are more interesting as you get new 
spells to try - and ideally similar things should be in place for other skills, 
so that you have something to look forward to and new things to try out.


 Some could also be strategic - some special attacks may take more time to 
perform, so the player has to make the choice if the effect you get would be 
worth it or not.

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

Re: [crossfire] Proposal for artifacts changes

[Mark Wedel]

On 10/16/11 04:21 AM, Nicolas Weeger wrote:

Hello.


I'd like to change artifacts handling by introducing archetypes for all
artifacts combos.

So for instance, for the 'Thieves' artifacts, an archetype named
'__ring_Thieves' would be generated with the relevant properties, and used for
the actual ring of Thieves. There would be various '__helmet_(whatever)' for
helmets, and so on for all artifact possibilities.


 Do you see this as being done automatically (at collect time for example), or 
this all done by hand?  Or some combo?





I see various benefits to that.

First, it would be possible to remove totally an artifact, leading to load
errors warnings and discarding (making a singularity I think) the actual
items this artifact represents.


 In general, using singularities is not a good thing.  I'd have to look at the 
code in particular, but when that happens, all that can happen is that the 
singularity created can only fill in the values that it is reading from the save 
file.  And the save file only contains differences from the artifact, so the end 
result is that the loaded object is likely to be missing a lot of information to 
the extent it probably isn't usable (it may even be missing name information).




And secondly it enables changing artifacts like other archetypes, with the
change being applied directly to all existing items, instead of having various
variants of the artifact.


 And that would be a good thing.  I do wonder if it might make sense to only 
apply this to equipment and not monsters however.  Monsters, being short lived 
and generated at that time, probably don't need archetypes - if the artifact 
gets changed, it is not like there are a bunch of artifact monsters sitting 
about that are out of date.




The drawback I see is the introduction of many temporary archetypes, but I
guess we can live with that.


 I do wonder if rather than making artifacts for everything, if it would be 
easier to just store a reference to the artifact that an item was created from. 
 I honestly don't really know - the problem with what I suggest is that you 
need to have the logic at load time to go through and look at the artifact, look 
at the original object (clone), and re-apply the artifact changes and see if 
they are different.  So as I think about it, archetypes probably is simpler.


 Few questions/thoughts on this:
- If the archetype for an artifact combo is missing, what happens?  Does the 
server just treat that as an invalid combo and do nothing?  Or something else? 
I'd personally suggest it do nothing - in that way, combos can be further 
tweaked by not having the corresponding archetype.  There are some combos that 
really just don't work - this is because the artifact applies a percentage 
difference to the original, but the original has base values too low such that 
no difference actually results.


- If archetypes for all now exist, does it perhaps then make sense to just make 
up treasurelists for these instead?  Such that the occurrence for these can be 
better tweaked, or more easily seen what the chances are?




What do you think of this proposal?


 Sounds good to me.  One other advantage here is that this would make adding 
artifacts to maps more consistent - one could basically just take the armor or 
helmet or whatever archetype as is, and put it on the map and the right thing 
should happen.

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

Re: [crossfire] skill/class cost table

[Mark Wedel]

On 10/12/11 11:52 PM, Mark Wedel wrote:


Following up on:

http://wiki.metalforge.net/doku.php/user:mwedel:skills

I've made up:

http://wiki.metalforge.net/doku.php/user:mwedel:skill_classes


 Just a note - I've updated the above to include race/skill combos.

 In doing so, I've more less come to these conclusions:

1) Races modify skill costs instead of giving skills at fixed costs.  I think 
this is more interesting - as noted on the page, fixed point skills didn't work 
out - if the cost of the skill is greater than the class gets it, it does no 
good, and if it is too low, it it just too powerful.  For example, if some race 
got divine casting at 4, they could basically turn any of the other classes into 
a priest/whatever hybrid.


2) Skill Scrolls get removed, and characters know all of those skills.  However, 
skills start at level 0, and must be increased to level 1 before they are 
usable.  For example, a knight character starts out at with fire magic at level 
0.  He can use 8 AP to increase it to level 1, and now use it as a level 1 
skill.  My basis for this change is several:  The vast majority of skills are 
things a person would know to do (anyone can pick up an axe, or try to make a 
sword - they might be very poor at it, but could do so).  Also, I see the 
starting skills in the existing system as the way to create the classes - 
fighters don't start with magic skills, not everyone starts with praying skill, 
etc.  But with skills costing different costs, that is what really defines the 
class in the new system - a fighter will be a better fighter because the 
fighting skills are fewer points for them than the mage.


Also, skill scrolls really just created a short term limitation - once a 
character got enough money, which typically wasn't too many levels, they could 
go out and buy all the different skill scrolls.


3) Abilities may be things that need to be learned/bought.  Abilities are a lot 
like spells but for other skills.  For example, the ability to do triple shot 
would be an ability, and that might be something the character needs to go out 
and learn (ideally by quest, but perhaps also by random scrolls).  I haven't 
really thought much about all the possible abilities - ideally there would be 
10-20 per skill (and evenly distributed out so a character gets one every 5 
levels or soemthing).  For crafting feats, the recipes could like abilities in 
some context - knowing how to make certain items.  For combat skills, special 
attack moves.  Spellcasting already has spells.


4) As is now, this will certainly mix up the races and classes a bit.  A good 
example is there is no class for the dragon player which is good with unarmed 
combat (claws) and spellcasting - as it is, the dragon either has to choose to 
be a melee dragon or a spellcasting dragon.  I am sure some things will need to 
get adjusted.



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

Re: [crossfire] exp loss changes

[Mark Wedel]

On 10/12/11 10:04 PM, Rick Tanner wrote:


On that page, in the notes, I mention that level loss will not
result in loss of AP - rather, it just means that it will take
longer before they get any new ones.


Very interesting.


With such a method, I was thinking that instead of decreasing exp
from the player total, instead add a new field like exp_penalty or
  exp_loss. When a player dies, that field is increased by
appropriate amount- exp_loss += (exp - exp_loss) *
death_penalty_ratio.

Then, any earned experience after that point gets applied to
exp_loss first, and only when that is zero, does exp get applied to
normal total.


By chance could some of this exp loss by death or drain be regained
through quest items/rewards or other in game mechanics?


 I didn't initially think about that, but yes, this would allow that to happen.

 A problem right now is there is no way to know how much exp a character has 
lost through death/draining.  As such, there is no way to restore it - if you 
give a character 10,000 exp, that is just 10,000 exp, which means if the 
character has not lost exp, that is just a bonus.


 But by tracking loss, one could basically do something like exp_loss -= 1; 
if exp_loss  0 exp_loss=0;


 So things like quests, potions, spells, etc, could reduce that field, but if 
that field is already 0, they gain nothing.  One could think of this to the 
restoration spell in ADD - it is used to regain lost levels, but doesn't give 
the character exp.


 So in crossfire, one could have expensive potions to get back that lost exp. 
This would make monsters that do drain attacks much less annoying than now - it 
might cost a fair amount of platinum to get that potion, but at least you could.


 Having spells that do it would probably not work, as it would just be too easy 
for players then.  But potions, scrolls, praying at altars, etc, would seem to 
be possible solutions - and of course, there is nothing that they would have to 
restore it all - maybe they reduce it by 50%.  One could repeat that many times 
and get the number closer and closer to zero, but still never get it to zero by 
that method.

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

[crossfire] skill/class cost table

[Mark Wedel]

 Following up on:

http://wiki.metalforge.net/doku.php/user:mwedel:skills

 I've made up:

http://wiki.metalforge.net/doku.php/user:mwedel:skill_classes

 Which goes into a bit more detail on costs - mostly because I got to the point 
where I started to need to know that information to progress on work of the system.


 That is only a first pass (as noted on the page), but I don't see any reason 
not to share it - other folks can make suggestions even at this point.


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

Re: [crossfire] exp loss changes

[Mark Wedel]

 Just a note on this - changing it as suggested does effect permanent 
experience in a subtle way.  Right now, experience you earn after losing 
experience still goes towards permanent experience.


Suppose a situation where a character has 100,000 experience and has not died. 
Permanent exp is set at 20%, and a character loses 10% of exp on death.


 In the old system, character would have 20,000 perm exp.  He dies, goes to 
90,000 exp, and as he regains that 10K exp, he gets permanent experience for it, 
so when he is back at 100,000 (assuming no more deaths), his permanent 
experience is now 22,000, since that goes up on all exp gain.  If the character 
is constantly dying, eventually he'll get down to his permanent exp total, at 
which he could slowly level up just by permanent experience.


 Under the suggested system, a characters would be limited to having an exp 
loss of 80% of total, or 80K.  The character dies, his exp loss is 10K.  If he 
gets to 100K again and dies, this could repeat forever - he will never get to a 
point where he is down to his permanent exp total.


 One way to work around this is that if a character has an exp loss, and 
permanent exp is in place, when they regain it, some of it goes to his total.


 Taking the above example, character dies.  His exp total is still 100K, but he 
has 10K in exp_loss, so effective experience is 90K.  He regains that 10K - 20% 
(2K) goes to his total, and 80% (8K) goes to the exp loss, so at the end, he has 
102K total exp, and 2K exp loss - his effective total is still 100K, but he has 
not worked off all his loss.


 I think this would pretty closely match the permanent exp thing as is now. 
Since his real exp is slowly going up, the cap of his exp loss is also slowly 
going up.

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

[crossfire] exp loss changes

[Mark Wedel]

 After long last, I've started work on the skill system I suggested at:

http://wiki.metalforge.net/doku.php/user:mwedel:skills

(it helps to have some free time between jobs)

 On that page, in the notes, I mention that level loss will not result in loss 
of AP - rather, it just means that it will take longer before they get any new ones.


 What I mean by this is lets suppose the character got to level 10, and spent 
the AP he got there.  He dies or is drained, and is now level 9 - none of his 
existing skills are decreased (no way to really fairly do that), and he does not 
lose any AP.  He adventures, regains level 10, but since this does not exceed 
the max level he previously achieved, he does not get any AP for that level - 
not until level 11 does he get any AP.


 Doing this avoids all sorts of headaches within the code, and from a player 
perspective, is perhaps a little nicer - since the character does not really 
lose a level, they can go back to the same map they died and still have a good 
chance at finishing it - except for stat loss, they are the same level before.


 With such a method, I was thinking that instead of decreasing exp from the 
player total, instead add a new field like exp_penalty or exp_loss.  When a 
player dies, that field is increased by appropriate amount- exp_loss += (exp - 
exp_loss) * death_penalty_ratio.


 Then, any earned experience after that point gets applied to exp_loss first, 
and only when that is zero, does exp get applied to normal total.


 This system can be applied to the existing skill system, as well as monsters. 
 I think this would also simplify the permanent exp ratios - in a sense, 
exp_loss gets limited to exp * permanent_exp_ratio - this would also mean that 
the permanent_exp_ratio can get changed on an existing server and work as 
expectedly (right now, it doesn't really, as permanent exp is added to the 
bucket as it is earned).


 I think for permanent exp servers, the output may be a bit more clear - show 
total exp earned, total penalty, and effective total.


 I also think that in many ways, this just simplifies a lot of the code.  And 
if one did still want to reduce levels, that is pretty easy - just use exp - 
exp_loss when looking up what should be the level of the skill.


 Thoughts?

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

Re: [crossfire] Account connection limit

[Mark Wedel]

On 08/ 4/11 11:44 AM, Nicolas Weeger wrote:

Hello.


Currently one account can have only one character logged at the same time.


I'd like to remove that limit, so you can play multiple characters.


What do you think of that?


 I have no issues with that change.

 Only note is that right now, there is some mechanism in place to recover 
orphaned logged in characters.  For example, your dsl modem reboots so you have 
a new IP address and the server has not detected the dropped connection yet - 
when you log in again, it will basically move the connection of that character 
to your new client connection.


 I can't remember right now where this is done - if this happens when you 
select the character, or at account login.  My only concern would be that that 
should not get broken (and at the same time, need to also make sure that the 
same character can not be logged in more than once)


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

Re: [crossfire] Face overlays

[Mark Wedel]

On 07/16/11 01:45 AM, Nicolas Weeger wrote:

   Ah - so it sounds like you are looking at one of these 2 possibilites:


snip

Correct :)




   My gut instinct is that #2 would actually be easier.  For #1, I think it
may require potentially more protocol changes (there may be issues with
number of layers, so some extension for that, and the map send code would
have to look at the object and see if that given object has overlays that
need to get sent, look those up) - I'm just not sure how efficient that
would be.



#2 seems nice too, but this also means there will be a need for many
temporary images.

Imagine the player with a basic armor, and the associated overlay. There will
be 4 (for most races) directions * 3 pictures (for most animations) so 12
composite images.

Now the player casts a spell - that's another animation, so 4*3 pictures
again.


 I wonder if the composite images could also include the animations - for some, 
that may not work if it is a single run action, but for others, one could 
imagine it would work . In particular, I'm thinking auras might be something 
animated to some degree, but the timing on those really isn't critical (if the 
aura animation is a little off from what the server things it should be, no big 
deal).


 But likewise, if the armor or weapon is animated (flaming swords, special 
armor), same thing - those are basically a loop, and if the timing is off on the 
client, no problem.


 Casting is trickier (as may be attacks), as you do those once (more for 
spells).  OTOH, attacks maybe should also be a cycle.


 So one could imagine that if you add a composite image protocol command 
(cmpimage), it could be something like:


cmpimage type[face|anim speedanimation](and repeat those)

Type could basically just describe the next set of data that follows.  If that 
data is an animation, the server would have to send the animation.  Of course 
same is true for face - if the face has not been sent, has to get sent to the 
client also.


Directions would still be an issue, as that is 4x or 8x the number of images.





So I'm wondering how many pictures that will imply at total...


One way would be for the server to find all action-related animations (so
player_fenx_spellcasting and friends) and for each regenerate temporary
faces for any face. That could mean 200 faces for a player. Maybe not that a
big evil deal...


 On the server, that is not much a concern - the amount of data for each one 
probably would not be that much (50 bytes?) A bigger concern I would have would 
be that if one used a simple method (new composite face = composite face +1), on 
a long running server,  one could go beyond 16 bits (65536 composite faces), 
which may mean that the server is unable to properly send the data to the client.


 Realistically, probably want to use a hash table that can hash the 
faces/animations for the composite image - that makes lookup much faster, and 
one could limit the hash table size to how many bits the protocol can handle 
(nearest prime less than 65535 for example).  If the hash table fills up, the 
server could basically just give up an die.


 A more complex approach could be that each client connection has a lookup 
table - while it is conceivable that the server will go beyond 16 bits, it is 
pretty unlikely that a client would see all of those.  So for each client, the 
server could literally start at zero and start increasing as that client 
encounters more and more composite faces.  But that does not have to be in the 
original design - if that proves to be an issue, it could always be added later.






Also it seems the server will need to send faces updates at almost each
equipment change. Probably not that a big deal either, but still.


 Yes - for each equipment change, there is the potential of a composite face 
protocol command.  But if the player is not changing equipment all the time (eg, 
the change in question lasts for a little time) or the player cycles between a 
few established ones (casting, combat, moving, certain aura going up and down), 
it probably would not take too long (and many composite image commands) for the 
client to get all of those, and the server now saves bandwidth on those future 
updates.  For example, if one has to send all the images that make up the 
player, than that may be 8 bytes (base + armor + weapon + aura) for that, but 
once it is established, it is just 2 bytes (composite image).  The composite 
image command itself is probably something like 20 bytes?  Protocol command 
(cmpimage?) + 2 bytes for the number + the 8-12 of the actual images.  So one 
doesn't have to use it too many times to come out ahead.



For clients not having this support, the fallback would be simply to send the
regular player face, imo.


 Yes - the only thing would be that in this case, the composite image, if it 
exists, should probably be stored in a different field in the object, and not 
replace the face - then it is very 

Re: [crossfire] Face overlays

[Mark Wedel]

On 07/14/11 06:35 AM, Nicolas Weeger wrote:

   But is the client assembling these images, or have all these images been
pre-assembled on the server (and thus, they are valid images)?


That's one my questions, and something I'm asking other people for opinion :)


Two options, server sends all needed faces at the same time (overlays to the
player face) ; or server sends a special face the client knows to be a
combination of faces.


 Ah - so it sounds like you are looking at one of these 2 possibilites:

1) Server sends all needed faces for the player - this means that for a player, 
it may have to send 4+ images for the player (aura, armor, weapon, base image) - 
of course, this could be higher.


2) Server generates a composite face, sends information on what that composite 
face is, and thus only needs to send 1 face in the protocol command, but it may 
end up sending a bunch of other information for to tell the server what that 
composite face is.


 My gut instinct is that #2 would actually be easier.  For #1, I think it may 
require potentially more protocol changes (there may be issues with number of 
layers, so some extension for that, and the map send code would have to look at 
the object and see if that given object has overlays that need to get sent, look 
those up) - I'm just not sure how efficient that would be.


 In case #2, all the map logic is basically unchanged (note that some extra 
logic would be needed to send non layered face information for old clients) - 
the generation of the composite face can all be done when the player equips the 
items/does those actions.


 But I guess it really depends on how hard it is to check the layered faces for 
an object, or maybe additional structures are needed to hold those.  I'm just 
thinking that in a more generic usage, one might want to use overlays for 
monsters (I'm thinking more for auras and not armor/equipment), so probably good 
to make sure a solution is chosen that works for everything, not just players.

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

Re: [crossfire] Compressed file support

[Mark Wedel]

On 07/14/11 07:34 AM, Nicolas Weeger wrote:

Hello.


Unless someone is totally against, I'd like to remove support for compressed
files (through open_and_uncompress_file() and friends).


I don't see the use of that feature, to be honest :)
(which AFAIK never was used)



 Sounds good to me.  That is something that was leftover from days distant pass 
where the amount of space used by those files might be a concern.  But that 
probably hasn't been the case for 10+ years.


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

Re: [crossfire] Monster regeneration

[Mark Wedel]

On 07/13/11 11:46 AM, Nicolas Weeger wrote:

Hello.

I wonder why monsters which are asleep in the dark don't regenerate hp/sp.

monster_move() is pretty clear, if the monster is asleep, can't find an enemy,
and in the dark, then no regeneration.

I'd like to change that, and make monsters regenerate anyway.


What do you think of that?


 Sounds good to me.

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

Re: [crossfire] CS_STAT_SKILLEXP_ constants

[Mark Wedel]

On 07/13/11 01:53 PM, Nicolas Weeger wrote:

Hello.


In serve/include/newclient.h are CS_STAT_SKILLEXP_xxx defines, which (from what
I remember) are for the old skill system, with only ~6 skills defined.

Those are still used by the GTK client (common/commands.c).


Unless I'm mistaking (and someone remembers better than me :)), I'll clean
that at some point in the future.


 They can almost certainly be removed.  They probably were not removed 
originally to support older servers that used the old skill systems.


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

Re: [crossfire] Face overlays

[Mark Wedel]

On 07/13/11 01:25 PM, Nicolas Weeger wrote:

   My question here is does this means that each of those combos above
(overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to
a unique face/png image on the server?


I see animations and overlays working like that:
- player has a standard animation, fenx_player
- each action (using skill or item) can have a temporary animation, like it is
currently ; thus fenx_player_sword or fenx_player_spellcasting
- each equippable item defines an overlay ; so armour would give the
overlay_armour face on top of the player's face

Of course, items can be specialized for player ; so overlay_armour could be
overlay_armour_fenx_player_spellcasting for a specific spellcasting
animation, or overlay_armour_fenx_player for the general armour.


With fallback so not have to explicitely define everything.





   Or is there some level of trickiness going on with how the client
assembles those faces?


I see it merely as adding new pictures on top of the player's main face.


 But is the client assembling these images, or have all these images been 
pre-assembled on the server (and thus, they are valid images)?


 If the client is left to do this layering, then somehow, it needs to know what 
faces to layer for any given object (typically players, but one could see reason 
to add this to monsters).


 From my reading, which could be wrong, it sounds like the server would have 
these composite images - thus, the server itself would have a lot more images, 
but really no change in the protocol is needed - the server would just know to 
use different faces and send those to the client, which would just display it.


 For a small number of combinations, that works pretty well.  But if you start 
to have multiple things you may layer, the combinations multiply up pretty fast. 
 For example, weapon + armor + aura could be hundreds of new images (say 5 
weapons, 5 armors, and 5 auras = 125).  These would all have to either be images 
in the arch directory tree, or created during the collect process.


 I'd personally think that having the client do the layering would be much 
better - one could have the number of combinations be much larger without having 
issues (eg, 10 armors x 10 weapons x 10 auras x 50 monsters = 50,000 image combos).

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

Re: [crossfire] Face overlays

[Mark Wedel]

On 07/11/11 01:17 PM, Nicolas Weeger wrote:

Hello.


I've been thinking on how to show what equipment a player is actually using
during the gameplay.


My current idea is to add overlays on faces.


It would work something like that:
- base player animation doesn't show anything
- the eg armour overlay is displayed on top of the player, to show the
armour being worn
- for compound animations (eg attacking, and thus), use the same overlay, or
a specific overlay


This could also be used to add effects for long-time spells, eg a red aura for
protection from cold, and such.


Examples:
- base animation fenx_player
- for armour, use overlay_armour_fenx_player if it exists, else
overlay_armour for an armor with overlay_armour overlay specification
- if the Fenx attacks, compound animation is fenx_player_sword, so use
overlay_armour_fenx_player_sword if it exists
- if the Fenx cast the rage, add overlay_rage_fenx_player if it exists,
else overlay_rage simply


This would of course mean many potential animations... And more face
information sent to the client.


 My question here is does this means that each of those combos above 
(overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a 
unique face/png image on the server?


 Or is there some level of trickiness going on with how the client assembles 
those faces?






One other option I thought of is to use a dynamic face, in which server
tells the client face (max_face + 2) is a combination of this, this and this
face, use this special face for the map2 command, and inform client of face
changes when the equipment changes.

This of course adds some more complicated logic.


 Answer to the above question sort of determines that answer.

 Using a unique face (max face +2, +3, +4) probably isn't as hard as one might 
think - if that face is created (and assigned to the player) when the objects 
are equipped, most of the sending logic remains the same - the only additional 
logic would be to communicate what faces make up that unique face value.


 The method used to currently inform about animation sequences could be used, 
just with the addition to say 'this is a composite face, not an animation'.  The 
one advantage I see with this approach is that a lot of the code can be re-used.


 For example, the elf equips a sword.  The server sees if there is any 
animation stacking already created that matches - it finds there is none, so it 
creates elf_sword, and at the given time, sends it to the client.  The elf then 
casts a protection spell, which adds an aura around the player.  Once again, 
server checks, finds no such animation, and creates a new one (elf_sword_aura), 
which gets sent to the client.  Now at some point, the spell expires, so now we 
are back to just elf_sword - server checks, it already has this, so it just 
updates the fact to that value, and is done.


 It would be the actual map sending code which would see if the client (which 
may not be the elf players client, but another players client) knows about that 
animation, and if not, would do the normal routine to send the animation 
information as well as information about the faces.


 Note that the animation names above are really used for illustrative purposes 
- I think when it comes time for the server to see if it is new or old 
animation, it would have to check the actual image numbers, and not go on name.


 The compositing of images probably becomes the harder case - in your example 
above for armor, this means you need different armor images that will properly 
overlay on the given race - for small and big ones, this probably does not work 
very well.


 For more generic things, like auras, size on those is not as important, so 
they probably work in all cases.



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

Re: [crossfire] Ground and container view

[Mark Wedel]

On 07/10/11 03:20 AM, Nicolas Weeger wrote:

Hello.


Because I use JXClient which displays contents of a container like the ground
view, I changed the server to enable browsing container items like the ground
view, with arrows for next and prev group of items.

I just realized the GTK client displays contents of a container as children of
that container, instead of the ground view.

Thus my changes conflict with that, and introduce paging for GTK when there
was none.


Now I'm wondering, GTK doesn't limit the number of displayed items in
containers but the server does limit to 50 the number of items in the ground.


This behaviour doesn't make sense IMO - either the ground should display
everyhing like containers, or both should be browsable.



So I'm wondering what's the correct fix for that:
- should server limit items for ground and container view? if so then clients
should be adjusted
- should there be no limit? note that currently the server will limit to 100
for ground view, but no limit for containers...


 So to go into some background on this:

 Way back when, the ground view would display all items.  The problem was that 
if the item had a huge number of different objects (typically in apartments), 
the amount of data that needed to be sent for a ground view was large enough it 
would overflow the output buffers on the server.  The server catches than, and 
presumes it is a slow or otherwise poor client, and drops the connection.  So 
users would get into cases where when they moved onto such a space, their 
connection would just drop.  The solution to this was to limit the amount of 
objects we send at the ground view to 50.  That number was arrived at through 
some analysis based on size of ItemCmd, and I also believe that for non image 
cache users, how much image data might get sent.


 Now containers (and for that matter, the players inventory) could have the 
same issues.  I suspect they typically don't because there are limits on amount 
of stuff (based on weight) that can be put into a container or the players 
inventory - this effectively puts some upper limit on number of items.  Now it 
certainly is possible that this number of items could be too large, but it just 
doesn't seem to happen much.  I suspect some of this may be because in the case 
of inventory of containers, the objects may share the same image much greater 
than the pile of artifacts in the players apartment.


 I also believe that the socket logic has been improved since the original 
problem, such that the server has additional buffers and thus more data needs to 
get generated before the buffers fill up - I think when the problem originally 
happened, the server was just using the size of the OS's buffer, which was 64k.


 So to answer your questions:

I believe there should be no limit for number of objects in ground view - the 
reason that limit was put in place was due to socket limitations, which _may_ no 
longer exist.  However, there could still be potential cases where a limit is 
reached - 1000 objects, or 10,000 objects etc on a ground space may go above 
even the larger buffers now in place.


 For containers, if this was an issue, a limit could be put on the number of 
different objects in a container beyond just weight (limit it to 100 or 200).


 Forcing cache mode for clients would also help this - the amount of data in an 
itemcmd isn't too large - maybe couple hundred bytes (assume 256)?  So 200 * 256 
= 64k  It is when sending images (and potentially animation sequence, such that 
one objects may be 4 images) that you really start using up space.


 In the ideal case, the server really shouldn't care anything about containers 
or ground view.  What I mean by this is that the client would have the contents 
of the container, and it is totally up to the client on how to display that (in 
the ground view, as a child, as a pop up window, etc).  The extent of this would 
be that when the player activates a container, the client would send a request 
to get the contents of the container.  The client could in fact send such a 
request for all containers in the players inventory when the user logs in.


The server would have to some sanity checking in this case (can the player in 
fact open this container (locked chest for example)).  Likewise, whenever the 
player tries to use an object, it would have to same level of sanity checking 
(is this container still accessible to the player, and can the player still 
access it (did not leave the key behind)).


Likewise, some method of moving entire contents of one container to someplace 
else could be done - right now, that seems to be done based on active containers 
and open containers, if the container is on the ground or not, etc - basically, 
the client doesn't have anything to do on it, and I think the client could be 
designed to have a much better way to do this (the client could right now 
iterate through all the items in the container, but ideally 

Re: [crossfire] Materials

[Mark Wedel]

On 06/26/11 05:28 AM, Nicolas Weeger wrote:

Hello.


In the code is support for NEW_MATERIAL_CODE.


Enabling it randomizes the material for many items, leading to proliferation
of items with different materials and properties (more damage to weapons,
different resistances, and such).


Material support is half-written for multiple combinations (iron + paper for
instance), but not totally everywhere.


I wonder whether to enable that (extended material) support by default and fix
issues, or totally remove it.


 Leaf did pretty well summarize the issues, but there was another annoyance I 
found with it:


 For most items, the material made very minor difference.  So following on 
Leaf's example, no only would you have 6 different boots of speed (instead of 
them stacking), but save for maybe 1 point of resistance here or there, or one 
being a little bit lighter, they were all basically the same.


 So you got a lot of inventory clutter for very little gain.  And the way the 
code work, it would find something of 'iron', and then randomize the material 
for all the things that could be iron.  Some materials might make a difference 
for armor, but not weapons, and vice versa, but the material code itself had no 
way to restrict that. so you would have 6 times of metal armor, with maybe only 
one or 2 of the materials being different enough to really care about.


 So I would say that the material logic could be removed.  If one was to 
improve it, these are my thoughts:


1) Make it more like the artifact code, where one can restrict it to different 
items.  Thus, a yew bow may be really good, so you would find normal wood bows 
and the better yew bows, but wouldn't find pine, spruce, etc.  OTOH, this starts 
to look like just another stack of item bonuses, and is it worth it to do it via 
material instead of just making some bows better and in the description say they 
are made from yew?


2) Ability to regionalize materials.  It might make perfect sense in the area 
far to the north where only pine trees grow that the vast majority of wooden 
items would be pine, in a jungle area, bamboo, etc.  That would sort of 
eliminate some of the stacking problem - since you would typically do your 
adventuring within an area and then go to the shop to sell at once, most of your 
items would be made from the same local material.  But even then, I would have 
to ask if the changing of materials really gains that much?


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

Re: [crossfire] Interview for Gamasutra Article on Open Source Games

[Mark Wedel]

On 06/20/11 03:19 PM, Michael Thomsen wrote:

Hi there,

I'm a writer in New York and am working on a story for Gamasutra about open
games. I'd love to include some discussion of Crossfire both because of how long
running it's been and for how dramatically it seems to have changed over the
years. It would be great to speak with someone by phone or email or whatever
format's most convenient about the roots of the game and how it's changed over
the years.

Would anyone be available for, say, a 20 minute call or maybe some email 
questions?


 I could certainly take e-mail questions, phone may be a bit harder as my 
schedule is a bit chaotic.  Could probably also some form of on-line chat, since 
I am more likely to be able to squeeze that in.

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

Re: [crossfire] Make start maps unique

[Mark Wedel]

On 03/16/11 03:48 PM, Nicolas Weeger wrote:

Hello.


Unless someone gives a good counter-argument, I'll make the
/start/newbieshouse a unique map (from the Nexus).

The rationale is that there are things to do, books to read, monsters to kill,
traps to find, so it's logical the map is always ready for new characters (and
no, fast reset times don't count IMO).


 That seems completely reasonable.



I'll also add it to the map choice in the character creation (this'll require
changing the mechanism to handle unique maps), maybe replacing the Nexus map
- since Scorn and Navar can be reached from the starting map choice.


 I wonder if some hook/plugin should be used to delete that unique map once the 
players leave it.  The problem with the unique maps right now is they sit around 
forever (unique  permanent) - but for something like the newbiehouse, probably 
no reason for that to be true (I'm not even sure if one can get back to it after 
really starting play)


 That said, for modern systems, the amount of space those unique maps would 
take would be pretty trivial, so probably not that big an issue.

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

Re: [crossfire] Player creation bug

[Mark Wedel]

On 02/13/11 03:47 AM, Tolga Dalman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

currently, the player creation in crossfire 1.60 is broken.
You can reproduce it by doing the following with the
crossfire-client 1.60:
- - create new character: fire hatchling/monk
- - maximize str, dex and con
- - set remaining stats so that they are 1 in total
- - distribute the remaining points to pow

This will fail, because the stats are checked after applying the
race (but not the class). The attached patch fixes this issue.


 I'm not quite sure if I understand the problem or not.

 I tried to do that, and got a message saying stat to low.  That is correct 
behavior IMO.


 The old rolled method would allow for class combos where the minimum stats 
were not meant - that is no longer allowed, and that was an intentional change - 
since the player can distribute points, they can more easily make sure they meet 
the minimum values.


 I also think this is needed for balance - if a class has a big stat penalty, 
you need to spend some points to offset that penalty.  If one does not need to 
spend any points to offset penalties, then the penalties become a lot less 
meaningful (don't put any points, and the fact there is a -8 penalty doesn't 
mean anything)




Being on this topic, I have some suggestions for the crossfire-client.
I think it is already pretty good, however for a normal user like
me it is quite difficult to create a character in a sane way.
So I suggest:
1. add descriptions for stats (e.g. tooltips).


 Already there - at least they work for me.


2. make the stat number field read-only (this feature is actually not useful,
but rather confusing and error-prone).


 Entering stat numbers by hand works (I presume you mean the base attribute 
value).  Maybe it was just my testing, but I often would just enter the numbers 
directly vs using the spin wheels.



3. when selecting a race or class automatically update the stats to the required
minimum values. Also, these values should become constraints, i.e. pushing
the '-' should not yield in stats lower 1.
4. disallow negative unspent stat points. This should be a simple check in the
'+' buttons.


#3 is perhaps reasonable - I'll defer that to the community.  My initial thought 
was that if one wanted to look through the different races and classes, one 
might want to be able to see those different choices without it messing with the 
values one set.


 For example, one might be making up a barbarian, and current has human.  Given 
this is a barbarian, str, dex, con are maxed, remaining points in cha, and 
int,wis,pow are minimum.


 I might then decide I want to see what things would look like if I did a troll 
instead.  If select troll increases the base stat values, it means I just can 
not go back and select human (after deciding I don't like troll) and get those 
same values back.


 And conversely, on point #4, that compounds the issue.  Eg, I select troll, it 
updates the stats to minimum values - now I have negative stat points.  So now 
it goes and decreases the high stats to make things legal.  If I go back to 
human, then those stat values are really nothing close to what I had put in before.


 I'm not 100% sure what is the best way here - each one has its pros and cons. 
 My initial implementation of that was to make it very easy to experiment with 
different combos, which means it does allow illegal values when playing around.




5. Choose starting map should be replaced by the actual drop-down menu with
Scorn as default value.


 I had issues fitting the description in.  I had also thought that maybe at 
some point, that even gets extended with an image of some sort representing the 
map choice.

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

Re: [crossfire] Skill thoughts

[Mark Wedel]

On 02/21/11 01:14 PM, Nicolas Weeger wrote:

   I finally got around to recording my thoughts on a revised skill system:



What is the planned implementation timeline?


 I'm always bad at estimating how long things will take.

 What I really want to do next is write up brief descriptions of the skills, 
possible special abilities, etc, they give, and probably combine some skills 
while I'm at it.


 For example, I'm think that detect magic and detect curse, as too different 
skills, would really never be worth spending points on (above getting it 
initially), but if those are combined as perhaps a general identification skill, 
it might be.  But in that model, it would be not as good as the specific item ones.


 For example, with smithery, you might identify weapons/armor of level less 
than your skill.


 With general identification, it might be items less than 1/3 or 1/2 your skill.

 Likewise, combining singing and oratory would make sense to me - it is easier 
to calm monsters than make them friendly, so same skill could have different 
effects.





I'm wondering whether it's worth fixing (or at least trying to fix) existing
monsters with the current system, or just waiting for the new one.


 It probably depends what is wrong with them.  While ideally monsters will 
follow the same rules for players (and thus have same skill with special 
abilities, etc), I don't necessarily know if that would be something I'd do in 
the first pass - I'd much rather get the new skill system really sorted out for 
players and then tackle adapting monsters to use it.  I'll note that many games 
don't actually make any attempt for the monsters to follow all the same rules 
for players.  But once the player stuff seems fairly well balanced, then 
apply/converting monsters to use that would start (I'm not 100% sure if it would 
make sense for all monsters to use that system, but that could get sorted out at 
that time)


 So things like hit points, damage, resistances would all be things that would 
still get used under the new skill system.  Level would still get used as a 
starting point for any conversion.


 But in any case, I do want to write up some more details - its much easier to 
spend an evening or 2 writing up some ideas and getting a better idea if they 
work than to code them up.






Note that of course I'm ready to help implementing that, and others may be
too.


 Thanks for the offer - the problem I keep facing is feature creep - if skills 
are going to get redone, and attributes redone, should resistances be tackled at 
the same time?  What about spells?  At some point, it ends up being a big task, 
but maybe that is also needed to really get balance/playability back - a lot of 
things currently in the game were added one by one (new skill here, new spell 
there, new artifact over here) without any real central idea of how everything 
should work together.


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

Re: [crossfire] Skill thoughts

[Mark Wedel]

On 01/28/11 10:25 PM, Mark Wedel wrote:


I finally got around to recording my thoughts on a revised skill system:

http://wiki.metalforge.net/doku.php/user:mwedel:skills

Take a look, let me know what you think - as the bottom of the article says, I
have no immediate plans to implement it - it is mostly thoughts that have been
bouncing around my head that I wanted to record someplace.


 Just a note, I've added an attribute section to that, since to balance any 
system, how the attributes (and their bonuses) has to be thought out/balanced 
also.  IMO, current system is not balanced due to large bonuses some high 
attributes get and fact they are applied to first 10 levels.


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

Re: [crossfire] 1.60 release thoughts

[Mark Wedel]

On 02/ 6/11 01:57 AM, Nicolas Weeger wrote:


- At some point, the legacy character creation code should get removed, and
related, basically all the ST_ values/player_set_state().


Makes sense too. Many commands (join party, form party) should be first handled
by client to get player's input.
Note that there'd be some return value for commands, eg join partyname
with a return value of -1 wrong password so the client can display the
password prompy.


 Right - in the account management code, I added the ability for the server to 
send back failure responses, and that same logic could get used here.


 In fact, many commands that take such input may have failure scenarios - 
create party could still fail if that party name already exists.




- For ChangeLog/CHANGES file:  I suggest the ChangeLog file get generated
by svn2cl - this is already done for maps.  But each area also has a
CHANGES file, which updated by hand but is used to note
improvements/things of more general interest - hard to say where to really
draw the line, but reformatting, minor bug fixes would not go in the
CHANGES file - big features would.  Maybe the determination is anything
that actually affects gameplay?  Thus, bug fixes wouldn't typically get
put in (they may change gameplay because someone is exploiting a bug).
One reason I bring this up is that with the maps ChangeLog file from SVN,
really no way to get any real useful content from that - I pretty much
used the crossfire traffic - it is that type of stuff that could perhaps
get put in the CHANGES file.



I think the manually made file should only list significant (and maybe only
player-related?) changes, not all the minutia we have now.
So crossfire-traffic would just be a copy of that file.


 Yes, that is what I was thinking - it is just never clear how significant 
something should be.  But that can be left up to the developer


 I'd argue that there could be significant changes that are made (and worth 
noting) but that don't really directly impact the player.  EG, if someone fixed 
some serious crash bug or made major performance improvements, that is probably 
worth nothing in the CHANGES file, even though as players see it, that impact 
may not be so great.

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

[crossfire] 1.60 release thoughts

[Mark Wedel]

 1.60.0 is close to being out the door, it might be by the time you read this 
message - after doing it, I've had various thoughts:


- With SVN tree, all computer generated files get removed - I think the only 
thing really left is some of the macro files - since developers out of SVN are 
going to need autoconf/automake, pretty likely they will have 
aclocal/libtoolize, etc (in fact, I think those later ones are in autoconf or 
automake packages anyways)


- Within the file release on sourceforge, I think it makes more sense to just 
have the version directories at the top (eg, 1.60.0, 1.50.0), and then under 
each one, put all the associated files - server, maps, client, different clines 
(linux, windows, java, etc).  That would certainly be easier to navigate - very 
clear what the latest one is and no hunting for files.  If we do get the case of 
some files not released (lets say we do an interim 1.61.0 for clients but not 
server), the readme there could note to use the 1.60.0 server.  Thoughts?  This 
becomes perhaps more relevant when jxclient and gridarta are added, as then 
there are lots of top level items.


- At some point, the legacy character creation code should get removed, and 
related, basically all the ST_ values/player_set_state().  Anything that should 
have confirmation should be handled on the client, eg, if creating a party, 
should be an interface on the client to do that, which confirms the party 
password (and throws up an error if a mismatch), and it just sends the command 
to the server - maybe a protocol command for that, but there really isn't any 
reason password confirmations should be handled on the server.  This just makes 
a much cleaner design  - if a character is logged in, they are always playing.


- For ChangeLog/CHANGES file:  I suggest the ChangeLog file get generated by 
svn2cl - this is already done for maps.  But each area also has a CHANGES file, 
which updated by hand but is used to note improvements/things of more general 
interest - hard to say where to really draw the line, but reformatting, minor 
bug fixes would not go in the CHANGES file - big features would.  Maybe the 
determination is anything that actually affects gameplay?  Thus, bug fixes 
wouldn't typically get put in (they may change gameplay because someone is 
exploiting a bug).  One reason I bring this up is that with the maps ChangeLog 
file from SVN, really no way to get any real useful content from that - I pretty 
much used the crossfire traffic - it is that type of stuff that could perhaps 
get put in the CHANGES file.



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

[crossfire] Skill thoughts

[Mark Wedel]

 I finally got around to recording my thoughts on a revised skill system:

http://wiki.metalforge.net/doku.php/user:mwedel:skills

 Take a look, let me know what you think - as the bottom of the article says, I 
have no immediate plans to implement it - it is mostly thoughts that have been 
bouncing around my head that I wanted to record someplace.

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

Re: [crossfire] Balance ideas

[Mark Wedel]

On 01/ 8/11 02:54 AM, Nicolas Weeger wrote:
Yes - that is reasonable.  But I also wonder if there is/should be a way
 to increase potency at the expense of sp cost.

Taking that fireball example, changing the weighting would more or less
 keep the sp cost the same - but the power of the fireball itself does not
 change all that much.  But maybe there are some modifiers which increase
 the power (eg, damage, duration, range), but also drastically increase the
 sp cost - if you want to try and emulate current spell effects, your sort
 of need this.

Otherwise, just by changing weighting, you will never be able to get
 something as powerful as a large fireball currently is - but at the same
 time, the large fireball itself is higher level and costs considerably
 more sp (base 16 sp vs 6).

 Which is why I mention that possibly the sp cost is a weighted combination of
 the various weights, so you can make power more expensive that radius, for
 instance.

  Right, but I think for that to really work (get desired effect), you may need 
to do something beyond weighting - adjusting the weighting itself may not 
change 
some parameters enough.  You might almost need some modifier which does 
something like (range+1) at some increased cost of SP.


This is just my preference, but at some level, it is nice to have things
 to try and achieve (once I get 10th level, I can cast this cool spell) -
 if number of spells is drastically reduced, I have a feeling that effect
 would also change.

 So make fireball a level 1, comet a level 47, meteor storm a level 80. That's 
 a
 challenge to reach 80 to get really powerful meteor storm spell :)

 Or there could be steps in increase, ie from level 1 to 10, fireball has a 
 base
 power of 3, from 11 to 20 5, and such, with some big steps along the way.

  Yes - that might work.  I was more just thinking about the idea of learning 
spells.

  On a similar note, I think it would be interesting to have most all skills 
give some new benefit once in a while, eg, for melee skills, maybe at higher 
level, there is a chance of stunning on opponent - for thieves, extra damage 
would make sense, and so on.

  Those wouldn't as much be about balance (those extra effects a fighter has 
may 
make things a little easier, but not a lot), but more about cool new things - 
eg, 'that is something I couldn't do before'.


 Or add a fire mastery skill, that will increase the power or radius when you
 gain it.

  That might also work.  I wonder if one could even do something like that for 
spells - have a 'beginners version', 'expert version', 'master version', 
'grandmaster version' type of things.  Maybe the higher versions have an 
increase in base damage or something else - I don't know.

  On a side note, I think it might be better to remove the sp adjustment based 
on level.  Eg, that basic fireball will only cast 5 sp, whether you are level 1 
or 50 - presuming no modifiers.  It is just odd now that based on when cost 
increases, one could gain a level but effectively cast fewer spells because 
their cost has gone up.



 Note that the whole global balance requires some heavy work on item_power.
 I'd definitely see good weapons over 30, just to require a player to be high
 level and not a low one.
 Same would be for armors, a 1-40 item power doesn't seem too weird. This would
 force players to compromise on the equipment.

  Yes - in some places, this is easy to fix - any pre-defined weapon (eg, it is 
set in a map) can have the item power set appropriately.

  A problem is for the random items that are generated - it can generate things 
with potentially wrong values (wrong in the sense it is too high or too low) - 
that is because it uses a fairly basic formula which is always hard to adjust 
to 
be perfect (some attacks are more important than others, etc).

  On a vaguely related idea would be to change the entire basis on how weapons 
are improved (armor also, but that is more limited right now).

  Many games have the idea of runes/sigils/whatever that improve items, but the 
item has a limited number of slots to hold these.  These sigils are also 
found/recovered from items during adventuring.

  In some ways, this is more interesting than current method which just 
requires 
large amounts of wealth - you need to find both the base item you want to 
improve (better one may have more slots, as well as just have more base slots) 
as well as the sigils themselves.  But that probably starts to stray away from 
balance, other than the fact that the current weapon improvement scheme 
probably 
has balance issues right now.

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