The_Cowboy wrote:I have not started native coding yet (have been resisting this temptation), but I have collected some information about it over time. The reason people "knowing the way" dont discuss it is that it would render all the anticheats useless.
I strongly disagree. Cheat-makers often know the engine better than the ones trying to protect it from them.
Everytime an anti-cheat is released, the veteran cheat-maker will reverse engineer it and bypass it in a fairly short amount of time, while the novice cheat-makers will ask info about the engine and how things work natively to those same veterans.
I even go as far as to state the following: when I started to make my first experiments (last Friday), some of my questions were answered by cheat making forums. I didn't go there directly, but as I searched in google certain terms and certain errors and problems, some of them directed me straight to a cheating site, where one guy was trying to develop a cheat, and the veterans were helping him by giving him info about it.
I would even dare to say that there's a greater deal of public information on native coding in a cheating forum than ever was in every non-cheating UT community.
So I don't really see what the harm would be to level up the discussion here as well... when in fact some interesting things may be discovered to nullify some of these anti-cheats and even engine crashes. Discussing or not discussing it won't make a dent on the cheating possibilities.
Of course, anything that I personally find to crash the engine or that could be exploited, I won't post to public either, since some of these cannot be fixed, instead I may only discuss it with some trusted parties, like anth for example.
The_Cowboy wrote:AFAIK, you have to compile the code using gcc (and obtain .so instead of dll) if you want you mod to run in LINUX machine. Anthrax has already mentioned the required settings for it.
Yes, he also mentioned that it takes a good deal of work and hacks to make something work there without giving problems. In Linux v436, it seems some essential things for any native mod are not even possible and will crash the engine from the boot up of the package.
So I have my doubts in whether is it worth it or not. What's the latest Linux version where a mod without any major hacks (no Windows specific libraries, no Windows specific code, no modifications in the headers) is able to run without issues?
Thanks for the links. I also looked into anth's demo manager source (which he posted above as an example of cross-OS compatibility), but they use the guard and unguard functions, so I assume the UT Linux version it works with is not the v436 one, but one below that one.
Either ways, I am getting the hang of it. I had to (and still am) reading in the C++ syntax, and so far things look a lot clearer now, and they are actually rather easier than I imagined them to be. Atm I am trying to read skeletal meshes bone information and trying to figure it all out. Raven wrote a native mod to do so, but unfortunately he didn't continue and his mod doesn't really work at all, since he misunderstood how the skeletal mesh coordinates worked (for example, he reads only the skeletal accumulated relative positions to give a bone position, however he also needed to consider their orientation otherwise all the locations (except the root bone) will be off from their real positions, and for this I need cumulatively rotate the quartenions in each bone to know the real position of the next in each branch... I still didn't finish it, as I am trying to figure out which native functions I should use for this, some of them are confusing).
I know it's possible, with some heavy math in the mix, but possible nonetheless, and fairly important to what I want to do.
I wanted to make it work under Linux too, but the problem is that there's a greater lack of information about Linux than for Windows in this, and even if it ends up working nicely, there's a greater chance of crashes and glitches in the Linux version. I am not even worried about the Linux client (I discarded that a long time ago), but the Linux server as I don't know how many server admins use Linux to host UT (probably most of them since I guess gameservers use Linux for all their games).EDIT:
I already understood what the guard/guardSlow do exactly. Anth talked about UnFile.h and that's where I should have looked into first, the source itself is like a manual.
If I understood right, it's simply for the engine to catch the exception and present it with full info during a GPF (in other words, it's the one of the things that trigger a GPF instead of letting it crash on its own). But from what I understood by looking at the code, I can use them in Linux, but I have to redefine DO_SLOW as false whenever the OS is Linux from my headers, or alter the UnFile.h header to detect that on their own.3 questions though:
1 - I intend to manipulate files sooner or later, as well create directories (to keep things organized). Should I use the functions from the UT headers or should I write my own functions for it, given this UnFile.h limitation in Linux? (I know that creating directories is OS-dependent, but in case I add support for Linux, I will search how it is done in each system and then create a generic function with both simply separated by preprocessing conditions and OS flags, I guess that's the correct way to do it?)
2 - I also intend to use multi-threading for a few things (gotta use the CPU power available nowadays)... is std::thread safe to use in both operating systems?
3 - Does anyone know about this: https://github.com/stephank/surreal
? (it seems to be for the OpenUT project, specifically for Linux... could it be that perhaps I could compile everything safely for the Linux version of UT using the modified headers from that place?)
(probably I should create another thread just for this stuff)