Findings and uses of lg.ini so far

[Displacer]

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:

[AppCore]
MakeAllCodeWritable

[WinShell]
ShellKind
StrictGDIPalette
GDIOriginX
GDIOriginY
MT
ShowCursor
DisableInactiveBlock
DisableWindowsPrintScreen

[Threading]
Enabled

[Allocator]
UseExternal
Heap
MultiPool
Timings
Debug
DumpUnfreed
MemoryCap

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:
GDIOriginX=0
This will start the editor aligned at the upper left corner of the screen

ShowCursor=1
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

[Nameless Voice]

[WinShell]
DisableWindowsPrintScreen

Unsurprisingly, this disables the Print Screen key while DromEd has focus. Default value is 1.

[Displacer]

Yea, also I'm wondering if MakeAllCodeWritable is something akin to a safe mode, you can look but not alter the map data

[Telliamed]

Yea, also I'm wondering if MakeAllCodeWritable is something akin to a safe mode, you can look but not alter the map data

No. Normally application code is tagged as read-only. For whatever reason, probably having to do with directx tomfoolery, LGS wanted the ability to modify executable code in memory.

I can't think of any usefulness to us.

[WinShell]
MT

Multi-threaded.

[Allocator]
UseExternal
Heap
MultiPool
Timings
Debug
DumpUnfreed
MemoryCap

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).

[Displacer]

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:

[WinShell]
MT (default 0)
DisableInactiveBlock (default 0)
DisableWindowsPrintScreen (default 1)

[Threading]
Enabled (default 1)

[Allocator]
Heap (default 1)
MultiPool (default 1)
Timings (default 0)
Debug (default 2)
DumpUnfreed (default 0)
MemoryCap (default 0)

[Res]
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

[Telliamed]

[Allocator]
MemoryCap (default 0)

Resurrecting this thread to expand on something I should've tested back when this thread was first made. When MemoryCap is not set, Dark will use up to 3/4 of physical memory but no more than 40M!. (And at least 8M.) Some of the problems with huge missions using lots of custom resources are surely the result of memory allocations going past this limit. (like crashing in the inventory panel, right Kolya )

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...

[Allocator]
MemoryCap=2147483647

Remember that LG.INI must be in C:\WINDOWS, not the game directory.

[Kolya]

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.

[Enchantermon]

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?

[Zygoptera]

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?

[Kolya]

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?

That's pretty much the problems I'm expecting when trying to integrate this fix in the SS2Tool. However Telliamed has sent me instructions for a hex-patch of shock2.exe which seems a serviceable solution. Given the chance I would still prefer to put lg.ini into the game dir though.

[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.

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]

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]

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.

[Zygoptera]

I guess that explains why I could always 'fix' the problem by optimising.

[Kolya]

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

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]

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.