Widescreen Gaming Forum

By the way, you're right that Win7, 8, and 10 use differing methods of allocating the process memory space. Usually it's an attempt to make the naughtier forms of code injection more difficult. I actually just tried diddling with the mitigation bits for this app. I could make it slightly random, but ...

I'll have to look into it, looks like a bug on my side - altho I really have to ask, haha, why the hell are you still running Windows 7.

Two reasons:

1) I worked at MS while 8.0 was in development. Everyone had to use it. What I developed was a hatred for 8.0. 8.1 was better, but at that point I ...

keep in mind 64bit is heavily reliant on relative addressing... perhaps I'm wrong, but you need to confirm the actual memory region that the executable is living in.

Fair enough. Luckily, I can do that. I attached visual studio to the process and here's the useful bit of the modules window ...

Maybe this is a dumb question, but am I receiving a 64-bit executable from Steam due to being on a 64-bit OS, but a person on win32 would receive a different executable that would be inherently more compatible with FWS?

I'm still not seeing how printf is broken. My and your printfs both show 64-bit numbers. I've aligned the numbers and separated words for clarity:


c_HackTool -> JMP candidate for ObjectAspectFix_cc, NOPS=1, Address=0x 1 401a 6298
vs
c_HackTool -> JMP candidate for ObjectAspectFix_cc, NOPS=1 ...

Well running it locally you can clearly see the problem.
...
Pay attention to the bottom - your OS is behaving like it's 32bit, printf is atleast.

Not actually seeing what you're seeing. Mine prints 64-bit values just fine, it's just that there are only nine hex digits in the values, vs your ...

Waitaminute.

http://i.imgur.com/4UlopMt.png

c_HackTool -> JMP candidate for ObjectAspectFix_cc, NOPS=1, Address=0x 1 401a6298

Where's the leading '1' I would have expected on the base address shown in the screenshot? Is this physical vs. virtual, or did the upper 32 bits get ...

It's just named that because you can circumvent the unnecessary launcher by swapping their names around. And no, doing it the right way around doesn't make any difference.

^ Slightly inaccurate. Same results, almost the same numbers. The base address goes to 0x3FCC0000 when I run the standard way ...

What's the base address of the executable as per the main window (not debug window, it's not provided) - screenshot it probably is easiest.

Ah, I didn't notice that, sorry. Here you go:

http://i.imgur.com/LdAiIH1.png
http://i.imgur.com/LdAiIH1.png

And what ...

BTW, this could possibly be due to having the machine set up for development as well. It could be something like windows debug symbols getting loaded up with the executable or something like that, though I'm pretty sure that only happens when a debugger is attached. Still, could be something like ...

Oops, missed this:

Can you paste the relevant base address ( which is shown in the main window ) and the allocation address along with the error - did you identify which function or codecave block this is in the Lua file?

Yeah. Here's the debug console spew from a run I just did ...

If you use a register or other mechanism that can reference or represent a true 64bit value then you can jmp across the entire address space, the problem with this is one is trying not to dirty any registers.

Not sure if you saw this, as I edited it in around the time you were probably writing ...

Could also be that your codecave and the patched executable section are more than ±2GB from each other, so even a 32-bit relative jump won't do.
Yup, there it is. The original code is circa 0x140000000 and your codecave is at 0x1c7750000. Delta is 0x87750000, which is outside the ±0x80000000 range ...

I have no idea why this would be happening in a 32-bit app, unless it's talking about the physical address. I do have a boatload of ram in this box, so stuff easily gets loaded above 4GB in physical address terms.
Could also be that your codecave and the patched executable section are more than ...

That's an interesting problem - it suggests the code is different in some way (ie fallout4.exe)

Have you tried launching without Nexus Mod Manager? (I'm not entirely sure how it interacts with the executable)

Yeah, sorry, I meant to say that yes, it does the same thing without NMM.

I'm assuming ...

If you wish to try it, I would strongly recommend you return any modified UI flash files back to their defaults, and any INI edits relating to the HUD to default initially.


Hey HaYDeN, thanks for getting this working.

Alas, the UI fix is not working for me. FoV mod works, just not the UI.

It's ...

While I'm here...

I use SLI'ed 2GB GTX 680's on my system. I was looking at the diagnostics while in high-stutter areas and realized the game was pegging my vram full-time, sitting at about 2,010MiB allocated almost all the time.

Presumably it was thrashing ram<-->vram, like regular virtual memory ...

Heads up: I posted a solution to unintended wallhacking with extra-wide displays here:

m

The important part says to merge two revised near clip values into Fallout4.ini. Here's the same ini snippet from the referenced post, but with numbers that would probably work better for 21:9.

&#91;Display ...

Hey guys, regarding the unintended wallhacking you get with surround resolutions (and, at least on my box, the glaring white background that often shows through and blinds me)... I have a fix.

Merge this into Fallout4.ini:

&#91;Display&#93;
fNear1stPersonDistance=0&#46;4
fNearDistance=6&#46;0000 ...

There's also heavy pixelation with volumetric lighting that I also can't find the source of. Is affected by godray quality and turns into blurry aliasing at higher quality.

Volumetric lighting is often computed at a lower resolution than the background visuals, since it's typically A) quite ...