BeBot - An Anarchy Online and Age Of Conan chat automaton
Archive => Anarchy Online Archive => BeBot 0.2 support => Topic started by: Nesi on October 26, 2006, 10:49:49 pm
-
Thought i'd try my luck at this one. Downloaded bebot 2.9 and coded/tested a few hours ago. So I have only tested !is and !member (which does not work due to FC also having integer probs).
Note a: Problems might occur depending on your MySQL version and setup. (Strict mode)
Note b: All Character id's are now passed as strings, so if you like to define variables in (ie: $id = (int)$this...) your scripts it will have unintended results upon meeting an id > 2^32
Another thread, with the same theme already exists. This is very different code tho and i did not want to step on the other posters toes.
-
ohh and btw, please post if it works or not :)
-
Solved the problem with new users :-)
Tower attacks get parsed somewhat strangely now tho:
[2006-10-27 05:23:02] [GROUP] [MSG] [All Towers] -1: ~&!!!&r!5b/RR!!!8S!!!!"
s"The Society for Rollerrat Crueltys?JeekR!!!8S!!!!"s¶Ancarim Iron LegionsAvalon
i!!!Asi!!!IC~
-
think bebot had a modded version that parsed them.
the output you gave is an unparsed message, that's the original format the bot receives those messages in.
maybe this new version didn't include the same modifications bebot's one had?
-
I just downloaded the 2.9 version and slapped this together from it's AOChat.php, for the tower message to be parsed as such the username must be "0" the towermsg posted by jjones is from "-1" so it won't get parsed.
edit: Fixed version posted further down.
-
Hmm, I don't understand how this change of number can happen? What should cause that?
-jj-
-
Ah, a small problem occured in get_uname thats called on incomming group messages - it evaluated the $user "0" as a numeric and then tried to get the associated username, instead it should just return "0" as the uname, which it is.
Should be fixed now.
Edit: New version on page 2
-
Works fine so far :-)
Thanks again!
-jj-
-
I'm getting an SQL error on INSERT INTO members, with the new toons;
Out of range value adjusted for column 'id' at row 1
id = INTEGER in the table.. should I modify it?
-
Try changing the id int -> bigint, it has builtin string -> integer conversion so that should do the trick.
edit: On second thought the BigInt will prolly break equals comparison between id's because it will be converted to float type when fetched by php, so varchar(11) might be better, since it will return a string.
-
I think I've fixed it by changing the ID column in table Members to Unsigned Integer.. seems to be working fine atm :)
-
I'll have a look at this asap.
-
More than likely the real issue here is that some people are ending up with negative character id's now in funky lengths and seems to be unpredictable from what I've seen. Should be easily fixable with just a change of type on the table as noted above.
-
As long as there are only loose id comparisons , changing the id column to unsigned integer will be ok.
Im not very familiar with the current bebot tho, so i don't know if any methods use strict comparisons on id's.
-
More than likely the real issue here is that some people are ending up with negative character id's now in funky lengths and seems to be unpredictable from what I've seen. Should be easily fixable with just a change of type on the table as noted above.
The bot ends up with negative id's because the new players have id's higher than 32bits signed, which is the only integer type available in php, this will then overflow into the negative.
This is 100% predictable behavior and can be reversed, only you can't use floats, php's other numeric type, as array keys since php will round and convert that to an integer. The only type left then are strings...
-
Nope, FC is directly assigning negative character id's now for some reason. I ran into this myself on a recent alt I made. ;)
-
Sounds like an unintended side effect of something Funcom simply hadn't thought about.
Could you provide any specific names of characters with negative id's?
-
Nope, FC is directly assigning negative character id's now for some reason. I ran into this myself on a recent alt I made. ;)
Nope they didn't. They data type they should (and are at most places) be using is UInt32 which is unsigned and therefor doesn't even support negative id's.
The reason you see negative ID's would be when the ID is converted from bytes to Int32 instead of UInt32.
-
Sounds like an unintended side effect of something Funcom simply hadn't thought about.
Could you provide any specific names of characters with negative id's?
Gimp69 and Wirent are two toons that if treated as signed 32bit intgers will show negative numbers. (Ie, their charids are over 2^31)
Nope, FC is directly assigning negative character id's now for some reason. I ran into this myself on a recent alt I made. ;)
WRONG, make a new toon on Dimension 1 and then hit shift+f9 when you're in the arrival hall, look at the number, it is over 2^31 and thus if the number is treated as a signed 32bit intger (ovbiously being first inputted as an unsigned 32bit intger) then yes, you recieve a negative charid, however it is indeed unsigned, and thus positive, its just that many things are (incorrectly) interpreting it as signed when it is not.
-
You should make a minor change in the code where requirements are checked, here:
if(!extension_loaded("gmp") &&
!extension_loaded("bcmath") &&
!extension_loaded("aokex"))
This AOChat version does require bcmath specifically, aokex won't do it (unsure about gmp).
It uses functions like bccomp and while it seems bcmath is included in PHP depending on your version and OS it also is not necessarily compiled in by default. Or to be more specific: "These functions are only available if PHP was configured with --enable-bcmath... The windows version of PHP has built in support for this extension. You do not need to load any additional extension in order to use these functions."
-
You are correct Porter, some linux users may have trouble with this AOChat.php if their php is not compiled with bcmath. Windows and most linux repos are compiled with bcmath tho so hopefully not too many will have that problem.
The stuff i put in only requires bcmath not gmp, and aokex is only used to generate valid login key.
-
I actually happen to have gmp but not bcmath :) After a quick comparison of the functions used here and those available in gmp / bcmath I used a few minutes on a coffee break at work and edited the bc into gmp_ in every bcmath function except bccomp which would be gmp_cmp and will try it in a little bit. I'll edit / post reply later when I know if it works.
-
I still haven't had time to look at this, but i suspect the following will need to be updated for AOEXT messages to work.
case AOCP_GROUP_MESSAGE :
/* Hack to support extended messages */
if($packet->args[1] === 0 && substr($packet->args[2], 0, 2) == "~&")
{
$em = new AOExtMsg($packet->args[2]);
if($em->type != AOEM_UNKNOWN)
{
$packet->args[2] = $em->text;
$packet->args[] = $em;
}
}
break;
-
I actually happen to have gmp but not bcmath :) After a quick comparison of the functions used here and those available in gmp / bcmath I used a few minutes on a coffee break at work and edited the bc into gmp_ in every bcmath function except bccomp which would be gmp_cmp and will try it in a little bit. I'll edit / post reply later when I know if it works.
So far no good. Roster update tries to add each of the new (too large id) characters as id "" and naturally fails after the first one. Even the first one does not help a lot because the id is obviously wrong. Either gmp differs somehow from bcmath there or I missed something else so far :(
EDIT: gmp_strval... I guess I need to convert the GMP results back to strings :) I hope that's it...
EDIT2: not solved yet... sleep next. Sorry for the monologue, while right now this battle is personal I hope if I can fix this with GMP it may help someone else as well...
EDIT3: Today I converted the bcmath much more thoroughly into gmp but still can't get large IDs out of AOChat.php :/ The function "lookup_user" is unmodified and if I trust it to return the (large) user ID as a string to function "get_uid($user)" where "if(gmp_cmp(gmp_init(0), gmp_init($uid)) == 1 || $uid == 0xffffffff)" does not return FALSE for the large IDs but the returned value still translates into empty string in Roster_GUILD.php I am beginning to give up on this attempt. If it was trivial to recompile this specific PHP with bcmath I'd have done it already. Unless something comes up I'll drop this and wait until I have the chance to install PHP5.
-
Ohh, i did not know the tower msgs were borked. Guess i should have tested it abit more, ill see if i can't whip something up.
Yes, that is where the problem lies Khalem.
-
Changed the lookup_user so it returns int 0, should help with the strict comparison pointed out by Khalem. I tested it and seems to work ok, please lemme know if it does not.
Porter: I would glady make a gmp version for you if you would point me to where i can get a gmp plugin for php 4.4.4 (windows).
-
Thank you for the offer, but seems you can't test it on PHP4 for Windows - quoting PHP docs on GMP: "Note: This extension is available on Windows platforms since PHP 5.1.0."
However, if you or someone happens to spot something obvious... The problem would seem to be in the lookup funtions here:
/* User and group lookup functions */
function lookup_user($u)
{
$u = (string)ucfirst(strtolower($u));
if(isset($this->id[$u]))
return $this->id[$u];
$this->send_packet(new AOChatPacket("out", AOCP_CLIENT_LOOKUP, $u));
for($i=0; $i<100 && !isset($this->id[$u]); $i++)
$this->get_packet();
return isset($this->id[$u]) ? $this->id[$u] : false;
}
function get_uid($user)
{
if(!is_numeric(($uid = (string)$user)))
if(!is_numeric(($uid = (string)$this->lookup_user($user))))
return false;
if(gmp_cmp(gmp_init(0), gmp_init($uid)) == 1 || $uid == 0xffffffff)
return FALSE;
else
return $uid;
}
Here lookup_user is straight from 0.2.9 and get_uid is my conversion from bcmath to gmp. It does not return FALSE as far as I can tell but $uid with a value that translates into an empty string in the roster update. My user id is defined as varchar(11) in the member database.
Or maybe my translation of the big dec/hex etc is faulty here:
function bighexdec($x)
{
if(substr($x, 0, 2) != "0x") $r = $x;
else $r = gmp_strval(gmp_init($x)); // default base is 10 for strval and auto recognize for init
return $r;
}
function bigdechex($x)
{
// gmp_init($x) <- base 10 string to GMP number
$r = gmp_strval(gmp_init($x),16); // GMP number to base 16 string
return $r;
}
function bcmath_powm($base, $exp, $mod)
{
$base = $this->bighexdec($base);
$exp = $this->bighexdec($exp);
$mod = $this->bighexdec($mod);
$r = gmp_strval(gmp_powm($base, $exp, $mod));
return $this->bigdechex($r);
}
I did not gmp_init $base, $exp, $mod because the conversion to GMP numbers should happen automatically in a gmp-function. I did use gmp_init in get_uid just in case because of something I read about 0 maybe causing trouble unless explicitly converted.
-
ah ok, ill make a version for the 3.x bot series abit later today then, just got back from a 15mile run and im a mess atm, feels good tho :)
-
I got the GMP version working finally :) While I did fiddle with the Roster_GUILD.php as well (to debug) I think the only actual problem was me missing one gmp_strval() here:
case "I" :
$res = (string)array_pop(unpack("N", $data));
$data = substr($data, 4);
if((gmp_cmp("-1", $res) == 1))
$res = gmp_strval(gmp_add((string)$res, "4294967296"));
break;
Also, unrelated but above in my previous code the "function bcmath_powm($base, $exp, $mod)" obviously does not need to be converted to GMP since the original AOchat already checks for GMP before bcmath and never uses this function if GMP is detected (or Aokex before either of these).
I'm right now too tired to try and post the complete AOchat.php for users of PHP4 with GMP but no BCmath but I will try and do it later, certainly if requested by anyone with the same problem I had.
-
diff's would be appreciated ;)
-
I'm using the AOChat.php that you have on AODevs and changed the id column in the members table to varchar(11) "Out of range value adjusted for column 'level' at row 1" and I'm not sure why. The table has level listed that it can be null and the insert into statement is trying to leave it a null value but it errors. Any ideas?
-
Gridfan has published another approach to fixing the 2^31 problem, and basically evolves around the fact that as long as we are inside the bot, it doesn't matter if the id overflows into the negative. It also does not matter if the negative id is saved in MySQL as once it's read again it's treated the same way as before it was saved by the bot.
This way we only have to worry about converting the id to a string whenever we want to do anything externally with the id, ie xml lookups.
There is one issue with this however.
Anyone having used the convert to string fixes put forth so far will have new characters saved with an ID which will be incompatible with the new fix and will need to have the column converted back to int, and then either delete entries for the high id's or convert them.
See http://aodevs.com/index.php/topic,66.0.html
-
My GMP version of Nesi's BCmath fix is here: http://firstlight.inevitablethursday.net/code/AOChat.tar.gz
NOTE: it absolutely requires GMP. Bcmath is not included as an alternative.
-
Official BeBot fixes:
0.2: http://svn.shadow-realm.org/svn/BeBot/branches/0.2/AOChat.php
0.3: http://svn.shadow-realm.org/svn/BeBot/trunk/Sources/AOChat.php
I'm going with Gridfan's fix as it will be easier for end users, and only requires a little more care from Developers.
-
Imagine I know NOTHING about .php...
How would I add this fix to my Bot?
-
Download the appropriate file for your version, i.e. if your running BeBot 0.2.x, download the 0.2 version, if your running a development version, download the 0.3 version. Simply replace the existing AOChat.php with the one you downloaded and restart the bot.
-
Khalem,
Does the towerattack module need to be modified at all btw? I know 1.19 has different output to the older Bebot one.
-jj-
-
Depends on which of the several modules floating around you use.
The current development version has been using the "new" format for some time now, but i cannot remember offhand when it was actually added.
The simplest thing to do to find out is to check the regexp in your tower attack module against that in SVN trunk.
On a side note, this is exactly why im annoyed at Auno for choosing to hard code the strings in AOChat.php, and even more annoyed that he choose to alter the strings from the default.
When the command hooking and parsing changes are added sometime after 0.4 release i will be changing the way modules register commands and how data is passed to the modules so that they may choose to use only the arguments passed and not rely on the text at all.
In addition i will when i find time rip the hard coded strings out and use the stock AO Client's mdb database for lookups or a trimmed down version of it that contains only messages that the bot could possibly see.
-
Sounds good, thank you =)
-jj-
-
Ahh, glad im off the hock. Been really busy lately.
Odd tho, when thinking of a solution for this problem i though about doing this, but php complained about the array keys being negative.
Musta done something wrong heh.