Re: [crossfire] No autogen.sh for the client?

[Mark Wedel]

tchize wrote:



Speaking about automake.

Since a few week i noticed each time i do a commit, all the Makefile.in are 
commited along. Did someone change the configure script to regenerate 
automake.in file each time a ./configure is run? If that's the case, maybe 
removing Makefile.in files from cvs would be a good think (if they became 
machine dependent, there is no reason to keep them in CVS)


 Some file is out of sync, so it keeps re-running automake.  One would normally 
thing this should correct itself once the up to date ones are committed.  Maybe 
something that the makefiles depend on was committed with a bogus date.


 The rationale for having the Makefile.in's in CVS is to make it easier for 
users to grab snapshots and not need a large set of tools.  Ideally, this 
dependency should get fixed up somehow so that it doesn't re-run automake every 
time.



___
crossfire mailing list
[EMAIL PROTECTED]
http://mailman.metalforge.org/mailman/listinfo/crossfire

Re: [crossfire] ingame music

[Mark Wedel]

Andrew Fuchs wrote:

On 6/2/05, Mark Wedel <[EMAIL PROTECTED]> wrote:


 The obvious question for this is how to handle it.

 Would it be sufficient to have map wide values of 'music' to play, such that
we just need to add a value to the map header?  Or do people see the need/desire
that they may want different music depending where on the map they are?

 I'd separate this discussion from that of background or other noises, of which
those should be tied to objects.  But something like this music wouldn't seem to
be tied to any specific object.



Yes, having the value in the map header is mainly what is needed,
though hijacking the lighting code would be the way to go for
connecting it to specific objects.


 Perhaps, but not positive if that will work.  Lighting is just a single value. 
 If you try to hijack that code for music, you will get cases of two sources 
overlapping, so that single value doesn't work - you then need to store both 
sources or figure out which is louder or something.




There is also the posibility of adding fields to triger sounds when
items are applied (not hard coded like the current system).


 Yes, and that is on the TODO list.  But that is seperate from music, because 
those are mostly going to be things that get played as direct result of actions 
and not persist in the background for ever (although there are perhaps some 
sounds that should).



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

Re: [crossfire] ingame music

[Mark Wedel]

Brendan Lally wrote:


This is a limitation the lighting code could do without also. If such a
mechanism were used for the sound code anyway, then it could usefully be
extended to the lighting code to allow coloured lights. I don't know how easy
it would be to implement client side, but it would be a nice way to give
feedback on some levels, or create interesting optical effects.

The easist thing to do in that case then would be to store RGB values in the
stats for the light object, and then when they overlap have the resulting
colour be the weighted mean in each value. (based on proximity and strength
of source).


 Having the server figure out the color for each space is a complication it 
doesn't need.


 If/when colored lighting is added, it will be handled by the client.  The 
server will still figure out what spaces are actually visible based on lighting, 
but won't care about the color.


 Conversely, the client should be able to apply properly lighting techniques by 
knowing where the light sources are and drawing properly shaded/dimmed circles 
of the right color.  This will just allow for better handling of lighting in any 
case - right now, all the lighting mechanisms for the client are a bit of hacks 
and add a lot of complication in trying to figure out light value for all the 
spaces.



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

Re: [crossfire] new metaserver

[Mark Wedel]

tchize wrote:

Le Jeudi 2 Juin 2005 09:20, Mark Wedel a écrit :



1) Has someone agreed to run the metametaserver?  What about the slave
metaservers?  While all this looks nice, if you don't have people willing
to run it/take care of it, it is all pretty pointless.  For the
metametaserver, I'm thinking more of the Tanner's, since they currently
hold the main crossfire home page, but of course, the metametaserver could
move someplace else (not as sure how many people have as stable and ip
address and network connection that they do).



That's were a static list on various website is usefull, easy to place 
(crossfire.sourceforge.net could be a place to hold the list)


 Yes, but a static list != metaserver.  That is a seperate issue.  Certainly, 
having static lists isn't a bad backup plan, but isn't really the same thing.






2) having the clients connect to the various servers to get stats like
current number of active players is IMO an extra level of complication that
can be done without.  If we have a dozen active servers (which was actually
low if I recall), you probably don't want to do it sequentially - that
means it coudl take a significant amount of time to go through them all. 
Especially if one is down or unresponsive.  this means you need to do it in

parallel, and writing that threaded code is a bit more complicated.  Add to
the fact that the client would then have to send some commands and parses
the responses from the server. I just don't see any reason that dynamic
info shouldn't be included.



could be done in udp (send a packet to each server than wait 2 second for any 
response)


 udp is probably not a good option.  Most peoples private firewalls will 
probably not work in that setup without changing the configuration (they'd need 
to be modified to let the return udp packet through the firewall).  So from a 
client perspective, we really want to just stick to tcp.



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

Re: [crossfire] new metaserver

[Mark Wedel]

 As asked, here is my thought on this.

 To make typing this easier, CMS = chief (core) metaserver. SMS = slave 
metaserver

 There is one CMS.  All crossfire servers that want to be listed in metaserver 
output send there data to this server (exactly how - udp/tcp, and what to send 
is an open issue.  My thought is that the server should send most every bit of 
data the might be useful - after all, it's only sending an update packet once a 
minute or something, so the amount of bandwidth for that is trivial).  My 
thought is also that this should be an actual daemon like program - I think 
having it be up holds some advantages.  One being that the connections from the 
servers to it can be persistent (presuming tcp here) - that makes things a lot 
easier on the server side, and also replication side.  The only sites that can 
request data from the CMS are trusted SMSs.  The CMS serves the data in a 
relative raw format.  The CMS would also provide information on the SMS's, just 
like the server (haven't got any requests from this SMS for a while, etc).  The 
new CMS would need to be a bit more robust than what is there now.


 There are numerous SMS's.  The clients talk to one of the various SMSs.  These 
SMS's talk to the CMS to get their data.  The ideal case, IMO, would be for the 
SMSs to also be persistent program, and thus could just have a tcp connection to 
the CMS.  However, probably not any reason that the CMS couldn't just to a 
connection to SMS, get data, close connection.  Thus a php script could be 
written to get this data.  Probably a reasonable idea for the SMS to at least 
potentially be web based.  Depending on the web server and access a person has 
to it, the way it gets data could vary.


 For example, a php based one would just contact the CMS periodically (not 
necessarily every time it gets a requests - presumable it should have a cache 
file it uses - if the cache file is too old, then it gets new data from the server).


 For other people, that can actually run scripts on the web server, they can 
perhaps have a persistent script that is in contact with the CMS, and just gets 
the data and stores it as static pages.


 The client would ship with a file that lists the current SMS's as web 
addresses (given different people host them, you can't just have a URL like 
http://myhost/cfservers - people may need to do things like 
http://myhost/~username/cfservers or whatever).


 The SMS would have two bits of data from the CMS - the list of all the servers 
and their stats, which has obvious usefulness.  However, it would also have a 
list of the other SMSs, so that the client can update its lists of what SMS's 
are out there.  Thus, as long as a client can find one SMS, it can talk to it, 
and now get an updated list of all the new SMS.  Thus, as SMSs come and go, the 
client will automatically keep up to date and not have to rely on some other 
external site.


 If the CMS is down, the SMS's just serve the last data they have.  This data 
will eventually become stale, but with very limited traffic going to the CMS, I 
think DOS attacks against the CMS are much less likely.


A few other notes:

An agreement/usage policy for people that want to be SMSs is probably in order. 
 Probably the main bit of that policy is that it won't abuse the CMS (eg, 
behave correctly), but also that it has to serve the data it gets from the CMS 
in basically an unaltered state (can't drop servers it doesn't like, can't 
add/fake servers it does like, etc).


 Also, relative to the client getting the data, it should be served up in a raw 
form (eg, not html, but something easy to parse).  That said, the CMS can also 
make html output if it so desires, but that would be for human readable format, 
not for the clients.


 I think this takes various bits people have discussed but with some changes.


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

Re: [crossfire] Spellcasting Swords progress

[Mark Wedel]

Alex Schultz wrote:
I'm trying to insert a rod into the sword, where the rod has a spell in 
it (I've usually done that with the old style spell numbers in my tests 
which the server seems to nicely convert). For example, I make the 
following treasurelist which is in the "randomitems" of the sword arch:


   treasureone katanafire
 arch rod_light
 sp 82
 level 15
 hp 50
 maxhp 50
 no_drop 1
 no_pickup 1
 startequip 1
 chance 100
   end


 That is not valid syntax for the treasures file.  You can not make changes to 
the archetype in the treasures file.  I imagine if you watch the server startup, 
you'd probably see a bunch of error messages related to that.



I tested it putting the sword on a map and that works except for the 
above mentioned information loss. However when I tested it by using the 
DM "create" command, the randomitems were not obeyed.


 If you use the map editor to create the sword, put the rod in the sword, and 
put a spell in the rod (clear out randomitems from the rod), then it should 
work.  If that doesn't work, I'd consider it a bug.


 I don't remember for sure if the dm create command actually does all the right 
thing, regarding setting up the treasure lists.




I assume this information loss is because the treasurelists don't accept 
such data and only use the defaults of the arch, so one solution would 
be creating an arch for each rod that I want to use on the swords, 
however I feel that would be a bit kludgy, and I am wondering if anybody 
has any better solutions.


 That is one solution.  But is your goal to make these show up randomly?  Or is 
your goal to put these on a few special maps?  If the later, then see my note above.


 The other possiblity would be to change the code, so that the sword itself can 
act as the caster object.  I'm not sure what changes would need to be made - 
perhaps not too many.  The real complication here is that for weapon 
improvement, it probably uses some of the same fields as you'd need to it to be 
a casting object.  The simple solution this is that spell casting weapons can't 
be improved - then you don't have to worry about that conflicting use of fields.




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

Re: [crossfire] Spellcasting Swords progress

[Mark Wedel]

Nicolas Weeger wrote:
 The other possiblity would be to change the code, so that the sword 
itself can act as the caster object.  I'm not sure what changes would 
need to be made - perhaps not too many.  The real complication here is 
that for weapon improvement, it probably uses some of the same fields 
as you'd need to it to be a casting object.  The simple solution this 
is that spell casting weapons can't be improved - then you don't have 
to worry about that conflicting use of fields.



I propose an option, but it's a long-time goal as it implies to refactor 
many parts of the code. It's a rough proposal.


The idea is to replace the 'type' field (which stores only one value) 
with a binary value, flags indicating what the item can do.

So you could have 'is_weapon 1', and 'cast_spell 1' at the same time.
Of course arises the issue of the different parameters of the item 
(spell points, and so on). Let's put items in the inventory, with a 
special flag ('is_parameter 1') and the associated specific flag.


Thus you'd have: (* = item, + = parameter)
* sword
 + is_weapon 1
 + casts_spell 1
 * sword caracteristics
  + is_parameter 1
  + is_weapon
  + wc
  + damage
 * spell caracteristics
  + is_parameter 1
  + casts_spell 1
  + sp
  + level

Drawback, there will be many flags (basically one for each item 
type...). Also requires to convert all existing items (argh), and fix 
all maps (argh again). Can probably be done incrementally, ie let server 
convert at load time.
Also it may slow the server, as there's a need to find the item 
parameters often.


 In addition to ones that have to get updated, presuming that we don't reset 
the server, also need to update all player files as well as their apartments.


 The idea has merit.  The problems are as you discussed.  Also, you end up 
needing a lot of flags to accurately describe items.


 For example, cast_spell isn't good enough right now to cover the spellcasting 
objects (potions/scrolls, wands, rods).  For potions & scrolls, you'd need 
something like the is_used_up flag - that already exists - to denote the item is 
used in casting.


 for wands, you need something like an is_charged_item flag, to denote it has 
charges.


 For rods/horns, you need some other flag to denote that it regenerates sp.

 But the biggest problem is that you describe - the fact that the structure 
fields often overlap.


 At some level, the approach that Alex is using isn't a bad one - put an object 
in an object in an object.  The real problem is that the treasurelist doesn't 
allow setting attributes for the objects.


 It could be intersting, for more than this case, to be able to specify 
archetype type parameters in the treasurelist (the treasurelist basically holds 
a copy of the archetype that could be modified).  This actually makes the 
treasurelists much more extensible.




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

Re: [crossfire] Spellcasting Swords progress

[Mark Wedel]

Alex Schultz wrote:

I'm trying to make it show up randomly. Since the e-mail you're replying 
to, I've found a nice solution: create another python script that runs 
when it's applied which generates a rod if it doesn't already have one, 
and it is generated based upon parameters given the event options of the 
script. This seems to work quite nicely, and and still allows map makers 
to just put the rod in via the map if they want (which I see as easier 
for map makers).


The only issue I'm running into now, is where the best place to insert 
such items into the treasurelists to make them randomly appear. I do 
know of several places that would work technically, but I'm not sure 
which is the most proper and from what I see chance values add up to 100 
so I would have to change existing ones so I'm not sure of the best way 
to do that.


 Probably best to find existing weapons in the treasurelist and reduce the 
chance of those.


 Note that the total value of the chance fields in a treasurelist does not need 
to be 100%.  Look at the doc/Developers/objects for more about treasures.  Briefly:


If if it is a 'treasureone' type list, one item is generated.  At load time, the 
server sums out the chance fields - they don't have to sum to 100, probably just 
habit that they do.


 If it is a 'treasure' list, then the chance field is the percentage chance of 
each object showing up.  In a normal treasure list, you can get 20 items from 
one list showing up.



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

Re: [crossfire] Java Editor

[Mark Wedel]

ERACC wrote:

On Sunday 05 June 2005 01:40 pm
Todd Mitchell wrote:



The current Java Editor does not seem to be very stable.  Especially it
tends to have a problem with really big maps (can't open them) and
eventually won't open maps and has to be restarted.  Behaves like a
Memory leak?  Also sometimes the map window graphics are getting
corrupted by the file menus from the main window (something updating the
wrong container?)



Noticed these problems here too. Hopefully some Java guru will have a
try at fixing it and release a new .jar (I haven't tried yet to build
from source). I did make it able to open huge maps by increasing the
maximum heap size using a command line switch. My personal bash
script to run the editor is attached.


 I've noticed it to on fedora core 3.  Using the -Xmxm to 
increase the heap size helps out.  I don't know what the default is, but does 
seem to small.  It certainly is a memory leak issue, because I do see errors 
like this from the window I run it from when it starts to misbehave:


 [java] Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: 
Java heap space


 In theory, java is supposed to reclaim memory so there shouldn't be memory 
management issues.  I wonder if some pointer isn't being cleared, and therefor 
memory from the map isn't being freed as it should.


 One can see the problem pretty easily - load one of the world_x_y maps and do 
enter north/east/whatever a few times.


 Increasing the heap size really just masks the problem.  OTOH, I think the 
default is probably pretty low for how much memory most systems probably have 
now days.



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

Re: [crossfire] Color Spray

[Mark Wedel]

Mitch Obrian wrote:

Perhapse it's time to PUMP (THE SPELL) UP!
...
and maybe make circular spells talked about earlier...
please...



 What do you mean by circular spells?

 Cone spells can already be cast in a 'circular' fashion if you fire on your 
own position (shift .) and not a specific direction.  And the space you are in 
will not be affected by the spell.


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

[crossfire] Pet Peeve - converters/altars/other that take gold, not money.

[Mark Wedel]

 This is an old pet peeve of mine - originally, I thought it was just a matter 
of old maps not being updated, but I'm seeing new maps that are similarly broken.


 What is basically comes down to is altars, converter tables, etc that require 
gold.  You can't use platinum, you can't use silver, it must be gold and only gold.


 This then requires that you go to the bank, convert that platinum to gold, go 
back, etc.


 If you set the altar/converter to take 'money' instead of 'gold' or other 
coinage, it will take the appropriate sum of money (it has to be all of one type 
of money, and it won't make change).  Not that money is in silver pieces, so to 
convert existing objects, the sacrifice count needs to be increased.


 Maybe map designers don't know about this.  I can't think of any compelling 
reason that the requirement should be gold.  After all, when you to the shop to 
sell stuff, they pay you in platinum.  There are tables to convert from one 
coinage to another with no extra fee.  If you buy stuff from a shop, it will 
take any of those currencies.


 If one were to think about this in modern currency terms, it'd be like a place 
saying it will only take $5 bills, and not $20 bills (substitute $ for currency 
of choice).  Such a policy could make sense if you're being something for $15, 
but most all the tables I've seen are wanting sums in the hundreds, if not 
thousands - surely such tables would prefer the bigger currency and not the 
small bills.




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

Re: [crossfire] new metaserver

[Mark Wedel]

Mitch Obrian wrote:

Cave's php metaservers are great. The sms's are sent
the data by the servers. They then send the info to
the cms which sends the info to the other sms's. This
way (since the sms's are trusted) the cms is unDoSable
as it's ip is unknown except for the trusted sms.
Since cave's metaservers are written in php they can
be hosted anywhere... including hosting companies with
near unlimited bandwidth.


 seems to me that making the CMS ip secret is just security through obscurity. 
 Once someone discovers that IP through whatever method, you lose that benefit 
- this means the CMS has to be secure on its own.




We should implement it, it has been written. It is
good. The time for discussing how it should be done is
passed as we allready have a product now.


 You discussed the metaserver/program before, however, when asked to provide 
link/URL, did not provide one.  Trying to search for info on it is pretty 
meaningless, as cave is just too common a word.



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

Re: [crossfire] new metaserver

[Mark Wedel]

 A few more notes/thoughts:

 For the server, switching to tcp is perhaps a good thing.  What I'd actually 
think is the best thing is there to be a small helper program that the server 
executes, and then talks to that helper program then a named socket (or perhaps 
just a pipe).  The server could send the helper program things like number of 
players and any other dynamic data (for the static date, the helper program 
could just read the settings file).


 This then eliminates the problem of costly or dead connections to the 
metaserver - only the the helper program would have any issue, and it can 
basically take as much time as it wants (if it takes 5 minutes to make the 
connection, not a big deal).  This helper program can also be quite small so the 
cost of the initial pipe creation isn't that big (and if it dies, not very 
costly for the server to restart).


 The one concern I have about tcp is number of active connections allowed to 
the meta server.  Most OS's put some limit on the number of open file 
descriptors any program can have - often set at 1024 or lower.  Thus, a 
perfectly valid DDOS attack is for a bunch of systems to just make connections 
to the metaserver and just keep the connection active.  Maybe this is unlikely - 
never really had an attack like that on existing server.  The metaserver can 
obviously enforce the idea of only 1 connection from 1 ip address, so getting 
1000+ hacked systems might be unlikely.


 But the fact is that if you want to make persistent connections, you can't do 
that to a web server script I don't believe.  OTOH, I'm not sure how quickly web 
servers will time out connections.  But it also just seems inefficient to have 
to execute an entire script for each update - having a persistent program is 
much more efficient in all its processing.  IT just means you can't run such a 
program on any web server.


 One possibility is a hybrid approach - trusted SMS can update the CMS. 
Servers can talk to the CMS directly.


 Just one other note - having something done first does not mean that is the 
way to go.  This is not any comment on Brendan's work, but the argument 'xyz has 
done this so you should use it' holds no weight to me.  This approach has 
certainly be used a few times in crossfire, and if that first approach isn't a 
good one, it just results in extra work, as that code has to be 
fixed/removed/redone/whatever.  If one takes this approach, then any code that 
anyone submits to crossfire should just be accepted, and that certainly wouldn't 
be a good thing.


 As said, this doesn't reflect on the code in the patch - I haven't looked over 
that closely enough to make any comment on it.  But I will make the comment that 
it seems to be missing the server -> metaserver notification piece, and IMO that 
is really the core piece, because that is the one where the most problems can 
arise (eg, you can't cause the server to block, you don't want a slow update 
time, but you still want to provide dynamic data.  The small helper program I 
mention above is probably the way to fix that, and actually should be pretty 
easy to do).



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

Re: [crossfire] new metaserver

[Mark Wedel]

Brendan Lally wrote:

On Friday 10 June 2005 06:27, Mark Wedel wrote:


 A few more notes/thoughts:

 For the server, switching to tcp is perhaps a good thing.  What I'd
actually think is the best thing is there to be a small helper program that
the server executes, and then talks to that helper program then a named
socket (or perhaps just a pipe).  The server could send the helper program
things like number of players and any other dynamic data (for the static
date, the helper program could just read the settings file).



This seems like a nice idea, it has the added benefit of making it possibile 
to send data about servers that are down, (assuming that it keeps running, 
and new servers speak to it...) as well as those that are up. (if the server 
isn't updating data to the subproccess, then it could notify the metaserver 
that the server is unresponsive, which is probably more useful than having a 
server suddenly disappear from the list.


 Yes - that depends on implementation.  Ideally, a down server is automatically 
restarted, but I suppose there are cases that doesn't happen.


 Since server updates may be sporadic, presumably the metaservers won't drop 
the listing for a server until some amount of time passes (30 minutes or 
something).  Note also that the current metaserver tracks when it last got an 
update from a server, and does provide that information to the client (I haven't 
heard from this server in xyz seconds).



For a well configured web server, something like mod_php or zend or similar 
will be running anyway, the scripts will be acting like compiled code in many 
respects. It will still be slower than a well written independent program, 
but then that is the price that is paid for having a web server handle all of 
the availability stuff.


 Right - I'm not sure the cost of doing it web server based vs independent 
program.  For the number of crossfire servers we're talking about, probably not 
a big deal in any case - although with it being web server based, you do have to 
be concerned with things like file locking, which may not scale will with large 
number of updates happening - this is mostly because it has to do all updates 
through a file.  A standalone metaserver has the advantage it only has to do 
some locking on the data structures, and only periodically needs to write it out 
to a few (say every few minutes for backup purposes).  The php one has to 
read/write the file every time in gets an update.  As said, for the number of 
servers we have, may not be a big dea.



By comparison, however the final system is implemented, the client /will/ 
connect to a server and parse some information recieved from it. However that 
server is configured, libcurl can pretty much cope, so writing a fairly 
generic parser attached to libcurl is a nice base to begin from, should 
libcurl be disliked as a dependancy, then it is simply a matter of adding the 
appropriate socket code later.


 I never like adding new dependencies if it can be avoided.  As a data point, 
my system did not have libcurl installed on to it.


 In my ideal world, the metaservers should be able to provide information in 
both 'pretty' html and something raw.  One could envision this by something like:


http://myhost/metaserver.php
  giving nice html output, and something like:

http://myhost/metaserver.php?output=raw

 providing real raw output (something like we have now).  I think however the 
client would still have to toss the http headers, but that shouldn't be too bad.





watchdog when it is compiled in has the server send UDP packets to a local 
socket. AFAICT it doesn't really matter to much /what/ it sends, so it might 
as well send the data that the metaserver will use, in that case then the 
program you describe would end up looking similar to 
crossfire/utils/crossfire-loop.c (though maybe in perl?)


 IMO, the metaserver notification helper has to be started automatically by the 
server, and not be an external entity started via script (like the watchdog one 
uses).  This is simply easy of use - otherwise the problem is that someone 
starts it by hand, or uses their own monitoring script and don't send metaserver 
updates when they should.


 Also, it is probably nice for the metaserver updater to be connected via tcp 
or pipe to the server, so each can know when the other dies.  If the helper sees 
the server dies, it can send a last update to the metaserver informing it that 
the server just died, and then exit.  If the server sees the helper dies for any 
reason, it can start up another copy.  The problem with the udp notification and 
watchdog is that the watchdog could be dead and server would never know.


 The helper program also needs to have some basic security - making sure the 
connection is coming from the local host and not something remote (don't want 
some remote host connecting to the helper and forging inform

Re: [crossfire] new metaserver

[Mark Wedel]

Brendan Lally wrote:


 Right - I'm not sure the cost of doing it web server based vs independent
program.  For the number of crossfire servers we're talking about, probably
not a big deal in any case - although with it being web server based, you
do have to be concerned with things like file locking, which may not scale
will with large number of updates happening - this is mostly because it has
to do all updates through a file.  A standalone metaserver has the
advantage it only has to do some locking on the data structures, and only
periodically needs to write it out to a few (say every few minutes for
backup purposes).  The php one has to read/write the file every time in
gets an update.  As said, for the number of servers we have, may not be a
big dea.



Yes, I don't know how to get round this, although at least on a good 
webserver, if the files are accessed enough to matter, they shouldn't be 
leaving RAM.


 True, but that is harder to predict.  The OS will do the file caching, but if 
the webserver is busy enough, the cache hit rate might be poor.  The flip side 
is that if the metaserver is used a lot, more likely that the file will be 
cached, and thus performance improves.


 But how the OS caches varies OS to OS.  Linux is very aggressive on caching 
data, others less so.


 OTOH, if the core metaserver can be run as a non web program, I think there 
are still benefits from doing that.  It's a little more work to write such a 
program, but probably not much.


 Related to this, how do the slave metaservers do updates?  They can obviously 
only do anything when someone is requesting data from them.  Do they look at 
their local cache modification time, and if it hasn't been updated in X minutes, 
go talk to the core metaserver to get up to date information?






 In my ideal world, the metaservers should be able to provide information
in both 'pretty' html and something raw.  One could envision this by
something like:

http://myhost/metaserver.php
  giving nice html output, and something like:

http://myhost/metaserver.php?output=raw




or indeed, showservers.php and showserversclient.php, which were two of the 
first things that I wrote when I started to play with this. (since a 
webbrowser is easier to play with than some quickly crufted C code.)


I haven't done file locking there because I am yet to get round to it.

You could have a get call and merge the two I guess.


 Probably not a big difference for them to be one program.  Two seperate 
scripts work just fine.




watchdog when it is compiled in has the server send UDP packets to a
local socket. AFAICT it doesn't really matter to much /what/ it sends, so
it might as well send the data that the metaserver will use, in that case
then the program you describe would end up looking similar to
crossfire/utils/crossfire-loop.c (though maybe in perl?)


 IMO, the metaserver notification helper has to be started automatically
by the server, and not be an external entity started via script (like the
watchdog one uses).  This is simply easy of use - otherwise the problem is
that someone starts it by hand, or uses their own monitoring script and
don't send metaserver updates when they should.



True, but a fork and exec at startup can do that.


 Right, but that then isn't really the watchdog program.



 Also, it is probably nice for the metaserver updater to be connected via
tcp or pipe to the server, so each can know when the other dies.  If the
helper sees the server dies, it can send a last update to the metaserver
informing it that the server just died, and then exit.  If the server sees
the helper dies for any reason, it can start up another copy.  The problem
with the udp notification and watchdog is that the watchdog could be dead
and server would never know.



This is true, although to a certain extent the idea is that the watchdog is 
simple enough to not die.


 Famous last words.  But there are of course other possiblities beyond the 
watchdog having faults.  Someone accidentally kills it.  Something external to 
it causes it to fail (out of memory, disk error, whatever).  And right now, if 
the watchdog does die, not a big deal - server continues to run, no one notices 
anything different.  However, if the metaserver helper dies and is not noticed, 
then the server in question is no longer reported, which does cause problems


 I'd personally like things to be simpler - if a user can just run the main 
server, and everything works, that is much better them then having to restart 
the helper manually.






 The helper program also needs to have some basic security - making sure
the connection is coming from the local host and not something remote
(don't want some remote host connecting to the helper and forging
information).



Is it insecure at the moment? It /is/ already in the server code, this was why 
I suggested using it, if it is there presumably it at least works in some 
fashion (although this has been shown to be fals

Re: [crossfire] The real cause of the metaserver DOS attack

[Mark Wedel]

Andreas Kirschbaum wrote:

I'm fairly sure that the real cause of the metaserver DOS is not some
random attacker but the crossfire server itself: you just need to set up
a (new) crossfire server and change the "metaserver_notification off"
config option to "on" to make your server flood the metaserver.


The patch

cvs diff -r 1.9 -r 1.10 lib/settings

changed the default value for the "fastclock" config option from 0 to 1.
That probably means that many new servers will run in fastclock mode.


Furthermore, socket/loop.c contains a logic error if fastclock is
enabled:

(excerpt from socket/loop.c; I stripped code not related to the problem)
| /** Waits for new connection */
| static void block_until_new_connection() {
| do {
| /* Every minutes is a bit often for updates - especially if
|  * nothing is going on. This slows it down to every 6 minutes.
|  */
| cycles++;
| if (cycles == 7) {
| metaserver_update();
| cycles=1;
| }
| if (settings.fastclock > 0) {
| Timeout.tv_sec=0;
| Timeout.tv_usec=50;
| } else {
| Timeout.tv_sec=60;
| Timeout.tv_usec=0;
| }
| }
| while (select([...], &Timeout)==0);
[...]

This function is called whenever a server has no active connections.
Basically, with fastclock=0, the metaserver update will be sent once per
6 minutes but with fastclock=1 it will be sent once per 6*50 usec (which
could be more than 3000 packets per second on a fast machine).


 Probably so.  Related, but limited to the local system, if fastclock is sent, 
the server will also send a ton of udp packets for the watchdog logic.  This is 
at least on the local system, but probably increases the load about.


 Real bug here was the commit of the settings files that changed the value of 
fastclock.  Unfortunately, changing the settings file back doesn't really help 
things out because by default, the settings file is not installed if one already 
exists - thus, all the people will broken settings file will continue to have it.


 I'll commit a fixed settings file and also work on some bug for the fastclock 
logic in that loop itself.




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

Re: [crossfire] Re: The real cause of the metaserver DOS attack

[Mark Wedel]

Lalo Martins wrote:

And so says Mark Wedel on 23/06/05 12:58...


Real bug here was the commit of the settings files that changed the
value of fastclock.  Unfortunately, changing the settings file back
doesn't really help things out because by default, the settings file is
not installed if one already exists - thus, all the people will broken
settings file will continue to have it.



May I respectfully suggest a hard throttle, so that no matter what else,
the server just won't talk to the metaserver more than, oh, once per
minute or so? Then even people with fastclock on will have this solved.


 The code change I put in place reduces this rate considerably to something 
normal.

 However, unless/until people update to this newest code, they will continue to 
flood packets.



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

[crossfire] cone damage oddity

[Mark Wedel]

 After playing a bit I noticed a cone oddity - it turns out if you are right 
next to the caster, you take less damage than if you are far away.


 Through experimentation, I quickly found that if you are 2 or more spaces 
away, you will take 3 times as much damage than if you are right next to the caster.


 If you are always at the very edge of the cone, you will take the same damage 
(as if you were right next to the caster).  Basic diagram:



   0   0   0   0   0   0   0   0   1
   0   0   0   0   0   0   0   1   2
   0   0   0   0   0   0   1   2   3
   0   0   0   0   0   1   2   3   3
   0   0   0   0   1   2   3   3   3
   0   0   0   1   2   3   3   3   3
   0   0   1   2   3   3   3   3   3
   0   1   2   3   3   3   3   3   3
   1   2   3   3   3   3   3   3   3
   1   3   3   3   3   3   3   3   3
   1   2   3   3   3   3   3   3   3
   0   1   2   3   3   3   3   3   3
   0   0   1   2   3   3   3   3   3
   0   0   0   1   2   3   3   3   3
   0   0   0   0   1   2   3   3   3
   0   0   0   0   0   1   2   3   3
   0   0   0   0   0   0   1   2   3
   0   0   0   0   0   0   0   1   2
   0   0   0   0   0   0   0   0   1


 Think of that table as a damage multiplier.

 I guess the first question is whether this is considered a significant flaw or 
not.  It has long been held that center of cone does more than edges, but in 
this case, center has a very broad meaning.  And the fact that being next to the 
caster does less seems quite odd.


 Now it is a very simple fix to make it so that the entire cone does the same 
amount of damage.  A side benefit of such a change is that it would also reduce 
server load - basically, reduce the number of objects used in the spell casting 
by a factor of 3.


 This would obviously weaken spells, so all cone spells would need to be upped 
in the damage they currently do.


 Trying to do any fix more sophisticated than that gets pretty complicated. 
This is basically because as the spell moves, the new objects are created, so 
you can't precalculate the damage for all spaces within the cone - you'd 
basically have to store a lot of info within each spell object, and I can't 
think of any way of doing that without things getting really complicated and messy.




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

Re: [crossfire] Color Spray

[Mark Wedel]

Alex Schultz wrote:

ERACC wrote:


I cannot believe HOW neutered this spell is. It used to be an awesome
spell worth the effort of going to get. Now I am sorry I wasted an
entire evening going to get it on crossfire.metalforge.net earlier.
As hard as it is to get this spell it should be at least as powerful
as I remember it being. What's with neutering hard-to-get spells?

Can the spell be returned to its' former glory, please? Otherwise it
just takes up space in my spell list. Level 46 sorcery and it takes
THREE casts of color spray to kill about 10 - 15 Fiends. They should
ALL be dead in one cast based on how the spell USED to work.

I agree, it's currently underpowered to the point where it's useless 
even when it might otherwise be attractive due to it's variety of 
attacktypes being difficult to resist. Even if I inscribe lots of 
scrolls of it that are about lvl 100, it can't even graze a lvl 60 in 
the arena or any monster that's of the slightest worth.
The balance of the spell might currently be ok for a lvl 15-30, however 
it's near impossible for a lvl 15-30 to get it considering the quest 
it's in and the fact that spellbooks can't be carried out.


 Comparing it to dragonbreath (which seems properly powerful), there are a few 
things I quickly notice:


 Base damage for dragonbreath is 25, for colorspray, 8.
 Both increase damage at same rate (1 point/3 levels)
 Colorspray has a longer range (10 vs 7), both increase at 1 sq/5 levels.
 Colorspray costs considerably more mana (35 vs 13)

 Looking at this, it'd seem that starting damage may be a bit low and casting 
cost a bit high.


 But I also wonder if some of the problem is that nature of the spell itself. 
If casting on high level creatures, chances are they are probably highly 
resistant to several of the attacktypes.  For example, if a creature is immune 
to half the attacktypes, the damage it does would effectively be reduced.


 In comparison, you'll use dragon breath or other single attacktype spells on 
the creatures that it works on.  So in that sense, it is probably also more 
effective.



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

Re: [crossfire] cone damage oddity

[Mark Wedel]

Rick Tanner wrote:


 I guess the first question is whether this is considered a significant flaw or 
not.  It has long been held that center of cone does more than edges, but in 
this case, center has a very broad meaning.  And the fact that being next to the 
caster does less seems quite odd.



Might be a different subject matter - but how does damage propegate 
outwards from a ball spell exploding?


 Don't have any real examples.  The code appears proper in that the explosion 
has proper tracking for uniqueness.  Thus, the main reason fireballs do more 
damage is that the inside of the fireball lasts longer than the edges.




Should this damage (from ball spells) work the same as cone spells?
Or work the same as updated (from this email thread) cone spells?


 Maybe.  OTOH, its somewhat obvious how the ball spells work - the fact the 
fire lasts longer would be pretty clear indication that standing there will do 
more damage.  I actually like the fireballs - how it explodes and then collapses 
back on itself - I think it would actually be odder if it expanded, and at some 
point, there was no fire left at the center while it continued to expand outwards.


 

 Now it is a very simple fix to make it so that the entire cone does the same 
amount of damage.  A side benefit of such a change is that it would also reduce 
server load - basically, reduce the number of objects used in the spell casting 
by a factor of 3.


 This would obviously weaken spells, so all cone spells would need to be upped 
in the damage they currently do.



Going back to your original table which showed 1's on the edges, then 2's, 
followed by 3's in the middle - would it be easier and less spell damage 
tweaking to use the "3" for all areas of the spell isntead of the 1's or 
2's?


 The reason that diagram exists is pretty basic - think of 3 cone spells 
emanating from those initial 3 spaces.  Where they don't overlap, it is a 1. 
Where it overlaps with 1 other cone, it does 2x damage (2 spell cones active). 
Where it overlaps with 2 other cones, it does 3x.


 the basic change I have in mind would make that area act as one logical cone 
spell, so the entier cone would do the same damage.  It makes things more 
efficient because now there would only be 1 fire object on those spaces instead 
of 3.


 As I've said before, I generally don't like the code to make adjustments that 
aren't obvious to the player.  So if I did the above change, the cone spells 
would effectively do less damage because there is no overlap.  The archetypes 
would be adjusted upward to take account for this (although perhaps not as much 
as 3x).  Thus when an archetype says 'dam 40', you know it will do 40 damage, 
not 120, not 13, etc.




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

Re: [crossfire] Re: In-game games

[Mark Wedel]

 As per some others comments, I don't quite as much see the point of solo in 
games, but I suppose if players find them interesting and it doesn't complicate 
things too much, no real issue not to add them (but those could be big if's, 
especially if it requires additional client and protocol support).


 That said, I wouldn't mind seeing lockpicking expanded/improved upon.  Right 
now, it is arguably a pretty useless skills - you can always bash down doors, 
and often, you can bash them faster than you can lockpick.


 Various thoughts I have, which probably wouldn't be hard to do:
1) Add more door archetypes - unlike the special doors that require special 
keys, these would be normal doors, just have a lot more hp and/or perhaps 
resistances (trying to bash through a steel door should be pretty difficult - 
difficult enough that perhaps lock picking would be a time game)


2) Related to above, these doors have different levels of difficult to lockpick. 
 Likewise, perhaps add more varieties to the standard keys we have - for steel 
doors, you need the steel keys, etc - thus finding all these key combos may be 
moer difficult.


3) Lock picking should be based on difficulty of door.  Add code for 
catestrophic failure (you break your picks).  Thus, you can't go and try to pick 
that level 50 door with level 1 lock picking and figure if you try enough, it 
will work.  It might, but you may go through 20 sets of lockpicks.  Related 
would be higher difficulty doors give you more exp when you do succeed.


4) Perhaps controversial, but allow lockpicking of the special doors.  If you 
have level 50 lock picking, why not give a chance for players to open those 
doors without needing the special key?  IMO, default behaviour would be the door 
remain impassable - the change here is to really allow the lock picking - maps 
can then be updated to update the doors for this based on the difficulty of the 
map (eg, a map targeted at level 10 players would have the door difficulty set 
so that players of that level have a so/so chance of succeeding, and same true 
for maps for level 50 players - that map would have doors of higher difficulty). 
 If a player wants to play a less combat intensive character, let them (one 
could envision interesting party dynamics - I'll lure away the big nasty monster 
that has the key but I can't kill while you go and pick the lock and get the 
treasure)


 Some of these, if done, would be very easy to integrate into the random maps, 
while other points would require maps to be updated, but that is often the case 
with new ideas/objects.



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

[crossfire] Random ideas.

[Mark Wedel]

 Some random ideas I've had:

1) As a dragon player, I find that at some point I just have stat potions piling 
up since I have no real use for them (can't make weapons that are usable).  One 
thought I have would be to allow players to effectively go beyond max stats, but 
 only rarely (say 1% chance of each potion you drink going up a stat?)  That'd 
give a little value to those potions.


2) Does anyone right now really use the magic map command?  One thought I've had 
would be to change it - instead of just sending the colors, it instead sends the 
faces of everything (or maybe limit it to just the floor/wall/other non living 
stuff?)  this would probably make it useful.




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

Re: [crossfire] Random ideas.

[Mark Wedel]

Nicolas Weeger wrote:

1) As a dragon player, I find that at some point I just have stat
potions piling up since I have no real use for them (can't make weapons
that are usable).  One thought I have would be to allow players to
effectively go beyond max stats, but  only rarely (say 1% chance of each
potion you drink going up a stat?)  That'd give a little value to those
potions.



Or we could use'em in some alchemy/smithery/... recipes. Or enchant
ring/whatever to increase stats?


 Yes, perhaps. One would have to be careful about balance on that - as I 
recall, dragons get some benefits on the basis they can't use specially 
enchanted weapons (the dragons biggest shortfal, arguably, is the limited number 
of things they can equip).  Thus, if you limit recipes to say 5 enchantments, 
that might still be more useful than some things out there, but probably won't 
make things really out of balance.






2) Does anyone right now really use the magic map command?  One thought
I've had would be to change it - instead of just sending the colors, it
instead sends the faces of everything (or maybe limit it to just the
floor/wall/other non living stuff?)  this would probably make it useful.



Yes, I use it often, to spot monsters on maps, and such.
Sending faces could make more detailed maps.
Also, maybe we could implement automapping? So player knows some maps
already visited, and keep that knowledge between sessions. Maybe with
a 'forget' factor, losing some details :)


 Yes, sending faces would make it more detailed - perhaps arguably too 
detailed.  OTOH, maybe not that bad if you go by the basis that for many maps if 
you've been there before, you sort of know what is around anyways.  Certainly by 
sending faces, the client could use it to fill in a bunch of fog of war spaces.


 As far as automapping, that can almost be done automatically on the client. 
The real issue why it can't easily be done right now is that we hide the 
coordinates that the player is on when they change maps.  This is done because 
without doing so, so maps become much simpler (if you can see where all the 
teleporters are taking you, very easy to see where you need to go and where 
you've been).


 A real example of this would be the electric church in brest.  If coordinates 
are sent each time you fall through a bit, working your way through the maze 
would be very easy.


 That said, while playing, it can be very annoying to step on a teleporter and 
have your entire known map go away, even when you step back through again.  So 
it really becomes  balance on convenience vs trying to be secure.


 More random thoughts on client caching fog maps:

1) If some coder was really clever, they could automatically try to figure out 
what map, and thus what cached fog map to use, based on data they see.  A simple 
example is scorn - see 4 signs, a fountain, etc, and you'd easily identify that 
as scorn, and could load up the appropriate data.  Many dungeons would be much 
trickier because the data isn't as consistent or could be more ambiguous (and 
client would have to catch that - did it guess the wrong map, or did someone 
cast an earthwall?)


2) If client was to cache maps, it'd need some logic, just like the server, to 
time out maps that player hasn't visited for a while.  For example, you don't 
want megabytes of random maps stored away, which by definition, the player can't 
visit again.


3) Related to above, for random maps, map name may not be good enough to know if 
the right version is in use.  Think of this case - server starts up, player logs 
in and goes to random dungeon (gets random0001).  Server restarts, player 
repeats - gets the same name, but since map is random it is not the same map. 
Yet at the same time, there is some desire to remember random maps, like say 
when going down through a random dungeon - if for some reason you leave and come 
back, would be handy to be able to see where you've been before and make it that 
much easier to get through.


4) Client caching maps wouldn't have to be that complicated, and wouldn't take 
that much space.  Could do something just like:


mapsize 20 20
space 0 0
forest.111
sign.111
space 0 1
cobblestone.111
orc.111
...

 because after all, the only think the client knows is the face name/number. 
It'd really need to store things by name since the face numbers can change from 
run to run (OTOH, it could be clever at create a bmaps file for each map that 
contains the number to name map for the faces stored in the map, thus making it 
even easier to parse those cached maps).


5) Outdoor maps would need improved handling - right now, the client isn't even 
aware when the player moves across the tiles.  It does have logic to recenter 
and clear out the old data as needed, but to handle outdoor maps, it would sort 
of need some idea of where it is (which goes back up to telling the coordinates).


6) It would be neat to have 'map' objects within the game that show a map.  I 

Re: [crossfire] Re: Random ideas.

[Mark Wedel]

Alex Schultz wrote:

Mark Wedel <[EMAIL PROTECTED]> writes:


1) As a dragon player, I find that at some point I just have stat potions
piling up since I have no real use for them (can't make weapons that are
usable).  One thought I have would be to allow players to effectively go
beyond max stats, but only rarely (say 1% chance of each potion you drink
going up a stat?)  That'd give a little value to those potions.



I have the same issue and I think this would be great, but I'm thinking that
perhaps using a more gradual curve than 1% after normal max would be good.
This change would also be more useful if the cap of 30 for stats even with
equipment was removed, or at least raised.


 I'm inclined not to raise the cap.  It's basically a never ending max if we 
do.  At one point, the maximum for stats was 25.  It was raised to 30 because it 
was considered too easy to get all the stats up to 25.


 The problem I see is that if the cap is raised, what do you raise it to?  35? 
 50?  One potential issue with a higher cap is that map makers feel there is 
less a problem of having items that give bunches of bonuses.  After all, if you 
say make the cap 50, an item that gives +10 int wouldn't seem all that 
outrageous (you'd need 3 of those to get that 50 int).


 If the cap is raised, then I'd think it would also make sense to follow the 
example of AD&Dv3 and make the stats bonuses linear, and not exponential.  Thus, 
the advantage of raising the stat is less relevant (if you get an extra +1 dam 
from that point of strength, not that big a deal).  With the non linear bonuses, 
right now it is highly desirable to get those last extra points because in terms 
of dam/sp/grace/whatever, it means a pretty big difference.



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

Re: [crossfire] Random ideas.

[Mark Wedel]

Andrew Fuchs wrote:


The current map can be gotten through the "mapinfo" command, though
figuring out where you are located on a map, is more difficult; since
you can make several locations look the same.


 Right - I knew that.  For some maps, that isn't a very big deal, as its pretty 
obvious where you are.  But I have certainly used the fact that mapinfo reports 
the maps to get at least near the location of certain things I'm looking for 
(eg, know that titan cast is on world_125_124 - using mapinfo lets me know if 
I'm close or not).


 Because of that, I had considered that the newmap protocol command could 
actually send the map name of the new map the player moves to (that's just 
sending along already public information after all).


 In some sense, for many maps, that could be pretty close to good enough to 
sync things up - for example, if the client remembers that from level1 to level2 
the player shows up at x1,y1, and from level 3 to level 2, shows up at x2,y2, 
that would make syncing up very easy, often because there are also objects 
around that are rarely used by correspond to those exits (stairs, doors, etc).





If the map's path (as returned by "mapinfo") ends in "random",
check to see if the suroundings match what was cached.


 right - I was just trying to think of some way to make it easier than trying 
to sync things up that way.   OTOH, if the client guesses wrong, that isn't 
really the end of the world - once the player sees those spaces, the server will 
send the real information for that space and it will correct itself.  Could be 
useful for a client command like 'clearcache' or something that clears all the 
cached info for that map that the client has once the player realizes that the 
map is different.





That brings in the question, of if there should be a cartography
skill, and if map makers should be able to restrict it's use on some
maps.  I think the results of mapping the maze mikeeusa has been
working on recently would prove to be interesting. (it would need to
be mapped in more than 2 dimensions, since it uses tricks with tiling)

In addition, I think the idea of having "bad" or inaccurate maps, for
the purpose of misleading players, could prove interesting.


 Not 100% sure if a seperate skill would be needed, or if literacy would be 
good enough to cover it.


 Certainly, allowing players to make maps as they see it would be completely 
reasonable (eg, player stands someplace and uses the skill, the the server makes 
a scroll based on what the player sees around him).  Perhaps errors are done 
based on skill of character making map, eg, some spaces get transposed or off by 
one or something).


 Having players make false maps, IMO, would be more an issue of the interface 
for the players to do it.  For map makers, an interface could be designed (or 
perhaps more easily, the ability to select a portion of the map in the editor 
and do something like 'save as game map', which saves it in the format used for 
the in game map scrolls.  Thus, easy for map makers to tweak about.



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

Re: [crossfire] Proposal to fix experience inflation due to random maps

[Mark Wedel]

Andreas Kirschbaum wrote:

ERACC wrote:


I am looking at the Valriel random map settings (within the map
/scorn/temples/valriel3) in anticipation of reducing the number of
levels, reducing monster density, adding some "new", tougher monsters
called "saints" using existing NPC arches and making the random maps
larger. One question I have but haven't been able to resolve: is
random map monster density determined by /styles/monsterstyles/* or is
it elsewhere?




The attached patch changes this. The reduced monster density is
noticeable, but since the resulting maps do not feel sparse to me, I
think it is still acceptable. Besides that, it also affects the total
experience:


 I don't see any problem with it, so I'll apply the patch to the code and 
commit to CVS.



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

Re: [crossfire] license problem with file lib/adm/map_check

[Mark Wedel]

Kari Pahula wrote:

This was already discussed on irc, but for record, I'll repeat this to
the mailing list too.

File lib/adm/map_check in crossfire has the following license:
#!/usr/bin/perl
#
# (C) Copyright Markus Weber, 1994. All rights reserved.
# Permission is granted to use, copy, and modify for non-commercial use.
#

I'm not aware of crossfire's licence policy, but at least Debian
requires that all parts of the programs are usable, copiable and
modifiable for commercial use too.

I noticed this so close to the sarge's release that the release
manager told me to either get this fixed in a few hours or have
crossfire-server dropped from it.

Crossfire tarballs are now repackaged in Debian to exclude this file.
Apparently nothing else used this script, it was just there available
in case the user wanted to use it directly.


 I'll update the makefiles so as not to include this script by default.  I'll 
keep it in CVS, as that shouldn't violate any licenses, and it might still prove 
useful to mapmakers.



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

Re: [crossfire] Remember to replace config.{sub,guess} for releases

[Mark Wedel]

Kari Pahula wrote:

The config.sub and config.guess files are used by configure to
determine architecture depentand features of the system.  The
autotools don't replace them themselves, but you have to update them
yourself from time to time.

The current config.sub and config.guess files in crossfire date back
to 2001-09-07 and client's files are from 2003-06-18.  It would be a
good idea to replace them for the next release.


 I'll update these and commit them to CVS.


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

Re: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with )

[Mark Wedel]

 I personally don't have an issue if a character can get straight 30 stats.

Unless the odds are really low, I think that even a cap of 35 would be reached 
at some point.  My character probably has 100+ stat potions stashed away, but 
OTOH, I'm not actively looking for them.  If I really had need/desire for them, 
I'd perhaps go to places/maps where they show up more often.  In a sense, those 
5 extra max points aren't going to change the makeup of characters, it will just 
change at what level the all the characters look the same.


 The fact that pretty much all stats are relatively important - if a wraith 
theif can get pretty close to that 30 dex at first level, maybe not great, 
however, it does mean that instead of that player having to equip dex 
improvement items, they can go for the con or str or other stats.  Right now, 
I'm sure there are several race/class combos that get relative close to 30.


 If the stat limit were to be raised, I'd be inclined to do something a bit 
more radical that increasing the limit by 5 points.  Make the limit 50, make the 
bonuses linear, etc.  Because otherwise I have a feeling that couple years from 
now, we'll be having this discussion again that 35 is not high enough.





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

Re: [crossfire] Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:

Hi,

I'm currently making a bot framework with a GUI display similar to a normal
client in python. I have managed to impliment handling for the map protocol in a
way that works quite well except for a few obscure bugs, one of which I'm
wondering if anybody has any idea about.

I've noticed that often while teleporting in the GTK client, that sometimes some
seemly random tiles are blank for a very brief moment and then display after the
others. In the bot that I'm making, for some reason this same thing happens
except those tiles stay blank. I haven't been able to determine the pattern to
which tiles are blank, but I'm wondering if anybody has any idea about possible
cause of that.


 I'm not sure why the tiles would stay blank on your client - that bit seems 
odd.

 I've not investigated the problem at all, because as said, it does correct 
itself pretty quickly.


 My thought is something like this:  The server logic is to only send those 
spaces that change.  When you change maps, there are cases where some spaces may 
be the same (or perhaps some faulty logic on the server part).  So those aren't 
send on the first map command.  On the next one, the server sees that some data 
it has sent isn't correct, and sends the updated data correcting the problem. 
But since there is roughly 1/8th a second between those two commands, you see 
the missing spaces briefly.


 I seem to notice the most when leaving some of the shops in scorn.  But the 
map draw logic has gotten very complicated with various changes and I really 
need to redo it at some point.



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

Re: [crossfire] Client display issue

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

With current CVS GTK client, there's a big display issue with
multiplart images.
Client apparently keeps old parts in memory, and won't erase'em.
Casting spells doesn't change display, but using dimension door (thus
invalidating cache) fixes the trouble.
So I'd guess it's related to caching. But someone who knows more about
multipart can tell better :)


 I've looked at this some.

 I've mostly been experimenting with the opengl logic in the gtkv2 client, 
because it has the distinct advantage that it redraws every space every tick, so 
no worry about the client not drawing something it is supposed to.


 My first finding is that putting a 'return' at the top of expand_face() 
greatly reduced number of errors (but did not eliminate them completely). 
However, this only works for opengl which only cares about the head location - 
it doesn't care about the sub pieces because it is fast enough it can draw 
everything each tick.


 The problem here is that the client is thinking it needs to keep the face 
around erroneously.  I didn't investigate closely what the client is trying to do.


 However, it does seem largely client related, because there is a 'mapredraw' 
command you can invoke - what happens when you invoke it is that the server 
clears out information on all the spaces it sent to the client, which basically 
forces it to send all the data for every spaces again (just as if you changed 
maps).  However, on corrupted maps, that does not fix the problem, pointing out 
an issue that it is the client holding the wrong info.


 Unfortunately, as of this writing, there is no client command to similarly 
clear out all the data the client is holding - if so, would be very easy to 
figure out who is handling the bogus data.


 All that said, the above change greatly reduces the frequency, but does not 
eliminate it 100%.


 I think there may be some interaction related to the large object, which 
pieces of it are visible, and if they have come into and out of visiblity.


 All this is because for the big images, the server only sends the face in the 
bottom right coordinate, even if that space isn't visible.  This unfortunately 
makes server handling more difficult - it could be that the server isn't sending 
a 'this no longer here' type of thing when it should.


 However, at the same time, the client has to remember which spaces it has 
gotten this data from - this isn't really a fog space, so its handling gets odd.


 I'm not 100%, but I could envision oddities in cases like this (imagine a 2x2 
image).  first, the upper left is visible - server sends bottom right location, 
client has to remember to keep that around as 'non fog' drawable.  Entire 
creature then becomes visible, so now the client basically treats all spaces 
normally.  Now, player moves or something, so only the upper left is visible 
again - the client already has record of the the bottom right face, and may get 
confused on updating it.


 My personal finding is that if one goes through the titan quest, one can 
really see the problem here.


 I think there are some fixes to the client that may make this work better. 
But I really think I need to change the map handling on the server, and how it 
is communicated to the client, to really fix this up properly.



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

Re: [crossfire] RFC: Wild idea to make experience more interesting

[Mark Wedel]

 I'm not sure what the proposed exp change really fixes.

 Tending to force playing styles on players usually isn't a good way to fix 
things.

 I agree the real fix is to make exp gains for other skills easier, or perhaps 
more to the point, give more exp.


 My own peronsal finding is that at low level, find and disarm traps can give 
quite a bit of exp relative to needing to gain levels (picking up a couple 
hundred exp is non trivial).  Yet at the same time, it is actually dangerous - 
I've been killed by traps at low levels.


 At higher levels, the traps don't give much exp, but also aren't dangerous. 
Is there really any traps out there (save for perhaps rune of death) that are of 
any danger to a level 10 player with full hp (disarming traps when you are at 
10% of your hp is pretty stupid after all).  And I think the answer is basically 
'no'.  At the same time, the amount of exp you get get at that time for finding 
and disarming traps certainly doesn't keep up what you get for killing things.


 So at least for those skills, obvious thing is to increase danger, and also 
increase exp.


 I'd also second the comment that if we want other behaviour, we should provide 
the oppurtunities for players to get those skills (Be archivist or whatever), 
and not force playing style.  I think otherwise, you'll either see players who 
say 'this new system basically maxes my level at 70 or something, so quit then' 
or players who know the tricks to get skills in all the different exp categories 
(right now, getting it in pyromancy and evocation isn't that hard, and I seem to 
recal there are other ways for some of the other skills).



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

Re: [crossfire] Random ideas.

[Mark Wedel]

 A lot of stuff discussed, so I'm going to try to catch up quickly.

1) Basing success of potons on overall level to me isn't good - base it on the 
overall stats of the player or something.  If I'm a sucky player and don't do 
the right dungeons to get a bunch of potions to level 30, I'd hate to 
effectively be punished for that fact by not being able to use those potions.


2) I'm not sure what increasing the level arrays to 115 really does relative to 
improvment potions, and/or I don't see how that wouldn't make characters more 
powerful.  And the fact that improvement potions loose usefulness isn't as big a 
deal to me as stat potions (the fact that improvement potions show up in shops 
also make me reluctant to make a change - if they are always useful, players 
will always snatch them up.  Stat potions OTOH can only be found in dungeons)


3) Stat inflation (wraith thief 30 dex at level 10) is perhaps derived directly 
from the fact that stat limits were increased.  At one point, the racial and 
class bonuses were not that big - that was described as a problem, so the limits 
were made more extreme.  Still don't see how a wraith theif can get a 30 dex - 
looking at the archs, a theif gives +3 dex, wriath +4.  So I think the best they 
can start with is still a 25 (max base stat I believe is 18).  There max natural 
would be 27, so they'd still seem to need a little help to get to 30.


4) There is no clear difference of max stats vs max stats + equipment.  The 
entire discussion here relating to max stats is how big the arrays are that 
describe the bonuses.  max 'natural' stats is really limited by the rules of 
potion consumption and racial/class bonuses.


How is this for a proposal:

1) Increase the stat limit to 35.  However, this would be done by effectively 
stretching out the bonuses, eg, the bonuses a character currently gets at 30, 
under the new system they would need a 35, so bonuses at 30, 25, etc, would be 
lower than they are now, thus weakening hte characters (I really don't want to 
make any change that would let characters become yet even more powerful)  I'm 
still mixed on this, especially see point at end


2) By default, stat potions would be temporary, but with a long duration (in 
real time, like an hour).  A small percentage of the time, they may permanently 
increase a stat.  This percentage would be based on if the character has reached 
racial maximums in that stat, as well as their overall stats (thus, a player 
that starts with sucky stats has an easier time catching up with someone who 
starts with really good stats).


 In the initial version, I'd make the stat gain happen all the time (I think 
that in itself would result in players just using the potions as they play - 
right now people have piles of them because they've been adventuring for a long 
time with nothing to do with them.  If stat potions gave me a temporary boost, 
I'd probably drink a potion of almost all the stats before going into a dungeon.


 I would amend this to be that for each stat, you can only have one temporary 
boost based on potions for each stat (eg, you can't drink 5 str potions to boost 
your str 5 points).  But I think even boosting 1 point for many stats is 
something I'd certainly use those potions for.


3) It could be interesting to make potions that would increase stats by 2 points 
(greater strenght potion, etc) on the temporary basis.  These greater potions 
would also have a greater chance of permanently increasing a stat, but would 
still only increase it by 1 point)


4) Change #2, while not incompatible with existing code, maks things pretty 
unfair to new players who have to play by different stat raising rules that 
players who have been on the server that predate this change.  I suppose someone 
could write a script that basically adjusts existing characters stats (knowing 
that at best, the starting total would have to in some range or something), but 
that is likely to make existing characters not especially happy.


 Likewise, change #1, presuming the stats aren't lowered for existing 
characters, would weaken characters (characters would not have as many 
hp/sp/grace as before, do less damage, be slower, etc).  This can actually be 
pretty annoying - it might have been that you could pretty easily kill a dragon, 
but with the changes, dragon now kills you - it'd probably take a little time 
for players to effectively 'rediscover' their characters


 the simplest would be for existing serves to wipe the data and start anew, but 
that would probably irk existing characters (OTOH, for some servers, maybe not 
so much, as it would potentially give new players the oppurtunities to get 
guilds or other things that have all been snapped up).






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

Re: [crossfire] RFC: Wild idea to make experience more interesting

[Mark Wedel]

Andrew Fuchs wrote:

On 7/6/05, Anton Oussik <[EMAIL PROTECTED]> wrote:


I agree. However many maps (e.g. Humanoid TC)
currently increase the danger by having several
traps. It is quite easy to trip several of them when
disarming the chests there. Forgetting about them
and just opening a chest around levels 25-30 is
just dumb even for a lvl 100 character.



Several players just burn the chests open though...
One reason, is that the burnable contents don't seem to be worth much.


 I'm not 100% sure that is a good method, depending on what you consider worth 
while.  But that may perhaps be correct - the best items - artifacts and the 
like, tend to be made of materials that can't be destroyed


 OTOH, there isn't really any fix for that problem - it isn't fair after all 
for a burned up chest traps to seek out a player 20 spaces away.  That said, the 
code could certainly be changed that if a chest is destroyed, any traps do 
activate - in the case of most rune traps, not a big deal.  But if the chest has 
something like a fireball or burning hands, one could see how that could burn up 
other traps, set off more traps, and cascade into something pretty nasty.


 It may also be that traps need updating - I think a bunch of new spells have 
been added but they don't show up in traps.


 The problem with multiple traps is twofold - first, they are created because 
multiple treasures are put into the chest, so it can't really take into account 
the other traps that are there, and second, when attempting to disarm traps, you 
can only set off traps you know about.  This basically means you are better 
searching until you find one trap, disarm it, search more, etc - you don't want 
to search a bunch of time and find all the traps.


 All that said, in my play, I search and disarm the traps, and since pretty low 
levels, I can't remember ever remember getting hurt to any extent from traps - 
some prove annoying, like poison or disease, but certainly not fatal.  And this 
includes cases where I've been surrounded by chests and have had 20 traps to 
disarm at once.




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

Re: [crossfire] Re: Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:


Wouldn't it work if you made the server behave properly, then let existing
clients just send their mapredraw anyways? It might be a tad bit of extra wasted
bandwidth, but it would make new servers behave properly to the protocol spec
and old clients wouldn't be hurt, and just continue to waste bandwidth with the
mapredraw to a similar to how they do already.


 The server is arguably behaving properly - as said, the design is that the 
server basically just sends what changes.  The event that causes those changes 
isn't a concern to the server


 Originally, the client did not have any fog of war, so this was all very 
simple - the server and client would remain in sync, as the server would send 
updated info for all spaces that have changed.


 However, when fog of war was added, it was necessary for the client to know 
when its fog of war data was no longer valid - hence the addition of the newmap 
command.  Originally, this was basically something to just tell the client 'get 
rid of your fog data' - the server would still do the 'right' thing and only 
update the spaces that changed, and the client was still supposed to remember 
what data was visible.


I imagine it became too much a problem to try and figure out what spaces the 
client should keep, and which it should get purge - it just became simpler to 
purge all the data and do a mapredraw.  So I imagine that is how we got to that 
state.


 Now, when maps are being changed, it probably is more efficient to have a 
server->client command that basically says 'I'm clearing everything' - that 
would be more efficient than the server sending the coordinates and whatnot for 
a bunch of spaces that need to be cleared.


 The easiest way to handle this is to probably add something like a newmap1 
command.  The client can negotiate its understanding of that with the setup 
command like the other stuff.  IF the client gets that command, it acts liek it 
does now - clear out its fog data, and the server knows that if it sends that 
command, it also clears out all its data.  So when the client gets it, it then 
knows it doesn't have to send a mapredraw request to the server.


 However, if doing, that goes back to a discussion from last week about fog map 
caching and stuff - the newmap1 command would be the obvious place to include 
map name and any other pieces of data.




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

Re: [crossfire] Client display issue

[Mark Wedel]

Anton Oussik wrote:

On 7/6/05, Mark Wedel <[EMAIL PROTECTED]> wrote:


However, on corrupted maps, that does not fix the problem...



It happens very infrequently, but from time
to time the server poisons the maps with
black tiles, which looks alike to a gap in
the fabric of space. Although it's a good
effect, and goes a great way of showing
that the universe we live in is fragile, I don't
think it's intentional. Has anyone else
noticed this or knows why it happens?
I'd hate something like this to happen to my
apartment/guild.


 I know a behavior - I'm not sure if it exactly what you are talking about.

 An example of this behavior is the coloseum in scorn at night.

 As said, the server sends the lower right coordinate for the face, even if the 
entire thing is not visible.


 So what can happen is that some portion is visible, and some portion is not 
(because it is too dark to see).  However, the client knows about the entire 
image, so draws all of it, but it doesn't have any background, and thus looks odd.


 The other case you may be talking about is monsters that cast darkness.  The 
'darkness' image is a black space that is the full tile size.  So this looks 
'odd'.  This is easy to confirm - go stand on that space and in the look window, 
the darkness will show up as 'darkness'.


 I'd probably be interesting to add smoothing for the darkness arc - that way 
diagonal lines of darkness at least woudl look not so ragged.  Or perhaps 
replace the darkness arc with something not as block so it doesn't look quite so 
abnormal.




___
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] Re: Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:

Mark Wedel <[EMAIL PROTECTED]> writes:

 The server is arguably behaving properly - as said, the design is that the 
server basically just sends what changes.  The event that causes those changes 
isn't a concern to the server



If one calls properly, to the spec of the doc/Developers/protocol file, then it
would depend on your interperation of certain parts of that document (hence the
"arguably" part).


 Yes - the definition of what 'newmap' really should do isn't explained 
especially well.





Yes, and on that topic, I think it would be best to use a newmap1 command or
something like that to include both the map name and starting coords for the
'fog map caching', but also allow individual maps to disable 'fog map caching' 
(if the coords would give away too much, or it there's some sort of storyline

reason), in which case the server wouldn't send the coords and the client gets a
special signal that tells it that it can't cache fog maps here.


 The easiest way to handle maps that we want to keep the coordinates secret is 
to send -1 -1 as the starting coordinates in the newmap1 command.


 The client can still go and cache the data for fog purposes - it will just 
have to invalidate it each time, but that is no worse than how it works right now.


 The trickier part is trying to come up with a standard of for what maps should 
be secretive and what shouldn't.  Because from a player perspective, you'd 
always want all maps to be non secretive, and that could lead to a discussion of 
'why is map xyz secretive?  Map abc isn't, and the info is basically the same'



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

[crossfire] treasure chests & wealth

[Mark Wedel]

The discussion of too much wealth in crossfire often comes up.  Looking at the 
random map treasure chest code, I found some oddities.


 Now I'm not sure how much of the excessive wealth comes from random maps, so 
this may not be a really big deal


 But looking at the code, the deeper down in the dungeon you are, the more 
treasures it creates on a level.


 This is readily apparant in some cases, when pretty much every space on the 
map is covered with a chest.


 This in itself wouldn't be bad.  However, the deeper in the dungeon, the 
higher the difficulty rating, and this means better treasure.  So not only do 
you get better treasure, you get more of it.  And this completely ignores the 
treasure that the creatures you are killing have.


 So my proposed fix is to eliminate/reduce the increase of treasures that show 
up on maps.  Deeper levels are still better, simply because better quality stuff 
will be created.


 (as an aside, there are basically 2 modes of treasure creation on the random 
maps - in one mode, a chest is created for each treasure.  In the other mode, it 
places only a few treasure chests, but fills them with a whole bunch of 
treasures.  This is why at deep levels, you sometimes see the maps covered with 
chests, and other times, just a few chests with tons of stuff in them)


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

Re: [crossfire] Re: Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:

Sebastian Andersson <[EMAIL PROTECTED]> writes:



Shouldn't the secretive be based on the teleporter used to enter?
If I enter via the front door, then I would expect it to be pretty
obvious where I am, but not when entering via a "random" teleporter
or just jumping around on the same map via a teleporter.
That would of course make it even harder to update the maps (or perhaps
some clever program could help here), but I think players would except
it to work like that.



Yes, I have thought of that possibility, but as you say, it would make updating
more difficult, despite the result being a little nicer for the players.


 One problem right now is that inter map exits all basically appear the same, 
that is, of type exit.  So within the server code itself, it can't easily detect 
correct behaviour (other than have a list of names to look at).


 Now in some cases, even teleporter type exits should be treated differently. 
Think of all the shop mats - in those cases, we actually want to suppress the 
newmap command - I'd have to think about the way to properly deal with it, but 
if you look at the scorn shops, where the map is visible from the shop and vice 
versa, it is arguably wasteful to resent the entire map when most seems to be 
the same.  But probably no easy way to handle that, so don't worry about.


 But the other point is that there are some maps where for style reasons, you 
may want to hide the locations a bit - I'm think of some maps where there are 
multiple levels on the same logical map (to deal with things like levers and 
buttons ) - while each level is perhaps non secretive, showing the relation to 
each other might be ugly.


 OTOH, maybe we jsut live with that.

 Other consideration is how to deal with world maps - I guess teh client could 
be smart enough to figure it out.


 One other thought - with the newmap command, for non secretive maps, probably 
want to include the mapsize with it.  That way the client could be more clever 
about storing away the data after the player leaves and/or figuring out where on 
the fogmap it could place this map and not destroy existing data (the idea here 
being if you come back to the map, you could get your old fog data back)



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

Re: [crossfire] force python instance

[Mark Wedel]

Todd Mitchell wrote:

The latter.  I don't want to mess with the system python but I do have
another python installed for programming and to run Zope. Zope has a
--with-python option in the config since it is fairly version dependent
and I thought that might be good for the CF server as well since it
would be more flexable to be able to select than just detect. 
It's more a feature request than a fix I guess but it would be nice to
be able to point config to the python you wanted to use. 


 It only took 5 months, but I've added a --with-python option for the crossfire 
server.




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

Re: [crossfire] treasure chests & wealth

[Mark Wedel]

Vernon T Rhyne wrote:



This changes (for the negative in my opinion) the other dynamic at work, the
acquisition of truly rare items.  Since this is basically a lottery at really
really long odds, these random levels are a significant potential source of
rare items.  If you kill the volume, you dramatically lower the chance at a
rare item.

If we're reducing clutter, I'd argue we should increase the value of
individual-item yield for super-high level treasures.


 but by that arguement, we should then increase the number of treasures, so it 
is more likely items show up.  But I doubt many people would think that is a 
really good idea.


 Now what could perhaps be done is increase the likelihood of artifact items 
show up slightly based on difficulty of the dungeon.  Right now, I recall the 
likelihood of artifacts (ring of miracles type of thing) is somewhat constant 
based on difficulty - or at least, the chance of a ring becoming a 'special' 
ring is constant - some items do require minimum map difficulty levels.



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

Re: [crossfire] Re: Map Protocol Question

[Mark Wedel]

Alex Schultz wrote:


Yes, based upon the issues you're talking about in the three above paragraphs, I
think I've thought of a system that should work well:
-Give exits and teleporters a new attribute which for the purpose of this
explaination will be rerfered to as 'secrettype'
-the 'secrettype' would be any value from 0 to 255, as well as -1
-a 'secrettype' of -1 means that the client receives no data about it's coord,
for what has been rerfered to as 'secret maps' in this conversation
-for values of 0 to 255, all coord data is send and the client.
-values of 0 to 255 are an id of sorts that is sent to the client, the client
then appends this to the mapname for storing purposes which fixes asthetics in
non-secret areas. To make it look nicer the client considers it a seperate map
for caching purposes even though it knows the coords on the real map.
-a exits and teleporters which do not have a 'secrettype' defined default to 0

And maps that need secrettype set would need (either for plot, cheating, or
asthetics) to be set manually, possibly with the assistance of a script to
detect possible potential spots (i.e. maps with lots of teleporters to itself
would be good things for a script to look for).
This method would take significant effort to adjust old maps where applicable,
however I feel that it would provide the best end-user experience and would at
the same time be not too much harder to modify maps for than something like the
regions was.


 Why can't a global map flag (no_client_coords) or something be added?  That 
would seem to be a lot simper than having to update all those exits (other 
concern I have with that is if you mix an exit or you add a new one or whatever 
else, things are broken).


 While having a secret type lets the client be more clever, you also have the 
problem of conflicts (suppose a map maker accidentally uses the same secret type 
for 2 exits?)  that screws up the client.  There is also the case that many 
exits don't always exit to the same space (when using an exit, if the target 
space isn't free, it finds a nearby free space) - that is likely to screw up 
clients who think it should be on sapce X.


 The other gotcha here is that you now have to modify the exits that lead to 
the maps, and not the maps themselves - this also seems an extra level of 
complication.


I'm also not sure what that buys - imagine the case of a 3 level dungeon, with 
level 2 having secret coordinates.  The exit from 1 to 2 would have one secret 
value, and 3 to 2 a different one.  But the effect here is basically the same as 
having no secret type, because the client won't be able to easily resync when 
player goes from 3 to 2, because the secret types don't match, and thus the map 
names don't match, so client would have to use a completely new map (logically) 
for fog purposes.  However, see my notes about tiling on how that could perhaps 
apply here.


 I wonder if instead of sending -1 -1 as coordinates, some form of hash could 
instead be done based on the coordinates.  This also works better with the idea 
below of sending exit data





If the map name was sent with the newmap command, as well as tiling data (names
of the maps that it tiles to), then it could deal with tiled maps easily and
properly.


 Actually not, not as it is now.

 Imagine the case of maps A -> B -> C -> D

 player enters map A.  gets newmap info for map A.  Player then goes to map D, 
exits, and comes back on D.  In the case of the first exit, client would get 
connection from A -> B, but nothing more.  When player comes back on D, gets 
info from D -> C.  However, client has no idea of the B -> C connection.  Newmap 
protocol commands are not sent when moving across tiles maps, because tiled maps 
are suppose to be opaque to the user.


 This is a bigger consideration if you consider that the world maps are tiled, 
and often players are moving across 10's of transitions before changing exits.


 My thought to fix this is that when you exit a map, the newmap1 command 
includes the map name of what you just exited, as well as the coordinates you 
exited from.  This in a sense fixes the problem, because often you will come 
back on the map from the same place you exited.  So when you enter the store 
then exit, the client would more easily be able to reconnect to where you were.


 This doesn't fix the problem of players using word of recall or town portals 
for example.  Even dimension door may through things off.


 My initial thought about the client being able to figure it out is that the 
outside world tiles have a very clear naming scheme.  For example, if you are on 
world_110_110, I can tell you that it is 500 spaces to get to world_120_110 (50 
spaces/tile).


 the other thought is that perhaps that when players do make a tile transition, 
send some form of newmap1 command (perhaps include some flag in that command 
that includes something like 'is tile update - don't clear your old data'.

Re: [crossfire] treasure chests & wealth

[Mark Wedel]

Andreas Kirschbaum wrote:

Mark Wedel wrote:


The discussion of too much wealth in crossfire often comes up.



Is this still a problem? After all, two exploits were fixed recently:
broken money converters and shadow alchemy. (And I've noticed quite a
few players on metalforge that did exploit these "features".)


 Maybe the issue just comes from what to do with that money.  As discussed 
numerous times, basically at some point, you'd never buy anything (the only 
thing I can recall my character buying is piles of healing potions).


 Now the point about alchemy is perhaps valid - there are of course various 
remedies (have items created via alchemy not worth anything or worth much less - 
problem with this is that then they don't merge with normal items).


 Maybe it's just a data point, but my character, not using any alchemy 
exploits, probably has half a million platinum and piles of gems.  But as said, 
the problem is perhaps really nothing much to spend it on, so no matter what, 
you'll accumulate large amounts of money.


 OTOH, perhaps my point to some extent is that these random maps perhaps have 
much higher density of treasure than most randmo maps - moderate level random 
maps might have 100 treasure chests on a level - I can't think of many non 
random maps that have anywhere near that treasure, and those that do have it as 
perhaps a treasure room/final map, and not level after level.


 The change I describe would only effect amount of treasure chests, and not 
treasures created by monsters.  Thus, the amount of wealth reduction may be 
minor, and when looking for certain objects, like rings, going to maps have 
creatures that tend to have those items is probably still a good bet. 
Especially, as if I mention, the likelihood of the artifact items increasing 
slightly by level/difficulty.   That may not actually reduce wealth much, but 
would I suppose reduce clutter.



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

Re: [crossfire] About "glue" code

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

What's the use of the "glue" code? In glue.c, and the callback
functions, in the library.

From what I understand, it was supposed to be for the Python plugin.

But the fun part is that is doesn't work under Win32: the library is
generated as static, so plugin and server have each their own without
any shared data.

So I was pondering simply cleaning/removing that. That would imply
fixing plugin system, too, as all functions should be callbacks and
not directly hooking to server (like add_string that does *not* work
between plugin and server under Win32...).

Opinions?


 It could certainly go away.  I suppose a few people still use crossedit, but 
that could be fixed similar to the client - any things that common needs to call 
that exist elsewhere, the editor could just define as empty dummy functions.


 I'm not sure if that really fixes thing on win32 or not - it would seem to me 
that having the common area be a static library that gets linked into the plugin 
will ever really work right - I note that on linux, crosslib isn't linked in as 
part of the plugin process.


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

Re: [crossfire] Group spells

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

I committed a few days ago a new spell type, 48, 'party spell', which
lets a player cast a spell on party members in the same map.
It will need to be throughly tested, I'm not sure whether everything
works or not, or if behaviour is as intended :)
To make one such spell:
* define subtype as 48
* fill in 'other_arch' with the spell archetype

Note that spell uses party spell's statistics for gp/sp, not party
spell, and has a one-time cost.
Also currently all players on the same map are affected, for the same
price, whereas maybe it could be decided randomly or based on distance.


 Maybe - hard to say for sure - one would think the cost should be pretty fixed 
(if the party is on mixed maps, would be sort of annoying to not have enough 
mana to cast the spell because someone popped onto the map you're on).  Perhaps 
the best thing to do is limit the number of people the spell will effect, going 
from closest to caster to farthest.


 One note - one should not user comparisions of op->map to check for same 
mapness - use 'on_same_map' - checking directly won't work correctly on tiled 
maps, which is all the outdoor maps.



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

Re: [crossfire] Win32 snapshot release plan

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

Been some time since there was a release, so i plan on doing a
snapshot release for Win32 this week-end.


 I was planning to do an official release soon, might want to wait for that.

 My plan for that is this:
This week (until sat/sun) - people please commit whatever stable stuff you are 
working on.


On saturday or sunday, I'll update metalforge to latest code.  Then let it soak 
for a week to make sure there are no horrendous bugs, and do an official release 
on july 30/31 weekend (or maybe a few days sooner if no problems show up)





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

Re: [crossfire] Re: [Crossfire-cvs] CVS commit: client

[Mark Wedel]

Andreas Kirschbaum wrote:

[EMAIL PROTECTED] wrote:


Module Name:client
Committed By:   mwedel
Date:   Sun Apr 17 04:47:13 UTC 2005


[...]


Index: client/gtk/image.c
diff -c client/gtk/image.c:1.22 client/gtk/image.c:1.23


[...]


***
*** 203,211 
 */
p = (uint32*) (fog->pixels + i);
g = ( ((*p >> 24) & 0xff)  + ((*p >> 16) & 0xff) + ((*p >> 8) & 
0xff)) / 3;
!   p = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff);
!   l = (uint32*) fog->pixels + i;
!   *(uint32*) l = *p;
}

SDL_UnlockSurface(fog);
--- 203,211 
 */
p = (uint32*) (fog->pixels + i);
g = ( ((*p >> 24) & 0xff)  + ((*p >> 16) & 0xff) + ((*p >> 8) & 
0xff)) / 3;
! l = (uint32*) fog->pixels + i;
! + *(uint32*) l = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff);
!



Is this plus sign at the beginning of the line really intentional?


 no, almost certainly a cut/paste issue from some other patch.




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

[Mark Wedel]

Nicolas Weeger wrote:

Hello.



* what functions should a plugin be able to access? I'd say the more
the better, to have nice effects. But a plugin should not be concerned
with server logic - it should just issue simple orders.


 Note that some number of server functions probably make no sense to be called 
externally.  That said, this is perhaps driven by what functionality the clients 
need.




* should we take care that a plugin can't crash the server or make it
a mess? This would mean active verification of object state after
calls, and take time to implement. Or we could just let plugins access
functions, the script developer being responsible for not crashing
server. Simple example: remove player object. That's a bad thing to do
- should a plugin be able to do that, or should the server forbid it?


 Ideally, nothing should every be able to crash the server.  So if we can do 
extra sanity checks to preven that from happening, probably a good idea.


 That said, there are certainly checks in the server or other places where the 
server code does call abort(), simply because if we get to that state, we want 
to log it ASAP, because trying to continue will just cause a panic a few seconds 
later.  But that is controlled by the MANY_CORES define.


 At minimum, we probably want to at least log bad things that the plugin is 
doing, so if it does panic, it is very easy to see (look, plugin xyz removed a 
player object).  There are certainly some number of crashes I see on metalforge 
that I have no clue how the thing got into that state - I'm not saying a plugin 
is responsible, but if we can log bad things, sounds like a good idea to me.



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

Re: [crossfire] Java editor questions

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

I was wondering how hard it would be to modify / reuse part of the Java
editor to edit actual archetypes. It would make creating / modifying
archetypes much simpler, imo.


 Well, in my ideal world, the need to create new archetypes shouldn't really 
exist.  Or in those cases where it is needed, most likely that need would 
predate any ability of the editor to know how to handle them.


 That said, what perhaps need fixing/examination is where archetypes are needed 
and can the code be changed so they aren't.


 Easier said than done.  Off the top of my head, where archetypes are still 
really needed:


1) cases where other_arch is used - I believe for many cases, the object in the 
inventory is used.  However, that may not be universal, and causes problems 
where and object creates and object, and that object is looking at other_arch.


 One possible fix for the more general case is make a 'other_object' field that 
acts as another inventory (for cases where you can't use the object inventory). 
 OTOH, I think additional investigation is needed to see if there are really 
any cases right now where using inventory doesn't work.


2) Treasurelists.  The real fix here is to make it so objects can specific 
treasure lists (entire text entry).  And to extend treasure lists so that they 
can include objects.   These are non trivial changes however.



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

Re: [crossfire] Quests, continued

[Mark Wedel]

Nicolas Weeger wrote:

Hello.

I'm not totally satisfied of my quest implementation. It's not general
enough for many things we could think of, and there are some drawbacks
(like removing all markers on completion).

Therefore I suggest we don't use that for now, and think of everything
we'd want to be able to do.

What I can think of (some stolen from Daimonin):
* kill a monster


 Yes, and if the player is part of a party, and other party members are on teh 
same quest, this should count for them also.



* collect n items of something


 Can you be more specifc on this?  Does this meaning having n items in your 
inventory?  Having picked up that number?  Tkae them someplace?  If the later 
case, I'd suggest that quests should be allowed to be connected to other objects 
to control what happens (eg, you drop the 5 x on the altar, and it activates the 
end quest action because it is linked to that on the same space).  This 
flexibility then allows quests to be controlled in a variety of ways.



* go someplace


 On a basic level, this can be done pretty easily by putting objects on the 
spot they need to go to.  However, on a more abstract level, having something 
like 'go to navar city' could be harder to do, unless you blanket the entire 
town with the appropriate objects, because the player could have numerous ways 
of getting there.  This can be remedied to some extent by being very specific 
where to go (go to town hall help desk, etc).



* get an item (from a chest/monster) only if doing quest


 Doe this mean you can only get the item if you are on the quest, or does it 
mean it only counts for something if you are doing the quest?  If the later, 
that would seem pretty obvious.  This would presumably be basically tied to 
pickup item.


 I'd add:
Converse with someone.  Eg, a quest to go tell xyz abc.  This could be done as 
above - tied to connected objects, so could be tied to a magic ear.



 To me, what seems to be missing is the entire reward structure:
1) Give object.  Some quests (scorn nobility) quest does this, but can 
potentially run out of objects - if done via quests, don't have that problem.


 Also, should have special code to give invisible objects - if player doesn't 
have it, it gives them.  Thus, quests could give out skills and spells. 
Potentially, there should be some fallback (player already has meteor swarm, 
give them 10 potions instead or something).


2) Ability to give exp, and give it into specific skill categories (bring me an 
elven bow and I'll teach you more about bowmaking, etc).


3) Ability to give stat/other bonus, up to racial maximums (just like potion). 
Resistances could be for everyone or maybe just dragons.  Perhaps have some 
constraint (only increase resistance if less than 20 or something).


 Also, from the current quests, I'd say that if the quest is timed but you 
don't complete it in time, you should generally be able to restart it.  Ideally, 
few quests should be timed, but my concern here is that a player perhaps get 
distracted, quests expire, and not player has not chance to redo it.





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

Re: [crossfire] MF Crash/Arena petmode

[Mark Wedel]

Alex Schultz wrote:

Hi,

It seems something went wrong with the arena petmode and it caused two 
crashes on metalforge today, and it crashed right in the middle of one 
of the code blocks that's used in the arena petmode, but I can't figure 
out what's wrong despite writing most of this code block myself (giant 
expression beginning on line 118 of pets.c). In case anyone can help, 
I've attached the core dump files I got from Leaf, and here's the 
offending expression for quick reference.


 I'd personally suggest cleaning that 'if' statement at all possible - break it 
into smaller pieces or something.


 Anyways, hard to know exactly the logic of the if statement.  But looking at 
the core files, and at the statements, that big problem I see is that you are 
looking at owner->contr->... without knowing in fact that owner->contr is in 
fact valid.


 owner does not have to be a player, and looking at the two crashes, in fact, 
owner is not a player, but a Balrog.  I'd also be wary of any other ->contr 
checks here, unless you really know 100% sure that they are valid.  The if 
statement is too complex for me to see that at a glance if the checks are there.


 The other problem with such complex if statements is that the crash point is 
really 'someplace' in that statement - breaking it in smaller pieces gives you a 
bit finer control.


 The cleanest thing is if you can do some basic checks like:

 if (simpler expression) continue;
 if (other simpler expression) continue;
 ...

 and then perhaps the if statement that is executed could perhaps be readable.




pets.c, line 118  and onward:
   if (QUERY_FLAG(tmp2,FLAG_ALIVE) && (
   !QUERY_FLAG(tmp2, FLAG_FRIENDLY) || (
   (owner != tmp2->owner) &&
   op_on_battleground(pet, NULL, NULL) &&
   op_on_battleground(owner, NULL, NULL) &&
   op_on_battleground(tmp2, NULL, NULL) &&
   (owner->contr->petmode == pet_arena) && !(
   (tmp2->owner->contr->party_number ==
   owner->contr->party_number) &&
   (owner->contr->party_number > 0
   && !QUERY_FLAG(tmp2,FLAG_UNAGGRESSIVE) &&
   tmp2 != pet && tmp2 != owner && (
   (tmp2->type != PLAYER) || (
   op_on_battleground(pet, NULL, NULL) &&
   op_on_battleground(owner, NULL, NULL) &&
   op_on_battleground(tmp2, NULL, NULL) &&
   (owner->contr->petmode == pet_arena) && !(
   (tmp2->contr->party_number ==
   owner->contr->party_number) &&
   (owner->contr->party_number > 0 &&
   can_detect_enemy(pet, tmp2, rv)) {

   Thanks,
  Alex Schultz




Core was generated by `/home/crossfire/bin/crossfire -d'.
Program terminated with signal 6, Aborted.
#0 0x400e6921 in kill () from /lib/libc.so.6

(gdb) Executing command "bt full":

#0 0x400e6921 in kill () from /lib/libc.so.6
No symbol table info available.
#1 0x400e6720 in raise () from /lib/libc.so.6
No symbol table info available.
#2 0x400e7808 in abort () from /lib/libc.so.6
No symbol table info available.
#3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957
No locals.
#4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898
No locals.
#5 
No symbol table info available.
#6 0x08091479 in get_pet_enemy (pet=0xaa18980, rv=0xb4b0) at pets.c:118
tmp2 = (struct obj *) 0x8
owner = (struct obj *) 0x8117f69
tmp = (struct obj *) 0xb538
attacker = (struct obj *) 0xb4b0
tmp3 = (struct obj *) 0xaa18980
i = 134790287
x = -16385
y = -3096
nm = (struct mapdef *) 0x401d3458
search_arr = {5, 15, 23, 21, 14, 9, 20, 22, 11, 17, 13, 19, 10, 12,
16, 18, 24, 26, 40, 31, 37, 44, 35, 41, 36, 34, 43, 32, 39, 48, 28, 47, 42,
38, 25, 46, 45, 29, 27, 30, 33, 1075655768, 1075655768, 135358108, 24,
139796480, 1114131, 0, 0}
#7 0x0808bc8f in find_enemy (npc=0xaa18980, rv=0xb4b0) at monster.c:211
attacker = (struct obj *) 0x0
tmp = (struct obj *) 0x0
#8 0x0808c0ab in move_monster (op=0xaa18980) at monster.c:326
dir = 0
diff = 0
owner = (struct obj *) 0x0
enemy = (struct obj *) 0x8c16890
part = (struct obj *) 0x80b82bf
oph = (struct obj *) 0xaa18980
rv = {distance = 0, distance_x = 0, distance_y = 0, direction = 0,
part = 0x0}
#9 0x080bc532 in process_object (op=0xaa18980) at time.c:1312
evt = (struct _event *) 0x0
#10 0x0808af52 in process_events (map=0x0) at main.c:1002
op = (struct obj *) 0xaa18980
marker = {contr = 0x0, next = 0x0, prev = 0x0,
active_next = 0xaa1ddf4, active_prev = 0xaa18980, below = 0x0, above = 0x0,
inv = 0x0, container = 0x0, env = 0x0, more = 0x0, head = 0x0, map = 0x0,
count = 0, refcount = 0, name = 0x0, name_pl = 0x0, title = 0x0, race = 0x0,
slaying = 0x0, skill = 0x0, msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0,
oy = 0, speed = 0, speed_left = 0, nrof = 0, face = 0x0, direction = 0 '\0',
facing = 0 '\0', type

Re: [crossfire] Quests, continued

[Mark Wedel]

Nicolas Weeger wrote:
 n items in your inventory? 


Imagine a quest like "cook NPC: I'm missing 10 potatoes for my
party tonight, please help me!" => player has the quest
"collect 10 potatoes". When s-he gets 10 potatoes, it could be
nice to put a reminder "oh, you found 10 potatoes, you can
give'em to the poor cook". So need to activate quests items
when player picks the last of 10 items.


 Ok - that makes sense.



I was thinking "when player opens the chest, if doing the
quest, find the right item and other random items. If not
doing the quest, just the random items".


 Do you then have a requirement that the item in question be unique in name or 
something?  Do you somehow tie the quest to specific quests?


 What I'm geting at is that you don't want to disable the player from finding 
whatever that item is in other chests.





Already done. I extended the match function, you can do
(imagine a NPC farmer, after the cook asked you to find 10
potatoes):
match @potatoe
quest potatoe_quest start
You're seeking potatoes? If you  help me find my missing cow,
I'll give you some".


 but being able to connect it to other connected objects has additional value.

 For example, pulling different levers could perhaps change your quest state. 
Or any other numerous connected objects - sacrificing something at an altar 
might not only open the door, but also change quest state, etc.






1) Give object.  Some quests (scorn nobility) quest does


this, but can 


potentially run out of objects - if done via quests, don't


have that problem.

Can generate random item, too - simple to do with plugin or
whatever.


 I thought you said you didn't want the quest stuff to be in the plugin?  this 
seems to state otherwise.


 I also think the trying to generate custom items via plugin could be a pain 
(eg, a bunch of script lines to set specific values on the object), unless that 
custom item is stored in the quest objects inventory or something.  And if we're 
going to do that, why get the plugin involved - let the quest controller do the 
right thing.






 Also, should have special code to give invisible objects -


if player doesn't 


have it, it gives them.  Thus, quests could give out skills


and spells. 


Potentially, there should be some fallback (player already


has meteor swarm, 


give them 10 potions instead or something).



Can be done through plugin, again. Code to check for all that
exists iirc.


 Same point above applies however.  I'd also think from a map maker 
perspective, it would certainly be nicer if I'm not required to know/use the 
plugin code to do simple quests.


 Now, the alternative object logic should perhaps be in the plugin, but I think 
the basic item creation should be in the server code.


 What the server does would largely be based on the object in question, but I 
think it'd be pretty easy to work out a system.


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

Re: [crossfire] Quests, continued

[Mark Wedel]

Nicolas Weeger wrote:


Well, i don't mention removing random items themselves.
Case scenario: player gets to treasure room or a ruined
castle, opens chests, find nice treasures.

Then later s-he talks to a npc: 'i'm the former servant of the
now dead king of that castle, could you recover my master's
mirror for me? i'd like to keep it as a souvenir' [insert
usual spam / reward line here :p]. Player redoes map, then in
one of the chests finds treasures and that mirror - but can't
find it without having talked to the npc.

Of course you could imagine quests where you start by finding
an item => don't redrop item if quest already started. Thus
need to check inventory / do quest thing.


 As a note, it isn't possible the code to know if an object in the chest was 
placed there by the mapmaker or was part or randomly generated treasure.


 What you probably want to do is add something like FLAG_QUEST_ITEM - this 
makes the processing all around much easier.


 For determining when we send object info to player, very simple to check that 
flag, and if that flag is set, then bother to check quest state.  This then 
fixes the problem of items of the same name showing up randomly.  It can also be 
used to make sure the item in question is the desired quest item.


 One question - what about these just showing up not in quests.  Eg, suppose it 
is in a chest, but the chest is burned up.  Does the item then always go away 
then?  Is it visible to everyone?  Not visible, but if player as part of quest 
is on the space it should be, it is visible?





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

Re: [crossfire] MF Crash/Arena petmode

[Mark Wedel]

Alex Schultz wrote:

Ok, because I've used the same logic block in a couple places I've 
separated into a separate function, and I've now split it into many if 
statements and such which should be much much more readable. I've also 
added many safeguards in the process that should get rid of the bug that 
caused the crash on metalforge and should hopefully prevent other 
similar bugs from cropping up (including some sanity checks that would 
indicate bugs in other places if they end up being triggered). I've 
tested this update and committed it to CVS. It isn't necessary, but it 
would be convenient if metalforge was updated to the latest CVS 
including this for more extensive testing before the upcoming release.


 I've just updated metalforge.  Given the timeframe, I probably want to let it 
run through the entire weekend to make sure it gets enough testing on it before 
making a release.




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

Re: [crossfire] Quests, continued

[Mark Wedel]

Nicolas Weeger wrote:


I was thinking of:
* create a new either 'quest' archetype, or special force, for
quests (right now i use forces, will probably keep that)
* use that to link items to quests. So an item could actually
be part of multiple quests. It's then just a matter of adding
force to item's inventory - editor lets do that, and maybe
we'll have a nice interface to manage quests.


 That can work, as long as the item in question doesn't normally have an 
inventory that is used.


 For example, such a system would not work if you wanted to make a rod of 
restoration as part of a quest, because it already has a spell object in the 
inventory.


 but it is true that you do need to have someway to denote what quest an item 
belongs to.




Then it could be simple, when opening the chest, to check for
one such force in items in chest - if there's a force, and
player doesn't have it, remove affected item.


 Mmm - this could work better the opposite way - have the force contain the 
item in question - if matches player, then remove object from force and insert 
it normally, if not, just remove the force as well as its contents.




I would say:
* quest items burn as everything else, unless mapmaker made it
indestructible. After all, not different than existing quest
items!


 But for all items, it isn't a 100% sure thing that items get destroyed - 
pretty much all items have some probability of it happening or not.



* quests should be party-aware. So if a party player is doing
a quest, and another party player not doing the quest opens
the chest, the quest item does appear and maybe quest-doing
player is warned so he can tell other player 'gimme that item
plz'.


 yeah, perhaps.


* if two unrelated players play in same map, and one not doing
the quest opens the chest, item doesn't show up. Let's just
argue that the player forced the chest open and destroyed the
item by being uncareful :)
* or we could give the item anyway - this way quest doing
player could get item from another player


 To me, this seems the more logical approach.  If you're not doing a quest, 
finding that silver mirror is probably meaningless to you, and that is how it 
would be in real life.  If you are doing the quest, you'd be informed that the 
silver mirror needs to be returned to xyz.


 Sure, it does mean other players could fetch quest items for others.  But that 
isn't very far removed from 'killing all monsters so player on quest can come in 
and open the chest'.


 After all, the person that wants the silver mirror doesn't care how it is 
returned - if it passes through 10 hands, doesn't make a difference to them.


 If player fetching it is important, could always add one of the proximity 
checkers on the map to make sure the player at least visits the map.


 Which leads to an interesting question - is it possible to set bit states on 
the quest status flag.


 I'd imagine you could have a thing like 'go here, get item X, kill y'.  And 
you'd want to do something like |4 for the go here, |8 for get item, and |16 for 
kill y, and then check for 28 in the state flag.


 Granted, this could be done by three seperate quests, or by enforcing order 
(stage 1 sets state to 4, and only if state is 4 will get X set it to 5, and 
only if 5 will kill y set it to 6, etc).


 Perhaps an easier to see example would be 'deliver these 5 messages to ...' 
type of thing.



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

Re: [crossfire] CVS branches

[Mark Wedel]

 I'd be more concerned about this if there were lots of commits going on,
or there was a real desire to have a stable branch (eg, significant changes in 
main branch that may make it real unstable or incompatible, and thus you want to 
retain an older branch for compatibility reasons.


 But the fact is it does add more work - someone has to take patches from the 
head branch and put them in the stable branch and vice versa.


 The other issue is that generally, I'm not seeing so many commits that having 
people hold off a week would seem like much an issue.


 The simpler approach would not do real branches, just for me to keep a checked 
out copy and use that when making the release, and bring over changes manually 
that are critical in nature.  Problem with that is you can get the case where 
there is no version is CVS that directly corresponds to the released version. 
However, I suppose in that case, a branch for any relevant files could be made 
at that time.


 But what it really comes down to is that it is more work for the person doing 
the release (me), and I really don't want to make things any more complicated 
for myself - I'd much rather be dong stuff more worthwhile than syncing up branches.


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

Re: [crossfire] Metalforge down?

[Mark Wedel]

 The crash is because there are hundreds (thousands) of fire objects on the 
same space.  So the time it takes to insert a new one is sufficient that it 
grinds to a halt.  That's the cause of the hang (it is still processing, just 
not getting anywhere).


 The problem is that I'm not sure why it is getting to that state.  The cone 
code is such that only one force of each cone should be on any space.  So it 
almost seems like hundreds (thousands) of cones are being cast.


 Unfortunately, by the time I see it, the original source of the problem is 
gone - I see the cones propogate, but not what originally created them.


 I suppose it could be a malicous player casting hundreds of runes on some 
space which some player sets off.  but otherwise, if anyone has a clue, let me know.



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

Re: [crossfire] CVS branches

[Mark Wedel]

Nicolas Weeger wrote:

Hello.



The other issue is that generally, I'm not seeing so many commits that
having people hold off a week would seem like much an issue.



Well of course we can always wait one or two weeks to add features. But
sometimes it's things we'd rather have people test fast than wait weeks.
Also need to consider the possibility of finding a weird bug weeks after
the release - nice to be able to backport to current stable even after
having a whole lot of commits.


 Yes, although that doesn't come up that often.





The simpler approach would not do real branches, just for me to keep a
checked out copy and use that when making the release, and bring over
changes manually that are critical in nature.  Problem with that is you
can get the case where there is no version is CVS that directly
corresponds to the released version. However, I suppose in that case, a
branch for any relevant files could be made at that time.



That could work, but you'd also need to send the files to specific
platforms maintainers (me for Windows) to have synchronised releases,
with same code.


 I could, if necessary, do a branch commit if there are in fact any files that 
are different.  But then I suppose the question is why not just do a branch in 
the first place.


 Of course, within CVS, there really isn't a branch until something needs to be 
commited that is different.


 We probably want the main (head) stream to continue to be CVS.  So by the time 
you want a branch, it is in a sense too late (someone has already commited 
somethign to the head).  An in that case, you don't really want a branch, unless 
you make changes - you just want to note that version x.y is what is going in 
the main release.


 Using tags may actually make more sense.

 Right now, when I make the actual release, I tag the files, so you can do 
something like 'cvs checkout -r rel-1-7-0'.


 But as described about, not until a change happens do you need a branch.  So 
what should probably be done is at the 'code freeze' time do a cvs tag can-1-8-0 
or something.  Thus, if nothing changes, that can be tagged again as rel-1-8-0 ( 
can = candidate, rel=release).  So if changes are made to CVS head, no big deal 
- the can- tag is still there to get the files to release.  If a fix needs to be 
backported, the can- tag can be used to find the point to make the branch from.






But what it really comes down to is that it is more work for the person
doing the release (me), and I really don't want to make things any more
complicated for myself - I'd much rather be dong stuff more worthwhile
than syncing up branches.



On the other hand having a branch lets more people contribute to fixing
bugs on that release, anyone could backport as opposed to your scenario.
Also, I don't think there's a rule in stone saying only you can do
releases, is there? :) I'm sure we'd find people to help for that. I'm
also pretty sure CVS helps a lot for merging changes.


 If other people want to help with releases, that would be great.  Having a 
more frequent (quarterly) release schedule would also be good.


 Even people taking some portiosn of the release (maps, archs) reduces the 
effort a bit on my side - those bits aren't really hard, but if I save myself 15 
minutes, that is always nice.



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

Re: [crossfire] Am interested in porting to Mac

[Mark Wedel]

 Quick notes on how the common stuff works:

 The GUI aspect of the client controls its own event loop.  All it needs to do 
is check the network socket to see if it has input, and call do_network().


 do_network() then reads the data and parses it, taking care of the protocol 
and making function calls on its own.


 In some cases, this results in function calls back to the GUI area.  the 
common/external.h lists the functions the common area will call.


 In some cases, the gui functin call may do nothing at all - it may just 
provide that function because _some_ clients do something with that.


 The common area also sets up data structures - the most notable of these is 
the_map structure which is what the map looks at.  Other things it maintains is 
the players inventory, stats, etc.


 In the case of the opengl client, it basically doesn't do anything with the 
disaply_map_..() functions, other than to set that the map has changed.  It then 
just redraws the map on its own timeframe (basically when there is no input left 
on the socket).


 I have no idea if this callback method works with objective C.  But as others 
have said, if you can continue to use the common area, it certainly will save 
you work in the long run - while the protocol may change, these functions and 
data structures are less likely to change.


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

Re: [crossfire] CVS branches

[Mark Wedel]

Nicolas Weeger wrote:

What will be the next server version? 1.7.1 or 1.8.0?
If no one object, i'll put a tag for the release candidate tomorrow or
friday, so people can again break cvs with commits :)


 Got my system stable again, and upload 1.8.0 right now.  So feel free to 
commit away.



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

Re: [crossfire] CVS branches

[Mark Wedel]

tchize wrote:

Joining thread a bit late, trolling a bit perhaps :)

I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a 
bad decision is always better than no decision).

I don't think we need branching at each release (unless we
want to keep a few weeks after release a bugfixing branch while
devels can develop addons in main branch).


 I think the rule on this is that branching at release time will only be done 
if there is some fix that needs to go in for the release but the latest version 
of that file can not be used.


 For example, at time of release candidate, player.c is 1.20
 a few days later, someone commits some changes (new features) that result in 
player.c be 1.21
 A bug is discovered and fixed in 1.22.  That fix is desired for release, so a 
branch from 1.20 is done with that bug fix.


 So in general, I'd expect branches to be uncommon.



But perhaps, we need more of a release and development policy. I may be the 
only one to think this, but isn't developpement here a bit too democratic 
(without much obligation, other than discussing big changes in ML). Coders 
put add-ons they like and which meet some players need. This is great. But 
maybe, to have a good release policy, devels should make once a year or alike 
their 'development plan' (what and when add-ons could be done) and submit it. 
Then a few reviewer amonst us would analyze all given plan and provide a 
yearly timeline on when we will release and what should be in for each 
release.


 that could be convenient.  But as said before, given a volunteer effort, it is 
always hard to drive those things.


 People probably have enough deadlines to keep at work and school, and don't 
really want one for something they do for 'fun'.


 It's also hard to get volunteer people to do something they don't want to do. 
 So while statements like 'code xyz need to be cleaned up', can be hard to 
convince someone to do that.


 That said, certainly deciding release schedule based a expected features makes 
sense.  If nothing but a few bugfixes, might not be a reason to do a release.


 the problem is that can then lead into the current case - long time between 
releases because it is hard to discern when there are enough notable changes to 
warrant a release.


 that said, doing a release tonight, one thing I found is that aspects of the 
make dist were broken - more frequent releases should probably keep that more up 
to date (or at least not as many broken pieces)



Currently, If we go on quarterly releases, i have no idea what is forseen to 
be on following release! And am sure am not the only one. Lots of other open 
source projects have a clear idea of what is to be done for when. Even if the 
delays are not to be followed strictly (some project releases years after 
forseen date :) ) this give a clear view to users and also to developers.


 I think it would certainly be nicer to have a clearer idea of what people are 
working on and when they expect to complete it.  If nothing else, it provides 
some visibility of what everyone is doing - maybe a wiki someplace?  Or maybe 
something like Leaf maintains for the maps?


 Only actual projects/features need to be tracked - if your fixing bugs, don't 
need to document that - if your writing hundreds of lines of new code, that 
should probably be tracked.



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

Re: [crossfire] CVS branches

[Mark Wedel]

Brendan Lally wrote:

On Monday 08 Aug 2005 07:49, Mark Wedel wrote:


 If other people want to help with releases, that would be great.  Having
a more frequent (quarterly) release schedule would also be good.

 Even people taking some portiosn of the release (maps, archs) reduces the
effort a bit on my side - those bits aren't really hard, but if I save
myself 15 minutes, that is always nice.




I'll volunteer if someone will point me to a suitable HOWTO document/checklist 
of things to do.


 this is actually a script I have:
#!/bin/sh
echo "Did you remember to update the version?"
gtar --exclude=CVS --exclude=unlinked --exclude=test -hcvf maps.tar maps
gzip -cv9 maps.tar > maps.tar.gz &
bzip2 -cv9 maps.tar > maps.tar.bz2&

gtar --exclude=CVS --exclude=dev -cvf arch.tar arch
gzip -cv9 arch.tar > arch.tar.gz &
bzip2 -cv9 arch.tar > arch.tar.bz2&

cd crossfire-CVS; make dist
cd client-CVS; make archive

 But the slightly more detailed bits - at least for arch and maps:
do cvs update -dp to make sure all up to date.
cvs tag rel-1-8-0 (or whatever) to tag the files.
Then run those tar and zip commands.

 The server and client are a little more complicated - in those cases, the 
version number has to be updated in the configure.am/in file, and then 
autoconf/automake run, then has to verify that everything does build.  Then a 
cvs commit for those new files, followed by the cvs tag, then followed again by 
the make dist/archive so that the files distributed really match those.


 That said, the client really needs to be updated to use automake throughout 
it.  When I put in the gtk-v2 client, it was using automake, so kept that, but 
its this funky automake/non automake hybrid.  automake provides the make dist 
for us, so as long as the file listing in the makefiles is kept updated, that 
makes life easier.





___
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] specialised shops

[Mark Wedel]

 If memory serves, garbled actually put in code that did sort of the supply and 
demand thing.  IIRC, prices to buy stuff were basically nothing.


 The most basic is that there is little stuff that players buy in stores.

 My personal experience:
Spellbooks (especially at low levels where spellbooks don't show up in maps)
healing potions
potions of life
Once in a while, a ring or other object - in the case of armour, the rare cases 
where the shop has something better than I found.


 The basic problem, if we go back to the cpu analogy, is that the shops sell 
1500 mhz cpus, where going through the dungeon, you regularly find 2500+ mhz 
cpus.  So why ever buy from the shop?  And the few times the shop has the 4000+ 
mhz cpu, it is incredibly expensive.


 Also, I think the crossfire approach goes back to a long line of RPG games, 
where you go back and sell your stuff in the shop.


 Looking over the patch, a few quick thoughts:
1) Why not put shop_greed as its own field to make it easier to pull that data 
out?

2) Another thought would be to add a shop_cap value or the like.  Right now, in 
the sell function, there is a point where objects higher than a value become 
worth quite a bit less (lines 155-160 in shop.c).  Having these adjustable based 
on shop could also be interesting (high level players wouldn't find scorn shops 
very useful, but places like lake county or brest could be more useful).


 Likewise, havinga shop_min_value which is the cheapest items shops will buy 
from players could be interesting (shops have a minimum standard to uphold) - 
selling junk at the brest shop is not likely to be welcomed.


 One could see having 'membership' shops - have to pay to be able to use it, 
but also get better prices.


3) From a player perspective, depending on the difference you get in the 
specialized shop, I think it will still be convenient to have general shops - 
maybe get .75 value or something - I just don't really want to have to wander to 
5 shops to sell my loot, and am willing to pay something for the convenience factor.



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

Re: [crossfire] Metalforge down?

[Mark Wedel]

Anton Oussik wrote:

On 8/8/05, Mark Wedel <[EMAIL PROTECTED]> wrote:



 I suppose it could be a malicous player casting hundreds of runes on some
space which some player sets off.  but otherwise, if anyone has a clue, let me 
know.



Instead of processing each effect individually, would a better
approach not be to have a single spell effect per tile and add to it?

For example instead of having a stack of fireballs from meteor swarm
or banishment on one square, have one that has "Time To Live" foo.
Damage dealt can then be deduced from how long it has to live (a spell
that has longer to live should cause more damage as it is more
powerful?). It can then decay in strength with time, and if any more
of the same spell is cast on it, the new spell can simply increase the
time to live, and therefore strength and damage dealt.

Other spread, damage, and decay-related parameters could then be added
to make this more customisable. If needed it could possibly be made to
decay along some decay curve, but that would be more CPU-intensive.

I know this approach is very different from what is being done now and
will proably require substantial changes, but it should prevent single
players from being able to grind the server to a halt, as after the
initial explosion it will not matter if you have one fireball going
off or a thousand.


 It becomes very complicated.

 Merging spells of different damage types is not likely to work, or if you try 
to do it, result in abuses that are easily exploited (if you take whatever is 
higher, you now have just let players effectively get more potent spells.  If 
you take whatever is lower, players could now neutralize spells)


 In addition, there are lots of reasons these objects may not be able to merge 
- different owners would be the most obvious, but different ranges (small vs 
large fireball), different durations, levels, offsets (if two explode one space 
from each other, do you try to merge those effects)?


 If the problem is player abuse, all that is really happening is you're making 
it a bit more difficult for the players.


 A more sensible, and much easier approach, is to just track the number of 
spell objects on a space.  If it goes above some count, basically just don't 
insert anymore.  One could argue there can only be so much going on in one space 
anyways.  And a number could probably be found that is high enough that it is 
unlikely to ever be reached except by people trying to abuse the system, but 
still low enough the performance is at least somewhat OK.




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

Re: [crossfire] Extensions to building

[Mark Wedel]

Alex Schultz wrote:

I don't know much about the styles for random maps and such, but I 
wonder: would it be possible to use unique floors in a random map so it 
would work like normal unique maps? If so, I think such a random map 
approach would be a good one to make buyable buildable pocket dimension 
things.




 unique floors in random maps will basically do nothing at all, or worse, 
really screw things up.


 That is because unique floor information is stored based on map name.  random 
map names are basically just an increasing value (goblin001, goblin002), so the 
unique stuff would be stored as goblin002.  When the goblin maps reset, the next 
series will start at a higher number, and thus, the unique info won't be found.


 IF the server does restart, then the unique names may be used again.  But then 
at that point, the new map and last unique map are not likely to match, so the 
unique stuff is not likely to show up as expected (and if the new map size is 
smaller, unique stuff could be out of the map bounds).



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

Re: [crossfire] specialised shops

[Mark Wedel]

Brendan Lally wrote:

On 8/13/05, Mark Wedel <[EMAIL PROTECTED]> wrote:



 Looking over the patch, a few quick thoughts:
1) Why not put shop_greed as its own field to make it easier to pull that data 
out?



well, the thing is that if I start doing that, it can lead to a stupid
number of map headers. I have been writing in a prefered race to the
things it can parse for, I suspect other things may be added with
time.


 I'd rather have a number of map headers than a long string of stuff that one 
has to parse.


 Mostly because such a case is easier to debug, and probably results in fewer 
bugs - if there is a long string to be parsed and you're seeing odd behaviour, 
is the problem in the string?  In the parser?  Someplace else?


 If instead it is something simple like map->greed, very easy to verify that 
the parser (loader) handled it correctly and the value is indeed set correctly.


 Certainly for the objects themselves, having that as one line makes sense, 
since it is a set of attributes for one field (one could see this is similiar to 
the slaying field for objects - it can be a comma seperated listed, because 
having a slaying1, slaying2, etc fields wouldn't make sense).


 So please do pull shop_greed into its own field, as well as any others added.



Also with a single line to parse, it is easier to write a simple bash
script to find the best place to sell any given item, not that anyone
would do that of course :)


 Would be only marginally harder to write a perl script to do that.  And in 
fact, one could probably modify the various map check scripts to do that quite 
easily.






2) Another thought would be to add a shop_cap value or the like.  Right now, in
the sell function, there is a point where objects higher than a value become
worth quite a bit less (lines 155-160 in shop.c).  Having these adjustable based
on shop could also be interesting (high level players wouldn't find scorn shops
very useful, but places like lake county or brest could be more useful).



And there we have another thing :)
actually that is an idea I really rather like, I don't know if there
is a nice way tell a player that they are up against the cap though,
(maybe in the description in c_object?)


 One thought, if not already done, is that when the players use the shop map to 
enter the shop, pull the info from the map header and tell the player, eg:


This shop specializes in weapons, bows, and arrows.
They generally do not buy things above 500 pp.
They will not buy things worth less than 3 pp.

 (better phrasing may be necessary, but you get the idea).  Thus very clear to 
the player what they are and are not getting.


 Having a shop with a very high minimum value could be interesting if also made 
with a very high timeout - there'd be a shop where really expensive (and thus 
useful) stuff is.






Yeah, I have the penalty for being a general store at 50% at the
moment, that is trivial to change though if that is too harsh


 Having that be setable is what I was thinking - then that general general 
store may give 75%, but that membership general store gives 85% or something 
(but maybe once again has higher minimum value it buys)



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

[crossfire] gcfclient and sign display

[Mark Wedel]

 I should probably preface that I'm responsible for the 'nopopup' mode in the 
gtk client (v1).


 But does anyone else find the sign display code in the client really annoying? 
 To me, these are the major issues:


1) No way to turn it off, save for code modification.

2) It centers it on the screen, not the client.  This is bad behaviour, 
especially for those of us with dual monitor setups (I really don't need it 
straddling the monitors)


3) It shifts input focus to the sign area itself, thus the client stops 
receiving useful input (like movement commands)


4) No button or the like to dismiss it - have to use whatever functionality your 
window manager provides to dismiss it.


5) Since info appears in that window, it does not appear in the normal windows, 
thus, once destroyed (or you read another sign), you lose the contents.  Thus, 
that information on the sign at the start of the dungeon may effectively be lost 
(won't be in scrollback buffer).


6) At least as things are now, it doesn't really add much.

 I guess the key issue is #1 - then people can just turn it off, and anyone who 
uses it is basically choosing to live with points 2 through 5 (or they aren't 
important).


 But when I first saw this proposal, I had envisioned that it'd do something 
clever with the text window (draw graphics, whatever), not put in pop up windows.




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

Re: [crossfire] Client display logic rewrite

[Mark Wedel]

Andreas Kirschbaum wrote:


But the actual server implementation differs: the server just forgets
the out-of-normal-map-bounds information after a map_scroll.

What should I do here?

a) fix the documentation (map_scroll implicitly clears out of map bounds
   information), or


 That seems fine.



Another question: I did fix all clients (x11, gtk, gtk2) and (where
appropriate) with -smooth, -sdl, and -opengl. Unfortunately, I cannot
test gtk2 -opengl because it crashes at program start up with a
"BadMatch" error. Is this a problem with my X11 setup or is the client
broken?


 I started seeing the same thing after I updated by system and lost the 
hardware opengl support.


 I would have thought that the software (emulated) gl support should work, but 
apparantly doesn't.  I'd need to check the output of glxinfo in both cases and 
see what is different - most likely, the software opengl support isn't 
supporting some type of visual  or the like - that is what BadMatch typically means.


 Open a bug on this so its not forgotten.  That said, if you don't have 
hardware opengl support, you don't get much by using that mode.



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

Re: [crossfire] gcfclient and sign display

[Mark Wedel]

tchize wrote:

Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit :

 I should probably preface that I'm responsible for the 'nopopup' mode in the 
gtk client (v1).



What is?


 run with -nopopups command line option.

 Without it, gtk client pops up window for player name, password, and some 
other things.


 With that option, player name and like is entered in the text dialogue box.




 But does anyone else find the sign display code in the client really annoying? 
 To me, these are the major issues:


1) No way to turn it off, save for code modification.



First comments on it i receive since implemented. Disabling for those 
requesting it should be easy to code.



 Please do so, ideally adding a config option that shows up in the config menus 
and is saved in the config file (eg, like all the other config options).


 This is a relative new feature, so not positive how many people are really 
using it, which could be one reason relative to comments.




2) It centers it on the screen, not the client.  This is bad behaviour, 
especially for those of us with dual monitor setups (I really don't need it 
straddling the monitors)



GTK centering behaviour, do not know much of gtk to know how to correct this.


 I recall there is an option to center it on the application and not the 
screen.  I don't know it off the top of my head, but I think the magicmap code 
(which creates a popup) uses that.





3) It shifts input focus to the sign area itself, thus the client stops 
receiving useful input (like movement commands)



Quite obviously, you are *reading* the sign, not doing much more else. This 
seems to me
a normal roleplay behaviour. If you have any better idea...


 There shouldn't be any reason it needs to shift input focus.  I can move the 
mouse to get focus on the main screen again with the sign still up.


 Alternatively, any input it receives should just get passed along to the 
client where applicable (mouse presses aren't, keystrokes are)


 My concern here is as more objects get this support, it can mess up players. 
Imagine what happens if the wrong scroll gets applied while in the middle of 
combat (a scroll containing info vs that scroll of restoration) - not only did 
you get the wrong scroll, but until you move the mouse around, the client stops 
getting any input, likely resulting in a dead character.





4) No button or the like to dismiss it - have to use whatever functionality your 
window manager provides to dismiss it.



Could be added i suppose, though i don't see why the window manager way of 
closing
windows is an issue.


 Requires moving the mouse and clicking.  Normally, once I start playing, I 
tend not to need to move the mouse for large stretches, and when I do use so, it 
is then continuously for a little while (selling those items).


 But this also goes up a bit to the one above - the comment about a key press 
(or specifically, 'a',) dismissing it seems quite reasonable.


 The first time this happened to me, it took several seconds to figure out it 
was this pop up sign.  IMO, this is not a good/intuitive design then.



 But when I first saw this proposal, I had envisioned that it'd do something 
clever with the text window (draw graphics, whatever), not put in pop up windows.




GTK too limited to do 'something clever' like draw graphics in the text window. 
Moreover, if my memory don't fail, concerning signs, i never suggested doing anything

else than show sign content inside a sign graphic.
And unless i miss something, having a popup show up when you apply a sign 
and not be able to fight is not really a problem, unless you start applying signs

while fighting??


 See comment above, or do you not plan to extend it to things likes books and 
scrolls (I seem to recall that was on the list of things to do).


 I can understand that there is limitation with the text window.  But I thought 
it was possible to draw graphics in the text window (was marginally more 
complicated, but still possible)



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

Re: [crossfire] gcfclient and sign display

[Mark Wedel]

Brendan Lally wrote:

On 8/16/05, tchize <[EMAIL PROTECTED]> wrote:




Even better would be if the food value were a role against Int, and if
recalling a sign with a low food value corrupted the message
(arbitrarily transposed some words, or mispelt some things) - the
recall then, would be the memory of the /character/, and not the
player.


 The problem with that is then the players will just copy/paste the contents of 
important signs into text editors or whatever.


 Unless there was a hook to actually require the character have read and 
remember the sign, all it really does is add more bother to the player.  And 
that's something I'd want to avoid at some level.


 My real beef about the signs wasn't long term memory.  There are several maps 
that have a sign early on in the map which contain info related to finishing the 
map(s).  Being able to find that information without having to visit the sign 
again is nice, and the current implementation doesn't have that.


 With the multiple text windows, sign messages don't get lost that often (but 
this depends on frequency of people chatting).  So all I really wanted was some 
way to have that info there - putting a copy in the text window works fine or me.



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

Re: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire

[Mark Wedel]

Andreas Kirschbaum wrote:


It is also a mistake for me to send as void* (as opposed to const
void*), since it's then easy to change the string in the plugin which
would lead to data corruption.



I agree. But wouldn't it be better to leave out the type casts and let
the compiler issue warnings? After all, (as you pointed out) it *is* a
problem, so suppressing the warning is not good.


 My two cents:

 If we know it is a problem, but one which we consider safe, I'd rather supress 
the warnings.


 Otherwise, what happens is you get 500 warnings (or some other large number), 
and you'll just ignore them all.


 If we fix the warnings that in a sense we know about, then any warning that is 
spit out is a real issue and needs to be examined.  That examination may reveal 
that the behaviour is 'ok', and putting a cast in or whatever supresses the 
warning and go on.


 In other cases, warning may find a real problem for us.  And that is a good 
thing.



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

Re: [crossfire] specialised shops

[Mark Wedel]

Brendan Lally wrote:


 One thought, if not already done, is that when the players use the shop map to
enter the shop, pull the info from the map header and tell the player, eg:

This shop specializes in weapons, bows, and arrows.
They generally do not buy things above 500 pp.
They will not buy things worth less than 3 pp.

 (better phrasing may be necessary, but you get the idea).  Thus very clear to
the player what they are and are not getting.



I am unsure about this one, what I have done so far is give a cue to a
player leaving a shop as to the shopkeepers mood, instead of saying
'thank you for visiting our shop' all the time, it now has things like
"The shopkeeper gives you a friendly wave." or "The shopkeeper glares
at you with contempt."


 the problem here is that in some sense, it is too late.

 I really should be getting clues while selling objects.  One issue is the way 
selling works - you drop the item, get the money, and sale is done - no going back.


 As a player, it'd suck to sell something worth 5000 pp and only get 500 pp 
because its a cheap shop.  The problem is, if I don't find out I'll only get 500 
pp until I sell it, I'm a bit out of luck.


 In real life, there'd be more give an take.  You'd say 'how much for this 
widget', and shop keeper would say '500 pp', and you'd go and take your business 
elsewhere.


 I'm also concerned as this is a change in how things currently work.  Players 
are currently used to going into whatever shop and getting a fair price.  If 
they don't get any warning that they won't be getting fair prices, that is a bit 
 of an issue.  This was another reason why having the shop maps tell info on 
entry would be good - players may ignore the message, but at least they got fair 
warning - it is their fault they didn't read it.


 One thought, which I'm not sure if its done, is that examining an item _in the 
shop_ should reveal precisely how much the shopkeeper will give, and any other 
relevant information (beyond what he'd normally pay, below what he'd pay, etc).


 The stuff below value is easy - shopkeeper doesn't buy it, so player can pick 
it up and take it elsewhere, no worse for wear.




likewise I was going to have a cue in the description for the max
price (something like 'the shopkeeper says, 'this is more valuable
than most things I would trade in, I can offer you FOO but no more
than that', I would have an equivilent thing for things that are worth
too little.

getting the item types isn't possible as far as I can tell, the
correspondance between description and  number is in a series of
defines, and is stripped out by the pre-proccesser.


 It wouldn't be hard to set up a table of that mapping.  The defines aren't 
really good names anyway.




In any event I was thinking more of using some of the spare people in
taverns to give hints to the player (eg someone in a pub says, 'I got
a new pair of gloves from $FOO in $BAR yesterday, he ripped me off)


 That's nice, but comment about change of behaviour relative to experienced 
player still apply.


 Maybe put in the messages for transition purposes, and then down the road, 
they could be disabled.



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

Re: [crossfire] Quests ideas, continued

[Mark Wedel]

Nicolas Weeger wrote:

Hello.



Quests are subdivided in "tasks". You don't need to complete all tasks
to complete the quest. So for instance if you ask an ncp you'll get to
know the shortcut to the big manor with the villain you're supposed to
kill, but you don't require it.


 It'd probably be nice if that is somehow setable (eg, you need to do tasks 
1,5,6, but 2 and 3 are optional).   Not positive how hard that would be to set up.




Quests/tasks should be able to interact/start/end when player:
* takes an item
* talks to a npc/...
* goes to a specific place
* activates an altar


 I'd like that be be more general - activates any connected object, just not an 
altar.  Might not make sense to tie some actions, but I think the ability would 
make it more flexible.




Quests rewards:
* items
* skill
* experience (either some levels, some rough exp, a percentage of exp
needed to level, ...)


 If this is a level or percentage of a level, then I think some form of cap is 
needed.  Eg, you don't want high level characters doing easy quests as a way to 
get a level in something.




* when the quest is completed, keep tasks for later referral. Or maybe
remove some?


 probably want to record quests that where completed, not sure if we care about 
unfinished tasks.




Performance issues: many inventory checks required. Move quests items in
a specific sublist at load time?


 Some checks, but it seems not very often.

 Monsters being killed doesn't happen that often, so checking their contents at 
that time isn't that big a deal.


 All the rest are relatively infrequent (player talking, altar, etc).  So I 
don't think performance wise, it shoudl be much an issue.



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

Re: [crossfire] autogeneration of news file

[Mark Wedel]

 In my mind, the news file should contain broader/bigger changes.

 Grabbing all the data from the Changelog is likely to be more data/detail than 
most people care about.  Are players really going to care that the global arrays 
are now consts, or that pointers have been fixed up?  Probably not.


 You could perhaps limit it to 50 lines of the most recent changes.

 However, I think it would still be best to just hand edit that file for 
changes that players should really be aware of.


 That way, players are actually likely to read it.  If you otherwise just get a 
list of changes that you ignore most of the time, you won't notice the few times 
there are changes you actually care about.



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

Re: [crossfire] Mac client - status

[Mark Wedel]

Amorya North wrote:
I've got somewhere. Common files compile in now, and work fine. I've  
got a vague event loop up and running, and some of the callbacks  work. 
I've got as far as displaying text sent to the console, and  displaying 
a list of current stats.


Here's a screenshot:

http://www.amoryanorth.com/crossmac.png

There's a lot I don't understand about the common code still - in  
particular, what the create_and_rescale_image_from_data() function is  
actually supposed to do! But I'm working on it.


 Just as it sounds.

 All image data is png.  However, the png data has to be converted to something 
that the display system knows how to display.


 In order to abstract this, the cache_entry image_data pointer is basically 
private - whatever the display specific code deams to store there is fine.


 The basic idea of this is to have the caching logic all in the common code (if 
it gets a face it knows about, it will do the right thing), but have the actual 
rendering code in the client area.


 For the gtk and gtk-v2 clients, that function is perhaps a bit messier than 
need be, because those clients support different display modes (pixmap, sdl, and 
in case of gtk-v2, opengl), so what exactly is stores there may be different.


 The rescale part is jsut that - rescaling of the image.  You may decide for 
your client that you don't want to allow rescaling - that's your choice.  Just 
for the gtk clients, people wanted to be able to rescale the data so they could 
play on lower resolution displays.




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

Re: [crossfire] Crossedit patches

[Mark Wedel]

Kevin Rudat wrote:

Crossedit - which of these would you accept, please?
 * Fix: not drawing floor at weird times.
 * Fix: large faces
 * Fix: regions
 * Fix: Map attribute editor 
 * Fix(?): Using window manager's close functions closes the window rather

   than stopping crossedit.
 * Feature: Display only certain things, like the Java editor can.
 * Feature: crossedit starts faster - images uploaded to xserver when needed
 * Some user documentation


 It's sort of a mixed issue.

 On the one hand, crossedit is basically obsoleted, so I don't want to spend a 
bunch of time and resources maintaining it.


 On the other, if people want to do so, who am I to say don't do it.

 That said, when doing such patches, it makes it much easier to deal with if 
each patch is limited to what is if fixing/adding, and not redoing other code, 
or a collection of fixes.  Small focused patches are much easier to look over 
and be convinced that they do the right thing.


 And while not an issue with crossedit, the general case is that if the patches 
can be isolated, more likely to apply correctly or figure out what is going on. 
 If the patch does several things and very large, odds are more likely that it 
may get a conflict, and it can also be harder to tell what the correction to 
that conflict is (eg, not clear what bug/feature is being addressed).


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

Re: [crossfire] Renamed objects and inscribed objects

[Mark Wedel]

ERACC wrote:

Greetings y'all,

It has come to the attention of DMs on Metalforge that some players
are abusing item renaming and inscription to get around the "no foul
language" rule on Metalforge. For example an item was renamed to a
rude phrase and dropped in Scorn where kiddies would see it.

If a coder would be so kind as to make a patch to add the player name
to these objects when a player mods them that would be quite lovely.
Just the name of the last player to edit the object would probably
work (renaming or inscribing).


 Just a note - the key/value code I checked in a few days ago would make this 
very easy.


 if desired to seperate inscriber vs renamer, could even do that, eg, in the 
appropriate place:


set_ob_key_value(op, "item-renamer", who->name, TRUE);
and
set_ob_key_value(op, "item-inscriber", who->name, TRUE);

 The dump below command does properly print out these key/value entries.


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

Re: [crossfire] Mac client - status

[Mark Wedel]

Amorya North wrote:

Ah, ok - so I can store a pointer to an NSImage in the cache entry?  
That would help a lot. I was wondering where I'd be able to do the  
conversion.


 You might want to double check the gtk code/image.c - I'm not sure if your 
client would need to store anything else.  At least for the gtk client, since it 
stored multiple image entries (one for the image, one for the mask, as well as 
one for inventory display vs map).  But if one pointer conveys all the data you 
need, then I think that should work.




As for scaling, it's dead easy in Cocoa. A single line of code will  
scale the map window's contents _after_ it's been composited. So I  
won't allow scaling of images to be stored - it's just not needed!


 If performance is acceptable doing it that way, that is fine.  It was just 
generally a lot more efficient to scale day the images when created so you are 
moving fewer bits around than moving around the full size images and then 
scaling down the entire map display - if the scale down is done in software, 
probably can't be done fast enough during gameplay.


 that said, there is no requirement that scaling of the data even be allowed.


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

Re: [crossfire] Crossedit patches

[Mark Wedel]

Kevin Rudat wrote:


I didn't mean to imply that I'd give a bunch of changes in one monolithic
patch. :(

Which patches is it worth making, for inclusion in CVS?

At the moment all the changes are in one source tree. It's a bit more work
to extract them into separate diffs.

I wanted to know if there's any objections to the changes, so I don't spend
time composing patches that won't be used.

I mean, objections to each idea, rather than issues discovered when
reviewing a patch itself.


 I don't have any objections to any of the specific ideas, as long as the 
patches are of reasonable enough size to be easily handleable, or you want to do 
the CVS commits yourself.



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

Re: [crossfire] Re: Crossedit patches

[Mark Wedel]

Lalo Martins wrote:

And so says Kevin Rudat on 21/08/05 14:26...


On Sat, Aug 20, 2005 at 09:53:43PM -0700, Mark Wedel wrote:

On the one hand, crossedit is basically obsoleted, so I don't want to 
spend a bunch of time and resources maintaining it.


On the other, if people want to do so, who am I to say don't do it.


I was thinking/hoping you'd say something like that. =)



Personally, I like crossedit better.  May be my allergy to all things
java in general.  If you want to maintain it, more power to you.  If you
want to re-do it in gtk2, I might even step up to help.


 I wonder how much is also force of habit - took me a while (and some code 
changes) to get the java editor to the point I was willing to use it.


 That said, java is very portable, so easier for those non unix people to use 
it.

 I suppose a gtk client would be easier to make to a windows port.  And while 
one side of me would sort of like the speed and efficiency of such an editor, 
one side of me says I really don't want to see another such editor due to the 
maintenance and support headaches it would involve (support for the deprecated 
crossedit is headache enough).


 That said, doing a gtk client probably wouldn't be really hard - layout could 
be done with glade, and the fact it would be C would mean it can basically 
re-use a lot of existing code (load/save code, display logic from client, etc). 
 But that's really not a road I'd want to see resources spent.




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

Re: [crossfire] Map cache

[Mark Wedel]

 The problem is that it often isn't the world maps that cause the lag.

 It is peoples personal apartments or the like where people pile many thousands 
of different objects.  I believe the worse case was the communal apartments. 
I'd imagine other cases right now might be guilds.


 The 'problem' with preloading is how do you know what maps to load?  Looking 
at all the maps on the server and figuring which to load would take a non 
trivial amount of time.


 Also, these maps still need to be saved out periodically, which may also take 
a non trivial amount of time.


 In addition, as the server is right now, when maps are in memory, the objects 
on them are processed, when not in memory, they aren't.  Thus, keeping a map in 
memory would result in that map being processed, which could mess some things up.


 The best solution is to do something similar to what Brendan suggests - 
seperate map loading, freezing the player.  I had tried to do something like 
that many years ago, never worked very reliable.


 Better long term would be for each map to have its own thread.  With multi 
core/thread cpu's, this makes more and more sense.


 However, that requires some prety significant changes.  First being that any 
function that declares any variables as static is not thread safe.



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

Re: [crossfire] Re: Crossedit patches

[Mark Wedel]

[EMAIL PROTECTED] wrote:


Personally I prefer the java editor's interface, though issues with java have
caused me very major headaches (i.e. on one 2GHZ computer it runs unuseably slow
for no apparent reason, whereas it runs perfectly fine on a very similarly set
up 400MHZ computer). In the past I have been considering trying to write an
editor in python using pygtk (GTK2). I'm currently thinking that it may not be
the best place to spend resources compared to working on the main server and
client, however it would make an improvement in my opinion. I personally think
that the best ways to go about making a new editor would be with useing
python/pygtk and packing existing C loading code and such into a C extension for
python, or making one in C/GTK2.


 I haven't played much with python/pygtk.

 But with c/gtk2, one could use glade to pretty quickly do all the layout 
design.

 However, I still think it would be better to put work into improving the java 
editor vs writing a new one.


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

Re: [crossfire] Item stacking

[Mark Wedel]

Brendan Lally wrote:


updating the maps isn't too hard, in fact the following is a diff that
does just that. (I haven't included much context here, partially for
brevity, partially because anyone playing with these maps in the
editor will probably break this diff anyway.)

I'm tempted to reduce the accuracy of some more of these, express them
in furlongs, or maybe even miles (or leagues), since I doubt anyone
seriously goes around counting the squares, the screens maybe.


 IMO, the numbers could be less accurate (more round numbers), but please leave 
the numbers roughly as is


 Basically, right now, as said, 1 space = 1 mile.  Thus, those signs describe 
how many spaces the towns are from you.  IMO, this is a good thing, especially 
for now players (how far do I hav to walk to get to navar?)


 Changing to obscure units IMO doesn't add anything - it either results in 
players having to go to google to figure out how many furlongs in a mile, conver 
that, and then know how far the town is apart.


 I think for ease of use, the numbers as shown on the signs should represent 
number of spaces.  If we want to call them some other unit, I don't mind, but I 
don't want them changed to some value and then have new players lost because 
they traveled 75 spaces in the right direction and didn't find anything.  Things 
are already obscure enough - no reason to make them harder for new players.



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

Re: [crossfire] Map cache

[Mark Wedel]

 Catching up on various points:

 I have no plans, no do I expect to see any work on making crossfire multi 
server distributed.  The work to do that would be huge.  At minimum, the game 
almost needs to be thread safe, so why not just do that?  With multi thread/core 
processors hitting the market soon, it makes more sense (sun's 32 thread cpu 
will be out sometime soon for example).


For item stacking, since the issue here is related to performance, it would be 
raw number of items that don't merge.  This may be hokey, but the goal here is 
to improve efficiency by reducing number of objects on the space, so we don't 
care actual nrof, weight, volume, whatever.  We just care if the number of 
objects is above X, objects should spill over.  This also helps out on the 
client interface aspect.


 Putting objects into misc containers adds a bunch of complication and not sure 
it really helps out.  If another axe is dropped, then presumably you have to 
check all the objects in the 'axe container' to see if it merges with anything, 
so loose any efficiency by having fewer objects.  Also, having that pseudo 
container would seem to result in other oddities, like special handling when 
player tries to pick it up, etc.


 In terms of trying to do actual threading:
You can of course set up locks.  I believe the loader is inherently unthreadable 
(do to lex), so you'd need a global lock to prevent that happening.


Each player structure would need a lock, so things like chat, talks, shouts, 
etc, could be handled safely.


Otherwise, my thought is to basically move away from global objects and instead 
put the object link list in the map structure.  Thus, loading and saving doesn't 
need to touch any global structures, and even for processing, each map could be 
its own thread.  But as previously said, a lot of the functions are not thread 
safe, so would either need locks or need to be made thread safe.


 As far as what started this discussion - actual map load times:
I haven't profiled it, but a few guesses:
1) Loading is lex, but still lots of strcmps and the like.  So that isn't as 
fast as say a binary system, but not easy to fix that.


2) objects with huge number of spaces isn't efficient - that is because for each 
object loaded on the same space, it has to compare with all the other objects on 
the space to see if any merge.  Thus, it becomes an O(n^2) operation.  Fixing 
that is a bit more difficult, but if the number of objects allowed on a space is 
limited to some value, that helps out (note same thing happesn for chests or 
players inventory however - those are harder to fix).



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

Re: [crossfire] Inconsistencies between map loading and map saving code

[Mark Wedel]

Andreas Kirschbaum wrote:

There are some inconsistencies in how crossfire/crossedit and
CFJavaEditor handle the map headers "reset_timeout" and
"enter_x"/"enter_y":

 - CFJavaEditor uses the default value "0" for missing headers. It saves
   the headers only if the current value is positive.

 - crossfire/crossedit use the default value "7200" (for reset_timeout)
   or "1" (for enter_x and enter_y). But it saves these values only if
   the current value is not "0".

This behavior makes crossedit add these headers by just loading and
saving a map.

I'd like to remove these inconsistencies by always using "0" as the
default value for missing headers, and saving the headers only if the
current value is positive.

To not change the semantics for maps without a reset_timeout header
field, I'd change set_map_reset_time() in common/map.c to treat the
value "0" as the "default timeout value" (7200). (Note that
set_map_reset_time() is the only function accessing this field.)

For the fields enter_x/enter_y I just hope that most (all?) maps will
still work: either the exit leading into this map contains coordinates,
or the server will (hopefully) place the player to 1/1 if row and column
0 are blocked.


 If the change is only made for future maps, I think that is fine.

 That is to say that if a map has enter_x as 1, and loaded in the editor and 
saved, the editor shouldn't now strip that out.


 It basically should just not modify maps that don't have that field set.

 I'd say same thing for timeout value.


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

Re: [crossfire] Map cache

[Mark Wedel]

Brendan Lally wrote:

On 8/27/05, Mark Wedel <[EMAIL PROTECTED]> wrote:




You are probably correct, it is certainly easier to let Moore's law do
the work instead. It is likely that if there ever were a compelling
reason to split load across servers it would be to reduce bandwidth
usage from each server.


 But that then requires a fair amount of client logic (move from server A to 
server B for all communication).


 Something like that could almost be easier - you could for example have pup 
land all operate on one server, and so on.  When a player moves/leaves pupland, 
data is tranfered to the other server (player file) as well as telling the 
client to talk to the other server.


 In this mode, the amount of work is less - each server pretty much operates 
independently - what is needed then is code for things like chats/shouts/tells 
to get passed across servers.


 but still not convinced if that is necessary.

 Leaf/Basic - is it possible to set up some form of cpu usage monitoring on 
metalforge?  I know solaris has 'sar'.  I'd mostly be interested in seeing on a 
whole what percentage of the cpu is actually being utilized.


 Because I think, with current number of players, on the whole, cpu is probably 
still mostly idle.  Exceptions abound - I'd imagine map loads/save generate a 
small spike, and various 'hundreds of spells' also spikes the cpu, but those are 
exceptions and not general case.


 Only if the cpu was actually operating at a high percentage of use would 
distribution of servers actually make sense (and/or server generating enough 
traffic to saturate its link, but then a different server only makes sense if 
that server is on a different link - hosting 2 servers at the same ISP wouldn't 
help out)




 Putting objects into misc containers adds a bunch of complication and not sure
it really helps out.  If another axe is dropped, then presumably you have to
check all the objects in the 'axe container' to see if it merges with anything,
so loose any efficiency by having fewer objects.  Also, having that pseudo
container would seem to result in other oddities, like special handling when
player tries to pick it up, etc.



Well, there was a reason that I did specify that these would have to
be no_pick, so that there is no concern with picking it up. (you don't
pick up a pile of things, merely the individual items in it.)


 Ok - but I'd say that makes the user interface a little clunkier - containers 
now magically show up that the player has to open/close to get the items in/out of.




The merging would have to be done anyway, but it may be easier to do
it on opening the container, especially if items are often dropped
there but rarely retrieved.


 But presumably any item dropped should merge with the object in the container 
(that was the point of that container in the first place).  In that case, logic 
is still basically the same - have to examine all objects on the space to see if 
any of hte right type exist, as well as any containers.  If we get any of these 
special containers, then have to examine objects in that.


 This also creates a complication that at some point, the code has to decide 
'there are 15 different axe like objects here - lets create a container for them'.


 I think it'd actually make more sense to make this an in game feature.  EG, 
you can buy weapon cabinets at the store, and perhaps have different types 
(sword cabinet, axe, etc) so item would go in right cabinet.


 One thing that would probably need to be coded is being able to drop the 
weapon on a space with all those cabinets and have it go in the correct one 
(this works for inventory since you can have active containers in your 
inventory), but not on the ground right now.  Maybe using the walk_on flag could 
be used for this - if set on a container, do appropriate checks and insert 
object in container if appropriate.






It might be possible to 'compile' maps, to take the map files, and run
a seperate program on them which would 'load' the maps like the server
does currently, and output the raw values of the object structs with
the relative place of pointers so that the server on loading the maps
can merely dump the items into an appropriatly size array of structs
and offset the pointers properly.


 The problem is that a recompilation of the server (or even new objects) 
results in those pointer locations being different.  So that doesn't work well.


 My thought for a binary form would be something like:
<2 bytes> - describes variable/field (eg, hp, sp, etc) - this is basically 
handled by a table/nice long switch statement.
<1 byte> - describes type of value (1=8 bit 2, 2=16 bit int, 3=32 bit, 4=float, 
5=string, etc)
length is prepended so loading string is very efficient)


 Some fields could also be collapsed.  For example, the FLAGS could just be 
saved as the 32 bi

Re: [crossfire] Map cache

[Mark Wedel]

Preston Crow wrote:

On Thu, 2005-08-25 at 18:57, Anton Oussik wrote:


When the server comes across maps containing large amounts of items it
takes a long time to load. While it is loading the whole server
freezes for other players, and on very large maps (like the scorn sale
shop or some apartments) this can take in excess of 10 seconds on
metalforge.



The way I would solve this is to have the map loader count how many
objects it has loaded.  After some fixed number, it would stop until the
next time tick.  There would be no processing of objects, including
players, on a partially-loaded map.

This would eliminate the lag for everyone except the player entering the
cluttered map.

I'm just not sure if this is less work than the other approaches to
solving the problem that have been suggested.


 the problem is that the loader itself stores state information.

 So, while unlikely, you could get this case:

 Player A enters some exit.  Map starts to load, gets to point, and returns 
expecting to continue next tick.


 Player B enters map, laoder kicks in, this map finishes.

 Next tick, when it tries to resume loading map A, the lex state is messed up, 
so the load fails or you get weird results.


 Now this can obivously be fixed (is any map in proces of being loaded but not 
finished, etc).


 Many years ago, I tried this approach, but never to it stable enough.

 I'd still be more tempted to just go the threading approach - to cover the 
above case, its probably not too far from getting a threaded system anyways.


 Its how well you want a threaded server to scale that becomes an issue.  One 
coud just set some very broad thread locks - easier to do, but means it wouldn't 
scale as well.  But at a first pass, and given current loading, that may be good 
enough.





--PC


___
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] loader mangles item names

[Mark Wedel]

Andreas Kirschbaum wrote:

While searching for the source of bug #1059537 (Chainmail mutations) I
discovered that the loader strips out leading material names.






Since this patch is now more than two year old, most item names should
have been fixed by now. Therefore: any objections if I remove this code
fragment again?


 No object from me.



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

Re: [crossfire] undecipherable code

[Mark Wedel]

[EMAIL PROTECTED] wrote:

Quoting tchize <[EMAIL PROTECTED]>:



Second, why do other unique objets present on this map
square influence the behaviour of op. 


I believe this behaviour is related to unique floors saving items on them.
Unique floors do have unique set, so other items on them should care about it.


 that is correct.





And if this is legitimate,
why do they only influence object put on top of them?


If my hypothesis above is correct, then I believe this is the intentional
behaviour related to the fact that unique floors only save items ontop of them.


 That is correct, but that snippet isn't looking at just the floors - it is 
looking at all the objects on the space.


 To me, that seems incorrect - as tchize says, it means if I drop say a unique 
key, and then drop other items on the same space on a non unique maps, all items 
on that space are treated as unique.


 If the processing stopped once beyond the floors, I'd imagined it would be 
much faster (would only need to iterate a couple times before it gets there).


 the FLAG_OBJ_ORIGINAL has something to do with the overlay maps.  Garbled 
added those in.


 Arguably, with addition of overlay maps, shouldn't be much need for the unique 
maps or vice versa, as they tend to duplicate function (the per player unique 
maps are a different matter, since that just saves the entire map - I'm talking 
about the unique maps that contain just the unique items).


 I'd be more tempted for the unique object maps to go away - at least the 
overlay maps are stored with map header information so could be loaded up in the 
editor.


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

[crossfire] server map code redo.

[Mark Wedel]

 This is a heads up that I plan to start work on a pretty significant map code 
redo.  Below are the main areas I plan to tackle.  I may do these in smaller 
pieces, but the are somewhat related in that I'll be changing the map structure 
itself to some extent to make this all happen.


 I'll send out more detailed proposals on these points, but this is a brief 
outline:


1) Refine move/block types.  Right now, we have 2 move types (walking & flying). 
 There is only 1 block type, that blocks both flying and moving.  Extend code 
to allow for more move types, as well as refined blocking (blocks walking, not 
flying, etc).


2) Change/improve lighting code.  Max light radius of 4 made sense when the map 
max size was 11x11, doesn't make a lot of sense when it is now 25x25.  Look at 
other line of sight improvements


3) Add more layers to display logic, also have it handle head information better 
so that the client/socket side doesn't have to do this.


4) Store more object attributes in the mapcell so we don't have to look through 
the list objects to see if any have that set.  Also store number of objects 
(likely pickable and flying as different values) so can implement spill over 
logic, make sure number of spell objects is at some reasonable level and bail 
out if it gets too high.


 Future/down the road:

5) To convey some of these changes to the client, a new protocol command is 
needed.  But no reason to write that until we have data to actually send to it.


6) As per other discussion about threading - moving the maps objects to a per 
map list makes threading much easier.  However, above changes are really related 
to mapcell and related functions, so redoing pointers doesn't really fit in here 
(doing it as part of the above just makes that more complicated).




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

[crossfire] Server map redo: movement types

[Mark Wedel]

 This mail describes my current proposal on changing the movement types.  Some 
areas are open for discussion.


Basic change: Allow more extensible movement types, as well as blocking of 
specific movement types.


All fields below use a bitmask to represent value, similar to how the attacktype 
works.  These would be defined like:


MOVE_WALK   0x1
MOVE_FLY0x2
MOVE_SWIM   0x4
etc

move_type: This is a bitmask that represents all the movement types the object 
is capable of.  There is a clear analogous value right now - default is 
basically move_walk, and if creature is flying, that would be same as MOVE_FLY. 
 However, this is a bitmask that represents available movement types of object, 
so serveral values could be set.


move_block:  Represents what movement types are unable to pass this space. 
Similar to no_pass (which will likely remain for backward compatible reasons and 
not allow anyting to pass).


 The code to handle this would basically be:

if ((space->move_block & op->move_type) == op->move_type) space is blocked

 Thus, a space has to block all movement types player is capable of (otherwise, 
it can be assumed object is smart enough to do what is needed to move to new 
space).  Eg, if you can fly, you fly over the obstacle if that is all that is 
blocking.


 Note however for the player to fly over, they need to have equipped an object 
tht lets them fly (unless it is a native ability), as at least as players go, 
may not be as useful.


 Question: Do we want to print messages and/or add support of messages that 
give some clue as to possiblity to move but player lacks ability.  Eg, player 
trys to walk into water and gets message 'you lack the abilility to swim' or 
something, and a player tht does have swimming but tries to swim into deep water 
maybe gets a message like 'you can't swim in the deep water - it is too rough' 
or something?


move_on/move_off:  Analogous to the walk/fly_on/off flags.  Basically, if you 
have movement type and move onto a space, walk on function is called, if move 
off, walk off function is called.


 I'm mixed what to do for multiple move types.  If a player has both fly and 
walk movement types, what should happen when he walks on a trap door?  Nothing 
at all?  Or activated?  What about when he walks on a teleporter/shop map - same 
question?


 I'm thinking the logic should be like the block code above - players generally 
avoid the hazards.  In the case of shop mats/teleporters, players could manually 
apply them.  Perhaps keep the enforcement of 'can't be flying to pick stuff up', 
so players could always put those nifty items on top of traps to try and lure 
the players.


move_slow: Like move_block, bitmask that represents slower movement of that 
type.  Walking though jungle should be pretty slow, and flying over it shouldn't 
slow one down much.  right now, the actual penalty is same for all movement 
types, so not sure if there is a need desire to be able to specify different 
move penalties (10% if flying, 60% of walking, etc).


 Loading/saving details:
On saves, I'd expect all these values get saved as the name above and bitmask 
mentioned.


However, for loading, I'm thinking of allowing more general naming, so instead 
of having to do:

move_on 7

You could do
walk_on 1
fly_on 1
swim_on 1

 And the loader takes care of setting up the bitmask.  I mostly see this as a 
convenience for archetype writers - using fill names is much easier than having 
to look up bitmask, convert, etc (ok, with just a few values, not hard, but 
still).  I'm not concerned about saves, as the editor should be able to nicify 
this is necessary.


 This also has the advantage of keeping that backwards compatilibity.  Some new 
ones would be added like walk_move, fly_move, fly_slow, etc (basic idea is to 
keep the names consistent so parsing is easier).




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

[crossfire] LOS and lighting map redo

[Mark Wedel]

 The basic premise behind this idea is to add more lighting levels given the 
larger visible map, and make some other LOS improvements.


First, I'm undecided exactly how many light levels there can be (and thus, 
directly related, max glow radius).  Larger values impose more server processing 
- even if they aren't used, if there is the possiblity of a glow_radius 16, it 
does mean you have to look out 16 spaces in all directions to see if anything is 
in fact glowing.


 One improvment I do plan to make is to have the map code (update position and 
like) deal with figuring light/darkness level - after all, other than player 
moving, there isn't a reason for it be handled in LOS code.  thus, as an 
example, if a player without a light source is moving about scorn, we don't need 
to do any light/darkness calculations - we have the values, know they are good.


 My first inclination is to have up to glow_radius 16 value.  Thus, a player 
holding one of these super bright objects could basically illuminate the area 
around them.


 As far as client/server protocol, I expect the revised protocol will just send 
the light sources and light client handle shading.  The server itself still 
needs to calculate light levels for line of sight reasons.


 I also plan to look into having walls block the light from progessing.

Other changes:

map header values:

ambiant_darklevel (or maybe lightlevel, depending if the desired default is that 
maps be illuminated or dark) - this is the default light level for all the 
spaces on the map - thus, you can make a dimly lit tavern just be setting this 
and nothing else.  This actually makes more sense for the world maps - after 
all, at dusk, I can still see a long ways, everything is just a bit more dim.


darklevel:  This current value in the map header needs to be revamped. 
Basically, right now, it determines how far you can see, but sort of does it in 
odd ways - in a sense, it reduces how much stuff illuminates to some extent.


 What I'm thinking is adding a map header which basically is 'unless space is 
illuminated at least this brightly, you can't see it'.  So in a sense, it 
determines how quickly the light drops off to darkness, but within the light 
area itself, it would still be illuminated.


 To me, this makes more sense - if we have 16 light levels, something at level 
1, after graphic effects, might still be so dark as to be virtually black.  So 
it may make sense to have something like 'unless at least light level 5, not 
visible' - this then plays with ambiant darklevel.


 For creatures/players can can in fact see in dark, that reduces this.  In the 
above example, now maybe those people can see down to light level 3.


 Other thoughts;  Is there a strong desire to be able to have colored lighting 
(Red, green, whatever)?


 Other LOS ideas:
For objects with elevation, make line of sight be elevation sensitive.  Eg, if 
I'm on the highest mountain, other mountains should block sight that much.  Same 
thing if I'm flying above the jungle - should get a good view.


 The question here is then do we want another flag to denote elevation based 
blocking, or do we assume that if something does have elevation, its LOS shoudl 
be based on elevation?


 Also, I'm not going to try to cover the cases of intervening elevation changes 
and things being obscured.  Eg, can't see into valley one ridge over because of 
ridge between you and valley - trying to handle that type of logic gets much 
more complicated and time consuming (you basically have to handle that by actual 
math - my elevation is X, target elevation is Y, at point a,b view line would be 
at elevation z, but that object elevation is ...).


 Partial LOS blockage:  Certain things, like jungle, currently block LOS.  My 
idea here is to mimic this by having partial blockage.  For example, jungle may 
block 25%.  So if you are in the midst of the jungle, space space right next to 
you is at full brightness, one next to it is at 75% brightness, etc.  This then 
plays with light levels also - in the middle of the night, that jungle would 
really be dark.


 Light propogation would similarly be blocked comings towards you holding a 
lantern in the middle of a jungle won't let someone else see you from very far away.




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

Re: [crossfire] LOS and lighting map redo

[Mark Wedel]

Brendan Lally wrote:

On 8/30/05, Mark Wedel <[EMAIL PROTECTED]> wrote:


 Other thoughts;  Is there a strong desire to be able to have colored lighting
(Red, green, whatever)?



Yes, and directional ones too (that propagate in a cone in a given
facing). This would be a nice easy way to make the colours of items
vary then. (instead of making a blue version of a wall, have a white
one, add a directional negative glow radius 'white' light, and a
positive glow radius directional 'blue' light, and have the client's
graphics card deal with the colouring. This would allow much more
variation in colours of objects, without adding arches. (and colour
spray done by abusing that could look pretty).


 Colors aren't as hard.  Especially if we make the rule that if a space has 
multiple light sources, the brightest one takes precedence for things like color.


 That said, it then depends on how many colors and how much bandwidth we want 
to use for lights.  If for example we say max brigthness if 15 (4 bits), that 
gives 4 bits for colors (15) and still be able to fit lighting informatin into 1 
byte.


 Directional light sources are more difficult.  I was originally thinking it 
wouldn't be hard - and for the server side of things, it actually wouldn't be 
that hard.


 The problem is communicating this to the client - we now need to tuck the 
direction someplace in the protocol.  And using a few bits, that could be done. 
 But then you get the case of suppose you have a space with multiple 
directional lightsources of varying brightnesses.


 From the server perspective, what I see calculating for each space is 1) The 
brigthness 2) the color and 3) directional information.


 Point #3 is hard to do if you have the situation I describe - multiple 
directional light sources of different color.


 So I'm thinking the directional light sources is something.  We could generate 
a bitmask of the directions, but that isn't going to give satisfactory results. 
 So you'd now need something like ability to actually have multiple light 
sources on the same space with different attributes and send that to the client.


 IMO, that is getting things more complicated (client now has to be able to 
handle all that also).


 IF the real goal is to be able to say 'make this space green', I'd almost 
think the way to go is just add a color hint object or something.  After all, 
problem with light sources would be dimming, uneven color, etc, even with 
directional light.


 However, either method still has the problem that this is an attribute of the 
space.  So not only would the wall be green, but the floor underneath it, etc, 
which probably aren't the results we want.


 I'd also be tempted to say that if the only goal is to make different color 
objects, pretty simple manipulation through image editing programs can do this 
with probably equal quality as the graphic card.  After all, the graphic card is 
just using some algorithym to do it, and I'm sure that exists in numerous functions.


 So in summary, I think adding support for different color light sources, but 
still only have circular light sources is the way to go.





___
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] Server map redo: movement types

[Mark Wedel]

Anton Oussik wrote:



On 8/30/05, *Brendan Lally* <[EMAIL PROTECTED] 
> wrote:


Additionally MOVE_HORSE, being much faster than walking, but less

and MOVE_WAGON, which would be able to carry vast amounts of items, 



And your face should change to a mounted figure or horse driven 
carriage. Maybe also include MOVE_SHIP when you get a ship, which can 
travel very fast, but can only dock in ports. Then you have to navigate 
between ports, or perhaps have director-driven shipping routes, so you 
get on he route and your ship sails itself using directors to your 
destination.


 Note that you are heading down a different conversation or something that the 
proposed code will enable, but is not something that will be done in the 
proposal at hand.


 The basic design is to change how it is done, and that is what I'm looking for 
comments on right now - less so everything it will enable.



Speaking of image transformations, when something moves from a square A 
to a square B it currently stays in A all the way until it jumps to B. 
Could the new protocol provide a way for the transition to take n 
seconds (or ticks or frames), so arrows would really fly, and monsters 
would walk at you instead of jumping, the land would scroll by as player 
walks on it, and spells would propogate more smoothly? I don't know if 
this is even vaguely possible given that currently CF is completely 
tile-based.


 It isn't really possible.

 The main reason is that the server only sends map updates to the client at 
about 1 every 8 seconds, and that is how often the client draws it.


 So even if the server did track this incremental movement and send it to the 
client, that alone won't be enough.  Things that move fast will still hop a 
square (or maybe half a square depending how fast) at a time, etc.


 Also, any such calculations coudl only be done as a best guess where that 
object is going.  Objects always move a full space when they move - what changes 
is how often they move.  Changing that logic is very complicated and is likely 
to cause a much higher load on the server.


 But what that means is that the monster may be moving towards you, but maybe 
changes direction.  So you'd get odd cases like the monster is half a space 
towards you, but then jumps a full space in some other direction or something.


 So the short answer is this really can't be done without a major rewrite. 
With some hints, the client could perhaps guess at this (for all objects taht 
are moving, client could be informed what direction they were last moving and 
how fast) and do its own calculations, but the result is sure to be flawed for 
reasons above.




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

Re: [crossfire] Server map redo: movement types

[Mark Wedel]

Nicolas Weeger wrote:

All fields below use a bitmask to represent value, similar


to how the attacktype 


works.  These would be defined like:

MOVE_WALK   0x1
MOVE_FLY0x2
MOVE_SWIM   0x4
etc



Sounds like a great proposal.
I'd tweak it slightly, having MOVE_FLY_LOW and MOVE_FLY_HIGH:
first is your regular levitation, flying over jungle and water
maybe, second is flying over high mountains.
Let's not forget also MOVE_CROUCH :)


 How do we differentiate those, or maybe the question is what has 
'move_fly_high'?

 Do we map everything that has flying right now to move_fly_low?  spells and 
whatnot?





I'd say yes, we should warn player, directly or not (ie "you
hate water, don't want to drown" => hint hint: learn to swim!).
It could be nice to also either have the player automatically
fly over an obstacle (for instance), or get a message
(something like "the wall is too high to walk on" => hint
hint: try flying! :p). This way players won't need to always
fly or have to try all solutions to get over walls.


 My thought on how to handle this is look at the msg field of the object - if a 
player is unable to move onto the space, look for the object preventing him and 
print the message.  Thus, they can all be customized in objects, not the code.






 I'm mixed what to do for multiple move types.  If a player


has both fly and 


walk movement types, what should happen when he walks on a


trap door?  Nothing 


at all?  Or activated?  What about when he walks on a


teleporter/shop map - same 


question?



I'd say handle as it is now. Player is assumed to walk, unless
using levitation spell/skill/item.
This then means dragons should be able to levitate (skill) and
cast spells, of course (not sure it's possible).


 But current method doesn't work well in the new mode.

 I consider it completely reasonable that a player may have multiple move types 
set.  It may be he has to use a skill or object to get the flying, but if we use 
the same logic we do for objects, these abilities would OR with his basic 
(archetypal) movement type, this giving him several.


 And for things like swimming, this may be needed for it to work at all 
sensibly - if you have both MOVE_WALK | MOVE_SWIM, things just work fine - you 
move into the water and start swimming, and move out of hte water and start walking.


 To mimic existing code, there'd basically need to be special logic - if 
move_type & MOVE_FLY, move_type = MOVE_FLY, eg, strip out any other move types 
the object has.






It could be interesting to do, but maybe too complex.
But it could be fun, imagine a big jungle and a small path you
can follow to go faster - alas, monsters lurk around!


 The slow penalties is an object attribute, so you can set up the paths.

 What I was talking about was different penalties based on move type.  If we 
take that jungle example, it has move_slow MOVE_WALK.  It may be reasonable to 
say that you can't fly as fast also, so should have move_slow MOVE_FLY | 
MOVE_WALK - the problem is that either mode of transport would get the same 
movement penalty.


 Actually, perhaps one way to handle this is multiple objects - the movement 
penalty itself probably doesn't have to be stored in the object (or could be 
stored in an array).  So you could have something like:


object move_fly_penalty
move_slow MOVE_FLYING
move_penalty ..
end

 and put that along with the jungle.



I'm thinking of tweaking the collect.pl script to accept names
instead of values for flags. So instead of having "attacktype
5940423" you'd have "attacktype fire cold poison". The
collect.pl changes that to correct numerical value.
This way the loader doesn't have to handle those gory details,
no performance hit :)


 Doing that for attacktype certainly makes sense.

 I'm not concerned about performance hit vs doing it in collect - after all, 
archetypes are only loaded once, so if a little slower, not a big deal.


 However, keeping that parsing code out of the loader would be nice.

 But for the move types, since the naming can would be consistent, minimal 
complications - it'd be done something like the body_ values.



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

Re: [crossfire] Server map redo: movement types

[Mark Wedel]

Todd Mitchell wrote:
I think that we should treat flying differently than walk,swim, etc.  
Flying should have to be initiated by the player.  You can fly almost 
anywhere you could swim of walk so flying shouldn't be automatic.  If 
you move from ground to water you or back you would switch from walk to 
swim but you could fly (or jump) you over either.  If you are flying you 
can't pick up stuff, won't trigger buttons, etc. 


 Unless a race has native flying, the player would have to do something to 
start flying (wear those boots, ready the skill, cast a spell).


 The question was really want to do once that has happened.  Eg, player has 
applied the boots of levitation and now walks to a shop map, etc.



I also think that even players with fly ability shouldn't be able to fly 
all the time but only for a period of time (based on CON or STR and race 
or spell?).  Jumping would basically be flying for one turn.


 Certainly depends on how they are flying.

 Something like levitation boots obviously give you permanent flying.

 A spell does have a duration.

 Now for skills, trickier issue.  One could argue there could be something like 
a fatigue stat, and if you're too fatigued, have to stop using certain skills 
(like flying or other strenous stuff).  Actually, this idea has merit, so I'll 
start a different thread on fatigue.



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

[crossfire] fatigue

[Mark Wedel]

 As per started in another thread, adding a fatigue stat has some interesting 
ideas.


 Basic idea fatigue is a stat, that you ideally want low.

 You get fatigue by doing strenous things (swimming, flying via skill, 
attacking, moving a lot).


 You lose fatigue by resting - this can basically be measured by the character 
having an action and not actually doing anything.  Certain magic potions could 
also reduce fatigue.


 I'd suggest that movement speed should be redone under such a system - 
movement speeds would vary less, but that amount of fatigue you gain by moving 
is dictated by how much stuff you are carrying.


 If not carrying much, you wouldn't get much fatigue - thus, a lightly equipped 
person could run around all day and not have to rest much.


 If you're near you wait limit, you'd get fatigue pretty often.

 Running isn't covered special here - it would fall under movement, but that 
fact you move whenever you can when running basically means you'd never be 
resting at all, thus only gaining, never losing.


 For certain skills, if your fatigue was too high, you could no longer use that 
skill (have to stop flying, may drown if swimming, etc).  Your max fatigue 
should perhaps be based on constitution and maybe level (don't get fatigued as 
much at higher levels).


 for the normal case of just attacking/running around, one idea is when fatigue 
gets too high, your speed starts to go down, but at the same time, you start 
losing fatigue (in a sense, game is enforcing idea that you have to slow down). 
 One way to handle this might be that if fatigue is so how, player doesn't get 
as much speed as they should, but loses some fatigue,


 anyways, just random thoughts.



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

[crossfire] map redo: more layers.

[Mark Wedel]

 The basic premise is to add more visible layers on the map, so more than 3 
objects can be displayed on a space.


 One other fix is to also more hard assign what layers objects show up in.  One 
problem with current protocol is that objects can move layers, and this is one 
thing that would be nice to fix.


 My basic idea would be to just assign what goes on the different layers, from 
bottom up:


0: map floor - since you can't see anything beneath the floor, this is the 
bottom.

1: building/buttons/whatever on top of floor, that player then stands on top of.
2: Same as 1 - I don't think there are actually cases were there are 2 objects, 
but I rather like to keep this open for expansion.


3-5: objects player may actually pick up/interract with

6: Player/monster
7: second monster - should really only show up if one of these is a multi space 
monster overlapping something else.


8-10: Flying objects - typically spells.

 The trickier part in all this is how to condense it down for the 3 objects for 
old protocol.  May idea would be to basically set up a table which says order of 
objects you are looking at.  The order would always be the same, but it may be 
something like:


0-6-8 (floor/creature/spell) - 1-9-2-3-5-10-7

 Basically, we look at those layers, and once we find 3 objects, we stop 
looking any further.


 This logic could also be useful for the new protocol - for bandwidth reasons, 
you may want to limit the number of layers to some level, say 5.  So it'd use 
this same mechanism to find the first 5 items on the space to send.





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

Re: [crossfire] server map code redo.

[Mark Wedel]

tchize wrote:


5) To convey some of these changes to the client, a new protocol command is
needed.  But no reason to write that until we have data to actually send to
it.




I'll opt for a complete rework of whole client/server protocol in a branch. 
This way we can easily tweak new protocol for performance and not take 
care of old protocol compatibility. Backward compatibility could come 
afterwards when new protocol is mature enough.


 The problem, as mentioned in layering thread, is that some of these changes 
basically necessitate some mechanism for backward compatiblity.


 Basically, right now, the server stores 3 layers of information in the 
mapcells.  I don't want to have to have those as well as all the new layers - 
I'd want those old layers to go away - this means some mechanism to pull the 
right data to display.


 As far as new protocol, I'd actually argue that there is less reason to branch 
that than making a change to an existing protocol.  After all, we could pretty 
easily put something in at the top of socket/request.c which will basically have 
it refuse to serve the new protocol (by refusing setup command) unless 
uncommented - if someone is savy enough to mess with that, they can live with 
the consequences.


 I do note that I wrote up a 'map2' protocol proposal a while back and it does 
sit in the doc/Developer/protocol file as the proposal.  I think tha should 
cover everything, but in that one, I only did 8 image layers (including 
smoothing), which wouldn't cover the proposal I just sent out.



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

Re: [crossfire] LOS and lighting map redo

[Mark Wedel]

Amorya North wrote:


On 31 Aug 2005, at 07:37, Mark Wedel wrote:

 Colors aren't as hard.  Especially if we make the rule that if a 
space has multiple light sources, the brightest one takes precedence 
for things like color.




Why don't we have the client composite it all? I'm hoping my client will 
look as graphically nice as possible... so we could have it calculate 
the effective colour so that if there was a red, green and blue light of 
the same brightness, you get white...


 Mostly because it now means that the server has to record all the different 
light sources, colors, etc on the specific space and communicate that 
information to the client.


 That makes things a bit more complicated than just having to record the 
brigthness and brightest color of the space and communicate it.


 In addition, I'd expect there to be pretty few cases where there will actually 
be multiple light sources on the same space, so this extra complication that 
would have to be coded doesn't buy very much.



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