Re: [crossfire] Classes
On Thu, 27 May 2010 22:03:50 -0700 Mark Wedel mwe...@sonic.net wrote: For starting skills, should skill tools be done away with (eg, talismans, holy symbols?) My take, which may be wrong, is more often than not they are annoying/disliked, and I'm not sure what is really gained by having them vs giving the characters the native skills. Thoughts? I'd agree with the skill tools bit, mostly they are just clutter in my character's inventory until I find a 'proper' skill scroll (which I would typically buy anyway because they are cheap enough). Maybe talismans could remain as a form of amulet that gives a skill boost to the spell schools in question? If they were made rare enough*, then this would be a way to make it much easier to 'start' a wizard-style character. Give a talisman as starting equipment to each mage that increases the effective level of their skill by 3 levels (probably capped at level 15 or so). They would then immediately be able to cast 4th level spells whereas non-specialists are forced to start with first level spells. If the first area of effect spells are made available at levels 3 or 4 then it will be very slow going for anyone who isn't a wizard by trade. * with appropriately high-level quests which fighter-style characters could attempt when they are strong enough to think about generalising. Related to the skills discussion, maybe sense magic sense curse skills go away, and instead become special bonuses of praying and wizardry skills? Or maybe they should just become an extension of the identification skills? So if I have an enchanted sword and use my smithery skill on it, there are three possible outcomes: 1) I fail completely and think it is a mundane sword. 2) I know there is something magical about it but don't know what. 3) I find out everything there is to know about it. If the skill is lacking, then you could still have an unmodified roll against INT and WIS to try and determine 2. Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Attributes/Stats
Sorry, just noticed that my reply to this originally was sent to the wrong place On Wed, 12 May 2010 23:49:31 -0700 Mark Wedel mwe...@sonic.net wrote: On 05/12/10 03:58 PM, Brendan Lally wrote: On Wed, 12 May 2010 19:11:14 +0200 Nicolas Weegernicolas.wee...@laposte.net wrote: Never saw any response, but had some other musings. Changing subject to use attributes, since that is a bit less general than statistics, which can mean almost anything. Related, Brendan started a page at http://wiki.metalforge.net/doku.php/user:cavesomething:possible_stat_values listing ideas for combat rewriting. Under the kind of idea I was describing there, then stats like Pow, Wis and Int could give bonuses to different resist points (including negative resistances). I've described that in more detail at: http://wiki.metalforge.net/doku.php/user:cavesomething:resistances (this page is linked to from the one Nicolas referenced above) Hopefully a fighter character would think twice about putting 1 in INT or WIS if it guaranteed double or triple damage on almost every magic attack used against them. The one issue I sort of see with that is a lot of times fire/electricity/cold are not magical in nature. So use int/pow/wis for a resistance on them seems a bit misplaced. Yeah, I can see why that'd be the case, I guess really it is a question of balancing what makes sense with what makes the stats work sensibly, it might be that part of the answer to that is to alter some attack types for existing weapons/spells etc. However, problem in that case is that if say fire is Dex, and magic is Pow, if I have a 20 dex and 1 pow, that is the same damage as if I have a 11 dex and 10 Pow. If I'm a fighter type, in that case, I'd probably still like the high dex/low pow - result is the same, but high dex would help me out more the rest of the time. Could do something like the geometric rather than arithmetic mean, in that case, the 'average' of 11 and 10 is still roughly 10 1/2, the average of 20 and 1 is 4 1/2 (substantially worse). If that isn't an extreme enough effect, could use the harmonic mean, that would really punish having uneven stats. However, that table is interesting, unfortunately it does no represent all the stats very well. Cha still has no role. Yeah, I don't think that's anything like a final table, and certainly don't think it's properly balanced for the attack types that are in use. Probably there needs to be some proper analysis done of the monsters currently in the game (don't know if CRE can help with that - something like total damage dealt by type for all instances of all monsters in all static maps would give a good idea of the relative importance of each attack type for the player). With that, I would make some general changes: Magic: Pow Or maybe separate magic attacks into arcane and divine magic, with one based on the average of Pow Int the other Pow Wis? (This'd require *lots* of item changes, but then so would most everything else item-related). Fire/Cold/Electricity: Dex (on idea nimbleness avoids damage). I The reason I avoided using Dex mostly is because it is tied to the idea of armour class. The full description of how I would redefine combat is on the first wiki page linked above, but the short version is: 1) Roll an attack number (based on the object doing the attacking) and a defence number (based on armour class) 2) Consider a hit when the attack number is greater than the defence number. 3) Then damage is scaled to the ratio [attack-defence]:[resist points] Under such a setup then a high dex gives a higher armour class which should typically increase the defence roll, and reduce the number and 'strength' of the hits that are taken. (and this would be true for all attack types) Actually avoid damage from them once a hit is scored, should probably be based on another stat (otherwise Dex counts twice). Drain, Turn Undead, Fear, Death, Life Stealing: Cha - you resist the effect from happening. Ok, those are probably attack types where Cha could be made to matter, (although there might need to be some lore changes to justify some of those in game-terms) Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Attributes/Stats
On Thu, 13 May 2010 22:51:55 -0700 Mark Wedel mwe...@sonic.net wrote: Exactly how potion improvement works is a bit different discussion. One thought is a characters first 10 potions are sure to work, and potions after that have some reduced chance (maybe -10% for each potion, so potion 11 is 90%, potion 12 is 80%, etc, to a minimum chance of 20%). These numbers could be adjusted for what is considered appropriate (number of potions sure to work, reduction in probability, etc). Currently, improvement potions are useless once a given number have been used and level array has been met. One suggestion for how to handle improvement potions which wouldn't have that issue, is as follows: Firstly, don't roll primary stat improvements, simply generate them to always be the same, (so something like gain (Con/4) HP/level, (Pow/7)+(Int/7) SP/Level, (Wis/7)+(Pow/7) Grace/Level With plus 1 when remainder level% (4 or 7 as appropriate)) Those figures may well need adjusting depending on how many stat points are available in practice, and it may be worth defining a starting bonus, so level 1 characters aren't extremely weak. I am thinking of two effects: Firstly, there are the h/s/g points that the player has, and the points they would have if their stats had been high all along - So for example, If I play a level 1 character with 6 Con, reach level 10, then boost up to 14 con, I would have 20 less HP than if I had started with 15 con. Improvement potions could then rectify the gap there, so boosting the primary stats as though the gain were retrospective. - This would mean that any time a player gained a stat, they would want improvement potions. At high levels, (say when a player is level 80-odd and gained a stat), they would want /lots/ of improvement potions. Secondly, at every level up, have a bonus 1 HP/SP/Grace that could be gained, store this as 'potential Max HP/SP/Grace' (probably as an extra living struct on the player) and then when an improvement potion is used, have a chance (based on how much potential has already been granted) to transfer 1 point of potential Max HP/SP/Grace into 'real' Max HP/SP/Grace. (use the current potential 'current' HP/SP/Grace figures to store the amount that was transferred)). This removes the need for the level array tracking and gives pretty well defined results for characters, there is never any need for luck in character development, and boosting Con later rather than earlier is not much worse in the long term (other than affecting how many improvement potions are needed). Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Attributes/Stats
On Wed, 12 May 2010 19:11:14 +0200 Nicolas Weeger nicolas.wee...@laposte.net wrote: Never saw any response, but had some other musings. Changing subject to use attributes, since that is a bit less general than statistics, which can mean almost anything. Related, Brendan started a page at http://wiki.metalforge.net/doku.php/user:cavesomething:possible_stat_values listing ideas for combat rewriting. If one looks at these descriptions, one can see that spellcasters have a tougher time on stats than fighters - for fighters, pretty simple - Str, Con, Dex, Cha, Wis, Int, Pow, and the last 4 could be 1 and it wouldn't hurt the fighter much. What about rebalancing by making Wis or Int more useful for fighters? Something like 'your armor will communicate to you if you're intelligent enough, to help you more'. Or some way to make fighters pay if they have too low Wis or Int or Pow. Use Pow to resist some attacktypes? Under the kind of idea I was describing there, then stats like Pow, Wis and Int could give bonuses to different resist points (including negative resistances). I've described that in more detail at: http://wiki.metalforge.net/doku.php/user:cavesomething:resistances (this page is linked to from the one Nicolas referenced above) Hopefully a fighter character would think twice about putting 1 in INT or WIS if it guaranteed double or triple damage on almost every magic attack used against them. Brendan signature.asc Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest system - Error reporting needs work
On Mon, 10 May 2010 22:45:03 -0700 Mark Wedel mwe...@sonic.net wrote: Since the quest system (and some other core functionality) is using python/other plugins, should the configure check be changed so that configure errors out if the python libraries are not available (eg, will be unable to compile the plugin) I think I would prefer that to happen, or at least require it to be specifically disabled if the server wants to run without it. (ie if a server admin wants to run ./configure --without-python, then I'd consider that to be ok, they can either ignore breakage or disable/replace maps. I don't think knotwork is making much use of python in his crossciv mapset for instance) Most of the plugins add functionality that is not 'core' (for lack of better term), but I would put quests into a core functionality area (especially if these replace the mechanisms currently in the game that do not require plugins). As it is, even ignoring the quest system, there are a number of maps in the standard set that don't behave sensibly without python - the mad monk in scorn, the banking system and the post offices are all obvious examples. Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest system - Error reporting needs work
On Fri, 7 May 2010 02:05:16 -0500 Kevin Bulgrien kbulgr...@att.net wrote: I tried to play test some of the new quests tonight and nothing worked. None of the dialog paths did anything. I could not get past go. Having looked at this a couple of hours ago, the token check I had was bad, and failed with multiple token options, this was a regression caused by my breaking out the dialog actions into separate files and I've now fixed this. It isn't something I hadn't picked up before because not many dialogs use tokens in that way, thank you for reporting it. Something needs work. So digging around, I find: python/dialog/dialog_check.py I decide to see what it does: $ python python/dialog/dialog_check.py scorn/kar/gork.msg Traceback (most recent call last): File python/dialog/dialog_check.py, line 11, in module import cjson ImportError: No module named cjson When you run the npc_dialog script as part of the server process then it runs through the cfpython plugin which includes cjson as part of the source tree, it gets be compiled at the same time the cfpython plugin is (if it weren't you'd see a similar message in your server output) This doesn't add cjson to the normally available pool of python libraries, so running the dialog_check.py script would require that you have cjson installed for python normally. (there isn't really a good way around this as far as I can see, from the maps/ folder there isn't a clear idea of where crossfire plugins are installed - I suppose crossfire could install cjson globally, but that will probably cause more problems than it would solve). Ah... Yeah, that should be reported to the server admin as a major error. If the quest system is going to start depending on this, then packaging, etc. needs to make sure people know what is required to get basics of the game operational. So in my case, the package is probably python-cjson... The dialog_check script isn't really part of the basics of the game, it is a tool I've created for my own purposes while writing dialogs which others may find useful too, anyone who isn't a map-maker writing npc dialog shouldn't need to care about it (and anyone running into characters with dialogs should find that the cfpython version of json works correctly). So then I wonder if the player shouldn't also be told too... There may still be a question around player feedback on errors, I'm not sure what the best way to approach that is, mostly because it is sometimes difficult to define what an error is - in some cases having no matches to a set of rules is a bad thing, in others, it might be fine. Let's try again... :-) # urpmi python-cjson [trunk]$ python python/dialog/dialog_check.py scorn/kar/gork.msg Error: No script to support action: settoken Expected: post/settoken.py ERROR: verification of action file post/settoken.py failed for rule 1 condition ['settoken', 'gork_speak', 'hoard'] ... Gaack! [trunk] cd python/dialog [dialog]$ python dialog_check.py ../../scorn/kar/gork.msg checked 9 rules from file ../../scorn/kar/gork.msg Found 0 errors and 0 warnings Ok... Umm... its a computer. Can't it figure out where to look for its stuff? It's only relative path... Yeah, that script does still need a bit of work in terms of figuring out where to look for things. (as well as extending the checking to verify that named quests exist, etc), I've committed it now because it is still a lot nicer than trying to navigate through maps to where a character is found, trying to speak to them and finding that there was a typo in the .msg file. Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Pickup Drop Event expansion
Hi All, Quite a minor patch this, but one that has an impact on script/map compatibility, so I figure it should probably go here. https://sourceforge.net/tracker/?group_id=13833atid=313833 This patch changes the meaning of the return types from event_pickup and event_drop. The initial motivation for this was in developing an implementation of draughts (something which is still at quite an early stage) and needing to be able to prevent an item from being picked up under certain conditions (ie by the player playing the other colour). The current behaviour of event pickup isn't helpful for this because the item disappears if the pickup fails. So what I have done is altered the meaning of the return values, rather than 0 meaning 'item may be picked up' and non-zero meaning 'item may not be picked up' I have 0 meaning 'item may be picked up' negative meaning 'item will disappear rather than being picked up' and positive meaning 'item will stay where it is' Because picking up and dropping items are opposing actions, it follows that they should have the same relative meaning for their return types, hence event_drop is altered too. The only immediate effects of this will be to give a cleaner way for QuestEssentialUntil.py to handle item dropping (returning negative and writing a custom message rather than setting start equip and showing the default 'the gods who lent it to you' message) Although I think navar_midane_pickup.py might need amended also, and possibly also cf_darcap. Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] skill window
On Tue, 20 Apr 2010 00:18:27 -0500 Kevin Bulgrien kbulgr...@att.net wrote: I imagine that the intent was to set up some kind of feedback mechanism to help client development. Pretty much, and also allow a way to determine if there is a desire for new layouts to be created (the point of making the wiki comment that I did was that if there was anyone who thought along similar lines, then that would give me sufficient reason to create it). I do hope to move along and be over with this, Absolutely. I'm sorry that a lot of this discussion has generated more heat than light, and I wish to apologise for the role I have played in that. In retrospect I should have asked the 'how are client layouts being updated now' question and then left the 'how can client layouts evolve and be maintained over time' issue for another thread at a later date. I am also now of the view that my earlier proposal was over-engineered. I will be more than happy to rework a .glade to your specifications, and plan to do so based on what I saw on the wiki. I appreciate the offer, but please don't feel like there is a need to do so for my sake. There are lots of UI changes that ought to take place over the next few months in order to make it easier to use some of the existing game features, and these may well require additional thought in terms of how an interface layout should represent them. As such, it is likely that my local copies of the glade files will end up being a bit of a mess as I test things. To give you some idea of what I am thinking of: Medium term (ie, after the next release) I am looking at: * A 'knowledge browser' that doesn't involve typing in numbers to recall knowledge (preferably one that is ordered into categories, and somewhat crosslinked - ie, clicking an ingredient in a recipe should show you a recipe to make that ingredient if you know one). * A 'quest log' that will show information about current and completed quests. As I'm thinking currently, these might go into the 'player' menu, Longer-Term I am also thinking in terms of: * A nicer interface to the 'who' command, so that it brings up a list of players and allows 'tell' commands to be sent more easily (without typing in an (often difficult to spell) player's name) Possibly there could also be additional controls exposed for dms, things like muzzle and kick. * And then additional things like toggle buttons the 'obscure but useful commands' such as brace, bowmode, peaceful, afk, etc. I still don't really have a clear idea of where any of those could fit interface-wise, so that's something I'll be looking to discuss in more detail. Ultimately I want to be able to reach a point where: * it is possible to play crossfire without needing to type anything other than to chat with other players/NPCs. * None of the command-based functionality is lost since that gives a lot of power to keybindings (I just don't want to *need* to use them just to play the game). * The interface doesn't become cluttered. There would be times where these three aims would be in conflict, so I would welcome any discussion/thoughts on the most effective approach. There is a separate discussion to be had around creating more default keybindings for the client. The current approach is to explain right at the start of the game how to bind commands to keys, my view is that this is an intermediate/advanced topic, and shouldn't be something that a new player should want or need to care about until they are a few hours into the game. Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Auto ID on examine
On Sat, 17 Apr 2010 13:00:24 +0300 Otto J. Makela o...@iki.fi wrote: Brendan Lally wrote: This changes the way the examine command (triggered by left clicking on an object) works so that if the object is unidentified, and the player has the appropriate skill, then an attempt to identify the object is automatically made. The intention is that this should make the ID process much smoother for new players, and less likely to be discovered after wasting money on ID tables or selling items that were useful. This does change the overall game balance a bit (making it easier to use skills automatically), but all-in-all I think it is a good change. I'd like to think that the change to game balance is only for the first few levels and only because with the current behaviour new players may lose money because they sell items before identifying them, or pay to identify items which they could have IDed for free because they had the appropriate skill to identify them. I'd consider such behaviour to be a challenge posed by the interface rather than the game itself. The flipside is that a player who would want to 'scum' exp by identifying a huge stack of arrows individually using a keybinding or script might accidentally click on the stack and 'lose' the exp they would've gained. I'm not sure that sort of behaviour that should be encouraged or rewarded though - even if I have done it myself in the (distant) past... Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] skill window
On Fri, 16 Apr 2010 18:30:56 -0500 Kevin Bulgrien kbulgr...@att.net wrote: http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates Where these responses can be collected. The other advantage of this approach is that if no verdict or comments are given after a month or two, then it is probably safe to consider that layout unused and unloved, and then to consider it for exclusion from future releases and ultimately removal from the SVN repository. Surely you jest. Just how often is the quantity of wiki edits / month or two an accurate sampling of the entire crossfire player population's views on anything? I'm hoping the answer to that is, 'when there are a number of mailing list, IRC and forum posts inviting, with ever escalating persistence, an expression of such views. That probably means up to 4 mailing list posts forum posts + at least that quantity of IRC discussions which follow the following form: 1) There is a proposal to change layouts, can all layout owners/maintainers give their verdicts and interested users give comments. [2-4 weeks later] 2) Please give all comments and verdicts to the layout change proposals in the next 2 weeks, the following layouts are lacking any response: the following layouts have comments but no owner verdict. ... [2-4 weeks thereafter] 3) The following layouts have not received a response from the owner/maintainer regarding the change n. ... Please can any commentators who wish to take over maintenance of these layouts contact the mailing list. [2-4 weeks thereafter] 4) The following layouts received no response at all to the proposed layout change n, ... and are now considered abandoned, they will be removed prior to the next release. There may also be a case for a crossfire-announce posting to be made in the lead-up to a release, probably a couple of weeks beforehand so that there is time for anyone who doesn't read the main mailing list to yell. (Although then you might question how much such a person really cares about the ongoing development of CF, and if they would really notice). The overall aims here are: 1) That the number of layouts remains fewer than the number of players, preferably substantially fewer. 2) That the majority of players using the majority of layouts should benefit from work being done on client changes, unless they are deliberately choosing layouts which are designed not to. My view would tend to be that if: * There is a layout currently that is intended never to be updated, * It is for the use of a single individual, who has decided that it is perfect as it is Then that shouldn't be in SVN, and shouldn't be a choice in the client as it is distributed by default. By all means keep a backup somewhere globally accessible, along with instructions for using it with a client, but for someone new to CF, who discovers the layout selection widget for the first time, they should expect that the selections they choose from correspond vaguely with the documentation that they will read, and not have something which is hugely different (other than in the ways that are a design feature of the layout) The case of an underused layout where there is a desire to see it actively maintained is a different matter, I'd hope that all the current layouts fall into this category, and the only question is over how to implement such maintenance (if at all). Obviously if there are vastly differing and strongly held sentiments in terms of what should be done for any given layout, then that makes the case for creating another new layout. If no one cares to express such views over the course of several months, the conclusion must be that they are not strongly held. Brendan. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] skill window
On Thu, 15 Apr 2010 22:17:24 -0500 Kevin Bulgrien kbulgr...@att.net wrote: Questions: 1) Can the skills and experience pane now disappear? Other layouts might be other player's favorites, so making sweeping changes seems to take some extra thought about who it affects. Ok, so taking all of that, then it is even less clarity over who can 'bless' a change to a layout, particularly if the author of a layout isn't the same thing as a user. Because there are multiple respondents, giving different verdicts, the mailing list probably isn't the ideal place to try and collate those, so I have created a wiki page: http://wiki.metalforge.net/doku.php/gtk-v2_ui_updates Where these responses can be collected. The other advantage of this approach is that if no verdict or comments are given after a month or two, then it is probably safe to consider that layout unused and unloved, and then to consider it for exclusion from future releases and ultimately removal from the SVN repository. Obviously if there are vastly differing and strongly held sentiments in terms of what should be done for any given layout, then that makes the case for creating another new layout. icons for all of the skills (implemented by sending a face number along with the reply_info skill_info response) Its fine, but I'd note that graphics blows out the vertical space requirements, so some consideration might be given to allowing them to be turned off or made quite small so as not to expand every line. The thing I like about your dialog now is that it is pretty tight and readable. I'm not really sure that I see a lot of value in skill graphics myself except as eye candy - which tends to aggravate things if you happen to have a really small monitor, but can be nice if you have screen real estate to throw away. Ok, I can certainly see that point, OTOH there are 44 skills and it is a scrolled window which is sortable, a few of these are mutually exclusive anyway, and a couple are switched off, so you are probably looking at not more than 40x32 pixels = 1280 pixels For many players on modern systems, that entire list probably fits on screen or very close to it, for the rest, then sorting by level is probably going to show them the skills they care about anyway (after all, when was the last time you gained jumping experience?) The 'character' pane on the client to show the icon for the skill rather than the name, and clicking on the icon to trigger the callback for the skill window in the same way that the menu entry does. Not sure I know what you mean by the 'character' pane. If you mean the core stats, I'm not in favor of the text version of the readied skill going away on all the layouts... but maybe I'm not groking what you want to do. Whereas some people like pictures, I tend to like text for that. I think graphics are ok for fairly static things like button bars, but I would find the readied skill shown only graphically to be frustrating. That is what I meant, I can see why you might not like that, so maybe it is something that should be altered on a per-layout basis. Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Auto ID on examine
Hello all, Just wanted to get some opinions on the following patch: https://sourceforge.net/tracker/?func=detailaid=2988536group_id=13833atid=313833 This changes the way the examine command (triggered by left clicking on an object) works so that if the object is unidentified, and the player has the appropriate skill, then an attempt to identify the object is automatically made. The intention is that this should make the ID process much smoother for new players, and less likely to be discovered after wasting money on ID tables or selling items that were useful. Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] skill window
On Wed, 14 Apr 2010 22:59:43 -0700 Mark Wedel mwe...@sonic.net wrote: On 04/14/10 12:10 PM, Brendan Lally wrote: The aim is to enable access to all of the skills that a player has without needing to type anything. (I would expect that sooner or later, a player will want to bind use_skill praying to trigger a dozen times per press of a hotkey rather than clicking repeatedly, but if that is something that the player only needs to think about after playing the game for a couple of weeks rather than on the first day, then I'd consider that a win) One could make a compelling case that it shouldn't be necessary for the player to hit the same skill 50 times, but that is a more significant change (although one way could do it is some setting which basically has character doing the same activity under another command is entered, eg, character keeps playing until player hits some other command like north). That could probably be implemented reasonably easily with a server-side command, so you would have a syntax like 'repeat [command you would normally issue]' Then if the server stored a 'repeat command' then when the server comes to process the command stream from the client, if it is empty, it would use the 'repeat command' stored against the player. if it is not empty (a new command has been given) then it would clear the 'repeat command' string and process the new commands instead. Client side, there would probably want to be a stat that is sent to say 'I am current doing your repeated command' so that the player knows when they are no longer praying/searching for traps/etc Might be necessary to mark a few commands as unrepeatable, since they don't really make sense to run multiple times (quit would be an obvious one) Questions: 1) Can the skills and experience pane now disappear? Yes, I think so. 2) If it goes, should character, protections and core statistics move into the same pane? (so one pane with 3 tabs rather than 2 with 2 each) This seems to be a layout specific issue - so there isn't a simple answer. For example, right now the gtk-v2 layout has a stat area (where the hp, sp, etc, bars are) and another area which right now has 3 panes - core stats, skills exp, protections. I don't think there is any clear/best answer here. If you have a large/wide window, have 2 pane areas half the width may be more useful than one pane that is the entire width but of of which most is just blank. ok, so it probably comes down to being a question for the creator/maintainer of each of the layouts. I've left them as they are for now (other than adding the menu entry) it does mean that the information is duplicated, but that's not a huge problem. *The following are things I would like to add probably during the next release cycle or the one after: Columns showing the keyboard shortcuts for the skills (ie looking for shortcuts for use_skill or ready_skill) - not sure whether those should be settable there, since that treads on the task of the Keybindings window a little IMO, settable there would be good. Likewise, letting the player do spell binding in the spell window might be handy. Yeah, although with spells it is probably a bit more complex because they have options that can be passed to them My thought on this is that right now, the keybinding window is a bit archaic - you basically need to know the syntax of the command you are going to bind - hardly a simple/beginner thing. But for skills and spells, the client knows what the command is, so can provide a nicer interface, something like the player selects the skill, then hits a 'bind key to skill button', and it pops up a window or something and says 'press key you want to use to have this skill used when you activate it', and all the player has to do is hit a key and maybe something like a confirm button (or maybe a bind to ready or a bind to use type thing). That's more like a 'hot-key' setup That's much better than having players have to know that they need to do a 'user_skill praying' syntax in the bind window. Yeah, my inclination would be to say that the more advanced bindings should still be possible, but that simple bindings should be simple to set up icons for all of the skills (implemented by sending a face number along with the reply_info skill_info response) Yes - that would be nice. I'm not 100% sure if there are currently suitable faces for all of the skills however. Most of them don't have any faces at all currently, I'm hoping there's someone who'd be prepared to draw them. The 'character' pane on the client to show the icon for the skill rather than the name, and clicking on the icon to trigger the callback for the skill window in the same way that the menu entry does. I'm not sure if I'd want the window to pop up, or just clicking it causes it to do the skill - I think the later may be more useful in most
[crossfire] skill window
Hi All, As part of an overall aim to make the cf client a little more user-friendly, I have created a patch to add a skill window to the client. This may be found here: https://sourceforge.net/tracker/?func=detailaid=2987308group_id=13833atid=313833 The aim is to enable access to all of the skills that a player has without needing to type anything. (I would expect that sooner or later, a player will want to bind use_skill praying to trigger a dozen times per press of a hotkey rather than clicking repeatedly, but if that is something that the player only needs to think about after playing the game for a couple of weeks rather than on the first day, then I'd consider that a win) There are a few things I'd like to add at some future point* but for now this is complete. Questions: 1) Can the skills and experience pane now disappear? 2) If it goes, should character, protections and core statistics move into the same pane? (so one pane with 3 tabs rather than 2 with 2 each) 3) Is there time for either or both of 1 and 2 to occur before the release of 1.50? (and when is that taking place?) *The following are things I would like to add probably during the next release cycle or the one after: Columns showing the keyboard shortcuts for the skills (ie looking for shortcuts for use_skill or ready_skill) - not sure whether those should be settable there, since that treads on the task of the Keybindings window a little icons for all of the skills (implemented by sending a face number along with the reply_info skill_info response) The 'character' pane on the client to show the icon for the skill rather than the name, and clicking on the icon to trigger the callback for the skill window in the same way that the menu entry does. Brendan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [CF-maps] Sprite Recolouring
On Thu, 01 Apr 2010 22:00:25 -0700 Mark Wedel mwe...@sonic.net wrote: On 04/ 1/10 05:46 PM, Brendan Lally wrote: 1) Are recolours worth adding as a way to increase variety of NPCs? For NPC's, I'm not quite sure about. However, for PC's, this could certainly be interesting (provided we have a way for players to choose this). But I'd also say that more diversity is seldom a bad thing. I started off with NPCs for two reasons: 1) there are a lot more of them than there are players 2) they can be changing them in the map files requires nothing more than using sed appropriately. I was also looking at creating the png file directly in the arch/ folder, so that none of the server-client interaction was affected. I'll carry on with writing some C code to handle palette extraction and substitution, since if it isn't used, it may form the basis of a client patch if it is decided the client should redraw PNGs. What you are describing now is potentially much more powerful, although also more complex. I've copied in the main CF dev list because that is more a server-client discussion. 2) does the answer to question 1 vary depending on how they are implemented? (lots of different PNG files, or a script to rewrite the palette entries of a single png file, maybe as part of the collect step) Would it/how hard would it be for the client to do this coloring? Yes, some mechanism to convey this extra information would be needed, but on the plus side it means that the client doesn't have to download a bunch of images that are the same except for a different color palette. Also, depending on how this is done, it actually provides for a lot more potential images (realistically, there is probably some upper limit of number of different colored versions of the same image you want, but if in the client you convey a 256 color base (3/3/2 bit rgb values let say), and have some way to specify that in the arch, you now provide a huge number of possibilities. And if you want to let the full 24 bit values in (figuring extra few bytes of bandwidth is not an issue), you now have endless colors. I think there are several possible approaches here: 1) a different face number for each image. = This involves very little change to the server/client interaction, since they are just more face numbers. However it is inefficient, because the image data is sent each time, and the number of faces potentially spirals out of control. 2) a palette number associated with each face, so that the palettes are sent separately = this is more efficient than 1, and less so than 3. You also would need to extend the map2 command to send the palette varient. = the least distruptive way to do this would probably be to have a 5 byte variation on the image information, so that the options then become: 2 bytes: This is only the face number. 3 bytes: face num[smooth|animspeed] 4 bytes: face numanimspeedsmooth 5 bytes: face numanimspeedsmoothpalette variation there would also need to be some either some extension to image2/creation of image3 in order to send the palette variations ahead of time, or a separate palette command Client side, the clients would need to hold the alternate PLTE sections of the png files and substitute them in depending on the palette variation they are sent. This could be quite quick if the variations are stored in an array associated with the face but it would mean a fair bit of custom PNG mangling. For the C client, this shouldn't be too bad, I don't know what that would be like for 3) Try to send the individual colour substitutions. While this would be potentially more efficient, it also causes a question of how to store them sensibly, I can't think of a coherent design for this at the moment. This clearly changes the logic for the client - it would need to color them real-time in that case (for 24 bit values). Conceivably, for 8 bit values, it could just set up an array and fill that in as it actually needs, and even in worse case, on modern systems, probably not a high burden on memory (and if done on the client, the client could perhaps choose not to even do that coloring to save memory or reduce the palette to 16 colors or something). But I have no idea how hard it would be to do this on the client - I would suspect that some form of standard for the images would be needed. Yes, I'd suspect at a minimum, the existing images would need to be re-indexed less efficiently (so that for example colours 1-10 are hair colours, with 1 being the highlight colour through to 10 being the darkest shadow in the hair. 11-20 skin tones 20-25 facial features (nose, eyes, mouth) 26-35 torso 36-45 lower body 46-50 feet/shoes 51-60 weaponry (if held) 61-70 headwear and so on. Not many images can conform to something like that currently, and it would bloat the PNG files to include what would be in many cases duplicate colours (eg, the blue of a cloak may be the blue of the eyes
Re: [crossfire] Quests with multiple outcomes
On Tue, 30 Mar 2010 20:55:36 -0700 Mark Wedel mwe...@sonic.net wrote: On 03/30/10 10:20 AM, Brendan Lally wrote: quests: 1) 2) 3) Down to the docks: a) Port Pass b) Scorn Password c) The Hero of Scorn 4 ... etc and then the info section would say: snip Yes, that makes a lot of sense - it sounds like the solution to what I said above was to do sub quests, but I'd really not want to see a huge list of quests which are really subquests and have no value on their own (in my example above, fetching a baz only makes sense as part of talking to foo). There is really a trade off here, the choice is between having the smallest possible number of really complex quests, or a greater number of simpler quests. My instinct is to go with the simpler individual quests, because they are a lot easier to build and test in isolation. That makes sense. And really, single big quests vs many small quests is a server mechanic - if they are presented to the client in a cohesive fashion (so those 12 subquests appear as steps of a big quest), that is great - you don't need to have the big quest have those 12 individual steps. My main concern, beyond it being managable from a map designer standpoint, is also have some way to make them cohesive for the players. It would seem to me in such a system, you'd need the following information for these subquests: - What part of quest are they (parent quest) - what quests do these open when completed. In terms of what the player sees, I think it will suffice to show them a two level hierarchy. The subquests would probably be called 'objectives' or something similar in the client. The default behaviour then would be to only show the active subquests, not the completed ones Any occasion where there are more than two or three nested layers of subquests for one quest probably indicates a need to rethink how the quest is defined, or to split it up into a 'chain' of top-level quests. One thing I do want is hidden quests and quest steps, simply because for many quests, it will be easier to change the state of the quest rather than use markers, and there is a value to suppressing some status changes. (eg, there is one I am looking at where there are a number of monsters around a leader, if one of the monsters is killed, I want to close off a peaceful resolution with the leader, so easier to set the queststate to $bignum rather than track a marker in the dialogue). I think the generic thing to do this is to have a 'parent' marker in the child quest file, and allow each stage of any quest to conditionally advance any other. ie, quest scorn/TerrysFarm step 30 advancetarget scorn/DisputedFarm advanceif 0-5 advanceto 10 so that setting the terry's farm quest to state 30 should advance the disputed farm quest to step 10, but only if it is already between steps 0 and 5 (so if it is at step 7, or 20, nothing happens) Obviously, it would be considered bad form to update another quest without there being some story-line reason for doing so. For example, one could have a quest that has 6 different steps, and they have to be done in order (doing step 3 before step 2 doesn't make sense). But you could have other quests where several of the steps could be done in parallel - a simple example could be alchemy quest - you may need to get 5 materials for the recipe, but what order you get them in doesn't matter. I'm not sure how this later one is handled in the system - the step to go to alchemy master with cauldron shouldn't open up until all 5 of those subquests are done. This could be done with a hidden quest and lots of combinations of steps, but I think the more sensible solution would be to check the 5 subquests for completion in a dialogue. (so the dialogue script would check all 5 quests are completed before causing the connection on the map to be triggered. One of the things I will be doing very shortly (ie, the next time I change the quest file definition after the release) will be to break the default.quests file into lots of smaller files. I was going to use the region file to specify these, so that quests then become attached to a region of the game world as well. Makes sense - ideally, .quest files could sit anywhere in the map tree, but that would make it trickier for the server to find them all. But one could imagine that in some cases, a quest may relate to a small set of maps (already located in its own directory in the maps tree), and keeping the quest near there would make sense. I wonder if rather than regions file, if maybe adding something like #include directives into the the default.quests would work? Server would then just process those and load all quest files. It should only need to do this at startup, so shouldn't add much to load time, but gives maximum flexibility. The reason to want to tie them to regions, is to give an idea
Re: [crossfire] Quests with multiple outcomes
On Sun, 28 Mar 2010 21:03:33 -0700 Mark Wedel mwe...@sonic.net wrote: On 03/28/10 06:19 PM, Brendan Lally wrote: snip quest scorn/PortPass title Port Pass description Acquire a port pass to be allowed into Scorn's docks. end_description stopstep 20 restart 0 step 10 description The guards told me that I could acquire a port pass from the Office for Gate Passes. I should try asking there. end_description end_step step 20 description I have purchased a port pass to allow me into Scorn docks end_description end_step step 30 description I have found a port pass that should allow me access to Scorn Docks description end_step step 40 description I have found another way through the gate that leads to Scorn Docks. end_description end_step end_quest Here then, the 'stopstep' is 20, and the steps 20, 30 and 40 are all steps that complete the quest, but in different ways.* So just to be clear - in this case, it means that if the player somehow gets the quest state to be 20 (stopstep value) that the quest is done? This is correct. Rather than having the stopstep, for each step, would it be possible/better to have a keyword there to not that the quest is done? What I'm thinking is that for complex quests, there could be several paths, and it would seem clearer to me that for one path, maybe steps 20-25 dictate one path (with 25 being the finish point) and for another one, steps 30-38. For a map developer, it would be easier to have all steps for one path be together - better than having to go from step 24 to 40 to note the quest is done. The design of quests as things stand assumes: * Quests only progress forwards, not backwards * Once a quest is completed, then it is not un-completed (although may be restarted). Taking these two principles, anything that can be represented with finish points at different stages can also be represented with finish points all grouped together at the end. (Any path in a quest that could be completed multiple times will be something that should be implemented as a restartable sub-quest). There is a further assumption, that I have been working with, that bigger stage numbers = nearer completion. In particular, the script I have been using to handle dropping quest items has that assumption built in. The way to fix this is probably to change the meaning of the quest_was_completed command, and assume that most quest items should be kept for the entirety of the quest. (and that, if they shouldn't, then (as an aside, not related to the system but the example above, I think the quest description should more or less match - finding another way to the port area doesn't really satisfy the quest description of getting a port pass. If the quest was 'get access to the port area', then that would be fine - and in this example, it may be a guard telling the character that they can buy port passes) The reason for having the 'finding another way' description is because there are 4 quests that I have defined for the port gate, 1 for each of the three way of getting access, plus another one for the 'getting access' quest. The 'getting access' quest is set to complete once the player successfully walks through the gate any of the three sub quests which haven't been completed by that point are marked as complete to step 40 at that time as well (step 40 says something similar for all 3 of them). In this case, it is not so much that the quest has been 'won' but just that it is unnecessary now, finishing them all at the same time is a way to remove them from the active list. One of the additions I will want 'real soon' after release is an idea of 'parent' quests. That way, rather than listing all of the quests on the same level of priority, there would be quests and subquests, so the list would read: quests: 1) 2) 3) Down to the docks: a) Port Pass b) Scorn Password c) The Hero of Scorn 4 ... etc and then the info section would say: Down to the docks Description: There is a gate separating the main part of scorn from the docks. It is closed and the guards won't let you past. Current Status: To pass through the gates I need to get a port pass, find the password or become the hero of scorn. Perhaps one of the guards will tell me how I can do one of those things. Subquests: Port Pass Description: Acquire a port pass to be allowed into Scorn's docks. Current Status: The guards told me that I could acquire a port pass from the Office for Gate Passes. I should try asking there. Scorn Password Description: Discover the password that will permit passage through the gates in Scorn. Current Status: The guards have told me that there is a password, just
Re: [crossfire] Healthbars
On Sat, 20 Mar 2010 21:14:41 -0700
Mark Wedel mwe...@sonic.net wrote:
On 03/19/10 11:24 AM, Brendan Lally wrote:
The following is a proposed addition to the crossfire protocol to
enable the clients to show monster health bars.
Just a note, this was discussed several years back, and at that
time, there was concern that that 'gives away' information to the
player that perhaps should not be given away (how close a monster is
to death as an example, or fast regeneration).
I don't know if we still consider that a concern or not - I know
lots of other games show something similar, but is something I
thought I'd mention.
The overriding principle I have been working to is that what should be
presented is information that the player's character may reasonably be
expected to infer from looking at a monster, so if there is something
that has a direct visible effect on a monster, then the character would
know about it, so the client should, if there is no direct visible
effect, then the character won't know about it, so the client shouldn't
either.
snip
In order to implement this, the following is altered.
A setup command 'healthbars' is added, if a client request it with
argument '1' then the server will send healthbar information to the
client, if they do not, then there is no visible change.
[Possible expansion, if the setup flag is sent and
confirmed, expect that the client will ignore attack messages ('you
cut foo', 'you miss foo', etc)]
I'd have the player ignore attack messages be some option. While
for the most part, they are not needed, I don't know there are some
attack messages which you would care about (I'm not 100% sure what
all messages fall into the attack category). But dropping them all
could result in information not being displayed that is important.
The gtk2 client already has client message configuration, so it would
be a question of changing the default to 'off' for that type of message.
As it stands, there are a couple of cases where you might want to keep
attack messages, invisible creatures would be the obvious ones, because
they wouldn't get healthbars sent. - maybe the answer is to use one of
the subtypes of attack message to allow those ones to be kept and the
others to be filtered out?
The map2 command is extended to have another type of data that may
be sent. type 4 is a healthbar. There follow 2 bytes, the first is
the hitpoints as a proportion of maxhp, the second is the flags
that apply to the hitpoint bar.
I haven't looked in detail, but it sounds like this information is
now space specific (eg, this space has flags 0x02 and hp 0x40). Is
that correct?
Yes, the information is sent for the highest (by layer) ALIVE object
on the map square. - This does potentially mean that there are
creatures on lower layers that aren't displayed, but there probably
isn't a sensible way to display health bars for multiple creatures on a
square anyway.
The healthbar is sent for an alive creature that is either a
monster or a player. It is sent whenever a face changes on the
square, or always if the creature is below their maximum health.
The client should show healthbars until the information for the
square is updated.
I'm a little concerned about sending it all the time if creature is
not at full health. Maybe with modern connections, the bandwidth
isn't a concern, but there are still lots of maps with large mobs of
monsters - I could imagine them getting hit with a burning hands, and
now sending update for all those monsters every tick (while the 3
bytes for the data isn't bad, there are additional bytes needed for
each space to denote the coordinates, etc).
The other thing I have come across is that some maps seem to do odd
things with locked doors, I think it probably is useful to be able to
see information for them, but they seem to have their maxhp set oddly
and are getting sent a lot.
If this is a per space attribute, it would be better to cache that
data - both in the map structure itself (so fast to fetch) and in
socket structure that holds the player map.
In that way, server would only need to send data if it has changed
in any way.
Caching like that is a really interesting idea, the other thing this
does, if there are many players viewing the same squares, is mean that
the flags only need to be calculated once per tick.
Probably the place to store it is in the mapspace struct, then on each
tick update all the mapspace information for the maps that either have a
player on, or are loaded and linked to a map that does.
I would probably add, if other face information is being sent anyway,
then always send the healthbar because it is probably better that a map2
clear would clear the healthbars anyway (and things like newmap commands
should too)
The first byte has a value between 0 and 255, 128 means that the
creature is at full health, above that means
Re: [crossfire] reorganizing the entire world
Been a while since I played cf, so I will be commenting on the game as it played a year ago; but this is a subject I've touched on before in #crossfire, so I hope the following is helpful. On Thursday 14 June 2007 20:18:22 Juergen Kahnert wrote: What do you think about reorganizing the entire world to get regions for characters in a range of levels? For example the starting region has maps for character with level 1-5, than move over to a region for level 6-10 character, ... Every region should have a storyline quest which leads through this area. After the quest is solved, you're able to enter the next region and so on. The way I had thought of this before was in terms of a 'home town', that being the place where a character would store most of their items, and set out to quest from. In order to have a progression in the difficulty in maps, it is useful to also have a progression in 'home town'. For example: a player should start out in scorn, hang around there for a bit, visiting the other nearby villages before heading to navar, at high level establishing themselves in brest, before finally (maybe) moving into a guild hall. In order for that to work, there should be three things that are true. 1) it should be more useful to a mid-level character to live in navar than scorn 2) it should not be distinctly more useful (nor obviously enticing) for a low-level character to leave scorn (although they should be free to do so if they want) 3) the degree to which a character can be 'locked in' to having scorn as a home town, and thereby be discouraged from moving should be limited (probably there needs to be some kind of python-based house moving support to help there) The reasons why this didn't work last time I played; navar had a worse apartment than scorn, with less useful portals scorn had plenty of high level maps easily accessible. Brest had a portal leading directly there from scorn, making the approach quest meaningless (I don't see any changes to scorn apartment, suggesting this is still the case) In order to fix this then; Define the 3 major home cities (allow others, but assume the natural progression of scorn-navar-brest) in each city, have portals which go back but not forwards, (so navar to scorn, but not scorn to navar). Move some of the very high level maps from scorn and its nearby cities to navar (or brest) - for example, the entrance to pupland would probably move. Make the other apartments available at least as good as the one in scorn (changing the portal layout probably achieves most of that anyway). Move the guild hall purchasing place to Brest. From what I remember the game world looking like then, you would have a structure like Scorn ---Navar---BrestGuilds (maybe) || Euthville Wolfsburg Santo Dominion pupland (moved) darcap (hopefully that's vaguely readable to most people) So in this case then, a low level character could go straight to navar (they could try to go to brest and get killed en route as well), but they would find there wouldn't be much to interest them, that they couldn't afford an apartment, and they would probably leave to go back to scorn for a bit. The quest based progression could be interesting, for example if the reward for some intermediate stage of the scorn royalty quest was an invitation to see the mayor (or whatever it is, I forget the backstory) of navar (write it as a diplomatic visit or some such), who would send his own dragon to give a free ride there, then you get a strong indication that maybe your character is 'ready' to move ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
On 10/13/06, Alex Schultz [EMAIL PROTECTED] wrote: A few times, tracking the svn revision instead of the $Id strings has been brought up. IMHO this should be done, both in the client and server. I propose we implement it as follows in both: This version would both be used in the client for outputing to the console instead of the rcs-id values, and the server will use this version for reporting to the metaserver as well as console output. Does this model make sense to everyone? I'm not sure it is such a great idea to send the revision number to the metaserver, certainly not if the metaserver is going to push that information out to clients, in that case, someone who wished to be annoying could look for servers with revisions predating certain bug fixes or balance tweaks and abuse or exploit them. If you are talking about sending the revision as a seperate field to the metaserver, that isn't for propagation to clients. then that is a different issue altogether, and could provide useful information about things like how quickly updates are made available in practice. Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
On 10/13/06, Christian Hujer [EMAIL PROTECTED] wrote: Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). Oh that would make it easy for a bogus server to abuse or exploit known client bugs to hack client machines. I apologise if I was unclear on that point, I'm talking about sending the information to the /metaserver/, not the individual servers for the purpose of determining client version usage rates. Currently the best guess as to which clients everyone is running is based on connections to metaforge, but most of these people probably query the metaserver first (since that is default behaviour). It would be nice to be able to tell roughly what versions everyone is running in terms of addressing issues of backwards compatibility (eg, is anyone using 1.4 or 1.5 still, and is it therefore safe to break compatibility? or, if a serious bug is found, is it worth making a new point release for a version that the majority of the userbase runs?) Likewise if the interface mode (gtk2, gtk, x11) were sent, then there would be some usage statistics to base the questions about client design on. I am thinking of something to go alongside http://crossfire.real-time.com/metaserver/ that instead of listing servers would list summary statistics for the clients, eg In the last week there were x client connections of which y were from unique IP addresses from n different countries. They were using the following versions: 1.7 ...% 1.7.1 ...% 1.8 ...% and so on. In terms of client abuse of servers though, I am thinking of annoying bugs and balance exploits and not security concerns. To give a recent example, if someone sees a server running revision = 4995 then they may know they will be able to unequip cursed weapons by changing skill and abuse that bug, whereas it might not occur to them to check otherwise. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire protocol cleanup
On 10/9/06, Mark Wedel [EMAIL PROTECTED] wrote: - May not be able to use a 2.0 client to play on an older server (depends on how old, and what protocol commands to use). Could still use the 1.x clients of course. Might I suggest then, that when the 2.0 protocol changes are (vaguey) finalised, a version of the 1.x server be released which understands a 2.x version number and acts as though all of the appropriate setup flags were set (without adding any of the new features), and also is aware of any new commands that can be sent to it, but merely ignores them (with suitable draw_info-ed error messages). That way it should be possible to have a compatibility upgrade to the server allowing both sets of clients to work for however long it would be until most distros have upgraded the versions they ship. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Removal of output-count/output-sync from server
On 10/7/06, Mark Wedel [EMAIL PROTECTED] wrote: One area that could use cleanup IMO is the output buffer handling in the server. ... One question is whether it makes sense to put that code into the client. Given that both GTK clients have multiple panes for messages, and the only thing that really benefits from this combinining messages is the attack messages, the amount of benefit isn't as great. Plus, since the attack messages where changed to be more variable in terms of what they print, those often can not be combined. IT seems the main area of benefit is spells. The other useful one is searching for traps, especially at low levels, I find that a small number of searches isn't sufficiant, and will hold down the 's' key for a while, using the output count to bundle the messages into groups of 10. That way I can search 50-100 times (depending on how bored/paranoid I am feeling) without having the searching messages spam the message list hopelessly. Potentially client side support for this could be much better than existing server-side support (if it were to say redraw the last message on the same line it was on but with 'n times:' prepended to it), but no existing clients do that. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable party lists
On 6/24/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. I have uploaded a patch to the sourceforge tracker which forms an initial proposal for requestable party lists. https://sourceforge.net/tracker/index.php?func=detailaid=1475202group_id= 13833atid=313833 This patch has been opened for some time, and didn't receive much flame, just a few comments :) Should I commit it? Honestly, I don't recall what needs done with this, I have been meaning to go back and finish it for a while, but haven't had the time to do so. I seem to remember it worked whilst I was testing it, but this doesn't mean it is of quality suitable for inclusion in CVS as is (and indeed it probably isn't) I'd like to be able to say that I would definatly get the time to sit down and finish this in the next week or so, but I can't honestly claim that to be the case. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Backup(?) CVS via darcs
On 5/4/06, Alex Schultz [EMAIL PROTECTED] wrote: Here is my opinion of Darcs as well as some other alternatives to CVS: Is there any reason why GNU Arch hasn't been considered in your comparison? Is there something wrong with it that discounts it straight away? (NB: I have never used it, but savannah does). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable party lists
On 4/24/06, Mark Wedel [EMAIL PROTECTED] wrote: Overall, the idea looks fine, but I haven't looked at the actual patch. But a few other thoughts: 1) It could be nice to include the highest number party number in the stats command (only transmit when changed). Since I recall that whenever a new party is created, the client can use this to know when in fact there are new parties. party number doesn't exist anymore, it hasn't for a while, there was an issue that it was possible to cause that value to wrap, and in so doing duplicating parties, this was why I wrote a patch last summer to treat parties by the pointer to the party struct rather than the partyid 2) It could likewise be nice for the requestinfo party_list to take a parameter, which denotes to only send party info above that number. You could give a name, and say only send parties beyond that one in the linked list, but then what do you do when the party you send the name of doesn't exist? (possibly changing the replyinfo to reflect that fact?) In this way, the client could keep track of what is last requested up to, and then can just request the new parties. yes, this might even work if done by name, however it provides no nice way to ensure that the player count even vaguely resembles reality, nor any way to cope with parties that are obsoleted. Normally, this isn't an issue, but I believe there have been cases where people have tried to abuse the server by creating hundreds of parties. If with a relatively modest number of parties, you probably want to be able to only send the new ones. Yes, I was the one who first mentioned that almost a year ago (the thread 'large numbers of parties causes weirdness' from last April) This is why parties with no members are now periodically removed. If the creation of vast numbers of parties is a great concern, it may well be possible to limit each player to a certain number of parties (3 say) and, each time a party form command is received, count up the number of parties they currently have. Periodically I suppose the client could go through and request all the parties to figure out which are now defunct. OR perhaps more to have something like a request active party type of thing, which really only needs to send the party numbers of the active parties. I don't see how that can usefully allow player counts to be updated. One more point, which is tangential to all of the others, should parties also allow comments? I am thinking of ~50 characters to describe any given party, to be sent as an extra field in the replyinfo. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Protocol compression.
On 3/27/06, Mark Wedel [EMAIL PROTECTED] wrote:
I just ran a quick test (find . -name *.png -exec gzip -vc {} /dev/null
\;) , and this is a somewhat typical result of the entire arch tree:
snip
Some files not compressible, some marginally compressible, and some very
compressible.
I had a play with pngcrush, to see if the same space savings couldn't
be achieved in the arch tree itself, I ran PNG crush on all the png
files, then compared the filesizes before and after. I dumped a list
of all the images which are reduced in size by 10 bytes or more at
http://pastebin.ca/47176 (I strongly suspect that any gain less than
this is likely to be completely wiped out by those clients which need
to recache the image after it changes, and indeed, the threshold at
which that is true may well be closer to 50-100 bytes)
Note however, that the images which most benefited from this are /not/
the same ones that gzip seems to be able to compress well. (if anyone
wants to try and recreate this, I used pngcrush -fix -l 9 with version
1.5.10) - I think this is something to do with palette utilisation in
indexed images.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] JCrossfire and Web playing
On 3/27/06, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: Then, you will ask...Quake2 on JAVA, maybe cool...but what is matter? The cool thing is that you can play Quake2 using your web browser, if it has JWS (Java Web Start) installed and supported. Also needed JRE 1.4. I have see also a port of crossfire, using JAVA, then, a cool idea, can be to play CF over the web browser, usin also JWS. This can allow to play CF without any installation, compilation or so on, or maybe, players who can't download software fron the web, to play Crossfire. For example, from a University, from the job, and more. I have tested the Jake2, and he goes at same speed than normal Quake2 (using Linux). Also, JCrossfire is more playable over windows than the GTK version (i have tested gcfclient on windows, and it is really slow) But the very best of JCrossfire over the browser is that the user will be playing the last version released of JCrossfire. I'm not altogether sure what you mean by JCrossfire, there is jcrossclient, which is the java AWT client that I took over from Phil Brown, and jxclient which is a java+openGL one (or something like that) which is in crossfire CVS and primarily (exclusively?) developed by gros. In anycase, experimental Java WebStart scripts exist for both of them, gros is the person who actually understands it (and indeed helped me hack one for jcrossclient) In the case of jxclient, no public release has yet been made, so all JWS scripts are ad hoc ones for testing. In the case of jcrossclient, I didn't have the binaries from the previous release signed (or some such detail) so it didn't work nicely, and I didn't want to re-release the binary just for that. I can't comment on when gros thinks that jxclient will be in a state suitable for a stable JWS script, he will have to tell you that himself, for my part, jcrossclient /may/ have one for the next release, if I remember in time and find a sufficiantly straight-forward howto. :) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient info window text trimming crash.
On 2/4/06, Mark Wedel [EMAIL PROTECTED] wrote: Does this mean that info trimming is completely disabled with version 1 of gtk? If so, I'd sort of say, what is the point - that is why there is a config option. Yes, but the config option causes crashes, and if that is the case, it shouldn't be an option when that will occur. Are you sure version 2.0+ of GTK fixes the problem? IIRC when doing the gtk2 client, there is a new widget for text stuff for gtk2, and the gtk2 docs specifically say don't use the old widget if at all possibly because it is severely broken. Trimming works when the client is compiled against gtk2 using maligor's patch found at: http://bluemist.ath.cx/~maligor/cf-gtk2.patch That said, it could be that that option get removed from the config page - if people want to muck with their config file, fair enough, but they are doing that at their own risk. IIRC, the config page specifically says it may cause crashes if you use that option. This approach will show the option if it is safe to use, and remove it if it isn't. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Why have you banned my CVS access, And why do you hate mlab (I just finished mlabhell and I want mlab in for 1.9)
On 2/4/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Why have you banned my CVS access, You'd need to ask the person who banned you, but criticising other developers in a cvs commit message would probably have a lot to do with it. and why do you hate mlab? I do not hate mlab, I think they are some of the most interesting maps in the game. I just finished mlabhell and I want mlab in for 1.9. It's better to have it in non-dirified format for 1.9 then not in at all. That's a point of contention. Also I am offended at lauwernmark and errac's plot to change mlab's culture. To a great extent I would agree, but this does not excuse criticising them in a CVS commit message for a commit it is not clear should have been made. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
On 2/4/06, Mark Wedel [EMAIL PROTECTED] wrote: To me, at some level, keeping the gtk(v1) client about may not make a lot of sense. Especially if we start going down the path of new character creation and other widgets - I don't look forward to trying to write those for the gtkv1 client. I'd note at this point that the recent spell interface updates I did were for gcfclient not gcfclient2 - I find glade complex and confusing, gtk code is comparatively straightforward to write, at least for maintenance. I know a lot of people still use the gtkv1 client. So my basic question is, for those of you that do, what needs to be changed/added/fixed in the gtkv2 client so you would use it. I'm not sure that is necessary, not so long ago there was a patch to gcfclient to make it compile against gtk2, I will assume that this gets accepted in the move towards 2.0, with the few bugs it isolates picked up on the way. If cfclient is removed, (and the broken gnome client also), then there would only be one toolkit in use. It would then be possible to restructure the client directories to have common/ gtk_common/ gtk-v1/ and gtk-v2/ mapping to: protocol parsing and storage, toolkit specific code, and interface respectively. These parts individually would not be so hard to maintain. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gtkv2 client vs gtk client gap list.
On 2/5/06, Mark Wedel [EMAIL PROTECTED] wrote: But what at the main features that are missing? IMO, there is a lot of stuff in gtkv1 client that I'm not sure people use. One being the keybinding interface - do people use that very much, or do people just use command line. It doesn't make sense to add features that no one needs. I use the keybinding interface on the occasions I run gcfclient. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 2/1/06, Alex Schultz [EMAIL PROTECTED] wrote: Well, IMHO this may not add too much for the player to use, but I can see it as something that would add alot of depth to the gameplay. Not sure how worth it it would be to do though, as it is indeed alot of complication, though I would say it would certainly improve the player experience. The small ships would be fine I think, as long as they can still 'attack' each other and have such an event create a 'battle' map, where there are two ships with all their occupants, plus cannons, etc to fight each other. (there could then be pirate ships patrolling just outside the main shipping lanes, and on PVP servers, groups of players could be pirates themselves). ___ 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] Transports
On 1/31/06, Alex Schultz [EMAIL PROTECTED] wrote: Such things incline me to want to disallow them from going through exits, though that in my opinion makes them more limited in usefulness too. Can exits use the move allow/block idea too? if so, you could look at them to decide whether a transport can go through an exit or not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Transports
On 1/31/06, Mark Wedel [EMAIL PROTECTED] wrote: Usage/implementation details: To activate a transport, the player will stop onto it and 'board' it. When this is done, the transports op-contr will point to the player, and a pl-transport pointer will be set up. An 'unboard' command will be needed to leave the transport (thoughts on a better way to deal with this?) I don't think apply will work because that will be needed to get stuff in/out of it like a container. what's wrong with pickup? If I follow the description properly, this transport will stop most of the items on the ground being useful once you are inside it anyway, so you could send as the ground view a single item such as 'get off horse' 'dismount ship' (this requires a new K-V (onboard name). Picking up this item should then dismount from the transport. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] cfclient colouring (was: gcfclient options deathlist)
On 1/31/06, Mark Wedel [EMAIL PROTECTED] wrote: I'd personally say that requiring a 256 color display isn't asking too much now days. I'm inclined to agree, I just don't know xlibs well enough to break support for 16 colour displays in a non-hacky way. (there is still some 'private colourmap' stuff, which I think is somehow related to that) I actually think the grey background looks nicer than the old dark green background. excellent, I've commited the patch. ___ 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
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] 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 -
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
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] Moving server towards a modularized system?
On 1/28/06, Yann Chachkoff [EMAIL PROTECTED] wrote: I'm not speaking about theoretical developers - I'm speaking about those who (hopefully) will still play with crossfire and its code long after we don't. I'm thinking about all the ideas that could get implemented much more easily on a cleaner base than on a patchwork of code. I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, not completely, but at least back to what is actually used. Debian Stable is probably the single most obsolete GNU/Linux distro in widespread use, but even this ships crossfire 1.7.0 Given that crossfire 1.9 should be close to release (maybe?) the second digit would wrap round, and the next release after that would logically be 2.0. A major version number shift would be a reasonable time to deliberately break compatibility with all versions below 1.7 (and maybe include some metaserver filter to stop servers older than this being included too). If this were to occur there would be an awful lot on the server side that could be dispensed with the map command and map1 commands (map1a could be used exclusively) the item1 command (the C clients have long since used item2) spell conversion from the old spell system support for the old skill system. support for oldsocket mode (pippijn recently made a textmode parser using the modern packet structure, oldsocketmode is a hack that could be retired completely) doubtless there are more that I haven't thought of. Remove all that compatibility cruft first, and then, when the server is made leaner as a result, look at what, if anything needs simplifying. (note also, I would suggest taking the same approach with the C clients, which have a similar problem (though less acutely)) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/28/06, Brendan Lally [EMAIL PROTECTED] wrote: I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, oh, one other thing which is vaguely related to that, a 2.0 release would also seem to be a good time to rename some binaries. Currently the server binary is called crossfire, and the gtkclient is gcfclient, every few weeks someone appears on either #crossfire or the cfmb who can't find the name of the binary to run, the naming system isn't as straightforward as it might be I would suggest the following mappings (for both binaries and package names) crossedit - crossedit crossfire - crossfire-server gcfclient - crossfire-client gcfclient2 - crossfire-client2 (or crossfire-client-gtk2) cfclient - crossfire-client-x CFJavaEditor - jcrossedit The slight annoyance this might cause with script breakages can be justified by a major version number change. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
On 1/25/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). The idea of separating the code into fairly well defined areas is something I would support wholeheartedly, I don't think the current tangle of functions is a desirable thing and would much rather some functions were rearranged between files, to better reflect what they do. In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Modules would disallow this (bad) as they are not loaded untill they are called. In an organisational change that would achieve the same effect, these same functions would be marked static anyway, so this is a non-point. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
On 1/26/06, Anton Oussik [EMAIL PROTECTED] wrote: Is there anything that can be done to improve movement on laggy connections? Could the server send the client a matrix of what tiles on the map can be moved to, and send updates of that as they change for example? Any better ideas? One thing that might work for this, is something I have been idling toying with concerning movement. I was looking a few weeks ago at adding a 'goto' command so that the player could send a command goto xy (relative to the player) and then, as long as they had no further commands sent, they would go towards that point. (in terms of controls, this would map to clicking on the map view somewhere). - the stupid implementation of this is quite straightforward, getting the routing to work properly is harder. In any case if that became the defacto standard way of moving (as it is in most graphical RPGs), then it would be possible to figure out what route the player would take, and send the moves they would make to the other players in the room early. - this would still lead to the ocassional de-sync issue (when they change direction, or something moves in the way) but it would be a noticable improvement over what is currently there. (the extension to that would be to have an attackto command (or a flag to goto) so that monsters could be targeted to get the player to follow them and attack when they are in range. - probably such advance telling of commands should only occur if the ping time is bigger than the tick time though. In general though, if your ping time is over a second, you need a better internet connection, most games are difficult to play when you are that laggy. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
On 1/19/06, Anton Oussik [EMAIL PROTECTED] wrote: I did not necessarily mean more powerful spells. Some existing spells can get moved up the chain, and intermediate interesting spells can be added to fill the gaps, so a player always has a new spell just within reach. Either that, or spell could be made to not get more powerful with level, and then players could learn more powerful versions of a spell they already know, which would exist every 5-10 levels. The problem with that is that skills already scale with level, icestorm is one of the best cold spells at any level, because of how well its damage and range scale, so unless you want to nerf the scaling of all the low level spells, they are going to remain the best option, especially if the base level of the supposedly 'better' spells is increased, because then they will have fewer levels to scale over. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
On 1/18/06, Mark Wedel [EMAIL PROTECTED] wrote: Miguel Ghobangieno wrote: Yes, it would be best to remove that option from the menu IMHO. I just tried this out. If I select the 'Quit Character' option from the file list, it does ask if I want to quit or not. Regardless of that, I would suggest that it is something that is something that is so infrequently the intended course of action, that making the player issue the command themselves would be desirable. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Polymorph etc
On 1/18/06, Anton Oussik [EMAIL PROTECTED] wrote: Adding fighting levels to weapons would also make sense, and in my opinion would be more consistent for things like swords and bows than item power is. Having a minimum level for every object that can be applied wouldn't be that difficult, I'd be inclined to say it could work well with item power as well. (to wield sword of foo you must be level n at one_handed_weapons and have x spare item power) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
On 1/18/06, tchize [EMAIL PROTECTED] wrote: Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. I agree on this point, however I suspect that much of this could be avoided by simply shifting a few functions and #define's around, much of what exists currently has been grandfathered into various parts of the code (look at include/define.h for a good example of this) moving these into more logical locations (or maybe even just documented locations) would help in finding various parts of the source code. Likewise moving things around could probably reduce the number of functions which are called from different files, improving the usefulness of text-editor based find tools. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
On 1/17/06, Mark Wedel [EMAIL PROTECTED] wrote: True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. This point (more than any other) is potentially alarming. Currently crossfire is written in C and python, with some perl scripts doing some minor things. If this range of languages is increased, there is a danger that it would include languages outside the range of competence of the existing developers, or outside the range of languages which are well supported on some of crossfire's target platforms. Whilst it might be that $NEW_WHIZZY_FEATURE would be very easy to write in D, for example (or some other $OBSCURE_LANGUAGE) it is unlikely that most systems running servers have a suitable compiler installed or that most existing developers would be able to adequately maintain code written in it. Whilst C++ on its own isn't greatly objectionable, there must be some guidelines as to which languages would be permissible so that we don't end up with 20 different modules in a dozen different languages half of which were known only to their original author who has since disappeared. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient options deathlist
Ok, to try and summarise from this. (this is how I'm reading the existing responses, yell if you think this isn't a fair summary). Not a target for removal: Split Information Window (Takes effect next run) Automatically re-applies a container when you use apply to close it. Still targeted for removal: (on) Colored Inventory Lists (on) Colored Information Text - maybe to be replaced by some future feature (off) Print Grid Overlay (on) Cache Images (on) splash window (gros' suggestion) Options on how to display resistances: - keeping the two options involving scroll bars, but still haven't heard from an advocate of the no-scrollbar option (if this were removed, it could go from 3 buttons to 1) the options in the list above need someone to claim the use of them sometime within the next fortnight. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable spell lists.
On 1/6/06, Mark Wedel [EMAIL PROTECTED] wrote:
All looks good - just a one minor question:
+ name (1 (non-zero) length byte, followed by that many bytes
of ascii text)
+ This is the name of the spell, and should be sent to the
server
+ in order to cast/invoke it.
+
+ display name (1 length byte (which may be zero) followed by that
+ many bytes of ascii text)
+ This is the name to display to the player regarding the
spell.
+ If length is zero, then the name should be used instead.
Just curious what these these two names are far. As far as I know right
now,
each spell only has one name, so not sure why there are two.
gros wanted a way to do it, I think the reasoning was that there could
be the 'internal' name of the spell, and a more flavourful display
name.
Currently I have it set up to send the name and then name_pl as the
display name, but only if it is
1) present
2) different from name.
I could of course use a different field instead ('title' maybe?)
As an aside - it doesn't need to be part of this patch, but it might be nice
to have the cast/invoke command be able to tag a numeric value instead of
string
name, eg:
cast 12345
Which casts the spell associated with tag 12345. This provides a slightly
more efficient way of the client communicating to the server what spell to
cast,
and also provides a fairly good optimized way for the server to find the spell
(doesn't have to worry about duplicates - just has to see if an item with that
tag exists in the inventory (of which there is already code that does it) and
verify it is of type spell.
This could be done quite easily, although to not break older clients,
it would have to be the case that no spell names currently start with
a number. I believe this is the case however.
one other point, should I send the face number (if there is one) too?
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 1/3/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: gold and silver coins are not fiate currencies, their value can't be just inflated. You need paper money for that (or money who's value is more then the value of the material). I won't support inflating gold and silver etc. I will support creating paralell fiat currencies, and yes they did exist in the ancient world. Ah, but now you have to consider what is actually fluctuating. Is it that the value of gold is dropping, or the value of the currency is increasing. In recent history, it has tended to be the case that fluctuations in the prices of gold/silver etc, have overwhelmingly /not/ taken other prices with them. Just because the US dollar weakens against gold (or if you prefer that gold strengthens against the dollar) doesn't mean that the price of bread alters. Certainly it is fair to say that gold has traditionally been quite consistent with reference to other commodities but silver-backed currencies (and especially silver-backed currencies with a debased coinage, which is what I am describing here, rather than fiat currencies) have fluctuated over time with respect to the price of gold. Whether you make the 'value' field relative to a fixed commodity, or a currency, is really an irrelevant point, once you have the same relationship between them being expressed, however, if we take the consumer's-eye view of the economy, prices are significant relative to wages, which are fixed in a currency, not to a commodity that few of them will ever trade in (plus it involves modifying fewer object values). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 1/3/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: It would be nice to beable to set in for instance: Object goldbar name goldbar weight 1 value gold Object goldcoin name goldcoin weight 10 (or whatever it is) value gold that way the value will be * by the current value to weight ration (in thiscase 1/1) This is an interesting idea, and one I hadn't thought of before. Probably for ease of parsing however, it would need to be a new property 'valued_as'? maybe that should be in addition to the value field? For example, a gold necklace might have a fixed value based on the workmanship of the necklace, plus an inherent value based on the weight of the gold. The final value then would be the combination of the two. This would also scale nicely to enchanted weapons and the like. For example a sword could be valued_as steel, with a value of 20 (say) but a sword +1 might have a value of 1000, and a sword -1 a value of -500 (this would require negative values, but allow in principle that a player could make money by melting down cursed items, and reforming them. The questions then become, is it better to hijack the 'material' value for that, and what effect would that have on the things that material is currently used for? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 1/2/06, Miguel Ghobangieno [EMAIL PROTECTED] wrote: Changing the value of the metal coins isn't doable as silver has a set weight to value ratio... Well, today silver has about 1/80th of the weight to value ratio of gold. So changing the relative prices is certainly possible. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
On 12/31/05, Miguel Ghobangieno [EMAIL PROTECTED] wrote: While regional currencies exchange values could change depending on factors that are not in the game yet the silver, plat, gold, jade, and amberonium coins should keep their absolute value forever. Actually, something I think might be interesting would be to have major and minor currencies. Consider the (pre-decimalisation) British Currency. Prices were given in pounds, shillings and pence, 12 p made one shilling, and 20 shillings one pound There was a one penny coin, a one shilling coin, and a one pound note. In principle it was possible to use these, and only these, for purchasing items. However, there were a number of other coins of intermediate values which were extensively used to make up intermediate values, without prices being quoted in them. (note that I am referencing old British currancy, simply because there were so many coins of arbitrary values that were issued - http://en.wikipedia.org/wiki/British_coinage#Denominations_of_pre-decimal_coins_and_their_years_of_production looks to be a fairly good list). Now, what I am wondering, is if the coins with which shops make change couldn't be the thing that varied, so that money would be taken from one of 12 or so different types of coins, and change given in a similar manner (to take an example from the above list, an item which would require 50 shillings (gold) change might cause it to be given in the form of two unites and a half unite in one place, but one two guinea coin and two double florins somewhere else. These could all be legal tender everywhere, whilst causing a player who would travel in certain areas of the world to have different types of coins to someone else elsewhere. A modern form of this can be seen to a lesser extent with the euro coins and notes, whilst they lack the amusingly contradictory values, they have different designs on the reverse depending on which country they are from, so that a coin with a design from a country relatively far away is a mild curiosity on the occasions they are encountered. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)?
On 12/31/05, Mark Wedel [EMAIL PROTECTED] wrote: Not until relative recent history did paper money really become popular. That said, if currency is changed, I'd suggest unique graphics (that are clearly distinguishable) are probably desired - having bunches of coins in my inventory that all look the same would be confusing/annoying, and remove some of the reason for doing this, which is to add character. This would also have to affect character generation, currently players that are generated get an amount of money when they choose a class, and before they exit the nexus. If the two destinations from the nexus have differing currencies, then the player could get the 'wrong' type. Moving the acquisition of money to the teleporters which the player stepped on might work, but since dead players return there until they get another savebed, this might be hard to guarentee to not be exploitable (at the least, every existing player who didn't set a savebed, would get some money next time they died). Making those teleporters damned could work, indeed, if they pointed to a relatively 'safe' place (scorn town hall maybe?) it might be considered a good thing anyway. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 12/27/05, Anton Oussik [EMAIL PROTECTED] wrote: Also replying to several posts. Firstably card vs chequebook: I don't think there is plastic in CF, and so things should not be made out if it. Why do you assume that credit cards /must/ be made out of plastic? They could be made out of wood, or copper. In fact, credit cards give a saner way to charge the player, because real loan sha^W^W banks do exactly the same thing. Charge a fixed amount each year/month, everytime you buy something, send a request for payment of an amount vaguely related to the amount owed. Every $STUPIDLY_SHORT_SPACE_OF_TIME increment by BIGNUM You could then have differing credit limits backed by the amount that you have in the bank (and, maybe, the level of the player). - These could also have differing costs. Maybe there could also be a few cards that offer gimmicks - like a free dragon flight after you spend above a certain limit. In case you couldn't gues, I don't like credit card companies very much. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 12/25/05, Anton Oussik [EMAIL PROTECTED] wrote: On 25/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Anton Oussik wrote: On 24/12/05, Mark Wedel [EMAIL PROTECTED] wrote: At some level, it becomes a question of why not just make money a 'stat'. As said, this wouldn't be really hard. Add a uint64 field to the player object. I suspect this would also fix the client bug when the client crashes when it steps on a tile where something has nrof 2^32. Wouldn't stepping on non-money items which have a sufficiantly high nrof also trigger such a crash? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Banking system
On 12/24/05, Anton Oussik [EMAIL PROTECTED] wrote: Thinking about lalo's patch, an interesting idea would be to make a patch that makes the banking system more useful by introducing the following changes to the banks: - Gain interest on money deposited [snip] In my opinion this will encourage people to use the banking system to store money. It would, but I think there would need to be an associated opportunity cost, otherwise there would be no incentive to keep liquid capital. maybe something like 'real' banks do, where there are two accounts, one a currant account against which cheques are drawn, and a savings account, which takes a week (or more) to take money from, has a high transaction charge, and also offers a reasonable interest rate. This would unfortunatly require a more complex interface. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wraith changes
On 12/16/05, Anton Oussik [EMAIL PROTECTED] wrote: a wraith should be strong enough to suck life from victim faster than victim sucks blood from it, since if it is losing hp it will die. But surely this point is only true for creatures that are weaker than it? One wouldn't expect a level 1 wraith to be able to kill a dragon surely. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] requestable spell lists.
On 12/17/05, Mark Wedel [EMAIL PROTECTED] wrote: Brendan Lally wrote: This could work, but requires a new command in the protocol. I don't know why it would require a new command. the setup command is not true/false values, it is setting some variable to whatever value. So a 'setup spellmon 6' is perfectly valid. And to push the data, the same command could be used - it'd just need to be clarified that spellist would represent updates to existing data. Or the spellist command could send optional params to denote what it is updating. There is no 'same command' the existing implementation uses stats and request/reply info. the other advantage of push is we can be more bandwidth efficient. If a player learns a new spell, only need to send that spell down the line, and not all the spells if done on a pull approach. I thought about that, but I can't see how it can be done without the server storing the spell list for each player, which is a fairly ugly way to implement things. (the only other thing I could think of is to abuse the spell objects, and set an update value for each one (added, removed, changed costs, changed damage, etc) Same way it is done for most objects - you send it at the time of the event. So in server/apply.c, in learn_spell, you'd make a call to send_spellist() when the player learns a spell. This is how most all of the object updates for player inventory are currently done - the update is sent in the code that makes the change - we don't hold the results and send them later. One thing that was suggested by gros on IRC earlier was almost a hybrid approach, instead of having a stats value that says what type of change has occurred, you have a stats value that contains a number for the spell object, these would be assigned sequentially, and be unique for any one player on each run of the server. (everyone would have their spells numbered 1,2,3,4, etc.) Then, if ever a spell was added or removed (by moving the attunement into a seperate stat, and sending only the base cost, this can be the only time an update is needed), the stats command can send the number of the spell that was changed, and the client could then requestinfo # and get back only that spell. (this was my understanding of gros' suggestion, I hope he will clarify if I misunderstood some detail) 2) I wonder if more spell info should be sent. For example, base damage values, lore information, etc. If we only send spells on push, bandwidth shouldn't be that costly, and it then gives the player more info to choose spells (fireball, 24 dam, ...). Lore and damage seem reasonable, although then the question is, should that be base damage or effective damage? Both of these values have issues, effective damage may not do as much damage as stated (even before resistance) owing to quirks in how each spell propagates, if base damage is sent, then you need to send a lot more data and hardcode the calculation. (more on that below) For damage, we obviously can't take into account resistances of creatures. So it'd be basic damage - if the spell does more, like cones, because of multiple effects on top of each other, we don't factor that, as you can't really know for sure how that will work out (likewise for fireballs - damage would vary greatly based on where the creature is in the effect). The lore info could note those increased effects. This requires a substantial increase in the number of spells with such information. Related, I think it'd be easier all around to send the spell path information as a bitmask - saves some bandwidth, and the bitmasks values should be pretty stable (can't remember last time a new spell path was added, and even then, the client could just display something like 'unknown' or whatever) This could work, although currently the clients have no information about spellpaths. This could be added, although maybe then a request_info spellpaths would be better to initialise it? (this way clients couldn't fall out of sync, and there is no restriction on adding new paths). Perhaps, adding requesting adds complication, but not that much. At the same time, there is a lot of communication that is defined stable. IF someone were to add another stat for example, that would require some significant changes - the client isn't designed for dynamic stat information. Requesting spell path names, at least on the server side, is easy, I had it working locally already. The way I'm dealing with stats is to only send them if spellmon is set, anyone sending that should know what they will get back. At some level, it could be nice for the server to somehow note what current client version is and tell the player if their client is out of date. So if the client is out of date, they'd know to go update it - that'd be good for reasons beyond just spellpaths. I'm not sure
[crossfire] requestable spell lists.
I have today attached a patch to the sf tracker (which can be found at https://sourceforge.net/tracker/index.php?func=detailaid=1381875group_id=13833atid=313833 ) which implements the beginnings of support for a new requestinfo type - spell_list. Whilst this is not complete - the cases where the spell list could be updated are not all dealt with, and there is no proper client support (although https://sourceforge.net/tracker/index.php?func=detailaid=1381871group_id=152431atid=784287 contains a hack for jcrossclient that I've been using for testing purposes). - it is at a stage where comments are needed. - Should any of the fields used change, or be extended or added to? With this in mind, I ask you to read the rest of this message which contains a (hopefully clear) description of the changes I am considering. requestinfo spell_list: This is intended to allow clients to request the spell list, and get it back in a controlled way, so that it can build menus/lists/interfaces of whatever sort it thinks appropriate. Additionally, it adds a new setup option, spellmon, which sends a value if the spell list has altered. This is sent once each time it alters (or might have altered) between sending of the stats command, and only if requested. It sends back a value which corresponds to the type of change that might have occurred; 1 - costs changed. 2 - attunements change 4 - spells were added or removed. This is a bitmask, so multiple values may be sent, depending on what the client wants to do with the information, it may or may not want to re-request the spell_list. from the diff to doc/Developers/protocol: spell_list (no parameters) This returns a list of all the spells the player knows, along with some other information about them. The data is sent in plain text, one spell per line in the following format. spell name:spell level:skill:spell paths:status:mana cost:grace cost Where: skill is sent as the number that maps to the skill as provided by skill info (above) spell paths is sent as a series of space seperated words status is a number that has the following meanings; 1 - attuned 2 - repelled 4 - denied any or all of these may or may not be set for each spell, if so, they add together. All of these fields will be sent, but it is not certain that any field will have entries. If extra fields are added later, it will be to the end of each entry. an example response is: burning hands:1:174:Fire:1:4:0 holy word:1:170:Turning:0:0:4 spark shower:1:176:Electricity:0:5:0 note that in the case where the player hasn't logged in, or doesn't have any spells, a blank list is returned (the replyinfo forms the only line in the response) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: weather, lattitude, town location, and the world
On 11/15/05, Lalo Martins [EMAIL PROTECTED] wrote: And so says Mark Wedel on 11/15/05 16:05... I'd personally think that canals on that scale would be more modern than what crossfire is really set in. Not really. The ancient Chinese did it, and Bigworld has powerful and (relatively) cheap magic to make up for the low tech. Also there are the Roman Canals, Foss Dyke was built in the second century, and is over 10 miles long (about the length of the continent at the moment) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] weather, lattitude, town location, and the world
On 11/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Crossfire is somewhat limited by only 1 aspect of terrain is available (we don't have forested mountains for example). Forested mountains could exist in principle, it just requires someone to be able to draw alpine trees. All that said, if we were to create another continent and wanted to start with an automatic process, there are many improvments I can think of: 1) Create altitude map (with different seed of course) like did before. Actually, I think it might be preferable to create tectonic plate boundaries, and then generate heights from that, it would give a much greater concentration of mountains, without having them scattered everywhere (and impeding movement) It would also be more realistic. 2) Based on that altitude map, run weather on it for a long time (elevation 0 is of course see). The problem with that is that the same results aren't guarenteed, so if this is done once, and a mistake is made with a heightmap somewhere (a big mountain in the centre of navar, say) it could be difficult to run the weathermap to the same effect again after fixing it. Water has to go somewhere, so that determines rivers, lakes, and marshes (lakes would basically be formed when the total water flowing into a set of spaces is above some amount and that set of space(s) is constrained by higher objects around that would hold the water. This would also be limited by temperature, at lower temperatures, the amount of inflowing water needed is less, because less evaporation occurs. (this is a major part of the reason why there are so many lakes in scandinava). Mountains should probably be determined if the elevation is above some height. But low mountains are also possible, but that should be done based on different of elevation of neighboring spaces - if a space is say 1000' different in elevation from its neighbors, it is a mountain. similar for mountains, but no height - just height difference (in the 250-500' range?). Well, if the surrounding area is high, and there is a line of low altitude, then you get a canyon, if the surrounding land is low, and there is a line of high altitude, then you get a mountain ridge. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] weather, lattitude, town location, and the world
On 11/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Brendan Lally wrote: On 11/12/05, Mark Wedel [EMAIL PROTECTED] wrote: Crossfire is somewhat limited by only 1 aspect of terrain is available (we don't have forested mountains for example). Forested mountains could exist in principle, it just requires someone to be able to draw alpine trees. All that said, if we were to create another continent and wanted to start with an automatic process, there are many improvments I can think of: 1) Create altitude map (with different seed of course) like did before. Actually, I think it might be preferable to create tectonic plate boundaries, and then generate heights from that, it would give a much greater concentration of mountains, without having them scattered everywhere (and impeding movement) I believe there are other projects out there (not related to crossfire) about mimicing a planet creation process. If we were really serious, we should look at those. I did ask the freeciv developers on freenode about that point a few months back, they have a random world generator which creates tile based maps. However a lot of what they had was quite hardcoded, and they don't have a nice way to analyse the squares. - Plus the scale is much larger, millions of acres per square. This was just before their 2.0 release however, they map have something more hi-jackable now. Then with that, you use that as the blank slate to start putting towns, dungeons, etc on. Having the above info actually makes some of that process easier - towns wouldn't be in the middle of a mountain range, but likely along the rivers, and most typical, at the river/sea junction. That could work, particularly if canals were added later, so that boats could travel across much of the continent (your movement code reworking could make it possible then to have narrowboats to travel between cities). But point here is that this is still creating a map with actual forest spaces and whatnot - you use a dynamic process to create a static map. Yes, and thereafter are forced to use that static version to edit it, this is an issue if there is a change that would be easy to make with a heightmap, but which would require extensive modification otherwise. Incidentally, it also strikes me that the best way to get a height map would be from a grayscale image. - simply say that brightness is altitude, and then lots of adjustments could be made with the use of gimp filters. That said, if the same weather process is used to create this static map as that used in the game, then at least as the game runs, the weather would be consistent with the terrain. For example, right now, there are desert areas on the map, but with the weather code, I have no idea what level of rainfall they get, since the location of the desert was rather arbitrary set (lets put it here). Also there aren't enough deserts, but that is another point altogether. In geological terms, rivers will carve out valleys. So in those cases where a river flows into what would form a lake, see where the water would flow out and make some random determination if the ground in that area is hard (rock) or soft (earth/gravel/whatever), and thus a gorge would get eroded away to let the water out, and you don't have a lake anymore. The issue with doing that is that it would require playing with the sea levels as water evaporates, to compensate for the water falling as rain. As long as the world is mostly land, and not water, then that will be a significant effect. Furthermore, because in the real world, water will often drain through rock until it reaches an imporous layer, there is normally a water table rather than lots of water on the surface, creating vast swamps. It would be neccessary to account for this effect to avoid a disproportiate amount of swamp, maybe there would need to be two inputs then, elevation and geology? This would also improve lake formation, since it would simply be the point at which the water table intersects with the surrounding land. To get this to vary properly then, at least an approximation to measure groundwater flow would be needed. (probably the laplace approximation would be sufficiant, but I'd need to do some reading to check on that), hmm, hacking the weather code to include a water table would have some merit to it (for one thing, the quick hack would be to determine porous rock depth by archetype, so deserts might still get rain, but they would have lots of porous rock, so the water would never stay on the surface (yes, I realise that is not even vaguely what deserts actually are, but it would at least stop puddles forming) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] jcrossclient lives.
On 11/11/05, Yann Chachkoff [EMAIL PROTECTED] wrote: Just a small question: Why hasn't been jcrossclient made part of the Crossfire project, but is being maintained separately ? It seems a bit strange to me, especially since there is obviously no licencing issue. There is also no code shared between the two. Whereas the cfclient/gcfclient/scfclient and gcfclient2 are all written in C, using the same code in common/ jcrossclient doesn't. Everything is written in java (or with the newer parts in a mutated form of java that is pretending to be C, but that is more an issue of my coding style). Also the eventual goal is different. I intend to modernise the featureset of jcrossclient, to match up to current servers, but after that, I intend to turn it into a web applet, so that crossfire servers can offer a way to play on them with a web browser using a java plugin (mikee has already told me that he will do this with cat2, once it is working) This is still a couple of months away, but even so, it is the nature of such a goal that the release schedule will be different for jcrossclient compared to crossfire as a whole (and, at least initially, I expect be having a release every week or two as I try to stabalise towards a 1.0 release. - having these releases announced in connection with the main crossfire project may very easily cause confusion, especially since the version numbering is different (look at the number of questions that occured around the time of the 1.7.1 cfclient/gcfclient release). One final point, the controls are subtly different, and the nature of awt is such that it would be very hard to get it to mimic the gtk clients behaviour in all respects, as such it is likely that there will need to remain seperate control documentation, which again is harder to differentiate in a single project. Do not think however that this means that there will not be significant design and code overlaps, I have already ported/mutilated some code from gcfclient for the map1a parser, I would like to think that in future such a transfer could also happen the other way, although that is not likely to be until there is more code to borrow. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] weather, lattitude, town location, and the world
On 11/11/05, Anton Oussik [EMAIL PROTECTED] wrote: On 11/11/05, Lalo Martins [EMAIL PROTECTED] wrote: Hmm. Maybe bigworld is not big at all :-P Brendan's calculations still make sense to me generally, except that now I'm thinking about one-chain-wide mountains and finding them a bit silly. But that can pass, since those are relatively rare. Such rock formations may actually be possible, wih a hard surface and wind and such. Since the planet is not Earth and since we are willing to accept teleportation and beds to reality, then why not small naturally occuring rock formations? These /do/ exist in the real world, a quick google turned up http://home.bawue.de/~jjk/travel/Urlaub%202002/Canyonlands/Needles%202.png They don't look like they occupy much more than a tenth of an acre. Of course, arguably they should be called rock formations, and not mountains, but that is a different point. Personally I would say that if bigworld were not already established, it would be nicer to use a height map, so that each square would have a height associated with it, and then whether they are hill, mountain, plain, river or desert could be inferred from the height values (the areas that cities are currently on would need to be flat, with a depression to the side with between them and the nearest sea facing mountains, to redirect the resulting river). This would have the added advantage of reducing the size of the bigworld maps download, although at a cost of slower startup time. Note that I don't actually suggest this is done, but merely seek to describe how it might work. Effectively to go from a height map to terrain, you would need to determine a coastline (being areas that have height 0) determine the water absorption, (inversely proportional to depth and distance from shore should be a reasonable approximation) and then propagate water along a path roughly parrallel to the coastline, losing water with a rate given by grad(height), low flat areas inland would be deserts under that model, unless there was a small lake in which case an oasis would form, if there were a mountain range then, there would be a watershed given by the peak, so that a river would form along the path that involves the quickest drop to sea level. if the mountains are not very high, then water would flow down the other side too, creating savannah or temperate forests (based on temperature) the rivers being created there would create areas of river delta, with either swamps/rainforest or bogs/farmland (depending on temperature, or local rainfall?) If this were done in a way that avoided the use of random numbers, this would still be a fixed value, and it might even be possible to set exits to go for 'nearest accessible square of arch' - for example a mountain cave might be set to be placed on the nearest mountain square to its current location (probably only 4-5 squares away, unless the heightmap is altered substantially). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] jcrossclient lives.
As those of you who follow #crossfire on freenode will be aware, I have recently taken over Phil Brown's jcrossclient project, and started updating it to make it work again with modern servers. I have tonight uploaded a new version of jcrossclient to the sourceforge page I created for it a few days ago. It can be found https://sourceforge.net/projects/jcrossclient/ This is the first new version to be released in four and a half years. In keeping with the previous numbering system, this is version 1.0-alpha-2. Please note that this /is/ an alpha release, and therefore should not be considered suitable for use as a main client (yet). If you play using this client, and get killed due to a bug, I will not be held responsible. Major changes of note since the previous release include: * Support for PNG images (and removal of xpm support) * Support for big images on the map view * Support for scaled big images in the ground view window ( as seen at https://sourceforge.net/project/screenshots.php?group_id=152431) * Numberpad now works for control * Names in the inventory window are no longer corrupted. * default view size is 15x15 * Removal of fatigue bar Known Bugs: * Command window is a bit, interesting, and sometimes throws exceptions if the commands are malformated. Unlike other crossfire clients, jcrossclient requires commands to be prefixed by ' and say commands to be prefixed by * Main window doesn't get created at the correct size, and must be manually re-sized to expose the stat bars. * Map updates are somewhat slow, even on my AMD64 system, and the display can flicker if it has lots of activity (like rapid movement). I hope to address these issues over the coming weeks, most noticably the map update speed/smoothess issue, as well as continuing to add support for more of the newer features that the server can provide (such as new_draw_info_ext support). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Selling price variance and buying price variance
On 11/8/05, Mark Wedel [EMAIL PROTECTED] wrote: Brendan Lally wrote: This is because there is an arbitrary adjustment to price based on the item count and map name, it is in the range of +-5% it is designed to allow otherwise identical shops to give a small variation in price. Possibly it shouldn't apply to shops selling items, only buying them? How does it do that? does it just randomize the price in the query strings (if so, how does that remain consistent), or does it change the actual objects value? It is the price returned by query_cost that changes. lines 295-300 server/shop.c /* we will also have an extra 0-5% variation between shops of the same type * for valuable items (below a value of 50 this effect wouldn't be very * pointful, and could give fun with rounding. */ if(who-map-path!=NULL val 50) val=(sint64)val+0.05*(sint64)val*cos(tmp-count+strlen(who-map-path)); making this not apply to a shop when it sells items, is as simple as adding an ' flag == F_SELL' to the if statement. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Selling price variance and buying price variance
On 11/7/05, Kevin Bulgrien [EMAIL PROTECTED] wrote: I do not get the purpose behind the fact that selling price of look is wildly different from store to store. At first I thought it might have something to do with the store having more of an interest in certain items, but now I am not so sure. It is. It seems that the lighting emporium pays almost 4x for many items compared to some other stores. This was true of body parts, flint/steel, and weapons. Yeah, I made a mistake adding the header for that shop, left off a minus sign, making it a very /good/ place to sell those items, instead of somewhere that isn't so good. (incidentally, I posted it to the crossfire-maps maling list, and no one called me on it). I've updated CVS to use a more reasonable value. It is also pretty weird to see flint and steel sold for well over 1000 plat in say the weapon store when you can walk over to the lighting emporium and get one for 260-ish. yes, that is the other consequence of me goofing with the header. And, I say -ish, because in the store, each one has a different price... for my character, 239-265 or so. That seems bizarre. Why would the price not be the same for the same item in the same store? This is because there is an arbitrary adjustment to price based on the item count and map name, it is in the range of +-5% it is designed to allow otherwise identical shops to give a small variation in price. Possibly it shouldn't apply to shops selling items, only buying them? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] alchemy/alchemy
Currently there are two concepts within the game world called 'alchemy', the first is a skill for the transformation of items, the second (which I was just reminded of today, having forgotten of it due to its general uselessness) is the spell alchemy which transforms items into gold. These two things having the same name is confusing, so I propose that one of them change their name. since alchemy.c is a file that deals with the skill alchemy, it would be more consistent to rename the spell. I propose the name 'aura of midas' although if someone else has another idea then that would be fine too. If it were the case that it were decided to keep the name alchemy for the spell, then notwithstanding the comment about source file names, it would be equally straightforward to rename the alchemy skill. In this case I would suggest something like apothecary as a suitable replacement name. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Pickup issues
On 11/5/05, Nicolas Weeger [EMAIL PROTECTED] wrote: Hello. The query_cost function was changed part of selling / buying improvement. But now the pickup ratio, which uses this function to estimate the item's price, grabs much more items than before. Should we try to fix to keep previous behaviour? Or just ignore leave like that? That it doesn't have the previous behaviour would be a bug. You are however welcome to call it a feature, although I believe ragnor has just gone and fixed it on me, so such a nomenclature will be short lived.. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Love and marriage, love and marriage...
On 10/19/05, Sebastian Andersson [EMAIL PROTECTED] wrote: In fact, there are many societies that don't value pretty as something possitive (goes nicely together with many religions' art of self-denial) That is what should happen, unfortunatly there are enough greedy people around that it doesn't actually occur that way. and if they were to live alone gold would have a lower value as it wouldn't be wasted on vanity items. That's a nice theory, but it didn't actually happen. Gold was highly valued throughout the ancient world, and was one of the first things that was traded for in the new world, often in the form of jewelery and ornamentation (which demonstrates that it was valued and worked there too). I suspect that if you were to find a society that had no gold reserves accesible, then you would find one which didn't value gold, but that would be the only one. I'm usualy surprised how much is the same in crossfire and other human societies. If magic was so easily obtainable as it is in crossfire, I think few people would buy a flint stone. Most NPCs don't cast magic. The idea of introducing reagents (mentioned elsewhere) is an attempt to balance this. but if one is interested, wikipedia has an article about it: http://en.wikipedia.org/wiki/Same-sex_marriage#History_of_same-sex_unions None of these are marriage, but are instead more like that of the relationship between a mentor and appretice, some of them taken to a sexual level. From the article: In China, especially in the southern province of Fujian where male love was especially cultivated, men would marry youths in elaborate ceremonies. do you what to include the next line too? 'The marriages would last a number of years, at the end of which the elder partner would help the younger find a (female) wife and settle down to raise a family.' quite clearly then /not/ a (semi-)permenent relationship, and /not/ one that was considered to create a unique family in its own right (as marriage is) To call this 'marriage' is to use the word in a non-standard way, and therefore is unhelpful to clarity of thought and expression on this topic. That in turn seems to come from the book: Bret Hinsch, Passions of the Cut Sleeve: The Male Homosexual Tradition in China, p. 132 I don't know this book or this author. nor is it explicitly referenced in the article (an omission on the part of the creators of the article?) Other parts of the article speaks of unions, which in my opinion is another word for marriage. In my opinion it isn't. I suspect most trades unions would hold the same view. marriage is a specific type of union, one that has members of two families leave and form a new family. Other types of unions, such as those between apprentice and mentor, do not fulfil the same description, indeed to the host family, such a union is more similar to a birth in terms of the change in family structure. Considering how diverse societies there have been, I don't think one can assume anything about a crossfire society by looking at ours'. Not ours, but all human societies. There are always certain constants, things like status determined by dress and ornamentation - in the aztec empire, to wear clothing marking a status above your own was punishable by death. Today in England impersonating a police officer is considered to be a very serious crime. I can't think of any society (certainly not any large and successful one) where clothing or jewelery was not reserved in such a way as a means to show status. To not have such a thing in crossfire would seem odd, and likely ring false. Heck, would people in a crossfire world even need to grow food, the beginning of most human societies? In crossfire I would rather think that societies would start up around priests, casting restoration on their friends or around mages casting create food. But these are high level spells, most of the NPCs don't cast spells, nor have access to them. And production isn't at a high enough rate to feed everyone. Nonetheless, this is yet another reason for spell reagents sex has to be introduced first (and better text handling). I'm not quite sure how those two follow on from each other... are you thinking of new attack messages? I was thinking about sex as in gender, not the verb. But I should have used the word gender of course to avoid such confusion. Better text handling would be needed to let people know about sex by using her/his, she/he etc. I suspect that the effort to do that would be about the same as that required to i18n the server (but not the archs or maps). If it is going to be done, switching to gettext at the same time may be worthwhile. But as has already been mentioned on the list, make things generic and let the people in the game role-play such things. Yeah, and it doesn't involve playing with .po files. ___ crossfire mailing list crossfire@metalforge.org
Re: [crossfire] Re: New movement code.
On 10/19/05, Anton Oussik [EMAIL PROTECTED] wrote: When activated the wraith becomes invisible, stealthy, can move through walls, and can not cast spells, or hold items in inventory (except invisible ones of course), The only attack then avaliable is wraith touch, which deals ghosthit, depletion, drain, and life slealing. Without clothes wraiths are not very strong, so I do not see how it will make them overpowered. Running for the nearest wall will often be the best choice, only preying on the weak, but that will be the only way of surviving, since you would die from three hits by a powerful monster, if you can not life steal them as fast as they are hitting you. Will direct attacks hit wraith stood in a wall (like they do in ADOM with ghosts)? Will rings/amulets remain wearable? I'm inclined to say that at least there should be a /big/ hit points penalty as well (maybe 50% - though with a small ac bonus too ?) While in this mode the wraith ca not pick anything up, or interact with the environment, like push switches, buttons, or anything like that. Ok, so their weight would have to be zero too. Would you change the face as well, to give some clue they are in this mode? This would also mean players can not take stuff out of treasure rooms... they can get in, fly though it, and then walk out again leaving treasure behind. They would not be able to steal it without completing the quest. You need to deal with switching out of this mode inside the treasure room (you try to adress this later) That could still lead to lots of potential spoilers (you could observe the boulder layout and infer information from that) Also you should not be able to go into void squares to get to other floors or mechanic sections of the map. You should be able to apply exits though, to get around between maps. not all boulder layouts are seperated by squares with no tiles on. There is howerver a case of the player going into the mode sneaking up to a switch opening treasure room, and then taking it out. The only way out of this I see is to only provide one way of leaving the mode once entered: by visiting some well defined set of points (like an altar of devourers, or a graveyard to posess a new body). This way it will be impossible for a player to either cheat in the quest or help other players cheat. Alter of devourers might work, but there are maps that have alters in dungeons, and these might get placed in areas where a player could get stuck. Also what about a wraith that doesn't worship devourers? There are similar issues with graveyard placement, plus it is a little illogical that a graveyard corpse should work, but a 'fresh' one should not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 10/19/05, Anton Oussik [EMAIL PROTECTED] wrote: Another issue I'd like to bring up is grace. getting rid of spellpoints will make grace stand out. If you ask me the model works, but it will stand out now that spellpoints are going away. Would spell points go away? To my mind they do different things, reagents limit the total number of spells cast, spellpoints limit the rate they can be cast at. Arguably spell delay can compensate for this effect on its own, but it would then need to be tweaked up. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code. (Wraith stuff) (Please don't implement)
On 10/19/05, Mitch Obrian [EMAIL PROTECTED] wrote: Please do not implement this passing through walls stuff. I /strongly/ oppose passing through walls. I do not want my maps to become worthless because someone decided we need to make the game worthlessly easy. If it were a new movement type, then it would be possible to block it explicitly. How many maps would need modified to block that movement type for one reason or another? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 10/20/05, Todd Mitchell [EMAIL PROTECTED] wrote: A quick summary of ideas I have: very high mountains (mountain_5) remains blocked high mountains (mountain_4) require 'climbing' or 'flying' movement type to pass On a related note, whilst all these tiles need updating, flattening the tiles a little may be worthwhile (mountains 1 and 2 become hills, hills become flat ground) - currently the world map is very mountainous, flattening it would aid movement. rivers remain blocked (how to explain this re flying?) with reference to back to the future - hoverboards don't work over water. *most* wall types and doors remain blocked Wasteland remains blocked (or becomes like swamp?) except to flying That will break the team arena. Also, since it is being changed anyway, how about altering its name to 'volcanic plain' or something similar? Wasteland sounds like something that should be traversible. shallow sea requires a 'swimming' or 'sailing' or 'flying' movement type sea and deep sea require a 'sailing' or 'flying' movement type or a submarine movement type, which should also work on icebergs and sea ice. (not as anacronistic as might be supposed, the first submarines were in the early 17th century). new types of jungle and woods require a 'woodlands' or 'flying' movement Also, roads and tracks should allow carriages to pass and roads, tracks and grass should allow horses to pass. (these don't exist yet, but should). further in the future Desert should allow camels to pass (if there ever is a large enough desert to make that worthwhile). Tundra and glacier should be passable to husky sled. type flying has limits on range but you also said sea and deep sea require a 'sailing' or 'flying' movement type so if a player flies out over deep sea and lands, what happens? do they insta-death? swimming has a drowning behaviour (like swamp)? climbing has a falling behaviour (like swamp)? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 10/20/05, Todd Mitchell [EMAIL PROTECTED] wrote: Brendan Lally wrote: with reference to back to the future - hoverboards don't work over water. But you can still fly over seas... until you tire. The reason I suggest we need to restrict rivers is because they are so often used to direct movement already and they have fords and bridges to allow passage. Restrict such a restriction to fresh water? (salt in the water [techobabble] so that the [technobabble] provides greater lifting force) but you also said sea and deep sea require a 'sailing' or 'flying' movement type so if a player flies out over deep sea and lands, what happens? do they insta-death? I think if they can't swim they would probably drown. If they could swim they better hope they make it back to land before they drown. But if deep see is blocked to swimming, then they won't be able to swim back. I imagine you can't recuperate fatigue so you can fly again while you are swimming... That will be guarenteed death then. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Love and marriage, love and marriage...
On 10/18/05, Anton Oussik [EMAIL PROTECTED] wrote: I persume you would get married in a church, which means you would need to worship a god of some sort. Wouldn't it be a high level thing anyway? Marriage typically something that was engaged in later in life than soldiering. - Should the couple worship the same god for marriage to work? Maybe allow marriages between worshipers of different gods as long as they are not enemies and there is no conflict with any of the gods? or allow each god to define it. I'm inclined to say no though, the gods in crossfire are not merely different denominations, but different religions, there is no real-world norm to parallel to what you describe. - Do we allow same sex marriges (I can see valriel rejecting them)? I can only assume this is an attempt to provoke an off-topic flamewar. I shall simply state that it is ahistorical, without precedent in any society that approximates the technological state where crossfire is set (medieval europe/renaissence - with the odd 17th century-ism) Should it be god dependant? Should some gods not allow marriage alltogether (like devourers, since the primary goal of getting married is having children, and this seems to go against the principles of devourers) probably, or else they would have polygamy/polyandry - Divorces. Let's face it, relationships do not last for ever, and you may decide to go your own ways. Should there be a mechanism for terminating a marriage? not a standard one. The way that divorces can occur varies between different faiths. I see no compelling reason why crossfire should be different. There are major issues though, if marriage would allow a shared bank account, then splitting it afterwards would be interesting. This would become more acute if polygamy existed ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New movement code.
On 10/17/05, Joshua Wilson [EMAIL PROTECTED] wrote: Brendan Lally wrote: The following are IMHO only. IMHO is good enough for around here :-) On 10/17/05, Joshua Wilson [EMAIL PROTECTED] wrote: Do the undead (Devourer) breathe? And if not, can they simple sink to the bottom anyway and walk as far as they want? in theory, but, since water will contain trace amounts of holy water (being one large interconnected system into which such water will at some point have been introduced), and since holy water is fatal to undead, when they tire and sink, they start to swallow water and the component of that that is holy water kills them. Interesting. A few thoughts here. Are you using this logic as a way to prevent the undead from getting an advantage that overpowers them, or is this how you really see it? according to wikipedia: 'Once consecrated, more ordinary water can be added to the supply of holy water, and the entire quantity of water remains consecrated provided that the amount added is less than the amount of water that was there.' I had never heard this before (but then I've never really thought about that before, so have never tried to look it up), but it sounds plausible. Gameplay is to me the key point, If there is drowning, then there is no need to have massive alterations to world maps that have open bodies of water (and illogical limits on where a player can and can't swim). If some characters are not guarenteed to be able to drown, then they could go anywhere in a body of water, which would mean a need to modify them to define where someone can't swim to. The 'all water is partially holy water' argument does have one other problem, in that wraiths can drink potions of water with no ill effects. Isn't holy water blessed by a priest to become holy, and after it's been used no longer holy and just water? In this case wouldn't water returned to the sea no longer be holy? That's an interesting question, I infer from the wikipedia quote above, that the water would then no longer be exorcised, but that is an unsourced line from a wikipedia article. I have been unable to find a better reference myself. I do know that the quantity of water recognised as holy by any person is a tiny fraction of the world's total (even if the hindu intrepretation is used where (as I understand it) the entire river gagnes is considered holy - I'm unsure on this point, and would welcome it being corrected, I don't think hinduism has exorcism of water in the same way as Christianity.) Anyway, regardless of the reality of holy water, the world of crossfire is polytheistic, one god can define its persistance in rivers, seas and streams (but not in glass bottles, or fountains - sounds kinda like a gaea sort of claim to me.), while the others don't. If their banishments can work against wraith, why not their holy water? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] New movement code.
On 10/17/05, Mitch Obrian [EMAIL PROTECTED] wrote: Gaia is a diety who has it's own lore, other dieties have other lore. We should not make one lore primacy above other (_especially_ gaia's). Is there actually a proper set of lore for the various gods in crossfire? If so, where is it? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: New movement code.
On 10/18/05, Lalo Martins [EMAIL PROTECTED] wrote: And so says Brendan Lally on 10/18/2005 09:19 AM... Is there actually a proper set of lore for the various gods in crossfire? If so, where is it? It was a pet project I was working on, many, many years ago. It's on the wiki. It's not by any means official. And I only did Gaea, Valriel and Gorokh versions (although it's possible that followers of other gods subscribe to the Gaean version, it was written with that intention). Yeah, I was thinking in terms of inside the game. possibly however this stuff should go into the handbook? If anyone actually finds them interesting, I'm game for making improvements or writing more stuff. It certainly looks interesting, there are a few grammatical oddities (things like teached instead of taught), but I'll wait until there is a wiki with revision control until I fix them (speaking of which, when is that expected?) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New movement code.
On 10/16/05, Todd Mitchell [EMAIL PROTECTED] wrote: I would advocate that only the shallow sea should be swimmable. Could seas use the same approach as swamps? That when a player starts walking into them, they stand a chance to sink slightly, and if they keep going, they die? This would effectively stop long distance swimming Obviously the messages would need to change appropriately: You glide comfortably through the water You feel your legs start to get tired You struggle to keep your head above water You gasp for breath, and in the process swallow lots of water You are drowning ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
On 10/16/05, Mitch Obrian [EMAIL PROTECTED] wrote: Also the corpses should look bloodied up, and if someone consumed the monster totaly with fire spell etc then a corpse shouldn't be dropped. or look at the last attack type, and if it is fire or lightning and enough (maybe level?) damage is done, create a charred corpse instead. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
On 10/15/05, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: We have disscussed the way to do this, and like we talk about, the best way is: 1.- Spawn 2.- Create random Loot 3.- Die 4.- Create container 5.- Move loot to container 6.- Put container in monster What would you do to the container (cadaver?) after a player 'opens' it? Destroy the container, or leave it there, empty? If the corpses were to remain, then using the dead bodies for storing different equipment could be interesting. I can certainly envision storing large numbers of axes in a goblin. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Houses system for guilds
On 10/15/05, Alberto Sáez Lodeiros [EMAIL PROTECTED] wrote: Personally, i like more the blank map idea, because in this way, we can create our own city. have a read of the thread from this post: http://shadowknight.real-time.com/pipermail/crossfire/2005-September/009238.html ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] More server speed reducing the objects number
On 10/15/05, Mitch Obrian [EMAIL PROTECTED] wrote: If one's server is lagging because of items then one is running his server on a 286 PS/2 system (if that is even possible). This is a non-problem. Well, to be fair, on the occasions where servers do slow down, it tends to be from spell objects (normally coupled with directors). This is lagging 'because of items'. However I would agree that treasure drops from monsters aren't normally an issue in this case. Any benefit there would be would be to bandwidth usage, not server memory usage. However, even there, unless/until the number of faces visible per square is increased, the difference is likely to be minor (2 objects instead of 3, if there are multiple items dropped, and if there were nothing on the floor already) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 10/14/05, ERACC [EMAIL PROTECTED] wrote: Needing items to cast spells is more along the lines of witchcraft than sorcerous magic (read some Steven Brust http://dreamcafe.com/ to see what I mean). In CF the magic system seems to be sorcerous based. The witchcraft based magic is more akin to alchemy in CF. Why do you take this to be your reference point? Real world magic is mostly con tricks and illusion anyway, and there is therefore no 'correct' way (consistent with the real world) to model the invocation of magic in a game. Using items for spells to my mind is as such more an issue of game balance than adherence to the fictional work of some random novelist. Anyway, the old amiga RPG worlds of legend (I never did win that game...) used a similar system, and I think runescape does too. If you really want to get around the issue of carrying ingredients, have it incorporated into diet. - define certain magic ingredients and have food be able to contain them. eating that food would then increment a counter stored as an invisible object on the player (or directly on the player struct - that would be faster in combat). Then decrease that back to zero every few hours (as the ingredients break down in the players body), or whenever a spell is cast. For extra effect, there could be variant sources of these foods which did nasty things, like permanently reduce stats. Then there would be a trade off (nice spells, or not needing to use more stat potions) In terms of game balance, spell ingredients /could/ be useful. Especially if they were created with alchemy/woodsman skills at high level. - That skill could then become essential to the ongoing usefulness of a wizard, and high level spells might be used a lot less if they were sufficiently expensive. (probably that means not using comet or meteor swarm against everything around - burning hands and firebolt could be useful even at higher levels if they cost much less) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 10/14/05, ERACC [EMAIL PROTECTED] wrote: Needing items to cast spells is more along the lines of witchcraft than sorcerous magic (read some Steven Brust http://dreamcafe.com/ to see what I mean). In CF the magic system seems to be sorcerous based. The witchcraft based magic is more akin to alchemy in CF. Why do you take this to be your reference point? Real world magic is mostly con tricks and illusion anyway, and there is therefore no 'correct' way (consistent with the real world) to model the invocation of magic in a game. Using items for spells to my mind is as such more an issue of game balance than adherence to the fictional work of some random novelist. Anyway, the old amiga RPG worlds of legend (I never did win that game...) used a similar system, and I think runescape does too. If you really want to get around the issue of carrying ingredients, have it incorporated into diet. - define certain magic ingredients and have food be able to contain them. eating that food would then increment a counter stored as an invisible object on the player (or directly on the player struct - that would be faster in combat). Then decrease that back to zero every few hours (as the ingredients break down in the players body), or whenever a spell is cast. For extra effect, there could be variant sources of these foods which did nasty things, like permanently reduce stats. Then there would be a trade off (nice spells, or not needing to use more stat potions) In terms of game balance, spell ingredients /could/ be useful. Especially if they were created with alchemy/woodsman skills at high level. - That skill could then become essential to the ongoing usefulness of a wizard, and high level spells might be used a lot less if they were sufficiently expensive. (probably that means not using comet or meteor swarm against everything around - burning hands and firebolt could be useful even at higher levels if they cost much less) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
I'll try to only post to the list once this time. On 10/14/05, ERACC [EMAIL PROTECTED] wrote: He's not random. I chose him specifically because I agree with his fantasy ideas on witchcraft vs. sorcery and his writing that down in his novels keeps me from having to reiterate it here. It might do if it was someone I had heard of. As for game balance ... well, I've not ever been fond of that term as it usually means nerfing or disabling something I have found fun to use in the game. If by 'fun' you mean unequivocably superior to all other options to solve the same problem, then yes. Almost all games, from a simple game of draughts to more sophistacated games like risk or DD are based around making interesting choices, when the best choice to make is unclear and requires some combination of skill, luck, experience and planning. A choice that has an obvious or trivial best solution is null. It doesn't matter in game terms and is merely an impediment to the enjoyment of the game. I am not convinced that currently choice of spells (particularly in combat) is an interesting choice most of the time (it tends to be meteor swarm, if that doesn't work icestorm or banisment (if undead or the right race). Only very rarely are any other spells used, at least IME. Same goes for game economy. It's a fantasy game, it *should* be easy to get insanely wealthy once one knows how. If I want things to be difficult and to have little money I have that in real life. Maybe but you shouldn't get that at level 1. It should rather be something that is gradually accumulated, and requires a degree of challenge, at least initially. If that is absent, then money is made worthless. I'm reading game balance but thinking game complexity. I think this will just make the game more complex. It is already quite complex now and takes plenty of time to learn to play well enough to survive to a high level This doesn't neccessarily have to make the game more complex. It would be quite possible to remove spell points at the same time, and with it the complexity of power crystals, power potions, and magic stats. Especially if the amount of each ingredient it was possible to stockpile was limited (to go back to my previous idea about incorporating it into food, a point at which you are told 'your body is incapable of holding any more of this' likewise paths could be removed, rather have attunements to the individual ingredients (so that you need twice as much, or half the number for certain spells). To my mind that would be a /simpler/ magic system than the one that exists currently. The question then would be whether it is worth changing to. That is a difficult question to resolve (which is why it is a topic of discussion here). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [IDEA] Reagents for cast magic
On 10/15/05, Mitch Obrian [EMAIL PROTECTED] wrote: I also like the food idea. Perhapse if you don't follow the correct diet then your SP stays at 1/2 of what it could be. hmm, this is a different idea to what I had in mind, but actually has a lot to commend it. maybe even moreso, have all foodstuffs have different stats, and have them affect the player. foods could have a series of different stats, so that eating different types of food would slowly skew a character a little. Eating lots of fat would increase armour and resistances, and decrease speed and ac. Eating lots of sugar would increase dex and Con, but reduce intelligence and power and make spellcasting failure more common. Eating foods with E-numbers in could increase spellpoints and give spellpath attunements, but also have randomly bad effects (confusion, blindness, paralysis, death) Drinking some alcohol would increase Cha and cold resistance but reduce Dex, drinking more would reduce it, and create a (non-transmittable) illness - hangover. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unban me
On 10/10/05, Vernon T Rhyne [EMAIL PROTECTED] wrote: laughs That hasn't, and will never be the case. Rule enforcement at all levels is by whim and mood, as with most clique-managed open-source communities. Try as with all stable communities anywhere in the world. The nature of rules is such that to have them enforced uniformly would be unjust. because rules only describe concepts, not individual circumstances. This is why court systems the world over allow for extenuating circumstances. (and why politicians who distrust their local judicary and try to make the response to such calls formalised in law create the loophole-filled laws that blight most nations in the world today) It's undoubtedly a major reason that the wordlwide crossfire player count is in the hundreds (or less), rather than thousands or more. I suspect there are five more noticable reasons for the lack of players. 1) mediocre performance on slow/laggy network connections (crossfire was designed for playing on an internal university network, and has never really been properly optimised to cope with modem connections, that up until only a couple of years ago were very common) 2) a historical lack of stability. - less of an issue in stable server releases, though the metalforge and cat2 servers sometimes find rather more bugs than might be preferred (that is, however, the nature of CVS code). 3) difficulty in setting up clients - until comparitively recently this required some interesting playing with telnet, and windows client support is a fairly new (and under exposed) thing - I've had a small go at helping in this respect myself (look at the posts about autopackage from last month) 4) High initial learning curve to play the game - partially this is an artifact of the way existing clients are created, partially this is a map/item issue (the god-given initial items are an interesting detail for a newbie who accidentally drops something). 5) lack of information about the project. - there are some steps being taken to deal with that. ( http://www.gamesites200.com/mpog/vote.php?id=2197 is one of them) I grant that I'm a largely outside observer, but the general politics of crossfire ensured I'd never step inside. I have not seen any noticable intrusion of politics in the project itself, arguably on the metalforge server such a thing can be observed, but metalforge != crossfire With all of the problems and issues that have arisen since I joined the project, I have never seen anything but a desire to find the best or most useful technical solution to the problem at hand, ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
On 10/4/05, Mark Wedel [EMAIL PROTECTED] wrote: if (m-shopmin) fprintf(fp,shopgreed %d\n, m-shopmin); if (m-shopmax) fprintf(fp,shopgreed %d\n, m-shopmax); Is that code there really correct? It seems you are saving shopgreed as the field name when you are actually saving shopmin and shopmax. no, no it isn't, those are typos. I've fixed that now in CVS. Thanks for pointing it out. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On 9/29/05, Benjamin Lerman [EMAIL PROTECTED] wrote: Now, I plan to create Enchant Ring and Enchant Amulet scrolls that would work like Enchant Weapon, but because it demands a little more work than for the 2 previous patch, I'd like to know if those scrolls would be Ok. I'd like to also implement think like Improve resistance to `foo' for Weapons, but once again, would that be Ok? The one comment I would make here is to be sure to deal with the item power properly. What exactly 'properly' is in this context is not neccessarily clear, too little an effect and these scrolls would make rings overpowered, too much, and they would be useless. I would suggest however that if the results of enchanting rings to the extent that their stats are about the same as one with similar item power from the item generator, then you are probably ok. Something that does interest me though, is how you intend to fit this in with the jeweler skill. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 9/28/05, Alex Schultz [EMAIL PROTECTED] wrote: would enhance crossfire as a MORPG, because: 1) It increases player interaction by giving customizable maps that one can invite others into without having to bother with guilds and their storage rooms and such. IMO increased player interaction is something crossfire is in need of. 2) It plain gives players more to customize, which is a positive thing when it neither unbalances the game nor changes the genre You forgot a third one, it gives players something to do with all the money that they can currently collect. Currently there are ways to get money (alchemy dungeon crawling) which work ad infinitum, however the existing ways of spending money (slot machines, apartments, equipment) is fairly limited, so that, after the first million platinum or so, there isn't a whole lot to spend money on. However introducing a status element that can require vast expenditure, should be a nice way to take money away from the fool^H^H^H^H rich. - especially if there are enough glitzy things that can costs tens of thousands of platinum each (like mikee's coloured tiled floors in constructor form) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Buildable Land Plots
On 9/28/05, Todd Mitchell [EMAIL PROTECTED] wrote: I believe if you ask people if the built maps are superior to the random maps, you would hear that players like the built maps better. I'm not quite sure your image of what is being described, and what is attempted to being described quite match up. we are talking about random maps yes, but random mostly empty maps. you might well have a map that looks like (in rogue style graphics...) ... ... ..T...T .TT ..R. ... ... .~~ T.B.~ ..~ I've probably miscounted the width of some of those lines, but assume they are all the same width (T - tree B - bush R - rock ~- water) and every square would have can_build 1 on it Since most players aren't into making maps - perhaps they may find it a bit hard or at least annoying to have to build things They would be using constructors, not the map editor. and they might like to buy something like the guild houses with things like trophy rooms, pet kennels, guest rooms and other special areas. They are already available in several towns throughout the game world... At least with house templates you can have these nice features and make fun quests for players to access them. You can have nice constructors and have quests to access them too (for example a stone wall constructor, or a metal door constructor). For personalization, well you can add many rooms that are buildable to the different house templates. Also the blueprints/templates way is an easy way to set different house styles on the map (houses, long houses, keeps, castles, guilds, temples...) to represent the building This is true, I'm not sure if there is a nice way to do this. and a good way to set the starting price. Well, I was thinking to charge by plot (abuse the town portal marker, so that if it points to a valid plot square you 'ask' for that one), and charge based on proximity to entrances, roads etc although then all the constructors would have their own price, so a bigger buliding, would need more constructors than a smaller one. Nothing stopping you from coding up a storm in any case, I'm sure you have ready counter-arguments to this post. I will upload the templates I worked on before so they are available in any case. Excellent, if nothing else, they will give a good idea of how to balance the building shop treasure lists to avoid any of the standard items (walls, doors, wooden floors) being too rare. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
