Ok, first off make a file named lg.ini, this file must be in your WINDOWS directory, not the game directory containing the editor. Here's what I know so far about what entries go in this file, this is in standard .ini format with the heading in  and the entry below this:
I'm not sure what all these do, and I'll have the default values soon (these are what ShockED/Dromed use if this file is not present)
Some things I've tried:
This will start the editor aligned at the upper left corner of the screen
Attaches the standard windows arrow pointer to the crosshair in the editor
This has only been tested with ShockED, but I assume it will work with the one for Thief
Yea, also I'm wondering if MakeAllCodeWritable is something akin to a safe mode, you can look but not alter the map data
I can't think of any usefulness to us.
Controls memory allocation. ''UseExternal'' requires you to supply a DLL that exports a IMalloc interface. ''Debug'' uses an optional allocator that does more rigorous checking of the memory. (Something I should use more often... but don't).[Allocator]
The Dromesday Book
Well that clears some of it up. I have some of the defaults that it falls back to if this file is not present (which up to this point it hasn't I take it), so here's the defaults I've found:
MT (default 0)
DisableInactiveBlock (default 0)
DisableWindowsPrintScreen (default 1)
Enabled (default 1)
Heap (default 1)
MultiPool (default 1)
Timings (default 0)
Debug (default 2)
DumpUnfreed (default 0)
MemoryCap (default 0)
ARQ (default 1)
And yes that last one is a new one I found.
I'll eventually find out exactly what they do as I get deeper in the code
Of course that's an unreasonably limitation for the computers we're all using now. So everyone should be using an LG.INI with a sufficiently large MemoryCap. Something like this...
Remember that LG.INI must be in C:\WINDOWS, not the game directory.Code:[Allocator] MemoryCap=2147483647
Would be awesome if someone could find the code that calls lg.ini and make it work in the game dir. Having it in C:/windows sucks in terms of deploying the fix and compatibility.
So, wait...if we were to put this file in c:\windows, would that possibly eliminate the problem in ADaoB where the inventory items change their icons and crash the game?
Yep, setting that seems to have fixed all the missions I had the inventory/ keycard bug with, and removes the "memory allocation suspiciously high" notification from monolog too. I even set the music to a custom schema I had which loaded just about every single music file in the game to try and stress it more and couldn't get the error even with a 20mb CCP mission.
So yeah, also ought to fix adaob I would have thought.
May be a bitch to apply as a fix though- I presume UAC will stop a lot of people from doing anything in the Windows directory?
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.
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.
Last edited by Kolya; 13th Jun 2010 at 14:52.
It's read with 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.
I guess that explains why I could always 'fix' the problem by optimising.
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
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.Originally Posted by Telliamed
Last edited by Kolya; 14th Jun 2010 at 16:39.
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.