[WIPz] Fallout 4 Script Extender (F4SE)

[JonathanOstrus]

 

 

Do I need to do anything special to get F4SE scripts to compile? I've installed it as per the instructions (and included the files in /Data that aren't mentioned) but the CK refuses to recognize RegistorForControl in my script.

 

Well you need to make sure the modified source files are in the proper source directly. The latest F4SE archive should have them in data/scripts/source/user instead of the previous data/scripts/source/f4se. The specific file you need for that function is the ScriptObject.psc. You'll also want to make sure the ScriptObject.pex from the F4SE archive is installed as well. Then it should compile.

 

Awesome, thanks, I thought the .psc files were unnecessary so I put them in /F4SE instead of /User to avoid overwriting things. It's working now.

 

Also thanks to TheDungeonDweller for that changelog!

 

 

I personally still keep them in the F4SE folder just so if/when I use the CK archive tool it doesn't grab them. To be able to still compile from CK you have to add the F4SE path to the ini.

 

My CreationKitCustom.ini looks like this

 

[Papyrus]
sAdditionalImports = "$(source);.\Data\Scripts\Source\F4SE;.\Data\Scripts\Source\Base;.\Data\Scripts\Source\DLC01;.\Data\Scripts\Source\DLC02;.\Data\Scripts\Source\DLC03;.\Data\Scripts\Source\DLC04;.\Data\Scripts\Source\DLC05;.\Data\Scripts\Source\DLC06"

[BrendonLeCount]

I see "Set/GetEquipType" under Form (which is great), returning an EquipSlot type. Does anyone have any pointers on working with the EquipSlot type? I'd assume it would be structured as an array of integers representing equip slots, but if so I'm not sure how to access them.

[hlp]

BGSEquipSlot are vanilla forms (Signature = EQUP in xEdit). They don't have a specific script associated so they should use the Forms script.

They are defined in GameForms.h

[BrendonLeCount]

BGSEquipSlot are vanilla forms (Signature = EQUP in xEdit). They don't have a specific script associated so they should use the Forms script.

They are defined in GameForms.h

There's an EquipSlot.psc that extends Form, but this is the entirety of it:

Scriptname EquipSlot extends Form native Hidden

; Returns the Nth parent slot
EquipSlot[] Function GetParents() native 

Edit - I think I was confused on what GetEquipType does. I needed something that returns biped slots for armor, while GetEquipType returns an EquipSlot for a weapon. Edited August 5, 2017 by Imp of the Perverse

[BrendonLeCount]

I'm currently running into some trouble with the way GetInventoryItems works. It stacks items based on their base, unmodded form, which means you can't get up to date information on them. I'm trying to step through a container of weapons and select one based on damage output (and when that failed, value) but attached mods are ignored because only the base forms are available to pass as arguments to the functions. Mods can change the value, damage output, ammo type, and attached keywords. I also need to determine the ammo type, but GetAmmo returns the ammo type for the base form, and the "converted" keywords added by the mods don't register. Would it be possible to add a version of the function that returns the instances in the inventory?

[JonathanOstrus]

I'm currently running into some trouble with the way GetInventoryItems works. It stacks items based on their base, unmodded form, which means you can't get up to date information on them. I'm trying to step through a container of weapons and select one based on damage output (and when that failed, value) but attached mods are ignored because only the base forms are available to pass as arguments to the functions. Mods can change the value, damage output, ammo type, and attached keywords. I also need to determine the ammo type, but GetAmmo returns the ammo type for the base form, and the "converted" keywords added by the mods don't register. Would it be possible to add a version of the function that returns the instances in the inventory?

 

I don't recall if all the objects in the container will have valid ref id's to do this. It would be rather processor heavy so not the best solution to repeatedly run. Maybe have some sort of facility to cache it. But maybe a possible interim solution is to have a quest alias for another dummy container. Since you can get an array of the forms in the container. Get the count of that form type. For example all the 10mm guns. Transfer them one at a time to a new container to get reference id's via the alias on the dummy container. Have a script that watches the OnItemAdded for the dummy container. When added you have the ref id and can get attached mods or whatever and compute a value. Then once done computing for everything put it all back in the original container with a simple RemoveAllItems to the original container.

 

Alternatively have the watcher script/alias on the original container to watch when items are placed into it and maintain a cache. Should be substantially less processor heavy to just update when new items are placed. Of course there's the issue of arrays only handling 128 entries. I'm not sure if a RefCollection could work in this situation or what the max size for those are.

 

I'm not sure if either of these is even a viable working solution, right now I'm just brainstorming.

 

**Edit: After reviewing the functions I guess unless the items are persistent you don't get a ref id when they transfer containers, so I guess that won't work.

Edited August 16, 2017 by BigAndFlabby

[BrendonLeCount]

Darn, I was hoping the OnItemAdded route would work. I'm already doing something similar in my Telestorage mod for non-F4SE-based sorting.

 

The items aren't stacked in your PipBoy, so the information is there somewhere. It would mushroom the number of items returned, but maybe it could return an iterator rather than an array. Most items spend most of their time in inventories, so without a way to get a hold of them, the various accessor functions have limited use.

[pra]

I have a question.

I just downloaded the new F4SE (0.05.00) but now when I run it I get an error. "Unsupported runtime version (expected v1.9.4) *mod name* will be disabled." It shows this for every F4SE mod I have installed before the game launches.

EDIT: I realized that the mods also need to be updated, not just the script extender.

How exactly does this work? Is this something certain mods do actively, or is it a "feature" of F4SE itself? Do I have to actually recompile any of my mods' scripts which use F4SE functions? I'm not really comfortable with actually upgrading my F4 and looking for myself yet.

[hlp]

You have to wait for the people who write the plugin dll you use until they have updated. Your script will then work properly.

 

@f4se team: Thank you for the update.

[pra]

You have to wait for the people who write the plugin dll you use until they have updated. Your script will then work properly.

 

@f4se team: Thank you for the update.

Ooh, it's only about the DLLs, not about scripts? So if I only use F4SE script functions in my mods I don't have to update them?