Came across this mod since it was incorporated into the unofficial modder's patch. Was looking at the arrow switching code and it looks very brute force. Also, updating in the case of added items to the list becomes tedious....
Optional (slightly changing order, true) could be :
function arrows() bool bDone = false; ; Next closest arrows, one index away ?int iAdjacentIndex = 1 ; Original arrow type ?int findex = fIndexOriginal ; Continue until we find something while bDone != true ??; if there's a valid arrow type up at the next tier if findex + iAdjacentIndex <= nMaxIndex ; get the arrows of that type nextammo = SAArrowlist.getat(findex + iAdjacentIndex) ; if there's any of those arrows in our inventory if PlayerRef.GetItemCount(nextammo) > 0 ; equip them PlayerRef.EquipItem(nextammo, false, true) ; we've equipped a new arrow type, so we're done bDone = true endif endif ; if there's a valid arrow type down at the next tier, and we're not already done if findex - iAdjacentIndex >=0 && bDone = false ;get the arrows of that type nextammo = SAArrowlist.getat(findex - iAdjacentIndex) ; if there's any of those arrows in our inventory if PlayerRef.GetItemCount(nextammo) > 0 ; equip them PlayerRef.EquipItem(nextammo, false, true) ; we've equipped a new arrow type, so we're done bDone = true endif endif ??;Check next closest slots ??iAdjacentIndex += 1 ??; Did we run out of options? if findex + iAdjacentIndex > nMaxIndex && findex - iAdjacentIndex < 0 bDone = true endif endWhile endFunction
In the case of adjusting the number of items in the list, you only need to change nMaxIndex... which you could even have filled in at runtime, if I understand Papyrus correctly.
easier to read through (imo), but admittedly does slightly alter the choice of arrow that will be used next (going up one, then down one, up two, down two, vs down 1-3, up 1, down 4,5, up 2.. etc.)
I personally hate return calls mid function (C++ training showing) and honestly my first read through I didn't even notice them, so I thought the original was going to have a very different end result than it does.
I don't have a lot of experience in Papyrus, so I may have typos, syntax errors, or other imperfect usages, but if you also find this version to be cleaner, feel free to use it. (definitely some copy - paste issues that added question marks in weird spots that I can't manage to edit out of the post.)
At a minimum it fits on one page this way more similar to the bolts, so it should be easier to debug or update.
I tested it works for me after compacting it with xEdit and ESL flagging with WryeBash. I only tried stalhrim and glass, and it swapped the iron out for ebony and glass respectively as the next lowest I had.
I have 389 mods so far, so ESL is an essential feature for me.
My personal frustration is attaining ethereal arrows but then having the stupid game randomly revert to whatever physical arrows I might happen to have collected. Argh!
19 comments
Optional (slightly changing order, true) could be :
function arrows()
bool bDone = false;
; Next closest arrows, one index away
?int iAdjacentIndex = 1
; Original arrow type
?int findex = fIndexOriginal
; Continue until we find something
while bDone != true
??; if there's a valid arrow type up at the next tier
if findex + iAdjacentIndex <= nMaxIndex
; get the arrows of that type
nextammo = SAArrowlist.getat(findex + iAdjacentIndex)
; if there's any of those arrows in our inventory
if PlayerRef.GetItemCount(nextammo) > 0
; equip them
PlayerRef.EquipItem(nextammo, false, true)
; we've equipped a new arrow type, so we're done
bDone = true
endif
endif
; if there's a valid arrow type down at the next tier, and we're not already done
if findex - iAdjacentIndex >=0 && bDone = false
;get the arrows of that type
nextammo = SAArrowlist.getat(findex - iAdjacentIndex)
; if there's any of those arrows in our inventory
if PlayerRef.GetItemCount(nextammo) > 0
; equip them
PlayerRef.EquipItem(nextammo, false, true)
; we've equipped a new arrow type, so we're done
bDone = true
endif
endif
??;Check next closest slots
??iAdjacentIndex += 1
??; Did we run out of options?
if findex + iAdjacentIndex > nMaxIndex && findex - iAdjacentIndex < 0
bDone = true
endif
endWhile
endFunction
In the case of adjusting the number of items in the list, you only need to change nMaxIndex... which you could even have filled in at runtime, if I understand Papyrus correctly.
easier to read through (imo), but admittedly does slightly alter the choice of arrow that will be used next (going up one, then down one, up two, down two, vs down 1-3, up 1, down 4,5, up 2.. etc.)
I personally hate return calls mid function (C++ training showing) and honestly my first read through I didn't even notice them, so I thought the original was going to have a very different end result than it does.
I don't have a lot of experience in Papyrus, so I may have typos, syntax errors, or other imperfect usages, but if you also find this version to be cleaner, feel free to use it. (definitely some copy - paste issues that added question marks in weird spots that I can't manage to edit out of the post.)
At a minimum it fits on one page this way more similar to the bolts, so it should be easier to debug or update.
i suppose you don't need to update if you are having no problems.
Thanks for the quick response :)
New question, can it be ESL flagged safely? If the scripts use GetFormIDs it would most likely break the links after compacting/renumbering
I have 389 mods so far, so ESL is an essential feature for me.