Project Reality Forums

There are ways to run cheat engine on linux i think, but no idea how good the results are.
Either way i dont see anything preventing from adding this to windows servers, if it all works fine there.

Most if not all servers run on linux.

You can use wine, or an alternative called PlayOnLinux to run the cheat engine application in linux. It's an app that allows native support for most windows games & apps and is not an emulator.

Link: https://www.winehq.org/

It can run Battlefield 2 just google around on how to install.

Pm me and I can help you with linux if you need help. Im not very good but im familiar with linux, just not in a technical level.

Linux 32 bit:

dice::hfe::ServerQueryCache::ServerQueryCache(void)
Offset: 00077B8D change mov edi, 3Fh to 63h

dice::hfe::ServerQueryCache::ServerQueryCache(void)
Offset: 00077C9D change mov edi, 3Fh to 63h

dice::hfe::ServerQueryCache::getPlayerKey(int, dice::hfe: layerQueryKey) (optional)
Offset: 00078062 change cmp edx, 3Fh to 63h

dice::hfe::ServerQueryCache::update(void)
Offset: 000790BD change cmp [ebp+var_1AC], 3Fh to 63h

Attention: These changes are untested and may either not work or in the worst case cause server instability.

I will add 64 bit later.

EDIT:

Linux 64 bit:

dice::hfe::ServerQueryCache::ServerQueryCache(void)
Offset: 0006D387 change mov edi, 40h to 64h

dice::hfe::ServerQueryCache::ServerQueryCache(void)
Offset: 0006D477 change mov edi, 40h to 63h

dice::hfe::ServerQueryCache::getPlayerKey(int, dice::hfe: layerQueryKey) (optional)
Offset: 0006D30A change cmp esi, 3Fh to 63h

dice::hfe::ServerQueryCache::update(void)
Offset: 0006E546 change cmp [rsp+238h+var_22C], 40h to 64h

This seems promissing, can I ask how did you found out the values?
And did you tested this in your computer (local server)?

edit:
I've tried the 64x and I got a Segmentation Fault error.

Hi everyone,

Like you might noticed the assembly solution didn't worked, the servers running in windows machine are very few and the linux solution is nowhere to be found.

But not everything is lost, we still have a non-native solution... Python! this might have none to a huge impact on the server performance, so again it could be a dead end, but we still need to try.


After a day of work I've made a QueryModule that adds a listening (UDP)port and replies with json file.

Currently the model for this JSON file is: This is far from complete, for example I want to reply with a fastest and smallest message, instead of the current block of text (MessagePack)

But seeing this is my first time coding with Python I wanted to ask here if there's someone that could help me.



The current version of the code is already functional but needs to be optimized and expanded.

AncientMan and I tried python already, but we found that server stability seemed to suffer, which is why we reverted back to not worrying about it.

[R-DEV]piepieonline wrote:AncientMan and I tried python already, but we found that server stability seemed to suffer, which is why we reverted back to not worrying about it.

And was your approach the same as mine? I knew that AM already had tried but he never said how was his approach so I figured I would try.


And if indeed was this your approach what do you think about an alternative were the server keeps the information based on events and not by iterating all players and after X seconds is the server that sends the information to the Master Server, instead of replying to it.

We tried the other way, contacting the server. I don't think there would be any difference though...

Both of these methods might be worth testing again though, but we'll have to wait for other tests to finish up first probably...

All bf2 python programming that involves sockets resulted in lags. Seems like BF2 was never meant to support it.

BloodyDeed, we did manage to get around that, using timers and stuff, so that wasn't the issue.

It appeared that the number of crashes increased, which was the issue I was concerned with.

instead of trying to re-write something in a low level or using py, couldn't you just put alongside another little server that just reads necessary things from the game server memory?

[R-DEV]piepieonline wrote:BloodyDeed, we did manage to get around that, using timers and stuff, so that wasn't the issue.

It appeared that the number of crashes increased, which was the issue I was concerned with.

And did you guys managed to find out what caused the crashes? Were the sockets our accessing some null objects?

If there are any server admins interested in helping this project I would appreciate.

Not sure if its possible to add python modules to the server without conflicting the PR Server License, but I'd like to try this version of the code.

Edit: Could a mod change the title of this thread to "Fixing..." instead of "Fixed..."

If the Devs gives us the go ahead, I don't think that us at =MeRk= would mind to do this test.

Bumping Thread.

If =Merk= is interested in testing we just need the Devs to say if they can test it w/o password or if needs to be "event" like.

The sooner the better.


Edit:
Following Mineral's advice I've sent PM to AM and AD

Save bet is just to make it passworded and tie it to another event to get +64 on the server. But PM'ing a red-tag might get you a bit further then that

Green Light, Red Tags said it was OK to test the code in public games, no password no nothing.

Any server interested PM so I can send the (2-step) instructions.

=MeRk= Server is running the script right now. The only thing we need is to get 64+ players on the server.

Hi everyone, I've promising news.

Today, with =Merk= running with ~80 players, the scripted was tested and no problems were detected.
During 18:49 and now, 21:24 (PRT) the server stayed in a constant ~80 players, 4/5 map changes (1k to 4k) and no player complaint about lag. The script ran every 5 seconds through a web request.

I would like to see more servers running the script to have better statistics but it seems the python module does not create LAG or increases the Crash probability.