[RELz] Fallout Script Extender (FOSE) v1.2 : Fallout 3

» Sat Feb 19, 2011 6:53 am

Is there any chance of adding in the functions that Enhanced Economy uses for it's location based prices??

They look like this

  if tnoEE.useLocationPrices == 0        let tnoEE.location_prices := ar_Null    else        let tnoEE.location_prices := ar_Construct StringMap        let tnoEE.location_prices["IC"] := ar_Construct StringMap        let tnoEE.location_prices["IC"]["All"] := 1.15        let tnoEE.location_prices["IC"]["Armor"] := 1.0        let tnoEE.location_prices["IC"]["Weapon"] := 0.9        let tnoEE.location_prices["IC"]["Magic"] := 1.25        let tnoEE.location_prices["IC"]["Ayleid"] := 1.4        let tnoEE.location_prices["IC"]["Furniture"] := 1.0        let tnoEE.location_prices["IC"]["Book"] := 1.3        let tnoEE.location_prices["IC"]["Food"] := 1.25        let tnoEE.location_prices["IC"]["Drink"] := 1.25        let tnoEE.location_prices["IC"]["Potion"] := 0.8        let tnoEE.location_prices["IC"]["Gems"] := 1.2        let tnoEE.location_prices["IC"]["Jewelry"] := 1.4        let tnoEE.location_prices["IC"]["Clothes"] := 1.0        let tnoEE.location_prices["IC"]["ClothesLo"] := 0.7        let tnoEE.location_prices["IC"]["ClothesUp"] := 1.3        let tnoEE.location_prices["IC"]["Misc"] := 0.9        let tnoEE.location_prices["IC"]["LockPick"] := 1.2        let tnoEE.location_prices["IC"]["MiscLower"] := 0.7        let tnoEE.location_prices["IC"]["MiscUpper"] := 1.0etc. etc.

EDIT:

Failing this, could you make a SetBaseItemValue type function that works for meds and chems, because at the moment they have potion values instead of values

» Fri Feb 18, 2011 7:05 pm

Is it possibleto script new Begin blocks?

» Fri Feb 18, 2011 9:12 pm

FOSE hasn't introduced any new blocktypes.

OBSE allows user-defined functions via a "Function" blocktype, which can be triggered from other scripts. Assuming in-game events can be detected, I suppose it could be possible to define new blocktypes, but I can't say for certain.

Cipscis

» Sat Feb 19, 2011 10:36 am

OBSE allows user-defined functions via a "Function" blocktype, which can be triggered from other scripts. Assuming in-game events can be detected, I suppose it could be possible to define new blocktypes, but I can't say for certain.

Oh really? Did they work like proper functions, that is, execute immediately and then give a return value at the point from which it was called?

That would be really nice to have in FOSE...

» Sat Feb 19, 2011 7:41 am

That's right. Have a look at the OBSE docs for more info - http://obse.silverlock.org/obse_command_doc.html#UserDefinedFunctions

Cipscis

EDIT:

In the meantime, you can use http://geck.gamesas.com/index.php/OnActivate blocks to emulate this kind of behaviour by taking advantage of the fact that calling http://geck.gamesas.com/index.php/Activate (with its "RunOnActivateFlag" parameter set to 1) will cause the http://geck.gamesas.com/index.php/OnActivate block to run immediately while the original script is paused. I've used this method in CASM for saving and loading by setting remote variables in persistent references for parameters, then calling http://geck.gamesas.com/index.php/Activate on them.

Cipscis

» Sat Feb 19, 2011 2:32 am

In the meantime, you can use http://geck.gamesas.com/index.php/OnActivate blocks to emulate this kind of behaviour by taking advantage of the fact that calling http://geck.gamesas.com/index.php/Activate (with its "RunOnActivateFlag" parameter set to 1) will cause the http://geck.gamesas.com/index.php/OnActivate block to run immediately while the original script is paused. I've used this method in CASM for saving and loading by setting remote variables in persistent references for parameters, then calling http://geck.gamesas.com/index.php/Activate on them.

Thanks, I've been trying to find that method described again. I had tried to use it at least once before, but I think I was running into some of the other peculiarities of Activate and I wasn't getting the results I expected.

» Sat Feb 19, 2011 12:52 am

I have a question about the GetInventoryObject function. If I am sorting through a container and removing unwanted items, do the remaining items shift up to fill the empty slot immediately? Or is the entire order of Forms changed by removing all of one type, that requires starting the search over?

Thanks

ref rBaseInvObjshort iInvPosshort iItemTypeshort iItemCountLabel 1set rBaseInvObj to (MYNPCREF.GetInventoryObject iInvPos)if (rBaseInvObj)	set iInvPos to (iInvPos + 1)	set iItemType to GetType rBaseInvObj	if (iItemType == 41);Ammo Type		if (rBaseInvObj != MyNPCREF.rCurrentAmmoREF);Ammo not used by current equipped weapon (set elsewhere)			set iItemCount to MyNPCREF.GetItemCount rBaseInvObj			MyNPCREF.RemoveItem rBaseInvObj iItemCount;Now that the current item is deleted, do the remaining items shift up? Do I need to decrement iInvPos to continue searching properly?		endif			endif	Goto 1endif

Edit: found an example of searching from end to beginning but wasn't able to find a definitive answer for the above. http://cs.elderscrolls.com/constwiki/index.php/Walking_through_Items_in_an_Inventory

» Sat Feb 19, 2011 12:04 am

There are a couple of things making this awkward: firstly, all armour and clothing items return 24 for GetType, so they're all defined as Armour.
I've been using GetEquipType in Oblivion to distinguish between the different types - headgear, leggings, upperbody etc etc. I know it's not the same in FO3, but I was hoping I could use GetEquipType to categorise FO3 items in some useful way.
However, GetEquipType returns either 0, 7 or 8 for every single armour/clothing item - so according to the Equipment Type values, they're all headgear or backpacks or necklaces. :facepalm:

In this case, GetEquipType is returning the first matching biped flag. Most armour and clothing disables those given biped types when worn, and they just happen to be checked first.

The only practical solution I can think of is to use form lists for the base object types, then to use the non-FOSE function IsInList.

» Sat Feb 19, 2011 5:53 am

In this case, GetEquipType is returning the first matching biped flag. Most armour and clothing disables those given biped types when worn, and they just happen to be checked first.

The only practical solution I can think of is to use form lists for the base object types, then to use the non-FOSE function IsInList.

Yeah, that's what I was afraid of.
I was hoping to avoid using form lists, because items added by mods wouldn't be in those form lists and therefore wouldn't be handled automatically. Whereas if the EquipType gave me the information I needed, then they would just work straight out of the box, so to speak. I'll need to think through some way to resolve that.

» Fri Feb 18, 2011 11:03 pm

We very much appreciate all the help and effort! FOSE is a huge benefit to the community, and I'm grateful you are able to support and release it. :goodjob:

Cheers!

Miax

seconded

» Sat Feb 19, 2011 1:56 am

seconded

Thirded, lest there be a second's doubt about how much we appreciate OBSE and FOSE. Serious scripting would be nigh-on impossible without them.
My secret hope is that FO:NV's engine will be so close to FO3's that you guys will be able to port FOSE to it very early, and that we'll be able to port our mods over for use while the game is still fresh and buzzing with new players.

Unlikely I know, but a guy can dream, eh? :evil:

» Fri Feb 18, 2011 7:17 pm

Where would you put a suggestion command to be added to FOSE I believe I remember seeing it before, but I cant remember. I thought they had their own forum at one point for that?

Alright then.

I would like to know if the feature http://cs.elderscrolls.com/constwiki/index.php/NameIncludes could be added to a future version of FOSE

» Sat Feb 19, 2011 1:29 am

People normally post such suggestions here. This is kind of their official forum. :whistle:

» Sat Feb 19, 2011 1:17 am

Failing this, could you make a SetBaseItemValue type function that works for meds and chems, because at the moment they have potion values instead of values

I second this. Even Bethesda and the GECK don't properly handle the value of INGE items, mind you -- take a look at the calculated value when previewing a leveled list containing ingestibles.

Rolling the ability to check the potion value of ingestibles in the GetValue/GetItemValue functions would be the ideal solution, because then we wouldn't have to use GetIsType to distinguish and use two different functions, but if that proves impossible then I'm content with a dedicated GetPotionValue/GetIngestibleValue/GetChemValue/GetWhateverValue function. Likewise for SetBaseIngestibleValue/SetBaseYouGetTheIdeaValue.

So, yeah. If we can, SetBaseItemValue for ingestibles, GetItemValue for ingestibles. Please and thank you! In the words of Fable guards, "Much'happreciated!"

» Sat Feb 19, 2011 12:24 am

I have a question about the GetInventoryObject function. If I am sorting through a container and removing unwanted items, do the remaining items shift up to fill the empty slot immediately? Or is the entire order of Forms changed by removing all of one type, that requires starting the search over?

Dunno.

Though that doesn't help you, I'd suggest playing it safe and starting the loop over each time anyway -- the few dozen (at most) wasted loops will more than make up for themselves in general robustness.

[edit]Here's a thought: you can avoid the problem completely by running through the list from back to front; start at the end and work your way back, and it won't matter if items you remove shift the list around, since that would only affect positions that come after the item you've removed anyway.

» Fri Feb 18, 2011 8:13 pm

I'm curious, has anyone had any luck when trying to check the item type of a form found by GetInventoryObject?

I'm trying to use the following:

			;Remove all chems to a special container, then activate that container for the player			set inventoryitems to GetNumItems			set i to inventoryitems - 1			set containerRef to PlaceAtMe FreebieContainer 1			PrintToConsole "DBG: Successfully created container %i" containerRef			Label 1				set itemType to GetInventoryObject i				set count to GetItemCount itemType				PrintToConsole "DBG: checking item %.0f (%n) count: %.0f" i itemType count				if ( itemType.GetIsObjectType Ingestible == 1 )					PrintToConsole "DBG: Putting %.0f of %n into container" count itemType					RemoveItem itemType count					containerRef.AddItem itemType count				else					PrintToConsole "DBG: Not Ingestible"				endif				set i to i - 1				if ( i >= 0 )					Goto 1				endif			;Update the count to reflect the actual amount inside the container, rather than in the source inventory			set inventoryitems to containerRef.GetNumItems			containerRef.Activate Player

Unfortunately, whenever I run this block, the script halts completely at the GetIsObjectType line, failing to produce any further output. Checking GetIsFormType ALCH also fails silently. For the overboard attack, checking IsInList AllIngestiblesList also failed.

This isn't another of those "it's a special object which indicates the base type, not the base type itself" things, is it?

(If it is, the inevitable: requesting a GetInventoryObjectType function...)

» Sat Feb 19, 2011 11:09 am

I have a question about ListAddReference.

What use is it? It seems that one cannot use IsInList or ListGetNthForm on lists that contain references. I would love to see something like IsRefInList or ListGetNthRef commands to go along with the ListAddReference command. I just don't see how that function is useful in and of itself.

Can anyone shed some light on its use for me?

And what are the chances of actually being able to get information from a list that contains references added with ListAddReference?

Thank you all.

P.S. I would also like to add my voice to those that hunger for arrays.

» Sat Feb 19, 2011 9:15 am

Dunno.
[edit]Here's a thought: you can avoid the problem completely by running through the list from back to front; start at the end and work your way back, and it won't matter if items you remove shift the list around, since that would only affect positions that come after the item you've removed anyway.

Yeah - that's what i've been doing for now and it is working well.

» Fri Feb 18, 2011 8:15 pm

I'm curious, has anyone had any luck when trying to check the item type of a form found by GetInventoryObject?

I'm trying to use the following:

			;Remove all chems to a special container, then activate that container for the player			set inventoryitems to GetNumItems			set i to inventoryitems - 1			set containerRef to PlaceAtMe FreebieContainer 1			PrintToConsole "DBG: Successfully created container %i" containerRef			Label 1				set itemType to GetInventoryObject i				set count to GetItemCount itemType				PrintToConsole "DBG: checking item %.0f (%n) count: %.0f" i itemType count				if ( itemType.GetIsObjectType Ingestible == 1 )					PrintToConsole "DBG: Putting %.0f of %n into container" count itemType					RemoveItem itemType count					containerRef.AddItem itemType count				else					PrintToConsole "DBG: Not Ingestible"				endif				set i to i - 1				if ( i >= 0 )					Goto 1				endif			;Update the count to reflect the actual amount inside the container, rather than in the source inventory			set inventoryitems to containerRef.GetNumItems			containerRef.Activate Player

Unfortunately, whenever I run this block, the script halts completely at the GetIsObjectType line, failing to produce any further output. Checking GetIsFormType ALCH also fails silently. For the overboard attack, checking IsInList AllIngestiblesList also failed.

This isn't another of those "it's a special object which indicates the base type, not the base type itself" things, is it?

(If it is, the inevitable: requesting a GetInventoryObjectType function...)

This line needs to set a REF variable: set itemType to GetInventoryObject i

Then set the short itemtype variable using the same ref. Like this:

Label 1if (iWLInvPos)  set iWLInvPos to (iWLInvPos - 1)  set rBaseInvObj to (rMyContainerREF.GetInventoryObject iWLInvPos)  set iItemType to GetType rBaseInvObj  if (iItemType == 40)	;weapon Form    ..do stuff with it

also, if 'itemType' that you are using is already a ref, where are you launching the script from? Maybe you need to explicitly specify the container that GetInventoryObject is running against?

» Sat Feb 19, 2011 2:53 am

pkleiss -
I had thought the same about the need for an IsRefInList function, but then realized we could use ListGetFormIndex to the same effect. The only problem is that it and some of the other FOSE formlist functions still appear to have bugs in certain cases. Here are the apparent issues I've observed:

http://fose.silverlock.org/fose_command_doc.html#ListGetFormIndex will not return the index of a non-BaseForm contained in a FormList (will return -1).
If http://fose.silverlock.org/fose_command_doc.html#ListRemoveForm or http://fose.silverlock.org/fose_command_doc.html#ListRemoveNthForm are used to remove the last entry in a FormList (that contains more than 1 entry), no more entries can be added to the end of the list.

I don't think I ever used ListGetNthForm, but being the complement to ListGetFormIndex I'd imagine it works in a similar way, so I'm not surprised you found it to have the same problem (I haven't tested ListReplaceForm or ListReplaceNthForm either). I've already reported these things to Ian, but I've been wondering if some of these things are because FormLists were never really intended to contain anything but BaseForms, and subsequently those FOSE functions aren't expecting non-BaseForms either (note that the ListRemoveForm/ListRemoveNthForm bug described above occurs when working only with BaseForms as well). After all, the FOSE docs specify that the return type for all of these functions is either an integer (index) or a BaseForm (FormList entry).

But you might find http://www.gamesas.com/index.php?/topic/1079066-saving-formlists/page__p__15717978__fromsearch__1&#entry15717978 helpful. It describes methods to deal with both problems (lack of a working ListGetFormIndex or IsRefInList, and bug when removing entries at the end of a list). I've been using these for a while now with no problems (Feng Shui).

One other thing: http://geck.gamesas.com/index.php/IsInList is a different kind of function as it does two things. It's called by a reference, gets the base object (BaseForm) of that reference, then checks to see if the specified FormList contains that BaseForm. In respect to gameplay, that's a very common action, so we wouldn't to be without such a function.

» Sat Feb 19, 2011 1:32 am

This line needs to set a REF variable: set itemType to GetInventoryObject i

Then set the short itemtype variable using the same ref. Like this:

[snip]

also, if 'itemType' that you are using is already a ref, where are you launching the script from? Maybe you need to explicitly specify the container that GetInventoryObject is running against?

The snippet is trimmed, including the variable declarations, because it's part of a much larger NPC script. Sorry if it seemed misleading.

The relevant variable declarations are:

ref containerRefint inventoryitemsint iint countref itemType

containerRef is a ref variable pointing to a freshly-placed container using PlaceAtMe with no art (I'll try using a blank NIF version next, now that I've had a chance to sleep on it), which is placed in a separate stage of the script. The PrintToConsole line verifies that this container has been created, reporting the FormID. The container is unlikely to be the problem, however, since the script halts on the line of the if condition, not on the AddItem line.

Execution of the script produces the following output once it reaches that stage of execution:

"DBG: Successfully created container xxxxxxxx" (where xxxxxxxx is a formID)
"DBG: checking item 9 (Mercenary Cruiser Outfit) count: 1"
...and then bupkis.

The if condition is apparently failing because neither the "DBG: Putting 1 of Mercenary Cruiser Outfit into container" nor the "DBG: Not an Ingestible" outputs are produced.

I'll try using GetType next, since for whatever reason I missed it the three (!) times I reviewed the FOSE documentation, winding up finding the FO3 GetIsObjectType/GetIsFormType condition functions intended for Perks instead... The "GetType itemType" might play nicer than the "itemType.GetType" format.

P.S. Hungarian notation must die! =P

» Sat Feb 19, 2011 6:17 am

The snippet is trimmed, including the variable declarations, because it's part of a much larger NPC script. Sorry if it seemed misleading.

The relevant variable declarations are:

ref containerRefint inventoryitemsint iint countref itemType

containerRef is a ref variable pointing to a freshly-placed container using PlaceAtMe with no art (I'll try using a blank NIF version next, now that I've had a chance to sleep on it), which is placed in a separate stage of the script. The PrintToConsole line verifies that this container has been created, reporting the FormID. The container is unlikely to be the problem, however, since the script halts on the line of the if condition, not on the AddItem line.

Execution of the script produces the following output once it reaches that stage of execution:

"DBG: Successfully created container xxxxxxxx" (where xxxxxxxx is a formID)
"DBG: checking item 9 (Mercenary Cruiser Outfit) count: 1"
...and then bupkis.

The if condition is apparently failing because neither the "DBG: Putting 1 of Mercenary Cruiser Outfit into container" nor the "DBG: Not an Ingestible" outputs are produced.

I'll try using GetType next, since for whatever reason I missed it the three (!) times I reviewed the FOSE documentation, winding up finding the FO3 GetIsObjectType/GetIsFormType condition functions intended for Perks instead... The "GetType itemType" might play nicer than the "itemType.GetType" format.

P.S. Hungarian notation must die! =P

Ok, I see now

You'll also want to do a if(itemType) test to make sure the REF is not NULL before running any functions on it, because that will also cause a script to halt.

» Sat Feb 19, 2011 6:10 am

accidental multipost

» Fri Feb 18, 2011 10:37 pm

Ok, I see now

You'll also want to do a if(itemType) test to make sure the REF is not NULL before running any functions on it, because that will also cause a script to halt.

Yeah, sure enough, it's the distinction between "GetType ref" and "ref.GetType" that made it. The script now works flawlessly (aside from mild tweaking here and there that I need to do).

In summary: Trying to use the object returned by GetInventoryObject as 'ref' in any "ref.Function" causes the script execution to halt, even though it appears to work fine in any "Function ref". Darned shame... that limits some options. =/

[edit]After some testing, I've isolated some sort of bug with this system. I have no idea if it's a core engine bug or what, but for whatever reason, GetItemCount in the loop I've given above actually reports the count of the following item in the object's inventory. For instance, I'll get quirky behaviour like this:

DBG: checking item 9 (Marshal Pistol) count: 0
DBG: checking item 8 (10mm Round) count: 1
DBG: checking item 7 (Mentats) count: 55
DBG: Putting 55 of Mentats into container

There is 1 Marshal Pistol, 55 10mm Rounds, and 1 Mentats in the inventory, in addition to the other stuff... and yes, GetItemCount seriously does return "0"!

It's obviously some sort of fencepost error in the engine, but it boggles the mind because it just doesn't make sense that getting the item type of a given index then checking the item count of that type (with complete disregard for the index) would return the count of the wrong index. Unless this is a FOSE bug?

» Sat Feb 19, 2011 5:59 am

Yeah, sure enough, it's the distinction between "GetType ref" and "ref.GetType" that made it. The script now works flawlessly (aside from mild tweaking here and there that I need to do).

In summary: Trying to use the object returned by GetInventoryObject as 'ref' in any "ref.Function" causes the script execution to halt, even though it appears to work fine in any "Function ref". Darned shame... that limits some options. =/

[edit]After some testing, I've isolated some sort of bug with this system. I have no idea if it's a core engine bug or what, but for whatever reason, GetItemCount in the loop I've given above actually reports the count of the following item in the object's inventory. For instance, I'll get quirky behaviour like this:

DBG: checking item 9 (Marshal Pistol) count: 0
DBG: checking item 8 (10mm Round) count: 1
DBG: checking item 7 (Mentats) count: 55
DBG: Putting 55 of Mentats into container

There is 1 Marshal Pistol, 55 10mm Rounds, and 1 Mentats in the inventory, in addition to the other stuff... and yes, GetItemCount seriously does return "0"!

It's obviously some sort of fencepost error in the engine, but it boggles the mind because it just doesn't make sense that getting the item type of a given index then checking the item count of that type (with complete disregard for the index) would return the count of the wrong index. Unless this is a FOSE bug?

I've had strange things happen sometimes when making changes to an NPC's script. Like certain things firing off when I KNOW the variable was not set, etc. I usually fast travel a couple of times to other cells and back to reload the NPC, script, and packages after changing a script.