From nicolas.weeger at laposte.net Sun Feb 4 04:27:10 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 4 Feb 2007 11:27:10 +0100 Subject: [crossfire] Changelog for maps and archetypes Message-ID: <200702041127.10953.nicolas.weeger@laposte.net> Hello. What about we create a ChangeLog file for maps and archetypes too? This way we could track what happens more precisely than commit messages. Also, I suggest we resurrect the Crossfire Traffic (http://wiki.metalforge.net/doku.php/crossfire_traffic), for gameplay and such changes. We should could changes like: * gameplay whanges (like: wraith patch) * new features (like: apply -b) * bugfixes and maybe * development side (refactoring, ...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Mon Feb 5 02:58:30 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Feb 2007 00:58:30 -0800 Subject: [crossfire] GtkV2 client theme support. Message-ID: <45C6F1B6.8070702@sonic.net> I've just committed a change to the GTK2 client so it now supports different themes. There are only 2 now (Standard & Black), but should be easy to make more. Various notes: - The various hard coded values in the client are gone, and are now in the themes (fonts and in some places colors). This means that if you don't install the themes, you'll have a plainer looking client. If you do a 'make install', it will install the themes where the client expects to find them. Your theme preference will be stored in the gdefaults2 file, and can be changed in the config window. If no default is specified, it defaults to the Standard theme. - The 'Standard' theme is a theme that I wrote that tries to match the previous hardcode values (red for cursed inventory items, matching colors for text, etc). In addition to the Standard & Black themes, there is also a 'None' theme, which basically means don't use any special theme - just get all values from system wide theme. Effect on this is you won't see any colored text in the text panes, the inventories won't differ based on magic/cursed/etc status, and stat bars will use system default color for progressbars. - The client does support switching between themes on the fly - no restart needed. Even things like style of the text messages will get updated. However, if you go to the None theme, and then go to another theme, the text messages will still all appear in the default color - this is because when switching to the None theme, it deletes all the color text tags, where as when switching between actual themes, it updates the text tags with new values. - One case where the new system is slightly lacking compared to old is compound status on inventory items - old code had special logic for cursed & magic items (drawn in dark navy). Given there are 5 different status of items right now, I didn't want to try to handle all of those possible combos, so instead it just has a simple precedence (unpaid > cursed > magical > applied > locked) - There are many areas where this new code has more options than previous: - For the inventory lists, foreground color and font style can be set. The Standard setting extends previous logic by drawing locked items in italics and equipped items in bold. - The color for the stat (hp/grace/food/etc) bars can now be individually set. You can have your HP bar be red, you grace green, mana blue, etc. You can also use different colors based on graduated drawing or simple low/high/super vlaues. - You can now override the text colors in use. Eg, for black background, you want to change how black text will be drawn, so can say 'draw black text as white text instead'. And like the inventory lists, for all of the text pane values, font and both foreground/background colors can be set - The themes allow setting of font & color values for all of the message type/subtype values. So it possible to change things such that good messages are green, bad are red, etc. Loose ends/TODO: - When I wrote the theme styles for the message type/subtype handling, I looked in the server code to see what colors were being used for the type/subtype. However, in some cases, for the same type of message, different colors were being used depending on who wrote the code. In those cases, I took which color was being used the most, or made the most sense. - Related to above, it may actually make sense to depart from trying to keep things as is, and instead update/re-arrange things so color in the text messages is more consistent and plays a better role, like green=good, red=bad messages, related (but different enough) colors for all chat related messages, etc. - The [color=...] in message tags is problematic. Current handling is that if it setting the color to one of the standard crossfire colors, it works as expected. If setting to anything else, including RGB values, it is just ignored. The problem comes in that the message itself has no idea what styles I'm using on the client. A [color=#000000] really sucks if I have a black background. Using the standard crossfire colors isn't a problem, because the setting files can change how those look. One thought might be to change the client logic some to try to find the closes match to one of the crossfire color, and use that style. Or another would be to say 'only use standard crossfire colors' in the [color] tags. - The list of themes you can choose from is determined by what files exist in the themes directory. So if you don't see any option under the theme config option, you probably didn't do a make install. Also, it only reads in that directory once at startup IIRC, so if you are working on a new theme and copy it to that directory, you'll have to restart to client to see it in the list. - If doing development, the client will not do anything if the theme doesn't change - there is no 'reread' existing theme option. So your best bet is to choose a different theme, hit apply, then select your test theme again. If you have questions/comments, feel free to ask. From lalo.martins at gmail.com Mon Feb 5 03:07:01 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 05 Feb 2007 17:07:01 +0800 Subject: [crossfire] desktop file: help request Message-ID: Not for the first time, someone came to #crossfire today, requesting help to install crossfire, and it turned out he already had it, but couldn't find it. It turns out we don't ship a .desktop file for the gtk-v2 client, and distros such as ubuntu and fedora won't modify the package to add one. There is such a file for the gtk client, but it refers to a non-existent icon file. So here's a very simple battle plan: 1: Write a proper .desktop file for gtk-v2; possibly use it as a model to update the one for gtk too. I already committed that file. 2: Hook up the build system to install this file to $PREFIX/share/applications or whatever is the appropriate autotools magic. I really don't have time to relearn what little autotools I used to know to do this, so if someone who knows has a few minutes, please help here. 3: The icons should be the ones in pixmaps/*.png, but they are corrupted -- probably need the right propset to be recognised as binaries. Could someone with the svn fu please do this one? 4 (optional): The aforementioned icons are about as pretty as a dog inside out. Seems they were drawn at 16 and scaled up. So if someone with the talent wants to draw new ones, be my guest. 5: Again, they need to be hooked up to the build system, so that one of them (presumably the higher resolution) gets installed to $PREFIX/share/pixmaps/crossfire-client.png This is somewhat low priority, or I'd take the time to learn how to do it myself; but it should be only a few minutes for someone who knows how. cheers, 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. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue Feb 6 01:31:26 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Feb 2007 23:31:26 -0800 Subject: [crossfire] desktop file: help request In-Reply-To: References: Message-ID: <45C82ECE.1060601@sonic.net> Lalo Martins wrote: > Not for the first time, someone came to #crossfire today, requesting help > to install crossfire, and it turned out he already had it, but couldn't > find it. It turns out we don't ship a .desktop file for the gtk-v2 > client, and distros such as ubuntu and fedora won't modify the package to > add one. There is such a file for the gtk client, but it refers to a > non-existent icon file. > > So here's a very simple battle plan: > > 1: Write a proper .desktop file for gtk-v2; possibly use it as a model to > update the one for gtk too. I already committed that file. Looks good. I wonder if we should include something to differentiate the gtk1 & 2 clients. On my system, I do have the icon with the gnome menus for the crossfire client. And all it says is 'Crossfire Client'. If I hover my mouse over it, it gives me a description, but still doesn't say anything about what client is. Often times on the channel, it is recommended someone use a particular client. As the things go now, other than the person running it, there really isn't much client what client they would get. Even calling it something like 'Crossfire Client (Gtk2)' would be much more useful. > > 2: Hook up the build system to install this file to > $PREFIX/share/applications or whatever is the appropriate autotools magic. > I really don't have time to relearn what little autotools I used to know > to do this, so if someone who knows has a few minutes, please help here. This is in the RPM packaging. The normal make install doesn't do anything with the files. The fact that for it to be of any use, it must be installed in the global area, which has a pretty high probability of being outside of whatever --prefix is set to is one reason. One problem is that I believe a uniquely named file is needed for each program. So as things are now, with both the gtk and gtk2 using the same name, when installed, one will get overwritten. The one in gtk2 should be probably be renamed crossfire-client-gtk2.desktop - at least in this way, the name of the desktop file does match the executable. > > 3: The icons should be the ones in pixmaps/*.png, but they are corrupted > -- probably need the right propset to be recognised as binaries. Could > someone with the svn fu please do this one? This should now be fixed. > 5: Again, they need to be hooked up to the build system, so that one of > them (presumably the higher resolution) gets installed to > $PREFIX/share/pixmaps/crossfire-client.png Is that to make them more easily available for users to find them, or something else? > From mwedel at sonic.net Tue Feb 6 01:36:09 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 05 Feb 2007 23:36:09 -0800 Subject: [crossfire] Changelog for maps and archetypes In-Reply-To: <200702041127.10953.nicolas.weeger@laposte.net> References: <200702041127.10953.nicolas.weeger@laposte.net> Message-ID: <45C82FE9.8040604@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > What about we create a ChangeLog file for maps and archetypes too? This way we > could track what happens more precisely than commit messages. Perhaps not a bad idea. There actually is a CHANGES file in the arch directory, but tends not to get updated. One problem is that often times, the changes in those seem more trivial, so you get the question of whether there should be a change message for them. There is some understanding that really minor changes in the server/client code don't require an update to the changelog - I'd say for arch & maps, more trivial changes should be recorded, because the number of changes that otherwise match the criteria are not very many. > > Also, I suggest we resurrect the Crossfire Traffic > (http://wiki.metalforge.net/doku.php/crossfire_traffic), for gameplay and > such changes. That seems like a good idea. From mwedel at sonic.net Tue Feb 6 02:03:49 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Feb 2007 00:03:49 -0800 Subject: [crossfire] Data File (Maps, Archetypes) Encodings In-Reply-To: <200701312133.32097.cher@riedquat.de> References: <200701312133.32097.cher@riedquat.de> Message-ID: <45C83665.5010400@sonic.net> Christian Hujer wrote: > Hello dear co-devs. > > > We have a common problem with the text encodings of data files. > > Examples: > * Daimonin used (until a few minutes ago) the ISO paragraph character 0xA7 for > separating a map's sound spec from its name. > * Daimonin uses the ISO degree character 0xB0 for highlights in messages. > * Crossfire uses the a circumflex character 0xE2 for the name of a wine in > map /maps/scorn/houses/house3.bas2. Not sure if still the case, but at one time there were some objects that also used special characters - Mj?lnir comes to mind. > > This leads to some problems. > * Crossfire x11 client displays 0xE2 as a circumflex. > * Crossfire gtk client displays 0xE2 as ? (tested by Ragnor). And it appears in the GTK2 client, it won't draw the entire line/message that has the bad character. > > For both projects, it makes sense to rethink the file formats. I see three > possible solutions: > > 1. Use US-ASCII text only. > That means, only data files with bytes 0x13, 0x20-0x7E are valid. > Pro: easy > Pro: stable > Pro: no changes required. > Con: very limited solution And one that is currently not in use, as demonstrated we already have some non ASCII characters making their way in. > > 2. Use ISO-8859-15 text. > That means, bytes 0x13, 0x20-0x7E, 0xA0-0xFF are valid. > Pro: easy > Con: clients need special handling for non-ascii chars if they are UTF-8 aware > and run on UTF-8 systems (e.g. gtk client). > Con: limited solution > > 3. Use UTF-8 text. > That means, only valid UTF-8 streams with Unicodes u0013, u0020-u007E, > u00A0-... are valid. > Pro: future-proof > Pro: Allows full unicode (e.g. Chinese chars if somebody likes, or even > klingon if the underlying system supports it). > Con: clients need special handling. > Con: Windows users or users of other ancient OS editions with no good UTF-8 > support will have more problems than with ISO-8859-15. > > I see two places, where the encoding needs to be specified: > * Data files > * Network protocol > > My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike 2. > ISO-8859-15 very much. #3 probably makes the most sense, and at least for the gtk2 client, looks like it would actually be handled properly (as the message generated on the wine bottle is about invalid utf8 character). Also, I'm not sure how easy #2 is - it is easy from a person writing the maps or archetypes, but as demonstrated, pretty much all clients would have to do special string handling. #3 does make it harder for people putting the strings in (I'd think the map editors could try to do the right thing in those cases and covert ISO 8859 15 characters to unicode) So I'd vote unicode. I'd suspect that for clients that don't support utf8, things won't really be any more broken than right now - the client would display a funky character instead of the correct one. But I don't believe that would break any portion of the clients or protocol. From tchize at myrealbox.com Tue Feb 6 03:26:40 2007 From: tchize at myrealbox.com (tchize) Date: Tue, 06 Feb 2007 10:26:40 +0100 Subject: [crossfire] Data File (Maps, Archetypes) Encodings In-Reply-To: <45C83665.5010400@sonic.net> References: <200701312133.32097.cher@riedquat.de> <45C83665.5010400@sonic.net> Message-ID: <45C849D0.3080406@myrealbox.com> En l'instant pr?cis du 02/06/07 09:03, Mark Wedel s'exprimait en ces termes: (OT: Did not post for a long time, hello to everyone) > #3 probably makes the most sense, and at least for the gtk2 client, looks like > it would actually be handled properly (as the message generated on the wine > bottle is about invalid utf8 character). > > Also, I'm not sure how easy #2 is - it is easy from a person writing the maps > or archetypes, but as demonstrated, pretty much all clients would have to do > special string handling. > Well, it's just a 256 entries table to convert those character to destination system. > #3 does make it harder for people putting the strings in (I'd think the map > editors could try to do the right thing in those cases and covert ISO 8859 15 > characters to unicode) > At least for java editor, it's not a problem. Java natively supports UTF-8 strings. On the onther hand, java does not support easily iso-8859-1 or iso-8859-15. Java supports UTF-8 and US-ASCII, the other encoding formats support is platform dependent. > So I'd vote unicode. I'd suspect that for clients that don't support utf8, > things won't really be any more broken than right now - the client would display > a funky character instead of the correct one. But I don't believe that would > break any portion of the clients or protocol. > Here is how some special utf-8 characters looks like when drawn in iso-8859-1 utf-8 stored string: ? - ? - ? - ? - ? iso-8859-1 read string: ?? - ? - ?? - ?? - ??? Nothing very critical i think... > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Tue Feb 6 12:29:49 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 6 Feb 2007 19:29:49 +0100 Subject: [crossfire] Data File (Maps, Archetypes) Encodings In-Reply-To: <200701312133.32097.cher@riedquat.de> References: <200701312133.32097.cher@riedquat.de> Message-ID: <200702061929.49284.nicolas.weeger@laposte.net> Hello. > My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike > 2. ISO-8859-15 very much. Favorite solution is 3, UTF-8 :) It works nicely even with non utf8-aware functions (strlen & such), and is international so we'll not have any more issues with that :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Tue Feb 6 18:34:49 2007 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 06 Feb 2007 17:34:49 -0700 Subject: [crossfire] Data File (Maps, Archetypes) Encodings In-Reply-To: <200702061929.49284.nicolas.weeger@laposte.net> References: <200701312133.32097.cher@riedquat.de> <200702061929.49284.nicolas.weeger@laposte.net> Message-ID: <45C91EA9.1090807@telus.net> Nicolas Weeger (Laposte) wrote: >> My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike >> 2. ISO-8859-15 very much. >> > > Favorite solution is 3, UTF-8 :) > It works nicely even with non utf8-aware functions (strlen & such), and is > international so we'll not have any more issues with that :) Agreed again here, UTF-8 seems like a good idea to me. Seems there's a strong consensus of most people towards UTF-8 Alex From lalo.martins at gmail.com Wed Feb 7 18:40:59 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 08 Feb 2007 08:40:59 +0800 Subject: [crossfire] desktop file: help request References: <45C82ECE.1060601@sonic.net> Message-ID: On Mon, 05 Feb 2007 23:31:26 -0800, Mark Wedel wrote: > Looks good. I wonder if we should include something to differentiate the gtk1 > & 2 clients. > > On my system, I do have the icon with the gnome menus for the crossfire > client. And all it says is 'Crossfire Client'. If I hover my mouse over it, it > gives me a description, but still doesn't say anything about what client is. > > Often times on the channel, it is recommended someone use a particular client. > As the things go now, other than the person running it, there really isn't > much client what client they would get. Even calling it something like > 'Crossfire Client (Gtk2)' would be much more useful. Since (a) this is the client that we recommend primarily and (b) people's desktops will more likely be gtk2 than gtk1, I'd argue to leave it as it is and change the gtk1 entry instead. The guidelines for writing desktop entries out there generally call for more descriptive, less technical details. On that spirit, I used the text from the homepage for the "comment" field, rather than the text in the gtk client's desktop file. Another alternative is to use Name and GenericName keys: Name=Crossfire gtk-v2 Client GenericName=Crossfire Client Although that sounds to me like a stretch of the intended usage. See also below for more on that. >> 2: Hook up the build system to install this file to >> $PREFIX/share/applications or whatever is the appropriate autotools magic. >> I really don't have time to relearn what little autotools I used to know >> to do this, so if someone who knows has a few minutes, please help here. > > This is in the RPM packaging. The normal make install doesn't do anything > with the files. The fact that for it to be of any use, it must be installed in > the global area, which has a pretty high probability of being outside of > whatever --prefix is set to is one reason. I'm not sure about gnome, but I do have desktop files in /usr/local/share/applications and xfce reads them just fine. Maybe I should check the freedesktop.org spec on that. Can some ubuntu user verify that a file in /usr/local works? And KDE? > One problem is that I believe a uniquely named file is needed for each > program. So as things are now, with both the gtk and gtk2 using the > same name, when installed, one will get overwritten. The one in gtk2 > should be probably be renamed crossfire-client-gtk2.desktop - at least > in this way, the name of the desktop file does match the executable. I thought of that when writing the file, but I feel that if any file is called crossfire-client.desktop, it should be the gtkv2. Or we could rename both to make it explicit. >> 3: The icons should be the ones in pixmaps/*.png, but they are >> corrupted -- probably need the right propset to be recognised as >> binaries. Could someone with the svn fu please do this one? > > This should now be fixed. thanks. >> 5: Again, they need to be hooked up to the build system, so that one of >> them (presumably the higher resolution) gets installed to >> $PREFIX/share/pixmaps/crossfire-client.png > > Is that to make them more easily available for users to find them, or > something else? That's because we're using an "unqualified name" on the icon field: Icon=crossfire-client That makes the menu system look for a file named crossfire-client.png or crossfire-client.svg in the current icon theme, then in the icon path. It's the recommended way of doing it, so that icon theme authors can write an icon for crossfire if they want. The alternative is to write a full pathname in this field, which would require "compiling" the file after you know the installation prefix. 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. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Thu Feb 8 17:28:57 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 9 Feb 2007 00:28:57 +0100 Subject: [crossfire] Static buffer removal for query_name() Message-ID: <200702090028.57111.nicolas.weeger@laposte.net> Hello. I just committed a big change, removing the static buffer from query_name(), which now takes a buffer + size for working. There were > 150 occurrences, so I couldn't test everything. I may have made mistakes when replacing stuff :) I did take care, but well..... Another concern is that I may have used a buffer too small for certain things (used MAX_BUF instead of HUGE_BUF like it was). Thus some strings may be truncated, that will need some checking (but that shouldn't crash!). And I do plan on removing move static buffers :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Thu Feb 8 22:55:10 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 08 Feb 2007 20:55:10 -0800 Subject: [crossfire] Static buffer removal for query_name() In-Reply-To: <200702090028.57111.nicolas.weeger@laposte.net> References: <200702090028.57111.nicolas.weeger@laposte.net> Message-ID: <45CBFEAE.5040104@sonic.net> Nicolas Weeger wrote: > > Another concern is that I may have used a buffer too small for certain things > (used MAX_BUF instead of HUGE_BUF like it was). Thus some strings may be > truncated, that will need some checking (but that shouldn't crash!). for query_name(), I doubt that buffer size makes a difference. where it may be an issue is describe_item() and get_ob_diff() - but I'm not 100% sure if those return static values or not. From nicolas.weeger at laposte.net Sat Feb 10 01:56:17 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 10 Feb 2007 08:56:17 +0100 Subject: [crossfire] Static buffer removal for query_name() In-Reply-To: <45CBFEAE.5040104@sonic.net> References: <200702090028.57111.nicolas.weeger@laposte.net> <45CBFEAE.5040104@sonic.net> Message-ID: <200702100856.17556.nicolas.weeger@laposte.net> > for query_name(), I doubt that buffer size makes a difference. And we'll fix when needed :) > where it may be an issue is describe_item() and get_ob_diff() - but I'm > not 100% sure if those return static values or not. They did use static buffers :) I used HUGE_BUF, like the static buffer's length was, so should be no issue. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Feb 10 12:27:47 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 10 Feb 2007 19:27:47 +0100 Subject: [crossfire] Client-side LUA support Message-ID: <200702101927.47250.nicolas.weeger@laposte.net> Hello. I just committed to trunk patch #1560052: LUA client-side support, which has been sitting there for some time. From the description: Support is basic for now: scripts can intercept user commands, emit messages and commands, and react to stat change (hp, gr, ...). Look at example file to see how it works. Function to react to stats change is 'event_stats'. When running, the LUA script has access to three variables: * player: contains the player's sp, hp, gr, food (as player.sp) * ground: array containing the items on the spot the player is * inv: array containing the player's inventory and 2 functions: * cfdraw: write a message to player (red only for now) * cfissue: simulates player sending a command. Use is generall cfissue( 1, 1, "xxx" ), for isntance cfissue( 1, 1, "apply bed of reality" ) known issues: * will only work with LUA 5.0.2, NOT 5.1 (init functions changed, check the commented functions) * you can load the same file multiple times As a side note, number of C-defined functions is checked by the code itself, and can vary, so compatibility (adding color to cfdraw) isn't an issue. If some autoconf wizard could add a conditional switch to enable/disable that script, that would be great :) (for now it's always built) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Feb 10 16:42:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 10 Feb 2007 23:42:03 +0100 Subject: [crossfire] House sizes Message-ID: <200702102342.03415.nicolas.weeger@laposte.net> Hello. What would everyone think of: - deciding that eg one outside square translates to eg 20x20 squares inside. There may already be such a measurement, but I'm not sure it's that formal - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns bigger in the bigworld, but at the same time it would make the whole scale more coherent i think Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Feb 11 00:06:33 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 10 Feb 2007 22:06:33 -0800 Subject: [crossfire] House sizes In-Reply-To: <200702102342.03415.nicolas.weeger@laposte.net> References: <200702102342.03415.nicolas.weeger@laposte.net> Message-ID: <45CEB269.3090706@sonic.net> Nicolas Weeger wrote: > Hello. > > What would everyone think of: > - deciding that eg one outside square translates to eg 20x20 squares inside. > There may already be such a measurement, but I'm not sure it's that formal IIRC, there was some measure, like each outside space is 1 chain. A chain is somewhere between 60-100 feet. If one wanted to try and unify scales, one could use that as a base. If each indoor space is 10', then for each tile outside, it would correspond to 10 tiles inside. But I think that is a bit low - there would never be use for any 1 space buildings. a 20x20 seems reasonable. I think to be clear, you need a range, like 15-30/space. In that way, it becomes pretty clear how big an object should be - if 31, that is 2 spaces. Otherwise, if you just say the scale is 20:1, does that mean a building that is 30x30 should be 2 spaces by 2 spaces? What about a building that is 21x21, etc. I'd personally like some more buildings, simply because some buildings are getting re-used for different things (the guild building is used for guilds, but also the bank and some other buildings). But some could also just get changed with existing images - to me, the building currently used for the zoo could be a good bank building (it looks like a fortified building, which would make sense). Could even be interesting to have different guild buildings for the different guilds. And unique buildings for more of the religions (some of the ones in scorn are just re-using generic house images, etc). > - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns > bigger in the bigworld, but at the same time it would make the whole scale > more coherent i think I think we need to be careful here - based on the map size (and past discussions which says 25x25 may in fact be too large), you don't want to make buildings too big. Otherwise, the player only ends up seeing 2-3 buildings. But maybe that isn't a bad thing - then at least towns could get big enough to start to be interesting and/or confusing. I'd be wary of actually re-doing existing towns - moving apartments and other permanent maps about starts to get messy. However, no towns could use the new scale. And for some towns, a bunch of small empty houses could get replaced by fewer buildings that actually have stuff in them. There also isn't any reason that the world has to be static - one could certain envision various buildings showing up outside the town walls (town no longer big enough), or a new section of town built with a new section of wall, etc. From alex_sch at telus.net Sun Feb 11 01:58:27 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 11 Feb 2007 00:58:27 -0700 Subject: [crossfire] House sizes In-Reply-To: <45CEB269.3090706@sonic.net> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CEB269.3090706@sonic.net> Message-ID: <45CECCA3.4060007@telus.net> Mark Wedel wrote: > But I think that is a bit low - there would never be use for any 1 space > buildings. > > a 20x20 seems reasonable. I think to be clear, you need a range, like > 15-30/space. In that way, it becomes pretty clear how big an object should be - > if 31, that is 2 spaces. Otherwise, if you just say the scale is 20:1, does > that mean a building that is 30x30 should be 2 spaces by 2 spaces? What about a > building that is 21x21, etc. > I'd say ranges certainly do make sense. Personally, I'm not sure 10x10 would be so bad however. To me it seems that outdoor buildings with a scale matching the 10x10 scale would be more immersive. Despite that though, I think it would be best to see some mockups of each scale to get an idea of how it would feel to play with. >> - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns >> bigger in the bigworld, but at the same time it would make the whole scale >> more coherent i think >> > > I think we need to be careful here - based on the map size (and past > discussions which says 25x25 may in fact be too large), you don't want to make > buildings too big. Otherwise, the player only ends up seeing 2-3 buildings. > But maybe that isn't a bad thing - then at least towns could get big enough to > start to be interesting and/or confusing. > Well, IMHO it could be a good thing, provided it was well done. So long as it's just as (or more :)) visually interesting, and it doesn't impair navigation of the city much, then it'd have the effect of making things feel more immersive. > I'd be wary of actually re-doing existing towns - moving apartments and other > permanent maps about starts to get messy. However, no towns could use the new > scale. And for some towns, a bunch of small empty houses could get replaced by > fewer buildings that actually have stuff in them. Well, one could target re-doing of existing towns at 2.0, we could create true "bound-exits" where one exit refers to another's location regardless of if they move, or thirdly there is the option of just designing the redid town specifically so the old perm apartment exit was to the right place. Any of those three options would fix the issue IMHO. Alex Schultz From nicolas.weeger at laposte.net Sun Feb 11 13:48:19 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 11 Feb 2007 20:48:19 +0100 Subject: [crossfire] Armour restriction / girdle In-Reply-To: <200701211310.29325.nicolas.weeger@laposte.net> References: <200701202241.33310.nicolas.weeger@laposte.net> <45B31EDB.5080709@telus.net> <200701211310.29325.nicolas.weeger@laposte.net> Message-ID: <200702112048.19507.nicolas.weeger@laposte.net> Ok, I just fixed the whole logic, using this nice IS_ARMOR macro :) Also, girdles and cloaks are not considered as armor anymore, but now that's easy to change :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Feb 11 16:09:48 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 11 Feb 2007 23:09:48 +0100 Subject: [crossfire] Max speed In-Reply-To: <200611261924.44728.nicolas.weeger@laposte.net> References: <200611261924.44728.nicolas.weeger@laposte.net> Message-ID: <200702112309.48763.nicolas.weeger@laposte.net> > Related to bug > https://sourceforge.net/tracker/index.php?func=detail&aid=1539207&group_id= >13833&atid=113833 concerning the max_speed when wearing armor, I've changed > the logic in fix_object (former fix_player) to always cap speed at armor's > max_speed. Apparently that fix was too restrictive, so I kind of reverted it. Now, it would be nice to decide the exact logic we want for max speed handling... Currently, what (apparently) happens is: * speed is computed based on dexterity, and max allowed by armor * some speed is added, from objects in inventory having exp set (?) * some more speed is added, from objects having exp set (but only positive values are taken into account) * carried weight is taken into account * disease induced speed is applied * minimum speed is enforced This looks to me like a kind of mess, so we should probably decide how to fix that :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Feb 11 17:30:03 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 11 Feb 2007 15:30:03 -0800 Subject: [crossfire] Max speed In-Reply-To: <200702112309.48763.nicolas.weeger@laposte.net> References: <200611261924.44728.nicolas.weeger@laposte.net> <200702112309.48763.nicolas.weeger@laposte.net> Message-ID: <45CFA6FB.2080308@sonic.net> Nicolas Weeger wrote: >> Related to bug >> https://sourceforge.net/tracker/index.php?func=detail&aid=1539207&group_id= >> 13833&atid=113833 concerning the max_speed when wearing armor, I've changed >> the logic in fix_object (former fix_player) to always cap speed at armor's >> max_speed. > > Apparently that fix was too restrictive, so I kind of reverted it. > > Now, it would be nice to decide the exact logic we want for max speed > handling... > > Currently, what (apparently) happens is: > * speed is computed based on dexterity, and max allowed by armor Strength also plays a role, in that it determines how much you can carry, and how loaded you are also affects speed. > * some speed is added, from objects in inventory having exp set (?) For objects, exp was used to denote speed adjustment for characters. This is because the normal speed field is used for animation or other logic so couldn't be used. That should really be fixed, and changed to something like 'bonus_speed' or the like. > * some more speed is added, from objects having exp set (but only positive > values are taken into account) > * carried weight is taken into account > * disease induced speed is applied > * minimum speed is enforced > > > This looks to me like a kind of mess, so we should probably decide how to fix > that :) I had another thought, don't know if there is a tracker item, to completely redo how speed is done. Briefly: Normal max speed is 0.75. Normal min speed is 0.25. These values should actually be things in the settings file. How loaded you are determines your base speed. Eg, if 50% loaded, your speed would be 0.5 (0.75 + 0.25)/2 * (1-0.5) + 0.25. If your are 25% loaded, your speed would be 0.62. These values are to improve playability - if a character speed gets too low, it is just annoying to play, as you move once every few seconds. Likewise, this max speed is so fast objects still move fast - arrows faster than the player, etc. Objects that give magical speed bonus would add to this value. So speed values greater than 1.0 are still possible with things like speed boots, etc. Armor should have some effect - I'm not sure if it should be a hard limit (can't move faster than 0.6), or if those should more denote adjustments to current speed - instead of max speed, have it be speed penalty. That penalty could be absolute (drop .2 no matter what) or could be a percentage - wearing plate is going to drop your speed by 25%, so if you speed is 1.0, with plate, it is now 0.75. If your speed is 0.25, with plate, it is now 0.18 This cleans things up, but I think also improves playability - really fast players are an issue, and real slow players are not a good experience. Note that in above formula, dexterity doesn't play a part anymore. However, it still would for weapon speed, which is done differently IIRC. This could also make some new spells (or maybe they exist) more reasonable. Eg, something like haste that gives you bonus speed of .3 for some amount of time could be really handy - as of now, moderate to high level characters have really high speeds, so don't really need an extra boost. Such a change should be targeted for 2.0, since it would change gameplay quite a bit. From mwedel at sonic.net Sun Feb 11 17:38:21 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 11 Feb 2007 15:38:21 -0800 Subject: [crossfire] House sizes In-Reply-To: <45CECCA3.4060007@telus.net> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CEB269.3090706@sonic.net> <45CECCA3.4060007@telus.net> Message-ID: <45CFA8ED.5090507@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> But I think that is a bit low - there would never be use for any 1 space >> buildings. >> >> a 20x20 seems reasonable. I think to be clear, you need a range, like >> 15-30/space. In that way, it becomes pretty clear how big an object should be - >> if 31, that is 2 spaces. Otherwise, if you just say the scale is 20:1, does >> that mean a building that is 30x30 should be 2 spaces by 2 spaces? What about a >> building that is 21x21, etc. >> > I'd say ranges certainly do make sense. Personally, I'm not sure 10x10 > would be so bad however. To me it seems that outdoor buildings with a > scale matching the 10x10 scale would be more immersive. Despite that > though, I think it would be best to see some mockups of each scale to > get an idea of how it would feel to play with. It just seems to me that if 10x10 is chosen that there would be very few to none single space houses. I can't think of many maps that are 10x10. Another question on this could be height - if a map is multiple floors, after how many floors should the icon depict some height (I'm not thinking about basements/dungeons, but second/third/fourth floors). With the bigimage support, an object can have height without an enlarged footprint - a tower could appear to be 2 spaces high, but still only have a 1x1 footprint. > >>> - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns >>> bigger in the bigworld, but at the same time it would make the whole scale >>> more coherent i think >>> >> I think we need to be careful here - based on the map size (and past >> discussions which says 25x25 may in fact be too large), you don't want to make >> buildings too big. Otherwise, the player only ends up seeing 2-3 buildings. >> But maybe that isn't a bad thing - then at least towns could get big enough to >> start to be interesting and/or confusing. >> > Well, IMHO it could be a good thing, provided it was well done. So long > as it's just as (or more :)) visually interesting, and it doesn't impair > navigation of the city much, then it'd have the effect of making things > feel more immersive. Yes - bigger cities would be nice. Also, cities that have less empty houses would be good. While it may not be realistic for every building in town to be a map, from a gameplay perspective, it makes exploring more interesting. Also, the 'xyz is closed' is a misleading message to new players - if I saw this, I'd think 'so when does xyz open', thinking there could be time based events, etc. If bigger buildings were done, it could also make sense to add more 'blocksview' spaces to the maps - I shouldn't really be able to see the street behind the one I'm in if its full of big buildings. Individual blocksview type arches would be needed, as if you set it on a multipart building, it becomes the property of the entire building - more likely, it should be set on just the portions of the building away from the street (maybe those should also block passage also - don't know). >> I'd be wary of actually re-doing existing towns - moving apartments and other >> permanent maps about starts to get messy. However, no towns could use the new >> scale. And for some towns, a bunch of small empty houses could get replaced by >> fewer buildings that actually have stuff in them. > Well, one could target re-doing of existing towns at 2.0, we could > create true "bound-exits" where one exit refers to another's location > regardless of if they move, or thirdly there is the option of just > designing the redid town specifically so the old perm apartment exit was > to the right place. Any of those three options would fix the issue IMHO. True - if redone for 2.0, that would work fine, as we'll probably be making enough other incompatible changes that it would be a start over type of scenario. At some point, someone actually investigated doing everything in one scale - that'd certainly make the towns big, but probably too big relative to the current size of the continent. From yann.chachkoff at myrealbox.com Mon Feb 12 12:14:56 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon, 12 Feb 2007 19:14:56 +0100 Subject: [crossfire] House sizes In-Reply-To: <45CFA8ED.5090507@sonic.net> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> Message-ID: <200702121914.57272.yann.chachkoff@myrealbox.com> >What would everyone think of: >- deciding that eg one outside square translates to eg 20x20 squares inside. >There may already be such a measurement, but I'm not sure it's that formal > I see little point on forcing a definite inside:outside scale. >- doing more multisquare (4x3? 6x4?) buildings. This would mean making towns >bigger in the bigworld, but at the same time it would make the whole scale >more coherent i think I do agree. The current scale of the buildings is way too tiny to get good representations of them (I mean, a shop is no larger than four men - that's a really tiny shop :)). I guess that houses size should look from the outside maps in sync with the size of the players. Houses in the 5x5->15x15 size range do not seem too big or unrealistic to me. However, given that it would require a lot of changes in the maps and archetypes, I guess this should be a 2.0 aim, not a 1.x one. I also guess the weird footprint of some monsters/buildings would benefit to be corrected at the same time (for example, hill giants occupying 1x2 spaces, when in fact they are "tall", not "long"). From leaf at real-time.com Mon Feb 12 20:37:27 2007 From: leaf at real-time.com (Rick Tanner) Date: Mon, 12 Feb 2007 20:37:27 -0600 Subject: [crossfire] SVN Checkin - updated python based guild maps (templates) Message-ID: <45D12467.7000908@real-time.com> A user error on my part has resulted in the SVN commit for the python based guild maps templates being spread across multiple commits in Trunk. Revision 5526 contains /templates/guild/mainfloor Revision 5528 contains the updated README.txt Revision 5529 contains /templates/guild/guild_HQ and /templates/guild/secondfloor I apologize for the confusion and inconvenience. I'm working to make sure the commit to branch/1.x is "cleaner" Best regards, -------------- 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/20070212/91dd310b/attachment.pgp From mwedel at sonic.net Tue Feb 13 00:06:52 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 12 Feb 2007 22:06:52 -0800 Subject: [crossfire] House sizes In-Reply-To: <200702121914.57272.yann.chachkoff@myrealbox.com> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> Message-ID: <45D1557C.2060901@sonic.net> Yann Chachkoff wrote: >> What would everyone think of: >> - deciding that eg one outside square translates to eg 20x20 squares inside. >> There may already be such a measurement, but I'm not sure it's that formal >> > I see little point on forcing a definite inside:outside scale. Maybe it being absolute is a bit too much. But having a general rule of thumb could be a good thing - otherwise things become inconsistent in weird ways. One 2x2 house could enter into a 80x80 building, where a 3x3 house enters into a 40x40 - that type of thing. And at some level, these relations can also be odd - some of the house maps including the surround garden/landscaping, where as some others put you directly into the house. > >> - doing more multisquare (4x3? 6x4?) buildings. This would mean making towns >> bigger in the bigworld, but at the same time it would make the whole scale >> more coherent i think > I do agree. The current scale of the buildings is way too tiny to get good > representations of them (I mean, a shop is no larger than four men - that's a > really tiny shop :)). > > I guess that houses size should look from the outside maps in sync with the > size of the players. Houses in the 5x5->15x15 size range do not seem too big > or unrealistic to me. However, given that it would require a lot of changes > in the maps and archetypes, I guess this should be a 2.0 aim, not a 1.x one. At some level, it has to be assumed that the outside scale isn't completely uniform - a player isn't as high as the town walls, etc. Instead, I think we need to recognize that there are different scales about. Lots of objects in the game don't quite meet correct scale either (that bottle of wine is one _big_ bottle), but rather the scale is consistent within the object types themselves. If we wanted to fix all the scales, we could probably do that, but would probably be a major undertaking, as for a starting point, I think you'd need to make most players 2x2 or so to keep in scale with the objects they deal with (swords, gems, bottles, potions, etc). Shrinking those items to be correct scale I think would make them too small to be distinguishable on the map. But that also starts to get into another discussion - one which we could have, but something I think we'd probably be looking at more for the 3.0 timeframe. So back to houses/buildings - I think it becomes more important that they become consistent with each other (a 3x3 building is bigger inside than 2x2, which is bigger than a 1x2, etc). While a 1x1 building is odd in size relative to the players, it is no more odd than the other scale issues with other objects. Also, there is some limit on how big multipart images can be - I'd have to look at the map protocol, but I think right now it is somewhere in the 6-8 space range. This could be fixed in various ways. > > I also guess the weird footprint of some monsters/buildings would benefit to > be corrected at the same time (for example, hill giants occupying 1x2 spaces, > when in fact they are "tall", not "long"). Yes - that should be fixed. There really shouldn't be any monsters with a rectangular footprint, as it doesn't make sense - at least for height. For some it does perhaps make sense, like wyverns and the red dragons. This is because they are rectangular creates. In theory, they should be able to rotate, so that they are either 1x2 or 2x1 - I think that is doable, but requires some amount of coding and archetype work. In comparison, fixing 'tall' monsters is just archetype changes. Those changes should only happen in the 2.0 trunk, not the 1.x, but as far as I see, could happen anytime (in fact, at some level, the sooner the better as it then lets us find problems earlier). I suppose that is true for everything 'the sooner the better', but there is the issue of finding time to do so. OTOH, this is one of those things that doesn't require programming experience to fix. From aaron at baugher.biz Tue Feb 13 10:51:28 2007 From: aaron at baugher.biz (Aaron Baugher) Date: Tue, 13 Feb 2007 10:51:28 -0600 Subject: [crossfire] House sizes In-Reply-To: <45D1557C.2060901@sonic.net> (Mark Wedel's message of "Mon, 12 Feb 2007 22:06:52 -0800") References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> Message-ID: <86ejouhugf.fsf@bannor.baugher.biz> Mark Wedel writes: > Maybe it being absolute is a bit too much. But having a general > rule of thumb could be a good thing - otherwise things become > inconsistent in weird ways. One 2x2 house could enter into a 80x80 > building, where a 3x3 house enters into a 40x40 - that type of > thing. I like the idea mentioned earlier of trying to keep them within a range. The ranges could even overlap somewhat. Say a house one block wide on the outside could be 1-15 tiles wide on the inside, while a two-block-wide house image could be 10-25 inside, a 3-block house 20-35, and so on. (Or some other set of ranges that fit better with the current buildings.) The bigger the building is on the outside, the bigger it would *tend* to be on the inside, but map designers would still have room for creativity. If for some reason you want a larger map inside your small building, give it a huge basement. :-) > Also, there is some limit on how big multipart images can be - I'd > have to look at the map protocol, but I think right now it is > somewhere in the 6-8 space range. This could be fixed in various > ways. I don't know if there's a limit on tile size, but there's a 10000-byte limit on images sent to the server in MAX_IMAGE_SIZE. If you raise that, you soon run into MAXSOCKSENDBUF, which is currently 12239 bytes. (I discovered those when I converted the Demon_Lord into a single image and it was considerably larger than that before compression.) I was able to compress Demon_Lord, which is a 4x8 image, to 7841 bytes, but it only has two colors, so I'm guessing a more colorful image would be larger. In any case, I'm sure those limits could be raised, but it's something to consider. Also, do many players still play on an 11x11 map view? Buildings that are 5x5 or so would make that map feel *very* crowded. Maybe we could assume that by 2.0, all the clients would be capable of displaying a larger area than that? -- Aaron -- http://aaron.baugher.biz/ From alex_sch at telus.net Tue Feb 13 23:46:58 2007 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 13 Feb 2007 22:46:58 -0700 Subject: [crossfire] House sizes In-Reply-To: <86ejouhugf.fsf@bannor.baugher.biz> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> <86ejouhugf.fsf@bannor.baugher.biz> Message-ID: <45D2A252.8050909@telus.net> Aaron Baugher wrote: > I like the idea mentioned earlier of trying to keep them within a > range. The ranges could even overlap somewhat. Say a house one block > wide on the outside could be 1-15 tiles wide on the inside, while a > two-block-wide house image could be 10-25 inside, a 3-block house > 20-35, and so on. > As a brief note, I'd be inclined to say the recommended size should start greater than 1. Unless of course we have a 1 tile house outside, where the house takes much less than the full tile image ;) >> Also, there is some limit on how big multipart images can be - I'd >> have to look at the map protocol, but I think right now it is >> somewhere in the 6-8 space range. This could be fixed in various >> ways. >> > > I don't know if there's a limit on tile size, but there's a 10000-byte > limit on images sent to the server in MAX_IMAGE_SIZE. If you raise > that, you soon run into MAXSOCKSENDBUF, which is currently 12239 > bytes. (I discovered those when I converted the Demon_Lord into a > single image and it was considerably larger than that before > compression.) I was able to compress Demon_Lord, which is a 4x8 > image, to 7841 bytes, but it only has two colors, so I'm guessing a > more colorful image would be larger. > I'm thinking, that for 2.0 it may be desirable to use a separate port for media (images anyway) transfer, and perhaps we could even consider http for that part (though I'd say that if we wanted to use http, we'd want to optimize things by using cgi and GET parameters, or perhaps a micro-http-server specialized for serving cf images via http (after all, non-standard-complient http can be very simple ;P)) > Also, do many players still play on an 11x11 map view? Buildings that > are 5x5 or so would make that map feel *very* crowded. Maybe we could > assume that by 2.0, all the clients would be capable of displaying a > larger area than that? Well, so far as I can tell, I'd estimate around half of active users use gcfclient2, and a majority of the others using gcfclient, meaning a significant portion of the users are on a map view probably not bigger than 15x15, which is the biggest I can usably get the gcfclient view at 1280x1024 resolution. I believe though, that for 2.0, we should consider depreciating, if not removing, gcfclient and the x11 client. Also, Gros/Lauwenmark apparently has a major update to jxclient just about ready, which looks to me like it could be promising to eventually become a prominent, if not the most prominent, client in my opinion. I believe that for 2.0 we should be able to assume that the client should be able to display at least 15x15 or so, at any resolution that client intends to support, but beyond that we should try to keep our options open for 2.0 clients for now I'd say. Another thought is, do we want to toss the 'classic' tileset? On that same note, would it be worth just plain removing tileset support in order to simplify things? Alex Schultz From mwedel at sonic.net Tue Feb 13 23:49:06 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 13 Feb 2007 21:49:06 -0800 Subject: [crossfire] House sizes In-Reply-To: <86ejouhugf.fsf@bannor.baugher.biz> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> <86ejouhugf.fsf@bannor.baugher.biz> Message-ID: <45D2A2D2.2030001@sonic.net> Aaron Baugher wrote: > Mark Wedel writes: >> Also, there is some limit on how big multipart images can be - I'd >> have to look at the map protocol, but I think right now it is >> somewhere in the 6-8 space range. This could be fixed in various >> ways. > > I don't know if there's a limit on tile size, but there's a 10000-byte > limit on images sent to the server in MAX_IMAGE_SIZE. If you raise > that, you soon run into MAXSOCKSENDBUF, which is currently 12239 > bytes. (I discovered those when I converted the Demon_Lord into a > single image and it was considerably larger than that before > compression.) I was able to compress Demon_Lord, which is a 4x8 > image, to 7841 bytes, but it only has two colors, so I'm guessing a > more colorful image would be larger. There are certainly different things that could be done. One would be to have a separate server/process that serves the data file - that could be desirable for other reasons. I'd probably also be good to really force caching to be the standard also. But this is also a different discussion. > Also, do many players still play on an 11x11 map view? Buildings that > are 5x5 or so would make that map feel *very* crowded. Maybe we could > assume that by 2.0, all the clients would be capable of displaying a > larger area than that? I don't know how many play on 11x11 (could look at the logs and figure it out). However, one discussion was to have the map size be closer to 19x19 and not the max of 25x25 it is now. 19x19 is still good size, but start put down houses that are 5 spaces big, you may not see a whole bunch. This could also lead to other areas - the town walls should appear higher, trees perhaps bigger, etc. From alex_sch at telus.net Wed Feb 14 00:15:06 2007 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 13 Feb 2007 23:15:06 -0700 Subject: [crossfire] House sizes In-Reply-To: <45D2A2D2.2030001@sonic.net> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> <86ejouhugf.fsf@bannor.baugher.biz> <45D2A2D2.2030001@sonic.net> Message-ID: <45D2A8EA.9040500@telus.net> Mark Wedel wrote: > Aaron Baugher wrote: > >> Also, do many players still play on an 11x11 map view? Buildings that >> are 5x5 or so would make that map feel *very* crowded. Maybe we could >> assume that by 2.0, all the clients would be capable of displaying a >> larger area than that? >> > > I don't know how many play on 11x11 (could look at the logs and figure it > out). However, one discussion was to have the map size be closer to 19x19 and > not the max of 25x25 it is now. 19x19 is still good size, but start put down > houses that are 5 spaces big, you may not see a whole bunch. > I don't really think it would be a problem, not seeing a whole bunch on an outdoor map, provided that the town was still easily navigable. Actually, I believe that larger buildings would make the buildings more visually distinct at quicker glances, and thus would improve navigability, counteracting the negative effects of only seeing a smaller area. In addition, perhaps a little fog-of-war-minimap overlaid in the client or something along those lines could work nicely with it, but I certainly don't think that'd be necessary for that scale to work. > This could also lead to other areas - the town walls should appear higher, > trees perhaps bigger, etc. Hm, nice idea there. That would also fit well with the things about things visual height differing from the area they take on the ground. Alex Schultz From yann.chachkoff at myrealbox.com Wed Feb 14 11:43:30 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed, 14 Feb 2007 18:43:30 +0100 Subject: [crossfire] House sizes Message-ID: <1171475010.c7f51a7cyann.chachkoff@myrealbox.com> > Maybe it being absolute is a bit too much. But having a general rule of thumb could be a good thing Yes, I agree with that. > At some level, it has to be assumed that the outside scale isn't completely uniform - a player isn't as high as the town walls, etc. Instead, I think we need to recognize that there are different scales about. What annoys me with such scaling - for buildings, I'm not speaking of objects the size of a bottle or a sword - is that it prevents abstracting the visual representation of the game from its logical one. So, although generating a 3D view (or a 2D isometric one, or any other view than the top-down 2D view) from the data grid sent by the server would technically be not too hard, those scaling issues make the result rather ridiculous :). I'm also worried by the risk of wasted work: who can tell we wouldn't need to change scales again in the future ? > If we wanted to fix all the scales, we could probably do that, but would probably be a major undertaking, >(...) >But that also starts to get into another discussion - one which we could have, but something I think we'd probably be looking at more for the 3.0 timeframe. I tend to think that it is better to handle the whole scaling issue at once, instead of taking the transitional route - rescaling buildings alone would already mean a lot of work, both graphically and 'mapically'. Fixing all the scales later would probably mean fixing buildings again, and thus difficult work on the GFX would have been wasted (it isn't as if we had a lot of graphists... :)). > I suppose that is true for everything 'the sooner the better', but there is the issue of finding time to do so. OTOH, this is one of those things that doesn't require programming experience to fix. Yeah - maybe that's the biggest problem - it is easier to code a monster than to draw it :). I guess that we could proceed by not changing any of the current maps, but building a parallel set of renewed ones (maybe linked to the old ones in a way or another, so that they can be tested by players ?). So that could be a change not arbitrarily fixed for a given release, but something that could replace the old maps "once it is ready". From aaron at baugher.biz Wed Feb 14 18:26:53 2007 From: aaron at baugher.biz (Aaron Baugher) Date: Wed, 14 Feb 2007 18:26:53 -0600 Subject: [crossfire] House sizes In-Reply-To: <45D2A252.8050909@telus.net> (Alex Schultz's message of "Tue, 13 Feb 2007 22:46:58 -0700") References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> <86ejouhugf.fsf@bannor.baugher.biz> <45D2A252.8050909@telus.net> Message-ID: <867iukgt9u.fsf@bannor.baugher.biz> Alex Schultz writes: > I'm thinking, that for 2.0 it may be desirable to use a separate > port for media (images anyway) transfer, and perhaps we could even > consider http for that part (though I'd say that if we wanted to use > http, we'd want to optimize things by using cgi and GET parameters, > or perhaps a micro-http-server specialized for serving cf images via > http (after all, non-standard-complient http can be very simple ;P)) If all it needs to do is serve images, publicfile is extremely lightweight and fast and could do that fine. Or as you say, it'd be easy enough to roll something new with as little overhead as possible. > Another thought is, do we want to toss the 'classic' tileset? On that > same note, would it be worth just plain removing tileset support in > order to simplify things? I'm working on a script to convert all the tiled images to combined images. (I probably would have them all done by now if I'd just done them manually and forgotten the script. :-)) Once I'm done with that, there won't be any more tiled images to support, unless someone does new ones, and that could be deprecated -- just require that all new images must be full images. It seems like a waste to throw away all those classic images, but I guess they wouldn't be gone, just out of the distribution. Maybe some could be re-used for other archetypes. -- Aaron -- http://aaron.baugher.biz/ From mwedel at sonic.net Wed Feb 14 23:58:12 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Feb 2007 21:58:12 -0800 Subject: [crossfire] House sizes In-Reply-To: <45D2A252.8050909@telus.net> References: <200702102342.03415.nicolas.weeger@laposte.net> <45CECCA3.4060007@telus.net> <45CFA8ED.5090507@sonic.net> <200702121914.57272.yann.chachkoff@myrealbox.com> <45D1557C.2060901@sonic.net> <86ejouhugf.fsf@bannor.baugher.biz> <45D2A252.8050909@telus.net> Message-ID: <45D3F674.3000107@sonic.net> Alex Schultz wrote: >> I don't know if there's a limit on tile size, but there's a 10000-byte >> limit on images sent to the server in MAX_IMAGE_SIZE. If you raise >> that, you soon run into MAXSOCKSENDBUF, which is currently 12239 >> bytes. (I discovered those when I converted the Demon_Lord into a >> single image and it was considerably larger than that before >> compression.) I was able to compress Demon_Lord, which is a 4x8 >> image, to 7841 bytes, but it only has two colors, so I'm guessing a >> more colorful image would be larger. >> > I'm thinking, that for 2.0 it may be desirable to use a separate port > for media (images anyway) transfer, and perhaps we could even consider > http for that part (though I'd say that if we wanted to use http, we'd > want to optimize things by using cgi and GET parameters, or perhaps a > micro-http-server specialized for serving cf images via http (after all, > non-standard-complient http can be very simple ;P)) This is getting a bit off topic, but if a separate media server is done, there isn't really any reason that multiple protocols couldn't be supported (eg, http, ftp, whatever). I'd personally think that we shouldn't rebuild the universe for that - instead, we should leverage existing technologies/programs (ftp & web servers, perhaps others if there are light weight servers). I'm pretty sure there are some pretty light weight web servers out there if you don't want a big list of features. What I'd envision is something like this: Client connects to the server. The server (upon request) provides a list of servers where the media content could be downloaded. There would be some extra logic - in a sense, common media servers which hold the standard distributions, and specialized/local media servers, which are guaranteed to have all the data the local server is using (eg, if I add a custom graphic to my server, the general media server probably won't have it, but need some way for the client to get it). Most likely, the specialized one would be on the same system as the server itself. I'd need to think about this more, but I'd also like to have some way of versioning the data so that instead of the client having to query for all the media files the server is currently using, the client could do something like 'I have version 46 of the server media files. The server is now up to revision 52, so I need to download mediapaks 47-52 and be updated' And perhaps for efficiency reasons, the server makes jumbo packs every so often (so that if you don't play for 3 months and come back, it can upload jumbopak.60, jumbopak.70, and paks.71-73 type of thing). I think the way for this to work would be to change the collect logic - instead of the entire bmaps files getting rewritten each time, the file gets appended but isn't in order (it could be sorted internally by the server). So in a simple case, you connect to the server - its highest image is 5146. That matches what you have. Next time you play, its highest image is 5180, so there is those 34 images to download. Another advantage of this is that if the clients stores the number->image mapping for the first 5146, in practice they should never change, so it saves some bandwidth. If an image disappears, then there is just a whole in the bmaps file (or maybe some special tag is used, like none). Periodically, a completely rebuild would be needed, as I recall there are maximum image numbers, and if rebuilds didn't happen, we'd eventually overflow that (I think it is only 16 bits, so 65535 - that sounds like a lot, but if you only take into account that images get added, never removed, things would get out of date). > I believe though, that for 2.0, we should consider depreciating, if not > removing, gcfclient and the x11 client. Yes - it'd probably be nice to do that sooner, simply so as other changes happen, those don't have to get updated. > Another thought is, do we want to toss the 'classic' tileset? On that > same note, would it be worth just plain removing tileset support in > order to simplify things? There probably isn't much reason to remove the classic tileset right now - it isn't harmful. And IMO, the tileset support is useful in other ways. There have been discussions on IRC about a larger image tileset (64x64) - the multiple tileset that the server has makes it so this could be done right now without any server changes - you'd just need to create all those new images. The client would need support to know about this larger tileset. Or likewise, if someone really wanted and isomorphic view, they could make such a tileset (or more likely, grab the one from daimonin) From mwedel at sonic.net Thu Feb 15 00:16:06 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Feb 2007 22:16:06 -0800 Subject: [crossfire] House sizes In-Reply-To: <1171475010.c7f51a7cyann.chachkoff@myrealbox.com> References: <1171475010.c7f51a7cyann.chachkoff@myrealbox.com> Message-ID: <45D3FAA6.9080100@sonic.net> Yann Chachkoff wrote: >> At some level, it has to be assumed that the outside scale isn't completely >> uniform - a player isn't as high as the town walls, etc. Instead, I think >> we need to recognize that there are different scales about. > > What annoys me with such scaling - for buildings, I'm not speaking of objects > the size of a bottle or a sword - is that it prevents abstracting the visual > representation of the game from its logical one. So, although generating a 3D > view (or a 2D isometric one, or any other view than the top-down 2D view) > from the data grid sent by the server would technically be not too hard, > those scaling issues make the result rather ridiculous :). I'm also worried > by the risk of wasted work: who can tell we wouldn't need to change scales > again in the future ? I agree - we should only do this once. From what I recall, your thought is that there should still be two scales, just that scale of the buildings should be larger than being proposed elsewhere? The scales of crossfire always get weird. If relative to the player size, each square, either indoor or outdoor, is somewhere between 5 and 10' (a player takes up most of a space, etc). Lets presume that indoor is on the smaller size, and outdoor on the larger size. In that case, a building that is 40'x40' should be 4x4 spaces - probably not that unreasonable as I think about it (a 40x40 building is a good size building). Where things get complicated are the real big buildings - that castle that should 200'x200' now needs a 20x20 image - that is one big image for someone to draw. And at some level, you start to get the question - should there be such a large monolithic object, or should it be made up of multiple objects. You almost start to get to the point of maybe there should just be 1 scale at some point. So other than me rambling a bit, I guess the point to some extent is that scale will never really match actual player size quite right - there will always have to be some level of 'this building image isn't really as big as it should be'. > >> If we wanted to fix all the scales, we could probably do that, but would >> probably be a major undertaking, (...) But that also starts to get into >> another discussion - one which we could have, but something I think we'd >> probably be looking at more for the 3.0 timeframe. > > I tend to think that it is better to handle the whole scaling issue at once, > instead of taking the transitional route - rescaling buildings alone would > already mean a lot of work, both graphically and 'mapically'. Fixing all the > scales later would probably mean fixing buildings again, and thus difficult > work on the GFX would have been wasted (it isn't as if we had a lot of > graphists... :)). True - we should only fix this once. But we should also come up with a fix that can be reasonably done. If I had infinite time & resources, I can think of lots of things I'd like to do. But I don't, so I have to keep things more modest in many areas. However, a discussion on what should be the right approach is really the right thing to do, so I'm glad for this to continue. As I think about, I'm almost more fond of a single scale system - that is a huge amount of work, but fixes all the scale issues. > I guess that we could proceed by not changing any of the current maps, but > building a parallel set of renewed ones (maybe linked to the old ones in a > way or another, so that they can be tested by players ?). So that could be a > change not arbitrarily fixed for a given release, but something that could > replace the old maps "once it is ready". Yes, but my experience is that parallel releases/development is hard to do - the process of keeping things up to date becomes a pain, unless it is done enough for people to use it, you don't get feedback, etc. OTOH, SVN makes merging a lot easier than with CVS, so keeping branches up to date would be easier. One thing on my wishlist would be basic macro/preprocessing support in maps. Then you could have something like a 'map_config' file like: #define SCORN_PASSWORD rope #define BIG_MAP_SUPPORT And then in the map files, something like: @say The gate password is SCORN_PASSWORD and #ifdef BIG_MAP_SUPPORT slaying /my/big/map hp 8 sp 14 #else slaying /normal/map hp 25 sp 4 #endif Type of things - then you'd have one mapset. If you extend this, you could have nested #includes, stuff like: scorn_region: #include "global_map_defs" #define ... #define .... And so on, where the defines could perhaps be local messages for the regions, etc. > > > > _______________________________________________ crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Thu Feb 15 01:42:41 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Feb 2007 23:42:41 -0800 Subject: [crossfire] plugin crash on metalforge. Message-ID: <45D40EF1.1030604@sonic.net> Looking at some of the crashes on metalforge, which is latest 1.x as of a week ago. Saw 2 crashes wit the same cause. From the logfile: [Debug] ********** EVENT HANDLER ********** [Debug] - Who am I :Moneygoose [Debug] - Activator :reaper [Debug] - Event code :1 [Debug] - Event plugin :Python [Debug] - Event hook :/python/casino/platinumslots.py [Debug] - Event options :event_apply /home/crossfire/share/crossfire/maps/python/CFItemBroker.py:23: DeprecationWarning: integer argument expected, got float self.object.Quantity=tmp [Debug] ********** EVENT HANDLER ********** [Debug] - Who am I :event_destroy [Debug] - Event code :13 [Debug] - Event plugin :Python [Debug] - Event hook :cfpython_auto_hook [Debug] - Event options :event_destroy [Error] Trying to remove removed object. arch event_destroy name event_destroy name_pl event_destroy title Python slaying cfpython_auto_hook nrof 53 type 116 subtype 13 end the offending code is Crossfire_Player_dealloc() in plugins/cfpython/cfpython_object.c: static void Crossfire_Player_dealloc(PyObject *obj) { Crossfire_Player *self; self = (Crossfire_Player *)obj; if(self) { if (self->obj && self->valid) { free_object_assoc(self->obj); if (self->del_event) { cf_object_remove(self->del_event); cf_free_object(self->del_event); } } self->ob_type->tp_free(obj); } } In this particular case, self->obj == self->del_event, which is why I think this may be getting freed twice, but not 100% sure of that. Can someone with more plugin exp look at this? From nicolas.weeger at laposte.net Thu Feb 15 13:44:55 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 15 Feb 2007 20:44:55 +0100 Subject: [crossfire] plugin crash on metalforge. In-Reply-To: <45D40EF1.1030604@sonic.net> References: <45D40EF1.1030604@sonic.net> Message-ID: <200702152044.55203.nicolas.weeger@laposte.net> Le jeudi 15 f?vrier 2007 08:42, Mark Wedel a ?crit?: > Looking at some of the crashes on metalforge, which is latest 1.x as of a > week ago. Saw 2 crashes wit the same cause. From the logfile: Ok, that was a fun bug :) Chain of events: * you gain at the slot machine * slot machine creates platinum coin * slot machine puts coin in map * slot machine adjusts object count and such But the fun part is that the slot machine is an altar eating platinum coins. So when the coins are put on the map, the altar just eats them. There, the Python plugin just kept a pointer to removed object, so you had weird issues later on :) (especially with object reuse). I fixed by correctly getting object returned by cf_map_insert_object :) Now to fix the Python script itself, since now you don't get any money^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Feb 18 09:29:37 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 18 Feb 2007 16:29:37 +0100 Subject: [crossfire] Feature request 1025952: GTK Client - Save Pickup options. Message-ID: <200702181629.37220.nicolas.weeger@laposte.net> Hello. I just implemented feature request 1025952: GTK Client - Save Pickup options details at https://sourceforge.net/support/tracker.php?aid=1025952 I added stubs ("client_pickup") for x11 and gtk2 client, but only wrote the logic for "old" gtk client. I guess it could be implemented for gtk2 at some point, and the feature request closed :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Mon Feb 19 17:18:15 2007 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 19 Feb 2007 16:18:15 -0700 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5575] server/trunk In-Reply-To: References: Message-ID: <45DA3037.1030607@telus.net> Crossfire CVS repository messages. wrote: > Revision: 5575 > http://svn.sourceforge.net/crossfire/?rev=5575&view=rev > Author: qal21 > Date: 2007-02-19 15:03:04 -0800 (Mon, 19 Feb 2007) > > Log Message: > ----------- > Change move_arrow calls to ob_process. As a quick note, I accidentally forgot to add other parts to the commit message, see the ChangeLog message: Rebuild prototypes. include/{sproto.h, typesproto.h} --- Move arrow and thrown object code into types/ server/time.c, types/{arrow/arrow.c, thrown_object/thrown_object.c, common/projectiles.c, legacy/process.c} --- Change move_arrow calls to ob_process. server/{player.c, skills.c} Alex Schultz 2007-02-19