Jump to content

MadCat221

Unofficial Patch Project
  • Posts

    212
  • Joined

  • Last visited

Posts posted by MadCat221

  1. the crash seems only apply to synth/combat legendary armors.


     

    Update to the latest official version of the game, as per the instructions on every download page for the mod.That line I quoted is a telltale sign that you are on a pre-CC version of the game, as there are keywords that were added in 1.10 for CC support that had to be reflected in the Unofficial Patch.

  2. If you wish to have an Ebony Blade that can be taken to a grindstone, you can make your own. It's a simple affair in the CK. Start by looking at Constructible Object (COBJ) forms.

    No matter which route is taken, one of the two stances on this issue is going to complain about it. Convincing arguments were made that it didn't belong in USLEEP/USSEP, so it was removed.

  3. I wrote down some notes on my testing of this fix, and posted them to the ticket: https://afktrack.afkmods.com/index.php?a=issues&i=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.

  4. 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?

  5. 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.

     

  6. 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.

  7. 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?

  8. 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.

  9. 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.

  10. 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:

    5rPJP7V.png

    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.

  11. 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.

     

     

    TwBFtdT.png


    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.

     

     

    B5P19ii.png

     

    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.

  12. It seems that the checkbox for "Has Holotape" and possibly also the referred holotape (note?) form is not known to FO4Edit. Simply checking the "Holds Holotape" on the Terminal form and leaving the holotapeblank results in the terminal having an empty holodrive in-game, allowing one to insert things like the arcade games, or text/audio data holotape, or, more importantly for security control terminals, the Total Hack holotapes allowing you to hijack spotlights, turrets, and protectrons linked to the terminals.  I've discovered two security controller terminals so far in my new UFO4P adventures and am expecting more. Can the next version of xEdit have these?

    It seems that "COCT - Count" is the subrecord in question that is the governor for this. It doesn't have an apt descriptor for it though, and doesn't register as an overridden subrecord when "hide no conflict rows" is enabled.

  13. It only needs to be done once as a retro, as the revisions I did should make it stay in place without scriptiness.  The retro just needs to reset to editor position an already havok'd spigot so the separate spigot mesh with a proper static collision setup can stay put.  The problem is that the spigot mesh pointed to miscitem inventory mesh that you can havok about in the gamespace, and the script commands to lock havoky things in place are known to not work as well as they should.

×
×
  • Create New...