Jump to content

IDontEvenKnow

Premium Member
  • Posts

    24
  • Joined

  • Last visited

Nexus Mods Profile

About IDontEvenKnow

Profile Fields

  • Country
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

IDontEvenKnow's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Oh. Oh. Here's how to fix this: Open the consoleSelect the PA framerun this command: cf setlinkedref none workshopitemkeywordCrafting should start working as expected. Turns out that if you move a PA frame using the workshop system, it'll link the PA frame to that workshop, rather than the nothing it's supposed to be linked to. This can be caused by something like Movable Power Armor, but there are probably other mods out there that'll do it. Anyway, if the PA frame is linked to a workshop, the crafting system will look for resources from that workshop, rather than from the PA station/local workshop that it's supposed to. Most of the time you won't notice, but if you end up accidentally linking it to a workshop outside of your supply line network, crafting will appear to be broken. Manually clearing the link with the console command I wrote above will fix the frame, until you move it again anyway.
  2. If you're referring to the vanilla/Nuka World ammo types, .308 Winchester and 7.62x39mm aren't at all related, realistically. The easiest way to accomplish this would probably be to write a script that converts the ammo in your inventory instead, i.e. int diff = (PlayerRef.GetItemCount(Ammo308Caliber) - PlayerRef.GetItemCount(Ammo762)) / 2 if (diff > 0) PlayerRef.RemoveItem(Ammo308Caliber, diff) PlayerRef.AddItem(Ammo762, diff) else diff = -diff PlayerRef.RemoveItem(Ammo762, diff) PlayerRef.AddItem(Ammo308Caliber, diff) endifto just average the amount of both you're carrying out, which would work fine until you get very low on the ammo anyway. If you really want to go down the complicated route, take a look at https://forums.nexusmods.com/index.php?/topic/8844713-attatch-omod-to-equipped-weapon/&do=findComment&comment=83497518 and maybe https://www.nexusmods.com/fallout4/mods/24225/? The first of which is relatively straightforward to reverse engineer and/or tweak, and shows a basic method of attaching arbitrary mods to the currently equipped weapon. The second is a more fully-fledged (and many times more complex) implementation that changes the mods of equipped weapons based on their keywords/base ammo type, usually automatically, triggered by animation events. Most of the relevant code is in idek:gac:WeaponControlScript, and you can find examples of most of the sort of things you'd need somewhere in there if you want to dig.
  3. You'll probably want Subject GetPlayerTeammate, otherwise you're checking if the player is their own teammate and the RefCollectionAlias probably won't fill with anything. Do note that the Story Manager only auto-fills aliases when the quest first starts up, so you'll probably have to periodically stop and restart the quest to update the actors in the RefCollectionAlias. Note that this will reset any script data attached to the quest and any aliases, so if there's any state-sensitive data anywhere in you're script, you'll need separate "controller" and "finder" quests, and AddRefCollection the data in the finder quest over to the controller quest or whatever. Or, if you already have an external reference, you can always manually AddRef() to your RefCollectionAlias as necessary.
  4. Not possible, the Syringer and Junk Jet both use hard-coded, non-extensible special handling at the engine level. See the AmmoSyringer_DO, KeywordSyringer_DO and ObjectTypeSyringerAmmo_DO Default Objects, as well as AmmoJunkJet_DO, KeywordJunkJet_DO and NotJunkJetAmmo_DO. You could certainly make something share the Syringer ammo types, and add additional Syringer ammo if you wanted to, just look at the forms hooked up to the DFOBs and make sure you have the appropriate keywords on the new weapon/ammo. If you wanted a totally separate set of ammo from the default Syringer, it may very well be possible to set up a different set of keywords, and use F4SE to fiddle with the DFOBs, like via OnEquipped on a script attached to the weapon or something: https://www.creationkit.com/fallout4/index.php?title=DefaultObject_Script Just make sure to set the Default Objects back to their original forms when you're done, otherwise you'll break the Syringer.
  5. I made a pseudo-copy of the function a few years ago for this mod: https://www.nexusmods.com/fallout4/mods/28945 It was a pain. Here's the Papyrus bit: Annoyingly, there are a number of quest items registered with components, and there isn't any way to differentiate quest items (i.e. things that couldn't normally be removed from your inventory) from any other scrap, so the best I could come up with was to manually maintain a FormList of those and just transfer them back to the player if they get taken. I never managed to get the "real" button to work. I believe the way it works is that activating a container directly from the "special" TRANSFER UI button—provided by containers with WorkshopKeyword (defined by the Workshop Default Object in the CK), or a workbech/crafting station linked to one such container via WorkshopItemKeyword (defined by the WorkshopItem DFOB etc)—sets some state that watches for the extra button press event or whatever, and somehow links the UI button up to that; and also passes some extra data into the ContainerMenu Scaleform object that sets uiMode to 6 (CM_WORKBENCH), which enables the "native" button in the UI: https://i.imgur.com/7jlly14.png And you can change this so it will show up in other containers, but that only changes the UI. it doesn't actually make the button work. https://i.imgur.com/f6tR5qS.jpg I think the only way you could get this to work is by being really good at reverse engineering, and then use that to create an F4SE plugin that allows you to open containers in "workbench" mode. I don't think it's possible to "trick" it to work with other containers without completely breaking the workshop system (changing the Default Object).
  6. With that sort of structure, the easiest thing is probably just to let a very short timer expiration handle it: ScriptName MyFirstScript extends Quest Actor Property PlayerRef Auto FormList Property ArmorList Auto Form[] ArmorForms Event OnInit() ArmorForms = New Form[0] RegisterForRemoteEvent(PlayerRef, "OnItemUnequipped") PlayerRef.UnequipAll() UnregisterForRemoteEvent(PlayerRef, "OnItemUnequipped") EndEvent Event Actor.OnItemUnequipped(Actor akSender, Form akBaseObject, ObjectReference akReference) if (akBaseObject is Armor) ArmorForms[ArmorCount] = akBaseObject StartTimer(0.1) else RETURN endif EndEvent Event OnTimer(int aiTimerID) ; nothing has restarted the timer in the last 0.1 seconds, so unequips are probably finished int i = ArmorForms.Length while (i >= 0) ; do something with ArmorForms[i] i -= 1 endwhile ArmorForms.Clear() EndEventI do this sort of thing in a few places when I'm waiting for repeated events to stop, e.g. in the event handler for RegisterForAnimationEvent(PlayerRef, "WeaponFire"), so I can wait until a burst from something like a Gatling Laser is finished before I try running some longer code.
  7. As far as I know, it just isn't possible. Two masters is max, which allows for, at most, Fallout4 + the developer's .esp to merge into Fallout4.esm; or FO4 + 1 DLC + the developer's .esp to merge into the DLC. Bethesda never bothered to expand the version control system to support more than that because they just never had a need for it, I guess. IIRC the error only shows up when you go to "commit" the changes, so you might never have seen it. I did write an xEdit script that sort of works as a replacement: https://gist.github.com/EyeDeck/9cc4a65c5156870dba2a3f60efd64547 The intended usage is to have a master (master count for that master is irrelevant), and a "dev" plugin for that master. Do whatever work you want with the dev plugin "actively" loaded in the CK, then run that xEdit script on your dev plugin when you want to commit those changes (because it's xEdit you can also review and/or tweak them first, which is handy), choose which master you want to merge into, and hit Ok. It'll copy all the changes you've made into the master (including renumbering and merging new records), and delete them from the plugin. Note that it does not work with NavMeshes (I don't even know what happens if you do try to run it on a plugin with navmesh data). For that you'd have to have someone load the master up in the CK and do the navmesh edits on it directly. It also doesn't work with ESL-flagged dev plugins so don't try, and there may still be unknown bugs, but it's worked well enough for me when I've used it.
  8. One time I accidentally made a save just as the 0,0,0 cell loaded, and happened to look at it in FallrimTools later. Over 400 active OnLoad scripts...
  9. Oh, I made a mod that does exactly that a few weeks ago. Mostly as a basic demo, but it does work. https://drive.google.com/file/d/1Ol9pAUNKYhEWkWig_bsyIxKY8yhZ9jIm/view?usp=sharing Source is in the .ba2. In that version, compatibility for new weapons is achieved by adding additional entries to the WeaponOverrides array, which should be fairly self-explanatory. It has "pseudo-compatibility" for the vanilla Assault Rifle, and 10mm pistols as examples, but the intention is to replace those entries entirely with the "semi-auto"/"full auto" OMODs that lots of weapon mods tend to provide. If you uncomment lines 81-87 in idek:mst:FireModeController and recompile, it will also swap between two "generic" auto/semi-auto mods for any weapon type that's not in the WeaponOverrides array, and that does work on absolutely any weapon. It isn't guaranteed to work properly, though, since it doesn't affect base fire rates and so on. (edit: oh, you'll have to tweak the MST_FireModeSemi/MST_FireModeAuto OMODs too, at one point I removed the property that sets bIsAutomatic from them) There's also some commented-out code that mostly works that's based off of ObjectReference.AttachMod(), instead of ObjectReference.AttachModToInventoryItem() that the "active" code is based off of. Some of it might be of interest to you if you want to experiment. If you wanted to add "soft" compatibility to nearly any number of mods, you'd unflag WeaponOverrides as Const, and write some additional code to do a bunch of Game.IsPluginloaded() checks, followed by grabbing the appropriate forms via Game.GetFormFromFile(), inserting them into new WeaponOverride struct instances, and adding the new structs to WeaponOverrides, all at runtime. Feel free to do whatever you want with it by the way, I never intended to release it anyway. It's a good base to start from if you want to polish it up into a fully-featured mod.
  10. Judging just by the compiler error, you've got the Caps001 property defined more than once. It's difficult to guess without the script source to look at.
  11. Using all DLCs as masters would indeed cause trouble here, iirc the version control system simply does not work if a file has more than...two masters I think is the limit. It should give you a warning telling you you're doing it wrong and multiple masters aren't implemented "yet" because we're not making DLC yet, or something to that effect. Other than that, the version control system does work if you set it up precisely as described in the CK wiki tutorial. It can certainly slow your workflow down quite a bit though, since you have to deal with checking records in/out all the time.
  12. Nope, as long as you're okay with the load order implications. It even seems to be safe to change the flag mid-save, or at least I've done that myself without issues.
  13. Totally didn't mean to find this thread, but for anyone who still cares:If I recall correctly, that's Sclerocephalus, from the UFO4P team.No, he isn't why your game crashed, he was just the last person to compile some script that threw an error (most likely in original Bethesda code), that coincidentally happened prior to your crash.The Papyrus log does not contain information relevant to game stability—unless you're seeing loads of stack dumps, in which case general script overload might have caused your crash, maybe.You should thank him, because he's put a ton of work into patching up this broken game.
  14. Oh, that'll be because you've got "Hide no conflict and empty rows" checked. You can find the option in the context menu if you right click anywhere in the right pane. That option is really handy for conflict resolution, but not as much for mod development. The CK is definitely a necessity for serious development, though, so no harm in picking it up. Learning to use its clunky and painfully slow interfaces takes time though, it's an absolute behemoth of a tool.
  15. You just have to right click on the empty section next to the APPR subrecord and click Add, then you can edit it as you like. The subrecord doesn't exist in the record until you do that, so you can't edit it. xEdit also has a really handy feature where you can ctrl+click multiple similar records and click+drag subrecords between them, like so It makes doing stuff like what you're trying a lot easier, especially if you need to update or edit similar data in many records at a time.
×
×
  • Create New...