Author Topic: 32bit character int fix for aochat. (Read 15180 times)

Dabaron · « **Reply #15 on:** October 30, 2006, 09:53:01 pm »

Nope, FC is directly assigning negative character id's now for some reason. I ran into this myself on a recent alt I made.

Khalem · « **Reply #16 on:** October 30, 2006, 10:21:45 pm »

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?

Vhab · « **Reply #17 on:** October 31, 2006, 07:06:00 am »

Quote from: Dabaron on October 30, 2006, 09:53:01 pm

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.

Neo-Vortex · « **Reply #18 on:** November 01, 2006, 01:33:39 pm »

Quote from: Khalem on October 30, 2006, 10:21:45 pm

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)

Quote from: Dabaron on October 30, 2006, 09:53:01 pm

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.

porter · « **Reply #19 on:** November 10, 2006, 12:05:17 am »

You should make a minor change in the code where requirements are checked, here:

Code: [Select]

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."

Nesi · « **Reply #20 on:** November 10, 2006, 01:04:11 pm »

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.

porter · « **Reply #21 on:** November 13, 2006, 07:58:22 pm »

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.

Khalem · « **Reply #22 on:** November 13, 2006, 09:00:04 pm »

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.

Code: [Select]

         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;

porter · « **Reply #23 on:** November 13, 2006, 10:34:07 pm »

Quote from: porter on November 13, 2006, 07:58:22 pm

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.

Nesi · « **Reply #24 on:** November 14, 2006, 12:33:39 pm »

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.

Nesi · « **Reply #25 on:** November 15, 2006, 09:23:09 am »

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).

porter · « **Reply #26 on:** November 15, 2006, 10:25:51 am »

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:

Code: [Select]

    /* 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:

Code: [Select]

    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.

Nesi · « **Reply #27 on:** November 15, 2006, 04:40:21 pm »

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

porter · « **Reply #28 on:** November 24, 2006, 10:56:04 pm »

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:

Code: [Select]

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.

Khalem · « **Reply #29 on:** November 24, 2006, 11:44:56 pm »

diff's would be appreciated

Author Topic: 32bit character int fix for aochat. (Read 15180 times)

Dabaron

Re: 32bit character int fix for aochat.

Khalem

Re: 32bit character int fix for aochat.

Vhab

Re: 32bit character int fix for aochat.

Neo-Vortex

Re: 32bit character int fix for aochat.

porter

Re: 32bit character int fix for aochat.

Nesi

Re: 32bit character int fix for aochat.

porter

Re: 32bit character int fix for aochat.

Khalem

Re: 32bit character int fix for aochat.

porter

Re: 32bit character int fix for aochat.

Nesi

Re: 32bit character int fix for aochat.

Nesi

Re: 32bit character int fix for aochat.

porter

Re: 32bit character int fix for aochat.

Nesi

Re: 32bit character int fix for aochat.

porter

Re: 32bit character int fix for aochat.

Khalem

Re: 32bit character int fix for aochat.