Alex Schultz wrote:
>
>> - Should we switch to SVN? Switching repositories at same time as switching
>>what the head branch means would make the most sense.
>>
> I agree that when switching what the head branch means makes the most
> sense, however I'm not sure that to SVN would be a great
Per the recent discussion on code reorganization and what goes in what
release, this document is an attempt to gather the points raised and make it
into a formal document that can be included in the code or put on the wiki.
This document does not attempt to justify or explain why different things
I agree that adding new static variables may not be the best thing.
And actually, for the NPC code, making it so it doesn't need them may not be
so hard (since I think it recursives pretty locally). OTOH, it may not be so
easy - I briefly looked at the apply code before formulating my repl
Nicolas Weeger (Laposte) wrote:
>> Looking at that, and looking at your example, it seems hardly really
>> clear to follow.
>
> After some thinking, having a Python script handle the dialog seems the best
> way, actually :)
>
> This way, the whole dialog is written into the Python script, incl
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> Related to bug:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1534889&group_id=13833&atid=113833
>
> I can see 2 solutions:
> * prevent NPCs to react to other NPCs' chat
I can't think of anyplace where that would break something, bu t
Alex Schultz wrote:
> Nicolas Weeger (Laposte) wrote:
>>> OTOH, you don't want a case where player is about to complete quest and
>>> get reward, and then have everyone join them to get that bonus exp (one
>>> question if the reward is exp, does it get divided by number of people in
>>> party? Doe
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> I'm resurrecting that topic :)
> (long mail warning)
>
> After much thinking, I've changed my mind. IMO a quest management system
> could
> very well be written in Python, with a few improvements to the plugin system.
>
> What I'd add:
>
> First, e
Yann CHachkoff wrote:
>> My main concern was however the language use of NPC's. I don't remember
>> which NPC's this concerns, but some use expressions that are forbidden
>> on Metalforge.
>>
> I disagree. If the NPC represents somebody that uses rude language, so be
> it. As long as the usage does
Andrew Fuchs wrote:
> On 7/29/06, Nicolas Weeger (Laposte) <[EMAIL PROTECTED]> wrote:
>> Hello.
>>
>> Here are some patches i'd like opinions on:
>>
>> -
>> https://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833
>> New coins.
Alex Schultz wrote:
> Andrew Fuchs wrote:
>> - no/minimal anti women's rights material allowed in the game (see mikeeusa)
>> - the "14 year old wife" in mlab was questionably offensive,
>> inappropriate for the game
> One note on that, not just anti-woman's-rights content, but things
> likely to
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=1428566&group_id=13833&atid=313833
> new face for booze.
>
> Looks ok to me, though maybe we want items to be seen from left/horizontally,
> instead of top-down like monsters?
Like most thing
Alex Schultz wrote:
>> The question is what goes into the stable branch. By its nature,
>> everything
>> has to go into the head branch (presuming the change is still applicable).
>> But
>> the scope of changes for the minor releases in the stable branch probably
>> shouldn't be too big.
>
Alex Schultz wrote:
> Andrew Fuchs wrote:
>> Finally, i just want to note that our next release could be 1.10.0
>> instead of 2.0 if we need more time for cf2.0.
> And that is something I strongly believe should be the case. I
> personally do not believe that we are ready for 2.0 for a while (I'm
>
Yann Chachkoff wrote:
> Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit :
> Now, you could say that "there is no way to be sure that the server works
> before trying it"; I'd answer to this that (1) we developers are supposed to
> do at least some rough b
Andrew Fuchs wrote:
> On the community side, we need to encourage player interaction, both
> in and out of the game. One way to boost in game interaction would be
> bolstering the player economy. However, that will probably not be
> done in time for cf2.0. For the community out of game, make it
Alex Schultz wrote:
>
>> But that can then lead to rapid turnover of major releases. Eg, I do major
>> code restructure, make 3.0.0 release. Then some other change is made (maybe
>> compatibility breakage, maybe some other code restructure) - do you make a
>> 4.0.0
>> release 3 months later
Alex Schultz wrote:
> Mark Wedel wrote:
>> One thought is to define major.minor.micro releases like this:
>>
>> major release: Changes that break compatiblity (need to start with a clean
>> server as player files are not compatible, server/client compatibility may
Yann Chachkoff wrote:
>> if there is a separate branch for 2.0 (or 3.0 thinking after that), it
>> probably won't get used much, and before you can really release it to the
>> general public, you have to make sure it is in fact used.
>>
> Sounds a somewhat flawed way of thinking. If you
Alex Schultz wrote:
> Mark Wedel wrote:
>> 1) What is the target date for a 2.0 release? It can't be 'when all the
>> cool
>> stuff is done', as then it never happens - always something new to add, etc
>> -
>> some general date has to targeted.
Yann Chachkoff wrote:
> Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit :
>> To me, the issue for targetting this for a 2.0 release is timing.
>>
>> We can come up with a huge list of things that should be done before a
>> 2.0 list. And we could attempt t
To me, the issue for targetting this for a 2.0 release is timing.
We can come up with a huge list of things that should be done before a 2.0
list. And we could attempt to do them all, but then 2.0 probably won't be
released for 5 years or the like.
The discussion for a 2.0 release proba
Alex Schultz wrote:
> Robin Redeker wrote:
>> On Tue, Jul 11, 2006 at 11:15:18AM -0500, Rick Tanner wrote:
>>> Per the feedback from other people on IRC and other means, I've put
>>> together a list of requirements that people want to see with the
>>> metaserver reporting.
>>>
>>> So, with this pos
Tchize wrote:
> Andrew Fuchs wrote:
>> Would be easier to manage (on both sides) by having a "permanent" flag
>> sent to the metaserver, that has to be explicitly set in the server
>> config.
> Just a though:
> metaserver entries of 'permanent' server should, at least partially, be
> stored in a c
Alex Schultz wrote:
> Currently in the crossfire code, how objects behave is intertwined all
> throughout the code, and this is in many ways a problem as it makes it
> difficult to find code related to a type of object. It's current state
> also makes it relatively difficult to add code for new obj
Wim Villerius wrote:
> On Sat, 2006-07-01 at 10:57 -0700, Mark Wedel wrote:
>> Typically, monsters have lots of HP but are slow relative to players.
>> Things
>> probably need to be brought more in line - make most monsters faster than
>> they
>> are now, m
anyone know of a particular reason that earthwalls have no_pick 1 set?
Earthwalls are 'alive 1', so can't be picked up in any case.
Where this comes up is related to stacking and the new code - the new
stacking
code tries to put objects of specific types on specific layers (so monsters
Mark Wedel wrote:
> Alex Schultz wrote:
>> Tchize wrote:
>>> Maybe a ./configure --release=
>>> :)
>> I really like that idea, except for one issue. People compiling from
>> source releases typically wouldn't do that, so I think that what would
>>
Alex Schultz wrote:
> Tchize wrote:
>> Maybe a ./configure --release=
>> :)
> I really like that idea, except for one issue. People compiling from
> source releases typically wouldn't do that, so I think that what would
> be better than including that in the ./configure, would be having a
> simple
One thing which may make sense is different default levels based on if it is
a
precompiled binary vs something checked out from CVS.
I still stand by that the precompiled binaries should be less verbose on
problems - we're putting this out there as this is quality software, so it
should a
General quick thoughts:
I removed them as I believe (rightly or wrongly) that software presented for
general end user consumption should not be producing debug or information
messages - it should only print error messages. I'd almost be tempted to say
that the default log level should eve
Nicolas Weeger (Laposte) wrote:
>
> What about limiting skills in which you can get over level 20 (or 30, or
> whatever)?
> So if you're fighter you can get one/two handed weapon and punching to 50,
> smithery to 40, use magic item to 30, but can't have sorcery/pyromancy over
> 20?
> Of course
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> You are still mixing at protocol level the player login and the
> player creation, this is wrong. If a player want to create a
> character, he clicks on a new character button. He doesn't have to
> enter user/password before. At
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I do not agree on this change, those informations are not so verbose
> and have no reason to make users afraid of as they are not visible by
> default. Normal users don't start game in console and those starting
> in console want
Wim Villerius wrote:
> Well, this certainly makes sense for magic skills. Restricting a warrior
> to lvl 25 magic skills doesn't hurt much - he wont use them often.
> On the other hand, restricting a mage to use at most lvl 25 one/two
> handed is a BIG pain and an unfair restriction.
> I have no
Wim Villerius wrote:
> On Thu, 2006-06-29 at 22:48 -0700, Mark Wedel wrote:
>> It has long been discussed that with a few exception (the non humanoid
>> races
>> and the classes that prohibit weapons/armors), a lot of race/classes tend to
>> blur together.
>>
Alex Schultz wrote:
>> It might not be solvable without a lot of work, but I really think
>> adding a zero to the max stat would make a huge difference. That would
>> as well allow a change of the effects stats have. Now the difference
>> between 29 and 30 is incredibly big. It seems to be exponent
Looking at the 2.0 TODO list:
http://wiki.metalforge.net/doku.php/dev_todo:cf2.0
(as an aside, I'd hope to make the 2.0 release by end of year, which might
limit
it to the 'High' and perhaps some 'medium' items on the list)
One of the high priority items is character creation todo. That's
Alex Schultz wrote:
> Mark Wedel wrote:
>> For example, there may be 4 different skills of sorcery - basic, expert,
>> advanced, mastery. However, these all tie in with the same skill.
>>
>> The sorcery class starts with the mastery skill. Some of the other
It has long been discussed that with a few exception (the non humanoid races
and the classes that prohibit weapons/armors), a lot of race/classes tend to
blur together.
There are several reasons for this:
- There are not really any race/class restrictions for objects (or conversely,
not any
Tchize wrote:
> Sorry, jumping in Thread a bit late.
>
> I have quite a few experience with logging mecanism, here is my suggestion
>
> Arrange log entries in a hierarchy (scopes) like is done in java logging
> mecanisms:
>
> example:
> common.object (for everything related to object)
>
> Prov
Rick Tanner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Fuchs wrote:
>> - if you feel that something was improperly attributed, bring it up
>> on the mailing list to get it fixed
>
> I would suggest the following as well:
>
> When making such a request to the mailing li
Nicolas Weeger (Laposte) wrote:
>> Everything I know of, is attributed in the cvs commit comments, however
>> I am not sure he is aware of them or considers them proper attribution.
>
> There are AFAIK 4 patches on the tracker (closed, by elmex), and they all got
> (what i deem) proper attributio
Nicolas Weeger (Laposte) wrote:
>> Having the server of a plugin 'patch' objects loaded from the map itself
>> seems to me to be a pretty horrible hack. I know from a debugging side of
>> thing, having a bug with an object in some odd state, and not even being
>> sure how it got that way is a pain
Nicolas Weeger (Laposte) wrote:
> Hello.
>
>> I have uploaded a patch to the sourceforge tracker which forms an
>> initial proposal for requestable party lists.
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=1475202&group_id=
>> 13833&atid=313833
>
> This patch has been opened fo
I don't really have time to go into all the details, but have some quick
thoughts:
Having the server of a plugin 'patch' objects loaded from the map itself seems
to me to be a pretty horrible hack. I know from a debugging side of thing,
having a bug with an object in some odd state, and not
Alex Schultz wrote:
> Crossfire CVS repository messages. wrote:
>
>> Module Name: crossfire
>> Committed By:ryo_saeba
>> Date:Tue Jun 6 22:16:25 UTC 2006
>>
>> Modified Files:
>> crossfire/common: loader.c
>> crossfire/make_win32: crossfire32.dsp
>>
>> Log Messag
Nicolas Weeger (Laposte) wrote:
>> Which are harmless, but I think we should do a real logging system so that
>> isn't needed - instead, pass in the type of log message (object, map,
>> player, spell) to the log function, and then be able to specify what log
>> messages we want via command like, l
I just did a commit which really doesn't change any code, but does clean up
some compiler warnings (now the core area compiles without warnings when
compiled with gcc -Wall -Wno-char-subscripts).
As part of that, I removed a bunch of functions that were not being used
(with
#if 0/#endif b
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> While writing some test i came accross this line of code in
> sum_weight() (object.c)
>
> if(op->carrying != sum)
> op->carrying = sum;
>
> I suppose whoever wrote this had in mind that some memory chips are
> faster at read
Nicolas Weeger (Laposte) wrote:
> Anyone getting those messages when committing stuff?
>
> Nicolas
Nope, and I just committed a bunch of stuff. I suppose you could always
open
a ticket with the sourceforge support folks and see what is up. Is it a
continuous problem, or some more random?
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> Metalforge having been updated, I'm using the new mapcmd2 protocol, and
> noticed somee fun bugs :)
>
> First (no screen copy, sorry), sometimes 1 item only will appear from a pile,
> sometimes 2 items (without any monster)
I found the bug on that
Alex Schultz wrote:
> Mark Wedel wrote:
>
>> IIRC, gtk has no convenient way on handling the alpha channel (the
>> inconvenient way would be for the program to figure it all on its own,
>> figuring
>> out the appropriate RGB values, and then drawing those po
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> Unless I'm totally blind, current items's perspective is:
> * straight top-down view for ground, shop tiles, and such
> * top-down view with an angle, maybe around 30 or 45° (so the "bottom" is
> closed for user than the "top"), for walls, monsters, bu
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> GTK client (I didn't test the other clients) doesn't seem to support partial
> pic transparency.
>
> Has anyone tried to implement that?
>
> I'm asking because my centipede would look much nicer :)
IIRC, gtk has no convenient way on handling the a
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> Currently, balms of protection and such work correctly even on unholy grounds.
> On the other hand, balm of return home (word of recall) doesn't work. This
> because when it actually executes it checks again whether ground is holy or
> not, thus it ca
Wim Villerius wrote:
>> Would be interested in more details on that, especially if you can get a
>> reproducible test case.
> Not exactly the case Nicolas describes, but try the following: cast
> counterwall and walk in it. You'll see yourself disappearing. (This
> works for any spell I've seen)
I think the general balance issue on apply dynamic alchemy to any object is
basically this:
If the same rules apply for all armor type items (boots, gloves, helmet,
shield, girdle, bracers, and the armor itself), players can really crank up
their power.
For most of those, there is a lim
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> Metalforge having been updated, I'm using the new mapcmd2 protocol, and
> noticed somee fun bugs :)
>
> First (no screen copy, sorry), sometimes 1 item only will appear from a pile,
> sometimes 2 items (without any monster)
Would be interested in
Lalo Martins wrote:
> Having spent most of my last two working days implementing a colour picker
> :-P I must say I like the idea of hue/saturation; it's perfect for this
> purpose, as it completely describes a light colour. And you can use one
> byte, wasting no bits, and have great resolution;
Looking at the readable code, there are basically 6 readable object types.
I'm not sure if any treasure lists explicitly try to creatable alchemy books,
but if not, each has equal chance.
(the 6 types are monster info, artifact info, spellpath, formula, god, and
stuff
from the message file)
Alex Schultz wrote:
> Mark Wedel wrote:
>
>> 1) Increase number of lighting levels from 4 to 12.
>>
>>
> Seems rather arbitrary, but seems reasonable.
Most constants are arbitrary at some level.
However, I came to that number for a few reasons:
a) the MAP2_CO
Now that I've finished the map2 command, bringing up the idea of lighting
redo. As doing part of that, I've thought up some new issues.
But first, summary of proposed changes - most of these are from discussion
last summer. Note that all are not likely to be done at the same time, and
th
Andrew Fuchs wrote:
> I would like to ask a few questions in terms of making maps and archetypes.
>
> There are currently archetypes for chandeliers, would it require more
> code to make these appear above players?
For chandeliers, if fly is set on them, they will appear above players, as
the
Tchize wrote:
> Mark Wedel wrote:
>> Alex Schultz wrote:
>>
>>
>> This won't happen any more. living objects are defined to be on level 6
>> and
>> 7. So the only thing that would cause it to change layers is if it steps on
>> top
>&
Nicolas Weeger (Laposte) wrote:
>> But the other issue is more that compiling spews out a fair number of
>> warnings, and the basic problem is that if too many warnings are generated,
>> people just ignore them, and there could be valid issues.
>
> Latest tests i've done show only 2 warnings for
Alex Schultz wrote:
> Mark Wedel wrote:
>
>>
>>
>> 2) the map2 has support for 10 layers. However, compared to the old 3 layer
>> method where it tried to find something to fill each of those 3 layers,
>> different layers are well defined to hold speci
Nicolas Weeger (Laposte) wrote:
>> The one problem with doing so is that clients not using the map2 protocol
>> won't see these objects being animated anymore. My personal thought is
>> that this isn't that big a deal - the animation of these objects is more
>> window dressing than anything imp
Quick thoughts:
1) I'd prefer a way to say what item I want improved, vs it improving the
strongest. this is more an issue for the first improvements most likely. Or
if
it is very clear how it decides what is the more powerful object (item power)
that may be reasonable, except you have 2
Nicolas Weeger (Laposte) wrote:
> Hello.
>
>> Having recently updated my computer to an athlon 64, this creates some
>> issues for crossfire.
>
> I'm under an AMD64 since end of january, and didn't see any specific
> Crossfire
> issue. Ok, I don't run a local server, or play intensively :)
>
Having recently updated my computer to an athlon 64, this creates some issues
for crossfire.
Specifically, on 32 bit, sizeof(long)=4, sizeof(long long)=8.
On 64 bit, sizeof(long)=8, sizeof(long long)=8
This pretty much means the use of the 'long' type most anywhere in crossfire
is inco
I just committed the code that adds the map2 protocol command to the server.
I played around with it quite a bit and didn't notice anything odd.
A few worthy notes however:
1) Support for the original map command was removed. Clients as of 1.2 (or
thereabouts) have support for the map1 co
To me, the model sizes isn't that big a deal.
After all, most people will only need to check out the arch tree once at
most.
So that initial checkout will take longer. But unless the models actually
change, the time to do cvs updates shouldn't be longer.
The only way to get around
Pippijn van Steenhoven wrote:
>> * put generated pics in the arch/ directory
>> * put models and scripts in a new 3dmodels or whatever directory
>
> We are currently discussing this for Crossfire+. Ideas have mainly been
> expressed in IRC but some are here:
> http://cf.schmorp.de/tracker/view.php
Here is a little script I wrote to update the repository information - in this
way, you don't need to do a new checkout and then merge. cd into your CVS tree,
then run 'update_rep .' to update the entries.
#!/usr/bin/perl
use File::Find;
find(\&wanted, "$ARGV[0]");
sub wanted {
if ($_
Pippijn van Steenhoven wrote:
> Hi,
>
> just one thing about SSL streams. I suppose they would be used to transmit
> passwords from the client to the server? Well, if the model was changed and
> the password would not even be transmitted, there would be no need for such
> streams and the entire co
Jochen Suckfuell wrote:
>
> I wouldn't want to see the crossfire client's memory footprint exceed 500 MB
> (or does it already? - long time no play).
Each 32x32 image should take about 4k (32 * 32 * 4). There is of course some
other overhead, but probably not too much.
Thus, you get about
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> I've been toying with the idea to do some (3d) modelling for monsters and
> such
> for Crossfire, like some are doing for CF+.
>
> Right now many (monster) animations are 4 frames long (3 frames with 1
> repetition), and all I think are under 10.
>
Alex Schultz wrote:
> Mark Wedel wrote:
>
>> Some general quick thoughts:
>>
>> As stated before, selective 'per packet' compression has the nice advantage
>> very easy to do - no need for extra buffers on the client or server side
>> needed.
>
Andrew Fuchs wrote:
> Umm, was this the flaw i discovered, or is it a new one?
The fact it says version >= 1.9.0 are not affected would seem to suggest that
this isn't a problem anymore. but I'm not sure exactly what bug this is
describing.
>
> -- Forwarded message --
> Fr
Some general quick thoughts:
As stated before, selective 'per packet' compression has the nice advantage
very easy to do - no need for extra buffers on the client or server side needed.
That said, if someone is willing to write that extra code, sounds good to me.
A quick question is - are
To me, there are perhaps two issues, which may or may not be related:
1) Ability to have multiple repositories on stable systems.
2) What source control tool to use.
Right now, and probably with any source control tool, multiple _read only_
repositories could be done. In CVS, this would b
Alex Schultz wrote:
> Robin Redeker wrote:
>
>> The change in the earthwalls made the monsters attack you through the
>> earthwall, as if they could see you
>>
> On a slightly unrelated note to the topic of earth walls. Monsters
> currently omniscient to everything on the map that isn't 1) too da
Robin Redeker wrote:
> On Sun, May 07, 2006 at 10:50:09AM +0200, Nicolas Weeger (Laposte) wrote:
>> * earth to dust fails because no object with move_block is on the spot. This
>> is because earth wall that was created has no move_block set - wall is
>> alive,
>> thus player/monsters can't get o
Nicolas Weeger (Laposte) wrote:
> Hello.
>
> juhaj on IRC reported a earth to dust bug.
>
> Looking at the code, I see 2 issues:
> * in server/spell_effect.c, lines 705/706, it should be imo for(i=
> -range;i<=range;i++) instead of for(i= -range;i do [-range..range] inclusive
> * earth to dust f
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> Due to a bug in sourceforge security management, only project admins
> have access to the page named 'source logos' which contains the codes
> samples to use on every project webpage hosted on sf. As i will
> publish u
Overall, the idea looks fine, but I haven't looked at the actual patch.
But a few other thoughts:
1) It could be nice to include the highest number party number in the stats
command (only transmit when changed). Since I recall that whenever a new party
is created, the client can use this
Nicolas Weeger wrote:
> Also, the price estimation seems quite weird - you set the price to eg
> 2000 silver, and player will pay ~500 platinum :)
> I suspect it's due to the query_cost and such functions using charisma /
> shop specialization / ...
yes.
Presumably, shop specialization could
Robin Redeker wrote:
> Hi!
>
> Is that right what i just read: The random encounters where took out of
> the code around 2001?
> Why was it removed? Is it possbile to reimplement it?
The implementation that was there was IMO more a pain than worthwhile.
Basically, with some probability, grou
Sebastian Andersson wrote:
> On Tue, Mar 28, 2006 at 10:57:21PM -0800, Mark Wedel wrote:
>> 3) Compress everything sent. This should be done at a lower level (when we
>> actually write to the socket).
>> Cons: Stille harder to do - if we compress a block of data, but can on
Daniel Daxler wrote:
> Just thought I would mention this super fast compression and decompression,
> that I have had good experience with (over modem line).
> http://www.lzop.org/
>
> Or the mini-version miniLZO.
> http://www.oberhumer.com/opensource/lzo/#download
>
> I believe the sever cannot
tchize wrote:
>>>
>> This point is the real gotcha however - since the server can choose what
>> data
>> to compress, the question then becomes what portion of the commands are
>> being
>> compressed?
>>
>>
> I was unclear. I just meaned, the server would do something like
> and his datas
>
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Just a note about the suggested
> s->c compressed
> c->s compressed (yeah imho shoud go in both directions)
I'm not sure if there is anything to really gain by the client compressing
the
data. I can't really think of many
Brendan Lally wrote:
> On 3/27/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
>> I just ran a quick test (find . -name "*.png" -exec gzip -vc {} > /dev/null
>> \;) , and this is a somewhat typical result of the entire arch tree:
>>
>
>> Some fil
Various thoughts:
1) The idea is interesting. However, like most such proposals, balance has to
be maintained - if I can take a couple ancient red dragon steaks and get
mithril
chain resist fire +90, the case can be made that that is a bit too power.
2) You mention where to store informat
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello
> While writing arch check code, i noticed this.
>
> There are a few functions in arch.c which are named
> get_archetype_xx but in fact return a new object of that archetype
> using arch_to_object. I plan to rename thos
Sebastian Andersson wrote:
> On Sat, Mar 25, 2006 at 10:02:56PM -0800, Mark Wedel wrote:
>> There are a few likely differences which may or may not effect crossfire
>> in
>> different ways:
>>
>> 1) Some data crossfire sends is just not compressible. T
tchize wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mark Wedel a ?crit :
>
>>
>> All in all, seems a lot simpler to just restart the server than try
>> to sort all of this out.
>>
> Agree. However, if i understand well, the problem
Robin Redeker wrote:
> I've discussed now a different approach. First, i think you were right
> with 95% max resistancy. Thats indeed reasonable. But what about
> resistancies like paralyze, slow, drain, depletion? Couldn't there be
> +100 allowed?
Yes, 100% could be allowed for those.
>
>
Alex Schultz wrote:
> Mark Wedel wrote:
>
>> General notes - small map packets are not worth compressing. The cut off
>> to
>> be worth while is probably around 200 bytes.
>>
>>
> One note, usually, map packets are larger than that unless they are
&g
Sebastian Andersson wrote:
> On Sat, Mar 25, 2006 at 01:00:59AM -0800, Mark Wedel wrote:
>> For other reasons, I still think I'll add animation support to the map2
>> command. However, I think it also worthwhile to add something like:
>>
>> S->C: compress
&g
701 - 800 of 1085 matches
Mail list logo
