Re: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

2005-09-29 Thread Mitch Obrian
Note: I've though about asking for just such a backup
cvs dir/branch before, perhapse it would be a good
idea? 

--- Mitch Obrian <[EMAIL PROTECTED]> wrote:

> For all other maps sans mlab I follow the map guide.
> However mlab was started way before these, thus it
> uses the flatdirectory structure so it stays
> working.
> I've seen maps break many times before, including my
> tavern when it was uploaded to cvs originally.
> 
> Why must there be contoversy just over a file
> system? 
> 
> If I can't upload my maps to CVS where do I back
> them
> up to? Are they that worthless? I do a fair amount
> of
> CF work in arches and non-mlab maps, could I have
> alittle slack? Why is there opposistion just because
> I
> put the maps in their own flatlevel dir?
> 
> The reasoning that mlab doesn't even deserve to be
> in
> CVS is very alienating, I've worked years on theses
> maps. I work nearly constantly on maps for CF.
> 
> Mlab could be intergrated into CF-proper right now
> if
> I was just given the OK. If an exception to the dir
> rule was made.
> 
> I though after being involved in CF this long the
> controversy was over and I could develop as a
> regular
> without asking about every change. I uploaded mlab
> so
> it would be with CF, so if my computers go down my
> years of work are not lost. Sure one can say "go
> find
> some other place to back up to" but... that's
> basically telling the person to screw off; their
> work
> is of little value.
> 
> The tar is uploaded so it itself is not lost, it is
> only 5 megs.
> 
> --- Alex Schultz <[EMAIL PROTECTED]> wrote:
> 
> > Mark Wedel wrote:
> > 
> > > The mlab maps obviously do not fall into that
> case
> > - they are clearly 
> > > being actively developed, and the person doing
> so
> > has CVS.
> > >
> > >  One problem that arises from this is that there
> > really isn't any way 
> > > for anyone to integrate the mlab maps - your
> > trying to integrate a 
> > > moving target.
> > >
> > >  The other is that this really just seems to be
> a
> > way to avoid the 
> > > mapguide - I know Mike doesn't want to follow
> our
> > map directory layout 
> > > or some other areas of the mapguide.
> > >
> > > [snip]
> > >
> > >  But then I'm still stuck figuring out what is
> > going to happen with 
> > > all this mlab stuff - either the correct rules
> > should be followed and 
> > > this integrated in properly with the maps, or it
> > probably shouldn't be 
> > > there.
> > 
> > In terms of integrating a moving target, I don't
> see
> > how it would be any 
> > better if they weren't in CVS. Really, the target
> is
> > still moving if one 
> > was trying to work from Mike's periodic mlab
> release
> > tarballs, so though 
> > it being in CVS doesn't solve the moving target
> > problem, it does allow 
> > the movement of the target to be tracked better
> > which IMHO is somewhat 
> > helpful to the moving target situation, even if
> only
> > slightly.
> > In terms of mapguide issues, I agree, though if
> Mike
> > is too unwilling to 
> > change, it may be possible to fix many of the
> > mapguide issues by script 
> > (i.e. the directory layout could be autogenerated
> > from the map name 
> > prefixes that Mike is using), however chances are
> > this would break from 
> > time to time, so I don't see this as too appealing
> > an option unless Mike 
> > is willing to adopt such fixes for the development
> > of mlab. I know one 
> > of Mike's worries with changing his current layout
> > is that scripts could 
> > possibly end up creating small errors and
> breakage.
> > Question to Mike: What exactly in the mapguide are
> > you opposed to? And 
> > why exactly?
> > 
> > Alex Schultz
> > 
> > ___
> > crossfire mailing list
> > crossfire@metalforge.org
> >
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> > 
> 
> 
> 
>   
> __ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Re: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

2005-09-29 Thread Mitch Obrian
For all other maps sans mlab I follow the map guide.
However mlab was started way before these, thus it
uses the flatdirectory structure so it stays working.
I've seen maps break many times before, including my
tavern when it was uploaded to cvs originally.

Why must there be contoversy just over a file system? 

If I can't upload my maps to CVS where do I back them
up to? Are they that worthless? I do a fair amount of
CF work in arches and non-mlab maps, could I have
alittle slack? Why is there opposistion just because I
put the maps in their own flatlevel dir?

The reasoning that mlab doesn't even deserve to be in
CVS is very alienating, I've worked years on theses
maps. I work nearly constantly on maps for CF.

Mlab could be intergrated into CF-proper right now if
I was just given the OK. If an exception to the dir
rule was made.

I though after being involved in CF this long the
controversy was over and I could develop as a regular
without asking about every change. I uploaded mlab so
it would be with CF, so if my computers go down my
years of work are not lost. Sure one can say "go find
some other place to back up to" but... that's
basically telling the person to screw off; their work
is of little value.

The tar is uploaded so it itself is not lost, it is
only 5 megs.

--- Alex Schultz <[EMAIL PROTECTED]> wrote:

> Mark Wedel wrote:
> 
> > The mlab maps obviously do not fall into that case
> - they are clearly 
> > being actively developed, and the person doing so
> has CVS.
> >
> >  One problem that arises from this is that there
> really isn't any way 
> > for anyone to integrate the mlab maps - your
> trying to integrate a 
> > moving target.
> >
> >  The other is that this really just seems to be a
> way to avoid the 
> > mapguide - I know Mike doesn't want to follow our
> map directory layout 
> > or some other areas of the mapguide.
> >
> > [snip]
> >
> >  But then I'm still stuck figuring out what is
> going to happen with 
> > all this mlab stuff - either the correct rules
> should be followed and 
> > this integrated in properly with the maps, or it
> probably shouldn't be 
> > there.
> 
> In terms of integrating a moving target, I don't see
> how it would be any 
> better if they weren't in CVS. Really, the target is
> still moving if one 
> was trying to work from Mike's periodic mlab release
> tarballs, so though 
> it being in CVS doesn't solve the moving target
> problem, it does allow 
> the movement of the target to be tracked better
> which IMHO is somewhat 
> helpful to the moving target situation, even if only
> slightly.
> In terms of mapguide issues, I agree, though if Mike
> is too unwilling to 
> change, it may be possible to fix many of the
> mapguide issues by script 
> (i.e. the directory layout could be autogenerated
> from the map name 
> prefixes that Mike is using), however chances are
> this would break from 
> time to time, so I don't see this as too appealing
> an option unless Mike 
> is willing to adopt such fixes for the development
> of mlab. I know one 
> of Mike's worries with changing his current layout
> is that scripts could 
> possibly end up creating small errors and breakage.
> Question to Mike: What exactly in the mapguide are
> you opposed to? And 
> why exactly?
> 
> Alex Schultz
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Re: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

2005-09-29 Thread Alex Schultz

Mark Wedel wrote:

The mlab maps obviously do not fall into that case - they are clearly 
being actively developed, and the person doing so has CVS.


 One problem that arises from this is that there really isn't any way 
for anyone to integrate the mlab maps - your trying to integrate a 
moving target.


 The other is that this really just seems to be a way to avoid the 
mapguide - I know Mike doesn't want to follow our map directory layout 
or some other areas of the mapguide.


[snip]

 But then I'm still stuck figuring out what is going to happen with 
all this mlab stuff - either the correct rules should be followed and 
this integrated in properly with the maps, or it probably shouldn't be 
there.


In terms of integrating a moving target, I don't see how it would be any 
better if they weren't in CVS. Really, the target is still moving if one 
was trying to work from Mike's periodic mlab release tarballs, so though 
it being in CVS doesn't solve the moving target problem, it does allow 
the movement of the target to be tracked better which IMHO is somewhat 
helpful to the moving target situation, even if only slightly.
In terms of mapguide issues, I agree, though if Mike is too unwilling to 
change, it may be possible to fix many of the mapguide issues by script 
(i.e. the directory layout could be autogenerated from the map name 
prefixes that Mike is using), however chances are this would break from 
time to time, so I don't see this as too appealing an option unless Mike 
is willing to adopt such fixes for the development of mlab. I know one 
of Mike's worries with changing his current layout is that scripts could 
possibly end up creating small errors and breakage.
Question to Mike: What exactly in the mapguide are you opposed to? And 
why exactly?


Alex Schultz

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


[crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

2005-09-29 Thread Mark Wedel

Mitch Obrian wrote:

I uploaded the tar to cvs at
/maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz
in my tiredness last night. Can someone remove the
tarball
/maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

I uploaded it to the correct path today.


 My personal opinion is that mlab-devel.tar.gz should not be in CVS.

 The untarred files are already there - the tar is just redundant data.  I 
can't think of any compelling reason why it is needed - presumably anyone tha 
wants to use it is smart enough to do be able to do a 'mv' from the the current 
directory.


 It is after all sucking up an extra 5.5 megabytes of space.  Mind you, that 
isn't a lot, but in terms of bandwdith to download it (doing a cvs update -dP on 
entire map directory, which is often common procedure) it is non trivial.


 And since it is binary, you have to get the entire thing.  IMO, CVS is not 
well designed to hold binary files, and certainly doesn't deal well with really 
big ones.  So unless there is a compelling reason it needs to be there (and if 
there is, please provide it), it should be removed.


 Now as far as the untarred mlab stuff, I'm more mixed on that.

 In the past, the stuff in the unlinked directory was basically maps that came 
from whatever sources and needed to be integrated, but did not have anyone 
actively developing them.  So it was basically a holding area until someone 
found the time.


 The mlab maps obviously do not fall into that case - they are clearly being 
actively developed, and the person doing so has CVS.


 One problem that arises from this is that there really isn't any way for 
anyone to integrate the mlab maps - your trying to integrate a moving target.


 The other is that this really just seems to be a way to avoid the mapguide - I 
know Mike doesn't want to follow our map directory layout or some other areas of 
the mapguide.


 But it seems to me that either either the rules should be followed and these 
maps checked in the right places, or they shouldn't be checked in at all.


 I don't like the idea of stuff being thrown into CVS for someone else to take 
care of.  I could see this leading to similar things for the client or server 
code - someone throwing code into a 'patches' or 'test' directory or something 
that doesn't meet coding guidelines - either the stuff should be mature enough 
to be checked into CVS, or it shouldn't be.


 The other possiblities is to make a new CVS repository for this - instead of 
unlinked being a directory in the maps tree, make a maps-unlinked CVS repository 
for all this stuff.


 But then I'm still stuck figuring out what is going to happen with all this 
mlab stuff - either the correct rules should be followed and this integrated in 
properly with the maps, or it probably shouldn't be there.











__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Crossfire-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/crossfire-devel



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


Re: [crossfire] Improved collect.pl script

2005-09-29 Thread Mark Wedel

Nicolas Weeger wrote:

If I were to do it I would have implemented this behavior in


the server 


instead of in the collecting of archetypes (that way it


could be used in 


maps as well), but this is fine too.



I voluntarily choose to do that at collect time, because doing
it at item or map load time may be bad for loading performance.
Also it's much easier to do it with Perl than C :)


 Doing it at the loader would also have the advantage that you could tweak maps 
or player save files more easily.  And it should only effect load performance 
when it has to deal with those.


 The other gotcha might be people looking at archetypes and seeing things like 
'attacktype fire godpower' and thinking they can use that for their maps or 
other non archetype things.  But that probably isn't a very big issue either.


 That said, this is certainly better than was there before, and I don't really 
think the loader needs to be able to support this format - keeping that simpler 
is probably better.




The Java editor can use "raw" archetypes from the arch
directory. Thus it needs too to support "attacktype fire".
As I don't know Crossedit, I don't know whether it always uses
collected archetypes or if it too can use uncollected ones.


 crossedit only supports the already collected archetypes, it can't read the 
individual archetype files.


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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Alex Schultz

ERACC wrote:


On Thursday 29 September 2005 08:21 am
Benjamin Lerman wrote:

[...]
 


The second one allow to use argument with the cast command so that you
can use:

cast create food waybread
or
cast summon pet monster spider
   


[...]

Isn't this what 'invoke is meant to do? If 'cast will do it now then
why have 'invoke? Seems to me we should either leave 'cast as is or
make that change and remove 'invoke. There is no reason to have both.
I vote to leave 'cast as is because I have an oodle of key bindings
using 'invoke. :-)
 

Well, there are many times I prefer invoke for things were I don't want 
to add a argument. Such as quickly using word of recall without risk of 
using  it more than once by accident.


Alex Schultz

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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Joshua Wilson

Exactly.

Such that if you wanted to create a few rounds of something particular 
you have to invoke create food yyy a few times, instead of cast create 
food yyy and fire a few times.


Andrew Fuchs wrote:

On 9/29/05, ERACC <[EMAIL PROTECTED]> wrote:
...


Isn't this what 'invoke is meant to do? If 'cast will do it now then
why have 'invoke? Seems to me we should either leave 'cast as is or
make that change and remove 'invoke. There is no reason to have both.
I vote to leave 'cast as is because I have an oodle of key bindings
using 'invoke. :-)



Cast readys the spell for use, while invoke imediatly uses the spell.
Bolth have their place, but cast doesn't accept arguments like invoke does.

--
Andrew Fuchs

___
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] Summon pet monster

2005-09-29 Thread ERACC
On Thursday 29 September 2005 02:15 pm
Andrew Fuchs wrote:

> On 9/29/05, ERACC <[EMAIL PROTECTED]> wrote:
> ...
> > Isn't this what 'invoke is meant to do? If 'cast will do it now then
> > why have 'invoke? Seems to me we should either leave 'cast as is or
> > make that change and remove 'invoke. There is no reason to have both.
> > I vote to leave 'cast as is because I have an oodle of key bindings
> > using 'invoke. :-)
> 
> Cast readys the spell for use, while invoke imediatly uses the spell.
> Bolth have their place, but cast doesn't accept arguments like invoke does.

Ah, I get it now. Ready the spell *with* an argument so that when one
does cast it the argument is used. Ok. Yeah, that would be good.

Gene Alexander
-- 
Linux era4.eracc.UUCP 2.6.8.1-12mdk i686
 15:15:03 up 134 days, 15:56,  8 users,  load average: 0.19, 0.17, 0.13
ERA Computer Consulting - http://www.eracc.com/
eCS, Linux, FreeBSD, OpenServer & UnixWare resellers

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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Andrew Fuchs
On 9/29/05, ERACC <[EMAIL PROTECTED]> wrote:
...
> Isn't this what 'invoke is meant to do? If 'cast will do it now then
> why have 'invoke? Seems to me we should either leave 'cast as is or
> make that change and remove 'invoke. There is no reason to have both.
> I vote to leave 'cast as is because I have an oodle of key bindings
> using 'invoke. :-)

Cast readys the spell for use, while invoke imediatly uses the spell.
Bolth have their place, but cast doesn't accept arguments like invoke does.

--
Andrew Fuchs

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


Re: [crossfire] Summon pet monster

2005-09-29 Thread ERACC
On Thursday 29 September 2005 08:21 am
Benjamin Lerman wrote:

[...]
>  The second one allow to use argument with the cast command so that you
> can use:
> 
> cast create food waybread
> or
> cast summon pet monster spider
[...]

Isn't this what 'invoke is meant to do? If 'cast will do it now then
why have 'invoke? Seems to me we should either leave 'cast as is or
make that change and remove 'invoke. There is no reason to have both.
I vote to leave 'cast as is because I have an oodle of key bindings
using 'invoke. :-)

Gene Alexander
-- 
Linux era4.eracc.UUCP 2.6.8.1-12mdk i686
 13:57:12 up 134 days, 14:38,  8 users,  load average: 0.13, 0.19, 0.14
ERA Computer Consulting - http://www.eracc.com/
eCS, Linux, FreeBSD, OpenServer & UnixWare resellers

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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Mitch Obrian
I like the being able to specify summoned monster idea
:)

--- Benjamin Lerman <[EMAIL PROTECTED]> wrote:

> > Isn't there already a field in player structure
> for spell
> > argument? used when spells have delays, iirc.
> 
>  I did (and still don't) see it.
> 
>  If I grep for char in player.h, I obtain:
> 
> logrus ~/download/crossfire/include $ grep char
> player.h
> ... snip what is not on the pl struct
> charmaplevel[MAX_BUF];  /* On which
> level is the player? */
> charsavebed_map[MAX_BUF];  /* map where
> player will respawn after death */
> charspellparam[MAX_BUF];/* What
> param to add to spells */
> const char  *invis_race;/* What race invisible
> to? */
> charown_title[MAX_NAME];/* Title the
> player has chosen for themself */
> chartitle[BIG_NAME];/* Default
> title, like fighter, wizard, etc */
> charkiller[BIG_NAME];   /* Who killed
> this player. */
> charlast_tell[MAX_NAME];   /* last
> player that told you something [mids 01/14/2002] */
> charwrite_buf[MAX_BUF]; /* Holds
> arbitrary input from client */
> charinput_buf[MAX_BUF]; /* Holds command
> to run */
> charpassword[16];   /* 2 (seed) + 11
> (crypted) + 1 (EOS) + 2 (safety) = 16 */
> charsearch_str[MAX_BUF];/* Item we are
> looking for */
> 
>  If you remove spellparam which is the field I
> added, I do not see which
> other field you are referring to.
> 
>   Benjamin Lerman
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Re:[crossfire] Summon pet monster

2005-09-29 Thread Mitch Obrian
Resistances are bad, I agree. That would basically
make all maps in the game worthlessly easy. Same with
upping ring power. One has to, as of now, search for
good rings which, I think, is the correct way. If
anything CF needs to be made harder.

--- Nicolas Weeger <[EMAIL PROTECTED]> wrote:

> Hello.
> 
> >  The first one allow you to summon pet that are of
> lower
> level that the
> > current pet you can summon. It is mainly a one
> line patch
> that use the
> > same argument that create food or create weapon
> use.
> 
> Saw it on SF, sounds ok.
> 
> >  The second one allow to use argument with the
> cast command
> so that you
> > can use:
> 
> Isn't there already a field in player structure for
> spell
> argument? used when spells have delays, iirc.
> 
> >  Now, I plan to create Enchant Ring and Enchant
> Amulet
> scrolls that
> > would work like Enchant Weapon, but because it
> demands a
> little more work
> > than for the 2 previous patch, I'd like to know if
> those
> scrolls would
> > be Ok. I'd like to also implement think like
> Improve
> resistance to `foo'
> > for Weapons, but once again, would that be Ok?
> 
> I'd say you must take care of the overall game
> balance.
> Rings and amulets may already be quite powerful,
> probably
> don't want to give too much new & powerful stuff.
> As for resistances, i'd say rather no. Unless well
> though, it
> could lead to have really high resistances almost
> everywhere,
> thus making everything too easy.
> 
> >  And at least, I have a question, does there
> exists a way to
> force the
> > client to wear a particular holy symbol whenever
> possible.
> Right now,
> > whenever I change skill, even if I do not need any
> object to
> get my new
> > skill, my holy symbol is unapplied, which is quite
> a problem
> when the
> > holy symbol does a lot more than give the skill
> praying...
> 
> Afaik no. And yes it's quite a pain.
> Maybe something to change, ie whenever you cast a
> spell or
> something a talisman is autoapplied.
> 
> Nicolas
> 
> Accédez au courrier électronique de La Poste :
> www.laposte.net ; 
> 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50
> (0,34€/mn)
> 
> 
> 
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Benjamin Lerman
> Isn't there already a field in player structure for spell
> argument? used when spells have delays, iirc.

 I did (and still don't) see it.

 If I grep for char in player.h, I obtain:

logrus ~/download/crossfire/include $ grep char player.h
... snip what is not on the pl struct
charmaplevel[MAX_BUF];  /* On which level is the player? */
charsavebed_map[MAX_BUF];  /* map where player will respawn after 
death */
charspellparam[MAX_BUF];/* What param to add to spells */
const char  *invis_race;/* What race invisible to? */
charown_title[MAX_NAME];/* Title the player has chosen for 
themself */
chartitle[BIG_NAME];/* Default title, like fighter, wizard, etc 
*/
charkiller[BIG_NAME];   /* Who killed this player. */
charlast_tell[MAX_NAME];   /* last player that told you something 
[mids 01/14/2002] */
charwrite_buf[MAX_BUF]; /* Holds arbitrary input from client */
charinput_buf[MAX_BUF]; /* Holds command to run */
charpassword[16];   /* 2 (seed) + 11 (crypted) + 1 (EOS) + 2 
(safety) = 16 */
charsearch_str[MAX_BUF];/* Item we are looking for */

 If you remove spellparam which is the field I added, I do not see which
other field you are referring to.

Benjamin Lerman

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


Re:[crossfire] Summon pet monster

2005-09-29 Thread Nicolas Weeger
Hello.

>  The first one allow you to summon pet that are of lower
level that the
> current pet you can summon. It is mainly a one line patch
that use the
> same argument that create food or create weapon use.

Saw it on SF, sounds ok.

>  The second one allow to use argument with the cast command
so that you
> can use:

Isn't there already a field in player structure for spell
argument? used when spells have delays, iirc.

>  Now, I plan to create Enchant Ring and Enchant Amulet
scrolls that
> would work like Enchant Weapon, but because it demands a
little more work
> than for the 2 previous patch, I'd like to know if those
scrolls would
> be Ok. I'd like to also implement think like Improve
resistance to `foo'
> for Weapons, but once again, would that be Ok?

I'd say you must take care of the overall game balance.
Rings and amulets may already be quite powerful, probably
don't want to give too much new & powerful stuff.
As for resistances, i'd say rather no. Unless well though, it
could lead to have really high resistances almost everywhere,
thus making everything too easy.

>  And at least, I have a question, does there exists a way to
force the
> client to wear a particular holy symbol whenever possible.
Right now,
> whenever I change skill, even if I do not need any object to
get my new
> skill, my holy symbol is unapplied, which is quite a problem
when the
> holy symbol does a lot more than give the skill praying...

Afaik no. And yes it's quite a pain.
Maybe something to change, ie whenever you cast a spell or
something a talisman is autoapplied.

Nicolas

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)




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


Re: [crossfire] Summon pet monster

2005-09-29 Thread Brendan Lally
On 9/29/05, Benjamin Lerman <[EMAIL PROTECTED]> wrote:
>  Now, I plan to create Enchant Ring and Enchant Amulet scrolls that
> would work like Enchant Weapon, but because it demands a little more work
> than for the 2 previous patch, I'd like to know if those scrolls would
> be Ok. I'd like to also implement think like Improve resistance to `foo'
> for Weapons, but once again, would that be Ok?

The one comment I would make here is to be sure to deal with the item
power properly. What exactly 'properly' is in this context is not
neccessarily clear, too little an effect and these scrolls would make
rings overpowered, too much, and they would be useless. I would
suggest however that if the results of enchanting rings to the extent
that their stats are about the same as one with similar item power
from the item generator, then you are probably ok.

Something that does interest me though, is how you intend to fit this
in with the jeweler skill.

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


[crossfire] Summon pet monster

2005-09-29 Thread Benjamin Lerman
 Hi all,

 I write two patches that I put on the sf page.

 The first one allow you to summon pet that are of lower level that the
current pet you can summon. It is mainly a one line patch that use the
same argument that create food or create weapon use.

 The second one allow to use argument with the cast command so that you
can use:

cast create food waybread
or
cast summon pet monster spider

 What do you think about those patches?

 Now, I plan to create Enchant Ring and Enchant Amulet scrolls that
would work like Enchant Weapon, but because it demands a little more work
than for the 2 previous patch, I'd like to know if those scrolls would
be Ok. I'd like to also implement think like Improve resistance to `foo'
for Weapons, but once again, would that be Ok?

 And at least, I have a question, does there exists a way to force the
client to wear a particular holy symbol whenever possible. Right now,
whenever I change skill, even if I do not need any object to get my new
skill, my holy symbol is unapplied, which is quite a problem when the
holy symbol does a lot more than give the skill praying...

-- 
Benjamin

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


Re: [crossfire] moving gps code (map)

2005-09-29 Thread Mitch Obrian
It can be found in the maze/palace and requires 4
players to complete the quest. There is other treasure
there too, the gps is the prize though, If anyone
would like to incorperate it into their servers mlab
is under unlinked/mlab-devel and just needs to be
moved to the root of the maps dir and the
unlinked/mlab-devel/MISC/world/world_* need to be
copied to the world dir. 

--- Nicolas Weeger <[EMAIL PROTECTED]> wrote:

> Hello.
> 
> A while ago i added a "ground positionning system",
> item that lets you
> know your location in the world.
> AFAIK you can only find it on mlab maps, it's not
> yet on other maps.
> 
> Unless someone objects with good arguments, i'll
> move the relevant code
> to a Python script. Since it's not a mandatory
> behaviour (it's more a
> convenience), a script is the perfect way for it,
> and that means i can
> trash the specially introduced item type.
> 
> Note that there shouldn't be any conversion issue
> between old & new
> implementation as long as archetypes and maps are
> updated at the same time.
> 
> Ryo
> 
> ___
> crossfire mailing list
> crossfire@metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


[crossfire] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

2005-09-29 Thread Mitch Obrian
I uploaded the tar to cvs at
/maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz
in my tiredness last night. Can someone remove the
tarball
/maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

I uploaded it to the correct path today.





__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Re: [crossfire] Improved collect.pl script

2005-09-29 Thread Nicolas Weeger
> If I were to do it I would have implemented this behavior in
the server
> instead of in the collecting of archetypes (that way it
could be used in
> maps as well), but this is fine too.

I voluntarily choose to do that at collect time, because doing
it at item or map load time may be bad for loading performance.
Also it's much easier to do it with Perl than C :)

> I'm not sure what you mean. CrossEdit reads the archetypes
exactly as
> the server does. It won't know the difference because it
will read the
> archetypes after they've been collected and therefore after
the collect
> script has converted the attacktype values.

The Java editor can use "raw" archetypes from the arch
directory. Thus it needs too to support "attacktype fire".
As I don't know Crossedit, I don't know whether it always uses
collected archetypes or if it too can use uncollected ones.

Nicolas

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)




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