[Error] Using the Tibia functions

[Kush]

Hello guys, does anyone know what you're wrong?
I'm trying to inject a dll, but when I run the procedure does not work right, I use Delphi 2010, the same code works in Delphi 7.

Code:

const
  FSpeechAdress = $004073F0; // 8.6

var
  FSpeech: procedure(const speechType: Integer; const text: String); stdcall;

begin
  @FSpeech := Ptr(FSpeechAdress);
  // Execute
  FSpeech($1, 'Testing'); 

Result:
00:56 Test [1]: T

[Sketchy]

First stdcall is the wrong calling convention to use as the callee cleans the stack for this function, use cdecl instead as using stdcall will result in a corrupted stack pointer. If your program indeed ran fine with stdcall before you simply got lucky.

Now based on your result of only a single character I surmise that Delphi 2010 is using a 2-byte Unicode encoding (eg: "T\0" for 'T') for its string type which would be causing Tibia to stop processing it at the second byte due to a NULL byte immediately after the 'T' byte. A quick Google search does reveal that the string type will either be UnicodeString or AnsiString depending whether your project has been Unicode enabled. You should use the AnsiString type for any strings that will interface with Tibia's code, however you may need to pass them to Tibia's code through a PAnsiChar pointer (unsure how Delphi marshals an AnsiString to external functions).

And one more thing, if you aren't doing so already make sure this code is synchronised with Tibia.

[Kush]

Oh, Thanks.

Working:

var
  FSpeech: procedure(const speechType: Integer; const text: AnsiString); 

But I'm wondering if it is really safe to use in Tibia Global.

[Devil]

Sketchy, when using internals, I never had problems, even not synchronizing with Tibia...
Can you explain about it ? Why I need to sync with Tibia, and... how ?

[Sketchy]

Well taking this particular case for example the function being called is one of Tibia's outgoing packet constructors all of which write their packet to a single buffer which is ultimately encrypted and passed along to the socket send function. These aren't designed for concurrency and concurrently running two of them will likely cause both packets to be corrupted and potentially a client crash (not too sure about this case, but other internal functions it definitely could). So if your call isn't synchronised with Tibia you run the risk of its main thread calling one of these functions at the same time, and this risk increases greatly if the player is manually playing at the time too.

Ideally any call to Tibia's internals should be synchronised no matter how small the risk of concurrency issues is. Thankfully synchronisation is easy and you may be doing it already without realising, just hook one of Tibia's functions (eg: FPS print) to call your code which will then run from its main thread.