barcharcraz

In response to post #55086788. #55131908, #55143333 are all replies on the same post. is it package-able? By that I mean can it build without internet access aganst the distros native packages and without any nonfree plugins or codecs? Also if you do package it for linux consider flatpak, works on all major distros, one click install for gnome and kde users, also quite secure and integrates with namespaces and seLinux.

It's only OK to re-upload abandoned mods if you wait for ~110 years :)

Actually one of the big reasons a lot of programs are still 32-bit is because people who took the upgrade path from 32-bit versions of windows (and perhaps winxp-x64) are still on x32, and many of them don't realize that. For games the 360 and ps3 were both 32-bit so games had to restrict themselves to 32-bit features anyway. Now many programs are switching to x64 only. Office actually has an x64 version btw. My machine is running around 90% x64 programs at the moment. You don't have to alter 32-bit programs to run on a 64-bit OS. Hell all modern x86_64 CPUs will even run old 16-bit real-mode programs if you try hard enough. What you do need is a set of 32-bit libraries.

huh, maybe I was using an old version. I ended up just manually looking through things in radare2, and that has worked pretty well. :smile: edit: and reading lots of code from clang-cl

ClassInformer does not work very well for x64 RTTI. I ended up reading clang's MSVC codegen code. Also IDA is not something I can afford. Also it's not like I'm trying to make my own version of skse. I'm trying to find offsets and send them to the skse team.

I'm actually fairly new to reverse engineering, but I do have quite good c++ layout knowledge and I'm comfortable reading through assembly (as long as it's intel syntax. I almost failed a test back in college because they put a bunch of gnu style assembly on it) I think I'll just decode at least one class and email the new offsets to the team email address. Edit for anyone else attempting to help: the base type descriptor has a pointer to *its* vtbl, not the vtbl of the described type. *facepalm*

I've been using x64dbg. I found the type descriptors for those classes but they are not pointing me to the vtbls, I'm trying to follow the first pointer in the type descriptor though, tonight I'm going to try following it backwards. Edit: nope I'm an idiot and assumed the placeholder pointer at the start of the vtbl was the end of the vtbl Edit2: there's several approaches to verifying offsets but I'm going to go with finding the vtbl then finding instances of said object by finding references to it.

I'll admit that I kinda just wanted to read the code and dive into their hooking mechanisms. But my point was mods won't get ported over if SKSE64 is released without all the features of the original SKSE, and also that F4SE work is not necessarily taking away from SKSE64 work

Yeah you're right. But as many of us said before, its very likely that the more time passes, the less mods will get ported by their creators. That's not really what I meant. If they release it without all functions and data structures decoded many mods won't be able to be ported. Actually why don't I explain how SKSE works very briefly. SKSE's main components are skse_loader and the skse dll. The loader simply takes care of injecting the dll into the game's process and is actually really simple. All it does is create a new process with the executable of the game (which starts paused). It then finds the address of the LoadLibraryA function. Then it allocates some memory in the games address space (which it can do since it launched the process!) and manually writes a function call to LoadLibraryA("skse.dll") into that memory. Then it creates a thread (again in the games process) that starts in the memory it just allocated. Thus the thread runs and loads skse.dll and everything is good to go before the actual game thread starts up. The dll hooks into the game and does a bunch of stuff, the main thing modders notice are the new papyrus functions. These are exposed by hooking the function in the engine that registers all the normal papyrus functions and simply also registering the skse functions. This core functionality is probably done for skse64, after all it's only really a few functions that they need to find, and barring any really strange circumstances their hooking process will work fine for any function. The trouble is that in order to actually *implement* any new functionality SKSE needs to know the exact layout of the game's data in memory. If it gets this wrong then SKSE will end up reading and writing to random unrelated places in the game engine and anything could happen, including save corruption, erasing your disk, or causing nasal demons to erupt from your graphics card. There's a good chance that skyrim64 has added some functionality to the games internal objects, thus changing the order of any function pointers in them. Thus the SKSE team needs to run skyrim under a debugger, break on their hooked functions, and manually examine the game's objects to make sure SKSE's versions of those objects are correct. This involves creative debugging (adding breakpoints and making sure they get hit when expected) as well as actually looking at the code to make sure it more-or-less does what they expect. Now SKSE has MANY more thing exposed than F4SE does, so it's A LOT of work to update everything. Also as they are updating things they may find that an object is the same between both games, in which case they may decide to add that object to F4SE. So I don't think work on F4SE is mutually exclusive with work on SKSE64, but we have to recognize that the functionality we have in SKSE today is the result of years of reverse engineering work, and unless you want a version of SKSE64 that crashes all the time and corrupts your save in extremely "interesting" ways you need to be patient. Again I would love a little bounty board for verifying the layout of skyrim's objects!

It appears he has uploaded his mods to archive.org. Not sure it's really him though

The other thing I think is important to remember is they probably don't want to release a version of SKSE64 that only has a few functions decoded/added. Like people are expecting mods to just start being ported immediately and may be frustrated if that does not happen. With fallout4 they can incrementally release features and mods will start to use them over time. They ALSO probably don't want to get in a situation where some features of SKSE64 are unstable and it creates a cargo cult of thinking SKSE is unstable for years to come.

The problem is that a computer engineer costs ~ $1,000 a week at the low end. And trying to raise money could easily result in a massive community backlash because apparently the idea of getting paid for your work is not something that's that popular in the modding community (which I kinda understand tbh, the legal status of that work is kinda a grey area). Anyway I just wish that people like myself who have some experience mucking about in game engine memory could see a list of things that need doing and do them. That said I understand that the team probably does not want to spend time onboarding, and there are legal issues with really documenting all this stuff. What would be REALLY awesome would be for Bethesda to send behippo a copy of the release mode debug information for SSE, but I doubt that's going to happen.

Also considering that more regular updates would be like "found the address of this function!" and "Oh dear the optimizer messed with us on this one!" I do wish it was open source though, I love doing the kind of programming this kind of thing requires. Anyway I wish the whole team merry times and many wonderful nights in windbg!

As cool as EnB is I really do not like it at all. I find that every single preset has some issue, be it way to strong HDR, stupid high DoF, weird transparency issues, or whatnot. I would recommend RCRN which although not based on EnB (it is based in FXAA PPI) it has many of the same features including some custom shaders. The RCRN team is quite knowledgeable on photographic techniques and color grading and they have aimed for a look that closely matches the real world and not a JJ Abrams movie. RCRN does both summer days and storms well which is something I have not seen anywhere else. Oh don't pay too much attention to the RCRN team's suggested ini tweaks, essentially anything that is not accessible from the default launcher is untested and will probably break something or more likely run very slow. That said you do need float point render targets.

would it be possible to highlight mods in the tracking center when the last download date is before the last upload date, ie there has been an update. I realize that one can do this with greasemonkey but it would make the tracking center so much better.