St. Jimmy 272 Posted January 15, 2015 The UseLargePages is the flag. So change to 0, restart, change back to 1, restart and it should work again? Change something else in the flag? Change to what? Delete old and make new that's exactly the same? Running the LPManager privilege again and restart? :confused: Share this post Link to post Share on other sites
Greenfist 1863 Posted January 15, 2015 So change to 0, restart, change back to 1, restart and it should work again? Change something else in the flag? Change to what? Delete old and make new that's exactly the same? Running the LPManager privilege again and restart? :confused: Change the registry value (= a flag) to 0 and start the game. Apparently restarting is not needed, the value is read when the game starts. Share this post Link to post Share on other sites
Dwarden 1124 Posted January 15, 2015 NTheaders OptionalHader DLLcharacteristic DLLcanMove must be disabled the game engine is built with it enabled by default so it will always crash Share this post Link to post Share on other sites
neodammerung 8 Posted January 15, 2015 So if I understand this tweak doesn't work anymore because it's now part of arma 3 exe ? Share this post Link to post Share on other sites
nikiforos 450 Posted January 15, 2015 If someone can explain exactly what to do but the easy way:) Step for step , it would be great for people not having a clue about what Dwarden is talking about. The part Greenfist wrote is easy but not the last post :) Share this post Link to post Share on other sites
Greenfist 1863 Posted January 15, 2015 (edited) I think Dwarden meant editing the game executable, like mentioned in the first post. Or is just for arma3server.exe? We shouldn't be messing with the client executable, right? Edited January 15, 2015 by Greenfist Share this post Link to post Share on other sites
St. Jimmy 272 Posted January 15, 2015 (edited) If someone can explain exactly what to do but the easy way:) Step for step , it would be great for people not having a clue about what Dwarden is talking about. The part Greenfist wrote is easy but not the last post :) I guess the registry edit part isn't needed anymore and the engine already does it by itself. So you should edit the registry from 1 back to 0 or delete it. At least I'm getting LPs even when it's 0 and after deleting the DWORD. For the more experienced users, you can do the required changes manuallly too, by: 1. use regedit to create/set DWORD value 'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3.exe] (or just merge GMF_on.reg from github repository) Just reverse that. Edited January 15, 2015 by St. Jimmy Share this post Link to post Share on other sites
insumsnoy 4 Posted January 15, 2015 Arma III boots fine now, thanks Jimmy. Share this post Link to post Share on other sites
Dwarden 1124 Posted January 16, 2015 it's binary flag which needs to be set either by freds41 tool or by e.g. CFF explorer ... w/o such change it always crash Share this post Link to post Share on other sites
nikiforos 450 Posted January 16, 2015 What did you guys change in the engine ? I mean it worked before without any problems . Is this just an issue for Dev Branch or will this be implemented to the next Stable Branch release? Share this post Link to post Share on other sites
St. Jimmy 272 Posted January 16, 2015 it's binary flag which needs to be set either by freds41 tool or by e.g. CFF explorer ... w/o such change it always crash I'm now asking again just in case. This is about client only not server. So setting 'UseLargePages' = 0 is now right thing to do so there won't be any crashes? Because as 1 it crashes and as 0 (or the whole DWORD deleted) everything works fine. Or is there some other wizardy we should do to get everything out of the tweak in the current dev branch? Share this post Link to post Share on other sites
Dwarden 1124 Posted January 17, 2015 (edited) if you use the 'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3.exe] or 'UseLargePages' = 1, for key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3server.exe] under Windows 7 or 2008/2008r2 server then you need change flag e.g using program CFFexplorer http://www.ntcore.com/exsuite.php NTheaders - OptionalHader -- DLLcharacteristic --- DLLcanMove must be disabled as the game engine is built with it enabled by default so it will always crash this was and is ALWAYS known issue on server (that's why fred41 has the tool to switch the flag and always mentioned it) note: do NOT use this on 1.38 client nor server , it changes way the engine work with memory and unforeseen consequences Edited January 23, 2015 by Dwarden Share this post Link to post Share on other sites
fred41 42 Posted January 18, 2015 ... this are no good news ... The problem is most likely caused by a changed compiler/linker setting for 'arma3.exe' client build in dev branch. For BI devs, this is namely the linker setting /DYNAMICBASE (was always /DYNAMICBASE:NO for arma client). Linker setting /DYNAMICBASE:yes (or /DYNAMICBASE), together with IFEO 'UseLargePages=1' for 'arma3.exe' will crash at start. Patching the clients (arma3.exe) fileheader later (via CFF Explorer) is most likely not a good option, because of anti-cheat? Maybe a BI developer, familiar with the client building process, can tell us what settings we have to expect in the next stable build? Share this post Link to post Share on other sites
orcinus 121 Posted January 18, 2015 I admit to understanding little or nothing about what the file header patching is about. I am concerned about what it means; when Fred41 started the thread on using large pages, I tried it and found no difference, Investigation showed that a demanding proprietary program from a client had set that already. I use that program for certain consultancy projects and I don't want to have to keep changing settings. I only use the stable releases. IMO these should not contain code that affect the basic operation of users' machines and potentially hamper or even break other applications. If I've completely misunderstood what this is about, not really surprising as I would guess that many players would be equally clueless about such as: "NTheaders - OptionalHader -- DLLcharacteristic --- DLLcanMove" Orc Share this post Link to post Share on other sites
Dwarden 1124 Posted January 18, 2015 well my point is that the tweak never worked w/o the flag being changed (at least for me) ... i always needed 3rd party app to change it before starting game client or server binary Windows 7/ Windows 2008/2008r2 server ofc I will check with the programmers and building pipeline guys if we can do something about those flags Share this post Link to post Share on other sites
dazhbog 10 Posted January 19, 2015 ... this are no good news ...The problem is most likely caused by a changed compiler/linker setting for 'arma3.exe' client build in dev branch. For BI devs, this is namely the linker setting /DYNAMICBASE (was always /DYNAMICBASE:NO for arma client). Not true, we have always used /DYNAMICBASE for Arma 3. The thing that has changed recently is that we have switched to a newer Steam protection mechanism as the one we have used previously is now obsolete and stops working randomly. ---------- Post added at 07:37 ---------- Previous post was at 07:36 ---------- I only use the stable releases. IMO these should not contain code that affect the basic operation of users' machines and potentially hamper or even break other applications. Are you suggesting that Arma 3 affects your machine operation or breaks other applications? Share this post Link to post Share on other sites
nikiforos 450 Posted January 19, 2015 (edited) Can I as a casual player continue to use this tweak or am I doomed to lower performance because of the recent change you made? To be honest the only reason I started to play Arma 3 again was because of this tweak and tbbmalloc allocator because I was able to enjoy playing again with OK performance. If this is not possible any more then I might consider to stop playing again. Or a solution might be that I never update my game to 1.38. Edited January 19, 2015 by Nikiforos Share this post Link to post Share on other sites
orcinus 121 Posted January 19, 2015 Are you suggesting that Arma 3 affects your machine operation or breaks other applications? No, I'm asking for a simple explanation of what the phrases I quoted mean in terms of machine function. My machine is set to use large pages by default (otherwise a program I can't discuss will not function correctly or will likely crash with a large data set). If a forthcoming stable release includes code that messes with that setting or requires it to be switched off before running the game then I need to know about it. Share this post Link to post Share on other sites
Greenfist 1863 Posted January 19, 2015 No, I'm asking for a simple explanation of what the phrases I quoted mean in terms of machine function. My machine is set to use large pages by default (otherwise a program I can't discuss will not function correctly or will likely crash with a large data set). If a forthcoming stable release includes code that messes with that setting or requires it to be switched off before running the game then I need to know about it. The LP setting only applies to arma3.exe, right? It's not global to your machine. Share this post Link to post Share on other sites
fred41 42 Posted January 19, 2015 Not true, we have always used /DYNAMICBASE for Arma 3. The thing that has changed recently is that we have switched to a newer Steam protection mechanism as the one we have used previously is now obsolete and stops working randomly. @dashbog, look: a application linked with /DYNAMICBASE, would always be mapped at a random place in processes virtual address space (ASLR). This is not the case with current stable 1.36 (and was most likely not, since alpha in stable and dev branch for arma client). Simple proofs: 1. if you start arma3.exe 1.36 stable (without any patching or tweaking) and you check its mapping address (via VMMap, sysinternals), you will find it ALWAYS be mapped at the same address (0x400000) (-> /DYNAMICBASE:NO). 2. if you open arma3.exe with CFF explorer (explorer suite), you will find in 'NT Headers'->'Optional Header'->'DllCharacteristics' a value of 0x8100, what implies a fixed mapping address is prefered instead of ASLR. 3. GMF tweak would not work for current stable arma 3 client without fileheader patching, but it still does ... Share this post Link to post Share on other sites
DGeorge85 10 Posted January 20, 2015 (edited) I'm extremely late to the party here, and after some reading I wasn't 100% certain where this tweak stood with the current stable version, but I decided to give it a try along with the updated allocator. After using the Altis Benchmark (v0.60) I'm happy to report a jump from 58 to 67fps. I didn't really notice the frame increase on the top end, but where I did notice it was at the points of the benchmark that would stutter or tank my frame rate for a split second, which really makes a big difference. Thanks for this! Edit: I set up a small test battle on Altis including 4 tanks and about 20 AI, everything is running great but my Task Manager reports a RAM usage of only ~255MB for Arma which I though was very strange. Before the tweaks Arma typically used 1.6-1.8GB. I confirmed that everything is working in the malloc_xxxx.log so now I'm wondering, is there a version of the allocator somewhere that does not create logs? Edited January 20, 2015 by DGeorge85 Share this post Link to post Share on other sites
nikiforos 450 Posted January 20, 2015 Well be happy now because this is going to change with the next stable update! Share this post Link to post Share on other sites
DGeorge85 10 Posted January 20, 2015 Well be happy now because this is going to change with the next stable update! Why is that? Are they removing the ability to map Arma to large pages? Share this post Link to post Share on other sites
nikiforos 450 Posted January 20, 2015 (edited) Please read the last two pages so you can get the full picture. Personally I'm getting tired of all these changes for the "better". One step forward and two steps back:( Edited January 20, 2015 by Nikiforos Share this post Link to post Share on other sites
DGeorge85 10 Posted January 20, 2015 Please read the last two pages so you can get the full picture. Personally I'm getting tired of all these changes for the "better".One step forward and two steps back:( Well, I'm not sure I get what you are worried about thus far. The most notable piece I saw in the recent pages was this: I'm getting LPs even when it's 0 and after deleting the DWORD. In other words, Arma is automatically using large pages on his machine. I'm not sure there is any explanation for that other than BI is implementing this into future builds, but again, I'm not sure what you are worried about. Share this post Link to post Share on other sites