Re: [crossfire] Removing server-side help files for client-side commands
Preston Crow wrote: > I think we need to be sure that the clients are offering help on the > local commands before we remove that help from the server. JXClient has been updated accordingly. > I think what needs to happen is to have the client intercept the > 'help' command, display the client-side commands, then send the > command to the server for the server-side commands. If asking for > help on a specific command, the client would only pass it on to the > server if the command didn't match a local command. JXClient now implements this suggestion: it intercepts the help command, then prints a local help and/or sends the help command to the server. > But we still have the problem of people using older clients with newer > servers. I would not worry too much about this issue: A missing help file for some commands is not a big issue. The server does not even provide help for all defined commands. Also, we do not have too many players and I'm not sure how many of these actually use the help command. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Questions about archetype files
Bob Tanner wrote: > Object altar_valkyrie > name Altar of Valkyrie > other_arch Valkyrie > type 56 > face altarvalk.111 > no_pick 1 > level 100 > arch altar_valkyrie_pray_event > end <— ends Object altar_valkyrie This line ends "arch altar_valkyrie_pray_event". This allows to customize the inventory object. Or one could even create recursive inventories by nesting "arch xyz...end" blocks. > end <— What does this end? This line ends "Object altar_valkyrie". ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Magic map colors and related changes necessary for client and server
Mark Wedel wrote: Almost certainly what is happening is the client is getting a color value that it assumes is valid, and is looking up values beyond what are in fact valid. The Java client is more intelligent and does bound checking or the like. The right solution for the client in these cases is that if it does get a value out of bounds, it should just use a default. This is exactly what is happening: all of x11/gtk/gtk-v2 either allocate an array having 13 elements or allocate 16 elements but do not initialize more than 13 elements. The access is a color index 0..15 (without bounds checking). Jxclient allocates a 16 element array, fills the undefined entries with dark gray as a default, then uses an index 0..15 for access. If more colors are desired, that is more work to do, as the NDI type values would need to get extended. IMO, those NDI values will eventually go away (the messages have been changed to send the type of message, and the client can then look up how that type of message should be displayed). I'm still tempted for magic map to just send more data so fill in fog of war or other details on the map - in that case, the magicmap values would completely go away. I vote for this solution -- do not improve the existing magicmap color table but send actual face information in magicmap responses. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
Hi, I am one of the founders of Gridarta and I still maintain the editor. So expect my viewpoint to be slightly biased ;) I already mentioned on IRC some of the reasons why I think that this editor [gce] is interesting: it is fast (e.g., drawing walls or other features on a large map is much faster than with gridarta) It is known that Gridarta is quite slow on huge maps. The main reason is a less-than-optimal implementation of the undo stack. Fixing this would need a fair amount of work without having much effect for real maps: Crossfire maps generally should not grow too large; instead tiled maps should be used. Therefore I (still) consider fixing this issue a waste of time since more important features are pending. Besides that, my observation with gce was just the opposite: I did create a map with gce's default size (20x20 tiles). I hardly could edit this map because gce's display updates were sluggish at best: just moving around the mouse cleared the map view when the tooltip moved. I had to stop doing anything (including mouse movements) and wait 3-5(!) seconds until the map view was repainted and I could continue. The test was on the exact same machine that I use for Gridarta development and testing; gce is the version available for download on the Deliantra web site. , it has a nice way to display the properties of all map objects as you move the mouse around Yes, this is a nice feature; I plan to add a similar one to Gridarta. , it has less installation dependencies than gridarta I just can agree with Yann here that this is not correct. Gridarta needs only Java 1.6; no other external libraries are needed. Building from source additionally needs ant. According to the download web site gce needs at least Perl, libgtk2, and libglib2. For the implicit free software meaning: OpenJDK is about to go into Linux distributions. Therefore it is not (anymore) an argument for me. Also, the argument (as stated in another mail in this thread) that map makers may want to use Debian stable, is not an argument: the gce download page states that libglib2.0-0 version 2.12.6-2 is needed; Debian stable has 2.12.4-2 only. Windows users can also use OpenJDK (I guess), or just download and install Sun's JRE to run Gridarta. Not sure how easy it is to get Perl (and GTK2) installed on a Windows machine. FYI: gcj fails to compile Gridarta because gcj does not comply to the Java Language Specification (apart for other issues in the class libraries). I filed a bug report more than four months ago [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410]. It is still in state NEW. , etc. See below for a list of missing features. SCNR ;) However, the current version also has some drawbacks: [...] All these drawbacks are just technical issues that can be fixed. Therefore these issues are not really arguments against the editor (for me). (Without actually having guessed how much work is needed to get them fixed.) If there are no objections against this plan, I would like to import the code in SVN as soon as possible. Given that Gridarta is still in active development (more than 4000 commits since the project start about two years ago), and having invested much time (I did more than half of all commits), I do object. My main reasons are: - We (Crossfire) do not have that many (active) developers. Therefore splitting these few into the maintainance of multiple helper-applications that basically do the same seems just a waste to me. We should rather focus on the game itself. With game I mean: in-game content, a decent client (which runs on Windows, Linux, and hopefully on Macs), and a stable server [roughly in this order], but definitely not the maintainance of redundant helper-applications. Also, the main reason why we (Christian Hujer, Daniel Viegas (both Daimonin developers), and me) did start the Gridarta project was to fight resource splitting: at that time there have been two projects, Crossfire and Daimonin (I'm ignoring Angelion because it did use the unmodified Daimonin editor). Both projects did use and maintain similar editors. Our idea was to join the developers of both projects to get more development power. The intended outcome is a (mostly) unified editor which shares most of the basic functionality but has special features needed by either project. For Crossfire this merge process already did pay off since I could take over many features from Daimonin to Crossfire. Besides that I got quite some (constructive) feedback from Daimonin map makers. That said, I think starting a new editor would basically mean to split off Crossfire from Gridarta: having an editor part of the project (IMO) declares it as the official Crossfire editor. Which in turn means we (the Crossfire developers) are at the same state as two years ago: two editors to maintain (crossedit+CFJavaEditor vs. gce+Gridarta) with just a hand-full of developers. - Gridarta
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [8406] client/trunk/gtk-v2/src/config.c
Crossfire CVS repository messages. wrote:
Revision: 8406
http://crossfire.svn.sourceforge.net/crossfire/?rev=8406view=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.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] jxclient
Yann Chachkoff wrote: Le dimanche 5 août 2007, Kevin R. Bulgrien a écrit : Using run.sh, I get... disappointingly... Warning ! True full-screen support is not available. The system is a dual core pentium d (3.6 GHz) x86_64 with 3 Gb RAM. The graphics card is a NVIDIA 7600 GT running a true nvidia driver compiled on this machine. snip True full-screen support and hardware acceleration should indeed be available on a platform similar to yours. The client basically relies on the JDK to detect if fullscreen is available or not for the given screen resolution. I have get same problem now: at one time I got full-screen mode, but currently I cannot get it working anymore. I'm not aware that I did change anything of my X11 setup. It might be a software bug, but reading the source I get no idea what might be incorrect. Indeed, if the Java2D software renderer is used instead of the hardware-accelerated one, the client will be rather slow. This is because it has to redraw its whole GUI, which is a costly operation. I'm not sure this can really be improved. I think the client is slow without hardware acceleration because it uses transparent images for most GUI elements: if I make the client pretend that all images are opaque, the client runs very fast. That said, my plans to improve the speed are a) to minimize the number and sizes of transparent images in the GUI, and b) to redraw only the screen parts that actually have changed. I have an idea how to make it work with double buffering. So far I have not had it crash. I've played a bit with it, though at 1280x1024 it is only using about 1024x800 or so for the display, so I need a magnifying glass to see in game text and inventory and the little buttons. It's odd because the map graphics are in your face big compared to how I run the GTK clients. Unfortunately I only have 17 monitors on this machine. Yep - This is because the skin supplied for JXClient was made for 1024x768 resolution. If that screen mode is not available, Java will emulate it by using the next closest one, but it means you'll get (1) a tiny GUI and (2) some glitches outside the 1024x768 area. Hmmm... I did increase the font size to make it readable but not wasting too much screen space for text output. Good news is that, to some extend, jxclient is skinnable, so a lot of elements can be displayed in a different, and hopefully better, way. Gauges are indeed skinnable - the resistance ones and the HP/SP/Food/Mana ones are all using the same code, So making them clearer to see would probably be mostly a matter of changing the pictures used. Note that I believe that this interface would require more work than just changing a couple pictures, though. The screen layout now is defined by text files. To create a new skin copy the directory default.theme to (say) testskin. Modify the testskin directory contents to your taste: each *.skin file defines one screen; the files in fonts/ and pictures/ are the fonts/pictures referenced from the commands in the *.skin files. Then start the client with jxclient -jar jxclient.jar -S /path/to/testskin or jxclient -jar -jxclient.jar -S /path/to/testskin --server localhost The latter example skips the metaserver screen. To return to the default layout, start jxclient with -S default. (Currently no documentation exists yet. Also, the available commands probably will change a bit from time to time.) Wish list: Scroll wheel support. Indeed :) Not very hard to add for sure :). Noted. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK2-v2 Client new layout defined (gtk-v1)
Kevin R. Bulgrien wrote: Yeah... whatever... at least GTK clients are easily built. I'd try this so-called super awesome, non-geekified jxclient if I had a clue where to get a jar or how to build it, but maybe it is too good for the playing masses and we couldn't handle it? And for crying out loud, it doesn't even get honorable mention on the Crossfire web site. There is a simple reason it is not advertised on the web site: the client is still in development. You are able to connect to a server and actually play the game, but some gui elements do not yet work (click on an element and nothing happens), and error handling is almost absent (failure to connect to server, or have the connection break == client just exits). Also, it still runs quite slowly on machines without hardware accelerated graphics operations -- in fact, currently you basically cannot play on such machines... That said, I do not yet consider jxclient to be in a state to be released as a pre-compiled client intended to be run by normal players. Therefore I currently do neither advertise it nor provide pre-compiled binaries. I pulled down ant (87 MB with deps), and still didn't have a clue where to go from there. Thanks for pointing out this issue. I've now added a few lines to the README file about how to compile the client. Basically: run ant in the jxclient directory. This creates the file jxclient.jar. Run this file as java -jar jxclient.jar. For now, I'll stick with using a geeky client rather than none at all. Better yet: figure out how to make it work, then fix the documentation;) Or at least file a bug report so somebody else can fix it. Just declining and not telling anything does not enable us to fix issues... What's with java projects anyway? Gridarta doesn't release jars, I don't see one for jxclient. You have to get them off-project. I guess if you're not in, you're out. For Gridarta it is for the same reason: the project has started from the sources of both the Crossfire and the Daimonin Java map editors. They did share a common code base but have been developed separately for quite a while. Gridarta's goal was to merge both code bases to bundle the development resources of both projects, effectively helping both projects. We decided not to officially release binaries for Gridarta because we thought the editors might be (very) unstable during the merging process. Until today, the merging is still in progress (see http://gridarta.sourceforge.net/dev/mergeStats). To the off-site download place: It was introduced because some people couldn't compile the editor. (In fact, I did compile Gridarta for eracc. He then figured that it could be helpful for other to get at the pre-compiled editor as well, so he hade it available on his site.) As far as I know, currently all people who are (semi-)actively using the editor can compile it from the sources. Now, creating a new release takes me at least 30 minutes. Therefore I prefer spending this time into code improvements. That means I update the pre-compiled binary only very infrequently (less than once per month, almost always only when somebody complains that it is way outdated...) That said, even though we do not yet provide pre-compiled binaries for jxclient or Gridarta, feedback is always highly welcome. Both feedback about what needs to be improved/changed/implemented to make the application actually useful, and feedback about bugs/crashes/etc. Even feedback that you just use it without problems is useful (since it might accelerate further development ;)). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] On the software side of reorganizing the world
Lalo Martins wrote: What I think we need is a world editor. [...] Ideally, I'd like an UI on at least the magicmap scale, maybe farther, where I can lay mountains, rivers, forests, marshes, sea/land, and preferably copy large chunks right out of an older map (say, Lone Town) and paste into the world. Some of the features I plan to add to the editor: - Allow to shrink the map window. This affects only the map window but still allows all edit operations. I think this will help editing (untiled) maps that are (much) larger than the available screen space. - Add tiling support to map windows. That is, seamlessly display tiled map files in the map window. Though, don't expect these features to be implemented too soon since there are still a few unsolved issues. For example: loading all 900 world map files into the editor would need about 1.3GB RAM. This is way too much. OTOH, limiting the zoom feature to less then the whole world map seems not correct to me... Also control elevation by hand, using an interface similar to map editors in god games (eg, Sim City). For now, the editor mostly ignores elevation values. It tries to retain the elevation values when editing the map but I didn't add more support since I don't think elevation values are a sensible feature. (OK, I'll stop now because it's not the weather discussion...) And define things like regions right there, too. If you think the editor needs improvements, feel free to add your ideas to https://sourceforge.net/tracker/?group_id=166996atid=841185 I do not promise to implement all features, but not knowing about a feature, I cannot implement it. If someone wants to pursue that, either as a separate tool or a mode for the new editor, I'd be happy to contribute, although I don't know where to start if I were to write it myself. Generally speaking, I think almost all tools for map editing should be included into the editor. This makes it much easier for users to use them (no need to install yet another application/library/whatever and the feature is easily accessible though menus). It also makes it easier to maintain them (for the same reason). Also, the editor's code base now has reached a state to allow adding new features without breaking too much existing features. Andreas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Bug [ 1735459 ] Ground view missing face updates
Nicolas Weeger wrote: At some level, it is very easy to fix - if player is on a space, and anything (including face) on that space change, we just send all the contents of that space again to the player. Why all items? Don't items on a space get a tag, that can be used to simply send this item's update to clients? I agree: the server should remember which items and attributes he has sent to the client. (Which IMO already have to be implemented in order to make the item/upditem/delitem/delinv commands work right.) Using this information, the server is able to issue correct upditem commands for changed ground objects. Now a simple answer could be we don't really care about bandwidth, and I can put in my fix. I'm not sure if that is really the right answer. If it is really that costly, I'd say no. I think wasting bandwidth is ok if any other solution would be way too complex to implement. But in this case I think such a fix would not be the correct answer. The bug isn't important enough to warrant the fix. I somewhat disagree here: the bug is at least (slightly) confusing. For example, go into Beginners and follow the instructions of the first handle (Type an A to open). This applies the handle but the ground view does not change until you move off and on. Yes, client should handle all animation it can. Would simplify the server code, and save some bandwidth. I also agree here. Also, one should consider the case where the modified face is not visible because the map layer is full (can happen if many objects). Map layer does not apply here since it is the ground view. But still: the ground view holds only a maximum of 50 objects. But this case is implicitly handled by the previously suggested solution: the server would detect that the changed object has not been sent to the client. Therefore it would not send any updates to the client. Andreas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Materials
Nicolas Weeger wrote: Le samedi 09 juin 2007 23:49, Lalo Martins a écrit : what about... keep materialname and lib/materials, and kill the material field? Err, can't for now, Gridarta (which is hopefully the official editor doesn't handle this materialname field :) This should be no argument if it is just that one field is missing: adding (or changing or removing) a field to/from Gridarta is a simple change. That is, if you decide on which way to go, I can update the editor in no time. Andreas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire: [5296] server
Crossfire CVS repository messages. wrote:
Revision: 5296
http://svn.sourceforge.net/crossfire/?rev=5296view=rev
Author: qal21
Date: 2007-01-04 00:53:58 -0800 (Thu, 04 Jan 2007)
Log Message:
---
Apply patch #1627442 by Aaron Baugher, to fix bug #1551735. Works by using a
key_value of divine_giver_name to objects that are given by a god.
[...]
Modified: server/trunk/server/gods.c
===
--- server/trunk/server/gods.c2007-01-03 21:03:42 UTC (rev 5295)
+++ server/trunk/server/gods.c2007-01-04 08:53:58 UTC (rev 5296)
@@ -207,6 +207,57 @@
}
/**
+ * follower_remove_given_items()
I wonder if it is correct to include the function name here -- wouldn't
it be used as the function (brief) description in the Doxygen output?
[...]
+ * @param pl
+ * the player object
+ *
+ * @param op
+ * the object to be searched for items
The implementation allows for NULL pl or op parameters, so this IMO
should be documented (or preferably not checked at all if passing NULL
values is not intended).
[...]
+for (tmp = op-inv; tmp != NULL; tmp = next) {
+next = tmp-below; /* backup in case we remove tmp */
+
+const char* given_by = get_ob_key_value(tmp,
divine_giver_name);
Declaring a variable intermixed with statements is not allowed in Ansi C89
(which is to my understanding what the server code should be).
+if(given_by == god-name){
This probably will not work: when loading from a file, I think the stored
values will not be shared strings. I.e., this check probably will work until
the player logs out. But after re-login it may fail.
[...]
+free_object(tmp); /* free object */
IMO this is a useless comment and should be removed: the comment does not
contain additional information to what the code says.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas needed to fix exploit
It seems to me that the consensus is to base the exp gain of the attacker on the exp loss of the victim. The amount should be settable in the config file. A possible transferral of exp between skills is not considered a problem. That said, I think I'll add a new setting pk_exp_ratio which takes a value between 0 (no exp gain for pk) and 100 (attacker gains all exp the victim loses) with a default of 50. The current code limits the exp gain to 5 million. Should I keep this limit, or add just another settings variable (pk_exp_limit, defaults to 5 million)? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas needed to fix exploit
Mark Wedel wrote: Andreas Kirschbaum wrote: b) Reward a (pk) with MIN(5 million, (exp loss of victim)/10). I'm not sure if that really is a good idea since it probably creates another exploit: kill a player with some hard to train skill and gain lots of exp in that skill. I'm not sure I follow that logic - it doesn't seem to be any worse than now. If I can (hypothetically) kill someone with bad singing, that change above doesn't make things any easier or harder. I won't get any more exp than I did before that change, and will likely get less. If the player being killed is down to having only permanent exp left (thus doesn't lose anything), I gain no exp. The problem I see is that the current code calls calc_skill_exp() which probably returns a quite different value than the exp loss of the victim. Thus it may be possible to find a hard to train skill (which gives very few exp from calc_skill_exp()) which now gives lots of exp due to a huge exp loss of the victim. That said, the exploit would be to train a throw-away character with easily trainable skills, then kill it with the real character and with a hard to train skill. The result is that the real character gains lots of exp in the otherwise hard to train skill. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Ideas needed to fix exploit
Mike Wendell wrote: Why not just allow the experience as a one time deal? After they kill that one other player one time, they don't get any more experience from them doing it again? When do you want to reset this flag? If it is reset after a fixed time period, how does a player know when he would gain exp again? If it is reset after some exp gain, it probably can be easily circumvented. Or does it never reset, and the victim and/or attacker accumulates pk-forces? (Which probably could be interesting for DMs to be able to check the pk-history of a player...) Note that using only one force (last victim killed) is not sufficient: just kill two victims in turn. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [patch] fix inconstency between on_same_map and get_rangevector
Pippijn van Steenhoven wrote: while working on a script that would move an NPC, one bug was found in common/map.c. A diff is supplied at the following URL: http://data.plan9.de/adjacent.txt Basically, it's get_nearest_player which calls can_detect_enemy which then calls on_same_map and if that returns yes, it returns random crap. Thanks for the bugfix; I did apply the (modified) patch. Please add future patches to the Sourceforge tracker since patches sent to the mailing list have a high chance to be missed. Patches added to the tracker stay there until somebody looks at them. Some notes about the patch: - Please try to follow Ansi C (C89). This especially means that // comments are not acceptable. - I did rewrite parts of the code: it did contain lines like *dx = MAP_HEIGHT(...) which cannot be correct. - I did not had a map to check, but I think it now can handle tiled maps with differing sizes. (For example a 20x50 map tiled to a 50x50 map.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Collaboration on a Java-based map editor? (repost)
Rick Tanner wrote: About two weeks ago (or maybe longer..) on IRC one of the developers who worked on and updated the map editor for Daimonin asked about a collaboration on a Java based editor that had a central or common core with specific side packages(?) for Crossfire and one for Daimonin. For those who can *and* are willing to contribute Java development interested in persuing this? Or discussing it further? I'm interested since I did plan to fix/improve the editor for quite a while now (but never found time to really start work). And since both projects do not have that many developers, IMHO it would be a good idea to share resources. OTOH I still see some obstacles to consider when merging the editors: - Both editors are quite different (code-wise but maybe not feature-wise); it seems that both editors have been changed quite a bit since fork time. Since the Daimonin editor has no ChangeLog file, and the CF-Editor's ChangeLog file was not updated for all changes, it is probably not too easy to make sure all existing features are kept in a merge. - Into which repository should the merged code go? I don't think we should keep two copies (one in Crossfire, one in Daimonin) since it would be hard to maintain. Moving the CF-Editor into another project should not be hard to do since it is a standalone repository as far as I can tell. But the Daimonin editor is part of a combined server/client/editor/etc. repository. Therefore it probably has more dependencies to other parts of the project. - The Daimonin editor requires Java 1.5. The CF-Editor still works with Java 1.4. Since switching back to 1.4 does not really make sense to me, 1.5 would become a requirement for Crossfire. - I *think* some config files are not completely compatible anymore: - Spells are objects in Crossfire but (I think) still hardcoded as numbers in Daimonin. - Treasurelists in Daimonin use some syntax (I think). Not sure if the treasurelist format has changed, or if it is only the syntax of the string referencing the treasures. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire nolonger compiles
Miguel Ghobangieno wrote: [...] Filed bug report at http://sourceforge.net/tracker/index.php?func=detailaid=1399546group_id=13833atid=113833 Also crossfire server crashes if a player enters four random maps in quick succession. http://sourceforge.net/tracker/index.php?func=detailaid=1398239group_id=13833atid=113833 Please do not duplicate these bug reports here. It is not useful because developers automatically receive a mail whenever a tracker item was added or modified. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: [Crossfire-cvs] CVS commit: client
[EMAIL PROTECTED] wrote:
Module Name: client
Committed By: ryo_saeba
Date: Tue Dec 27 14:26:29 UTC 2005
[...]
Log Message:
Make nrof uint32, like server-side. Fix a crash with get_number.
[...]
! char *get_number(uint32 i) {
[...]
+ if(i0)
+ {
+ sprintf(buf,negative);
+ return buf;
+ }
This check does not make sense to me: the variable i is a unsigned
variable. Therefore the value never is negative, hence this code will
never be executed.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Proposal for player logfile / plugins
Nicolas Weeger wrote: It seems the slow issues Metalforge has been experiencing are related to Python, and possibly due to the size of the logfile (log containing birth date, kick info, muzzle, and so on). I agree that the lags for players logging in on mf are probably related to Python. (Disabling Python did solve them.) But I have concerns that the real cause of these lags is indeed the size of the logfile (Player_log): A while ago Leaf told me that the Player_log file on mf was about 226k. At that time the server did lag for about 5s for every player logging in. I created a Player_log file with 4901k size (5 players) on my own server. This did lag my server for about 5-7s (on a *much slower* computer). Since the Python parsing function should scale linear with file size, and if I assume that mf is (much) faster than my computer, the 226k file should result in a lag of (much) less than 0.3s (=6s*226k/4901k) on mf. That said, I'm still not convinced that the size of this file is the real cause for these lags. My proposal is to split this file, putting player's information directly in the player's directory. [...] Drawback (for logfile at least), no more consolidated file with all the info - but shouldn't be too hard to do a script to merge all info for statistical purposes. Maybe it could be interesting for DMs to know which players did log in from an ip address (or ip address range)? With the split info approach this feature probably is not possible. And I don't think using such a script is a good idea: it creates another external dependency. (And the Python scripts accessing this collected information probably will not detect old (i.e. not updated) information in case that external collect script fails to run.) What do you think of that? Removing code that does not scale well is probably a good thing to do. An alternative approach to consider: use a file format that does scale much better. Note that a previous commit apparently did the reverse thing: replace an efficient file format by an (accessible but) inefficient file format: | # cvs log python/CFLog.py | [...] | Working file: CFLog.py | [...] | revision 1.3 | date: 2004/09/01 02:03:25; author: temitchell; state: Exp; lines: +48 -28 | [...] | - replace crossfirelog shelf with plain text datafile (less efficient | but more accessable) | [...] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Command learn_spell does not work for some spells
Mark Wedel wrote: I'd think that the abil_ball_lightning could perhaps change names. The monsters don't care what it is called :). Seems to work: I did rename abil_xxx to xxx ability. The actual spell cast by the monster was still xxx. I'm just not sure if that is used for dragon players to give them the spell or something. The treasure lists dragon_ability_yyy (yyy=fire,cold,etc.) contain spell_xxx but not abil_xxx. Renaming these spells (perhaps to ball lightning ability?) also would allow DMs to learn the abilities. Not even sure what spelldirect_ball_lightning is used for - the archetype exists, but isn't used in the treasure for any monster nor is it used by any other arch (quick grep spelldirect_ball_lightning */*) - I _think_ this is here for compatiblity because some maps gave the monster this object (old spell code) so needed an object to use for that instead of getting a null object. IF this is the case, the maps should perhaps be examined to see if anything is still using this, and ideally, just fix up those references and remove this arch. No map (in maps-bigworld, both current and some old versions) references this archetype. Some more digging revealed: the ChangeLog file contains two references to spelldirect_xxx. And checking out old versions from cvs did show that dragon_ability_xxx did include spelldirect_xxx a while ago. At some time spelldirect_xxx was replaced by spell_xxx. Leaf did check the player files on metalforge: ten players include spelldirect_xxx objects. Therefore we probably should not delete these archetypes. All that said, looking for objects that have spell_ as the archetype name would probably be a safe workaround. With the above findings, I think we should use a slightly different approach: allow all objects with type 101 (SPELL) with the exception of arch names spelldirect_xxx. This, combined with the renamed abilities, and also an improved learn_spell command to prefer full matches over prefix matches should enable a DM to learn all existing spells other than the obsolete spelldirect ones. It'd perhaps also be good to somehow get that multiple matches were found and print a warning in that case, but not sure how easy that is to do. Should not be too hard -- I'll implement that. And also improve the commands learn_spell and forget_spell to give more accurate failure messages, and to allow a direct match even if a longer one exists (xxx vs. xxx ability, or vitriol vs. vitriol splash). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Command learn_spell does not work for some spells
The DM command learn_spell does not work for some spells: for example learn_spell ball lightning does not work. The reason is that three different archetypes with name ball lightning and type 101 (SPELL) exist: - abil_ball_lightning, - spell_ball_lightning, - spelldirect_ball_lightning. This makes get_spell_by_name() fail because it finds more than one matching spell and therefore rejects the name as ambiguous. To fix this, I'd suggest to make this function consider only archetypes with names spell_xxx. Any objections or other suggestions? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Weather bug, continued
Nicolas Weeger wrote:
[...]
My proposed check is to change insert_ob_in_map for:
originator-below = op;
} else {
/* If there are other objects, then */
if((top=GET_MAP_OB(op-map,op-x,op-y))!=NULL) {
object *last=NULL;
/*
* If there are multiple objects on this space, we do some
trickier
handling.
ie search floor such all the time. The code after handles INS_MAP_LOAD
and INS_ABOVE_FLOOR_ONLY flags.
I still cannot follow all the code that are done while loading maps. But
since the fix you propose here just reverses a part of the patch to
accelerate map loading (see cvs diff -r 1.100 -r 1.101 common/object.c),
it should not break too much. But reversing it will probably make map
loading slow again. Therefore: would it be possible to limit this
processing for overlay maps only? I.e. use something like
if ((!(flagINS_MAP_LOAD) || is overlay loading) top = ...)
instead of the original version
if (!(flagINS_MAP_LOAD) top = ...)
Btw it looks strange to me that an overlay is always on top.
This problem should be solved with the above proposal, too: objects from
the overlay map are merged correctly, but the original map is loaded
with all the checks skipped.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unbalanced spell types
5FJust committed the changes. I only fixed area affecting spells; bolt spells are still broken. Mark Wedel wrote: Andreas Kirschbaum wrote: I think the damage should be scaled down by the monster size (measured in tiles it occupies). This would mean a spell deals full damage only if it hits the whole monster (i.e. the spell covers all monster tiles). Do note you need to cover rounding issues. In the case of the greater demon (42 spaces), that could be a considerable amount of damage. I added this by simulating a float effect by randomly giving an additional damage point. Now on average it should do correct (fractional) damage. And ideally, this should be handled after damage (or maybe as part of) damage reduction from protections is taken into account, since that also has rounding errors (but I think those might have been fixed by randomly determing if the remainder does damage). I added the damage reduction code after all other damage calculations are done, just before the hp -= dam statement. Therefore no rounding issues should be present. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unbalanced spell types
Joshua Wilson wrote: Mark Wedel wrote: Having the same logic for bolt spells doesn't seem unreasonable - if a bolt only hits 50% of the creature, it only does 50% of the damage. This is awfully dangerous sounding - given a bolt spell can NOT hit 100% of any monster other then a 1xX monster we will end up nuking bolt spells if we are not careful here. Of course, we should not blindly scale down by monster area. Since a bolt spell naturally hits only in one dimension, we should scale down by monster diameter. The adjustment Mark Wedel suggested above should be (IMHO): scale down by the maximum number of tiles you could hit. This number depends on the bolt direction, so four values are necessary. For rectangular monsters this would reduce to: - horizontal bolt: scale down by width - vertical bolt: scale down by height - diagonal bolt: scale down by MIN(width, height) To reduce necessary calculations, we could add five new fields to the archetype type: scale factors for area spells and for bolt spells in all four directions. These fields would be calculated only once at archetype load time. (Unlike to the code I just committed which calculates the value each time it is accessed.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unbalanced spell types
Mark Wedel wrote: That said, one thing I said long ago and hasn't been done is the idea that a monster (or other object) no longer needs an archetype to cover the extent of its image. With the big image support, a hill giant can be changed so that it is only 1 square, but still appears 2 spaces tall. Likewise, demon lords could be greatly reduced in size - their full height doesn't have to be set. So that can be done to also reduce the footprint of many monsters, also fixing the problem to some extent. That said, some monsters, like dragons, can't really be fixed in that way. I'd support the arguments of Anton Oussik that such a change (i.e. user-visible monster size is not real monster size) will confuse players. Therefore I don't think this feature should be implemented. Nevertheless, the code I just committed should work with such monsters: it calculates the monsters size as the number of objects present in the archetype. This is the real monster size (i.e. the x/y area of the monster), not the user-visible monster size (i.e. the x/z or y/z area). Therefore, the damage will be scaled down by real monster size, which is IMHO the right value since an area spell (IMHO) covers more x/y than z dimension. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] loader mangles item names
While searching for the source of bug #1059537 (Chainmail mutations) I
discovered that the loader strips out leading material names.
cvs diff -r 1.36 -r 1.37 common/loader contains:
| Index: common/loader.l
| ===
| RCS file: /cvsroot/crossfire/crossfire/common/loader.l,v
| retrieving revision 1.36
| retrieving revision 1.37
| diff -u -r1.36 -r1.37
| --- common/loader.l 30 Jan 2003 00:07:08 - 1.36
| +++ common/loader.l 7 Feb 2003 06:57:17 - 1.37
| @@ -133,6 +135,22 @@
| else
| set_materialname(op, 5);
| }
| +/* back out the materialname from op-name very limited subset of obs */
| +if ((IS_WEAPON(op) || IS_ARMOR(op)) op-name op-materialname) {
| +mt = name_to_material(op-materialname);
| +if (mt strstr(op-name, mt-description)
| + strstr(op-name, mt-description) == op-name) {
| + sprintf(buf, %s, op-name);
| + p = buf + strlen(mt-description) + 1;
| + free_string(op-name);
| + op-name = add_string(p);
| + sprintf(buf, %s, op-name_pl);
| + p = buf + strlen(mt-description) + 1;
| + free_string(op-name_pl);
| + op-name_pl = add_string(p);
| + }
| +}
| +
|
| /* We changed last_heal to gen_sp_armour, which is what it
| * really does for many objects. Need to catch any in maps
The log message is:
|
| revision 1.37
| date: 2003/02/07 06:57:17; author: garbled; state: Exp; lines: +19 -1
| Mark clued me in that query_name existed.. and that brought to light that
| the way I was handling materialnames before was stupid. Back the old
| code out, and use query_name instead. Put something in the loader to
| back the names out of the objects I mangled.
|
That is, code to fix object names that have been mangled by a previous
bug now mangles item names of newly created items.
Since this patch is now more than two year old, most item names should
have been fixed by now. Therefore: any objections if I remove this code
fragment again?
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Inconsistencies between map loading and map saving code
There are some inconsistencies in how crossfire/crossedit and CFJavaEditor handle the map headers reset_timeout and enter_x/enter_y: - CFJavaEditor uses the default value 0 for missing headers. It saves the headers only if the current value is positive. - crossfire/crossedit use the default value 7200 (for reset_timeout) or 1 (for enter_x and enter_y). But it saves these values only if the current value is not 0. This behavior makes crossedit add these headers by just loading and saving a map. I'd like to remove these inconsistencies by always using 0 as the default value for missing headers, and saving the headers only if the current value is positive. To not change the semantics for maps without a reset_timeout header field, I'd change set_map_reset_time() in common/map.c to treat the value 0 as the default timeout value (7200). (Note that set_map_reset_time() is the only function accessing this field.) For the fields enter_x/enter_y I just hope that most (all?) maps will still work: either the exit leading into this map contains coordinates, or the server will (hopefully) place the player to 1/1 if row and column 0 are blocked. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
[EMAIL PROTECTED] wrote: Module Name: crossfire Committed By: qal21 Date: Wed Aug 17 18:38:35 UTC 2005 Modified Files: crossfire/include: sproto.h crossfire/server: build_map.c Log Message: Fix bugs, and allow buttons and pedestals to be built underneath gates. [...] Index: crossfire/include/sproto.h diff -c crossfire/include/sproto.h:1.133 crossfire/include/sproto.h:1.134 *** crossfire/include/sproto.h:1.133 Fri Aug 12 16:16:31 2005 --- crossfire/include/sproto.hWed Aug 17 11:38:34 2005 *** *** 70,78 /* ban.c */ int checkbanned(const char *login, const char *host); /* build_map.c */ void remove_marking_runes(struct mapdef *map, short x, short y); int find_unused_connected_value(struct mapdef *map); ! int find_or_create_connection_for_map(object *pl, short x, short y); object *get_wall(struct mapdef *map, int x, int y); void fix_walls(struct mapdef *map, int x, int y); void apply_builder_floor(object *pl, object *material, short x, short y); --- 70,81 /* ban.c */ int checkbanned(const char *login, const char *host); /* build_map.c */ + object* get_connection_rune( object* pl, short x, short y ); + object* get_msg_book( object* pl, short x, short y ); + int adjust_sign_msg( object* pl, short x, short y, object* tmp ); void remove_marking_runes(struct mapdef *map, short x, short y); int find_unused_connected_value(struct mapdef *map); ! int find_or_create_connection_for_map(object* pl, short x, short y, object* rune); object *get_wall(struct mapdef *map, int x, int y); void fix_walls(struct mapdef *map, int x, int y); void apply_builder_floor(object *pl, object *material, short x, short y); This patch makes the functions get_connection_rune(), get_msg_book(), and adjust_sign_msg() global by removing the static modifier. What was the reason for this change? (Grepping through the source did show that these functions are both defined and called from build_map.c only.) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Patch: Fix map display errors for big faces
I just added my patches to fix bug #1102991 (Duplicate grapical display of the same monster): http://sourceforge.net/tracker/index.php?func=detailaid=1269280group_id=13833atid=313833 I did add the patch to the tracker instead of just committing it because it is not just a small bugfix but basically a re-write of the display logic for all three clients. (The display logic is now in common/mapdata.c and is shared by all clients.) I'd like to get some feedback before I actually commit it. Note that mapdata.c still contains lots of assert() statements. They did help me to ensure the passed coordinates are valid. I'll remove them before I commit. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Map Protocol Question
Alex Schultz wrote: Quoting Andreas Kirschbaum [EMAIL PROTECTED]: - client receives map_scroll +1/0 client basically ignores it because it has a cleared map state This ignoring as I see it is the main issue with the current semantics. For one thing the python bot that I started on a while ago wouldn't ignore the map_scroll in this case, and therefore there isn't such a display error in that respect (though it's probably not a good thing to model a proper implimention based on because it has even more display errors). Maybe I did use the wrong words here, but the client does not just ignore the map_scroll command: I tried to say that the client currently has an empty map. Now he receives the map_scroll command and properly scrolls the map view. But since an empty map scrolled by one tile is still an empty map I said it basically ignores the map_scroll command. - client receives map1a difference of Scorn to gatehouse Note: this information is not correct because it is a difference from Scorn, not a difference from an empty map. This is why some tiles show up as blank for a short time: all tiles that did not change are displayed blank (client already has cleared his map view). I'm not exactly sure this is an issue *if* the client doesn't ignore the map_scroll. This is not the problem I tried to explain: the client does *not* ignore the map_scroll command (see above), but the problem is that the server sends: 1. newmap 2. difference S-G 3. difference E-G (with S=Scorn, G=gatehouse, E=empty) Therefore the client updates his map view as follows: 1. newmap: client clears his map view; it is now E. 2. diff S-G: client patches his map view (currently E) with a difference S-G. This is not correct because that difference should be applied to the map view S, but not to E. 3. diff E-G: client patches his map view (currently E patched by S-G, which is often G with a few blank holes in it). Again, this is not correct because this difference should be applied to the map view E but not to G with holes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
Nicolas Weeger wrote: Since Ansi C does allow you to assign any pointer value to and from void * this type cast is not necessary. OTOH such a cast potentially hides future bugs because the compiler cannot anymore generate warnings for mismatched pointer Actually, there is a warning (under MS Visual Studio) since event and options, const pointers, are treated like pointers. I see. I missed that the source pointers were const. It is also a mistake for me to send as void* (as opposed to const void*), since it's then easy to change the string in the plugin which would lead to data corruption. I agree. But wouldn't it be better to leave out the type casts and let the compiler issue warnings? After all, (as you pointed out) it *is* a problem, so suppressing the warning is not good. Note also that I added the specific conversion because (hopefully) soon plugin system will be redone and those parameter passing calls will be totally changed. OK. Then it probably does not matter anymore if the type casts are there or not. :) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Alex Schultz wrote: I think it might be good, though it might complicate things a little bit. I currently don't know anything about dealing with different branches in cvs, but I'm sure I could learn easily if I need to. I too think it would be good idea. And I don't think it would complicate things too much: any normal developer would just commit to the HEAD version. That means: NO difference for him. Just for critical bugfixes it would require a little more work because somebody would have to add that bugfix to the release branch as well. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] A few random ideas
Nicolas Weeger wrote: But with the current incorrect client type, the client shows an item converter as a weapon (that cannot be applied). By using a different client type, the client would at least not sort in these items between (usable) weapons. Hum, haven't checked client type. But then i never made any special cutting item yet :) I was referring to the slicingknife and b_slicingknife archetypes. They currently do exist in cvs and can be used to slice apples. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
