PushTheWinButton

I'll probably just forget about Fallout 4. I haven't played it in years and I'm not too interested in the modding scene so I'm unlikely to pick it up again. So mostly I'm just working with Oblivion, New Vegas, and photo editing. My research has turned up the budget option of the HP Pavilion 17". Apparently it maxes out at less than 45 db on full fans, which is similar to my liquid-cooled desktop from 2015. With the white accent instead of the neon green, it also looks fairly acceptable. However, the new HP Omen 15" released a couple of weeks ago is also said to have very good thermal performance, and a 17" version is on the way so I might hold off and see what that brings.

Hi. Hoping someone could point me in a good direction regarding computer hardware and laptops, since I'm not too knowledgeable on it myself and researching this stuff makes me lose the will to live. I'm currently using a gaming desktop + work and personal laptop combo, but I'd like to condense the two down into a gaming laptop which is normal-looking and runs as quiet as possible—both of these points are essential for me. I've been playing and modding everything from Morrowind to Fallout 4 using a liquid-cooled Alienware x51 r3 from 2015 fairly comfortably, but now I'm only really interested in Oblivion and Fallout New Vegas and I doubt I'm going to pick up any new games on PC, since my friends and I are mostly console now. In fact, modding Oblivion/NV is the only reason I use my desktop anymore. I would still like the option to mod up to Fallout 4 occasionally though. I was going to opt for the Alienware m15 or m17 r3 since I've been happy with my current machine, but then I got put off by some reports of loud fan noise and low battery life. It's hard to tell if this is because reviewers always get sent super-high spec models and test the most recent games, whereas I'd get one of the entry-level ones for playing 5+-year old games. I know that machine is obvious overkill too, even at lower specs, so it seems like I'm burning cash unnecessarily. Any other recommendations or experiences to help me out?

So I didn't actually know it was possible to do this kind of thing in NifSkope. You inspired me to have a shot (punssss) at it myself and this is what I came up with. I tried my best to preserve the pointiness and get a spear-type result whilst keeping the textures intact. I also made it a playable resource by replacing the default arrows with the bodkin meshes and distributing them in a 2:1 ratio with broadheads. The "arrowbodkincompact" meshes are for consistency with TIB's Compact Quivers. Feel free to use as you wish or add this to the mod page if you want. https://www.dropbox.com/s/2m3iloifjuyne13/Bodkin%20Resource%20PWB.zip?dl=0

That's brilliant mate! I've just given them a quick try and they work perfectly. The texture might be a tad blurred, but I assume that just a side effect of molding the original arrowhead. It's definitely not an issue in gameplay though.

Hi, Would it be possible for someone with knowledge of modelling to please quickly whip me up a nif model for bodkin steel and iron arrows. Other materials and/or icons would be a bonus, but not needed. My modelling skills are none-existent sadly :'( The vanilla arrows are all broadheads with knife-like tips, whereas bodkin arrows with just a sharpened tip were actually more common in the middle ages. I basically just need the arrowhead replaced with a pointy bit of iron or steel. Using the quivers from TIBs Compact Quivers would be cool to, since they're much better looking than vanilla. Purpose: I want to make a quick dumb mod to flesh out and balance archery a bit. Bodkin arrows will be more common, cheaper, fly faster, and potentially have armour-piercing, whilst broadheads will be more expensive and do more damage. Marksman characters will have to spend some of that coin they're saving on armour repair on the more flashy broadheads if they want to keep up the damage.

EDIT: So I've done some more testing, and arrived at the following: ATT = attack base damage DT = total damage threshold DAM = damage received, e.g. max [ ATT-DT, fMinDamMultiplier * ATT ] COND = condition damage if (DAM > DT) COND = fDamageToArmorPercentage * DT else COND = max [ fDamageToArmorPercentage * (DAM - fMinDamMultiplier * ATT) , 0 ]The armour piece that takes damage is dependent on what limb is hit, which explains why backpacks and accessories don't take damage. The above formula also means that condition damage is completely negated when the damage received is equal to fMinDamMultiplier * ATT, the minimum damage that gets through if DT is high. In other words, a really high DT would mean that your armour won't degrade, as every hit will be reduced to its minimum damage. Also, it looks as though effects ARE factored in. Weird stuff. ORIGINAL POST: I've been doing some testing this morning to try and work out the formula that governs how apparel takes damage. I couldn't find any information anywhere else (though admittedly I didn't look hard), so I thought I'd share my findings here for anyone who's interested, since it's not what I expected. So there's a game setting called fDamageToArmorPercentage, which by default is 0.35. Naturally, I've always assumed this was the percentage of the incoming damage dealt to armour because that seemed logical, and just left it at that. Not so. Turns out, every time you're hit, this is multiplied by your total DT, and then the result of this is subtracted from your armour's current health. I only tested this with torso armour, but I expect it's a similar case for headgear, though notably some slots don't take damage at all, as I've experienced with backpack and accessory-style mods. Note I said total DT. That leads to some strange quirks. It means that equipping a helmet that adds extra DT actually speeds up the rate of your armour degradation, and having no DT at all means your armour doesn't degrade when you're hit. Obviously, this means that the magnitude of incoming damage has no effect on the damage your armour receives—DT is the only thing that determines condition damage and, as long as this is constant, your armour will take constant damage per hit regardless of if your shot by a .44 or nibbled by a rat. This also means that your armour will degrade slower as it takes damage and looses DT. I haven't tested this with effect-added DT, but if it's included in the calculations it would mean that the DT from the OWB perks will also increase the degradation rate of armour. I also haven't tested the effect of DR at all, so that might be worth looking into if anyone wants to explore this further. I don't think this is a very logical formula at all. It reminds me a lot of how weapon degradation worked in Fallout 3, where damage per shot was a multiple of weapon damage. This meant that a sniper and a handgun with the same health would degrade at different rates, making balancing pretty difficult, which is probably why the devs choose to have a flat rate for each shot in NV. An example for armour from NV would be that the Settlers Outfit and Armored Vault 21 Jumpsuit have the same health, but the latter will degrade 4x faster due to it's higher DT. If anyone is interested in a mod idea, it is more than possible to change this behaviour by setting the aforementioned game setting to 0 and using JIP's OnHit event handler and GetHit___ functions to implement a different method, even changing the damage based on hit location and damage type.

 No, No he is not.   He is talking about YOUR patch wanting the files in a different load order   No, No you can not. Xedit locks the load order. You're either thinking of Wrye or are unfamiliar with Xedit.  Oh, and on a side note. Cleaning the master files is NOT needed. I have NEVER cleaned them and I have never had problems for not doing so. I have over 1900 hours playing FONV and have beaten the game at least 15 times, in every way you can think of. Even beat the game as a pure pugilist using nothing more than brass knuckles ( or "Love and Hate" Knuckles from Bitter Springs ) and perks, nothing more fun than taking on 3 deathclaws at once with spiked knuckles and living :D Ugh. Someone has selective reading. I remember why I stopped trying to help people on here... Yes, this is in fact about the PN masters/esps. As you said, Doubious is talking about my file wanting Projects Nevada's files in a different order to what he has already. I don't see what your're misunderstanding there to be honest. And yes, you can change the order of masters in a file's header using FNVEdit - I do it all the time. But whetevs. I quit.

 Um, that's not actually true. The laod order is determined by the mod authors load order when he or she made the patch / mod in the GECK or FNVEdit. If the authors load order was not correct, when the patch / mod was saved, it will save the file with the original mod authors wrong load order. Many times I've had to go through my load order and fix files SOLELY because of this oversight of the original mod author. Also, ANY AND ALL files that are orange in Wrye WILL cause crashes in game.  ... I am the mod author.   ok fine. Then the fact that your mod is asking him to change the load order of his vanilla files is exactly what I was talking about. If the vanilla game files, including all DLC the mod uses, was not in the right order then every person who downloaded your mod is going to have the same problem.  Here is a pic of exactly what I am talking about, below   This is the correct load order installed by steam. Any mod asking the user to change this load order simply needs to have Appendix 1 from my guide applied to it, and then it will be fixed and using the correct load order. This SHOULD also be the same load order LOOT assigns to the files. It'd help if you paid attention to the issue here. Dubious is talking about the PN masters - the vanilla masters are in the order you stated. And I believe you can just right-click on masters in the file header in FNVEdit and move them up and down to where you want them. Even clean the masters if you want. Not all of them are needed but I put them there because I could foresee some conflicts if certain PN files were loaded after the patch (i.e. it's a bit of a failsafe in case people couldn't follow my load order instructions).

Um, that's not actually true. The laod order is determined by the mod authors load order when he or she made the patch / mod in the GECK or FNVEdit. If the authors load order was not correct, when the patch / mod was saved, it will save the file with the original mod authors wrong load order. Many times I've had to go through my load order and fix files SOLELY because of this oversight of the original mod author. Also, ANY AND ALL files that are orange in Wrye WILL cause crashes in game. ... I am the mod author.

The load order of patch file's masters is based solely on how the "Sort Masters" command in FNVEdit chose to order them. I also use MO's built in LOOT ordering to order the PN files, as I cba to manually do it every time I enable PN in MO (I don't use PN myself, so I only enable the files when making patches and disable them again afterwards). So the tl;dr is that there's no reasoning behind the master ordering - I don't believe changing them around will break anything.

I'd suggest placing a marker called MojaveTunnelersREF or something, set to initially disabled, and using the script to enable it. Then just set this marker as the enable parent for all your Tunneller placements. This method means you don't have to enable every spawn individually in the script, and means you can add more spawns at a later date without having to modify the script at all. You could potentially do away with the DoOnce variable too, and simply check GetDisabled on the marker. Your choice. Another way is to simply StopQuest once it's done what's needed - that way it's not running any script at all.

Nope, you're not doing anything wrong (in the first line anyway - the second one is wrong). The function was added by FOSE originally and doesn't work for NV. It's probably something to do with a weapon's ammo being a formlist in NV, as opposed to a single form in FO3.

Yeah, I wasn't thinking any bloat would be major. I mean people cry about globals being inefficient, but considering the vanilla game has hundreds, I don't think a few mod-added ones are a problem. The thing with the leveled list function is: if you add a vanilla item, the change will persist even after your mod is uninstalled, but there's nothing to stop you putting said item in a new leveled list (with a chance none of 0) and then simply adding that new leveled list to the original leveled list. The end result should be the same, and since the new leveled list will be removed along with your mod, the change won't persist.

Just wondering if anyone knows some intricacies behind the GECK's default list addition functions (AddFormToFormList, AddCreatureToLeveledList, AddNPCToLeveledList, and AddItemToLeveledList). What exactly happens when the added objects no longer exist? E.g. if I make a mod which has a new armour item, and I add that armour to a vanilla leveled and form list using the above functions, what will happen when the mod is removed? Are the new list entries automatically deleted when loading a game or is there some lingering effect such as save bloat, etc? I assume that because the additions are permanent, there's also some increase in save size due to it (albeit very small) as the change has to be logged to the save. Does the game automatically delete references to objects that no longer exist or do they remain in some shape or form? And before anyone mentions it, yes I know that FOSE's form list functions are preferable I'm asking out of curiosity mainly. EDIT: also wondering the same in regard to containers.

I had similar script crashes which were hard to pin down when using ModLocalData, too. I find I often need to assign a variable from it beforehand and use that that in any if checks. ModLocalDataExists is particularly prone to crashing as I remember. Strings in general just seem to play up in ifs.