Did they turn on compiler optimizations this time around?

Ok so basically the nvidia plugin that has serves us well for so long is basically obsolete at this point. I signed up for the intel plugin, but at this point it doesnt exist to the public. it said they will email me when the beta is available.

As far as the archives go, me personally, i dont really care abuot all that. As long as we have a way to extract the archive (which you have already given us with version 2 of your utility), rebuilding a ba2 texture archive is not really needed since texture replacers generally are just installed as loose data files. The most pressing issue I see for most hobbyist texture modders is going to be a plugin or other method of saving/compressing in the correct format (BC5/BC7), as you described above.

Also, I wonder about using the uncompressed 8/888 A/RGB format with the nvidia plugin.. obviously not everyone will want that option because file size is tremendous, but I used it a lot for 1k normal maps in skyrim to avoid compression artifacts (1k uncompressed normal with no artifacts was better than a 2k compressed normal with artifacts, and both were the same size.. so i regularly used this in my skyrim normal maps)

I need a toggle for aim on this game - please included it!!!! Thanks! I am not playing till i get aim toggle....not that anyone cares cause who am I lol

interesting.. so even with the new switch that ian put in his ba2 extractor, the maps are still not correct? or they just arent being handled correctly by photoshop plugin, etc?

Im pretty sure i tried opening one of the extracted normals in wtv and it didnt even open it at all. Says "Format: Format Unknown" at the bottom of the wtv ui when i try to open one of the washed out normals that were extracted using the -atifourcc command line switch.

So.. not sure how you even got wtv to open them

The latter.... ish. There are no DDS headers in the BA2 for any of the texture files, so Ian's and my tools are making up the header data. I don't think anyone yet knows how their engine expects BC5/7 files to be laid out in the header. There is the option that the FourCC be "DX10", then there is a DDS_HEADER_DXT10 struct appended to the end of the header which contains additional DX10-specific information. Or their engine might also just take a FourCC of "BC5U" and skip the DX10 header.

Anyway, I currently have working code which takes the BC5U DDS out of the BA2 and writes them to an uncompressed format. There are still some issues. I was saving it as DXGI_FORMAT_R8G8B8A8_UNORM which I thought was correct. Oddly, the windows thumbnail previews show it correctly (Red/Green), but Nvidia plugin opens it up as RGB with the R channel black.

Edit: I guess that there are better formats to save to. There is actually auto-detection in the Microsoft DirectXTex code, if I give it no format it tries to figure out what to do. I guess I will try that instead.

Edit2: OK, the auto-detection doesn't work so well.

While I enjoy the whole settlement creation, I find it tedious when, for instance, trying to wall my settlement for defensive purposes. That's why, I'd like a mod where you can design the house you want to build and place that designed building in your settlement.

The engine supports the extended DX10 header - see Textures\Interface\LoadingMenuBG.DDS in the Startup archive. Problem is that most art tools don't. One tool that works very well is actually Visual Studio itself.

Of course they do. Someone has to fix that buggy game. :^)

YAY! Thank you sirs!

^^^^ THIS!! Much love and much hope for keybinding fixes!

Great news to report - we have the first underpinnings of F4SE up and running. And we have proof: http://f4se.silverlock.org/F4SE_Splash.jpg

Next up comes a lot of work decoding classes and porting over internal functionality from previous games. We're off!

In this case, most of the demo is just getting everything working again on an x64 steam-wrapped executable that can now be loaded at an arbitrary address. This changes much more than it sounds like it does, but the wrappers I've built should make most of this transparent from a development perspective, and there's only one case that doesn't have the optimal performance I'd like to have yet (calling a member function).

There is still a lot of work to do: hooking papyrus, hooking scaleform, decoding all of the form classes, etc. I may be waiting for a change in the executable from Bethesda before doing the first two to completion because that change will invalidate a large section of the work.

Please - if you guys can, I would love for you to address the horrendous keybinds that exist. Please mod it so we can use whatever key we wish!
Thank you for putting in this effort into the game.

well this is a real bummer. i am at a loss, especially since we are now getting into things that are above my knowledge. I guess it's sit back and wait to see if someone figures all of this out. Textures are the one thing I expected to be able to modify from the start.. didnt expect there to be all of these drastic changes to format ive grown accustom to using for several bethesda game generations.

Ultimately it seems that we are needing to figure out how the engine handles these textures, what it is expecting to be in the headers, etc. .. and how do you even figure something like that out?? beyond me, lol.

That's good news!!

The problem here is that unlike in previous games, the https://gist.github.com/ianpatt/e8066afe5dd9d8627a30 is embedded in the executable. If you take a look at that link, you can see that QCTakeItem is a separate bind from Activate. Cross-referencing this with Skyrim, the three zeroes near the end of the QCTakeItem line mean that the control can't be rebound. Switching that around doesn't make the control show up in the configuration menu, though. It seems like it would be good to change the "on" condition for that bind to be Activate instead of a fixed key.

However, for some reason that doesn't work. Changing the bind to another key does actually work, but the UI appears to be hardcoded to always display E as the pickup key.

I'm glad people are making progress figuring out where BS hid everything (you know, BS, gamesas - what did you think I meant?), still kind of horrified at how broken the interface is. Way too many contradictions, overlaps, context-sensitive changes...

I'm trying to figure out a way to hotkey multiple keys and multiple functions to make up for it, but it's like trying to flowchart relationships in Hollywood.

Yup, I get it.

I'm okay with the E Key staying where it is because I have a Gaming Mouse where I can allocate the key to the button. (And most of the other keys as well.)
I could probably get used to not using any of the Numpad keys as well - again, this is fine. I could hit RIGHT CTRL for Reloads instead of Numpad 0.

What is driving me insane is primarily happening in Workshop Mode - because WASD have been remapped to the arrow keys, I lose the ability to move around and/or I cannot navigate the workshop menu. (Depending on if I have hacked my keyboard registry or not.)

Long story short, with keyboard registry hacks and a few mouse keybinds, I managed to get the game working with EVERYTHING how I want, bar the workshop mode.

Is it possible to modify the workshop keys?

I'd like add: Even when I change my keyboard registry to assign WASD to the arrow keys, and reverse assign the arrow keys up to WASD - Workshop Menu does not recognise the new directional mappings at all at WASD, even though Windows DOES perfectly fine!

I don't like hearing that. Do you think it has something to do with some kind of Steam anti-cheat functionality BGS used when they compiled? Since this is a single player game, I don't see why they would compile the game to use something like that. Do you think you guys could talk to BGS and see about having them compile it the old way.way.

You guys rock! I can't imagine playing NV without NVSE...!! Thanks for all your amazing work!

This is business as usual. Skyrim was a steam wrapped x86 executable. Fallout 4 is a steam wrapped x64 executable. The move to x64 means that code can be relocated which is an additional complication for us. Previously the x86 exes always loaded at the same addresses. Ian was mostly reporting that we have just barely started the process and we aren't near a release.

Ah thanks, I didn't realize that about x64 code. This will be my first time RE an x64 bit executable (once I can afford the IDA 64bit upgrade).

I wrote a script extender mod that used the plugin functionality to modify the game's actual code while it was running. I was using VirtualProtect() to read and write memory at specific offsets within the game. From reading the VirtualProtect() docs, I can't tell if I can continue to do this, or if you guys are going to need to pass the new random start address to plugins and I'd have to add my offset to that address.

If anyone is desperate to get working on textures, GIMP with the dds plugin opens them both _s and _n just fine. You can save them as another image format in GIMP and open them in Photoshop. From there you can edit and save as 3Dc .dds using the Nivida dds plugin. The red image channel of the _s texture is glossiness (white is most glossy) and the green channel is specular (white is highest specular intensity). Fallout 4 is using physically-based shading/rendering and uses specular/reflectivity as opposed to metalness. Odd that they don't use a coloured specular map and didn't switch to a metalness workflow. Using metalness would have allowed for coloured specular highlights/reflections (think gold, bronze, coloured metallic paint, etc.) while using the same number of textures/image channels.

Awesome! do you think it will include memory block settings like those that helped skyrim so much? The game runs super smoothly for me, when it doesnt crash but I'm guessing my crashes are coming from memory allocation. went looking at fixes for skyrim and was excited to see f4se silverlock org up.