Multicore Dissabler for Version 451 (only)
 

This seems to be a common Problem with these Newer/Faster/Better Computers

*Edited*

Refer to this post here, for a better alternative.

Why would you need to install this when you can set affinity?

Repetition was my initial thought process...
 

10 rem -*set affinity 101,102,103-999*-
20 Open TaskManager > Processes
30 OnClick [RMB] > UnrealTournament.exe > Select Affinity
40 rem -*Deselect all cores except one.(0-16)*-
50 On_Error Goto 10
60 On_Load Goto 10
70 rem -*RMB = RightMouseButton*-
80 rem -*>*- = Select

BTW-The above patch assigns CPU-0 to the load.

something about those Grey area's...I can't quite put a finger on it .

Use a batch file to start ut then :s

start /affinity 1 <program name>

This is a HORRIBLE way to patch the game

I agree....batch file would be much better lol

why Horrible?

That looks better. Will Try that. Might improve it a bit more.

The Dual_Core_Patch @ Skillz is for version 432 I think.
So it would replace the 436/451 .EXE and Replace it with the Patched 432 ver. instead.

The Original_Dual_Core_Patch has helped Alot of players with dual-core performance issues
this was intended as a quick fix.Hopefully it works... in saying that ...
Someone could always zap us up a a menu in ut that allows for core selections ;)

and what else ... is not a product marketing

point being?
 

if you don't like it . Delete it.

'perhaps a sandbox with packet logging would help ease the *unknown's*'

Disabling cores completely degrades performance by a lot. Contrary to popular belief, UT is NOT a single threaded application. If you disable cores you will force all threads (rendering, sound, networking, input, mods, cheatprotection) to run on the same CPU core. Depending on how much work these threads have to do this might in fact result in worse performance than a completely "clean" UT.exe would.

Second thing is that this doesn't really fix the problem in any way. The real problem with UT is that it uses the RDTSC instruction to calculate the time. As in, it reads the cycle counter of the processor to calculate how late it is. This is an ancient method and it no longer works for two reasons.

Reason 1: Every CPU core has its own cyclecounter and they're not necessarily synchronized with eachother. This means that at the same time Core 0 might say that it's monday 22/02 01:22:00 AM while Core 1 might say that it's monday 22/02 01:24:00 AM (yes this is an oversimplified example but it illustrates the point perfectly).

Reason 2: The clock rate is not constant (this has many causes, one of them being dynamic overclocking, others include powermanagement features like Cool'n'Quiet). This means that during one second the cyclecounter might increase by 1000 while during the next second the cyclecounter might increase by 1500. In other words, RDTSC based timing is not at all accurate unless you constantly measure the current speed of the CPU.

You can eliminate the first reason by editing your UT.exe like you did but you can't eliminate the second. There are several other problems with UT:

1: The "current time" is stored in a 32-bit float. Every modern games uses 64-bit double floats because the latter allows much greater accuracy and precision.

2: UT does not use the timeBeginPeriod/timeEndPeriod functions to request high resolution timers. As you may know the main rendering thread always renders a frame first during every iteration, then it "pauses" until it's time to render the next frame, but because UT doesn't request high resolution timers the game never really pauses as long as it wants to pause. If for example the game wants to pause for 15 milliseconds, the actual pause might take 5-25ms.

The only fixes that do work are the following:
1: Setting the affinity of the rendering thread. This eliminates one of the problems of rdtsc timing but not the second.
2: Disabling dynamic overclocking and power management. This reduces the effects of the second problem.
3: Using GetTickCount/timeGetTime/QueryPerformanceCounter instead of RDTSC timing. A good example of a GetTickCount based UT.exe can be found here: http://coding.hanfling.de/launch/

ended up restoring back to original and downloading a Patch (after reading this post);

thanx for the input

Find psexec.exe and put it in your system folder then you can run it from the bat-file on the core you want ,in my bat its dedicated to core 1.
Looks like this in mine

C:
cd \HitmansMH\System
@echo off
set MTH=%DATE:~4,2%
set DAY=%DATE:~7,2%
set YR=%DATE:~10,4%
set HR=%TIME:~0,2%
set HR0=%TIME:~0,1%
if "%HR0%"==" " set HR=0%TIME:~1,1%
set MIN=%TIME:~3,2%
set SEC=%TIME:~6,2%
set MYDATE=%YR%%MTH%%DAY%-%HR%%MIN%%SEC%
@echo on
move ucc.log "..\logs\crash\(restart)_%DAY%-%MTH%-%YR%_%HR%-%MIN%-%SEC%.log"
:top
psexec.exe -a 1 ucc server MH-HitmanResetMap.unr?Mutator=MapVoteLA13.BDBMapVote ini=unrealtournament.ini log=ucc.log
@echo off
set MTH=%DATE:~4,2%
set DAY=%DATE:~7,2%
set YR=%DATE:~10,4%
set HR=%TIME:~0,2%
set HR0=%TIME:~0,1%
if "%HR0%"==" " set HR=0%TIME:~1,1%
set MIN=%TIME:~3,2%
set SEC=%TIME:~6,2%
set MYDATE=%YR%%MTH%%DAY%-%HR%%MIN%%SEC%
@echo on
move ucc.log "..\logs\crash\(crash)_%DAY%-%MTH%-%YR%_%HR%-%MIN%-%SEC%.log"
goto top

Nice Batch file there hitman :)

will definitely look into it

Thx
feel free to ask if it goes wrong,with this setting you don't need Actor-clp or set up the server to restart true nexgen if it crash :banana1:

Heej Hitman, nice batch man... yeah i noticed also that prob sometimes when a player leaves the server will get stuck... strange..
i have tried a local run on my testset and ure batch worked perfect... i will asap change my servers with it.