TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 16 of 16

Thread: Findings and uses of lg.ini so far

  1. #1
    Member
    Registered: Dec 2006
    Location: Edge of Reality

    Findings and uses of lg.ini so far

    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

  2. #2
    Member
    Registered: Mar 2001
    Location: Ireland
    Quote Originally Posted by Displacer View Post
    [WinShell]
    DisableWindowsPrintScreen
    Unsurprisingly, this disables the Print Screen key while DromEd has focus. Default value is 1.

  3. #3
    Member
    Registered: Dec 2006
    Location: Edge of Reality
    Yea, also I'm wondering if MakeAllCodeWritable is something akin to a safe mode, you can look but not alter the map data

  4. #4
    Member
    Registered: Aug 2001
    Location: Virginia, USA
    Quote Originally Posted by Displacer View Post
    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).

  5. #5
    Member
    Registered: Dec 2006
    Location: Edge of Reality
    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

  6. #6
    Member
    Registered: Aug 2001
    Location: Virginia, USA
    Quote Originally Posted by Displacer View Post
    [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...
    Code:
    [Allocator]
    MemoryCap=2147483647
    Remember that LG.INI must be in C:\WINDOWS, not the game directory.

  7. #7
    Member
    Registered: Sep 2002
    Location: LTSI
    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.

  8. #8
    Member
    Registered: Jun 2003
    Location: In His hands
    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?

  9. #9
    Member
    Registered: Apr 2001
    Location: New Zealand
    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?

  10. #10
    Member
    Registered: Sep 2002
    Location: LTSI
    Quote Originally Posted by Zygoptera View Post
    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.

  11. #11
    Member
    Registered: Mar 2001
    Location: Ireland
    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.

  12. #12
    Member
    Registered: Sep 2002
    Location: LTSI
    Quote Originally Posted by Nameless Voice View Post
    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.
    Last edited by Kolya; 13th Jun 2010 at 13:52.

  13. #13
    Member
    Registered: Aug 2001
    Location: Virginia, USA
    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.

  14. #14
    Member
    Registered: Apr 2001
    Location: New Zealand
    I guess that explains why I could always 'fix' the problem by optimising.

  15. #15
    Member
    Registered: Sep 2002
    Location: LTSI
    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 Originally 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.
    Last edited by Kolya; 14th Jun 2010 at 15:39.

  16. #16
    Member
    Registered: Aug 2001
    Location: Virginia, USA
    Quote Originally Posted by Kolya View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •