MadCat221

Goodbye fair AFKMods Chat... I am sorry I broke you that one time.

I wrote down some notes on my testing of this fix, and posted them to the ticket: https://bugtracker.iguanadons.net/index.php?do=details&task_id=22322 I'm guessing the maker of the mod you're using didn't try reloading while equipped after adding perks or something, because I stripped out all the fusion core perks and then just re-added Nuclear Physicist 1. Like before, it stayed at 500, but reloading put it to 625 (25% of 500 as per the perk description) without putting any partially used core back in my inventory. I'll pick apart the perks in the CK and the bobblehead addition method to make sure something's not baked in from adding. I also shot it a bit, 24 shots. 601/625 = 0.9616, and 96% charge remaining was what the removed core reported when back in my inventory. I think it's working fine, barring my finding something out in the picking-apart. EDIT: After reading the description on that mod some more, I went back and found an ancient save before I ever got the Repair bobblehead. I added all three perks in, and there was no problem with it going all the way to 999 on the counter without the Repair bobblehead perk present.

The bug fix is simple: boost the lasergat's ammo capacity to what Repair+Nuclear Physicist x3 would make it... 1100. Without them, the charge will still be 500. With partial perkage regarding fusion core power draw, it works accordingly. Reloading produces the proper partial charge left in the core. Only buggy bit is acquiring one of those perks while you have a LaserGat equipped, but even then it's not a big deal because reloading does not affect charge percentage of the removed core re-deposited in inventory. I learned of this fix from this mod: http://www.nexusmods.com/fallout4/mods/14689?

So seven times out of eight having no rares, and then suddenly one time out of eight having a whole slew of rares is correct? I'm not really believing that's intended. That's unlike any vendor inventory behavior I've seen in previous BGS games.

There are actually two points to enter a Chance None, and I think their behavior differs (much like conditions on MGEF and SPEL forms). I think that Chance None on the form itself is rolled for every count in a superior list's entry to it, while Chance None in the superior list's entries rolls for all-or-nothing. That's how Sclero is seeing the behavior he saw that piqued his suspicion of an oversight bug. The weapons merchant list in the group was set up with the Chance None >0 value being on the sublists' forms, instead of in the superior list's entry referral to the sublists. That one seemed to be the only one set up that way. Not to be taken as empirical, but it always seemed to me that the weapons merchants seemed a bit better-stocked than most of the others.

Time to do potential hardware correlations here too: Gameboy and Kesta, what is your video card? Mine is an Powercolor Radeon R7 370 with 4GB 256b GDDR5 RAM. I heard that even nVidia cards get it too, though, and people suspect it's a problem with the game itself.

That is a possibility. Have you tried BA2 archiving everything to see if the problem disappears? I am not barebones on mods, but not hugely over-modded yet, and I am contemplating total BA2 archiving of all loose textures to see if that solves the rainbow mipmap corruption. Be sure to configure the Archive2 utility correctly to pack them as BA2 texture archives. It alternately manifests as the wrong texture's mipmap, and on mesh bits with transparency, by disappearing at non-max mipmap levels.

I have a few inquiries about precombined meshes in FO4. I recently just successfully fixed a positional issue via directly altering a precomb mesh in NIFSkope, circumventing the problem of disabling precombines in that cell when doing so (here). I am now searching for some way to more reliably correlate a precomb BSTriShape to the object it represents. To find the precomb nif in the first place, you have to get the RefID and then use FO4Edit to get its formID; [REFR:00066BCA] (places BillboardWilsonAtomatoys01 [STAT:00178BC7] in GRUP Cell Temporary Children of AtomatoysFactoryExt04 [CELL:0000E2C6] (in Commonwealth "Commonwealth" [WRLD:0000003C] at 4,-22) in Precombined\0000E2C6_3BB2127F_OC.nif) I am wondering... could any of the unknown ints in the BSPackedCombinedSharedGeomDataExtra be a FormID? I tried converting the hexidecimal integers in the bit above to just Decimal to see if I could match up any unknown ints, but nothing. What are these VF1 VF2 etc etc things? Could they be some means to identify?

I just found a third security controller terminal without a holodrive; the sergeant's in the BADTFL office. This time, I corrected it via de-nulling that COCT subrecord to 0 in FO4Edit, going around the CK entirely. Its attached turret was responsive to alterations made with the Total Hack turret tape.

It appears that those two unknown flags are ultimately irrelevant to the holodrive. I unflagged those two on the Curator terminal in the Boston Public Library while still leaving that COCT at 0 (not null) and it still accepted holotapes. The Total Hack Turret holotape still functioned on its attached turrets too; scrambling the turrets' targeting parameters causes them to shoot each other. The existing unaltered terminal in Sanctuary Hills that had COCT = non-null 0 and never had Unk 4 and 13 ticked also accepted holotapes. No turrets to test since it's just a chem dealer's log, but the game holotapes work in it. The CK tagging those flags could just be extraneous stuff.

I was tasked with killing some thug murderer and a crooked chem dealer before getting to Kendra. Are you listening to the radio while inside Goodneighbor's boundaries?

The COCT field is actually an item entry count. The grayed out subrecord right beneath it is "Item", and gives a form record reference and item count to a holotape when the COCT reads 1. Here's the Vault 111 rec terminal that I used as a "has loaded holodrive" reference: It too has Unknown 4 and Unknown 13 tagged in the header subrecord. I randomly clicked around, however, and found a terminal that has COCT = 0 (and not null) and it did not have Unknown header flags 4 and 13 tagged. I'll check in-game to see if it has a holodrive.

I am really sure. Here's some screenshots: In the CK, it is clearly a checkbox. Leaving the dropdown blank results in an empty holodrive (as opposed to no holodrive) I analyzed other terminals to make sure that's how it's supposed to be. The screenshot reflects my alteration to that terminal to enable the Total Hack tapes to be used on the turrets and protectrons attached to it. In FO4Edit, it goes from null to 0. On computers with a drive and a holotape in it, it is a 1 and has the item ref info listed below it. Additionally, Unknown 4 and Unknown 13 were flagged in the override record's header subrecord. The second terminal I altered already had those flagged in Fallout4.esm.