Re: [crossfire] Crossfire 2.0+ features/priorities
In that case it would make sense to make a big noobie map, with buildings, each of which contains a course to do some thing. If each of these noobie maps was personal to the player, the players could learn about playing cf without anyone else spoiling their fun. This would also enable them to come back later to complete learning if they can not be bothered with advanced stuff just yet. I propose each building award the player some experience towards the skill at the end to make it worthwhile. These are the general buildings I can think of: - Basics 1: Moving, applying things, reading signs, notes, etc. - Basics 2: Wearing, equipping, making active, opening/closing, marking, 'body command - Basics 3: Changing/learning skills, commands like 'statistics, 'skills, experience system - Traps 1: Finding/disarming traps (on the floor, in doors, on chests) - Traps 2: Setting traps - Melee combat 1: Attack things with punching/karate/etc. - Melee combat 2: If you can hold a weapon, how to use it to do things in 1, run attack - Ranged combat 1: How to pick up and equip bow, arrows, and shoot - Ranged combat 2: bowmode and arrow quivers - Spell casting 1: How to see what spells you have, select a spell you have, and fire a spell. - Spell casting 2: Learning new spells, types of spells (schools), sp requirement, spell level. - Spell casting 3: Different kinds of spells (cone/bolt/etc) and casting them - Identifying: List different ways of identify items - Healing: List different ways of healing different things - Alchemy: How to use alchemy-like things - Stealing: How to steal ...and possibly a few more buildings for things like oratory, climbing, jumping, literacy (scroll making?). Then there could be specific houses for the races like dragons explaining the whole food/focus thing, a house for firebournes explaining the whole you are a ball of fire, don't get put out thing, and a house for wraith explaining You are dead - you don't digest food or heal (when I make the patch balanced enough to be applied to the source tree) thing. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 27/02/06, Mark Wedel [EMAIL PROTECTED] wrote: OTOH, I'm firmly in the camp that I'd like a nice popup window on the client where the player chooses his stats, race, class, and if we want to go in the direction of choosing skills, that also. Me too, but then followed by two introductory maps, one for the race, where the player goes through a course learning about their race, its advantages and disadvantages and how to use it effectively, and another about their class, learning about its advantages and disadvantages and how to use it effectively. That does however requires some map making to make it interesting. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Anton Oussik wrote: On 27/02/06, Mark Wedel [EMAIL PROTECTED] wrote: OTOH, I'm firmly in the camp that I'd like a nice popup window on the client where the player chooses his stats, race, class, and if we want to go in the direction of choosing skills, that also. Me too, but then followed by two introductory maps, one for the race, where the player goes through a course learning about their race, its advantages and disadvantages and how to use it effectively, and another about their class, learning about its advantages and disadvantages and how to use it effectively. That does however requires some map making to make it interesting. I could perhaps see some special maps for the special races (fireborn, dragon, maybe another). I can't really see the need of separate/unique maps for most of the humanoid races. Is an elf really much different than a dwarf than a human? Sure, there are a few different skills that each get, but they are similar in a larger regard (item identification/creation). The class one would perhaps sort of mimic the current newbie one? How to kill creatures, pick up objects, etc? I wonder if that could be expanded, like 'if you have a spell, this is how you cast it', etc. So new players could do what tasks are relevant for their class. Yet at the same time, see other things that can be done. I wonder if these could also be made as unique maps for each player, so they could also revisit them later (for example, it may be several levels, but that fighter may start picking up spellcasting, and being able to revisit the introductory dungeon and learn about spellcasting could be handy). This also has the advantage that if players bypass it/exit it prematurely, they could re-enter it. There should be a way for experience players to largely skip it, but then you get the case of inexperience players skipping out and realizing they need that stuff. IF they can be pointed with something like 'go to Introductory Building next to the inn', that would be easy enough. Another random thought - the idea of being able to start in different places has been raised. I wonder if this could be one of those places, which then just exits to scorn. If a player is experienced enough to start in navar, then they shouldn't need that introductory dungeon. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On Sun, 29 Jan 2006 14:38:55 -0800 Mark Wedel [EMAIL PROTECTED] wrote: the current method of 'press keys to swap stats', 'press spacebar to cycle through classes', 'move your now created character to choose a class', and then heading to the nexus are all a little hokey. (Here is my char creation draft, another of my series, if someone thinks I should gather all the drafts I wrote on the wiki, say me, so they are all near, instead that sparse on the list) Me and lalo did lot of discussion about that, and we ended up with a design to still use in-game creation system (that I personally do not like, but many seem to like it in cf comunity) withotu sacrifing flexibility. Lalo created different rooms for class selection each with a different wall and decoration layout based in yoru race. Those rooms can miss the conflicting/owerpowered race/class combos too. (many rooms are allready created, work just need to be finished) Race selection is done in another room before this one, with each path that has a decoration that matches the one used in the class selection. Each way to a race has a magic mouth that tells you the stat mods, so the player has just to step on it to read the description of that race. The player starts in the race selection room as a new arch named something like life force (or energy). Note: A nice romantic notice on ghostish races should be something like life force sacrifice and converts to a death force After that, each race receive a cerain ammount of tokens (non dropable inventory item) to spend on skills. Each class is teleported in a different room with many paths, each path rapresent a skill, at the path start you get a magic mouth that explain you the use of the skill and what you will be able to do with it. Each skill cost a different amount of tokens, based on class (room is per class as said above), then the player chooses one skill stepping on the teleporter at the end of the path, if he still has tokens he get the skill and then is teleported back in the room to choose another skill. There is a special teleporter that bring you to startgin point directly, converting all your tokens in money (like 500gp per token), this is for players that prefer having no skills, but more startign money. Notice that only common skills are here, skills for casting are not supposed to be bougth in this room, this is for professional skills like smithing, woodsman, mountanering and so on It woudl be fair for the avarae skill to cost 2 tokens, with less improtant skills costing 1 token and complex skills costing 3 tokens (like smithing). This is the basic common for all classes. Casters classes will do one more step and go in a room with many paths where they can use their magic study tokens (or devotion tokens if churches become like magic schools) to acquire different caster skills like piromacy, sorcery... The number of magic study tokens you get is based on the class, class that studied magic obsessiverly get 3 tokens, so he can get 3 magic schools, intermediate magic user get 2 tokens, and basic magic user gets 1 token. Special races get in a room with race tokens (each special rage get 1) where they can buy race skills, like dwarfs can buy for just one token smithering or jewlercrafting as starting skill. Fireborns can buy piromacy, elves can buy woodsman. Or again they can convert those tokens to money takeing the exit. I think that's all, code changes requided should be minimal, but since I am on the side of plugininzation I add that there is a way to make map changes minimal too. If random map generation becomes plugin, you can just add a layout that is char creation room layout that automatically generates the path rooms, given a list of skills that need a path wtih the skill token cost, the name of the token items. Then the teleporters will have all the same token checking algo. So those maps are dynamic and generated only when a player step in, this is cause this model has many maps and keeping them all loaded allways sound terible. Morover keeping them in sync with game engine is sad too, cause we want to be able to add new skills. Generating the map on the fly solve both issures cause if you want to add a skill to a class you just have to edit the class generation file (where the plugin read the configuration) and you are done. This extra plugin idea adds more code now, but reduce the ammount of mapper work needed (considering that we have few mappers and bad mapping tools, it sound good to me). Morover it nearly zeros the ammount of mapper work requided in the future in case of skill change, and personally, thinking about mantainability, this is the only way to have a char generation that can be keep in sync with the engine. Notive that since the plugins is dynamic, each server can configure char generation, so a server that do not want to allow smithing as a starting skill for example, can jsut remove it from the list in teh configuration file of the plugin.
Re: [crossfire] Crossfire 2.0+ features/priorities
On 02/02/06, Mark Wedel [EMAIL PROTECTED] wrote: That said, if the smooth movement stuff is a high priority item, I'd think that would completely redo movement and actions, and that could be the time to fix it then. I would say that a smooth moving slowed down crossfire where it takes time to kill things (with health bars over monsters, etc.) is a good general direction for the project. However the CrossFire of today seems quite different from that. I have very little understanding of the movement/map code, but I would guess changing that would be very close to a re-write. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
I don't want those abilities removed. Why shouldn't I beable to make a magic monster that can reflect spells or arrows that? Just remove the ability from the knights and gaurds and remove the reflecting amulet from circulation. I hate all this talk of removing everything from the game. Maybe crossfire should fork to crossfire-intact and crossfire-not-intact? __ 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
I think a better solution would be to, rather then show every attack message, only show one every 1 second or so. Friendly fire is setable in the settings file and can be set low to compensate. --- Mark Wedel [EMAIL PROTECTED] wrote: But this is also tied to player speed. Unless you make attack speeds really slow, but that doesn't work will with current movement code - really, attack speed I don't think has much effect if it is slower than the players normal speed. So I think without some significant changes, hard to slow it down to the point you can read it out without some major restructuring. If we say the player speed is 0.5, that is still 4 attacks/second. I think to be at a 'readable' pace, it would need to be closer to about 1 attack/second. But you still want to move at a reasonable pace. So to do that 'slow' attack, you'd need some code restructuring - basically, you'd have to have a separate 'weapon_speed_left' variable or the like - if you try to move onto a monster, if your weapon_speed_left is less than zero, you just can't move there (right now, you'd attack the monster). I had suggested a long time ago adding something like 'damage factor' as a setting, which divides/multiplies damage done/received. This provides a convenient way to make adjustments without having to change all the archetypes and the like If we're going to start adjusting HP of creatures/players, I'd state a primary goal to be that monsters and players have more similar HP. One of the problems right now is monsters have so many more hp than players that targeting spells at other players become almost instant death. ___ 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
I think we should have plots and reputation system in for 2.0. And a setting to show (by default) 1 attack message per second or so (rather then char punches once, and again, and SUPRISE again!). It would also be good if the int for hp, maxhp, sp, and maxsp (used for alters) was raised to int 32 (it's int 16 now, right?). I don't think we should mess with the amount of hp clients or monsters get nor the weap attributes. We may want to explore the use of regents or something for spells as talked about before (you need this before you can cast uber powerfull spell). More spells... such as circular spells (not 'nova spells', orbiting spells: ring of fireball, etc etc) might be nice too. Transports would be good too. __ 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 2/1/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: And a setting to show (by default) 1 attack message per second or so (rather then char punches once, and again, and SUPRISE again!). I want the rate of attacks to be down to about one (or two at most) a second - at least for 'normal' weapons (like broadswords). Try swinging a sword more than twice a second consistantly, and then you will see why I think this a reasonable limit (yes, you can do more with a fencing sword like a foil or epee, but they don't do much damage anyway, if someone wants to add them with stupidly high weapon speeds, they could still do so). - having fewer attacks means more time to think in combat, less hack and slash, more strategy, and less CPU overhead too. I don't think we should mess with the amount of hp clients or monsters get nor the weap attributes. I want to get rid of reflect spells and reflect arrows as abilities, I think they too effectively nerf lightning spells, and make cone spells to useful. However I would like to have a 'recast' spell, which would cast a copy of any spell that hits a player in the opposite direction for a short period of time (couple of seconds). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Brendan Lally wrote: On 2/1/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: And a setting to show (by default) 1 attack message per second or so (rather then char punches once, and again, and SUPRISE again!). I want the rate of attacks to be down to about one (or two at most) a second - at least for 'normal' weapons (like broadswords). Try swinging a sword more than twice a second consistantly, and then you will see why I think this a reasonable limit (yes, you can do more with a fencing sword like a foil or epee, but they don't do much damage anyway, if someone wants to add them with stupidly high weapon speeds, they could still do so). - having fewer attacks means more time to think in combat, less hack and slash, more strategy, and less CPU overhead too. The counter of course is that crossfire doesn't mimic real time - IIRC, time in the crossfire world is 8-10 times faster than real-time. That said, I wholeheartedly agree that crossfire is too fast, so should be slowed down. Slowing it down would have another effect, that being that it would take longer to kill stuff, and thus money would be accumulated slower (As well as exp, and/or alternate ways of exp become more valuable). But if physical attacks are slowed downs, spells also have to be moderated in some way. And that can start to get trickier if the player has multiple wands/etc. That said, if the smooth movement stuff is a high priority item, I'd think that would completely redo movement and actions, and that could be the time to fix it then. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 1/31/06, Anton Oussik [EMAIL PROTECTED] wrote: In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) One thing that might work well there, would be to also have a reduction in weapon speed (reduce it by a factor of 2 or so). Currently when you attack monsters the attack messages are numerous and spam-y, if they were slowed down a lot (to at least the point where you could read all of them out loud as they come in). There would be fewer attacks to calculate, the rate of damage would be less, and there would also be fewer draw_info messages to transmit, which seems like a win all round. It would also make it possible to bring back the point from long ago of attack sounds, since attacks and parries would be slow enough that you could actually have sounds mapped to them. As an extension to the aboce extension a new family or party spells can be introduced. These will aid parties in combat by providing spells like party heal, and party word of recall. Possibly party strength, party wisdom, and so on can be introduced. They would be high level spells that would act on all of the party, and will belong to different magic schools. IIRC party spells are already supported in principle, but nothing is currently using them. ___ 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/31/06, Anton Oussik [EMAIL PROTECTED] wrote: In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) One thing that might work well there, would be to also have a reduction in weapon speed (reduce it by a factor of 2 or so). Currently when you attack monsters the attack messages are numerous and spam-y, if they were slowed down a lot (to at least the point where you could read all of them out loud as they come in). There would be fewer attacks to calculate, the rate of damage would be less, and there would also be fewer draw_info messages to transmit, which seems like a win all round. It would also make it possible to bring back the point from long ago of attack sounds, since attacks and parries would be slow enough that you could actually have sounds mapped to them. But this is also tied to player speed. Unless you make attack speeds really slow, but that doesn't work will with current movement code - really, attack speed I don't think has much effect if it is slower than the players normal speed. So I think without some significant changes, hard to slow it down to the point you can read it out without some major restructuring. If we say the player speed is 0.5, that is still 4 attacks/second. I think to be at a 'readable' pace, it would need to be closer to about 1 attack/second. But you still want to move at a reasonable pace. So to do that 'slow' attack, you'd need some code restructuring - basically, you'd have to have a separate 'weapon_speed_left' variable or the like - if you try to move onto a monster, if your weapon_speed_left is less than zero, you just can't move there (right now, you'd attack the monster). I had suggested a long time ago adding something like 'damage factor' as a setting, which divides/multiplies damage done/received. This provides a convenient way to make adjustments without having to change all the archetypes and the like If we're going to start adjusting HP of creatures/players, I'd state a primary goal to be that monsters and players have more similar HP. One of the problems right now is monsters have so many more hp than players that targeting spells at other players become almost instant death. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
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] 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] 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] 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] Crossfire 2.0+ features/priorities
But relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. Apart from the code cleanup idea, here's what I see as important: - Better visual appearance. On the coding side, it means adding things like support for smooth moves (continuous move of characters and monsters between squares, instead of the current direct jump to the next square visual effect), or support for action animations (when I attack a monster, I expect my character to swing its weapon. When I wear a shield, I expect the shield to appear on the character displayed). - Better scenaristic background. Currently, a lot of the maps are very bash-n-slash without little to no story behind. I think that more than software code additions, solid, interesting stories will keep people playing. Offering different starting points for each race, providing more interactions with NPCs, chaining quests, etc. would require no new code and would also help filling the Bigworld map. - Friendlier client. The currently available clients are intimidating for newcomers: the cfclient looks rather primitive while gcfclient is crowded with options bars, icons and menus and leaves only a small patch in the middle to display the game playfield itself. I think that a friendlier design here that leaves more space for the game would make the game somewhat more immersive and enjoyable to play. Those are the things that I see as top-priority. Apart from the first, I don't think they require massive code changes. I tend to think that - once cleaned - the current game engine of Crossfire is very good and includes a lot of interesting features, on par with many commercial RPG and that it mostly requires to offer better content to get much more attractive. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Mark Wedel wrote: With the current discussion regarding modularization, the topic of new features also came up. Discussions do that :P For 2.0, it was mentioned do a general code cleanup to removed old crufty code that is only there for compatibility reasons. Fair enough. Yes, I agree. We can't keep much of this old compatibility cruft around forever. Yes we don't need to do a major release for it, but IMHO doing it at a major release will confuse the players less and therefore would be of benefit. but relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. Features added... well... here's some ones I think would be neat for a 2.0 release (though doing all isn't too realistic): -Land plots (I plan on working on those some time) -Colored lighting and more lighting levels -More layers -Revamp/fix sound A few ideas/proposals on those are at http://wiki.metalforge.net/doku.php/dev_todo (feel free to contribute to the todo list there) Also I would really like to see the weather fixed up. The issues with that are: 1) Some disappearing tiles and such ugly bugs (might be a bug in the overlay code instead of weather code). (Also, no this isn't just Mikee, I've seen this on my private test server too) 2) Too much granularity right now. For this I think strange elevation values might be to blame. Might also be some simulation parameters. Not really sure. But in any case, you shouldn't see things like so many wet and dry spots speckled right beside eachother, that makes it seem almost as if there is little rainclouds speckled all over the place looking like they could float individually over player's heads 3) Once the granularity is fixed, perhaps some new rain pictures would also help that look even better I'm somewhat curious to see what the thoughts are. I think this info may indirectly help drive the modularization discussion - it may be that some of these features require significant rewrites or cleanups of the code that make sense with modularization. It may also be that some are relatively easy to do and don't require such changes. Personally, I think modularization and better organization would be something good to do, however I do not think it is worth doing major rewrites to archive such. Perhaps rewrite some parts, but IMHO there is plenty of organization that can be done with the current code without major rewrites. Also, out of the modularization discussions, there has been some 'game engine' talk. Personally, I do not believe separating into a game engine would be a good goal within/for the project, though I do believe that it isn't harmful if such separation comes as a side affect of other goals such as making the code more maintainable (not saying engine separation would necessarily have that affect, that is for another discussion). Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
On 1/29/06, Mark Wedel [EMAIL PROTECTED] wrote: but relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. I'll split this into two parts, usability issues/improvements, and game issues/improvements (many of these things I have hinted at on IRC in the past, but I'll describe them more fully here) Usability: currently most useful features of the game are hidden behind obscure text commands, without any nice way for the clients to show them in a systematic way. . - the rest are really minor niggles. I would suggest then, in no particular order: * client side display of parties (so that they can present an interface more like gcfclient2 has for the metaserver, removing the need for using the rather complex party commands directly). * adding more stats, including a number that could be considered as settings, so that clients can have a configure menu for them (imagine having a 'server' tab next to the general, map, and keybindings tabs in gcfclient) In order to do that, I think you would need to send output-sync short (byte?) output-countbyte bowmode byte mapped to associated requestinfo applymode byte mapped to associated requestinfo listen levelbyte petmode byte mapped to associated requestinfo usekeys byte mapped to associated requestinfo all of which would have better names displayed client side (eg, group up to [spinbox] identical messages before sending, recieve messages with priority [spinbox] or lower) * I'd also want to consider removing brace altogether, or at least making it a flag in the stats so that it can be displayed client side (hitting brace by accident and not being able to move can be confusing). * providing an [instruction] ext new draw info so that clients can print the instructions that apply to them in order to do things. (I would imagine that this would be something like drawextinfo 0 8 0 to worship a new god, stand on their alter and $(use_skill praying) then a client could look up their own 'instructions' array, or check their keybindings, and if use_skill praying is found, print that instead (otherwise, strip out the $() characters). - so for example, my gcfclient setup has use_skill praying mapped to 'p', so when I receive that message, it should check an 'instructions' array, find it empty, and then look in the keybindings, find one that matches, and say to worship a new god, stand on their alter and press p * a new login system, which would allow single packet character login, or creation. something like a login name\0password packet, and also a createchar name\0\password packet (with the double typing the responsibility of the client). then some way to request die rolls, and send back the final results, and a race choice For this there would be something like requestinfo races, returning replyinfo [list of races with their corresponding face numbers], then requestinfo race foo return replyinfo race foo the foo are a mysterious race from the land of the metasyntactic variable - clients then would be able to present a list of races to choose from, and a nicer interface to handling swapping stats. * sending all the information given from describing items in the items command (I think this is only the message, chosen name values, then having the description generated client side, and shown as a tooltip to each item - freeing the left mouse button to do something else to items (moving apply away from middle click, maybe?). * having a concept of actions applying to a square (an extension of what I mentioned the other day about having a goto system, have something like left-click to walk to a square/pull a lever/talk to an NPC/fight a monster on a square (probably whichever is appropriate to the topmost item on the square, decided server side) and right click to cast a spell/fire an arrow, etc to a square. (diablo-style controls) possibly as an extension to this, send an actionid to the client with the map command (2 bytes per square (maybe a byte if there isn't a convenient tayste within the rest of the (newly redesigned) map command), so that clients can tell the player what would happen by clicking on a given square (this would also need some special flags to decide whether to show things like secret walls - possibly they should be marked walkable once you are adjacent to them, but not from a distance - or maybe the detect traps skill should mark them detected, after which they show up) - an extension to the extension above, send health status along with monsters (probably as a percentage to not give away total hp), they can then have clients draw health bars above their heads. * having a keywords system in NPC dialog, so that when NPCs speak, it formats their text specially, underlining (or similar) the words they say that you can ask more about -
Re: [crossfire] Crossfire 2.0+ features/priorities
I have added a page to the wiki, where crossfire 2.0 features could be tracked. http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Brendan Lally wrote: I would suggest then, in no particular order: * client side display of parties (so that they can present an interface more like gcfclient2 has for the metaserver, removing the need for using the rather complex party commands directly). Yes - that sounds like a good idea. * adding more stats, including a number that could be considered as settings, so that clients can have a configure menu for them (imagine having a 'server' tab next to the general, map, and keybindings tabs in gcfclient) In order to do that, I think you would need to send output-sync short (byte?) output-count byte I'd suggest the output-* stuff on the server should go away. That was put in before the client/server split IIRC. I think any collapsing/discarding of messages should just be done on the client. Granted, doing it on the server does save some bandwidth, but I can't see that as much an issue on current connections. bowmode byte mapped to associated requestinfo applymode byte mapped to associated requestinfo listen level byte is listen level really used much? I'd almost suggest this go away also, but right now, harder for the client to deal with it, since it isn't getting message levels. petmode byte mapped to associated requestinfo usekeys byte mapped to associated requestinfo Yes, all the rest makes sense, and wouldn't be hard to do at all. * I'd also want to consider removing brace altogether, or at least making it a flag in the stats so that it can be displayed client side (hitting brace by accident and not being able to move can be confusing). Brace could probably go away now. I believe there are other ways to get the same effect (ready melee weapon skill, and just fire in that direction) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
One of the things we should do for 2.0 (note: we are not yet at 1.9) is try to decrease bandwith usage. For instance, some animations are cylical, and the server knows which ones these are currently IIRC. The server shouldn't have to send a update for every tile every time for cylical animations, the client should beable to work this feat IMHO. Also if we can make some commands that are 4 bytes long (north south etc) or other longish commands shorter that might be good too. (We should keep backwards compat here maybe thought, so if a client says it's not 2.0+ it gets to use the old, easier to parse, stuff). Plots should go in at 1.9 I guess. Crossedit could be gtkized for 2.0. or after. (I'm not against updating crossedit, I am against removing it). Maybe some new spells too? Circular spells ect (kinda like a circle of protection of fireballs spining around you etc). __ 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
Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! We shouldn't do things that increase bandwidth usage... /me watches the bandwith usage skyrocket just to spite him. --- Mark Wedel [EMAIL PROTECTED] wrote: Brendan Lally wrote: I would suggest then, in no particular order: * client side display of parties (so that they can present an interface more like gcfclient2 has for the metaserver, removing the need for using the rather complex party commands directly). Yes - that sounds like a good idea. * adding more stats, including a number that could be considered as settings, so that clients can have a configure menu for them (imagine having a 'server' tab next to the general, map, and keybindings tabs in gcfclient) In order to do that, I think you would need to send output-sync short (byte?) output-countbyte I'd suggest the output-* stuff on the server should go away. That was put in before the client/server split IIRC. I think any collapsing/discarding of messages should just be done on the client. Granted, doing it on the server does save some bandwidth, but I can't see that as much an issue on current connections. bowmode byte mapped to associated requestinfo applymode byte mapped to associated requestinfo listen levelbyte is listen level really used much? I'd almost suggest this go away also, but right now, harder for the client to deal with it, since it isn't getting message levels. petmode byte mapped to associated requestinfo usekeys byte mapped to associated requestinfo Yes, all the rest makes sense, and wouldn't be hard to do at all. * I'd also want to consider removing brace altogether, or at least making it a flag in the stats so that it can be displayed client side (hitting brace by accident and not being able to move can be confusing). Brace could probably go away now. I believe there are other ways to get the same effect (ready melee weapon skill, and just fire in that direction) ___ 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
On 1/29/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! But since being pushed off the square is an intended effect, being able to brace to avoid that is probably a bug rather than an intended feature. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
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. A question I have is does brace have any ill effects. EX: if you are on a mover, and brace, does that stop you from being moved. If so then... well that's not supposed to happen and brace seems like it needs work, if not then nm. --- Brendan Lally [EMAIL PROTECTED] wrote: On 1/29/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! But since being pushed off the square is an intended effect, being able to brace to avoid that is probably a bug rather than an intended feature. ___ 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
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. A question I have is does brace have any ill effects. EX: if you are on a mover, and brace, does that stop you from being moved. If so then... well that's not supposed to happen and brace seems like it needs work, if not then nm. I'd make the case that this should just be handled better, like if you pray over an altar to another god, you get a message like: You currently worship ... Changing gods will result in a loss of experience in the praying skill. Are you sure you want to do this (y/n)? This is one of those cases where hacks are currently in place - IIRC, there is a 1% chance when praying over the altar of a new god you won't get pushed off. This still means that occassionaly someone could be over an altar, pray (not intending to change gods) but hits that 1% chance when it doesn't push him off and thus change gods. The current method is to just repeat until you are not hit by that 1%, but that still seems like a bit of a hack. This could be changed without breaking any compatibility in clients, since it is just messages. That said, the current query status is IMO one of those things that could be done in a better fashion - currently, there is a ST_.. case statement with function to call. It would be much more flexible to convert that into callbacks. Eg, the function that prints out that message would do something like: set_reply_callback(change_god_confirmation, ...) Instead of having to set ST_ states. I think one reason there isn't much in the way of actual questions from the server because it really is a pain to set them up. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire 2.0+ features/priorities
Miguel Ghobangieno wrote: One of the things we should do for 2.0 (note: we are not yet at 1.9) is try to decrease bandwith usage. For instance, some animations are cylical, and the server knows which ones these are currently IIRC. The server shouldn't have to send a update for every tile every time for cylical animations, the client should beable to work this feat IMHO. I'll probably throw out a 1.9 release in the next few weeks. I do plan to work on the map2 command in that not too distant future (really!). Part of that is to let the client do animations. That said, that isn't a huge bandwidth hog. Also if we can make some commands that are 4 bytes long (north south etc) or other longish commands shorter that might be good too. (We should keep backwards compat here maybe thought, so if a client says it's not 2.0+ it gets to use the old, easier to parse, stuff). IMO, the client-server communications isn't an issue. Even at say 10 bytes/command, and doing 10 commands/second, that is 100 bytes per second. A 2400 baud modem can cover that. 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). It _may_ be reasonable to compress the map data if that packet was big enough (there would need to be a new command, like: S-C: cdata len And after the client gets the data, it then uncompresses it and then runs the commands from it. But to do that, requires some reworking - ideally, you would want to queue all the data that the server is about to send to the client during the activity tick, and then after that, go and compress the data and send it along. This actually wouldn't be that hard. However, it does make a tradeoff of CPU consumption (on the server to compress it) vs bandwidth. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire 2.0+ features/priorities
With the current discussion regarding modularization, the topic of new features also came up. For 2.0, it was mentioned do a general code cleanup to removed old crufty code that is only there for compatibility reasons. Fair enough. but relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. I'm somewhat curious to see what the thoughts are. I think this info may indirectly help drive the modularization discussion - it may be that some of these features require significant rewrites or cleanups of the code that make sense with modularization. It may also be that some are relatively easy to do and don't require such changes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
