Re: [crossfire] Crossfire 2.0+ features/priorities (compression)
A server variable could be set that turns on/off compression. __ 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
Re: [crossfire] move_allow attribute
I like this idea very much (though I would caution against giving players themselves a pass wall spell), I creates a granular permissions system that is appealing. --- Mark Wedel [EMAIL PROTECTED] wrote: Thinking a little little about transportation objects (boats, horses, etc) and came to the realization that at some level, a move_allow field is needed. The basic idea is that move_allow would override any move_block. The case I'm thinking about here is boats - players normally can't move on the water. While the move_block of the water spaces for boats in harbor could be changed so you could get on the boat, this doesn't work so well if you anchor your boat at some island. The code to handle this would actually be fairly trivial - basically, in the update position, move_block = ~move_allow This also allows for some other interesting things. For example, one could imagine creating a 'bridge' spell that goes over water - basically, it just acts like a wall spell, but has move_allow WALK on it. Passwall (letting you put holes in walls) would be another case. One question would be on how to handle slow_move attributes - should those get blanked out also. I'm sort of thinking yes - then you could also have a 'create road' spell to get through the jungle quickly. Thoughts? Questions? __ 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
Re: [crossfire] Crossfire 2.0+ features/priorities
On 29/01/06, Mark Wedel [EMAIL PROTECTED] wrote: One of the things that have been on my wishlist a long time is a better character creation method. I'd say that a character creation window would work best - where you can select the name, roll and re-roll stats, chose your race, sex, and class, and see how it changes your character (as well as seeing how the character looks themselves). Race/Class descriptions can then go into textboxes under pulldown selection controls, and starting items/skills should be viewable. Another thing I can propose is to replace the listen level with channels, and be able to toggle/redirect individual channels between different tabs in the client. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 1/30/06, Anton Oussik [EMAIL PROTECTED] wrote: Another thing I can propose is to replace the listen level with channels, and be able to toggle/redirect individual channels between different tabs in the client. I had a working channels implemention, but the problem was that it was too complex to be really usable, and seemed too similar to the party code. hijacking colours in the draw_info packet to send meaningful data about the type of draw_info would be more reasonable Maybe also it would be an interesting idea to have a 'triggered' draw_info which would send back the packet number that caused them to be printed (this would involve storing the last packet number in the player struct, and sending it in the packet) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities (compression)
Miguel Ghobangieno wrote: A server variable could be set that turns on/off compression. This is a good point, it would allow servers to balance bandwidth and processor usage on the server side better if the are short on one but not the other. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] move_allow attribute
Miguel Ghobangieno wrote: (though I would caution against giving players themselves a pass wall spell) As I understand it, with what Mark is saying, walls would have to explicitly be set to allow passwall. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel Ghobangieno wrote: Well Leaf said that it was so that if someone really wanted to recant their diety that they could, but they would have to mean it (not by accident, or by mere trifiling whim) and thus brace. Actually, I pointed out how the brace command *can* be used when switching cults during a discussion[1] of removing the command because it offered little or no benefit for using it. [1] - http://forum.metalforge.net/viewtopic.php?p=9535#9535 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3q1ghHyvgBp+vH4RAtE3AJ9TirT0cTwj3+5tSuZgtcmH9C2r0gCfcGQU kt9rlYbH/7UPLeUD+uyxei8= =8P5B -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel Ghobangieno wrote: Maybe some new spells too? Circular spells ect (kinda like a circle of protection of fireballs spining around you etc). This effect is already possible (and probably unintentionally, too) by using the stay fire command. NOTE: I /think/ the stay fire sequence is used, but it's been years(!) since I bound this to my key settings. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3q+FhHyvgBp+vH4RAigXAKC9X0u0chR8f9aEcDYk5modvYDB0gCePVVm tkB0XDttxy7QyYq7we4Q3qw= =MWhv -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] move_allow attribute
move_allow * would just add some more control over movement permissions so that one can more easily set what cannot and what can pass over the tile; more granularity. Theoretically, after this is added, spells can be created (such as build bridge, which could set move_allow walk on the affected water tiles and then spawn brige arches forward (if spells were allowed on said tiles ofcourse) that can use modify permissions. I would suggest, however, that (specifically) a passwall spell not be given to players (could be used in fire-walls for some things though etc). --- Alex Schultz [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: (though I would caution against giving players themselves a pass wall spell) As I understand it, with what Mark is saying, walls would have to explicitly be set to allow passwall. Alex Schultz ___ 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
Re: [crossfire] Crossfire 2.0+ features/priorities
Brendan Lally wrote: On 1/30/06, Anton Oussik [EMAIL PROTECTED] wrote: Another thing I can propose is to replace the listen level with channels, and be able to toggle/redirect individual channels between different tabs in the client. I had a working channels implemention, but the problem was that it was too complex to be really usable, and seemed too similar to the party code. hijacking colours in the draw_info packet to send meaningful data about the type of draw_info would be more reasonable Maybe also it would be an interesting idea to have a 'triggered' draw_info which would send back the packet number that caused them to be printed (this would involve storing the last packet number in the player struct, and sending it in the packet) Long on my wish list also was to change handling of messages (draw_info) to change from color to tags that denote what the message pertains to. Eg, combat messages, listings (shop, who, etc), shout, talk, etc. I think there would probably be about a dozen different content types. The client could then have a pretty easy interface to say what to do with the message (discard, print in window 1, window 2). Also, let the player choose the color/font for these. This adds some amount of complication to the client. But a first pass is to just update all the draw_info to use new flags. A first pass on the client would be something simple like 'shout - ok, these are red, and put in window 2' - basically be hardcoded to how it works now, with the interface to follow, since that is probably the harder part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Alex Schultz wrote: Mark Wedel wrote: This issue is really the server-client direction, and that already is binary, so not a whole bunch of savings. I have a feeling the big hog is the map data - things like stats is never much. The item stuff, especially for huge piles, can add up. And I think someone suggested that the detailed item information (what you get from describe item) is also sent along - I think that may be a reasonable idea, but does increase the bandwidth on that (that is also tricky in that certain things could change the description of the item (it being identified will change its value for example) - I'm not 100% the UPD_ flags cover that, but probably do (but money will always be suspect - changing charisma can affect costs also). What would also save alot of bandwidth, would be including in the new server protocol a method of sending rectangular blocks of tiles that should all be added of deleted. This could potentially cut the map bandwidth in half or less in some locations (lots of floor and walls compared to everything else). Making the client interperate the data for that would be very easy, the most difficult part would be the server logic of where it should define rectangles but I am sure that is not too bad. It could be done now, but could prove to be a costly (CPU wise) operation - the map code would have to look to see if there are such regions. There may be fast ways to do that. But you also get the cases that you need to check to see if it is faster to send that block. a 2 square rectangle is not going to be any faster than just sending it as two spaces. a 3 space block may be the break even point. But it also gets tricky - having a 10x10 area of floor with nothing on it, it would be a clear win. But if that floor is littered with monsters, objects, etc, it becomes less clear, because we're going to need to send data on those spaces, so we are not saving the cost of sending the coordinates, just the cost of sending the face itself. I'm more inclined to just go with the compression method - if the same face is repeated 200 times, the compress code should do a good job of reducing that to very little space. And I think this may actually be less cpu costly than trying to find rectangles. It also helps for those cases where we are sending data that does not encompass the entire range of data size. For example, we use 16 bits to send the face data. Yet right now, we only have 5000 faces, which can fit in 13 bits. So going through compression would still save space even on maps without good rectangles. I put up a couple ideas about the new map protocol here a while back: http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol (see also http://wiki.metalforge.net/doku.php/dev_todo and http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 on the wiki) Alex Schultz ___ 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] cfclient colouring (was: gcfclient options deathlist)
I'd personally say that requiring a 256 color display isn't asking too much now days. Yes, in the old days, black and white monitors and workstations were somewhat common, and given crossfire was a unix game, made sense to accomodate them But 8 bit color has been around for a long time - I don't know the last system manufactured that only had black and white output. I actually think the grey background looks nicer than the old dark green background. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
