[crossfire] mapcmd bye bye.
Anyone have any issues for removing the original mapcmd protocol command? the map1/map1a commands will remain. Client version 1.1.0 introduced support for the Map1 command. So I can't really see it breaking anything. Due to changes needed for the map2 command, this will require some amount of updating for the map1 command. I just can't see much reason why the mapcmd is needed anymore, but thought I'd throw the question out there in case someone is aware of some issue. Probably the way to handle this is for the server to check after negotiation that at least the client has negotiated at least to the map1 command, and if not, print out an error and close the connection (error message along hte lines like your client is too old, update). The one issue where this could perhaps be an issue for any bots out there that just ignore the map data, and thus don't bother to negotiate a map version in the setup parameters. So maybe this message should be considered more a heads up to those people with bots to make sure it is at least negotiating a map1 protocol level? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] first bug discovered by unit test
That would be more functional testing than unit testing, however both are planned in the framework. security functional testing may be a good idea to include some of. Perhaps some thing like attempted buffer overflows over the protocol, or verifying that the password code isn't making any silly mistakes at any time in the future. That said, I'm not sure exactly what could be done for these sorts of tests, as not every circumstance could be tested, so the difficulty is planning what things are most important to test in order to catch potential future or current flaws in security. Miguel Ghobangieno wrote: >Yay. There should be added some security unit tests >aswell. > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] map2 & animations
And so says Mark Wedel on 13/03/06 10:25... > However, I was looking/thinking about letting the client handle the map > animations. Not knowing much about the protocol, the only comment I can contribute to this topic is: YES PLEASE! :-D Server admins and players with bandwidth limitation both appreciate it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] map2 & animations
I've started work on the map2 command - preliminary documentation on that has been in the Protocol file for a while, but I have made a few minor changes. However, I was looking/thinking about letting the client handle the map animations. From a protocol perspective, this isn't really hard - we just need to send down some extra information. My initial thought here is to just set the high bit on what is normally the face num field to denote this is an animation (this limits us to 32767 faces, but I'm not that worried about that). Also, to make things work better, I was thinking a couple extra bytes are needed - 1 for the animation speed, and one for the current animation position (where we are in the sequence). The later may or may not be important depending on how we deal with things. My thought is that for things like monsters, if we animate them, we want to send that - otherwise all the monsters are in a lock step formation. However, as I think about it, there are really 4 cases for animations we care about: 1) Animations that should be lock step. Point in case would be the ocean spaces - it would look better if they were all in phase - right now, you can see the edges of the tiled maps because the phase between the two maps is different. 2) Cases where it should be randomized. Monsters come to mind in the case - the phase of animation for things like goblins isn't important, and it does look better if they are in different phases. Randomizing this on the client works better than sending current phase because of timing. Think creatures that have a speed of 0.20. Once every 5 ticks, they move and their animation change. If we only send current phase, that means the client will have all of them on 'phase 2' go to phase 3 at the same time, and then all of them don't change for the next 4 ticks. If the client randomizes this on its own, then 20% will change animation each tick. 3) Animations in which phase is important (or temporary). Example here would be things like gates/spikes. In this case, the client really needs to know what phase the gate is in when it shows up - it can't lockstep it or randomize it. In addition, timing here is important - if the server spends a second loading a map, the client has to be aware that those gates haven't done anything for a second. This isn't that hard to solve by adding something like a 'S-C> hearbeat' protocol command which the server sends each tick it processes. But here, we still get a timing case - suppose those gates move at speed 0.2. Just telling the client that it is on phase 2 really isn't enough - the gate could go to phase 3 the next tick, or to that phase 5 ticks from now. So to handle this, not only do we need to send the phase, but also how soon until the next phase. My personal thought is this: Add new flag(s) which says how to handle animations. My personal thought is leaving case #3 as a server side is probably the easiest (server side being that we don't send animation to clients, just send face for the space like we do now). This doesn't get us as much of a bandwidth savings as possible, but does keep things simpler - at some level, its a balance of how much complication do we add to save some bandwidth. So I'd suggest addition of two new flags - one to handle case 1 (FLAG_CLIENT_ANIMATE_SYNCHRONIZE) and case 2 (FLAG_CLIENT_ANIMATE_RANDOMIZE). These flags would be used to tell the server that we should like the client handle the animation (hence the CLIENT part) as well as to tell the client how it should handle the animation. My thought is the top bits could be used to convey this. So something like: : If set, this isn't a face, but animation id: : Convey animation type. Right now, there are only 2, but it is good to leave a little room for expansion (I could perhaps seeing something like a FLAG_CLIENT_ANIMATE_ONCE for things like burnouts to denote that that once the animation gets to the last step, it should stop animating and not cycle) This leaves 13 bits for animation id, which is 8191 animations. Given we only have 989 right now (and that could actually be brought down by merging some of the multipart images to big images), I'd think that should be plenty. Thoughts/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] first bug discovered by unit test
Yay. There should be added some security unit tests aswell. --- tchize <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > While am still preparing check framework for > crossfire, i found a bug > in common/shstr.c where query_refcount was returning > wrong value. > Fixed and commited. I hope unit testing will > discover more of those > still undetected bugs :) > > Tchize > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFEFFfEHHGOa1Q2wXwRAh24AKCAnbCQIhV7s8lHc/rWQWsiQ05DpwCg8a+l > j9lkYAgdM+qrmtGnFsNUsVM= > =/d7V > -END PGP SIGNATURE- > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] first bug discovered by unit test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While am still preparing check framework for crossfire, i found a bug in common/shstr.c where query_refcount was returning wrong value. Fixed and commited. I hope unit testing will discover more of those still undetected bugs :) Tchize -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFFfEHHGOa1Q2wXwRAh24AKCAnbCQIhV7s8lHc/rWQWsiQ05DpwCg8a+l j9lkYAgdM+qrmtGnFsNUsVM= =/d7V -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Code cleanlieness and server stability
On Fri, Mar 10, 2006 at 10:39:05PM -0800, Mark Wedel wrote:
> Robin Redeker wrote:
>
> >
[...]
> > else if (item->type == SCROLL && QUERY_FLAG(mon, FLAG_USE_SCROLL)) {
> > if (monster_should_cast_spell(mon, item->inv))
> >
[...]
> > So we patched it like this:
> >
> > if (item->inv && monster_should_cast_spell(mon, item->inv))
>
> I think you still need the item->type == SCROLL check in there - otherwise,
> the monster will try to use spellbooks, wands, rods, containers - anything
> with
> an inventory, as a spell.
Of course we did not remove the line with the else if :) Sorry if it was
misleading. I only meant that we changed the line:
if (monster_should_cast_spell(mon, item->inv))
to:
if (item->inv && monster_should_cast_spell(mon, item->inv))
Robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests, request for comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Those won't be macros but function, they do too complicated stuff to be macros. Those will be part of the unit test toolkit (directory crossfire/test/toolkit), which will made available to each test_xxx. Various helpers will be developped and made available to users as unit test development advance. Alex Schultz a écrit : > Another thing, I'm thinking that in order to make such tests very > easy to make, a variety of convenience macros would be good to put > here. Such as perhaps one to run the main server cycle for x ticks, > and perhaps one to run the main server cycle until another > specified macro or function returns non-zero. It might also be good > to make some little macros such as one for map loading, that has a > slightly simpler interface than the normal one (don't need that > last parameter for most functional tests). Having a good variety of > such convenience functions and macros would make building > functional tests easy to learn by example even for someone who does > not know much C at all, and would make it faster for those who do. > > > tchize wrote: > >> Includes Testcases will share some include files not >> present in crossfire core. Those test specific headers will be >> put in test/includes >> > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEE/LaHHGOa1Q2wXwRAkrxAJ0fJOLQZzftcr3z4/hiV5x8uSWGvACgxOas uuajkXK4Kt5rZzJptC5wxQc= =gRkG -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
