Nameless Voice on 13/6/2010 at 14:04
UAC will prompt for admin rights to copy a file to C:\Windows
Still, other things such as the DDFix GUI already need to be run with admin rights, so it's not that huge of a deal.
A binary-hacked .exe would work, too. On the one hand, I'd say we'd want one for ShockEd too, but on the other hand I could say that anyone with enough computer knowledge to use ShockEd ought to be able to place a file into C:\Windows, too.
Kolya on 13/6/2010 at 17:47
Quote Posted by Nameless Voice
UAC will prompt for admin rights to copy a file to C:\Windows
Still, other things
such as the DDFix GUI already need to be run with admin rights, so it's not that huge of a deal.
Yeah, which produced loads of problems until I eventually decided to run a silent hex-patch instead of the ddfixgui during SS2Tool's installation. So that's what I want to avoid.
Regarding shocked: I'm not using it much, but I don't follow the logic that because it's complicated it doesn't matter if it gets even more complicated.
Telliamed on 14/6/2010 at 00:28
It's read with (
http://msdn.microsoft.com/en-us/library/ms724345%28v=VS.85%29.aspx) GetPrivateProfileIntA (and related functions) so to use the local directory you need to change the static constant "lg.ini" into the full path to the file.
And I'm pretty sure it uses unsigned arithmetic for the memory limit. I was a bit cautious in saying 2147483647, but you can go up to 4294967295.
Also, it seems that the resource cache is the
only place where it's used, other than the "suspiciously high" message which is just a message and not a limit. Curiously, portalizing tracks memory use and will increase the limit to the peak value after doing a portalization pass.
Zygoptera on 14/6/2010 at 02:56
I guess that explains why I could always 'fix' the problem by optimising.
Kolya on 14/6/2010 at 11:44
The binary fix itself works, but as soon as I introduce it to DDFix the game produces a crash upon level loading ("video hardware not supported"). The lg.ini trick doesn't have that problem.
Any ideas are welcome. Maybe we should invite Si02 to this thread?
Below are the instructions for hex editing shock2.exe
Quote Posted by Telliamed
Patch the EXE to get rid of the 40M boundary. You just have to change the bytes at these offsets:
002272FF, 00227308, 00227320, 00227327
from: 00 00 80 02
to..: 00 00 00 80
Which is 2G. Or change to FF FF FF 7F for maximum memory.
EDIT: After a few tests it looks like placing lg.ini isn't a problem with UAC, so I guess I'll stick with that.
Telliamed on 15/6/2010 at 20:42
Quote Posted by Kolya
EDIT: After a few tests it looks like placing lg.ini isn't a problem with UAC, so I guess I'll stick with that.
Actually the patch may be better. Volca pointed out that systems with lower memory could be adversely affected by a large cap. The patch just raises the arbitrary limit while keeping the 3/4 physical memory calculation.
Are you absolutely sure this patch is involved in the crash? I don't see how it could. I'm more keen to guess DDFix is acting up on its own and would do this even if you reverted the change.
BTW, those are the offsets for Shock2.exe. It's obviously different for Dromed. You can just search for and change the first four instances of '00 00 80 02'. Oh, and I fail at math. 0x7FFFFFFF is of course smaller than 0x80000000. The maximum is 0xFFFFFFFF, duh.
