Author Topic: Experimental Rooster_GUILD.php (Read 36765 times)

jjones666 · « **Reply #45 on:** June 20, 2006, 03:47:45 pm »

I wasn't 100% sure which AOChat I am using, I think from the previous SVN builds - I know Khalem said that his latest update breaks a lot of stuff so didn't update. I know Xen also distributes a modified AOChat also at one point (so assume this is the one his module is based on).

Hopefully these type of problems will go away when we have one "standard" AOchat to use for all modules.

I will try to fix the module module based on your above input Nesi (thanks very much!). Will let you know the results.

Cheers,

-b-

jjones666 · « **Reply #46 on:** June 21, 2006, 01:56:57 am »

Works perfectly, thanks!

One thought, with new roster automatically adding person to roster - removing a new member from guestlist automatically before making a member would make sense. (I know you can do this manually before invite).

Cheers,

-jj-

Alreadythere · « **Reply #47 on:** June 21, 2006, 02:29:52 pm »

The current way the cronjob adds buddies doesn't handle deleted characters well.
It adds them, printing an empty "[BUDDY] [ADD]" message, followed by "[BUDDY] [LOG] logged [off] (not member)".

Adding a check so only IDs > 0 gets added as buddie seems to solve this.

Nesi · « **Reply #48 on:** June 21, 2006, 09:31:22 pm »

Hmmm tried using a while loop instead of a foreach?
Foreach can cause problems in some cases.

Edit: took a quick peek at the module code around the add buddy segment.

The foreach statement may go sideways through the columns of the array if there is only one row, in the array that is passed to it.
On numerous rows it will go downwards through the array, catching the key and value of the buddy in question as expected.

IE. if there is only one member to be added and this member is offline, the array from AOChat could look something like this $bud_del[id#] = false.

Foreach may then treat both the id# and the false (0) as an array value, adding both to the memberlist. And 0 is a valid "character" ingame.

Nesi · « **Reply #49 on:** June 22, 2006, 01:38:53 pm »

No promises, but try this line instead of the foreach.. will do the exact same thing as the foreach but not going sideways.

// Add to buddylist if not yet in there
while(list($key, $memb) = each($members))

Alreadythere · « **Reply #50 on:** June 22, 2006, 02:28:30 pm »

The problem I noticed is this: a char that got deleted is still in the member table. Then you get the result I posted above.
Doesn't have anything to do with foreach, it's just a missing check for a valid ID before or in aorc -> addbuddy().

Nesi · « **Reply #51 on:** June 22, 2006, 02:59:31 pm »

Quote from: Alreadythere on June 21, 2006, 02:29:52 pm

Adding a check so only IDs > 0 gets added as buddie seems to solve this.

Well i assumed this was your fix, and you are talking about adding buddys.

Dabaron · « **Reply #52 on:** August 18, 2006, 09:18:03 am »

Found an error in here that was causing my bot to crash if I did a -seen on someone that it had never seen. Was crashing with Fatal Error: Cannot use string offset as an array in C:\BeBot\Beerraid\modules\Rooster_GUILD.php on line 219.

I changed 219 from:
if ($t_result

[0] ==

to:
if (empty($t_result))
and that seems to have fixed it. Made more sense to me since it was looking for if (!empty($t_result)) for people that it had seen.

Xenixa · « **Reply #53 on:** September 03, 2006, 02:45:59 am »

Quote from: Dabaron on August 18, 2006, 09:18:03 am

Found an error in here that was causing my bot to crash if I did a -seen on someone that it had never seen. Was crashing with Fatal Error: Cannot use string offset as an array in C:\BeBot\Beerraid\modules\Rooster_GUILD.php on line 219.

I changed 219 from:
if ($t_result
[0] ==

to:
if (empty($t_result))
and that seems to have fixed it. Made more sense to me since it was looking for if (!empty($t_result)) for people that it had seen.

Hmm strange my line 219 is:

Code: [Select]

if (!empty($t_result)) { $last['seen'] = $t_result[0][0]; }It's checking to make sure the timestamp field is not empty before it reassigns $t_result[0][0] to $last['seen']. Reassigning the value from the DB to a new string var clears up the offset error before the actuall value is used.

Also I updated my Xens_Rooster_GUILD.php on my ftp server that contains:
- Fix suggestion from Nesi about checking the regex in the gmsg function for the or your in the string that comes from aochat.php

Thanks Nesi.

buff · « **Reply #54 on:** October 17, 2006, 08:38:49 pm »

Not sure if anyone noticed a problem with the lastest update with Bot rekon the Org. Msg. when people join and leaves. When I temp invite my alts to org and leaves then log off. My online list still shows the name of the alts that temp join and leaves. Thought would bring that up if anyone noticed this issue.

Also when I use jj's gueslist function and turn alert on/off, i guess this warning:

MySQL error (# 0) on query: UPDATE guests SET alertstatus = 1 WHERE name = 'xxxxxxx'
Unknown column 'alertstatus' in 'field list'

Khalem · « **Reply #55 on:** October 18, 2006, 02:56:46 am »

Somewhat related, but the issue with people remaining on online list is resolved in 0.3 SVN which has a rewritten roster.

kuznechik · « **Reply #56 on:** October 20, 2006, 07:29:53 pm »

in Xens_Rooster_guild.php at line 131 there must be

if (empty($l_result[0]) || $l_result[0][1] != $memb["rank"] || $l_result[0][2] != $memb["level"] || $l_result[0][3] != $memb["ailevel"] || $l_result[0][5] = '')

instead of

if (empty($l_result[0]) || $l_result[1] != $memb["rank"] || $l_result[2] != $memb["level"] || $l_result[3] != $memb["ailevel"] || $l_result[5] = '')

buff · « **Reply #57 on:** October 24, 2006, 07:02:36 pm »

tried what kuznechik recommended but still not working :/

jjones666 · « **Reply #58 on:** January 23, 2007, 01:59:27 pm »

Branched and split discussion on autoinvite and alert plugins to...

http://bebot.link/index.php/topic,648.0.html

-jj-

pusikas · « **Reply #59 on:** April 06, 2007, 09:59:50 pm »

The Roster_GUILD.php module deletes a member from the raid_points table when you do a "!member del" on him. It doesn't do that when the person is kicked from org, or just leaves. It also only deletes the raid points if the command is executed on the main, not when it is done on an alt. This is especially annoying, as there is no easy way to find out how many raidpoints were deleted, and since everyone can use the !member command. While the "!points add" command is limited (for good reason) to superadmins. And guess who managed to delete all his raidpoints this way? ^^

Is there a reason for this, or can I just comment out the following line?

Code: [Select]

$this -> bot -> db -> query("DELETE FROM raid_points WHERE id = " . $id);