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] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ 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] Negative Luck for pk
On 1/28/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Hi, I've asked for just that configuration option before. I'll forward this mail to the mailing list so the other devs may see that this is a wanted feature. Correction: it /was/ a wanted feature, about a year ago, which is roughly when it was introduced. from the settings file: # This is the penalty to luck that is given to a player who kills another # player (PK's). The value here is deducted from their luck value, so set this # high to discourage PK-ing and zero (or negative) to encourage it. # Range is limited to -100 to 100, since this is the value range that the luck # stat can be within. pk_luck_penalty 1 In the case of cat2, you probably want to set it to zero. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/29/06, Yann Chachkoff [EMAIL PROTECTED] wrote: But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). I believe that the random map generator also needs the same seperation of common and server, at least the way it is compiled at the moment. ___ 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 -
[crossfire] crossedit and the Java editor (was: renaming binaries (was: Moving server towards a modularized system?))
Yann Chachkoff wrote: I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. From what I have saw, the java editor is very flawed (not impossible to fix, however IMHO not very maintainable), largely due to various fixable bugs, but more importantly the language being unfamiliar to most of our devs, and therefor bad things happen such as mistakes that cause it to be slow (As I understand, there are lots of slow java programs, not necessarily because of the language, but coding mistakes that are common in it for C coders and such). The old crossedit is also very flawed due to a combination of it's widget set, and rather messy code (so messy that it's even worse than the Java editor likely). IMHO, what would be BEST (by no means least effort, in fact likely most effort), would be a rewrite of crossedit (different toolkit, make sure the code is organized), and a big cleanup of the 'common'/'server' separation. I might be willing to do this myself even once I get a bit more time on my hands. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. As I understand, his reason is because Java is a non-foss dependency. IMHO this is not a worthless point, it doesn't prevent me from using the java editor, but it does leave a 'bad taste in my mouth'. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). I believe the way that it is dependent on the server code is actually a rather eloquent thing; why maintain two separate copies of the map saving and loading code? Of course, that said, the current state of the split between common and server IS very hackish and somewhat ugly. However, I see making the separation more distinct and cleaner, would be something that would help with modularization, not so much fo any advantage in making features easier, but for making the code more maintainable. So if anything, the boundary between common and server shouldn't be removed, but should be fixed/cleaned up and solidified. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/29/06, Mark Wedel [EMAIL PROTECTED] wrote: I would suggest the following mappings (for both binaries and package names) crossedit - crossedit Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). The problem is that at the moment there is no real replacement for crossedit (CFJavaEditor doesn't work well enough, it doesn't even have undo support). I don't think that crossedit needs to be abandoned though, splitting it out into a separately distributed tarball/CVS module would suffice, if the functions that it uses from the server code are well documented/commented, then any changes to these functions in the server module should backport to crossedit as and when that is needed. Meanwhile, the server/ common/ distinction could go, and everything be rearranged more logically. (this would also have the advantage of allowing crossedit to be ported to a modern toolkit without breaking the server). gcfclient - crossfire-client gcfclient2 - crossfire-client2 (or crossfire-client-gtk2) cfclient - crossfire-client-x I don't know if there is any official standard on this, but if anything, it would seem the standard is that it be toolkitname-program name. Eg, gnome-terminal, xterm, etc. It is a little unclear to me where gtk ends and gnome begins - on my system, I see a lot of gnome-* programs, but not many gtk-* programs But given that, I'd suggest gtk-crossfire-client, gtkv2-..., x-crossfire-client, etc to keep that naming convention. The thing with this is that currently all distro packages are called crossfire-client or crossfire-client-gtk. If I am on a debian (or similar) system and install a program, I always try and run it using the name of the package, only if that fails do I bother to grep the filelist for bin/, sometimes if it is something I don't care about, then I ignore it and find something else to do the job instead. having the binary being tab-completable from the start of the package name is a good thing, especially when the .desktop files aren't installed properly. of course, should there ever be a KDE client, then the rules change somewhat, the name krossfire-klient would be obligatory. Perhaps have a generic crossfire-client script that looks for the different programs and tries to run the 'best' one available. I'd be interested to know how 'best' would be determined there. CFJavaEditor - jcrossedit See note above about naming. That said, I'd be a little less concerned about this one, as I doubt there is as much confusion in this (at least on the unix side, you don't run it directly anyways - you're going to use ant or have to do the java command by hand, so that is sort of hidden). java -jar CFJavaEditor.jar I don't in fact know if this can be reasonably assembled into a package or installed. But once again, making a script called jcrossedit that runs the JVM with the needed flags (I recall the default memory sizes really aren't big enough) may be the way to really go here. The default memory size is ok if you only open a couple of maps, and is a lot better than it used to be since tchize fixed it a while back. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
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] renaming binaries (was: Moving server towards a modularized system?)
Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff [EMAIL PROTECTED] wrote: I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ 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] crossedit and the Java editor (was: renaming binaries (was: Moving server towards a modularized system?))
Crossedit still works to some degree. However, when new things are added, it does break and fixes are needed. Anyone remember regions? Also, I haven't looked lately, but I'm not sure sure if crossedit actually supports all needed features - is there an interface to map tiling information, etc. If crossedit was to be redone, this would briefly be my suggestions: 1) Use glade to do layout, so additional layout features are easy to add in/layout. This would make whipping up the basic interface pretty quickly. 2) Make this a separate program from the server (new CVS tree). That said, large portions of code could be grabbed from the server (load/save) and the client (display). Sure, having the editor be a separate program would mean that that code may get out of date. OTOH, at least on the server side, there is a lot of code there that does things that the editor doesn't really need (and there are about half a dozen editor checks in the common directory to handle things we do or don't want to do if being used through the editor). 3) Do something like the java editor and have a file that does an object type/special fields type of documentation, instead of it being hardcoded into the program (eg, for exits, it is sp/hp which are the coordinates it leads to, but the editor should present that as dest_x and dest_y) That said, all of this is a non trivial process. If the java editor is not good enough, and can't be made 'good enough' then this is perhaps something that should be investigated. random map code: It only requires the 'common' directory for the stand alone random map generator. Since the random map code is linked into the server, it does not need/care about libcross.a. I don't know how often the standalone program is used, but if it was used enough, I'd suggest that the server could be modified to take some command line options (eg, crossfire -gen-random-map -random_map_options='') ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries
Miguel Ghobangieno wrote: Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I seem to see this ultimatum almost once a week now (do this or I leave) This carries no weight for me. I'm not going to program and make changes based on what one person demands to be done. Maybe you are the one that needs to fork off crossfire for your own use so you can do whatever you want with it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries
Brendan Lally wrote: On 1/29/06, Mark Wedel [EMAIL PROTECTED] wrote: I would suggest the following mappings (for both binaries and package names) crossedit - crossedit Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). The problem is that at the moment there is no real replacement for crossedit (CFJavaEditor doesn't work well enough, it doesn't even have undo support). This is perhaps a problem. But then I think we need to figure out what our editor story is. If it is that the java editor is the official editor, these bugs should be reported and fixed up. I do agree that the fact it is in java and not C probably doesn't help things a great deal in terms of java competency of some of the programmers (me included). The thing with this is that currently all distro packages are called crossfire-client or crossfire-client-gtk. If I am on a debian (or similar) system and install a program, I always try and run it using the name of the package, only if that fails do I bother to grep the filelist for bin/, sometimes if it is something I don't care about, then I ignore it and find something else to do the job instead. having the binary being tab-completable from the start of the package name is a good thing, especially when the .desktop files aren't installed properly. Have to admit, I've not looked at what other packages do in terms of program names vs package names. Perhaps have a generic crossfire-client script that looks for the different programs and tries to run the 'best' one available. I'd be interested to know how 'best' would be determined there. Probably basically in this order: gcfclient (still most complete) gtkv2-client (not complete, but still usable, and probably more complete/featureful than) cfclient - last resort really, and it doesn't provide much in the way of UI, and I think is still limited in terms of graphics and map size. ___ 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] renaming binaries
Check the CVS logs. I have stopped committing about a week ago. If you remove crossedit I will not restart. --- Mark Wedel [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I seem to see this ultimatum almost once a week now (do this or I leave) This carries no weight for me. I'm not going to program and make changes based on what one person demands to be done. Maybe you are the one that needs to fork off crossfire for your own use so you can do whatever you want with it. ___ 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] renaming binaries
Lol. --- todd [EMAIL PROTECTED] wrote: I suppose this would be a nice perk and a big incentive to remove crossedit, but you've quit so many times before that it just isn't a reliable enough promise to base a decision like this on ;) Miguel Ghobangieno wrote: Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff [EMAIL PROTECTED] wrote: ___ 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
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
