From nicolas.weeger at laposte.net Fri Feb 1 14:16:27 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 1 Feb 2008 21:16:27 +0100 Subject: [crossfire] Weather code In-Reply-To: <200801302359.22703.nicolas.weeger@laposte.net> References: <200801302359.22703.nicolas.weeger@laposte.net> Message-ID: <200802012116.32207.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080201/910533f4/attachment.pgp From nicolas.weeger at laposte.net Fri Feb 1 17:15:35 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Feb 2008 00:15:35 +0100 Subject: [crossfire] What Crossfire is missing Message-ID: <200802020015.41210.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080202/b5c1bdf8/attachment.pgp From kbulgrien at worldnet.att.net Sat Feb 2 00:37:55 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 2 Feb 2008 00:37:55 -0600 Subject: [crossfire] Release announcement URLs broken? Message-ID: <200802020037.55409.kbulgrien@worldnet.att.net> The ftp sites listed in the announcement don't seem to work. > Crossfire is available on the following ftp sites > > Primary: >? ? ?ftp://ftp.sourceforge.net/pub/sourceforge/crossfire > > Secondary: >? ? ?ftp://ftp.real-time.com/pub/games/crossfire The SF link... who knows. I didn't try that hard and sometimes their stuff is hit-or-miss. Note that ftp.real-time.com has no pub/games directory that is visible. Nitpick alert: The release signature is January 1, 2008. ;-) In all, though, its good to see another release out. Some of those ChangeLogs are huge! From nicolas.weeger at laposte.net Sat Feb 2 02:34:43 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Feb 2008 09:34:43 +0100 Subject: [crossfire] Volunteer for Windows builds? In-Reply-To: <47A109DD.9030002@real-time.com> References: <200801302353.04427.nicolas.weeger@laposte.net> <47A109DD.9030002@real-time.com> Message-ID: <200802020934.47951.nicolas.weeger@laposte.net> > (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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080202/489ad2a3/attachment.pgp From nicolas.weeger at laposte.net Sat Feb 2 03:26:17 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Feb 2008 10:26:17 +0100 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: References: <200801270911.35887.nicolas.weeger@laposte.net> Message-ID: <200802021026.26428.nicolas.weeger@laposte.net> > 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080202/c12a82cc/attachment.pgp From lalo.martins at gmail.com Sat Feb 2 08:32:56 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 2 Feb 2008 14:32:56 +0000 (UTC) Subject: [crossfire] New plugin: citylife - help needed References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021026.26428.nicolas.weeger@laposte.net> Message-ID: Also spracht Nicolas Weeger (Sat, 02 Feb 2008 10:26:17 +0100): >> 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. > > 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 :) Really? From the description, I thought it did control the sims too -- be born, grow up, go from home to work and back, and so on, I love watching them on SC (although it's much more interesting in the later games of the series). > 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! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sat Feb 2 15:11:08 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Feb 2008 13:11:08 -0800 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: <200802021026.26428.nicolas.weeger@laposte.net> References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021026.26428.nicolas.weeger@laposte.net> Message-ID: <47A4DC6C.2030102@sonic.net> Nicolas Weeger wrote: > 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! Have to be careful on that one. If I'm running a private server and don't log in for a few days, it would be annoying for all the shops to be closed. Related to that you are likely to get some towns that may not be used much even on active servers - if I have a private server, I'm likely only working in one town at a time. I'd be more inclined to have towns be a bit more dynamic, but also have that driven more my player actions - eg, folks can by plots of lands outside of cities, etc or what not. At some level, if we let a player do it, then we could also let NPC's do it (some number of NPC's buy farms or whatever) From mwedel at sonic.net Sat Feb 2 15:18:09 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Feb 2008 13:18:09 -0800 Subject: [crossfire] Release announcement URLs broken? In-Reply-To: <200802020037.55409.kbulgrien@worldnet.att.net> References: <200802020037.55409.kbulgrien@worldnet.att.net> Message-ID: <47A4DE11.4070600@sonic.net> Kevin R. Bulgrien wrote: > The ftp sites listed in the announcement don't seem to work. > >> Crossfire is available on the following ftp sites >> >> Primary: >> ftp://ftp.sourceforge.net/pub/sourceforge/crossfire >> >> Secondary: >> ftp://ftp.real-time.com/pub/games/crossfire > > The SF link... who knows. I didn't try that hard and sometimes > their stuff is hit-or-miss. It appears you can only download them HTTP now days: http://sourceforge.net/project/showfiles.php?group_id=13833 as a starting point. Sourceforge has several mirrors. I'll change release notes for future. I'll likely just include those URL links in there, eg, http://downloads.sourceforge.net/crossfire/crossfire-1.11.0.arch.tar.gz And so on for the different files. From kbulgrien at worldnet.att.net Sat Feb 2 19:14:45 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 2 Feb 2008 19:14:45 -0600 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: <200801270911.35887.nicolas.weeger@laposte.net> References: <200801270911.35887.nicolas.weeger@laposte.net> Message-ID: <200802021914.45243.kbulgrien@worldnet.att.net> > 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). 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. 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? Mostly thinking out loud. From juhaj at iki.fi Sun Feb 3 02:29:38 2008 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Sun, 03 Feb 2008 10:29:38 +0200 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: <47A4DC6C.2030102@sonic.net> References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021026.26428.nicolas.weeger@laposte.net> <47A4DC6C.2030102@sonic.net> Message-ID: <200802031029.42766.juhaj@iki.fi> > If I'm running a private server and don't log in for a few days, it would > be annoying for all the shops to be closed. This should not be a problem: it should be easy to only count "active" ticks (i.e. ticks when someone is actually logged on to the server) when considering which shops thrive and which die. > Related to that you are likely to get some towns that may not be used > much even on active servers - if I have a private server, I'm likely only > working in one town at a time. This is more difficult. Perhaps the npcs themselves could help with this? Perhaps the npcs could be made to go to the shops as well? They might not need to buy anything, just enter and exit. Also, their influence in determining whether a shop lives or dies could be made orders of magnitude lower than players' influence. What I have in mind, is that if no player visits a shop in Scorn, the npcs can keep the shops alive, but as soon as players start visiting the shops, their "vote" counts so much more that if players do not go to shop A at all, the npcs' influence can't keep that alive. Some kind of differential metric between the shops, not an absolute one. An npc entering the shop is worth one "life point" for the shop, while a player is worth a 100. Then, whenever the lowest scoring shop is, say, 1000 points below the next lowest scoring, it dies. Also, this means that whenever the highest scoring shop is that 1000 above the next, it should expand its business... > that driven more my player actions - eg, folks can by plots of lands > outside of cities, etc or what not. This sounds nice. But... how do we keep track of who owns what? And how do the players find out if the beautiful spot they fancy is already owned by someone? > At some level, if we let a player do it, then we could also let NPC's do > it (some number of NPC's buy farms or whatever) Naturally, the npcs must basically be able to do whatever the players do. I'd like to see them enter dungeons themselves and join parties with players as well. Though the last type of npc probably would not be controlled by the sim code (if we choose to use that). (And I do not count the current hired hands in Scorn as npcs. They do nothing unless you hire them - not really very "c" in npc.) -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/4fca7722/attachment.pgp From nicolas.weeger at laposte.net Sun Feb 3 03:30:28 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Feb 2008 10:30:28 +0100 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: <200802021914.45243.kbulgrien@worldnet.att.net> References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021914.45243.kbulgrien@worldnet.att.net> Message-ID: <200802031030.33079.nicolas.weeger@laposte.net> > 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/bdfb2c29/attachment.pgp From nicolas.weeger at laposte.net Sun Feb 3 03:40:09 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Feb 2008 10:40:09 +0100 Subject: [crossfire] Player accounts, new player creation mechanism Message-ID: <200802031040.09187.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/65783695/attachment.pgp From nicolas.weeger at laposte.net Sun Feb 3 04:07:22 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Feb 2008 11:07:22 +0100 Subject: [crossfire] Map logical linking Message-ID: <200802031107.27869.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/c2185e8f/attachment.pgp From lalo.martins at gmail.com Sun Feb 3 11:47:05 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 3 Feb 2008 17:47:05 +0000 (UTC) Subject: [crossfire] New plugin: citylife - help needed References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021026.26428.nicolas.weeger@laposte.net> <47A4DC6C.2030102@sonic.net> <200802031029.42766.juhaj@iki.fi> Message-ID: Also spracht Juha J?ykk? (Sun, 03 Feb 2008 10:29:38 +0200): > This is more difficult. Perhaps the npcs themselves could help with > this? Perhaps the npcs could be made to go to the shops as well? They > might not need to buy anything, just enter and exit. Also, their > influence in determining whether a shop lives or dies could be made > orders of magnitude lower than players' influence. > > What I have in mind, is that if no player visits a shop in Scorn, the > npcs can keep the shops alive, but as soon as players start visiting the > shops, their "vote" counts so much more that if players do not go to > shop A at all, the npcs' influence can't keep that alive. Some kind of > differential metric between the shops, not an absolute one. An npc > entering the shop is worth one "life point" for the shop, while a player > is worth a 100. Then, whenever the lowest scoring shop is, say, 1000 > points below the next lowest scoring, it dies. Also, this means that > whenever the highest scoring shop is that 1000 above the next, it should > expand its business... Alternatively. Since the players are heroes, they could be opinion-makers and trend- setters. If they are seen favouring one shop, the NPCs will start preferring that one as well. If they avoid one, its popularity with the general populace will drop very fast... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From juhaj at iki.fi Sun Feb 3 12:14:41 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Sun, 03 Feb 2008 20:14:41 +0200 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: References: <200801270911.35887.nicolas.weeger@laposte.net> <200802031029.42766.juhaj@iki.fi> Message-ID: <200802032014.45391.juhaj@iki.fi> > Since the players are heroes, they could be opinion-makers and trend- > setters. If they are seen favouring one shop, the NPCs will start > preferring that one as well. If they avoid one, its popularity with the > general populace will drop very fast... Yea, this is reasonable, but in case there are no players around, I think my idea is worth having anyway. And when players eventually turn up, giving the players more impact than npcs could will be implemented either in the way you describe. It has the same idea as my proposal, but it has perhaps more ingame consistency in it. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/4b680732/attachment.pgp From juhaj at iki.fi Sun Feb 3 12:16:24 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Sun, 03 Feb 2008 20:16:24 +0200 Subject: [crossfire] Map logical linking In-Reply-To: <200802031107.27869.nicolas.weeger@laposte.net> References: <200802031107.27869.nicolas.weeger@laposte.net> Message-ID: <200802032016.25294.juhaj@iki.fi> > 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 > Opinions? Suggestions? I would vote for obligatory lore fields in all maps (old and new) describing the above mentioned minimum. It is extremely frustrating to stumble upon a map, especially in the editor, and not know what it is related to. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/a7bc114c/attachment.pgp From nicolas.weeger at laposte.net Sun Feb 3 16:26:52 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Feb 2008 23:26:52 +0100 Subject: [crossfire] Map logical linking In-Reply-To: <200802031107.27869.nicolas.weeger@laposte.net> References: <200802031107.27869.nicolas.weeger@laposte.net> Message-ID: <200802032326.56876.nicolas.weeger@laposte.net> Hello. I tweaked the mapper to extract some more information. The result can be seen at http://crossfire.ailesse.com/maps/slaying_info.html The page basically lists all values used for special keys, containers, locked doors. It is not complete, missing markers that make FORCEs and such, but should give a good start I think. I plan to add a few more features to the mapper tool, including maps linking to a specific map (so on a map you can see all information), things like that. But other suggestions are welcome :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080203/7456d240/attachment.pgp From mwedel at sonic.net Sun Feb 3 21:39:18 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Feb 2008 19:39:18 -0800 Subject: [crossfire] Map logical linking In-Reply-To: <200802032326.56876.nicolas.weeger@laposte.net> References: <200802031107.27869.nicolas.weeger@laposte.net> <200802032326.56876.nicolas.weeger@laposte.net> Message-ID: <47A688E6.3020801@sonic.net> One thing I have been a long proponent for is proper naming of the special keys. Many maps provide some information (rusty key, big key, etc), but many other maps don't - you just get a special key. Perhaps as part of this, maybe include the map name in the msg field. So that if I have a pile of strange keys in my inventory, named or otherwise, I can examine them and find out that this key is from a random set of maps, that key is from the navar city lighthouse, etc. I can then know how much I care about any of them - if I'm not working on that set of maps, that key is useless, and I can get rid of it. It can be annoying to have a bunch of special keys, and you may be working on some set of maps, but still don't know how they relate. That even holds true for keys that have been named - 'rusty key' at least lets me differentiate it, but I still have no clue what it is for Now that may be realistic - having a bunch of keys and not know what half of them are for probably isn't that uncommon. But point of crossfire is to be fun, not necessarily realistic. From mwedel at sonic.net Sun Feb 3 21:44:05 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Feb 2008 19:44:05 -0800 Subject: [crossfire] New plugin: citylife - help needed In-Reply-To: <200802031030.33079.nicolas.weeger@laposte.net> References: <200801270911.35887.nicolas.weeger@laposte.net> <200802021914.45243.kbulgrien@worldnet.att.net> <200802031030.33079.nicolas.weeger@laposte.net> Message-ID: <47A68A05.6000500@sonic.net> I've always thought that the cleaning woman, which is and archetype that is used in some maps, should be set to pick up everything (maybe not furniture) - after all, they are cleaning woman, so they should clean. Then there should be some of these about town, and same thing, they should go and pick up all the garbage the players leave about. Could be interesting to also have a garbage pile someplace which the cleaning woman go to do drop all the crap they pick up, so if the player leaves something 'temporarily' on the map and the cleaning woman pick it up, the player could still go to the garbage pile and try to get it back. From mwedel at sonic.net Sun Feb 3 21:57:21 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Feb 2008 19:57:21 -0800 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802031040.09187.nicolas.weeger@laposte.net> References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: <47A68D21.2050101@sonic.net> Nicolas Weeger wrote: > Hello. > > Here is a proposition for new player account mechanism and character > management. Note that this has been discussed a lot before on mailing list on wiki - probably good to look there for some starting points on this. > > 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. this is a step that is not there right now - I'd like a little more information on why to add an account that is linked to characters instead of just having the current method. > > 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. disagree on that - having half the character creation in the client and have still done on maps really isn't the right answer. A new player only has half the necessary information to create a character - race and stats. He chooses those, and then finds out that based on class, maybe he didn't choose good stats and race, and has to start over. Also, there really isn't much on the map related to classes - yes, there is a selection mechanism in the hall of selection, but all of those just use the generic archetype for the different classes. Just as we can send race information to the client, it should be easy enough to send class information to client. Give all those classes some unique type (if they don't have one already) so that the server can easily find all the classes and send relevant information. The data sent is really going to be in the same form as race data (stat adjustment, special notes, etc), so if we're sending one, sending the other wouldn't be much more work. If some server wants to add or remove classes, it is just a matter of changing the archetypes. Right now, if you want to change a class, you have to change the archetype and change the hall of selection, so just making it an archetype ability should make it easier to change classes. > > Characters can possibly be transferred between accounts. Account "survives" > until removal by player, characters disappear on death on permadeath servers. I'd still need to see more information on what benefit/meaning accounts have here. The first that come to mind are for servers that want to be private or pay for play - they can then have some alternative mechanism to create the initial account (once I get the money, I'll create an account type of thing). Thats fine, but I'd almost say folks that want to run those servers should write and maintain that code. Second point is that it may make character management easier - I log in as mark, and I can see all the characters with my account. I say may make character management easier - this really depends on how many servers I play on, if I can get the same account name on all of them, etc. If I end up having different account names on the different servers, doesn't really make things much easier (OTOH, I suppose the client could remember different account names on different servers). From kbulgrien at worldnet.att.net Mon Feb 4 01:34:40 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 4 Feb 2008 01:34:40 -0600 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802031040.09187.nicolas.weeger@laposte.net> References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: <200802040134.40240.kbulgrien@worldnet.att.net> > 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. See below. > 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. Actually, I think this is the most difficult aspect of character creation at the moment. Without class selection in the same place as race and stats, it requires external resources to adequately design a character. If we're going to improve character creation, I'd say rolling in class to the creation process is far more important than the suggestion to have accounts on the server as it would be a major improvement for the player. Also, even if creation is pushed off to the client for execution, I think it wise to consider that the information needs to be supplied by the server to get away from some very clunky issues regarding information handling that has to do with character creation. At the moment, there are about 4 copies of the Hall of Selection with identical information about each class. This is a pain to manage, and, furthermore, if character creation is pushed to the client, then we don't want to have to maintain this information separately for each client. I was somewhat stymied by the great volume of technical nitpicks on Yann's idea about a login server as expressed on IRC. The implementation effort need not be that great, as can be determined by more carefully considering what actual work would be needed. It could centralize character creation in a way that provides both immediate and long term advantage. I saw no compelling reason to so thoroughly reject the suggestion and actually prefer that the idea of the server-side login server module be reconsidered, and integrated with this suggestion for client-side character generation. > Characters can possibly be transferred between accounts. Account > "survives" until removal by player, characters disappear on death on > permadeath servers. I rather do like the use of a single password per server... that's always a pain in that I try not to reuse passwords from one server to the next in case they were to be breakable. I do not make a habit of trusting administrators on systems. Even if the same password is reused per server, it is still common for me to make the mistake of re-using a password from a different server out of "typing habit". By making a login account, the password is created only once. I do see this as somewhat nice, but still it strikes me as not as much of a priority in that the value add seems somewhat low. The main reason to include it may be that if the design for a new character creation subsystem makes it easy to do, or drives development of a cleaner design, then it might be done. Kevin From kbulgrien at worldnet.att.net Mon Feb 4 01:44:43 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 4 Feb 2008 01:44:43 -0600 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <47A68D21.2050101@sonic.net> References: <200802031040.09187.nicolas.weeger@laposte.net> <47A68D21.2050101@sonic.net> Message-ID: <200802040144.43890.kbulgrien@worldnet.att.net> > > 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. > > this is a step that is not there right now - I'd like a little more > information on why to add an account that is linked to characters instead > of just having the current method. I think you partly answer your own question below, however, you might note comments about password management in my other reply, but I'll restate and reword the thoughts here in case it clarifies the point. I have many times thought how unfortunate that it is easy to use duplicate passwords from one server to another because each character needs a password... so, it is easy out of habit from typing a password on one server, to accidentally use it on another one. I don't know about you, but I don't trust admins on other people's servers. Consider especially cases where a server admin might be hostile for whatever reason. An admin should not be easily able to discern what someones password might be on another server. Naturally, you cannot protect a player from their own stupidity regarding intentional re-use of passwords, but I do think that lowering the risk of accidental re-use of a password is responsible design and indeed worth considering on that merit alone. > > Characters can possibly be transferred between accounts. Account > > "survives" until removal by player, characters disappear on death on > > permadeath servers. > > I'd still need to see more information on what benefit/meaning accounts > have here. > > The first that come to mind are for servers that want to be private or > pay for play - they can then have some alternative mechanism to create the > initial account (once I get the money, I'll create an account type of > thing). Thats fine, but I'd almost say folks that want to run those > servers should write and maintain that code. > > Second point is that it may make character management easier - I log in > as mark, and I can see all the characters with my account. I say may make > character management easier - this really depends on how many servers I > play on, if I can get the same account name on all of them, etc. If I end > up having different account names on the different servers, doesn't really > make things much easier (OTOH, I suppose the client could remember > different account names on different servers). From tchize at gmail.com Mon Feb 4 08:32:40 2008 From: tchize at gmail.com (David Delbecq) Date: Mon, 04 Feb 2008 15:32:40 +0100 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802040144.43890.kbulgrien@worldnet.att.net> References: <200802031040.09187.nicolas.weeger@laposte.net> <47A68D21.2050101@sonic.net> <200802040144.43890.kbulgrien@worldnet.att.net> Message-ID: <47A72208.50809@gmail.com> En l'instant pr?cis du 04/02/08 08:44, Kevin R. Bulgrien s'exprimait en ces termes: >>> 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. >>> >> this is a step that is not there right now - I'd like a little more >> information on why to add an account that is linked to characters instead >> of just having the current method. >> > > I think you partly answer your own question below, however, you might note > comments about password management in my other reply, but I'll restate and > reword the thoughts here in case it clarifies the point. > > I have many times thought how unfortunate that it is easy to use duplicate > passwords from one server to another because each character needs a > password... so, it is easy out of habit from typing a password on one > server, to accidentally use it on another one. I don't know about you, but > I don't trust admins on other people's servers. Consider especially cases > Sorry to ask, but what in current state of accounts handling prevents your from using different passwords on different servers? Nothing forces you to use same password on different server, and you can use same password for all your accounts on a given server... Now, a really interresting point in having a notion of accounts, is that it opens a wide range of new possibilities :) 1) Get an idea of how much actual player there is, instead of how much characters 2) Exchange of items between characters of same player? (Some commercial MMorpg allow this). Not that it would be impossible now ;) 3) A common interface to manage all your characters (delete them, get their stats, whatever) 4) Retrieve password interface (send token by email?) On the other end, there are more important things to do for players than an "account", it will be better for players to have a simple interface to fully design their new character prior to any acocunt management interface. There is already a wiki brainstorming page for this. From robert at timetraveller.org Sun Feb 3 11:52:50 2008 From: robert at timetraveller.org (Robert Brockway) Date: Sun, 3 Feb 2008 12:52:50 -0500 (EST) Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802031040.09187.nicolas.weeger@laposte.net> References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: On Sun, 3 Feb 2008, Nicolas Weeger wrote: > Character creation mechanism is mostly moved to client, where the player can > select race and statistics. Hi Nicholas. Presumably the info generated in the client is checked somehow on the server to prevent hacked clients becoming a problem? Eg, a completely point based statistic system would be easily checked by the server before the character was allowed to login. I gather all info on a character would still be stored server-side. > 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. Dead characters on permadeath servers can still return from the dead via resurrection so they shouldn't be deleted. Cheers, Rob -- "With sufficient thrust, pigs fly just fine..." -- RFC 1925 "The Twelve Networking Truths" From lalo.martins at gmail.com Mon Feb 4 16:08:01 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 4 Feb 2008 22:08:01 +0000 (UTC) Subject: [crossfire] Player accounts, new player creation mechanism References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: Also spracht Robert Brockway (Sun, 03 Feb 2008 12:52:50 -0500): > Dead characters on permadeath servers can still return from the dead via > resurrection so they shouldn't be deleted. For that matter, I have a feeling an account system like that could make permadeath more appealing... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at worldnet.att.net Mon Feb 4 17:57:07 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 4 Feb 2008 17:57:07 -0600 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <47A72208.50809@gmail.com> References: <200802031040.09187.nicolas.weeger@laposte.net> <200802040144.43890.kbulgrien@worldnet.att.net> <47A72208.50809@gmail.com> Message-ID: <200802041757.07826.kbulgrien@worldnet.att.net> > Sorry to ask, but what in current state of accounts handling prevents > your from using different passwords on different servers? Nothing forces > you to use same password on different server, and you can use same > password for all your accounts on a given server... Obviously nothing prevents it, and that was not the point at all was it? > Now, a really interresting point in having a notion of accounts, is that > it opens a wide range of new possibilities :) > > 1) Get an idea of how much actual player there is, instead of how much > characters > 2) Exchange of items between characters of same player? (Some commercial > MMorpg allow this). Not that it would be impossible now ;) > 3) A common interface to manage all your characters (delete them, get > their stats, whatever) > 4) Retrieve password interface (send token by email?) > > On the other end, there are more important things to do for players than > an "account", it will be better for players to have a simple interface > to fully design their new character prior to any acocunt management > interface. There is already a wiki brainstorming page for this. From mwedel at sonic.net Mon Feb 4 23:41:51 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Feb 2008 21:41:51 -0800 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: <47A7F71F.1030603@sonic.net> Robert Brockway wrote: > On Sun, 3 Feb 2008, Nicolas Weeger wrote: > >> Character creation mechanism is mostly moved to client, where the player can >> select race and statistics. > > Hi Nicholas. Presumably the info generated in the client is checked > somehow on the server to prevent hacked clients becoming a problem? Eg, a > completely point based statistic system would be easily checked by the > server before the character was allowed to login. > > I gather all info on a character would still be stored server-side. Yes on both counts - not addressed in that particular e-mail, but was discussed extensively in the past. Basic idea is server would send relevant information to client (this is how many stat points you get, these are the different classes & races and what the stat adjustments are, other benefits, etc). Player then plays around with them (let me see how setting this class affects character, etc), and when satisfied, hits something like done. Client then sends data back to server - basically the stats, race, and class. Server then verifies data is correct (if a player doesn't use all their points, that would be fine, but a player can't use more than allowed). This basically follows the design philosophy of don't trust anything from the client. From mwedel at sonic.net Mon Feb 4 23:53:11 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Feb 2008 21:53:11 -0800 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802041757.07826.kbulgrien@worldnet.att.net> References: <200802031040.09187.nicolas.weeger@laposte.net> <200802040144.43890.kbulgrien@worldnet.att.net> <47A72208.50809@gmail.com> <200802041757.07826.kbulgrien@worldnet.att.net> Message-ID: <47A7F9C7.1070207@sonic.net> There are certainly some advantages to an account based system, including potentially easier banning of players. But several points need addressing/clarification: 1) How are accounts created? If a player can create an account at any time, and thus have a 1:1 account:character mapping, knowing number of unique players, etc, may be difficult. To make this happen, may want some greater benefit for the characters in such a system (item trading, maybe apartments/houses are account based, not character based, etc). 2) Need to handle player files without accounts. If a player logs in with one of those characters, are they forced to create an account? Is account name space different than character namespace? For example, if I use the name 'Mark' for my account, does that now prohibit characters from using that name? 3) In terms of security, one could argue accounts may make things worse. Right now if I play on a 'suspect' server and that server admin looks at my character and gets my password, that may only let him log into 1 character on another server (or at least he only has information on that one character on that server - he would need other mechanisms to find out all the character names I play on the other servers). However, if he gets access to my account, he now has access to all my characters. And I think the point tchize raised using different password on different servers is valid - is it really any more likely I'll use different passwords for different accounts on different servers? If I know my account on ailesse has password foobar, and account on metalforge is kumquat, it would seem I could remember that for individual player files just as easily. If security is a concern, other things should be investigated - right now, password from client to server are plaintext (allowing easy snooping) - it was decided long ago that character files are not critical enough to warrant the complexity of doing something like ssl. That said, I'm not against the idea of accounts - it could be useful. But like fair number, I'd need to see some compelling reasons of how it would be useful and why it is more important than many other things (but like everything, if some developer is gung ho on doing it, who am I to stop them). But at the same time, I think some of the points about account creation and legacy character files need to be answered. From mwedel at sonic.net Mon Feb 4 23:59:55 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Feb 2008 21:59:55 -0800 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802031040.09187.nicolas.weeger@laposte.net> References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: <47A7FB5B.8080806@sonic.net> One other note on all of this: The method to create a new character should not be the default if wrong password is entered. Instead, I'd see something like you connect to server. You are then prompted for name & password, or you hit something like a 'create new character' button. Part of the character creation is entering of a username, at which point server sees if it is OK, or sends error back to client saying pick a new name. If accounts are done, it would be a similar thing - log in to account, or create new account. Once you are logged into an account, you'd either get a list of characters you could play, or also have a 'create new character' type of button. From nicolas.weeger at laposte.net Wed Feb 6 16:56:30 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 6 Feb 2008 23:56:30 +0100 Subject: [crossfire] Player accounts, new player creation mechanism In-Reply-To: <200802031040.09187.nicolas.weeger@laposte.net> References: <200802031040.09187.nicolas.weeger@laposte.net> Message-ID: <200802062356.34285.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080206/890c4e03/attachment.pgp From nicolas.weeger at laposte.net Fri Feb 8 11:34:50 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 8 Feb 2008 18:34:50 +0100 Subject: [crossfire] Map logical linking In-Reply-To: <200802031107.27869.nicolas.weeger@laposte.net> References: <200802031107.27869.nicolas.weeger@laposte.net> Message-ID: <200802081834.53499.nicolas.weeger@laposte.net> Hello. Here is the (simple I hope!) format I propose for the 'lore' field of maps: - free form, put whatever you want - tag '@def whatever' defines a quest named 'whatever'. 'whatever' is free form, spaces or whatever authorized. All text from this tag to tag '@end' or end of lore is the quest description, HTML format. - tag '@quest whatever' means the map is part of the specified quest. Text following until end of lore or '@end' is added to the map's description in the quest page. I will modify mapper to extract this information and make a quest list, things like that. Example for lore field (--- to delimite things for clarity's sake), for the Scorn castle map: (text taken from the CF's website) ----- @def Royalty quest This map is also known as Scorn Castle. Once inside you will find serveral Royal Guards and other members of Royalty (Magistrates, et al) On the second level of the Castle - you'll find 4 sets of stairs, only 2 work. One takes you to the dining hall, where you can only enter certain rooms according to your rank. The other stairs takes you to the quest area. Enter the first room to the north to begin the quest for Knighthood and further instructions. Each of the adjacent rooms have additional quests, titles and rewards. Note: You are given general instructions on the quest map locations - you will have to do some exploring to solve these maps, which are are all randomly generated. For the most part, you are required to return to the Castle with a specific item in order to solve the quest. ---- Then in the Undead church in Scorn: ---- @quest Royalty quest This is the third quest in the Royalty quest. Location: The white church in south central part of Scorn. Description: A church that starts out as a large room. There is also a courtyard. Suggested Levels: Level 3 or 4 for a "fighter" and level 5 or 6 for a spellcaster. Monsters Encountered: Zombies, Skeletons. ---- If needed we'll extend that further on (thinking about linking to other quests, or maps, or whatever) Opinions? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080208/602e1f17/attachment.pgp From leaf at real-time.com Fri Feb 8 14:09:46 2008 From: leaf at real-time.com (Rick Tanner) Date: Fri, 08 Feb 2008 14:09:46 -0600 Subject: [crossfire] volunteer to build 32 bit RPMS In-Reply-To: <200801301016.15459.subs@eracc.com> References: <47A02E75.2060606@sonic.net> <200801301016.15459.subs@eracc.com> Message-ID: <47ACB70A.2050904@real-time.com> ERACC Subscriptions wrote: > On Wednesday 30 January 2008 > Mark Wedel wrote: > >> anyone out there want to build 32 bit RPMs of the client? > > I could do this if you assist me with it. Or I can give you a shell on my > 32-bit box. Whichever you prefer is fine with me. Send me a private e-mail > about it (gene \a\t eracc \d\o\t com) or ping me on IRC. More out of curiosity, how are things going with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080208/309e1347/attachment.pgp From leaf at real-time.com Fri Feb 8 14:12:26 2008 From: leaf at real-time.com (Rick Tanner) Date: Fri, 08 Feb 2008 14:12:26 -0600 Subject: [crossfire] Volunteer for Windows builds? In-Reply-To: <200801302353.04427.nicolas.weeger@laposte.net> References: <200801302353.04427.nicolas.weeger@laposte.net> Message-ID: <47ACB7AA.1090000@real-time.com> Nicolas Weeger wrote: > > 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 :) 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080208/09a092a7/attachment.pgp From nicolas.weeger at laposte.net Fri Feb 8 15:12:25 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 8 Feb 2008 22:12:25 +0100 Subject: [crossfire] Volunteer for Windows builds? In-Reply-To: <47ACB7AA.1090000@real-time.com> References: <200801302353.04427.nicolas.weeger@laposte.net> <47ACB7AA.1090000@real-time.com> Message-ID: <200802082212.25071.nicolas.weeger@laposte.net> > 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 !] From subs at eracc.com Sat Feb 9 11:44:12 2008 From: subs at eracc.com (ERACC Subscriptions) Date: Sat, 9 Feb 2008 11:44:12 -0600 Subject: [crossfire] volunteer to build 32 bit RPMS In-Reply-To: <47ACB70A.2050904@real-time.com> References: <47A02E75.2060606@sonic.net> <200801301016.15459.subs@eracc.com> <47ACB70A.2050904@real-time.com> Message-ID: <200802091144.14831.subs@eracc.com> On Friday 08 February 2008 Rick Tanner wrote: > ERACC Subscriptions wrote: > > On Wednesday 30 January 2008 > > > > Mark Wedel wrote: > >> anyone out there want to build 32 bit RPMs of the client? > > > > I could do this if you assist me with it. Or I can give you a shell on my > > 32-bit box. Whichever you prefer is fine with me. Send me a private > > e-mail about it (gene \a\t eracc \d\o\t com) or ping me on IRC. > > More out of curiosity, how are things going with this? If Mark contacted me via e-mail I did not receive it. I did not get a PM about it on IRC either. My presumption is that someone else filled the need. Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From mwedel at sonic.net Sat Feb 9 23:36:51 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Feb 2008 21:36:51 -0800 Subject: [crossfire] Map logical linking In-Reply-To: <200802081834.53499.nicolas.weeger@laposte.net> References: <200802031107.27869.nicolas.weeger@laposte.net> <200802081834.53499.nicolas.weeger@laposte.net> Message-ID: <47AE8D73.8030309@sonic.net> Nicolas Weeger wrote: > > > If needed we'll extend that further on (thinking about linking to other > quests, or maps, or whatever) > > > Opinions? Looks good to me. It may be worthwhile to define how that information is used, and thus perhaps other fields. If it is just for mapmakers, then no big deal. OTOH, it could be nice to tie it into the region, so that folks in scorn may talk about some aspects (The king of scorn is looking for heroes to solve some problems - go to the scorn castle) type of thing. Or maybe other snippets appear randomly in scrolls or books - that makes a lot of sense for things like forgotten ruins - a scrap referencing a ruined castle in a book found in a dungeon makes some sense. Or maybe all of this is driven by files in the map directory that cover these broader aspects of quests (like a scorn_royalty.qi file that determines what info shows up in books, shows up in NPC conversations, etc) From nicolas.weeger at laposte.net Sun Feb 10 03:54:56 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Feb 2008 10:54:56 +0100 Subject: [crossfire] Volunteer for Windows builds? In-Reply-To: <200801302353.04427.nicolas.weeger@laposte.net> References: <200801302353.04427.nicolas.weeger@laposte.net> Message-ID: <200802101055.00704.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080210/a8e3c0ff/attachment.pgp From kirschbaum at myrealbox.com Sun Feb 10 06:04:21 2008 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun, 10 Feb 2008 13:04:21 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [8406] client/trunk/gtk-v2/src/config.c In-Reply-To: References: Message-ID: <20080210120421.GA25725@localhost.localdomain> Crossfire CVS repository messages. wrote: > Revision: 8406 > http://crossfire.svn.sourceforge.net/crossfire/?rev=8406&view=rev > Author: kbulgrien > Date: 2008-02-09 23:21:50 -0800 (Sat, 09 Feb 2008) > > Log Message: > ----------- > - Reformat LOG() calls to break long lines. [...] > + LOG(LOG_WARNING, "config.c::load_defaults", > + "Ignoring iconscale value read from gdefaults2 file.\n" > + "Invalid iconscale range (%d), valid range for -iconscale " > + "is 25 through 200", want_config[CONFIG_ICONSCALE]); I'd like to question these changes. Background is that I often use grep to find messages or uses of variable names. Such wrapped lines make this process very inefficient: - You are never sure if some occurrences are missing from the result set. For example, a "grep 'for -iconscale is'" will not find the above example. - The grep output is not very useful because it lacks context. For example, a "rgrep want_config gtk-v2" returns [...] gtk-v2/src/config.c: if (want_config[CONFIG_MAPSCALE]< 25 || want_config[CONFIG_MAPSCALE]>200) { gtk-v2/src/config.c: "is 25 through 200", want_config[CONFIG_MAPSCALE]); gtk-v2/src/config.c: want_config[CONFIG_MAPSCALE] = use_config[CONFIG_MAPSCALE]; [...] This is not very helpful -- you have to check the source to find out what this "25..200" range means in this context. Using unwrapped lines, the whole LOG() statement would have been printed. This almost always gives enough information to quickly decide which lines belong to the issue I'm working on. The only (slight) advantage of such wrapped lines I can see is when using a text editor not being able to automatically wrap long lines. I think the disadvantages of wrapped lines outnumber the benefits. Therefore I propose to not normally wrap long lines rather than fixing editor shortcomings with source code formatting. Of course, there are exceptions for the "do not wrap line" rule: extremely long or repetitive expressions for example. Generally, I'd prefer rewriting very long lines into multiple simpler statements using suitably named temporary variables over wrapping. From kbulgrien at worldnet.att.net Tue Feb 12 07:03:20 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 12 Feb 2008 07:03:20 -0600 Subject: [crossfire] GTK V2 client default layout and map size Message-ID: <200802120703.21313.kbulgrien@worldnet.att.net> It is probably time to seriously consider changing the default layout of the GTK V2 client. It seems a not infrequent complaint that the current layout is not helping people appreciate GTK V2, and this was the primary reason I did work on GTK V2 since it was the entire reason GTK V2 was unacceptable for my use. Leaf has been kind enough to put up sample layouts at: http://crossfire.real-time.com/clients/gtkv2_client.html Even if the default is not changed immediately, a poll could be put up somewhere to start collecting data. That would at least help put some numbers to the situation instead of general impressions based on IRC comments. My opinion: I think meflin.glade and gtk-v2.glade are not viable candidates due to a number of reasons (map size/default window size), though I'd not avoid letting people vote on them. meflin.glade is definitely more of an expert player's layout, due to the messages/inventory being on different tabs such that you can't see the text displayed if you click on a floor or inventory icon. GTK V1 is not really that great, either IMO. Both Un-Deux and V1-Redux are better if going for a V1-ish look. If a layout is selected that is most likely to be compatible with all desktop sizes, oroboros.glade is the winner there because it has saved defaults that easily fit on a 1024x768 display, though personally, it has too many tab notebooks. In the end, it seems best to let players choose by vote, if only because the layout is tied so much to personal taste. I do think that the default map size in the configuration should be changed. 25x25 is not a practical size for many people, besides having a performance cost. It would be good to consider also selecting new default map sizes - possibly based on either the lowest common denominator of 17x13 (Oroboros driving the 13), or 17x17 by culling a couple of the two smallest layouts (Oroboros/GTK V1) and going with 17x17. Feedback anyone? Kevin Bulgrien From raphael at gimp.org Tue Feb 12 09:24:49 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Tue, 12 Feb 2008 16:24:49 +0100 Subject: [crossfire] Using svnmerge for backporting to branch? Message-ID: <20080212162449.3e6d703d@ibiza.islands.lab> Hi, 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 used svnmerge for gimp, gimp-web and related svn modules and I can say that it does makes life easier. The main purpose of this tool is to keep track of what has already merged between the trunk and a branch and also what has not been merged (blocked). This is useful when doing merges on a regular basis, because you can easily keep track and merge the useful bug fixes from the trunk without being distracted by the other things that have already been done or that should be avoided. (Note that the upcoming svn 1.5 will have a 'merge tracking' feature that is similar to svnmerge, but it will take a while until 1.5 is ready to be used by everybody.) There is an initial investment in using svnmerge: since several merges were already applied by hand and not recorded in the svn properties, someone will have to use 'svnmerge init' and mark what has already been done and what should be blocked. But once it is done, then anybody can use 'svnmerge avail' to review the revisions available for merging, followed by 'svnmerge merge' to merge in some or all available revisions. There is a quick usage overview and several tutorials available here: http://www.orcaware.com/svn/wiki/Svnmerge.py So my question is... should I start using svnmerge and initialize the revision tracking? It does not mean that everybody will be forced to use svnmerge from now on, because it is always possible to merge stuff by hand and then later someone else can mark the revision as already merged. But of course it would be better if most developers who intend to merge stuff between branch and trunk would feel comfortable with svnmerge. So I'd like to get some feedback before investing time in initializing the merge tracking. -Rapha?l P.S.: svnmerge is available in most Linux distros. However, it may be part of a package called svn-utils or svn-tools instead of being part of the main subversion package. From kbulgrien at worldnet.att.net Tue Feb 12 10:31:59 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 12 Feb 2008 10:31:59 -0600 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802120703.21313.kbulgrien@worldnet.att.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> Message-ID: <200802121032.00423.kbulgrien@worldnet.att.net> Kevin R. Bulgrien wrote: > Leaf has been kind enough to put up sample layouts at: > > http://crossfire.real-time.com/clients/gtkv2_client.html > > Even if the default is not changed immediately, a poll could be put up > somewhere to start collecting data. That would at least help put some > numbers to the situation instead of general impressions based on IRC > comments. FYI, waiting a bit might be in order. When I took the screen shots originally, I found some layout issues with two of them. I just fixed meflin.glade and have set up the GTK V1 layout to be much more similar to the original GTK V1 client's layout and appearance. I'd want to get updated screen shots up before voting. I also found I could make the GTK V1 default map size so it was one tile taller due to some improvements in how the widgets are set up. Apparently I learned some things after doing that layout that I didn't backport to my initial work. Given a bit more time, possibly I could put some of these improvement in other layouts. Kevin Bulgrien From mwedel at sonic.net Tue Feb 12 23:44:02 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Feb 2008 21:44:02 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802120703.21313.kbulgrien@worldnet.att.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> Message-ID: <47B283A2.6080203@sonic.net> Quick thoughts/past notes: I expect that the preferences will be driven a lot by what actual hardware folks are running on. If you only have a display that does 1024x768, then the Oroboros is the likely winner. But if you have a higher res display, that probably isn't a first choice, as you have a lot more display area than it uses. Now it may be that the client should try and be smart and choose a best default layout based on various factors, like screen resolution. Same could be said for things like map size. A better approach may be to have a basic configuration program (or window) that is used first time client is run by user (no .crossfire file). A fair number of commercial games use that approach - configure the display resolution/quality you want to use, configure sound, etc. That, however, is a fair amount of work, and ideally, the configuration dialogs used within the client match those initial configuration ones (don't duplicate code, but also easier for an end user perspective - if you see one set of configuration dialog the first time you run it that doesn't match the one you see later, may be harder to know what config options you used before, etc) Note that one reason I put the map window in the upper left corner is that to some extent it made using different map sizes easier. But I do have to say I don't find it ideal either (but I'm not sure what I find ideal). I'm also not wild about the way the stats are displayed in all the layouts (which really isn't changed) - that is to say being in a single row: Str 5 Dex 6 Con 10, etc as that never seems really easy to find for me, and I can't think of any other game that displays them - doing them as a column, with column to the right (or maybe several) may be more readable and more effective use of space, eg: Str 6 Speed 0.50 Dex 10 Weapon Speed 0.80 Con 18 Damage 15 Int 14 WC 6 and so on. As an aside, since exp now has its own statbar, there really isn't much reason for there also to be a display in the stat area. From kbulgrien at worldnet.att.net Wed Feb 13 07:42:58 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 13 Feb 2008 07:42:58 -0600 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <47B283A2.6080203@sonic.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> Message-ID: <200802130742.59100.kbulgrien@worldnet.att.net> > Quick thoughts/past notes: > > I expect that the preferences will be driven a lot by what actual > hardware folks are running on. > > If you only have a display that does 1024x768, then the Oroboros is the > likely winner. But if you have a higher res display, that probably isn't a > first choice, as you have a lot more display area than it uses. I'm not bothered by that, and it actually is in the spirit of making the game more accessible anyway. I'd consider setting it as the default without even taking a vote. Why should not the majority get their choice anyway - even if it isn't your or my favorite? > Now it may be that the client should try and be smart and choose a best > default layout based on various factors, like screen resolution. Same > could be said for things like map size. > > A better approach may be to have a basic configuration program (or > window) that is used first time client is run by user (no .crossfire file). > A fair number of commercial games use that approach - configure the > display resolution/quality you want to use, configure sound, etc. > > That, however, is a fair amount of work, and ideally, the configuration > dialogs used within the client match those initial configuration ones > (don't duplicate code, but also easier for an end user perspective - if you > see one set of configuration dialog the first time you run it that doesn't > match the one you see later, may be harder to know what config options you > used before, etc) If a user supplies a layout, it could get really hard to have all the necessary information where it would all work just right. It does make sense to pick Oroboros automatically on desktops at 1024x768 or lower. 1280x1024 and higher have always been supported on this client, so auto-picking once in that range seems not to buy much advantage, and none of them default to sizes that won't fit at all on that resolution. On IRC, people seem to be saying that 800x600 is still alive and kicking too. I figured I'd hammer a bit on Oroboros to get one option at that size, so having one of those to pull out of the hat if someone launches it on a small desktop might be good. As for a configuration program, what I can see is showing thumbnails of clients and let people browse them, along with the text descriptions, possibly calling out the default size of the layout separately. Doing something like that, you could advise against certain layouts based on the desktop size, but could allow them to be selected anyway if they want to try to deal with the resizing. That said, I think it needs to stay simple, but even so, presently there are better ways to spend a lot of development time. People still complain too much about what isn't there, and a configuration program won't address what gets complained about the most. Then... there is the whole thing about making the map size coincide with a selected layout... Right now it is difficult to know what to set the map size too. A first effort to address that is probably due quite high priority. You can totally hose a layout by using 25x25, which is the current default. I think the default map size should be a low common denominator unless new features are added to hint map size settings. > Note that one reason I put the map window in the upper left corner is > that to some extent it made using different map sizes easier. But I do > have to say I don't find it ideal either (but I'm not sure what I find > ideal). There are two options in the screen shots. Some that put the map on one side, and others. > I'm also not wild about the way the stats are displayed in all the > layouts (which really isn't changed) - that is to say being in a single > row: Str 5 Dex 6 Con 10, etc > > as that never seems really easy to find for me, and I can't think of any > other game that displays them - doing them as a column, with column to the > right (or maybe several) may be more readable and more effective use of > space, eg: > > Str 6 Speed 0.50 > Dex 10 Weapon Speed 0.80 > Con 18 Damage 15 > Int 14 WC 6 Hmm. Three layouts already do something like this. The first layout on Leaf's listing is very different, and not unlike what you describe. http://krayvin.home.att.net/caelestis_790x600.png Further, all the layout screenshots do not expose the stats, so unless one opened them, it would be difficult to say they hadn't changed. Chthonic, Oroboros do use columns as well. The GTK V1 variants do not for more obvious reasons, but for the others, I'll be most happy to do something different as it would free up more screen area. Remember too, I copied the legacy GTK V2, and differentiation occurs somewhat over time as I play with ideas. Keep suggestions coming. Oddly, when I mentioned stats and the homogenous mode before, the gtk-v2 format was argued for, possibly giving some exception to allowing numbers to cuddle the label. I imagine that had an effect of me not "fixing" all of the new layouts. Frankly, I think the non-spaced-out in-line stats are far more readable that the original layout, and a number of the new layouts do that. I'll revive thinking on other options for stat displays. > and so on. As an aside, since exp now has its own statbar, there really > isn't much reason for there also to be a display in the stat area. I've noted that, and think removing it might require a code change to avoid error messages as missing widgets do generate them, though I have not checked to be sure. It's a good reminder though. I have thought it odd for some time. Kevin From nicolas.weeger at laposte.net Wed Feb 13 12:18:34 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Feb 2008 19:18:34 +0100 Subject: [crossfire] Map logical linking In-Reply-To: <47AE8D73.8030309@sonic.net> References: <200802031107.27869.nicolas.weeger@laposte.net> <200802081834.53499.nicolas.weeger@laposte.net> <47AE8D73.8030309@sonic.net> Message-ID: <200802131918.37883.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080213/5505bffa/attachment.pgp From nicolas.weeger at laposte.net Wed Feb 13 16:45:48 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Feb 2008 23:45:48 +0100 Subject: [crossfire] Mapper tool Message-ID: <200802132345.54364.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080213/27010805/attachment.pgp From mwedel at sonic.net Wed Feb 13 23:32:39 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 13 Feb 2008 21:32:39 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802130742.59100.kbulgrien@worldnet.att.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <200802130742.59100.kbulgrien@worldnet.att.net> Message-ID: <47B3D277.6020309@sonic.net> Kevin R. Bulgrien wrote: >> Quick thoughts/past notes: >> >> I expect that the preferences will be driven a lot by what actual >> hardware folks are running on. >> >> If you only have a display that does 1024x768, then the Oroboros is the >> likely winner. But if you have a higher res display, that probably isn't a >> first choice, as you have a lot more display area than it uses. > > I'm not bothered by that, and it actually is in the spirit of making the > game more accessible anyway. I'd consider setting it as the default > without even taking a vote. Why should not the majority get their > choice anyway - even if it isn't your or my favorite? I have no problem with the majority not deciding the default layout. My point is that the majority is more likely to vote on what works best for them. If the majority chooses a layout that doesn't work good at low resolutions, is that the final word, or should we try to do work that makes things work better for low resolutions? Hard to say what the right answer is (at one time, a fullscreen mode was suggested, but with the wildly varying screen resolutions, that would be really hard) > Then... there is the whole thing about making the map size coincide with > a selected layout... Right now it is difficult to know what to set the > map size too. A first effort to address that is probably due quite high > priority. You can totally hose a layout by using 25x25, which is the > current default. I think the default map size should be a low common > denominator unless new features are added to hint map size settings. That should really get improved - arguably that is a bug going all the way back to the original X11 client. What should really determine the mapsize is the size of the window pane provided for it, not what is set elsewhere. That is also just a lot more user friendly. Start with a small map size and resize? You get a larger map display. Resize smaller? It should reduce the map size. I need to look and see how hard it is to do that. One issue with that plan is there could be folks that want a relatively little map data (11x11) sent from the server, but still have a larger viewable area for fog of war. For folks on highly constrained bandwidth situations (dialup modem), this may be relevant. OTOH, we may also have to ask ourselves how much effort should go into trying to cover old requirements. If easy to do so, we should do so, but at the same time, we shouldn't spend a lot of time trying to make things work in marginal situations at best. >> and so on. As an aside, since exp now has its own statbar, there really >> isn't much reason for there also to be a display in the stat area. > > I've noted that, and think removing it might require a code change to avoid > error messages as missing widgets do generate them, though I have not > checked to be sure. It's a good reminder though. I have thought it odd > for some time. At minimum, the lookup_widget routine generates an error whenever you try to find a widget that doesn't exist. If it gets removed from all the layouts, then removing the code that updates the labels makes sense. If some layouts have it, and others don't, I think this can still get managed by checking for null values or the like. An alternative may be to put those labels in some hidden widget that is never displayed, so the widgets are still there, just out of sight. From raphael at gimp.org Thu Feb 14 11:38:19 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Thu, 14 Feb 2008 18:38:19 +0100 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <47B283A2.6080203@sonic.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> Message-ID: <20080214183819.25a1cb32@ibiza.islands.lab> On Tue, 12 Feb 2008 21:44:02 -0800, Mark Wedel wrote: > If you only have a display that does 1024x768, then the Oroboros is the likely > winner. But if you have a higher res display, that probably isn't a first > choice, as you have a lot more display area than it uses. It depends. Since I play from time to time using different computers, I end up using different screen resolutions: 1024x768, 1280x1024, 1600x1200, etc. I think that the original gtk v2 layout isn't too bad and I can even use it at 1024x768 using a few tricks to save space. If you look carefully, you will see that the gtk v2 and the Oroboros layout are almost the same, except that the map area is moved from the top left to the bottom right. Otherwise, both are based on a basic 2-columns layout, with one column containing the same 3 rows (messages, inventory, floor view) and the other other one containing the map and the stats/skills/etc. One difference is that Oroboros puts the HP/SP/Gr/Food/Exp bars inside one of the tabs instead of besides the tabs. I do not like this choice because it means that I cannot view these very important bars as easily when I am viewing the other tabs, so that's why I still prefer the v2 layout. I think that before we try to pick the "best layout", there are two things that should be investigated: 1) What information is important to the players? What should always be visible on the screen and what can be toggled in/out of view using tabs or using any other appropriate mechanism? I would like to have a discussion on what we need to show before having a discussion about how it should be shown. 2) Is it possible to make the layout more flexible? Instead of having to select among a predefined set of layouts, could we find a way to provide a good default layout while still allowing the user to change it easily? After discussing these two points, then we can go back to the selection of the best layout if this is still relevant. I will start with a few comments on point 2) because this is related to what Mark wrote: > Now it may be that the client should try and be smart and choose a best > default layout based on various factors, like screen resolution. Same could be > said for things like map size. > > A better approach may be to have a basic configuration program (or window) > that is used first time client is run by user (no .crossfire file). A fair > number of commercial games use that approach - configure the display > resolution/quality you want to use, configure sound, etc. This is not an ideal approach because it forces to to select (automatically or via some configuration program) among a set of predefined layouts and maybe none of them is perfect for you. Instead, I would prefer to start with a good layout that can work well at low resolutions (a 2-columns layout) and then allow the user to add or remove a third column at any time and pick the tabs that should be in that column. I have some experience with that in GIMP: instead of having a fixed layout for all tools and dialogs, you can create any number of "docks" and drag tabs into these docks or out of them. GIMP uses separate top-level windows for the docks, but this could also be done using columns belonging to the same top-level window. Once you have done the initial effort to replace/subclass the GtkNotebook widgets, you get a lot more flexibility and then you do not have to worry anymore about what layout is best, because you know that the users will be able to re-organize the tabs according to their preferences. The main concern would be to select the best initial layout, but we would not need to worry about how a 2-columns layout wastes space on a widescreen display because we will know that it is easy to add a third column if the user wants it. > I'm also not wild about the way the stats are displayed in all the layouts > (which really isn't changed) - that is to say being in a single row: > Str 5 Dex 6 Con 10, etc > > as that never seems really easy to find for me, and I can't think of any other > game that displays them - doing them as a column, with column to the right (or > maybe several) may be more readable and more effective use of space, eg: > > Str 6 Speed 0.50 > Dex 10 Weapon Speed 0.80 > Con 18 Damage 15 > Int 14 WC 6 > > and so on. As an aside, since exp now has its own statbar, there really isn't > much reason for there also to be a display in the stat area. A column layout might be nice for the stats. But regarding the point 1) that I mentioned above, I would be interested in a discussion about what we consider to be the most important information. Besides the map, messages and inventory, I would consider the following information to be important especially during combat and I would like a layout that allows me to see all of these things at the same time: Most important (sorted by order of importance): - HP/SP/Gr/Food bars - range (current spell or bow) - important if I have the wrong thing active and I am wondering why the monsters around me are not harmed - protections (percentages for all current protections, armor) - important especially when they change because I have been hit or a spell expires. - AC - damage - speed - weapon speed - WC Less important (not important during combat, can be "tabbed away"): - stats (Str, Dex, Con, ...) - experience - level - skills and experience in each skill - character name Alas, there is currently no 2-columns layout that displays simultaneously all information that I consider to be important. Others may have different preferences, of course. But it would be nice to agree on what should be visible in the minimal layout (default) before discussing how it should be organized. -Rapha?l From nicolas.weeger at laposte.net Thu Feb 14 12:30:15 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Feb 2008 19:30:15 +0100 Subject: [crossfire] Using svnmerge for backporting to branch? In-Reply-To: <20080212162449.3e6d703d@ibiza.islands.lab> References: <20080212162449.3e6d703d@ibiza.islands.lab> Message-ID: <200802141930.19279.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080214/a9e3762d/attachment.pgp From nicolas.weeger at laposte.net Thu Feb 14 13:54:39 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Feb 2008 20:54:39 +0100 Subject: [crossfire] New field: "race_restriction" Message-ID: <200802142054.42669.nicolas.weeger@laposte.net> 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080214/41a1a881/attachment.pgp From nicolas.weeger at laposte.net Thu Feb 14 15:34:21 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 14 Feb 2008 22:34:21 +0100 Subject: [crossfire] Race / class animations Message-ID: <200802142234.24196.nicolas.weeger@laposte.net> 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 "_class_", 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 !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080214/f7455276/attachment.pgp From kbulgrien at worldnet.att.net Fri Feb 15 00:19:33 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 15 Feb 2008 00:19:33 -0600 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <20080214183819.25a1cb32@ibiza.islands.lab> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <20080214183819.25a1cb32@ibiza.islands.lab> Message-ID: <200802150019.34227.kbulgrien@worldnet.att.net> > Most important (sorted by order of importance): > - HP/SP/Gr/Food bars > - range (current spell or bow) - important if I have the wrong thing > active and I am wondering why the monsters around me are not harmed > - protections (percentages for all current protections, armor) - > important especially when they change because I have been hit or a spell > expires. - AC > - damage > - speed > - weapon speed > - WC > > Less important (not important during combat, can be "tabbed away"): > - stats (Str, Dex, Con, ...) > - experience > - level > - skills and experience in each skill > - character name > > Alas, there is currently no 2-columns layout that displays simultaneously > all information that I consider to be important. Others may have different > preferences, of course. But it would be nice to agree on what should be > visible in the minimal layout (default) before discussing how it should be > organized. > > -Rapha?l This is not a two-column layout, but I took your ideas and came up with this: http://krayvin.home.att.net/unnamed.png Nothing is hidden however. Run/Fire indicators are between the Range: and the speed stats. I decided to play around... this is almost 800x600! There are some widget resizing issues so it doesn't go quite within 800, but it was surprising to see what you could do. http://krayvin.home.att.net/small.png Accepting creative names. Kevin Bulgrien From mwedel at sonic.net Fri Feb 15 00:34:48 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 14 Feb 2008 22:34:48 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <20080214183819.25a1cb32@ibiza.islands.lab> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <20080214183819.25a1cb32@ibiza.islands.lab> Message-ID: <47B53288.7050502@sonic.net> Rapha?l Quinet wrote: ther tabs, so that's why I still prefer the v2 layout. > > I think that before we try to pick the "best layout", there are two things > that should be investigated: > 1) What information is important to the players? What should always be > visible on the screen and what can be toggled in/out of view using tabs or > using any other appropriate mechanism? I would like to have a discussion > on what we need to show before having a discussion about how it should be > shown. > 2) Is it possible to make the layout more flexible? Instead of having to > select among a predefined set of layouts, could we find a way to provide a > good default layout while still allowing the user to change it easily? Agree on both points. There may also be other things that make the client easier to use. Some of how the client works dates all the way back to it just be X11, where some more complicated things would have been very hard to do, but are quite easy to do with the widgets provided by GTK. >> A better approach may be to have a basic configuration program (or window) >> that is used first time client is run by user (no .crossfire file). A fair >> number of commercial games use that approach - configure the display >> resolution/quality you want to use, configure sound, etc. > > This is not an ideal approach because it forces to to select (automatically > or via some configuration program) among a set of predefined layouts and > maybe none of them is perfect for you. Instead, I would prefer to start with > a good layout that can work well at low resolutions (a 2-columns layout) and > then allow the user to add or remove a third column at any time and pick the > tabs that should be in that column. Yes, that is a better solution. I guess it depends on how much work it is to do. One nice thing right now is that all the layout work is done in glade. This makes it very easy to try different things, but also makes it very easy to add onto the layout. So while things could be done better, I'd want to make sure we don't drift away from also being able to manage the layouts within glade. Having thousands of lines of handwritten code to handle ideal layouts may be nice from an end user perspective, but starts to get really unmanagable from a developer perspective. At the same time, the first time a person runs the client, popping up some config options may still not be a bad thing, as right now, for lots of the config options, the client chooses defaults which may not be ideal. > A column layout might be nice for the stats. But regarding the point 1) that > I mentioned above, I would be interested in a discussion about what we > consider to be the most important information. Besides the map, messages and > inventory, I would consider the following information to be important > especially during combat and I would like a layout that allows me to see all > of these things at the same time: I'd make some adjustments even on those key points - inventory can/should be done better. Its been discussed, but what is really needed is ability to make up a custom list of objects I care about. In combat, there are probably less than 20 items I really need to see in my inventory - things like certain scrolls and potions, and maybe a few different weapons. I don't need to see all my items, and in fact, seeing all my items often makes it difficult to get to the ones I really need. > > Most important (sorted by order of importance): > - HP/SP/Gr/Food bars > - range (current spell or bow) - important if I have the wrong thing active > and I am wondering why the monsters around me are not harmed > - protections (percentages for all current protections, armor) - important > especially when they change because I have been hit or a spell expires. Pretty much agree. But I also think a better way to manage the protections is needed. While I want to be able to see them, being able to easily notice that my resist fire has gone from 90 to 20 may be difficult. Ideally something like a spell monitor would be nice - protections on my character are almost certainly controlled by various potions the character drinks. Because the duration of these potions can not really change, it is a fairly simple matter for the server to inform the client that 'Joe drank a potion of fire resistance, it will last for 30 seconds'. Clearly it would be done in a more concise term than that, but you get the point. So maybe some space in the statbar area could be used for this. A simple solution would be to use different icons for the different resistances/spell effects, and the client draw a little stat along with the icon, so one can see how much time is left on the spell. > - AC > - damage > - speed > - weapon speed > - WC While the above are handy, they also typically are not things that change in combat, so I don't really need to see them in a glance. At some point, less may be more - show me the data I care about, and don't show me other data, even if there is space for it, because it can then become harder to pick out the data I do care about. > > Less important (not important during combat, can be "tabbed away"): > - stats (Str, Dex, Con, ...) > - experience > - level > - skills and experience in each skill > - character name True for all of those. At one point, I suggested a window could be made for skill experience (name, status bar to indicate progress to next level) - given the number of skills, there is really no way any layout can easily define them. A nice effect of a window is that it can be made persistent if I have enough screen real estate. Last note, unrelated to layout, but related to usability, is that inventory control should really get an overhaul - in addition to a 'favorites' list, the fact that there are various shift/control left/right click combos to do certain things is just insane. My suggestion is left click examine, middle click apply, right click brings up menu with all sorts of other options (lock/unlock, drop, mark as favorite, mark as object for things like flint & steel + torch combo, and so on). Shift left-click could be drop - still not hard to drop stuff then, as you could keep your finger on the shift key. And there could still be other obscure control/alt/whatever combos to do a lock or mark or favorite item thing quickly, but having that default is hardly user friendly. From raphael at gimp.org Fri Feb 15 04:13:21 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Fri, 15 Feb 2008 11:13:21 +0100 Subject: [crossfire] Who uses the scrollbars around the map? Message-ID: <20080215111321.412a97dc@ibiza.islands.lab> While looking at the various layouts for the client, I remembered an old problem that we had discussed one or two years ago: the scrollbars around the map area take some space (almost one tile in each direction) and personally, I never use them. Is anybody using these scrollbars? If not, then we could save some space by getting rid of them. Scrolling is done automatically by the client anyway. Although I never use them, I suppose that scrollbars may be useful for layouts in which the map view is very small (e.g., 11x11). But if we arrange the widgets in such a way that it is possible to have 20x20 or at least more than 15x15 even with a screen resolution of 1024x768, then I think that we can remove them to gain one extra tile in each direction. -Rapha?l From juhaj at iki.fi Fri Feb 15 05:11:56 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Fri, 15 Feb 2008 13:11:56 +0200 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <20080214183819.25a1cb32@ibiza.islands.lab> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <20080214183819.25a1cb32@ibiza.islands.lab> Message-ID: <200802151312.00396.juhaj@iki.fi> Hi! I've been following the discussion on client layouts with great concern. What makes me concerned is the fact that most people seem to be fixed on the idea that a) the game window dimensions equal screen resolution and b) the window layout is (at least almost) fixed. For point a) please note that some people (at least me) never use full screen size windows for any purpose (except on my htpc, but that does not even have a keyboard and mouse so I won't be playing on it) and the current unability to let the window manager resize the window is simply absurd. If a user wants to resize crossfire window to 20x20 pixels, it's the user's problem when if becomes totally useless. Almost all programs scale their internal window widget sizes according to the window size (or introduce scroll bars). Why would crossfire not do this? For the map-view-widget this would probably be pointless, but at least everything else could scale. Even the map widget could scale at least is tile-size steps: if 16x16 tiles no longer fit on whatever size the user adjusted the window to, then only draw 15x15 - and leave some blank if the actual size is 15.5x15.5 or resize the info widgets to fill that space. For point b) Rapha?l already noted GIMP, my example would have been from gaming: FreeCiv. It has *exactly* the same situation as crossfire: a current map view based on tiles and some informative widgets displaying, for example, an overview of the whole world map etc. If you resize the window, the map view shrinks etc. No fixed map window sizes or anything. User can do whatever one likes, even float some of the widgets to separate windows (I would not like that feature myself in a real-time game like CF, but rearranging the widgets within the master window would be useful). Is there a reason for points a) and b) being as they are 1) now, 2) in the future? I hope there is no reason to keep them such in the future... -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080215/1ae19990/attachment.pgp From antonoussik at gmail.com Fri Feb 15 05:25:18 2008 From: antonoussik at gmail.com (Anton Oussik) Date: Fri, 15 Feb 2008 11:25:18 +0000 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802151312.00396.juhaj@iki.fi> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <20080214183819.25a1cb32@ibiza.islands.lab> <200802151312.00396.juhaj@iki.fi> Message-ID: On 15/02/2008, Juha J?ykk? wrote: > For point a) please note that some people (at least me) never use full screen > size windows for any purpose (except on my htpc, but that does not even have > a keyboard and mouse so I won't be playing on it) and the current unability > to let the window manager resize the window is simply absurd. If a user wants > to resize crossfire window to 20x20 pixels, it's the user's problem when if > becomes totally useless. Almost all programs scale their internal window > widget sizes according to the window size (or introduce scroll bars). Why > would crossfire not do this? For the map-view-widget this would probably be > pointless, but at least everything else could scale. Even the map widget > could scale at least is tile-size steps: if 16x16 tiles no longer fit on > whatever size the user adjusted the window to, then only draw 15x15 - and > leave some blank if the actual size is 15.5x15.5 or resize the info widgets > to fill that space. Likewise, I prefer to place each widget in its own window, get rid of window borders for them, and just rearrange them as I see fit. This allows for easy arrangement to play on multiple monitors, as well as allowing a very flexible way of arranging the client's components to suit playing style. From kbulgrien at worldnet.att.net Fri Feb 15 09:09:06 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 15 Feb 2008 09:09:06 -0600 Subject: [crossfire] Who uses the scrollbars around the map? In-Reply-To: <20080215111321.412a97dc@ibiza.islands.lab> References: <20080215111321.412a97dc@ibiza.islands.lab> Message-ID: <200802150909.06806.kbulgrien@worldnet.att.net> > While looking at the various layouts for the client, I remembered an old > problem that we had discussed one or two years ago: the scrollbars around > the map area take some space (almost one tile in each direction) and > personally, I never use them. > > Is anybody using these scrollbars? > > If not, then we could save some space by getting rid of them. Scrolling > is done automatically by the client anyway. > > Although I never use them, I suppose that scrollbars may be useful for > layouts in which the map view is very small (e.g., 11x11). But if we > arrange the widgets in such a way that it is possible to have 20x20 or at > least more than 15x15 even with a screen resolution of 1024x768, then I > think that we can remove them to gain one extra tile in each direction. > > -Rapha?l Nobody does. They don't work. There's an issue tracker at SF though. Funny I have left them there this whole time. :-D Thanks for piping up. Kevin Bulgrien From kbulgrien at worldnet.att.net Fri Feb 15 09:34:01 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 15 Feb 2008 09:34:01 -0600 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802151312.00396.juhaj@iki.fi> References: <200802120703.21313.kbulgrien@worldnet.att.net> <20080214183819.25a1cb32@ibiza.islands.lab> <200802151312.00396.juhaj@iki.fi> Message-ID: <200802150934.02161.kbulgrien@worldnet.att.net> > I've been following the discussion on client layouts with great concern. > What makes me concerned is the fact that most people seem to be fixed on > the idea that a) the game window dimensions equal screen resolution and b) > the window layout is (at least almost) fixed. So how is it all of a sudden any different than it has been for years? As I see it, the point is not that game window dimensions equal screen resolution. The point is, is it even possible to use a small size screen. I should think that is a positive thing and not something to be negative about. > For point a) please note that some people (at least me) never use full > screen size windows for any purpose (except on my htpc, but that does not > even have a keyboard and mouse so I won't be playing on it) and the current > unability to let the window manager resize the window is simply absurd. If > a user wants to resize crossfire window to 20x20 pixels, it's the user's > problem when if becomes totally useless. The idea is welcome, and will go in the hopper to be processed, but being packaged with such criticism, it is hardly motivation to do anything. Absurd? Really. Feel free to code up a non-absurd solution. It kind of bugs me to have such superlative griping all the time when someone takes it upon themselves to try to do some improvement, and everyone rips all of the ideas to shreds because it isn't perfect by some theoretical standard or another. I might like that too, but if you expect me to code that, you are going to wait a long time. I've never coded a GUI before, and I don't know how to make Glade/GTK do that. Again, the idea is great, as it helps one look at the tool for ideas on what it might do that hasn't been discovered yet. > Almost all programs scale their > internal window widget sizes according to the window size (or introduce > scroll bars). Why would crossfire not do this? For the map-view-widget this > would probably be pointless, but at least everything else could scale. Even > the map widget could scale at least is tile-size steps: if 16x16 tiles no > longer fit on whatever size the user adjusted the window to, then only draw > 15x15 - and leave some blank if the actual size is 15.5x15.5 or resize the > info widgets to fill that space. > > For point b) Rapha?l already noted GIMP, my example would have been from > gaming: FreeCiv. It has *exactly* the same situation as crossfire: a > current map view based on tiles and some informative widgets displaying, > for example, an overview of the whole world map etc. If you resize the > window, the map view shrinks etc. No fixed map window sizes or anything. > User can do whatever one likes, even float some of the widgets to separate > windows (I would not like that feature myself in a real-time game like CF, > but rearranging the widgets within the master window would be useful). > > Is there a reason for points a) and b) being as they are 1) now, 2) in the > future? I hope there is no reason to keep them such in the future... Neither a) nor b) are true. a) is used as a point of reference. In fact, if anything, a) was behind the rework of the client in the first place. The original GTK V2 layout was not small screen/workspace friendly at all. I refused to use it on low resolution desktops. What I did has started to explore layouts that are more flexible and can be used on smaller desktops. At no time has there been an assumption that the player must have it full screen. If anything, I did assume it wasn't full screen as all the defaults for all the layouts, except one, are smaller than any standard desktop size, to account at least minimally for task bars, and such. b) is not true unless you are talking about moving widgets around on docks. Both the GTK clients are fully resizable, albeit with some issues. I have absolutely no clue how to do docking, so you probably won't see that for a while unless someone else gets busy with the code, even if it is because that's just not a problem for me when there are a number of layouts to choose from. I like working the client, but I also would like to do other things in the project, so burning lots of time doing that isn't a big priority. I will custom design a glade layout for anyone that asks nicely. Give me a sketch, and we'll do it. I did that for meflin, and I'll do it for anyone else as long as I don't get flocks of requests. As for map sizing, that did get brought up, and is a concern that someone may be able to fix. Presently, I do not know the code enough to do something about it. Over time? Sure, its a possiblity, especially as there is no real reason for me to be the one who has to do it, and one thing is sure, if I am the only one working on it, I dislike the "fixed" settings, so have no reason to leave them that way in the future. I think the current changes are a huge improvement, not something to get all concerned about, but then, I guess I would see it that way since I'm the one that did them. I guess it also is interesting that discussion on the client hasn't born much in the way of results. It's interesting now that someone is doing something that all of a sudden ideas start popping. I think that's a good thing too. As long as they are nicely put, even critical observations help. Kevin From mwedel at sonic.net Fri Feb 15 20:59:28 2008 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 15 Feb 2008 18:59:28 -0800 Subject: [crossfire] Who uses the scrollbars around the map? In-Reply-To: <200802150909.06806.kbulgrien@worldnet.att.net> References: <20080215111321.412a97dc@ibiza.islands.lab> <200802150909.06806.kbulgrien@worldnet.att.net> Message-ID: <47B65190.9060908@sonic.net> Kevin R. Bulgrien wrote: > Nobody does. They don't work. There's an issue tracker at SF though. > Funny I have left them there this whole time. :-D Thanks for piping > up. It's a leftover from a feature I never got around to doing. My idea was to be able to scroll the map window to see fog of war data, etc (while it could be used, I didn't really envision someone with a 13x13 display area playing with 25x25 map data and scrolling about). Instead, the idea was more like 'I think I've cleared out this dungeon level. Let me scroll around the map window to see if I've missed anything'. Or in the case of maps with a more maze like layout 'let me scroll around and see how I get back to the exit'. But they can certainly go away until (if ever) that feature gets implemented. From kbulgrien at worldnet.att.net Sun Feb 17 02:30:11 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 17 Feb 2008 02:30:11 -0600 Subject: [crossfire] GTK V2 @ 640x480! Message-ID: <200802170230.11371.kbulgrien@worldnet.att.net> Played about today a bit. With a small code/glade change, and 50% iconscale: http://krayvin.home.att.net/gtk-v2-modified-640x480.png Or even... with 50% map scale... http://krayvin.home.att.net/gtk-v2-modified-640x480-22x22-map.png Kevin From nicolas.weeger at laposte.net Sun Feb 17 06:37:47 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 17 Feb 2008 13:37:47 +0100 Subject: [crossfire] GTK V2 @ 640x480! In-Reply-To: <200802170230.11371.kbulgrien@worldnet.att.net> References: <200802170230.11371.kbulgrien@worldnet.att.net> Message-ID: <200802171337.51037.nicolas.weeger@laposte.net> Le dimanche 17 f?vrier 2008, Kevin R. Bulgrien a ?crit?: > Played about today a bit. > > With a small code/glade change, and 50% iconscale: > > http://krayvin.home.att.net/gtk-v2-modified-640x480.png > > Or even... with 50% map scale... > > http://krayvin.home.att.net/gtk-v2-modified-640x480-22x22-map.png Nice :) And what about making the map 50% larger? like, tiles 48x48? For a bigger layout, of course, 640x480 would be too small... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080217/4ecb8658/attachment.pgp From juhaj at iki.fi Sun Feb 17 12:28:05 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Sun, 17 Feb 2008 20:28:05 +0200 Subject: [crossfire] GTK V2 @ 640x480! In-Reply-To: <200802171337.51037.nicolas.weeger@laposte.net> References: <200802170230.11371.kbulgrien@worldnet.att.net> <200802171337.51037.nicolas.weeger@laposte.net> Message-ID: <200802172028.12993.juhaj@iki.fi> > > http://krayvin.home.att.net/gtk-v2-modified-640x480.png > > http://krayvin.home.att.net/gtk-v2-modified-640x480-22x22-map.png These two are gorgeous! Note one point below, though. And my apologies if my previous email sounded to hostile. It was not meant as such. I was simply concerned (as I said). As what comes to actually making the widgets float and be rearrangeable, I think it should not be very difficult to look at the freeciv client code and see how it's done. I will do it, it this is still relevant next autumn - before that, I have no time to spare. That's why I've not been helping with the balancing, new spell system etc either, I'm sorry about that. > And what about making the map 50% larger? like, tiles 48x48? There has been (I do not know about the newest trunk) a bug in the map scaling algorithm. I have used the 50% map extensively and it has a bug which makes places disappear from map-window (you can click to see them, though). Is this a known bug? If so, skip the rest. =) This happens, for example, with certain types of "hole" on "hills". One of the holes close to Scorn vanishes this way. I think it is the place where there are lots of earth walls to bash. It may be the ogre chief cave as well. I do not have any copies of cf installed at the moment, so I cannot check. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080217/04312bcd/attachment.pgp From kbulgrien at worldnet.att.net Sun Feb 17 17:18:11 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 17 Feb 2008 17:18:11 -0600 Subject: [crossfire] GTK V2 @ 640x480! In-Reply-To: <200802172028.12993.juhaj@iki.fi> References: <200802170230.11371.kbulgrien@worldnet.att.net> <200802171337.51037.nicolas.weeger@laposte.net> <200802172028.12993.juhaj@iki.fi> Message-ID: <200802171718.12006.kbulgrien@worldnet.att.net> > These two are gorgeous! Heh. Ok, then here is a more serious attempt. This one might be worth checking into SVN. http://krayvin.home.att.net/gtk-v2-modified-640x480.png http://krayvin.home.att.net/gtk-v2-modified-640x480-0.5mapscale.png It would look better if I set my text font smaller, but it shows that it is doable. > There has been (I do not know about the newest trunk) a bug in the map > scaling algorithm. I have used the 50% map extensively and it has a bug > which makes places disappear from map-window (you can click to see them, > though). Is this a known bug? If so, skip the rest. =) > > This happens, for example, with certain types of "hole" on "hills". One of > the holes close to Scorn vanishes this way. I think it is the place where > there are lots of earth walls to bash. It may be the ogre chief cave as > well. I do not have any copies of cf installed at the moment, so I cannot > check. Are you talking about a smoothing issue? I notice that sometimes I do need to fix that here and there because entrances get hidden. That said, I have issues with any scale other than 50 or 100 it seems. I think the scaling and smoothing aren't very compatible, but I have not tried to figure out what is going on. Kevin From kbulgrien at worldnet.att.net Sun Feb 17 18:32:41 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 17 Feb 2008 18:32:41 -0600 Subject: [crossfire] GTK V2 @ 640x480! In-Reply-To: <200802171718.12006.kbulgrien@worldnet.att.net> References: <200802170230.11371.kbulgrien@worldnet.att.net> <200802172028.12993.juhaj@iki.fi> <200802171718.12006.kbulgrien@worldnet.att.net> Message-ID: <200802171832.41854.kbulgrien@worldnet.att.net> >> These two are gorgeous! > > Heh. Ok, then here is a more serious attempt. This one might be worth > checking into SVN. > > http://krayvin.home.att.net/gtk-v2-modified-640x480.png > > http://krayvin.home.att.net/gtk-v2-modified-640x480-0.5mapscale.png > > It would look better if I set my text font smaller, but it shows > that it is doable. On second thought, I like this even better... http://krayvin.home.att.net/gtk-v2-sixforty-640x480-0.5scale.png Kevin From leaf at real-time.com Tue Feb 19 20:42:20 2008 From: leaf at real-time.com (Rick Tanner) Date: Tue, 19 Feb 2008 20:42:20 -0600 Subject: [crossfire] Who uses the scrollbars around the map? In-Reply-To: <47B65190.9060908@sonic.net> References: <20080215111321.412a97dc@ibiza.islands.lab> <200802150909.06806.kbulgrien@worldnet.att.net> <47B65190.9060908@sonic.net> Message-ID: <47BB938C.9040407@real-time.com> Mark Wedel wrote: > > My idea was to be able to scroll the map window to see fog of war data, etc > (while it could be used, I didn't really envision someone with a 13x13 display > area playing with 25x25 map data and scrolling about). > > Instead, the idea was more like 'I think I've cleared out this dungeon level. > Let me scroll around the map window to see if I've missed anything'. Or in > the case of maps with a more maze like layout 'let me scroll around and see how > I get back to the exit'. > > But they can certainly go away until (if ever) that feature gets implemented. If/when this feature is implemented - I think it would be a good idea to include a button or something to recenter the viewpoint directly over your character. Otherwise, I imagine it would very frustrating to have to scroll around looking to see where you are at in some maps. ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080219/c5428b7c/attachment.pgp From kbulgrien at worldnet.att.net Tue Feb 19 20:52:53 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 19 Feb 2008 20:52:53 -0600 Subject: [crossfire] Who uses the scrollbars around the map? In-Reply-To: <47BB938C.9040407@real-time.com> References: <20080215111321.412a97dc@ibiza.islands.lab> <47B65190.9060908@sonic.net> <47BB938C.9040407@real-time.com> Message-ID: <200802192052.53428.kbulgrien@worldnet.att.net> > If/when this feature is implemented - I think it would be a good idea to > include a button or something to recenter the viewpoint directly over > your character. > > Otherwise, I imagine it would very frustrating to have to scroll around > looking to see where you are at in some maps. ;-) That little square button in the lower right corner is there just for that very purpose... Kevin From mwedel at sonic.net Wed Feb 20 02:02:03 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Feb 2008 00:02:03 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802120703.21313.kbulgrien@worldnet.att.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> Message-ID: <47BBDE7B.2070503@sonic.net> So I played around a little bit last night with making the map deal with size requests properly. Just to play around, I made two minor changes: In the glade layout file (in this case, I used the gtk-v2 glade file), I removed the size specification in the drawingarea_map widget. In the gtk-v2/src/map.c file, I removed the gtk_widget_set_size_request() on the drawingarea. Both of those seem critical, as without them, they set what seems to be the minimum size the drawingarea can be, and won't let me resize it smaller (I can move the viewpanes, but the window stays the same size and it doesn't generate any configure requests). Now one might thing that isn't that big a deal - it will figure out the right layout on its own. Unfortunately, this is not the case, and glade does some whacky things - see: http://tavern.santa-clara.ca.us/cf/gtk-v2-layout.png This in spite of the fact that the map area and stat vpane is set with specific placement. And what I find even odder is that it screws up the inventory area - this seems like an effort on glade to try and align things. If I put the size specification back in the glade file (but still have that code change), it puts things in the right place. Also, if I go and move the panes around into the right spot, and then save off the window position, next time I run the client, things are in the right place. Now these placements seem to be an issue related to glade, and probably not something we can solve mucking in my code. But my thought is this - since saved window placements work out fine, what about including default window placements as part of SVN? When the client runs, it can look for these placements in the normal install area if it doesn't fine a user customized one (if it finds a user customized one in their homedir, it ignores that global one). This fixes any odd placement issues, and I think will actually make the glade stuff a bit more morphable, as I suspect a fair number of layouts may have various size settings for things to 'look' right, which may not be quite the right thing. Another thought related to this is that I could also perhaps see different versions of these window positions for different resolutions. For example, a new user running on a laptop with a 1440x900 resolution screen fires up the client. The client can do a pretty simple query to see what the resolution is. It decides the layout.1280x1024 isn't good (won't all fit on the screen), but that layout.1024x768 does, so it uses that. A user running on an old laptop (800x600) has it use the layout that actually works right on that size. Making all these different resolutions files would be a pain, and probably only really necessary for whatever is the default layout. But there is no reason that these layout files should be any different than the .pos files saved in the .crossfire directory, so would be very easy for users to contribute them (in that 1440x900 case, the user might say 'here is the layout I use for this resolution') From mwedel at sonic.net Thu Feb 21 01:43:28 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Feb 2008 23:43:28 -0800 Subject: [crossfire] Using svnmerge for backporting to branch? In-Reply-To: <20080212162449.3e6d703d@ibiza.islands.lab> References: <20080212162449.3e6d703d@ibiza.islands.lab> Message-ID: <47BD2BA0.2080407@sonic.net> Perhaps the biggest problem with using svnmerge is getting everyone to use it. For myself, I've been doing merges with 'svn merge ...' Do have a few questions however: What happens if someone doesn't use svnmerge - makes change in trunk, and then still does manual merge in branch? I'm guessing it would try to re-merge it then? Given fairly big code changes in the server from trunk and client (item refactoring, some others), one gets more cases of automatic merges not working. I'm guessing this really doesn't change much (svnmerge won't get confused with those changes?) What about 'reverse' commits? It doesn't happen very often, but sometimes I make the bugfix first on the branch, and then commit back to server? From drnlmuller+crossfire at gmail.com Thu Feb 21 03:12:10 2008 From: drnlmuller+crossfire at gmail.com (Neil Muller) Date: Thu, 21 Feb 2008 11:12:10 +0200 Subject: [crossfire] Using svnmerge for backporting to branch? In-Reply-To: <47BD2BA0.2080407@sonic.net> References: <20080212162449.3e6d703d@ibiza.islands.lab> <47BD2BA0.2080407@sonic.net> Message-ID: On Thu, Feb 21, 2008 at 9:43 AM, Mark Wedel wrote: > > Do have a few questions however: > > What happens if someone doesn't use svnmerge - makes change in trunk, and then > still does manual merge in branch? I'm guessing it would try to re-merge it then? It will try to re-merge, since it has no information to prevent that. Marking revisions as merged is quite simple. though, so resolving these cases is usually a few minutes work. > Given fairly big code changes in the server from trunk and client (item > refactoring, some others), one gets more cases of automatic merges not working. > I'm guessing this really doesn't change much (svnmerge won't get confused with > those changes?) svnmerge is still using svn's underlying merge, so it shares the same issues. Unless something hapens to the svn properties svnmerge uses to track which merges have happened, it won't have any additional problems dealing with large code changes. > What about 'reverse' commits? It doesn't happen very often, but sometimes I > make the bugfix first on the branch, and then commit back to server? Those can easily be handled by marking the relevant commit as already merged. -- Neil Muller drnlmuller at gmail.com From kbulgrien at worldnet.att.net Thu Feb 21 06:56:17 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 21 Feb 2008 06:56:17 -0600 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <47BBDE7B.2070503@sonic.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47BBDE7B.2070503@sonic.net> Message-ID: <200802210656.17405.kbulgrien@worldnet.att.net> > So I played around a little bit last night with making the map deal with > size requests properly. > > Just to play around, I made two minor changes: In the glade layout file > (in this case, I used the gtk-v2 glade file), I removed the size > specification in the drawingarea_map widget. > > In the gtk-v2/src/map.c file, I removed the gtk_widget_set_size_request() > on the drawingarea. > > Both of those seem critical, as without them, they set what seems to be > the minimum size the drawingarea can be, and won't let me resize it smaller > (I can move the viewpanes, but the window stays the same size and it > doesn't generate any configure requests). Remember that the .glade file has size requests for the map drawingarea. I have been playing with removing the size requests in the glade file (without looking much at the code) to try to make sizing more flexible, but have had a lot of trouble with other issues when I did that. Maybe some solution involves both code and the glade file. > Now one might thing that isn't that big a deal - it will figure out the > right layout on its own. Unfortunately, this is not the case, and glade > does some whacky things - see: > > http://tavern.santa-clara.ca.us/cf/gtk-v2-layout.png Yes, I've seen stuff like that even just playing with the .glade files. I have not figured out all what is going on. There are shrink and resize properties for some widgets that seem important, but I don't yet know enough how to correct some of the problems. Some things can even render the position settings on the *panes completely ineffective as you say below. > This in spite of the fact that the map area and stat vpane is set with > specific placement. And what I find even odder is that it screws up the > inventory area - this seems like an effort on glade to try and align > things. If I put the size specification back in the glade file (but still > have that code change), it puts things in the right place. > > Also, if I go and move the panes around into the right spot, and then > save off the window position, next time I run the client, things are in the > right place. > > Now these placements seem to be an issue related to glade, and probably > not something we can solve mucking in my code. > > But my thought is this - since saved window placements work out fine, > what about including default window placements as part of SVN? I have considered this a bit, but did not think about it as much as you have. You may be on to something. > When the client runs, it can look for these placements in the normal > install area if it doesn't fine a user customized one (if it finds a user > customized one in their homedir, it ignores that global one). This fixes > any odd placement issues, and I think will actually make the glade stuff a > bit more morphable, as I suspect a fair number of layouts may have various > size settings for things to 'look' right, which may not be quite the right > thing. > > Another thought related to this is that I could also perhaps see > different versions of these window positions for different resolutions. > > For example, a new user running on a laptop with a 1440x900 resolution > screen fires up the client. The client can do a pretty simple query to see > what the resolution is. It decides the layout.1280x1024 isn't good (won't > all fit on the screen), but that layout.1024x768 does, so it uses that. > > A user running on an old laptop (800x600) has it use the layout that > actually works right on that size. > > Making all these different resolutions files would be a pain, and > probably only really necessary for whatever is the default layout. But > there is no reason that these layout files should be any different than the > .pos files saved in the .crossfire directory, so would be very easy for > users to contribute them (in that 1440x900 case, the user might say 'here > is the layout I use for this resolution') It's worth thinking about, though at some consideration, it seems quite noisy/messy to store individual files as the sources, though admittedly, likely very easy to implement (which is a lot of why I went with name.pos in .crossfire). I'd think one could have a .pos converter that could roll this data into a single file where one could have some meta-data could more easily be used than having layout sizes in the file name. The .pos file could be simply "contain" by some markup because it is a consistent format. A reverse tool would spit out the equivalent file when it was selected. Dunno. Random thoughts. Real Life is encroaching hard right now, but wanted to respond as I've been messing in this area lately. Kevin From raphael at gimp.org Thu Feb 21 08:25:29 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Thu, 21 Feb 2008 15:25:29 +0100 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <20080214183819.25a1cb32@ibiza.islands.lab> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47B283A2.6080203@sonic.net> <20080214183819.25a1cb32@ibiza.islands.lab> Message-ID: <20080221152529.6d5a28b6@ibiza.islands.lab> Unfortunately, it looks like I never received Mark's reply to my previous message due to some problems with my mail server, although I see his message in the list archives. So I will quote from the archives instead: In a message lost on Fri Feb 15 00:34:48 CST 2008, Mark Wedel wrote: > One nice thing right now is that all the layout work is done in glade. This > makes it very easy to try different things, but also makes it very easy to add > onto the layout. So while things could be done better, I'd want to make sure we > don't drift away from also being able to manage the layouts within glade. > Having thousands of lines of handwritten code to handle ideal layouts may be > nice from an end user perspective, but starts to get really unmanagable from a > developer perspective. I agree that designing a fixed layout with handwritten code is not a good solution. However, this would be less of a problem for a layout that is entirely customizable by the user (the user can add/remove columns and can place arbitrary elements in each column). The ideal solution in this case would be to use custom widgets for the docks and dockable items, and to have them supported by glade. I will have a look at how difficult this would be. > At the same time, the first time a person runs the client, popping up some > config options may still not be a bad thing, as right now, for lots of the > config options, the client chooses defaults which may not be ideal. Sure. On the other hand, a first-time config is not ideal for those who share a home directory between several machines with different screen sizes. So it would still be nice to have the freedom to re-arrange the layout by dragging widgets around. > I'd make some adjustments even on those key points - inventory can/should be > done better. Its been discussed, but what is really needed is ability to make > up a custom list of objects I care about. In combat, there are probably less > than 20 items I really need to see in my inventory - things like certain scrolls > and potions, and maybe a few different weapons. I don't need to see all my > items, and in fact, seeing all my items often makes it difficult to get to the > ones I really need. We already have tabs for the full inventory and for items that are applied, cursed, magical, etc. It would be nice to add another tab that would be a "filtered inventory" or maybe a "quick pick" list. But I am wondering how to design a proper user interface that would allow the user to select what should be shown there. Maybe another tab, pop-up window or drop-down menu showing the full inventory with checkboxes or as a multi-select list? And then only the selected items would be shown. But maybe the filter should be based on categories of items instead of single items? Otherwise it would be tedious to reselect the items each time you pick up or drop something. > > Most important (sorted by order of importance): > > - HP/SP/Gr/Food bars > > - range (current spell or bow) - important if I have the wrong thing active > > and I am wondering why the monsters around me are not harmed > > - protections (percentages for all current protections, armor) - important > > especially when they change because I have been hit or a spell expires. > > Pretty much agree. But I also think a better way to manage the protections is > needed. While I want to be able to see them, being able to easily notice that > my resist fire has gone from 90 to 20 may be difficult. I think that I suggested a solution a long time ago: highlighting the changes for the protections. Basically, every time a protection changes (goes up or down), the corresponding number would be highlighted in a different color (e.g., green for up, red for down) and then slowly fade back to the default color (black in most themes). So if your protection goes down, it would be highlighted in bright red for a very short time, then turn to normal red and slowly fade to black (over 2-3 seconds). The same code could be used for stats, skills experience, etc. > Ideally something like a spell monitor would be nice - protections on my > character are almost certainly controlled by various potions the character > drinks. Because the duration of these potions can not really change, it is a > fairly simple matter for the server to inform the client that 'Joe drank a > potion of fire resistance, it will last for 30 seconds'. Clearly it would be > done in a more concise term than that, but you get the point. > > So maybe some space in the statbar area could be used for this. A simple > solution would be to use different icons for the different resistances/spell > effects, and the client draw a little stat along with the icon, so one can see > how much time is left on the spell. That would require a bit more coding effort, but that would certainly be nice. And it could also be combined with what I suggested above. The main thing would be to pass the (estimated) timing information from the server to the client. Once this information is available, we could think about various ways to make it visible in the client: decreasing vertical or horizontal bar, text or image that changes color, animated shield symbol that spins slower and slower, simple text-only message that is displayed a few seconds before the protection expires, countdown for the last 5 seconds, etc. > > - AC > > - damage > > - speed > > - weapon speed > > - WC > > While the above are handy, they also typically are not things that change in > combat, so I don't really need to see them in a glance. At some point, less may > be more - show me the data I care about, and don't show me other data, even if > there is space for it, because it can then become harder to pick out the data I > do care about. That's right, they are less important. I listed them because they can (rarely) change during combat, for example if you have no protection against slow or if your equipment is hit by acid. But I agree with your comment. When these things happen, I am usually in trouble anyway and I will probably focus more on my HP and on finding a way out than on how these values are changing. So the things that are the most important and should be displayed at all times are the HP/SP/Gr/Food bars and range (current spell or bow). If possible, also display the protections although this could be in a tab that can be replaced by skills or other stats like AC, WC, speed, etc. Basically, I would be happy with the gtk v2 layout if the range info was visible permanently instead of being buried inside a tab with other less useful information. Then I could choose to display the tab with the protections (if I have some temporary ones) or with the skills exp (if I am in a party and I want to check if I gain exp in the right skills). > A nice effect of a window is that it can be made persistent if I have enough > screen real estate. That's right, but this also has a cost: a top-level window has some decorations that can take valuable space on smaller screens. So if you have a small display, then it is better to have as much as possible inside a single main window. > Last note, unrelated to layout, but related to usability, is that inventory > control should really get an overhaul - in addition to a 'favorites' list, the > fact that there are various shift/control left/right click combos to do certain > things is just insane. My suggestion is left click examine, middle click apply, > right click brings up menu with all sorts of other options (lock/unlock, drop, > mark as favorite, mark as object for things like flint & steel + torch combo, > and so on). > > Shift left-click could be drop - still not hard to drop stuff then, as you > could keep your finger on the shift key. And there could still be other obscure > control/alt/whatever combos to do a lock or mark or favorite item thing quickly, > but having that default is hardly user friendly. I couldn't agree more. All options that are currently hidden behind some strange combinations of button clicks and modifiers would be much more discoverable by the users if there was some kind of context menu for the inventory. This would solve the problem of defining favorites (well, at least for single items, maybe not for categories of items) and it would also provide room for expansion for all other actions that we might add in the future. -Rapha?l From raphael at gimp.org Thu Feb 21 08:27:37 2008 From: raphael at gimp.org (=?UTF-8?B?UmFwaGHDq2w=?= Quinet) Date: Thu, 21 Feb 2008 15:27:37 +0100 Subject: [crossfire] Using svnmerge for backporting to branch? In-Reply-To: <47BD2BA0.2080407@sonic.net> References: <20080212162449.3e6d703d@ibiza.islands.lab> <47BD2BA0.2080407@sonic.net> Message-ID: <20080221152737.482cf1b1@ibiza.islands.lab> On Wed, 20 Feb 2008 23:43:28 -0800, Mark Wedel wrote: > > Perhaps the biggest problem with using svnmerge is getting everyone to use it. This is not a requirement. It is easier if most developers use it, but it can also cope with revisions that are merged by hand. To be frank, when someone suggested last year that I start using svnmerge for the gimp-related svn modules, I was a bit reluctant at first. And I was also wondering what would happen if some developers were not using it. But after I started using it, I understood that it was just a smart wrapper around 'svn merge' that makes revision tracking easier and does not get in the way if you still want to do things by hand. That's why I am now convinced that such a tool is useful. But it doesn't do miracles either and I am not here for promoting it actively, so it is also fine for me if we decide not to use it. > What happens if someone doesn't use svnmerge - makes change in trunk, and then > still does manual merge in branch? I'm guessing it would try to re-merge it then? In the background, the svnmerge script calls 'svn merge' anyway. What will happen in this case is that svnmerge will show you that this revision is still 'available' for merging. However, when merging it will detect that the change was already merged, just like if you would try 'svn merge' twice on the same revisions. Once you commit, svnmerge will mark that revision as already merged, so that it will not pop up again when anybody else uses 'svnmerge avail' to list the candidates for merging. > Given fairly big code changes in the server from trunk and client (item > refactoring, some others), one gets more cases of automatic merges not working. > I'm guessing this really doesn't change much (svnmerge won't get confused with > those changes?) Since svnmerge uses 'svn merge' to merge the changes, it will not get more or less confused. The main difference is that one can explicitly block some revisions if they are not bug fixes and should not be merged. > What about 'reverse' commits? It doesn't happen very often, but sometimes I > make the bugfix first on the branch, and then commit back to server? This is not very elegant, but it also works. You can always merge things by hand anyway, and then later mark the revisions as merged. To give you an idea of how it works, I suggest that you have a look at this page and read the sections "1 Features" and then "7 Quick Usage Overview": http://www.orcaware.com/svn/wiki/Svnmerge.py -Rapha?l From juhaj at iki.fi Thu Feb 21 12:04:18 2008 From: juhaj at iki.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Thu, 21 Feb 2008 20:04:18 +0200 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <20080221152529.6d5a28b6@ibiza.islands.lab> References: <200802120703.21313.kbulgrien@worldnet.att.net> <20080214183819.25a1cb32@ibiza.islands.lab> <20080221152529.6d5a28b6@ibiza.islands.lab> Message-ID: <200802212004.25989.juhaj@iki.fi> > I think that I suggested a solution a long time ago: highlighting the > changes for the protections. Basically, every time a protection changes Something like this would be very helpful. Perhaps accompanied by a warning sound (should the user have sounds), too. This has been so big a problem, that I have considered writing a small script to recast all protection spells whenever they expire, but never got around to do that. > > Ideally something like a spell monitor would be nice - protections on > That would require a bit more coding effort, but that would certainly be Wait a second, I don't quite follow you now. Don't we already have this? At least protection spells cause a message "your protection from X is running out" some time before it actually runs out. Could we not use the same code (base) for an overall monitor? This warning was actually so big improvement when it was introduced that it probably was the main reason I did not write the above mentioned script. > That's right, but this also has a cost: a top-level window has some > decorations that can take valuable space on smaller screens. So if you > have a small display, then it is better to have as much as possible > inside a single main window. You can always request a decorless window from the window manager. I think any decent ;) window manager disregards the application's request, though, since it should be the user, who decides that. But the user with such a window manager can always tell the WM to remove the decors if they are too big. Unfortunately, according to the above requirement, I know just two decent window managers and I know no one who uses either. Luckily most wm's are almost decent and can add/remove decors when user wants. > I couldn't agree more. All options that are currently hidden behind > some strange combinations of button clicks and modifiers would be much > more discoverable by the users if there was some kind of context menu for Agreed. Although, I hate menus - shortcut keys and mouse-key-click -combos are so much faster, when you know the magic combo. But, like you already noted, these have the problem of being obscure and hard to remember (unless you use them frequently), so having a "slow" way of accessing these functions is very helpful. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080221/09c88e74/attachment.pgp From mwedel at sonic.net Thu Feb 21 21:39:31 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 21 Feb 2008 19:39:31 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802212004.25989.juhaj@iki.fi> References: <200802120703.21313.kbulgrien@worldnet.att.net> <20080214183819.25a1cb32@ibiza.islands.lab> <20080221152529.6d5a28b6@ibiza.islands.lab> <200802212004.25989.juhaj@iki.fi> Message-ID: <47BE43F3.6000209@sonic.net> Juha J?ykk? wrote: >> I think that I suggested a solution a long time ago: highlighting the >> changes for the protections. Basically, every time a protection changes > > Something like this would be very helpful. Perhaps accompanied by a warning > sound (should the user have sounds), too. This has been so big a problem, > that I have considered writing a small script to recast all protection spells > whenever they expire, but never got around to do that. I think highlighting protections as they change is a reasonable first step. but IIRC, there is also space issues related to fitting all the protections in the requisite area. > >>> Ideally something like a spell monitor would be nice - protections on >> That would require a bit more coding effort, but that would certainly be > > Wait a second, I don't quite follow you now. Don't we already have this? At > least protection spells cause a message "your protection from X is running > out" some time before it actually runs out. Could we not use the same code > (base) for an overall monitor? This warning was actually so big improvement > when it was introduced that it probably was the main reason I did not write > the above mentioned script. Messages being printed tend to get lost in the shuffle, at least in a nasty battle. This is sort of why i say less is more - having less information but making the information I care about more visible may be quite useful. > >> That's right, but this also has a cost: a top-level window has some >> decorations that can take valuable space on smaller screens. So if you >> have a small display, then it is better to have as much as possible >> inside a single main window. > > You can always request a decorless window from the window manager. I think any > decent ;) window manager disregards the application's request, though, since > it should be the user, who decides that. But the user with such a window > manager can always tell the WM to remove the decors if they are too big. > Unfortunately, according to the above requirement, I know just two > decent window managers and I know no one who uses either. Luckily most wm's > are almost decent and can add/remove decors when user wants. I don't think this top level window should be the only way way to see protections, but could be a good to provide a larger/better view of the protections. Same could be said for skills and perhaps inventory. A top level window for skills could be nice - list exp, show a nice progress bar on exp to next level, maybe even have some nice context information on how to use the skills (the message portion of the skill object). At the same time, I don't think this should be the only way to see skill information - showing it under a notebook on the client is still good. In a sense, one could sort of see this with the spell window - you don't need that window to cast spells, but it can provide some nice information in a better format than just the output of 'cast' can. I think the one that could have the greatest benefit here is an inventory handling window. Aside from a current problem right now of it sometimes being a bit too small to see full information for objects, I could see a full sized window having everything you might need: Icon, item name, weight, different check boxes to denote equipped/locked/different favorite lists (one could see having a few different favorite lists - up to players how they use them - it could be based on type of foe - fire creature items list and cold creature items list, or different items, whatever. It would be even cooler to list the value of items (based on current shop and 'real' value), so one can quickly see different objects, etc. And for that matter, include the message field of the object in that list if reasonable. Depending on space, maybe include a few other key things, like damage or AC/armor values I probably wouldn't go around adventuring with such an object inventory window up, but back in town at the shop, figuring out what to sell, such a window could be quite handy way to provide more concise information (being able to sell objects through the window should still be allowed). And likewise, having all that information at hand could be really handy to see relative value of different objects (damage, ac, whatever). Right now, I often spend a lot of time examining the different objects to see what they do. > >> I couldn't agree more. All options that are currently hidden behind >> some strange combinations of button clicks and modifiers would be much >> more discoverable by the users if there was some kind of context menu for > > Agreed. Although, I hate menus - shortcut keys and mouse-key-click -combos are > so much faster, when you know the magic combo. But, like you already noted, > these have the problem of being obscure and hard to remember (unless you use > them frequently), so having a "slow" way of accessing these functions is very > helpful. I'll look at doing that. It would mean changing the bindings some, but even with 2 buttons (left and middle), there are probably enough control and shift combos to cover all the needs. From mwedel at sonic.net Thu Feb 21 21:47:08 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 21 Feb 2008 19:47:08 -0800 Subject: [crossfire] GTK V2 client default layout and map size In-Reply-To: <200802210656.17405.kbulgrien@worldnet.att.net> References: <200802120703.21313.kbulgrien@worldnet.att.net> <47BBDE7B.2070503@sonic.net> <200802210656.17405.kbulgrien@worldnet.att.net> Message-ID: <47BE45BC.20506@sonic.net> Kevin R. Bulgrien wrote: >> Now one might thing that isn't that big a deal - it will figure out the >> right layout on its own. Unfortunately, this is not the case, and glade >> does some whacky things - see: >> >> http://tavern.santa-clara.ca.us/cf/gtk-v2-layout.png > > Yes, I've seen stuff like that even just playing with the .glade files. > I have not figured out all what is going on. There are shrink and resize > properties for some widgets that seem important, but I don't yet know > enough how to correct some of the problems. Some things can even render > the position settings on the *panes completely ineffective as you say > below. I played with shrink and resize, but those didn't seem to have any effect in my case. It may that the shrink and resize of the different widgets are what is important. What I suppose I find really annoying about this is that the vpanes are set with specific locations, but when run through the client, don't seem to be used. All I really want is for the client to display things the same way they look in glade, but that doesn't seem to happen. I've seen this in some other projects I've done with glade. > It's worth thinking about, though at some consideration, it seems quite > noisy/messy to store individual files as the sources, though admittedly, > likely very easy to implement (which is a lot of why I went with name.pos > in .crossfire). I'd think one could have a .pos converter that could > roll this data into a single file where one could have some meta-data > could more easily be used than having layout sizes in the file name. > The .pos file could be simply "contain" by some markup because it is a > consistent format. A reverse tool would spit out the equivalent file > when it was selected. My thought for storing the individual files is that it may actually be easier. The code that loads them and actually makes the changes doesn't need to be modified, as format is the same. The only thing that would need work is the chooser of the right file (the different resolution files). But that is probably just some work with readdir and the like. If the number of .pos files grew very large, then I might rethink on how to store it - having 200 different files would likely be annoying. From mwedel at sonic.net Wed Feb 27 02:06:30 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 27 Feb 2008 00:06:30 -0800 Subject: [crossfire] Spell rebalancing notes/thoughts Message-ID: <47C51A06.1000203@sonic.net> Finally found some time to get back to the rebalancing of spells. For now, I've just started with an elven pyromancer - I didn't want to go to any of the more special races - I figure starting with a good baseline is important. I gave that class a couple spells: firebullet - like magic bullet, this fires a bullet that does damage. It does not explode into a fireball. Costs 1 sp to cast firebolt - basically same as old ones, just lower damage. Costs 2 sp to cast. I figure that for low level spells, when character won't have many mana, they should start at the low end of the sp cost. I also reduced the casting time - before, both had a fairly high time, which basically meant that at best, you could only cast the spell every other or every third tick. Now you can pretty much cast the spell ever ticket But even with that, I found that I was waiting for mana to regen a lot. I suppose this isn't really any worse than fighters waiting for hp to regen. Since by the very nature, these are range spells, the wizard should ideally kill the creatures before they get next to him, and if they get close, fall back, cast again, and so on. But there are also a couple key points here - one actually needs the space available to fall back. In the newbie tower, once I started making progress, I could basic remain beyond the monsters detect range and hit them with spells (and once the kobolds are dead, gives an outer circle to move in. But the difficult time was initial assault - after opening the doors, kobolds come out eliminating much space to move about. The generator limit I put in is quite important - without that, progress would be quite slow - getting through the front doors may have been difficult with those generators always being there. Another change I made was to give the pyromancer a spell regen bonus - this helps reduce the waiting some more. Rather than that being a force (how I instituted it), doing it as a ring may make more sense - player can upgrade it, but it also means that they don't really get a bonus if they choose a wizard and play it as a fighter (at some point, they'd likely find a ring more suitable for a fighter, and thus loose that sp regen bonus) I'm thinking some defensive spell may be in order, so if creatures do get close, they get killed. OTOH, maybe that is part of being a mage - you really don't want to be close to monsters. But many maps don't give much choice - go through the exit, and monsters are behind door 2 spaces away. Another change I'm thinking of is item destruction. The firebullet doesn't destroy items, but the bolt does. I'm thinking that maybe bolts shouldn't destroy items either - as I see it, bolts are maybe a 1' diameter bolt that is 3' or so off the ground as it travels - as such, things on the ground shouldn't be destroyed. Otherwise, especially I think at lower levels, using bolts is a pretty big disadvantage because of all the treasure it destroyes. I'm somewhat happy on damage - a couple spells will kill the orc - the choice between bullet and bolt really depends on number of creatures - if you have several nicely lined up, bolt is clearly better, but for stragglers or individual monsters, bullet works pretty good. It may be that instead of defensive spell, giving them burning hands (cone spell), but with very limited range would work. But then, I'm also not sure how many spells we should/want to give out at first level - we need to keep some new spells for players to get as they gain levels.