Re: [crossfire] Project: Slow down combat
In some sense, this is sort of an inverse of how things work now - all actions more or less take the same time, but the characters speed differs. Hum no, spell casting for instance takes a variable amount of time depending on the spell :) Also some commands take more time, I think And in many ways, the above makes a fair amount of sense - some objects should modify certain action speeds, and not others - for example, speed boots should reduce cost of movement, but really shouldn't reduce cost of swinging a weapon. I think this would also need to be explored more - one quick concern I have off the top of my head is that all the different actions may now have custom code to figure out extra cost for this action based on various attributes. It also seems to me that a basic speed multiplier for each living creature may be a bit simplistic - if one were to do that approach, one would think different actions should perhaps have different costs based on races (some may be fast at spell casting, slow at combat). OTOH, that is a distinction that is currently missing from crossfire. Having different speeds for races is maybe not required for now? Let's have variable speed for different actions first, then adjust slowly :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spell idea: Elemental skills
Hello. Replying to various mails at the same time. And idea I had was to change the current spell skills into 4 elemental skills - fire, water, air, earth. The praying skill would not get changed. Sounds good, if we can balance everything. The idea of a 5th skill, well, not totally sure it's nice. I'd rather see generic spells you can use with multiple skills. The issue you'd have with a 5th skill is how to level it - if it has enough spells to level correctly, why use another elemental? if it has only utilitarian spells, how can you level it? That could be useful in other regards - another thread had the idea of breaking weapons down, so the some classes can only use a limit of the weapons (so a mage can't pick up the battle axe) - if we followed an example of multiple combat skills, something like a dagger could have 'skill simple|complex' type of thing, but the battle axe just have 'skill complex' Or what about: * create 'axe weapons' as skill, and forbid mages to get it * put a cap to what mages can use in item power for weapons things like that? It could also be interesting, but harder to do, that some spells use multiple skills for the effect. Something like pool of chaos, which is really creating something from multiple elements, should perhaps take a look at the skills and adjust it accordingly - if a character is level 50 fire and level 5 earth air, that pool of chaos would really mostly be fire, with a little bit of earth and air (things like para elementals are also a mix of two elements) It could be fun, and I'd add: allow 2 players to combine their spell to generate a different spell - fire storm + wind = big spell (more damage? greater range? Also, you couldn't cast eg chaos fire+air if you only master fire+water :) Thoughts? I think such a scheme would make the wizards a bit more different - playing a wizard and not being able to cast ice spells could be quite a handicap (or fire or lightning and hopefully same for earth). And it makes some logical sense. And it gives more importance to wands/rods/staves. I never use charging scrolls, for instance, not worth the issue - now if you find a nice wand, you have a use for them! I would though seriously limit the rods, because they effectively have unlimited casting - the golden unicorn horn for instance is really powerful, allowing almost continuous healing. That seems too powerful to me. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] back from grave
Hello, am back from the grave. Welcome back on board :) Coming back after lots of month away from crossfire, i took opportunity to checkout fresh svn. I noticed the latest entry in svn, that is not working. The readme tells it should contains the trunk of various tools. It did not. Assuming it was a missing commit for svn metadatas from someone, i added the server / client / maps / sounds / arch / gridarta as external repositories of latest/ (so now you can just check it out to get trunk of all tools) Nice, thanks. I also noticed lack of clarity about disparition of configure script. wiki give correct procedure, but INSTALL on server does not. I added 2 lines about autogen.sh there and a link to wiki for details Thanks again :) After sucessfull compiling and running of server i noticed a few messages that did not follow the time [level] message format of Log(). It appeared those where generated by calls to print in pythin script. I modified the cfpython plugin to add Crossfire.Log(), changed maps/python scripts that were using print to now use Log() and updated cfpython information on wiki. Sounds ok, thanks for the update :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Music and ambient sound
Le jeudi 22 novembre 2007, David Delbecq a écrit : I started a thread about music and sound creation in crossfire. I think it's time for users to take action and help developpers :) Main developpers are coders, not music artists. Note that there *is* server-side support for background music. See http://wiki.metalforge.net/doku.php/dev_todo:functions_implemented_but_not_yet_used#background_music for a short explanation. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Music and ambient sound
Hello. Just committed changes to sound (not background music) system. Check doc/Developers/sound for more details. It quite certainly isn't perfect, but I guess that's a start. The design idea is to have arbitrary sounds, and also specific sounds for specific item / monsters. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Arch category... wall dressing?
Hello. Consider this a call for ideas on a directory structure for storing archetypes of this nature. These aren't going to be walls, but probably will sit on a layer just above the wall so as to appear part of the wall. It is doubtful they would be used for anything except redecorating wall tiles. *votes for /wall/overlay directory* Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Plan to commit combat changes to trunk
I've been playing with the rebalance of melee combat for crossfire for a while, and while not 100% done, I think it is complete enough to warrant committing it to the trunk and hopefully getting more exposure. Now for folks running trunk servers, while the change will not cause anything to actually break (or it shouldn't), it will cause a change in game play, so folks may find combat tougher. Gonna be hard on permadeath servers :) I have also limited the generators, via arch change, to only generate 5 monsters before the generator dies. I'm sure some maps need updating - that 5 monster limit is actually a pretty good compromise - it tends to fill up those empty dungeons that rely on generators to fill them up, but also keeps monsters at a reasonable level. That's a major change, though. Many maps, especially some training centers or Gorokh's final map, actually rely on illimited generators. So maybe that should not be committed for now, or made optional for map designers to decide. I could do all this work in a branch - I'm just don't think that is really worthwhile - the main point of the trunk is to work on the big projects like this. I'd say that where things are now, it has moved beyond expiremental code to code that will be used, but some more work is still needed. I'll start another thread about future changes for balancing. But I'm willing to discuss, and for folks to see this as a heads up if you are running a trunk server. Agreed, trunk is for big changes... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Next release
Le lundi 31 décembre 2007, Mark Wedel a écrit : Had mentioned several months back I was going to do a new stable release in the near future. Between getting sidetracked and waiting for some changes to get put back, I never got around to making a release. Hopefully there will be a Windows release, last tests show everything work as intented, just need to ensure all DLLs are packed as needed :) Client has metaserver2 support, and server should too when I get the time (unless someone else does it before, of course ^_-) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client and Editor packages
Just a short note to tell you that Debian and Yum packages for daily builds of the Gridarta Editor (Crossfire version) and JXClient are now available. The version number used is 1.0-, followed by a revision number equal to the SVN commit the packages were made from. Nifty, thanks for those users :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] New plugin: citylife - help needed
Hello. I just committed (to trunk) the first version of a plugin named citylife that aims to add NPCs to towns. Plugin is doxygen-documented for interested people. Basic summary: when a map is loaded, adds NPCs to random zones. When the map is in memory, will randomly spawn NPCs from predefined points (houses / shops). Behaviour is for now totally dumb, NPCs will just move around randomly. Plugin relies on spawn zones and points, and archetype list (to vary NPCs for regions). Help would be appreciated to define the spawn zones / points for various towns (only Scorn is done for now) :) (or improve the plugin! see the todo list, or use your imagination). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Volunteer for Windows builds?
Hello. Is there anyone willing to do binary builds for Windows for now on? I don't mind doing the .11 release, but I must say if someone else would like to do the next ones, I'll gladly let him/her handle things :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Weather code
Hello. Is anyone actually using the weather system? Or does anyone actually understand the aim it has? Or has any plan to improve it? I was pondering making that a plugin, or simply trashing it... Opinions? Thoughts? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Weather code
Considering the strong opinion there is on this subject, I removed the code :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] What Crossfire is missing
Hello. Here are things Crossfire is missing IMO: * quests, new maps - there is some work on that, but not that much * ingame lore and stories - many stories on the wiki, not integrated ingame * graphics (new if possible, or remake existing ones) Any takers for some things? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Volunteer for Windows builds?
(Moving the discussion from IRC to the ML) What about using something like CMake ? http://www.cmake.org/HTML/Index.html http://www.cmake.org/HTML/About.html The issue isn't really the project/Makefile. The issue is to setup the build environment correctly :) (especially for the GTK client) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New plugin: citylife - help needed
I don't know if you already know this, already use it, already plan to use it, whatever, but: Sim City (classic) has been just GPLed under the name Micropolis, and the automata that runs the sims in the game is available as a library within the source tree. http://www.donhopkins.com/home/micropolis/ When that happened, one of the first things I thought was, how awesome it would be to use it to control NPCs in a game like Crossfire! Well, I'm not totally sure it's nice to control NPCs, because as far as I know it manages more shops/buildings than individual characters :) It could be used to control the general town development, though. But I'd rather see something based in part on player activity (players don't use at all a shop = it disappears) Of course, we could use some algorithms and ideas from that! Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New plugin: citylife - help needed
Out of curiosity, how hard would it be for city life to animate other things that are not NPCs? Am thinking along the lines of tumbleweed, whirlwinds, leaves and such. Not sure it is a suggestion yet. Was also thinking of objects the player might be able to walk on rather than have them be blocking. Well, you could expand the plugin to do that. Define eg trees as spawn points for leaves, maybe. If one were to do that, I'd suggest to generalize, ie define multiple spawnable lists, each with spawn zones and points. I looked a bit. The zones and points in code seem odd, but I guess probably mostly out of simplicity until it seems it catches on? It's a rough first implementation :) I didn't try that hard to adapt precisely to eg the port shape, and zones can just try to put on walls (but server won't let, of course). Feel free to change that, of course. In the suggested changes, it would probably make sense to define the zones in the maps themselves, maybe, or something not closedly linked to the server... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Player accounts, new player creation mechanism
Hello. Here is a proposition for new player account mechanism and character management. To be clear: * player = human playing on Crossfire * character = ingame character When connecting to a server, a player can create or log in to an account. This account is linked to characters, and the player can manage (add, delete, maybe other things) them. Character creation mechanism is mostly moved to client, where the player can select race and statistics. I'd keep class to be chosen ingame for now, as it depends on maps and such. Characters can possibly be transferred between accounts. Account survives until removal by player, characters disappear on death on permadeath servers. Opinions? Suggestions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Map logical linking
Hello. One issue I have with maps is that sometimes you have no clue what quest or thing they are linked to. Example: I was browsing (in the editor) maps in Navar, and discovered some quest spawning various maps, with keys in one or the other, but no idea where to find other maps. So I'd like to be able to easily find what maps are linked together for a quest. For this, I suggest to use the lore field in the maps, which is totally unused (it's loaded with other headers, but never displayed). Proposal for logically linking maps: * in one of the maps, probably the one with quest starting point or quest end, describe the quest in the lore field, and include what maps are linked to the quest, maybe more information like player level or reward? Minimum is the linked maps * in each quest map, add in the lore a reference to the quest and the map with all the information Since I'm (after all!) a developer, I could suggest to create an easy format for this lore field to be able to automatically extract information and make nice spoiler pages. But well, maybe not that necessarily to go that far :) Opinions? Suggestions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player accounts, new player creation mechanism
Hello. Replying to various points in one mail :) Benefits I see to account system: * easier for player to manage characters * easier for players to remember other's identities (one account vs multiple chars - assuming account named is for instance displayed in the 'who' output) * maybe character exchange * why not some benefit from dead chars on perma death servers? Agreed on class information chosen at the same time, makes sense. I'd see a transition period: at first old clients could create characters without accounts. Newer clients could create account and link characters to it (create account 'Nicolas', and tell the server the 'Warrior' character is linked to this account). Then remove players without account. Client could make some shortcut and propose to create account + player at the same time for lazy players. I see the account as a better way to count players - best case all players use an account, so we know how many there are ; worse case, one account per character, same situation as now. Yes, server will always check what client sends - basics of our protocol anyway. Concerning Mark's last point: obviously, player will choose 'login' or 'new char' on client which will send the right command - wrong password implies failure to log, not new char creation. I hope I addressed all points :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Volunteer for Windows builds?
I will have limited access to a 32bit Win XP home workstation starting in about 2 weeks. Will Visual Studio express work for the builds? Or, is something else needed or recommended? I'm not totally sure, I only tried with VS 6... Note that it will *NOT* work with Visual Studio 2008. There is a workaround to temporarily solve the issue, but it's not guaranteed it won't crash horribly at some point. Technical details: VS2008 apparently changed the behaviour of snprintf, which will happily not add a final NULL when the destination buffer is not big enough. Crossfire relies on the presence of a final NULL and uses strlen after such concatenation... The result under Windows is dirty, obviously :p One fix is to increase the buffer sizes everywhere and hope you'll never try to put larger text. Other solution (better) is to use StringBuffer for concatenation, which requires some work on the code... (something I have in mind, but not sure when it'll be done). (note that there may be some other function or compile flag I'm missing, I didn't test everything...) Also, for Windows builds, the hard part is the initial setup. Once everything is installed, building isn't too hard. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Volunteer for Windows builds?
Hello. Windows binaries for 1.11.0 released to Sourceforce. Links: * client http://downloads.sourceforge.net/crossfire/crossfire-client-1.11.0.exe * server http://downloads.sourceforge.net/crossfire/crossfire-server-1.11.0.exe * maps http://downloads.sourceforge.net/crossfire/crossfire-server-bigworld-maps-1.11.0.exe (SF may need a few hours to update) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map logical linking
Hello. Looks good to me. It may be worthwhile to define how that information is used, and thus perhaps other fields. As I see it, information is only used for mapper, to generate map information. No ingame link - at least, none that I plan to do, maybe others? :) The idea to split quests from maps could be interesting, though, someday (so you could distribute map packs containing a quest). As for the format of the field, I'd suggest: HTML, without anything fancy, and no h1/h2 headers (so they can be used for other things on the page). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Mapper tool
Hello. I'd like some opinions/suggestions on the mapper tool for Crossfire (found in server/utils/mapper.c). Current aim of the tool: * provide a map reference for map makers, to know what exists, show links between maps, point to areas where there aren't many maps, ... * spoiler for players wishing to learn how maps are connected or browsing maps online * help find inconsistencies in maps (same slaying between maps, invalid tiling, unreachable maps, invalid exits ...) * make nice pics we can use for background or whatever :) Here are the tool features for now (note: the pages on ailesse are not generated with the latest version, so I may refer to things you can't yet see unless you use the tool locally): * for each map, a page with exits from / to this map ; quest(s) the map is part of ; region of the map ; map lore (without quest info) and level ; map picture (real size and reduced size) - http://crossfire.ailesse.com/maps/scorn/misc/church.html * for each region, a page with the maps part of said region ; the region description - http://crossfire.ailesse.com/maps/scorn.html * a global world map with region information - http://crossfire.ailesse.com/maps/world.png * a map of roads, blocked things and exits (both used and unused ones) - http://crossfire.ailesse.com/maps/world_info.png * a global map index - http://crossfire.ailesse.com/maps/maps.html * list of slaying values used for keys / doors / various mechanism * uses a template system to customize the output (basic templates in SVN, ailesse uses custom ones) * warning for exits to non existing maps * list of maps that exist but are not reachable from the HallOfSelection Features not (yet) on ailesse: * uses real map and region names for display, instead of the filename * tiled maps support, grouping all maps linked through tile_path_ as one map - with the exception of the world maps themselves * list of maps sorted by level * .dot file generation with links between regions Features I'm thinking about and could implement: * nicer world map navigation, maybe using javascript to scroll maps * max small pic width/height to avoid things too big on page * use a scripting language for even more page customisation - may be overkill, but well ^_- Known issues: * Titan (and probably other) pics are shifted bottom/right - this is quite certainly due to the head being on non (0, 0) * platinum coins are weirdly displayed, as well as the pentagon in the HallOfSelection * does not take into account race-specific HallOfSelection Code wise: * no memory leak, even if the tool does not free its memory - all could be freed if needed, but as it isn't intended to run all the time, not required IMO * file too big, I'm thinking of splitting it for easier maintenance * not part of the build process nor installed - could be included (would then need to define a correct generation path, for now it spits into './html') * shouldn't use too much memory when running * could use more documentation, maybe (processing logic and such) So, what would you, as a developer, map-maker or player, like to see? I'm not saying I will implement everything, but you never know ;) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Using svnmerge for backporting to branch?
Hello. After applying a trivial bug fix for the manual pages of the clients, I thought about merging the patch to the 1.x branch. However, it looks like all previous merges have been done by hand (hopefully using svn merge) instead of using automated tools like svnmerge (no space). Or at least, I was unable to find the svn properties that are usually stored by svnmerge when it is used. I have no objection to use svnmerge, but as you point out *everyone* should it if we decide to use it. I would say for current trunk/branch it may not be that required, as I fully expect branch To Die Soon (tm) :) Except for bugfixes, of course. So maybe for the future 3.0 branch? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] New field: race_restriction
Hello. Just added what I hope is a fun feature: race restriction on items. From the wiki: Everything that can be applied, including items, exits, handles, and thus can have a ‘race_restriction’ key. The value should be set to a : delimited list of races that will be able to use/apply/open this item. The list is in the form: :race1:race2:...:racen: with leading and trailing :. Note that that this only applies to players - monsters can always apply everything. Also, Dungeon Masters are immune. Enjoy :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Race / class animations
Hello. I committed a few days ago a change that enables to have specific animations for all race/classe combinations. The animations should be called base race animation_class_name, so for instance a Fenx warrior will use animation fenx_player_class_warrior. So now we just need pics for all combos :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Mapper tool
Hello. I was wondering: would it be worth to make mapper generate one page per found monster archetype in ùaŝ. Currently there is one big page summing that up (monsters.html). Probably something like one page per archetype, with special monsters in a different section. So you'd have (random values): --- Bat hp: 6 wc: 1 found in maps: cave, ... Special variants: - Bat Boss: big cave - evil bat: demonic lair - Opinions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Mapper tool
Le lundi 24 mars 2008, Rick Tanner a écrit : | I was wondering: would it be worth to make mapper generate one page per found | monster archetype in ùa?. What is the last word in the sentence? It's not displaying for me for some reason. Sorry, it should read map, fingers slipped on other keys :) So, using the example above.. There would be the name Bat on a map summary page. This would be a hyperlink to a standalone page display the complete stats of the Bat? That would be the idea. I presume the user would then have to use the browser back button to get back to the map summary? Assuming the summary above holds true; Just some ideas.. What about using a popup window to display the monster information? What about using an iframe to display the monster information? Remember mapper uses a template system to display information :) So basic version would probably be link to another page, but you could just redefine / modify the template to use iframe or popup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] ob_methods / ob_types
Hello. I'd like to move all the ob_methods and ob_types functions, except init_ob_types(), to common directory. And I'd like to add 'ob_trigger', to be used into common/button.c trigger_connected(), once again to remove stubs. This way, we'll be able to remove the need to define move_firewall / move_teleporter / ... as stubs in many things. Opinions? Comments? Oh, and I do think this is getting real close to C++... Maybe it isn't required to reinvent the wheel all the time? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spell rebalancing notes/thoughts
Somehow, I don't like this definition of fun... But I admit I don't have many ideas of other definitions. I'm open to ideas to make this better. Certainly waiting around for HP/SP/Grace to come back isn't fun, yet at the same time, we can't just ramp up the regen speed, as that effectively makes characters more powerful (if a character gets all their HP back in 2 seconds, it means you just have to avoid damage for that long). What about making other fun activities the player could do while waiting for sp/hp/gr to regenerate? Like, going to drink in a bar and falling in love with someone. Or trying to decipher a coded message. Or getting around trying to be elected to mayor? While potions of heal/power/whatever work, one can't really give them out in infinite supply. What about forcing the player to accumulate some before they go in dungeons? What about focusing on non-combat things too? Enigms and such? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] If someone's bored...
there is much much lore on the wiki, that could/should be put ingame. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Dialog modification
Hello. I'd like to improve NPC discussion with the following system: * NPC displays a text * the player has a list of available replies * choosing one reply leads to another text * the player can also enter an arbitrary text The three first things make the dialog much simpler for players. The fourth is to open some text only if the player uses the right keywords. Comments and suggestions welcome. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] CFAnim
Hello. I've fixed some things from CFAnim, and it seems to work though some actions don't really work. Documentation is in doc/Developers/plugins.doc/cfanim/animfiles.txt or you can glance at the map /test/cfanim and associated scripts (cfanim.button and cfanim.animation) to get a rough idea of how it works. What kind of functions would be nice to have? Of course, the idea is not to do another scripting things, but basic animations. On top of my head: * animation loops * jump to a random animation * time based on NPC's speed and not ticks or seconds * send a custom event (to communicate with other plugins) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Resistance calculation
Hello. I would like to suggest a change to the resistance calculation to treat every additional protection and vulnerability relative to the current resistance. Currently, all positive resistances (protection) are accumulated, and the negative resistances (vulnerability) separately. (split much) IMO, the negative bonus that you can't overcome is part of the penalty for choosing a race/god. If you could, from -30, reach 100, there would be really no point for the -30 in the first place... There are, I think, enough items to have high resistances everywhere, so that -30 wouldn't matter much. I suggest to simplify the code and treat every protection or vulnerability the same by applying the accumulation formula above to both positive and negative resistance items. Code complexity has nothing to do here :) Code is at the service of features we want, not the other way around unless there is a really good reason - in this case none of those. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN commit access
I have recently been getting quite a few patches into svn for the server source (look in trunk ChangeLog for Arvid Norlander), and have been considering trying to become a developer, gros, Ryo and Ragnor (iirc) have all indicated this may be a good idea on IRC. So here is the request: commit access to the server source in svn, mostly in order to: 1) Clean up source, fix messy/bad/old source 2) Fix bugs (both security related and otherwise), memory leaks, valgrind errors. 2) Writing unit tests for server (has been requested by Ryo on IRC) I may have occasional bug fix for the gtk based clients too but my main interest is in the server source. Support for SVN access - just don't make big breaking changes without discussion first :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CFAnim
I tweaked some more, and it's starting to be usable. The newest feature is the ability to specify the animation to play through the 'message' sent as part of the event. Thus it's possible to group animations in a file, and run only one. Check /test/cfanim and associated .py and .conjurer files to see how it works. And I plan to use that for Navar university, so that'll give more hints. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CFAnim
I added an 'animation' directory in the maps, the a 'maps' subdirectory - the idea is to have the same structure as for Python. Navar university is now the first map to actually use TWO plugins to work ;) I added the whole Lorkas backstory, more as a proof-of-concept than a real use, though it could very well stay here. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
*sigh* if only the list could be so lively for content-related stuff... I globally agree with Yann. Also this is code no one here knows, it'll take a while to get into it, bla bla, but you do what you want with your time :) *goes back to his hole* -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
But so far, all the objections have been from developers involved with Gridarta and saying basically don't work on a new editor. Please, get your facts straight :) Yann didn't work on Gridarta unless I'm mistaken, and I definitely didn't (unless using it or making feature requests makes us developers :)). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Using UTF-8 in maps
Le lundi 21 juillet 2008, Raphaël Quinet a écrit : Just a quick summary of what was discussed a few minutes ago on IRC, so that it's not forgotten: - the gtk v2 client is already using UTF-8 correctly; - gxclient and the old gtk v1 client are still using iso-8859-1 but it should not be hard to convert them to UTF-8; - UTF-8 is pretty much the standard today and it will be increasingly hard to justify using anything else. Those who participated in that discussion were in favor of standardizing on UTF-8 (at least for maps, we didn't really discuss archetypes or anything else). There were no objections against it. Agree on UTF-8, it's much simpler :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Reimplementing seasonal weather.
I just had a conversation on IRC with Raphaël Quinet, relating to seasonal changes to the world. I was thinking about making an ice dungeon in the middle of a lake, that, by using the existing scripts relating to time, would only 'exist' during winter when the lake freezes over. Raphaël brought up the point, that if such a dungeon existed, it would make sense to have most of the world change to visually indicate the current season to players. Think about trees loosing their leaves, snow appearing on the ground, and lakes freezing over. snipped Nice idea, however it is implemented :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Face information for animations
Hello. When collecting the .face files, the collect.pl script will only write fg/visibility information for faces outside animation, and not all faces. On the other hand, when an animation is defined into an archetype file, the visiblity/magicmap is set for all faces of the animation. I'd like to fix that so the various animations can be factorized into .face files, with the face information (color_fg and such), that doesn't really belong to archetypes imo. Example: the 'sea' animation is duplicated between 'sea' and 'sea1' (file ground/sea.arch) - it would be much easier to have it defined in sea.face, including color_fg and magicmap and visibility, and just tell 'animation sea' in both archetypes. Opinions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Seeking life...
Hello. So, anyone working on something? Anyone having plans for working on CF? Or can we close the shop down? I admit I'm not motivated at all lately. The code is a real mess, maps are pretty boring usually, and the game is going nowhere. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Seeking life...
To sum up a discussion on the channel this morning: - there is no common goal, so everyone is doing his own stuff - there is no leadership who could define areas solutions: - define a common goal = need some leaders - enforce content rules (reject maps that don't integrate into the timeline / overall story) Nicolas Le lundi 03 novembre 2008, Mark Wedel a écrit : Nicolas Weeger wrote: Hello. So, anyone working on something? Anyone having plans for working on CF? Or can we close the shop down? I've been fairly busy for the past few months on a kitchen remodel which took away my time from other projects - that's finishing up just now, so will be getting more into crossfire work again. I plan to resume work on rebalancing the spells. I admit I'm not motivated at all lately. The code is a real mess, maps are pretty boring usually, and the game is going nowhere. I can certainly understand some of that. I've run into th same feeling now and again. The one that we usually always come back to is new maps. As a long term player/developer, I've played most all the maps, and playing them over and over again isn't that interesting (when I do player commercial games, I'll tend to play them through once - it doesn't really interesting me to play the game again with a different character or play the same areas over and over again with that first character - I might go explore areas I haven't done yet, but more often than not, just stop playing that game. Given how often I play such games, that tends to work out - something new will come out. At some level, it is probably unrealistic to think that new maps can be created at a pace faster than they can be played - a lot of map makers would be needed. It takes quite a bit of time to make up a good map - certainly longer than it takes to play it. And perhaps the other side of that is that it can often be difficult to come up with good maps. Everyone could sit down and spend several hours a week doing new maps, but if they are uninspired maps (more of the same), I'm not sure how much is gained. One could just play the random maps for that type of experience. The flip side is that many of the maps are so old that they predate many features since added (lighting immediately comes to mind, but probably many other aspects), so even new maps of the same type of things may still be an improvement. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Seeking life...
Hello. The harder part is perhaps that first one - finding leaders. I wouldn't mind being coding leader, but then right now the conditions aren't really met. Code is here to be used for the game, it is not the game. Therefore, if there is nothing going on game-wise, then it's no use having a living code. I do admit liking coding, which is sometimes more important for me than content, unfortunately. Therefore we'd need a good game content leader who can make the game really fun and drive development needs. I mean by content leader someone who can point out needs to be filled (missing a town linked to such and such story), accept or reject (saying why it is rejected) content submissions, who takes into account the whole coherence of the world and the background story, and such. And lately since there is no new content, no need to drive the development, nothing really going on, coding for CF has become some really uninteresting idea (and I admit the code is starting to be quite messy which is not helping, either). For the record here is what I'd like to do technically-wise: - stable server, few bugs (obvious, and not that far a goal right now) - distributed server, crash-recovery systems: server crashes, clients dynamically or transparently switch to another and go on playing maybe without even noticing - at least with minimal loss - dynamic updating of resources - no need to recollect archetypes to take into account an archetype change, or a pic change - regular releases (anyone remembers when the last one was?), as long as there is justification for that and in coordination with content leader And to achieve this: - well documented code, potentially linked to game features (monks shouldn't be able to wear weapons: how is it managed in the code, at which places? and such things) - unit tests where applicable - automate many things (win32 building and packaging, ...) - split the code to make it less messy. Do small atomic tasks, and chain them, instead of having one big code mess that does a zillion things and can't be easily replaced - move to C++, use Trolltech's Qt toolkit, and make a massive code refactoring (note: please don't start discussing those last points / how I'd like to do things, this is not the thread for such a discussion that I will happily ignore anyway) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire Resource Editor
Hello. I've just committed to trunk utils/cre a first basic version of a tool I've called Crossfire Resource Editor. This is for now a mere display of animations, archetypes, treasures, artifacts, alchemy formulea, but it may someday become something enabling edition (simple things like formulea aren't that hard I think). There is some framework around that, don't worry if you find buttons or such. This tool is written in C++/Qt (probably requiring a recent version of this toolkit), and is not part of CF's standard build process. Just cd utils/cre qmake make to build it (need to have CF itself built before, at least the common directory). Suggestions for improvements are welcome, bug reports too :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Seeking life...
Are we sure it is a good idea to make that ? Quoting what somebody else said about such an idea: I figured it would detract from suspension of disbelief and immersibility of the game Something I tend to agree with. Thoughts ? I would say it really depends how it is written :) On the other hand, it would be nice to have explanations for word of recall, the bed to reality, death penalty, and such ^_- Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Gameplay
As an add-on to that, I'd still like to see a quest management system that also provides rewards in exp or spells or the like, so that the only way to get that isn't by killing monsters (this can also be done now just by updating maps). Yet again I'll remind you: YOU CAN ALREADY GIVE EXPERIENCE FOR SOME EVENTS See http://wiki.metalforge.net/doku.php/dev_todo:experience_rewarder But of course no one is actually using it, not like it's useful is it? Also, I'll YET AGAIN tell on the list that, if map makers actually need scripts, I'm ready to write them, or help when needed. BUT I WON'T WRITE SCRIPTS FOR THE SAKE OF IT, IT MUST BE FOR SOME SPECIFIC NEED - I'm fed up writing things for the sake of it that no one will use. Nicolas, pissed off -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Turning transport
Hello. I've just committed an archetype, a test map and some server code enabling to have transports that don't occupy the same space depending on the facing. Check arch/transport/turningboat.* for an example, or maps/test/boat to see it into action. Warning: this only works for a transport that is defined as a square (the code will simply *assert* if this isn't the case - you don't want that :)). Basically, the server will update the move_type of the various parts according to the direction. This is slightly hacky, but I can live with that (for now). Note that, in the future, it should probably be expanded to eg monsters. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] C++/Qt server version
Hello. I do plan to have a C++/Qt (core only, no X dependency) version of the server, with advanced stuff (dynamic archetype loading, ...). I do expect / want this version to become the official server (winning on features, hopefully :)). But I definitely don't want a fork, so I'd like to work on CF's SVN server. So two options: - I work directly on trunk - my preferred option, considering it's unstable since some years, and doesn't seem to be soon stable, not much work going on it - I make a branch and work there - and if needed / when we want we merge to trunk Opinions? Note that this isn't for tomorrow, some stuff to finish before, maybe in a few weeks :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
I have seen C++ messes that I would hate to see in CF, but then it is well known that you see current CF code as a mess in itself, so perhaps it has potential for cleaning up the code... Well, that is one of the points of the rewrite I'm proposing, indeed... I depend on trunk not being broken so that I can test and develop things on trunk. I no longer have interest in working on branch. I play only 2.x servers. I do not want trunk broken (for long periods) as that will only be a detriment to play testing and developing what is on trunk now. This is how I work on content - a topic on which you are most vociferous. Yes, I'm vociferous on content. It seems lately some moves are made in this field, so I'm trying to prepare the (bright !) future for the ambitious content people are thinking of :) (something that current CF code doesn't always enable us to write easily, IMO). But the (partial/full/total/global/[insert word]) rewrite I'm talking about is not immediately, it's in some months, after some design work and such. From the various points on this list, I think I'll work on a separate branch, so it's easier to work on content. (and as you I try to not work on branch/1.x anymore) While I recognize branching is a pain at times from my libglade effort in the client, it is my preference if I read your intentions correctly - it sounds basically like a huge rewrite. Whether the branch be of the whole project or only portions that will be broken for some time is not really a concern. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Seems like a sort of odd decision since most recent conversations have seemed to have decided that more content and less code work is what is really needed to be done, but this seems to be a big code project... Yes, it has the potential to be ambitious. And just given the size and changes of the project, I'd like to see more detailed information - this isn't a minor change being made here. I plan on having design documents before coding, so hopefully we'll have time to think things over. So I can't give much details now, as I don't know them all :) Is that a satisfactory anwser? :) I also wonder that given such a rewrite if maybe a more drastic approach is needed. IMO, one reason for the messy/bad code is to maintain compatibility - new things are added, but don't want to break old maps/archetypes/whatever. I think some things could be simplified a great deal (or made more efficient) if it was considered OK to break some of that compatibility - this may mean lots of maps need updating, but if you're going to do a major rewrite, it may be an overall plus just to give up on some of that compatility for clean code. Indeed, but then let's do the whole thing and convert *ALL* things. One of the reasons for the mess is that people (me included, quite certainly) don't do the conversion globally, and only change a few maps/archs, thus we need to keep old compatibility code. I do remember a long time ago someone else looked at doing crossfire in C++, and his decision was basically to do it from scratch - better to write something that meets the functional spec than to try and figure out what all that code does, etc. But that is clearly a larger project. A plus is that with a complete re-write, one could at least architect it for certain things. But then you start asking questions on what is crossfire really, etc. As Yann mentioned in another mail, rewriting from the ground up with copy / paste can be a solution. I think it sort of depends on the expected development model. But I'd generally say do it as a branch. If individual changes were limited in scope to a few files and were basically complete at each commit, then maybe working directly in trunk would be OK. But changing languages would seem that that is less likely case. . The flip side is also that if not many changes are being made in the trunk, it should generally be fairly easy to keep up to sync (there aren't changes be made that requires syncing up, etc) I think it'll be on a branch, yes. I do have some concerns like Kevin's, in that the rewrite could take a long time (I have no idea on your expected schedule on this, so maybe not). I'd actually be more concerned that the trunk gets left in some hybrid state - some stuff rewritten, some stuff not, and unclear if having 30% of it rewritten in C++/Qt and rest be old C is better than 100% in old C. Doesn't matter. Current C code builds in C++ easily, so no is that C or C++? philosophical question :) (and that's not a theoritical reply, I did test a few months ago - code didn't change enough to warrant another test) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Well, one thought, is there any reason Qt-core as opposed Boost C++ perhaps? If I understand correctly, they provide similar faculties but Boost C++ also provides some rather nice looking python bindings that may make it far easier to move cfpython to a C++ code style. I'm not saying anything is wrong with Qt-core, and I've never actually used it or Boost C++ for that matter, but I'm just wondering if should maybe be considered, as it may have merits. That said, as you're likely going to be the main person in this code effort, simply having more experience with QT-core than Boost C++ can be a significant and quite valid factor. I'm not a Boost specialist either (and that can have an impact on my preference for Qt), but from what I gather, here are Qt features Boost doesn't have (someone will correct me if I'm wrong): - multilanguage support - GUI classes - modular, so you can disable if not needed, and if you need you're using the same base classes - image manipulation - crossplatform build system Note that C++/Qt and Python interact decently with some tests, there doesn't seem to be any issue there. Not too much of a strong opinion, except that if you do work on trunk there should be either a tag or branch made for the current state of trunk. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Hello. Ok, from what I gather, people aren't against massive changes on the server. Reminder, though: content goes first, always :) So feel free to ignore all the technical aspects if you only want to make content :D So here is what we'll do: - put on a wiki page what kind of game we want (quick gameplay? slow combat? combat only? other things?), so we all know what we aim for - put on a wiki page features we want from a technical point of view - put down design ideas for those features - select which one we'll use - then decide whether to start from the current base, from scratch with copy'n'paste, what to use, and so on I guess I'm the one to start the wiki page, since I launched the discussion in the first place :) I shall do this soon, just a few things to think over before proposing things :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Hello. I've put a first basic draft at http://wiki.metalforge.net/doku.php/dev%3Aserver_design The first step, though, would be to define the exact kind of game we want, obviously :) Feel free to tweak the page and add stuff you think is missing! (note: the dates are informative, can be changed by some days/weeks if needed - but I don't expect those design steps to take years, actually) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Hello. Reminder, the page http://wiki.metalforge.net/doku.php/dev%3Aserver_design and specifically the 'player-wise' section is waiting for you and your ideas! :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] What about a gameplay revolution?
Hello. Here are some propositions to make CF a different but hopefully funnier game :) 1) Don't give out stats to players. Don't give HP/SP/GR/ whatever. Only give hints about the health (you feel very bad, you bleed a lot) and such things (with great effort you take the armor, but fall on the ground trying to put it on) Rationale: we're doing a game, not some financial computation. Also, players should feel whether they are ready to tackle dragons or are doing damage to an opponent, not merely check stats. Of course, internally, the game could (should) still use numbers/stats. 2) Make attack/defense and other things just numbers with the rule the higher the better. Attack 50 vs defense 50 = 50% chance to hit (or something like that). No is it wc which is better lower, or ac?). In the same way, make weapons +1 just give some attack bonus, that's all. 3) Don't give so many powerful items. Have players actually create such items, with difficulty, so they need to take time (or buy it from other players). Makes a craftmanship or even alchemy skill much more interesting. Want a sword with fire damage? Go find a rare stone of fire or harness the power of a volcano to make such weapon. 4) Reduce loot a lot. Don't put chests everywhere just waiting to be opened. Have stuff randomly grow on trees or plants, fish from sea, mine ore to build items, find stones to build buildings, whatever. 5) Remove map reset. A player destroyed a map? Well, another needs to rebuild it ingame - or let an NPC do it. That costs money and time, that's fine. And no need to rebuild it the same way :) Just some random thoughts. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] What about a gameplay revolution?
If the human players were spending bunch of time doing calculations (like in live action games), then simplifying such things may make more sense. That is the point, I think: a fun game isn't a calculation game. So why put calculations we don't need? :) Likewise, if the game was much more an adventure game, then maybe not having stats would make more sense (by adventure game, I mean games where the focus is on exploration and solving puzzles, like say myst, and not killing things). Maybe that's somethine we should consider - remove some hackslash aspect, make the game more strategic, have more time to think about what you want to do next. I'm also not sure if removing stats would help out in your dragon example - the real problem in many cases when you first go to fight something is no idea how powerful it is. In many cases tough monsters can be found in areas with much weaker monsters. Then that needs to be fixed :) I think WC is the only thing that violates that rule, correct? And the reason it does so is because it was based on the old ADDv1 version of THACO/AC (or so I believe). I'll note that ADDv3 actually fixed that - higher the AC, the better. Likewise, the idea of WC basically went away - instead, you just have a bonus to hit. Ends up being very simple - if d20 + to hit = AC, you hit. Making that change in crossfire is IMO a good idea and would be really easy to do - one could easily enough write a script to go through and replace wc X with hit_bonus 20-X (with the script doing the calculation). Likewise, a similar change for AC could be done (new_ac = 20-X) Actually, I was more thinking like: if attack == defense, 50% chance to hit. Attack defense = more than 50%, capped to eg 90%. Attack defense = less than 50%, capped to eg 10%. Maybe not linear progression, but that can be adjusted (and 50% is some value I didn't think about, can be adjusted). Also, you could have 'sword +1' = +5 bonus to attack, or +10, something like that. Agree. Too often in maps/quests, the final reward is some artifact type weapon. It would be more interesting if these were components or pieces to make up really good weapons. And ideally give out very few static rewards (meaning that you always get item X from some quest - make it a treasure list of maybe 10 different items, etc) What about something like you need to do 10 quests to have all pieces needed for a powerful weapon? Each quests only gives one piece of the weapon, 10 needed. But that still doesn't address the issue of map camping or leveling up. I don't know if the problem is so much the amount of loot, or more the lack to spend it on anything. I know there are some exceptions - guild houses go up for auction, and you can spend lots of money if you want your apartment a big bigger or quick exits to different maps. But even many of those are one time upfront costs. At some point in my adventuring, I just don't find anything in the shops to buy very often - I've gotten all the spells, the likelihood of actually finding any decent items in the shops is low. So that money just piles up. I think that is really the problem - unless there are more useful ways to spend money (needed for adventuring gear) it just accumulates. Many things can be thought of. Apartment rent. Weapon/armor reparation. Potions to buy, or ingredients. Or lessons to level up or improve a skill. How do you handle dungeons? Once someone does the goblin quest map, no one can ever do it again (who is going to repopulate it with monsters, etc) Have some algorithm regenerate the map at some point, in a different shape? Mostly, make the world dynamic, with population variations and such (you trashed many orcs? hard for them, not many to see around - will become again visible later on). One could perhaps make more of the maps persistent on a per player basis (basically store them as per unique maps). So each player could only complete certain maps once. What I don't know how to do in that cases is parties where someone has done a map and other folks haven't (or suppose it is a big party, and several folks have explored a map to some degree). Clearly parties should be able to explore the same map if they wanted to. Yes, there's the party issue. IMO we should improve a lot how party work, to make it funner too. I think one current aspect of the game is 'everyone wants to be a hero'. If we want to keep this, of course we need to level up or such. If on the other hand we want something else, then maybe not everyone needs to be a hero :) One other point that was briefly discussed on the list: currently we lack a content and gameplay leader (not necessarily the same person, but well, maybe easier). Basically we need someone who can drive the game in some direction, and decide things (yes, those maps are great, accepted, could you add some more background story, please?, no,
Re: [crossfire] [ 1876788 ] Doubled characters in GTK clients (closed)
Hello. All GTK clients on trunk and branch are now considered free of the infamous and elusive double-character bug. i586 clients were tested at SVN r11002, and x86_64 clients were tested at SVN r11012. Nice, thanks for the fixes. Whomever builds the Windows client might want to rebuild a new snapshot. I'll try to find time for that. Lets also consider getting the trunk clients built and in distribution. I have auto-build scripts that make it pretty easy to generate both branch and trunk client RPM packages and and tarballs. Windows builds aren't that easy, unfortunately (I think), so making single-click scripts may not be that easy. I also would like to see the trunk clients become the new stable clients before 2.x goes incompatible with branches/1.x. I am willing to pitch in here as demonstrated by this drawn out debug. I've got many many hours into these clients and would like to see that effort acknowledged with a release. Sounds ok for me. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [ 1876788 ] Doubled characters in GTK clients (closed)
Whomever builds the Windows client might want to rebuild a new snapshot. Done and published. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Release 1.12
Given that we don't have anyone wishing to coordinate content and maps and make them coherent and fun, I have no intention to do massive changes to the code, so that question is probably rhetoric :) (unless someone else feels like doing such work, obviously) That's not true... I thought gros was going to do that... if he won't for some reason I already said I'll volunteer too. Yann dropped the project. And I didn't know you volunteered :) To be clear, let me yet again say what I mean by content leader: someone who gives the overall gameplay style (fast combat? strategy? much loot?), the overall content (medieval fantastic? futuristic?), is willing to decide (arbitrarily if needed - and assume this decision against flames sure to come by) whether maps fit or not in the game, ensures background stories are correct globally, probably sort out gameplay-related feature requests and things like that. To be honest, not some fun part, I'm afraid, but something requires IMO to ensure a correct game experience. (and not saying the content leader must do everything alone - of course other people can help, but the content leader is ultimately responsible for the global vision of the game) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Rebootworld] The true (hi)story
Hello. = Core history of the new Crossfire world = snip Based on your history, I wonder: - will we have research lab on magic/technology, aimed at improving the powers of this new world? - where is the super technology that was used to create the new world? - why do inhabitants of this world fighting, instead of cooperating to become more powerful? - why aren't inhabitants formed to this history during their childhood, and left in ignorance? you'd definitely want endoctrined people to work together and don't waste time fighting each other Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Platform statement
Happy new year everyone! Actually, I think I'm over-reaching here. All considerations of *how* to deal with gameplay, especially game mechanics, are just IMHO and suggestions. I'll say what I think, reply on threads when asked, but in the end, go with whatever the coders decide :-) No. It's not up to coders/developers to decide. It's up to the gameplay leader to decide game mechanisms. And no gameplay leader is why no one decides anything on the type of game we have, why so many questions aren't replied to, so many things are left as an exercice to the first one to actually move (meaning no coherence yet again). Remember: technical stuff is there FOR THE PURPOSE OF GAMEPLAY AND CONTENTS. Not the other way around. Content and gameplay should state requirements (features, ...) and have a feedback from the technical part about feasability/delays. So to sum up: - content leader = handles the story part of the game, maps that are ok or not story wise, and such - gameplay leader = handles combat mechanisms, has a say on quest rewards and such, works on non combat stuff, ... - technical leader = ensures needs of content/gameplay leaders are met, and maybe planifies development and such (of course it's not a total division, everyone can make suggestions - but at the end of the day the leaders ACTUALLY DECIDE on their domain) And we could obviously add interface/client leader, too. Nicolas PS: to reply to someone's mail, no, I don't want to be technical leader as long as we don't have a gameplay leader - and even so, I'm not sure I'd accept. -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Leaderships(s?) (was Re: Platform statement)
So, tell me: - what should chaos attack do? - how are wc and ac related? - what is the meaning of speed 1? - I made a map with this and that reward with those statistics, can I put it into SVN? - who will decide? - I made a patch to enable players to create items from other items through alchemy, is it ok to be put into SVN? - who will decide? - I made a patch so poison attacks aren't a one shot, but actually poison the player for 1 to 10 seconds - who will decide to put that into SVN? - here is a pickaxe to destroy walls, can I put it into SVN? (not necessarily what does it do right now?, but what should it do in the ideal game we're making?) As you said, this isn't a democracy, and latest discussions (and the lack of conclusions) should show that we need someone to actually decide when needed - so a gameplay leader, and a content leader, both are needed. And I don't worry for technical leadership - there are enough people willing to code for Crossfire, besides the code is enough for now for most things planned in the next releases. Nicolas Le mardi 13 janvier 2009, Lalo Martins a écrit : quoth Nicolas Weeger as of Tue, 13 Jan 2009 19:17:18 +0100: - content leader = handles the story part of the game, maps that are ok or not story wise, and such - gameplay leader = handles combat mechanisms, has a say on quest rewards and such, works on non combat stuff, ... - technical leader = ensures needs of content/gameplay leaders are met, and maybe planifies development and such PS: to reply to someone's mail, no, I don't want to be technical leader as long as we don't have a gameplay leader - and even so, I'm not sure I'd accept. Okay, sorry, but this is not going to work. For years, we had just one project leader. That worked in its time, then as Mark got busy with real life, things slowed down. Recently it has been proposed to have separate leaders for code and content. A volunteer appeared for code, but then the need for a content leader was played; quite reasonably, one volunteer claimed he didn't want to go far as code leader unless there was a content leader. So I volunteered to take the job. But now there's a third position that has to be filled as well? And even then we may find we still don't have a coding leader? Come on, people, we're getting nowhere this way. At this point in time, I don't think we even have enough people working on it to be talking about leadership. These are the important questions that need to be asked with regards to people resources: - Who will make content releases? (me, I guess.) - Who will make server releases? - Who will make gtk client releases? - Who will make java client releases? - Who will fix content bugs? - Who will fix server bugs? - Who will fix gtk client bugs? - Who will fix java client bugs? Only after those are answered, are we prepared to talk about adding new content, new features, or even massive rewrites. Oh sure, we could just declare 1.x abandoned; but considering all the cool stuff we have in svn, that would be a waste and a pity. All right then, to Gorokh with this. Here's my new proposal. Short term: I'm naming myself release manager for the 1.12 mini- project. I'll get a release out, code and content. The extra work in carrying the code release through childbirth may (probably will) mean missing the March 1st deadline, but I'll give it my best. I will *not* attempt to release clients, though. If someone wants to coordinate a client release, I'd be very happy and lend my support. (Kevin?) Medium term: I think the best thing to do, as far as separation of work is concerned, is to view this as a number of separate sub-projects: - Server (code and content) for 1.x - GTK/glade client (based on v2 I assume) - Java client - Gridarta for CF - Server (code and content) for 2.x (possibly later) Each of those should have someone taking responsibility. (Gridarta already does, and the Java client unofficially does too.) The necessity of a master overseer over the whole project is arguable; I think the sub-project leaders can work things out between them. But for now, let's concentrate on a release. My hope is that the work involved in doing that will wake us up, and that the right people for each position will rise up in the process. Frankly... this whole thing is silly. Free/Open Source projects aren't representative democracies; it makes no sense to be arguing about who will lead what when there's work to do and nobody to lead. Let's go get this release out. Please. best, Lalo Martins -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo
[crossfire] Feature proposition: [img] tag
Hello. I'd like to suggest a [img name=xxx] tag for client-side rich tags, as defined in mediaTags. As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). What do you think? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] How to integrate old stories in the game?
Hello. How would one integrate old (as some hundred years old) in-game stories in the gameplay flow? Right now, we have kind of the Know-It-All sage who will conveniently know everything of things that happened hundred years ago, without any mistake or such. Things I could envision: - old manuscripts, in languages a player would need to learn to decipher - wrong (plain or slightly mistaken) things around, to have the player try to figure what to trust - partial stories only, leaving the rest to deduction. Opinions? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Changing connection texts
Hello. Suggestion to change the various messages at login: Hello you nice soul, and welcome to this world. My memory is slightly blurred lately, could you tell me your name, again? [prompt for name] If new player: Ha, you're not on my registers, so you just had the authorisation to incarnate on this world, he? My name is [find name], and I'm here to help souls incarnate. [if perm death] Please note that on this world your corporal incarnation will be destroyed if you die, so take care. [if reincarnation] It could be recovered, but you'd need help from some nice soul. [if not perm death] You're lucky, here even if your corporal incarnation dies, you can still use it. Nice, isn't it? Anyway, now you must choose your corporal incarnation. I hope you'll enjoy it, whatever you select. If current player: Ha, nice to see you again. Now if you'd be so nice as to prove me you indeed own this incarnation? [prompt for password] What do you think? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] How to integrate old stories in the game?
If one were to go on this logic,than for any given message, it would be reasonable for what the player sees to vary based on literacy. I was thinking of script-based text garbling, actually, but your approach works too. I do agree that some way for the player to handle/deal with these messages would be nice. I use to resort to copying information down in another window, but that takes things out of the game experience. One could imagine something like a special folio object that holds all these - the issue is still how to present them to the user. Client issue that can be fixed. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] How to integrate old stories in the game?
A segue to something that has bothered me a bit: there are no longer any closed houses in Scorn, having been replaced with randomly generated ones. However, there is not much point in visiting them, as they are only single- level places with the randomly-generated paraphernalia. If you are very lucky, there might be a treasure room or some such, but otherwise they are fairly pointless: no monsters on the first level, nothing to do, nothing to see... How about someone working a bit on the generator, for example have the ubiquitous bookshelves actually occasionally contain something useful? I'd rather see real maps. The random map generator (which I did) was mostly supposed to compensate a lack of maps. If people do make maps for all houses, then the plugin isn't useful anymore :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
One question would be: What do you do on wrong password? A not too uncommon situation is you have a new player who is trying to use the name of an existing character. We probably want something that is clear that the existing name is in use, but at the same time isn't too confusing if they just mistype their password. Hum, I'm sorry, but your secret phrase doesn't match what I have written in my book. Could you restate your name, please? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] How to integrate old stories in the game?
It seems these kinds of ideas are good, though I'm not to sure about wrong information without some not insanely hard to find way to validate wrong data. Of the listed ideas, the first seems most likely to enhance play. The last seems reasonable, though perhaps better done by having the missing pieces completed as a related quest progresses as though the player is rediscovering the history through the act of digging through and using this partial story data. Validating wrong data is easy - go to the place, see there is no entrance, go somewhere else :) Without really claiming to have a vision of how to pull it off, perhaps the wrong/partial ideas could be supplemented by a mechanism by which a player can actually accumulate the stories client side for perusal in more of a book fashion instead of the encumbering NPC communication model. I think that the lore and quests in this game are hard to handle because there is no practical way for a player to manage the information in more than a piecemeal fashion. Adding wrong and partial stories seems like it could go the wrong way if something was not done to balance it out. Well, for one, players do have a brain, and they could use to remember the stories :) Writing sufficently fun stories would make it worth remembering them, IMO. Though a good solution could indeed be to have client-side recording. Pieces of stories could have identifier tags of some kind that would allow them to be fit together into a document on the client. Wrong information could have the same tag as good information - causing the player to have to decide which one was right when both were found. I'd rather have the player organize tidbits herself. No point in saying exactly what story a piece of text refers to, IMO. Agree that wrong information is more realistic in some sense, but am reluctant to get too realistic in this regard as it can frustrate rather than improve the player experience. This game is based on a fantastic world rather than a realistic one. So? Fantastic prevents wrong/distorded information? :) As long as the searching itself is fun, it should be ok, I think. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] What to find in towns, what to find in the countryside
Hello. Right now there are many houses / maps in the various towns which have monsters. What about moving all that outside the towns (which after all have guards and such, and should probably be safe places?), and putting them in the country side? Except maybe some mice or dogs here and there ;) This would leave the town with many houses to put NPCs, have shops, things like that. And increase the number of stories to tell to players :) What would you think of that? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
Hello. Suggestion to change the various messages at login: Apparently, those messages are part of the motd / server rules / news. So they could be changed as part of the default installation, but not that useful for existing servers. It's probably more a client-side modification. Or maybe a complete login rewrite is in order ;) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] How to integrate old stories in the game?
Obviously real maps would be the best solution. However, I think the random map generator does a fair job, specially on the multi-level dungeons; IMHO the different Scorn quest maps turn out nice and exciting. The fact that it does as reasonable a job as it does means that it might be worth putting a bit of effort into enhancing it... Then maybe a base map, with random books and such? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
More likely want to have something like an img tag with hints, for things like popup, desired size, etc. Then let's do the whole trick and use some XHTML subset? Note that anything that deals with popups can be annoying in some areas. If you read some scroll and it suddenly popped up a window, I'm not sure I'd like that. It'd probably be better as a default for the message to just be displayed, something like 'This scroll contains a map. Click on map image for a larger view (small map image displayed)' Client-side issue. My opinion: let's implement the tag in basic form, use it, and adjust later if needed. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] How to integrate old stories in the game?
I think we have sort of learned over time that coding in such solutions tends to lack flexibility we generally desire, or don't give as good results as we might hope. We could certainly have script based text garbling, but having it do it so that it doesn't look like something that was script based would be hard. Randomly replace a word by random letters, with the same length. That'd do the trick, no? I don't think this is a pure client solution. That's just my thought. It's never really clear where the split between client and server is. But my thought is something like this: On the server side, there is something like a folio object which characters can put all those different notes into. Perhaps there is even code to see if the character already has a copy of that message. This could basically be just a container object with some special handling. On the client side, it perhaps brings up a window which shows everything in the follow, so you can quickly read through it. Maybe in the form of a book which you just page through. Then let's find a volunteer to code that server side, and implement client-side too :) Ideally, each written note would have a title, so there could be a table of contents. Things like 'Dungeons of the Deserts', 'Monsters of the Southern Forests', 'Characteristics of Ogres', etc. I'd add options for the client to manipulate stuff around. And also to copy items to give to other people - if you have paper, and if you have writing, the higher the level the lower the probability to make copy mistakes. While this could perhaps all be handled on the client (when you read something, it automatically records that information in a file), that doesn't seem ideal. The information we are talking about here is really character information - while there is nothing that prevents one from sharing this knowledge, I just don't think it would be a good user experience that if you switched to a different client (or perhaps same client running on a different machine), you've suddenly lost all that information. Sure, server side. We'd need a way to identify uniquely a message, though, which I'm not sure is something we already have. Messages randomly generated, and also messages from /lib/messages Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
While you may jest, I still think that last comment is true. As a very basic level, the client could request both the username password at once for login, with another button with something like 'create new character' Depending on what the user does, gets appropriate results - while I've advocated rewriting the character creation process, that wouldn't need to happen in this case - if the user clicks new character, it just dumps them in the existing character creation area (but the messages there could perhaps be customized a little better 'Enter desired character name', 'that character name is already in use', 'Please enter password for this character', type of thing. If the user instead tries to login with invalid character name/password, it should just print out a message like 'incorrect login', and not try to create a new character for them, and try again - if the user really wants to create a new character, they should explicitly have to hit the 'create new character button' What I'd suggest: - introduce user accounts, to group characters - let the client gather login, check if account exists, then either ask for password or help create account After logged in with user account, let select character or create a new one. Maybe ingame already - like in a map. Any volunteer to code? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] What to find in towns, what to find in the countryside
Certainly for scorn, as that is a starting area, it makes a lot of sense. And a lot of the monster maps in scorn don't make a lot of sense. For navar city, there are several quest lines that sort of go with some of the maps in the town (old wizards tower, smuggling operation, etc). But those are also better in that for the most part, there is some sequence so you just can't wander into a random house full of monsters. I'd remove all monsters from town, or at least hide them. Or make them non aggressive, and they start attacking if player attacks. Or else we'll need to explain why the town guards are that incompetent! :) In terms of the NPC's, I think that can work. However, I wouldn't like there to be NPC's giving quests (not that we really have quests, but you sort of get the idea) that you have to hunt through all the houses. I think a method where most of the NPC's may have some basic information (so that for example they may have tales of haunted houses, etc) is good. Or for that matter, if there are NPC's in the houses with unique information, maybe some of the common knowledge would be about that person (Bob over there is looking for someone to ...) Well yes, you're supposed to know what your neighbourgs are up to :) That'll require much work to link information, of course. So, anyone willing to rewrite the in town maps? :) I'd start with Darcap, since there aren't that many maps. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Hello. I agree that you probably want other text - only popping up an image is not useful. Up to the map designer putting the text :) Older clients pose more an issue. If you are doing something like maps, it seems fairly difficult to try to support that with old clients (you could perhaps do an ASCII map). You also get the case of you probably really don't want to display that ASCII map if you can display the actual PNG image. We're talking about trunk, so let's forget older clients. We should take the opportunity to break things. As long as the major clients support it, I think it is reasonable to state that there is no requirement to be backwards compatible - I think that adds a lot of complication, and it is simpler to just have the users use the latest client. Yup. As for the rest, client side issues for most. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
Hello. Should some game things maybe be made account wide properties and not character properties? Off the top of my head, I could think of things like apartments. KISS for now. Let's just make an account, we'll think about shared apartments later. Though I'd rather have shared apartments decided by players - so you can have one apartment shared by all your players, and also another shared by various people. Like a guild, that is :) I don't really like an in-game solution. While easy to do, and easy for all of us to deal with, its not great for new players. Menu driven is fine, then, and not too hard to do, I'd guess. But I'm also not sure if your ingame comment refers to selecting a character to play or creating a new one. For creating a new one, we could perhaps leave the existing mechanism there since redoing is more work. But making in game (map based) character selection I think would be more work than just doing the appropriate dialogs. Current creation mechanism sucks. Yes. It's bad. It's evil. If only because first you choose stats then class - which then uses some stats more than others. So let's take the opportunity to rewrite the character generation mechanism. Question on accounts: Where do we store this information? May be a flat file or dbm file or something? After all, the only information associated with an account is the name, password, and characters for that account - not a lot of information here. But flat files don't work good if you have thousands of entries. Flat file seems ok for me. Obviously, I could suggest an abstraction layer with a pluggable storage mechanism being DB/file/..., but in C that'd be a PITA to write :) Step B: Character selection: 1: Player can choose from existing characters (display names), create a new character, or associate an existing character with this account (after all, for all characters existing before this change, they won't be associated). 2: If character selects existing character, just load up that character and play - assume that if the character has been set up for account, there is no need to check password, etc. 3: If player creates new character, basically same as now, but we don't need a password - like #2 above, since the character is associated with an account, we use that password. 4: If player needs to associated a character with this account, and for character name and password. See if that is correct - if not, error out. If so, verify that the character is not already associated with an account (if so, give them an option to associate with this new account?). Once player associates character with account, go back up to B.1 - player may not want to play that character immediately - I could see a case when first creating the account that you want to associate all your characters with it. Seems ok. Note also that within the client, in addition the existing logout, there another option is needed. Logout could be as it is now - logout and go back to metaserver selection. But also log out character and go back to character selection - should make it somewhat easy for player to choose which character to play. Yup. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player level vs monster level vs experience
That is how I see it - monster level and player level should roughly match. But in this context, I'd sort of say a group of monsters and player level should roughly match. For example, at first level, the character will be fighting typically large groups of level 1 monsters, it's not a 1:1 battle. But that first level character might be able to take on a level 4-5 monsters on a 1:1 basis, but should die if he takes on a group of them. Then that's not matching :) A real match would be a level 5 monster being able to kill a level 5 players. Except for the most part, there are not that many things to adjust for monsters in crossfire - you do have level, hp, ac, sp, and skill levels. But if all level 15 monsters had the same hp/ac/sp, it would be pretty boring - you need to be able to have enemy wizard with a bunch of sp, but maybe not as many hp, etc. Except you could say: monsters have 1 hp / ac / sp (whatever) for level 1. Each level can give 2 hp, or 1 ac, or 1 sp. Thus for level 15 you could have 31 hp / 1 ac / 1 sp. Or 1 hp / 16 ac / 1 sp. Or 1 hp / 8 ac / 9 sp. And so on. In theory, monsters should have all the same skills as players, and those be set at appropriate levels. Right now, I think a lot of the code just uses monster level for skill level, which more or less works. I'm not even sure the skill level is really used in many cases. When I was doing the rebalance, I was basically setting a monsters exp based on its level, but there was still a range. That said, I think it would be completely reasonable to redo it - exp is based solely on level of the monster. If a monster is too easy for that exp, then it needs to be adjusted in some way (which could mean lowering level). However, keeping it a monster attribute does allow for maximum flexibility - for example, when redoing it, I basically had this as a exp value based on level of monsters: 1 10 exp 2 25 3 50 4 100 5 250 on so on. But in this model, there are some big gaps - one could reasonably say a tough level 4 is maybe worth 125, and and easy level 5 (but still harder than that level 4) is 200 Really depends on the view for higher levels. Will you have a level 100 player fighting 50 levels 99 monsters easily? Or player level 50 versus 10 monsters level 45 is ok, but 100 vs 99 is balanced on 1vs1? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] What to find in towns, what to find in the countryside
Well, Scorn also has an explanation on why neglected houses have monsters in them: the situation with Old Town. Talking about that quest, would anyone have a description? That is what items one can find, clues there are, and so on? :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Spell proposals
Hello. Here are two proposals for spells. They are not totally incompatible, but well, even only one could fun IMO :) The aim is to reduce the number of spells, and also make it more customizable for players; I'll use the fireball spell as an example. Spells with options. -- Basic idea: level 1 fireball does x damage for y ticks on z squares. Each spell have defined bonus in damage, duration, range for one level. When casting a spell, you can add options, like: 1) /cast power 20% fireball 2) /cast range 15% fireball 3) cast damage 90 fireball 4) cast range 5% duration 2% fireball 1) means add (20% of levels over 1) * y ticks to duration, the rest split between range and damage 2) means add (15% of levels over 1) * z to range, the rest split between duration and damage 3) means add (90 * x) to damage, extra levels above split between duration and range 4) is left as an exercice to the reader :) Obviously, you could then have a client-side interface to tweak spells / help define your spells. Player-made spells -- Basic idea: get a spellbook for a standard level 1 fireball. Use alchemy (or other means) to tweak the parameters like range per level, duration, and such. Ingredients to customize could be costly, or different for spells, or whatever. Once leant, the spell has its own special parameters. What do you think of that? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
Its a different topic than this, but having such a pluggable interface would be nice. The biggest pain would be having to emulate it if a real database is not available (emulation would probably mean a flat file with fields separated by something or another) I can think of all sorts of stuff to record. And if it was stored in an SQL database, one could then do analysis. What are people really buying from the stores? What spells are characters using? Where are people killing monsters, etc. For crossfire, I was thinking something like dbm (or other native file based method) could be used, but I don't know how portable such methods are on non unix systems. But looking at that, other than fast fetching of the keys, the data for that key is all stored in one field, so the server would still need to parse that out. So doesn't gain as much as one would like. I also suspect that for most servers, the size of this file wouldn't be very large, so even parsing a flat file wouldn't be that costly. SQLITE is already used by my logger and newspaper (alpha) plugins. Seems ok for me. As for statistics, I don't really care actually for now, better to develop content and such :) And maybe Zebulon (Ragnor's bot) could actually give statistics, if needed. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing connection texts
Hello. One thing I did think of might be DM access - maybe the dm_file should use account name instead of/in addition to character name? It strikes me that if you are going to trust a player with dm access, you probably don't really care what character they are playing. Yes, makes sense. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Spell proposals
Hello. snipped text Like above, balancing that can be tricky - have to be careful what you let them tweak to once again not get overpowered stuff. Here is an idea I have, which takes some of these ideas into consideration. This is sort of an amalgam of the custom spell creation in the elder scrolls games as well as a rune idea a friend of mine used for a tabletop game. Has tweaking issues like other proposals :) Anyway, my guess is that the first to implement something will define the new spell system. So feel free to implement your ideas, they are as good as others :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting rid of AC/WC
Hello. With the recent discussions on spells and this or that, tossing out this one - get rid of AC and WC (one goes with the other really). snipped So what is the rule for hitting/defending? Will there still be sword+2? +3? what about armor? What is the difference between a chain mail and a plate mail? And if we go this route (which seems good as long as we simplify the rules), let's enforce the separate attacktypes damage for weapons - there is a skeleton for that, not sure it really works. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Getting rid of AC/WC
Hello. Basically like spells - if you aim at something, you hit it. Aim in this context may just mean standing next to a monster and moving in that direction. For arrows it would be a lot like bullets, etc. One could think of it like always rolling a 20 on the attack roll (there is special coding that a 20 always hits right now). There isn't really any defending, but right now, there really isn't any defending either. There has been talk about redoing things so you have various attack options and defense options. With a slower combat method, one could make a greater case for these - in a sense, they might be like spells but for warriors - you do an action and your next attack does something special. You do more damage, but your armor rating is lower (and there could be actions that are reverse of that). Or an attack takes longer, etc. But removal of AC/WC doesn't really change the attack options and need to implement them - it just changes what some of those actions might be. snipped Well, that sounds ok for me. Let's implement that, and see what it gives :) Could you maybe write that down formally, with simple rules, so it can serve as reference? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Looking at the code, something vaguely related here is character naming standards. Right now, character names are limited to letters and - or _, and the - or _ can not be the first letter. Spaces and numbers are not allowed. I can certainly understand spaces, as on unixlike systems, spaces in file names are a pain to deal with. But not sure why restrictions on numbers (like the - or _, I could perhaps see why we wouldn't want a character to start with number. But why shouldn't Mark99 be allowed? Ok by me to allow numbers. The other oddity (IMO) is that names are case sensitive. Thus, Mark and mark are 2 different characters. That to me isn't great. If I was adventuring with a person, I might remember their name, but probably wouldn't remember the details on its capitalization - it could be odd to find out the 'dave' I'm not adventuring with is not the same player as the 'Dave' I adventure with last week. Well, could make sense too, yes. So my suggestions on this: - Allow numbers in names - just the name can not start with a number. - Going forward, names should be unique in a case insensitive manner. The player can still choose variations on capitalization, you just can't have a 'mark' and 'Mark'. To handle that last one, simplest thing is to just store all character related files in a lower case version of the name (so Mark would be stored as mark/mark.pl for example). That's easy to do and solves the problem. The thing that is harder to solve is existing player files. Writing a script to rename them is straightforward. The hard part is dealing with any names that conflict (eg, server has existing Mark and mark). Unless I'm mistaking, there is no 1.x = 2.0 migration script for players, meaning people will have to restart their character. So name collision issues shouldn't matter. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Player level vs monster level vs experience
Maybe. Or just say that the level basing is that a character of level X can reasonably take on a group of 5 monsters also of level X. But as said, I think some of the failure is the AI in crossfire, so the make up for stupid monsters, there are just more of them. That's part of the game genre, no? Many monsters, not smart. Should we try to go towards less monsters smarter? Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] What to find in towns, what to find in the countryside
I haven't played it for a while, but one thing I recall is that the level range is pretty broad. Some of the undercity maps are suitable for low level characters (less than 5), while others are much tougher, with things like wyverns. So I'd probably say the level range is 0-20, but it really depends on what area you are in. One problem perhaps is that there is not enough exp to be gained here to start at say level 5 (easier area) and work your way through, to the point where at the end you are sufficient exp to complete it. If you start at high enough level to complete it, you may find some areas too easy. If you start at a level where the area is a challenge, you may find you can't complete it, and need to go adventuring elsewhere to get sufficient exp. Well, that quest could be integrated in a storyline, as per the advocated idea on another thread. So that'd be an opportunity to fix/balance the various maps. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] quest/storyline ideas
Hello. Recording for posterity a discussion in IRC about quests. I've probably forgotten a few things, but hopefully I got most of. snipped Seems ok for me. Some steps: - check existing quests, required level, existing hints - fix stuff so there is a real storyline - add hints at many places Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Darcap tweaking
Hello. I'm currently tweaking Darcap, to add some (I hope) interesting things to the town. My plans include: - move quest-related stuff outside the town - no monsters in town houses (but maybe through wells or holes) - linked characters, based on player's behaviour - improved NPC interaction For this, I'm writing a full plugin to handle various behaviours. Do you guys prefer I checkin my work now and then while in progress, or should I wait to have all finished? Please note I won't discuss the actual implementation (plugin or maps or archetypes), but I'm ok to discuss the town content itself. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Merry Christmas
Merry Christmas to everyone :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Merry Christmas
Toi aussi! J'ai vu qu'il y avait pas mal d'activitée récemment sur la liste de distribution, je crois qu'il va y avoir pas mal de changements dans les nouvelles versions de crossfire... Bonne chance! Hum, pourrais-tu me rappeler ton pseudonyme ? ^.^;;; (je suis mauvais en « vrais » nom, des fois) Quant aux changements, ça dépendra bien des gens et du « soutien » que j'ai - aussi de mon humeur, disons ;) ++ Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Darcap tweaking
Hello. Sounds like a good test city to work with. Does, or will, your work also include /darcap/town2/* maps? Yes, probably. Rewriting the elemental quest could be on my TODO list. If your changes will have a major impact on the existing guilds in Darcap for the trunk servers already out there, then it might be preferred to check in the work when it is all finished. Keep in mind the file paths for all the players who have a big chest in one of the guilds there. ;-) Otherwise, for tracking purposes - numerous smaller changes is preferred IMO. I won't change the guilds/apartments, so that should be ok :) I guess I'll commit often, then, even if experimental. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Darcap tweaking
Hello. Not sure what that means - do you mean linked quests, or something else. Linked characters. So you'll only get hints from T if you talked beforehand to Z. Or things like that. I'm presuming/hoping this plugin will not be darcap specific, and can be used for other maps as the need/desire arises? First I'll make it work. Then we'll see for reusing. I guess it depends on the status of the work in progress maps. If it is the type of thing this map/quest has been fixed, then I see no issue checking that portion in. I'd be more concerned in the case where a map is half done, such that if a player goes to that map, they would consider it broken. I'll try to do atomic things - right now, the tavern's barman is almost done. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Happy New Year!
Happy New Year to all the members of the team! May 2010 bring you inspiration to tweak maps, add content, write (and implement) good stories, and such things ;) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Dialog mode
Hello. I'd like to propose a (menu-driven) dialog mode for players. Something like what you can find in various RPG games. Description: - started when player says something to a NPC, like now - player is presented with text and options, and a free text zone (to not have all options visible/obvious) - player can't really move (or moving exits the dialog mode) - NPCs are marked as 'busy' and thus won't move while talked to - separates more the 'hack' part and the 'role playing' part - separates clearly the 'say' to trigger things / talk to other players, and the dialog with an NPC What do you think of that? :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
