Nicolas Weeger (Laposte | 2 Dec 19:04 2006
Picon

Re: Curse bug

Reading fix_object (former fix_player), it seems to be there's a big mess 
waiting to happen (or already happened?) :)

Basically, fix_object resets many many things, including all special flags 
(see in dark, stealth, ...), resistances, ...
This means all those custom values will simply disappear whenever a monster 
will drink a potion, be hit by a curse or a disease, things like that :)
Of course fix_object works fine when called with a player, but will horribly 
alter things for a customized monster.

I can see a few possible fixes:
* fix fix_object so it handles things correctly
* don't call fix_object except when absolutely required. Recode eg curse to 
simply decrease wc, and restore it later when the force expires. Of course 
it's a mess with other things modifying wc
* we could store all modified values so fix_object knows what to search for. 
An overkill solution is to temporarily create an artifact for each customized 
monster, and free it when monster diseappears.

At first glance, I'd say we should create a temporarily artifact. It's the 
only way to be totally and definitely sure we never have any issue and keep 
all intended values - after all, at some point monsters will drink potions, 
or wear armor, or whatever.

What do you think?

Nicolas
Nicolas Weeger (Laposte | 2 Dec 20:11 2006
Picon

Re: Player file corruption

> Fixing code should be easy, but fixing players will probably require a
> script to strip the last_grace/last_sp/last_eat fields from players's
> spells. Another messy option is to reset at loading fields, but i'm not
> that eager to do that, as it's a ponctual fix...

Ok, fixed the code by adding a structure storing spell state sent to server. 
Since this is an internal information, not stored, it'd be easy to change 
should the need arise.

Now we should fix player files, so probably a script. Anyone feeling like 
doing that? :) Affected values that should be removed are last_grace, last_sp 
and last_eat
Basically we should:
* check maps for special spells with special values for those
* strip information from player files, unless it's that special spell :)

Note that spells which normally have such a field set will simply reset to 
normal value through the archetype being all right.

Nicolas
Mark Wedel | 3 Dec 07:11 2006
Picon

Re: Curse bug

Nicolas Weeger (Laposte) wrote:
> Reading fix_object (former fix_player), it seems to be there's a big mess 
> waiting to happen (or already happened?) :)
> 
> Basically, fix_object resets many many things, including all special flags 
> (see in dark, stealth, ...), resistances, ...
> This means all those custom values will simply disappear whenever a monster 
> will drink a potion, be hit by a curse or a disease, things like that :)
> Of course fix_object works fine when called with a player, but will horribly 
> alter things for a customized monster.
> 
> I can see a few possible fixes:
> * fix fix_object so it handles things correctly

  It's unclear how one can simply fix fix_object(), because as you describe, 
there are lots of values modified, so you basically need to know what those are 
(fix_object has to start with some baseline of what the initial values are 
supposed to be).

> * don't call fix_object except when absolutely required. Recode eg curse to 
> simply decrease wc, and restore it later when the force expires. Of course 
> it's a mess with other things modifying wc

  Yes - especially if the monster has already been modified so some attributes 
are near maximums.

  Eg, if a creature has fire_resistance 100, anything that adds fire resistance 
won't have any effect.  But if a player cast a fire resistance spell on the 
monster, when that spells ends, the monster still needs to have fire resistance 
100 (you can't take away the resistance the spell would give).
(Continue reading)

Nicolas Weeger (Laposte | 3 Dec 11:17 2006
Picon

Re: Documentation / wiki

As a test bed, I've put doc/Developers/objects on the wiki, you can see it at 
http://wiki.metalforge.net/doku.php/dev:objects (not yet totally formatted, 
and dokuwiki is running out of memory caching it sometimes :))

Does that look good?

Nicolas
Nicolas Weeger (Laposte | 3 Dec 12:50 2006
Picon

Show invisible behaviour

Hello.

With relation to bug

https://sourceforge.net/tracker/index.php?func=detail&aid=1556723&group_id=13833&atid=113833 
about broken show invisible, i've changed the behaviour for that spell:

chance to show a hidden item is now (casting level-1) on (item's level).

This just means monsters over 110 will never be shown :)

If anyone has another idea, feel free to explain it ;)

Nicolas
Nicolas Weeger (Laposte | 3 Dec 13:09 2006
Picon

Re: Curse bug

>   It's unclear how one can simply fix fix_object(), because as you
> describe, there are lots of values modified, so you basically need to know
> what those are (fix_object has to start with some baseline of what the
> initial values are supposed to be).

Agreed, not that easy to avoid, specially for resistances and such.

>   Eg, if a creature has fire_resistance 100, anything that adds fire
> resistance won't have any effect.  But if a player cast a fire resistance
> spell on the monster, when that spells ends, the monster still needs to
> have fire resistance 100 (you can't take away the resistance the spell
> would give).

Note that we may think later of "lower resistance"-type spells, which will 
need to tweak values, too.

>   Do you mean artifact or archetype?  I'd think archetype would be easier -
> you could update op->arch with the new archetype (but really, you just
> chare about op->arch.clone).  You could even store away the original
> archetype is op->arch.clone->arch

I did mean archetype, indeed :)

>   I think temporary archetype is really the best way to go.

Me too. We'll have to take special care for loading/saving handling, though.

Of course, players are easy because they are always starting from their 
archetype (and also we probably never load/save one) :)

(Continue reading)

Mark Wedel | 4 Dec 09:20 2006
Picon

Re: Documentation / wiki

Nicolas Weeger (Laposte) wrote:
> As a test bed, I've put doc/Developers/objects on the wiki, you can see it at 
> http://wiki.metalforge.net/doku.php/dev:objects (not yet totally formatted, 
> and dokuwiki is running out of memory caching it sometimes :))
> 
> Does that look good?

  Looks good - a few notes:
 > 3. Create a bitmap. It must be dividable by 32 in both height and width. The
 > file format should be .PNG 256 colour and use transparancy.

IMO, that is no longer really accurate - pixmaps can be odd sizes (32x40).  Some 
clients may have issues drawing it (I think I fixed it recently for the gtk and 
gtk2 client).  Now there may not be a lot of reason to use odd sizes, but it 
should be supported.

 > 5. split the bitmaps up into 32×32 bitmaps and named according to the
 > naming.doc conventions in the arch tar package. Note, this is not really
 > necessary at current time - non splitted images should work properly, but some
 > older clients may have problems with it. (you can use the script “splitxbm”
 > which is included below).

  That should be removed - if anything, we are going in the opposite direction 
of merging these cut up images into one big image.  All clients should support 
it now days.  Likewise, with that, some of the points in point 6 could be removed.

  can_pass_thru further down should be removed - IIRC, when I redid the movement 
code, that disappeared (it wasn't used by anything anyways)
Aaron Baugher | 5 Dec 00:51 2006
Picon

Re: Documentation / wiki

I'm a relative newbie to Crossfire, playing as 'Mhoram' on metalforge these days.  I played it several years ago, but my Internet connection was poor, so I was stuck playing alone on my own server, and was never part of the Crossfire "community."  Since my C is too rusty to help much with the code, and I'm not artistic enough to make maps, I'd like to help add documentation to the wiki, and I'd be interested in opinions from more experienced folks here on what it could use.

Any suggestions on what documentation most needs to be written, updated, or improved?  I'll start a wish-list of things to work on.

In the meantime, I thought I'd start on the list of spells, since that's not on the wiki yet.  I'd like to do it differently than the web site.  Instead of all the spells broken up alphabetically, A-D and so on, I thought I'd split them up according to skill -- a page of summoning spells, a page of pyromancy, and so on.  Then there would be an alphabetical index page of all spells with links into those pages.  I'm finding that when I play a spellcaster, I'm usually not interested in every discipline (and may be banned from some by my god) so this way I wouldn't have to scroll past spells I can't use to find the ones I can.  It would also let me easily see what my next available spells are as I increase level in a particular skill.  What do you think?  I suppose I can go ahead and do up a sample, and trash it if that doesn't work.

Also, I was wondering about the organization of the wiki.  (I hope this is the right place to discuss it.)  I've noticed that most of the pages are 'top-level'.  For example, Lore is a top-level page, but then the pages under it, like Book of Valriel are also top-level, instead of having a link like lore:book_of_valriel.  Does this matter?  For the sake of organization, should I have links like magic:spells:pyromancy?  I want to make sure my links fit into any future organizational plans for the wiki.

Thanks,
Aaron

Any questions? Get answers on any topic at Yahoo! Answers. Try it now.
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
Rick Tanner | 5 Dec 19:45 2006

Re: Documentation / wiki


Aaron Baugher wrote:
> 
> Any suggestions on what documentation most needs to be written, updated,
> or improved?  I'll start a wish-list of things to work on.
>
> In the meantime, I thought I'd start on the list of spells, since that's
> not on the wiki yet.  I'd like to do it differently than the web site. 
> Instead of all the spells broken up alphabetically, A-D and so on, I
> thought I'd split them up according to skill -- a page of summoning
> spells, a page of pyromancy, and so on.  

Please continue to work on the spell list.  =-)

Thank you for all that you have contributed to!

Nicolas Weeger (Laposte | 9 Dec 19:10 2006
Picon

Re: Documentation / wiki

> IMO, that is no longer really accurate - pixmaps can be odd sizes (32x40). 
> Some clients may have issues drawing it (I think I fixed it recently for
> the gtk and gtk2 client).  Now there may not be a lot of reason to use odd
> sizes, but it should be supported.
>
>   That should be removed - if anything, we are going in the opposite
> direction of merging these cut up images into one big image.  All clients
> should support it now days.  Likewise, with that, some of the points in
> point 6 could be removed.
>
>   can_pass_thru further down should be removed - IIRC, when I redid the
> movement code, that disappeared (it wasn't used by anything anyways)

Well, do you see that nice "edit page" button? :)

More seriously the page could sure use some updating & proof-reading.

The thing i'd really like to do is actually document what the code does (not 
how it does) for each item type, what options, and such. This would make 
checking for bugs much easier.

Nicolas

Gmane