Regarding my files idea... I know that you said the first part would most likely be impossible, and that the third part is already possible, but what about the second part?
Printable View
Regarding my files idea... I know that you said the first part would most likely be impossible, and that the third part is already possible, but what about the second part?
Ah ye, unfortunately, since every file's format is different, I'd had to rewrite too many functions (for all file) to make this work. :/
Anyways, I'll might rewrite some parts because of porting to HPC (like no more patched exe just a custom strings.dll), including file handling part too till 6.0, and then your 1st and 2nd request is might be possible too. =)
Not sure if its a bug.
But if you open the Halo console and type "connect 95.211.120.168:2306 -d" and the server is full, so you don't join. And then you press the arrow-up key to enter the command again until a place gets free. Well then you get ip banned XD
Yes, you get banned after too many join requests in too short time (if antihalofp is enabled).
It's a protection against halofp (Halo fake players exploit), which keep filling the server with "invisible fake players" by flooding the server with join requests, so even if you see server is empty and try to join, you will get the "Server Full" message.
More: http://aluigi.altervista.org/fakep.txt
My servers are still messed up sehe.
Ok, V 5.4 is out, it should fix your problem. I finally found the bug that only happened on single core CPU systems after I set main thread's priority to time critical.
Halo's threading fail again:
004434C8 |> /8A4424 03 /MOV AL,BYTE PTR SS:[LOCAL.3+3]
004434CC |. |84C0 |TEST AL,AL
004434CE |.^\74 F8 \JZ SHORT 004434C8
assembly *barf*
Why are you setting the main thread's priorty to time critical, let alone when there's only one CPU...
Well because hardly anyone uses 1 core systems lately. :D And even if yes the main thread will still get more priority, that's the main point of it lol.
And souless we don't need your unintelligent comments here thx.
I'd still rather see benchmarks demonstrating that the main thread even needs such a tweak or that such a tweak provides a noticeable, and reliable, difference under load (the game can only do 30 game ticks a second), especially considering how this might interfere with windows services or the gamespy/cache read threads (as was the case above apparently). Isn't this the server app that is constantly crashing?