prideslayer

Well barring NVSE support, you could always ask the user for their keyboard layout (qwerty/azerty/dvorak -- this may be in the ini?) and then use UDFs of your own design to translate. Sounds like a pain in the ass though.

The scancode table is standard, there aren't different versions for different countries. A scancode represents the physical position of the key on the keyboard, not the ASCII character printed on the key. So what you're experiencing is normal. An AZERTY keyboard 'A' has the same scancode as a QWERTY keyboard 'Q' -- they are in the same physical location. If you use IsKeyPressed, IsKeyDisabled, or any other NVSE function that takes a scancode as a parameter, then it's the position that matters; 16 always means "Key at the position of 'Q' on a QWERTY keyboard". The functions that RETURN a scancode are thus, always correct. What's incorrect is saying press 'A' because 'A' may be in a different position on different keyboards, as yours is. So what you want to know is what the correct key for code 0x10 (16) is, for any given user. Unfortunately, there's nothing in (FOSE anyway) that does this. The "right" thing to do is add some scancode-to-ascii (and the reverse) functions to NVSE.

Still busy IRL here, sorry. Odessa & Jaam, I've seen the bug reports come in on gitlab and will address them when I can. If this issue isn't reflected there, please submit an issue there as well so I don't lose track of it. ActorX *should* be treated almost identically to any other -- except, IIRC, that actor doesn't have to be available (InUse) since it doesn't need to be locked for the act to proceed. It just needs to be valid. There is *definitely* an issue when it comes to actors leaving the cell before they should. It could be that not locking actorX is allowing the actor to leave the cell before being cleaned up, which means I should probably lock that actor as well.

GetTFC? Yay! Sorry for delays again people. Got busy.. then yesterday 500 errors.. now today, LL has forgotten all my thread 'positions' again (all threads are 'unread'). Playing catch up.

No. That's pretty stupid, isn't it. I'll see what I can do later today, should be simple.

It should be safe to call every frame. Internally it calls fnSexoutActorValid and fnSexoutGetFlag. The first checks some simple things like that the ref is valid and stuff, the second just gets an NX var.

If you ever validate the install, you can say goodbye to just about everything. Don't do that unless you have to.

The fallout launcher runs whenever you DON'T have steam already running before you start, or (sometimes) if steam has updated itself between runs. The next time you run FOMM it will run normally, no need to manually edit INI files. Also, there is no difference between running the game that way or not; it's not like the mods aren't going to be active or something. Just don't mess around with mod activation and such from within the launcher options menu.

There is no "enabled" or "disabled" for lists. Likely what's happening is when the DLC starts up, it clears the list and then refills it. If you modify it before this, your modifications are lost. Right click one of the lists in the GECK with your full load order active and search for usage, you may find a script clearing it out and can then come up with a way to ensure your script doesn't run until after that one via a quest var it sets or something.

Sure. To save money. The drives are more prone to failure as they get older, I don't disagree with that, but when you say "most" won't last much beyond their warranty, you are wrong. MOST will last beyond their warranty, with a good margin.

Not sure what else they're for besides.. storage.. and backup..

HDDs are not as fragile as you might think just because they have moving parts. It's not 1998. Dropping it is unlikely to damage a modern laptop drive, even while running -- most of them have 'free fall' detection sensors in them now that automatically park the heads before impact. The SSDs are not as "strong" as you might think either. Plenty of things inside can break if it's dropped or smacked hard enough. In fact, the maximum non-operating shock limit for an SSD and an HDD are nearly identical. When operating, it's vibration that is more likely to cause problems -- and the limits on SSDs and HDDs are again, nearly identical, both operating and non-operating.

I'm not sure what sort of tutorial you'd want? 1. Pick drives based on your capacity, price, speed needs. 2. Pick a raid level based on your reliability vs. space needs. 3. Leave the stripe size alone. Done. My recommendation: Always and only, RAID-10 (barring expensive SAN technologies), or RAID-0 if you keep great backups and don't mind reinstalling if a drive goes bad -- and keep a replacement on hand so you don't have to wait. Avoid RAID-5 at all costs. It seems like a good tradeoff at first when comparing (read) speed, reliabilty, and space. The problem is, when a RAID-5 goes degraded (drive failure), a lot more stress is put on the other drives in the array. Performance is terrible and gets worse when rebuilding. Rebuilding adds even more stress to the other drives, raising the chances of failure. Something like 60 or 70% of complete RAID failures occur during rebuild, when one of the OTHER drives fails. RAID-10 is the only consumer available level that mostly mitigates the problem.

Thanks for your concern.

Some day. Not any time soon. HDD technology is not as stagnant as you seem to think it is, and the big players like Seagate and IBM introduce "revolutionary" new technologies at an astonishing pace. HAMR and other technologies are "coming soon" for HDDs. By the time SSDs get anywhere close to current HDDs in $/GB, the next generation of HDDs will probably be here -- bringing 20TB or more per drive for roughly the same price as current 2T drives. By the time they do catch up, something will likely replace them both. NAND Flash is not a viable long term solution.

990FX uses SB950 southbridge. It shouldn't have a problem with large drives. The built in windows softraid (or any OS like BSD or linux, or OS agnostic like ZFS) will be much faster than any hardware RAID. Problem there is just no battery backup and difficult recovery, neither of which appeals to me. Like it or not, your CPU is a lot faster than the one on even a dedicated RAID controller. I don't really like onboard raid myself. When I retired my own SCSI drives I switched to the onboard to save a few bucks, and that decision came back to haunt me, so I ponied up for a nice Areca.

Maybe it's nitpicking, but one order of magnitude = 10x faster. Two orders of magnitude = 100x faster. SSDs are not 10x, 100x, or 1000x faster than hdds at anything meaningful. Twice as fast as a single HDD? Sure, but they also cost about four times as much per GB.

Nude males are overridden during sex using a bodysuit built into SexoutNG. Females are never overridden, and nude males not having sex are not affected either.

A fair point, but if you're going to bring "most people" into this, most people: - have a laptop and/or tablet, not a desktop. - don't know the difference between an SSD and HDD to begin with and will buy whatever is cheapest. - could care less about the performance even if they did know about it. Gamers and other types who do care about that stuff and know the difference are better served by RAID IMHO. SSDs are fast, but that comes at a cost in reliability (vs RAID -- not vs single HDDs) and space.

The Samsung SSDs with the 10 year warranty also have a 150TBW (150TB written) limit -- whichever comes sooner, just worth pointing out. 500M/s is, give or take, the SATA 6Gb/s limit. No single SSD is going to get the sequential read values a good 4 disk RAID-10 can get, or the write speeds of a 6 disk RAID-10 or 4 disk RAID-0. Single SATA channel just isn't capable of it, until SATA express is more widespread. Most enterprise HDD warranties are only 5 years, but no limit on data volume read or written. Setting up the RAID is easy, just take it slow and follow the golden rule: don't "mess" with non-default settings like cache modes and stripe size without a good reason.

2TB HDDs are under $100, while 1TB SSDs are nearly $500 and 512G SSDs that are competitive on performance are about $300. The SSDs are faster, but not by "orders of magnitude". All of the current performance SSDs are roughly the same at sustained read/write speads, about 500M/s on both. My primary raid volume, on a 4x 1GB RAID-10, writes at about 300M/s and reads at over 700M/s; it's more reliable overall (RAID), has twice the usable space, and cost the same as a 512G SSD. I'm sure the SSDs are faster in random read/write but I haven't tested to know by how much. On a workstation/desktop most activity is "read up this entire file" or "write this stream to a file" which is entirely sequential anyway. Now, a RAID of SSDs would be great, but that just costs too much.

No, that's not right. You must always use eval if any of the things you're comparing with if are not native GECK types -- unless you use the compiler override. You must use let instead of set for assigning NVSE types like string vars and arrays. The bottom line is this: If you're doing something with a variable type introduced by NVSE, you must use functions provided by NVSE -- or the compiler override.

The fomod installs many old versions (back to .62) under data/SexoutNGBackups. Note that going back to .82 might fix that problem, but will cause a bunch of others with newer sexout mods that require 85+

Well I replied above about the problems it would cause with CBPack, but this concern isn't really valid. Sexout already goes apeshit on the packages and always has, with SexoutDoNothing. It tries to save the current package before it does that stuff but right now, I have a feeling I might have missed that in a few spots. Not entirely certain.

An alternative, one that just came to mind for the curious, is to use a travel package instead (e.g. CBPackA instead of CBDialogA), and issue the startconversation yourself on package completion. You can get the conversation topic from a quest or NX var, so it could be dynamic -- not requiring a different package for every topic the way a dialogue package would. The CBPack stuff is NOT heavily tested, since AFAIK nobody has actually used it yet. If it doesn't work right just let me know, if anything, the SexoutDoNothing package might accidentally be getting added after the CBPack, given all the changes in sexout recently.