Re: [crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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)
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
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
> 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