Unfortunately, we have experienced significant hard drive damage that requires urgent maintenance and rebuilding. The forum will be a state of read only until we install our new drives and rebuild all the configurations needed. Please follow our Facebook page for updates, we will be back up shortly! (The forum could go offline at any given time due to the nature of the failed drives whilst awaiting the upgrades.) When you see an Incapsula error, you know we are in the process of migration.
You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser.
Its not best way to make items table external and there is a lot of offsets to fix, you can say it was my test to see if this will work at all and what security checks I will break. Its also not so easy to port it to another client.
I will think about some replacement for this.
The best thing would be to move external table to some other place, make space for 1000 items of each kind and than fix offsets to table.
Code:
How would the EXE access some offset from another file without parsing it, or something?
I loaded it into memory and I have access to it from there
Its not best way to make items table external and there is a lot of offsets to fix, you can say it was my test to see if this will work at all and what security checks I will break. Its also not so easy to port it to another client.
I will think about some replacement for this.
The best thing would be to move external table to some other place, make space for 1000 items of each kind and than fix offsets to table.
Code:
How would the EXE access some offset from another file without parsing it, or something?
I loaded it into memory and I have access to it from there
The DLL should "export" offsets to malloc() created memory, and the client should be redesigned to acquire the offsets it needs from those exports.
The DLL Entry Point should malloc() and load data in the case DLL_PROCESS_ATTACH: point. the lpData it gets from the malloc() should be an "Exported Symbol", so the client will know where to look (and it could be a different address each time the game is loaded) as soon as the DLL is loaded into the process space.
It will still take some considerable reconfiguring of the game client executable... but it will work. All other offsets are presumably relative to that base address... if not, other offsets, SizeOfs etc. can be exported by the DLL too.
Alternatively, any code routines in the game which reference the item table can be exported to the DLL it's self. Then the pointers to the dynamically allocated memory are local to the module they are run in, and don't need to be exported. Instead, you export each of the functions, (hoping that they don't refer to any other tables which are still in the game.exe) and call them from the import table in the game, or via GetProcAddress() if loaded dynamically.
The fact that this table could then reside at any location in memory makes CheatEngine hacks harder to implement, not easier. And checksums (such as they are) can still be applied to ensure that the file hasn't been changed. And you can add additional checks in either the DLL or the main client executable. (you will have made a lot of "cave" space)
What Vormav did is impressive, (though I think I'd have told the compiler to compile to a .asm file and hand assembled that in Olly) and I suspect that is a lot of how rPT / uPT clients are put together. I'm just saying, it is possible to do it in a more "adaptable" way.
I get PMs a lot asking how to use the globalField or Protocol DLL code without distributing a DLL file... and this is a good example of that. The Protocol.dll is a silly question, because I only removed the code from the server executable in the first place, so the answer is just don't remove the code from the server if you don't want it in a DLL... ??? What?
I may guide embedding your external DLL code into you main executable. I don't see it as any improvement, but if you want to keep the file count down for some reason, then it's worthwhile knowing that it can be done, and really isn't that hard.
Vormav, can you work better on it? I'd like to make it, cause I want to develop a program so you can add new itens to your server with just a few clicks
Well, we all know what Vormav is up to, and it is looking really good, and totally new and different. :
I am looking at something like that too. Though, I'm looking at making maps and items load from a text file or SQL data... so if you wanted "a few clicks" you'd have to write a GUI that created and modified the text files / SQL tables.
What Vormav has given us here is sufficient to be able to get on with that our selves. Don't you think?
I'm still in prep. Making a server which is cleared out of redundant stuff the way my client is, so as to give me space to put the new code this will take in the PEs' existing allocations rather than making nasty sections and flooding the flat memory... But we can start a discussion on implementing this in our servers and clients. I'm sure it would be helpful to pool our ideas and experiences. :
I will probably have to do it in XML next time, my current project require working item table, so its only natural to have easy access to items DB.
However I have few other things in mind for PT right now (visible aging/mixing parts of armor and hooking DDraw (F11 power without pressing it )).
Yea... if you could explain the DDraw thing I would very much appreciate it.
I did ask if anyone knew enough about DDraw in x86 to point me in the right direction to do something like that a couple of years... and the only responses I got where "hell yea, tell me too". XD (talk about blind leading the blind)
