vagonumero12

My tests on this were originally tested on an ActiveMagicEffect, by replacing MagicPlayEffectShaderOnHitScript, it was a quick test to save me from the hassle of making a esp just for the testing. https://pastebin.com/Cv3n7ZAw (stripped all the tests non-related with input). To start, make player use ebony flesh spell. To test the non-registration stuff, uncomment the several TestInput calls (I would test them one by one though). (Anyway, the registration part was also tested with other modified vanilla scripts, a modified WIDeadBodyCleanupScript to test forms registrations, and a modified Da05SindingScript to test Aliases registrations)

Well, there must be something in your setup different to mine, because here it is working. The most weird part is the "GetMappedKey" not working, though. With which params are you calling the function with? And which is the result?

Still, just in case, I would call and print SKSE.GetVersionRelase output to be totally sure that SKSE is there.I would also check the very first lines of papyrus log. If there is a function defined in script but not registered, it should appear there.

HoldKey and TapKey are not registration functions, though, those can't be related with cdcooley issue. What did you test those with? Those in concrete don't work with controllers, and I think tthe hold/tap doesn't work to simulate mouse either (this is the same behavior than in SKSE32, so it is actually the expected behaviour), it can only simulate keyboard. It is too many tested functions that you have that are not working. I would verify your installation and ensure that skse is running (use skse command to verify) and that the skse scripts are actually there. Iirc, the first package had the scripts misplaced.

Can you be more specific and provide how you are testing them? Because those have been tested and they do work. If there is anything special or inusual in your input setup, that could help too (I'm mainly saying this because a fourth input device was added in SE, apparently a virtual keyboard, and not sure if these functions would work with that device). Also, make sure the object where you are registering the events is "alive". Because if it is not attached to anything, or if the script attachment stops (like an activemagiceffect after the effect), the registration will be gone.

I see people going paranoid mode on reddit ahead of time. The change is probably to use 64 bits offsets and say bye-bye to the 2 GB limit. Now we'll have either a limit of 8 exabytes (if they still use signed integers, which imo, is not apropiated for offsets) or 16 exabytes. Ain't that cool?

In response to post #22626059. #22628034, #22636819, #22645084, #22660454, #22668584, #22669169, #22677289, #22683744, #22696394, #22703729, #22706194, #22707434, #22709384, #22711954, #22712964, #22718199, #22719194, #22741749 are all replies on the same post. All ppu elf (self) of ps3 are 64 bits. No exception because the kernel of gameos won't load any other kind of ppc elf. Dont believe me, go do some reverse engeneering on a file called lv2_kernel.elf. Although the 32 bits pointer in user mode thing was probably done for compatibility reasons, so you may be right on that. Still that was an artifice of the official compiler, registers are still 64 bits and you could access 64 bits addresses with asm code (totally useless though since there is no mapped user address beyond 32 bits on the ps3) . However I forgot about spu binaries, those are actually really 32 bits, but it's a different architecture, it can't communicate directly with the os (which runs on the ppu core) but it can pass messages to the ppu side. Not sure if Bethesda would have put that code on the spu. But anyway, if they were able to port the engine to this bizarre dual-architecture machine, x86->x86_64 conversion should be less of a hassle (not to mention that ps3 and x360 were big endian machine, that was probably annoying too when doing those ports).

In response to post #22626059. #22628034, #22636819, #22645084, #22660454, #22668584, #22669169, #22677289, #22683744, #22696394, #22703729, #22706194, #22707434, #22709384, #22711954, #22712964, #22718199 are all replies on the same post. Ehrm... NO. I know for a fact that ps3 binaries are all 64 bits. Although they used a bizarre eabi where the size of pointers were 32 bits, but size of long was 64 bits. iirc. (although that was a compiler thing, pointers were still 64 bits in the cpu side). kernel itself used 64 bits pointers, but it reduced all pointers coming from user mode to 32 bits before operating on those. For new consoles to run 32 binaries, they would need an api translation layer. In PC, thats provided by those wow64*.dll at system32 (one of them is responsable of cpu mode switch, but there is also ones that translates the parameters for nt sys calls from 32 to 64 bits). Although ms could have easily port that, I doubt Sony would bother with making one. On PC, the only reason why that exists is for compatibility. Consoles don't need that, so I doubt they wasted time and resources on something unnecessary.

In response to post #22626059. #22628034, #22636819, #22645084, #22660454, #22668584, #22669169, #22677289, #22683744, #22696394, #22703729, #22706194, #22707434, #22709384, #22711954 are all replies on the same post. Just in case anyone forgot, xbox360 and ps3 have 64 bits processors. Not x86_64 but still, they had to solve problems like data sizes for those already. Besides, they have to make a x86-64 version for the new consoles, so why it wouldn't be 64 bits on pc too?

A guard. One of those guards that know your whole life.

Armor mod? Animation mod? -> Release as loose files, user may want to edit those kind of things. Almost everything else -> use BSA. They are not only bad in speed, but loose files also eat more free space than an uncompressed bsa. Files are aligned to cluster size in the disk. If you have 200,000 files in your Data folder, and a cluster size of 4k, you may be wasting, on average, (4096/2)*200,000 = 390M. It is actually more than that, that's only the waste in data, but the file entries also take space. It may not seem much, but if you have a small hdd like some SSD or not too much free space, it can be annoying.

There is a japanese mod called "Icha Love" that allows kissing (it doesn't have anything extra, just the kiss). It comes with a MCM menu, whose options you will probably have to modify to adjust the kiss. While it is not the best of mods, it does the job, hopefully some day a new mod will appear that makes the scale automatically. And I guess hugging mods and walk by hands are centuries far still, people are not very romantic these days :laugh: Uh, after a search I realized that at least the hug mod exists. Now only one thing left.