From leaf at real-time.com Mon Mar 30 16:14:14 2009 From: leaf at real-time.com (Rick Tanner) Date: Mon, 30 Mar 2009 16:14:14 -0500 Subject: [crossfire] Testing, please ignore... Message-ID: <49D13626.5030105@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Testing the mailing list after a network move, please ignore this message. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ0TYmhHyvgBp+vH4RArPgAKDgKOmt8veBrhy8fUnxHImw+o8MPgCgtik8 NObJJjiklU3RHDTPt5ZM574= =En2P -----END PGP SIGNATURE----- From lalo.martins at gmail.com Mon Mar 30 17:35:13 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 30 Mar 2009 22:35:13 +0000 (UTC) Subject: [crossfire] About to release 1.12 Message-ID: I'll make content and client releases this week. There's one open content bug (that I'm able to fix myself), and no open client bugs that I know of. One of the reasons this is so much later than I wanted is because, apparently, my head isn't big enough to contain all of content, server, and client information (especially what with also doing other crossfire- related work on the side, and then work work...). So I've wasted most of my crossfire-time on the last 3 months trying to understand server dynamics and open bugs... and mostly failed. Meanwhile, I could have fixed and released content/client three times over instead. Even so, and despite my uselessness, the server bug count is apparently reduced to 6, mostly thanks to anmaster and mwedel: http://sourceforge.net/tracker/? func=browse&group_id=13833&atid=113833&status=1&category=312237&artgroup=897591 (if your mail|news client wrapped that, you know the drill, copy it and paste it as one line). If you can fix or at least understand one of those, your help would be appreciated. I have a clue I'm following on the godenchant bug (gods are one of the two parts of the server I understand reasonably well :-P). Hopefully, the server can be released in two weeks or so. May Lythander be on our side ;-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue Mar 31 00:47:04 2009 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Mar 2009 22:47:04 -0700 Subject: [crossfire] About to release 1.12 In-Reply-To: References: Message-ID: <49D1AE58.8060003@sonic.net> Lalo Martins wrote: > I'll make content and client releases this week. There's one open > content bug (that I'm able to fix myself), and no open client bugs that I > know of. Taking a quick look at that list, some comments. First question - is it known if these bugs still exist in 2.0 server? Quick notes/questions on the bugs from just spending a few minutes on them: Lockpick merge bug: Not sure why that would happen - can_merge() explicitly checks that the magic of the 2 items is the same, so unless the merge for lockpicks is somehow different (which would seem unlikely), not sure how that would happen. A test case (map) would help on that one. customize stack of weapons bug - that should be easy to fix - I'll see if I can get something done this week on it. CFDialog - not all familiar with that area of code, so someone else probably needs to look at that. 2.0 god enchant bug - I can see what is happening, right in lines 910-940 in server/gods.c. First time around, divine_owner would be null, so it would fall through to the code that sets the divine_owner, etc. But after that, divine_owner is not null, and check for it belonging to this god is true, so it prints that message and doesn't do anything more. I didn't write that code, so I'm not sure of the intent - I almost suspect that area should not exist (only check to see if it belongs to another god), and the section that sets the key values is encased in an else (so it called only if divine_owner is null). In that way, if the weapon has been blessed for this god, it can actually get to the code that gives it bonuses. 2.0 wraith feed bug - the order of unarmed skills is defined in include/skills.h. It is easy enough to move SK_WRAITH_FEED to top of the list. I think there is another bug that the unarmed skills are hard coded - unclear what the correct general answer is. The correct 'real' fix is to remove that hard coding and perhaps make that a character attributed (preferred unarmed skill or something)