ref walk utility : Fallout 3

» Sat Feb 19, 2011 4:56 am

I've started using ref walks to handle adding items to NPC inventories. It lets me avoid leveled list conflicts, in fact its the only way I could be sure that the items made it into the NPC inventories without my having to duplicate all of the associated leveled lists and set the "use all" flag. The drawback is that it seems to be a little processor intensive. Since other people might want to use this method, I was wondering if anyone would be interested in a shared ref walk utility. Right now, what my script does is move an invisible dummy object to the player's location. An if statement checks to see if the player is still in the same cell as the object, and if they aren't, it updates the dummy object's location, and performs the ref walk. It will perform the ref walk outside of combat, at the start of combat, and during combat if there are fewer than 3 enemies (its a stability thing).

What I was thinking is that I could make a standalone .esm with this ref walk procedure. It would pull items from a form list and add them to NPC inventories. If your mod has an item that needs to make it into NPC inventories, just add it to the form list via script, and it will be placed in their inventory along with all of the others.

It isn't quite that simple. You might only want it to end up in certain NPC inventories, like raiders or whatever. Plus, the ref walk might be performed multiple times near an NPC, but you'll only want one of your item to show up in its inventory. What you can do is make the object that you add to the ref walk form list a piece of dummy armor with "playable" unselected. Attach a script to that object that checks to see which NPC it's in the inventory of, whether they already have the desired object, etc., and either add the object(s) or remove itself depending on what it finds. Because this is happening in game mode, you'll need to also add and equip a dummy item, then remove it from the NPC's inventory a frame or so later. It prevents the inventory additions from interrupting NPC AI.

» Sat Feb 19, 2011 3:00 am

I don't know if we (FWE) could use this or not, but I think it's a great idea. We've implemented something similar in a new FWE feature, with a dummy object controlling wheather a ref walking script kicks in.

This idea also has me thining about FO:NV . . . it would be super cool if a group of modders could focus their efforts around developing features or "extensions" to the gameplay that took a standards/modder resource approach that readily allowed players to mix n' match various mods that utilize a common pool of resources. CALIBR and CRAFT are the two big obvious examples for FO3. Some of the new features we've been developing for FWE (night vision system, unfound loot, stealth fields, etc...) are designed with compatiblity in mind, and rely on ref walking scripts and/or implementation though formlists, which are good for resolving compatiblity problems via FO3edit's merged patch function.

It's interesting, we have FOSE to handle script functions and such. I could easily see another colaborative .esm file that contained lots of different base record types . . . i.e. new ammo, new formlists (i.e. a formlist for night vision objects) with associated support scripts. How great would it be to have a modders resource for follower behavior scripting (ala Companion share + recruit) that other modders could easily attach to their custom companions, etc....

Anyway, I know this is getting off track from your OP, but I think your idea can lead to an even broader discussion. FOIP 2.0?

» Fri Feb 18, 2011 7:50 pm

If such a feature collection were to be constructed, one should take great care to make it convenient to use for modders and mod users alike. This requires some simplicity as well as resistance to scope creep. Backward compatibility would also be a major concern, as modders come and go, but mods (usually) stays available.

In Oblivion, the Common Oblivion Library (COBL) were constructed to be a set of features available to modders, but many ended up not using it because it caused more headaches than it fixed. In particular, COBL were in active development, so (unlike CRAFT and CALIBR) it could not be bundled with the mods that used it. I'm not trying to diss your idea. I'm just pointing out some of the pitt falls.

» Sat Feb 19, 2011 7:55 am

I'd have found it useful a little while ago, but unfortunately don't really have anything else planned in the lifetime of FO3 that'd need it.
I think trying to create big, centralised resources that everyone should have doesn't really work out in the end unless they're distributed packaged with the mods that need them. TBH I think COBL could have been- as long as people didn't override new versions with old ones from downloaded mods, it wouldn't be an issue. That can be handled by FOMOD/OMOD-style scripts, or just by making sure that every subsequent iteration of the package is bigger so "Overwrite if larger" becomes a common rule.
They also need really solid design at the beginning and throughout to ensure backwards compatibility and expansion don't become issues.

» Sat Feb 19, 2011 5:22 am

Thta all makes sense. I never used COBL, but I can see where they might have run into trouble. Personally, I don't really like the idea of distributing the "resouces" with mods that use them. Incidentially, the rest of the FWE team prevailed over me, I'd rather require CRAFT and CALIBR to be downloaded seperately. If you do that, sure you'll have people that are like . . . "why doesn't my game start, what's missing?!" . . . but directing them to download a resource at least makes them more conscious of that fact that it IS a resource that may need to be updated, have an eye kept on it, etc... rather than some random plugin that they don't understand.

And I was suggesting this might be considered more for FO:NV since there will be a fresher start on the modding.

» Fri Feb 18, 2011 8:02 pm

I'll start by rewording what has already been said. It would need to be well maintained and the features kept compatible. I have run across some very interesting looking mods on the Nexus that I skipped after reading something along the lines of; "Do not use the latest version of FOSE/OBSE/(Insert name here) this only works with version # (2-3 below the current version)"

Now for myself, I would want to play around with somthing like this if it existed. Mostly because my own dalliances with ref walking did not produce the types of results I wanted, though I suspect that the issue was caused by something between the monitor and the chair. (Stupid keyboard!!) If there were an easy to use utility that had a place for conditions on one side and results on the other, depending on how flexible it is, I would try to make use of it.

» Fri Feb 18, 2011 8:02 pm

I wish I could reply to this stuff when I'm AFK, but for whatever reason my phone's browser crashes if I try to comment.

It sounds like there's some interest in this though. I think that there are definitely some interesting things that could be done if modder's had an easy, reliable way to place object scripts into the inventories of every actor in the wastes.

As a resource, I'd try to make it as black box as possible - the modder just adds there item to the form list via script, and the resource takes care of getting it into the inventories without the modder having to worry about it. If future revisions are necessary, like if someone figures out how to accomplish it without ref walks or FOSE functions, it would remain compatible with old mods. I guess the name should be something generic, like Inventory Access.

To get something out there for people to review, the implementation I'm thinking of is this:

The ref walk steps through all of the actors in the area, adding a PiggyBack token, unless the actor already has one in their inventory.

A script running on the PiggyBack token then steps through the formlist, checking to see if the actor already has one of each object in their inventory. If they don't, the token adds one. The token repeats the process every few hundred frames, indefinitely. That way if a new mod is added that uses the resource, its item will still make it into the inventories of actors that have already been visited.

The items added to the form list should be dummy pieces of armor with the "playable" flag left unchecked, with scripts running on them. Those scripts can be used to do whatever, with the caveat that if the modder wants to alter the actor's inventory or equipped gear with them, they'll need to either do that during menu mode, or add and equip a slotless piece of armor, make their inventory changes, wait a couple of frames, and then remove (2?) copies of the dummy armor via removeitem (to prevent AI hangups).

» Fri Feb 18, 2011 8:31 pm

Here's code if anyone's wants to take a look. It seems to work, but one question I haven't answered yet is what happens to the form list if a mod that adds a custom form to it is removed. CTD? Does the list shrink? Does that entry in the list become empty? If calling ListGetNthForm with an index that references an invalid entry crashes the script, I can deal with that, I guess - just increment the list index variable before calling ListGetNthForm, then if it crashes, you still move on to the next index the next time through the loop.

*Edit - yeah, that seems to be the case, an invalid form gets left in the list that crashes the script when ListGetNthForm is called on it. ListGetCount still works though, so the fix mentioned above did the trick. The code below has been updated accordingly.

Ref Walk Code:

Spoiler

scn IAActorWalkerQuestScriptshort sUpgradeChanceshort sCounterref rCurRefref rArmorshort sWalkshort sCombatshort sEnableWalkbegin gamemode		IF IAREFCellMarker.getinsamecell player	; misc. item persistant ref., begins in AnchorageWM dummy cell		ELSE			set sEnableWalk to 1			IAREFCellMarker.moveto player		ENDif		IF player.isincombat == 0				set sCombat to 0		ENDif			IF sEnableWalk 		; if a ref walk has not yet happened since entering the cell			IF player.isincombat == 0 || (sCombat == 0 && player.isincombat) || player.getgrouptargetcount < 3 			; if player is outside of combat, or just started combat, or is in combat with fewer than 3 enemies				set sEnableWalk to 0				set sCombat to 1				set rCurRef to getfirstref 200 1 0		; actors, cell depth of 1, do not include taken refs (whatever that means)				LABEL 10					IF rCurRef						IF rCurRef.getitemcount IAPiggyBack						ELSE		; current ref does not have a PiggyBack token yet							rCurRef.additem IAPiggyBack 1				; token with list scanning script							IF rCurRef.getiscreature							ELSE								rCurRef.additem IADestupidifier 1				; dummy armor object, removed by 								rCurRef.equipitem IADestupidifier 1			; IAPiggyBack script to prevent AI hangups							ENDif						ENDif											set rCurRef to apple										; fix for apple bug						set rCurRef to getnextref						GOTO 10					ENDif			ENDif		ENDifend

PiggyBack token code:

Spoiler

scn IAPiggyBackScriptshort sFrameCountershort sDestupidifiedshort sListLengthshort sListIndexshort sIndexshort sDSDelayshort sInitializedref rContainerref rTokenbegin gamemode	IF sFrameCounter		set sFrameCounter to sFrameCounter - 1	ELSE		IF rContainer			IF sListIndex == 0				set sListLength to ListGetCount IAPiggyBackList			ENDif			IF sListIndex < sListLength                                set sIndex to sListIndex				set sListIndex to sListIndex + 1				IF sListLength					set rToken to ListGetNthForm IAPiggyBackList sIndex					IF rContainer.getitemcount rToken					ELSE						rContainer.additem rToken 1						set sDestupidified to 0					ENDif				ENDif			ELSE				IF sDestupidified; nothing was added, no need to remove destupidifier					set sFrameCounter to 300 + 3 * getrandompercent					set sListLength to 0					set sListIndex to 0					set sDSDelay to 0				ELSE					IF sDSDelay	; items were added - wait a frame, then remove destupidifier						rContainer.removeitem IADestupidifier 2						set sDestupidified to 1						set sFrameCounter to 300 + 3 * getrandompercent						set sListLength to 0						set sListIndex to 0						set sDSDelay to 0					ELSE						IF sInitialized							IF rContainer.getiscreature							ELSE								rContainer.additem IADestupidifier 1								rContainer.equipitem IADestupidifier 1							ENDif						ELSE ; not the first time through, the Destupidifier will need to be added by this script							set sInitialized to 1						ENDif						set sDSDelay to 1					ENDif				ENDif			ENDif		ELSE			set rContainer to getcontainer		ENDif	ENDif	end

Test code:

Spoiler

scn IATESTAdderQuestScriptshort sDoOncebegin gamemode	IF listgetformindex IAPiggyBackList teddybear01 == -1		AddFormToFormList IAPiggyBackList teddybear01	ENDif	IF player.getitemcount ArmorEnclaveHelmet	ELSE		IF listgetformindex IAPiggyBackList pencil01 == -1			AddFormToFormList IAPiggyBackList pencil01		ENDif	ENDifend

» Fri Feb 18, 2011 8:58 pm

This is a great idea.

I have been trying for hours to get the result I want and I still don't see light at the end of the tunnel..! I would welcome a utility that did this automatically with flying colors!

As a side note, the silent explosion method isn't under consideration? :flamethrower:

» Sat Feb 19, 2011 5:12 am

Cipscis did a bunch of tests regarding script optimization, and reported the results in http://www.gamesas.com/index.php?/topic/987561-script-optimisation/. I think the verdict was that ref walks have significantly less of an impact on performance than silent explosions (though it might have been splitting hairs a little). Once you have a dozen mods all doing it at once though, I think it might get a bit more significant, which is where this resource would be handy. With just the one we could maybe try it out and see if it performs any better. You still need FOSE though for the form list functions.

There are a couple of changes I need to make to the above code before I consider releasing. I don't think there's any point in equipping the dummy armor in the ref walk script, and I think it might actually cause some problems - I've had reports from my PPA mod of tokens making it into raider inventories, when there is a check in the ref walk that is supposed to ensure that tokens are only given to NPCs wearing power armor. If that's the case, and the ref walk checks occasionally fail for some reason, then the ref walk might occasionally try to add and equip armor on an actor like a feral ghoul or rad scorpion, something that can't equip armor. I've confirmed that that will cause a CTD. So it's better to handle that entirely within the object script, where things seem to be more predictable.

As I've been testing it, either non-NPCs are immune to the inventory change AI bug, or the bug only happens when items are equipped via script, not when they're just added to inventory. I'll test it out though, it would be good to know.

Also, the invalid form list entries that are left behind when a mod using this resource is uninstalled will cause scripts to crash if those form list entries are accessed or acted upon by either the ListGetNthForm or ListGetFormIndex commands. That's not a big deal in the first two above scripts, its been accounted for, but the way the third script is written, the call to ListGetFormIndex used to determine if the form is already in the list would crash the script, preventing the form from ever being added. So the way it should be written is with a simple "AddFormToFormList, stopquest".

» Sat Feb 19, 2011 4:02 am

Cipscis did a bunch of tests regarding script optimization, and reported the results in http://www.gamesas.com/index.php?/topic/987561-script-optimisation/. I think the verdict was that ref walks have significantly less of an impact on performance than silent explosions (though it might have been splitting hairs a little).

That's correct - reference walking is more efficient than the "silent explosion" method. The difference in efficiency was much larger than I would have expected, too. Here's a link to the post in which I've reported the results of my test - http://www.gamesas.com/index.php?act=findpost&pid=14295479

Just in case that post becomes removed at some point, due to the thread being dead since February '10, here's a (slightly altered) direct quote of the post:

I just tested reference-walking vs explosion placing again, this time using http://geck.gamesas.com/index.php/CastImmediateOnSelf to apply a scripted Actor Effect when an actor was found via reference-walking. Like before, I tested each section of code in both an uncrowded area and a crowded area.

In the uncrowded area, neither method produced a noticeable effect on performance until they were run 9 times per frame, when the explosion placing method caused framerate to decrease. The reference-walking method didn't have any effect on performance until it was called 15 times per frame. Here are the results for 9-20 iterations per frame:

Spoiler

Iterations		Reference-walking		Explosion placing9			59.38				54.6410			59.38				52.5211			59.38				44.5612			59.38				45.7913			59.31				39.5914			59.38				37.7115			56.56				36.0216			55.25				34.0817			56.95				31.7318			56.56				30.3419			51.18				29.9420			49.55				29.24

In the crowded area, the explosion placing method had a noticeable effect on performance when called only once per frame, and caused Fallout 3 to stop responding before the reference-walking method had any noticeable effect on performance (at 6 iterations per frame). Here are the results for 0-5 iterations per frame:

Spoiler

Iterations		Reference-walking		Explosion placing0			60.46				59.381			59.31				25.852			59.38				14.183			58.62				9.924			58.69				7.745			59.38				6.69

Both tests were carried out for 50 frames, and the average framerate was reported at the end of the test. There was also a 50 frame gap between http://geck.gamesas.com/index.php/StartQuest being called and the test beginning, as I've discovered that http://geck.gamesas.com/index.php/StartQuest seems to have a small effect on performance that continues for some frames after it is called.

This is the script that I used to perform the test:

Spoiler

ScriptName CodeComparisonQuestScriptint iCountint iFrameCountint iStagefloat fFrameRateint bInitialisedref rCurrentRefBegin MenuMode	if MenuMode 0		if MenuMode 1004			TapKey 41 ; ~ (console)		endif	endifEndBegin GameMode	set iCount to 0	if iStage == 0			elseif iStage == 1		Label 10		if iCount < IterationsPerFrame			set rCurrentRef to GetFirstRef 200 0 0 ; Actor			Label 20			if rCurrentRef				if rCurrentRef.GetDistance player < 40000					rCurrentRef.CastImmediateOnSelf TestActorEffect				endif				set rCurrentRef to GetNextRef				Goto 20			endif			set iCount to iCount + 1			Goto 10		endif	else		Label 30		if iCount < IterationsPerFrame			player.PlaceAtMe TestExplosion ; 40000 Unit radius			set iCount to iCount + 1			Goto 30		endif	endif	if bInitialised		if iFrameCount < MaxFrameCount			set iFrameCount to iFrameCount + 1			set fFrameRate to fFrameRate + GetSecondsPassed		endif	else		set bInitialised to 1		PrintToConsole "===================="		PrintToConsole "Code Comparison Test"		PrintToConsole "%g iterations per frame, %g frames" IterationsPerFrame MaxFrameCount		Return	endif	if iFrameCount == MaxFrameCount		set fFrameRate to iFrameCount / fFrameRate		if iStage == 1			PrintToConsole "%.2f fps - Reference walking" fFrameRate		elseif iStage			PrintToConsole "%.2f fps - Explosion" fFrameRate		endif		set iFrameCount to 0		set fFrameRate to 0		set iStage to iStage + 1		if iStage == 3			set bInitialised to 0			set iStage to 0			TapKey 41 ; ~ (console)			StopQuest CodeComparisonQuest		endif	endifEnd

"IterationsPerFrame" is a global variable that I altered manually from the console. Each test started when I called http://geck.gamesas.com/index.php/StartQuest from the console.

Cipscis

» Sat Feb 19, 2011 1:16 am

I notice the example above uses a cell depth of zero. One disadvantage of ref walks is that, in order to ensure that you're getting all of the references in the immediate vicinity, even if the player is near a cell border, you need to set the cell depth to 1 rather than 0, meaning 9 times the iterations. I haven't seen a noticeable performance hit from doing so, but that might be a better basis for comparison. But I guess I can infer the impact of a 9 cell ref walk from the data you've provided because you've called the single cell ref walks multiple times per frame. If 5 iterations of a ref walk has considerably less of an impact than 1 iteration of an explosion in a crowded area, I'd guess that at 9 iterations the ref walk is still not bad.

» Fri Feb 18, 2011 8:22 pm

I'm wondering the performance difference of just adding tokens to every NPC, then doing the checks you want OnAdd instead of trying to Ref Walk with a huge list of conditions and various other statements. If nothing else it seems like it would be less error prone, but my gut says it would be faster too. But then again maybe adding and removing items from inventories has more overhead then I would think :shrug:

And on the other discussion, I think CALIBR and CRAFT are the right direction, and about as far as you can go with the community mod type of thing, as has been said COBL didn't really work and in that perspective. TalkieToasters (or maybe its someone else's idk) Companion Core is another likely candidate and should also be made available shortly after NV releases for maximum effect; but I don't really see any other applications for stuff like that since everything else tends to be far to specific for each mod.

» Fri Feb 18, 2011 9:11 pm

I'm wondering the performance difference of just adding tokens to every NPC, then doing the checks you want OnAdd instead of trying to Ref Walk with a huge list of conditions and various other statements. If nothing else it seems like it would be less error prone, but my gut says it would be faster too. But then again maybe adding and removing items from inventories has more overhead then I would think :shrug:

Why should item add + condition check be faster than condition check alone? thats counter-intuitive. if you use tokens first an item has to be added, then every token script will have its own variable space, the scripts need to be scheduled and im sure there lots of other stuff going on.

as for ref walk vs explosion, i wrote it in another thread today, that you dont haven have to compare test results to know that it is faster (well to KNOW you actually have to test it

). All this ref data is in probably more or less optimized data structures in memory or even cached, and the operations are read-only. It doesnt get much more inexpensive than that.

» Sat Feb 19, 2011 3:10 am

And if I might add it's a much more simple and user friendly method since anyone how knows programming
can easily understand how it works. I was trying to figure out the explosion method for hours to no avail :brokencomputer:

I have a pretty strong CPU so for me running scripts isn't a problem.

The scripting necessary to achieve the ref-walk is not very difficult to write and there are a few excellent templates in
this site.

In my opinion, the problem in this kind of scripting is conflicting scripts. Imagine an NPC with 3 tokens, each telling him to do
a different thing. I am actually trying to overcome such an issue for an upcoming mod and it's giving me a headache.

If you could specify or reorder the various commands the token scripts handle with a utility, so that everything works as
expected (like a bashed token patch or something), now that would be something :celebration:

» Sat Feb 19, 2011 5:29 am

What I'm going for is to spread the code out over as many frames as possible, which means minimizing the amount of code in between the LABEL and GOTO lines in the ref walk script. Its just the one conditional that needs to go there, the one that checks to see if the token is already in the actor's inventory.

OTM's right about the conflicting scripts. If you've got two tokens both trying to tell the NPC what gear to equip its going to get messy, but I can't think of a way to resolve it other than laying out some guidelines for anyone using the resource - like, don't use anything like the following:

If rActor.getequipped rArmor == 0
rActor.equip rArmor
ENDif

You'd end up bouncing back and forth between gear if more than one token had something like that in it (of course thats almost exactly what I'd want to be doing in one of my mod ideas...).

Anyone have a sense for how long it will be before there's FOSE for New Vegas? Is it pretty simple to port the existing FOSE functionality over to a new incarnation of the engine? I'd like to release something like this for NV modders as early on as possible, but FOSE is sort of necessary. It'd be almost as useful if there was a resource that added a "use all" leveled list to the inventory of each NPC/creature type. It'd be tedious to set up, but would accomplish nearly the same thing.

» Sat Feb 19, 2011 3:36 am

I can think of a way but it's pretty heavy duty to write

The utility could add tokens with a naming convention (e.g. token1, token2, etc)
Based on that convention, priority could be given to e.g. lowest number token.

Now, the scripts on those two tokens can be compared and if they are using similar commands (eg. equiparmor)
the command with the lowest priority would be commented out since it's meant to be overridden anyway.

Since the modder knows what he's after, there could be some tags, similar to BASH. These tags would be the
type of reference concerned (e.g. RAIDER, SUPER MUTANT etc). Remember that we are talking about ref walk
so it's supposed to influence EVERYONE around the player given the desired filtering (using "IF" loops). This
filtering could be tagged in the utility.

For example:

if actor.getDead == 0              ;TAG ALL ALIVE ACTORSif actor != player                 ;TAG NOT PLAYERif actor.getDetected player == 1   ;TAG ALL ACTORS DETECTING THE PLAYERif actor.GetCombatTarget == Player ;TAG ALL HOSTILE ACTORS

Using these tags, the utility can decide whether it should comment out a command or not so that logical conflicts could be avoided in a batch process.

It's pretty late here so I hope I made some sense :hubbahubba:

» Sat Feb 19, 2011 5:19 am

Edit: Double post

» Fri Feb 18, 2011 5:28 pm

Why should item add + condition check be faster than condition check alone? thats counter-intuitive. if you use tokens first an item has to be added, then every token script will have its own variable space, the scripts need to be scheduled and im sure there lots of other stuff going on.

I was talking about ref walking not overall, it's unquestionably faster to just add an item to every NPC you come across then running a bunch of conditions on each NPC as you do it, as far as the speed of "aquiring" all the NPCs in the cell which seemed to be a problem, which I'm not gonna lie I initially was just glazing over the thread :laugh:. The question was more directed to the overall performance.

» Sat Feb 19, 2011 9:11 am

That was how I was handling the ref walks in Powered Power Armor - all of the conditionals were in the ref walk, but I had major stability problems, and problems with the conditionals failing. Moving as much as possible to the token script improved things significantly.

I tested out the AI glitch - you can add things to actor inventories during gamemode without a problem, but if you equip them the AI freezes. Good news in that it makes my scripts much simpler, but bad news when it comes to supermutants - I don't think you can tell them what weapon to equip via script, since you can't do the equip armor/remove armor bug fix on an actor that can't equip armor. But I think if you put a better weapon in their inventory they'll probably switch to it (just a guess).

Here's the code again, I think I'm ready to release once I've put together the documentation, unless somebody sees some glaring error or something that could be improved.

Spoiler

scn IAActorWalkerQuestScriptshort sUpgradeChanceshort sCounterref rCurRefref rArmorshort sWalkshort sCombatshort sEnableWalkbegin gamemode		IF IAREFCellMarker.getinsamecell player	; misc. item persistant ref., begins in AnchorageWM dummy cell		ELSE			set sEnableWalk to 1			IAREFCellMarker.moveto player		ENDif		IF player.isincombat == 0				set sCombat to 0		ENDif			IF sEnableWalk 		; if a ref walk has not yet happened since entering the cell			IF player.isincombat == 0 || (sCombat == 0 && player.isincombat) || player.getgrouptargetcount < 3 			; if player is outside of combat, or just started combat, or is in combat with fewer than 3 enemies				set sEnableWalk to 0				set sCombat to 1				set rCurRef to getfirstref 200 1 0		; actors, cell depth of 1, do not include taken refs (whatever that means)				LABEL 10					IF rCurRef						IF rCurRef.getitemcount IAPiggyBack						ELSE		; current ref does not have a PiggyBack token yet							rCurRef.additem IAPiggyBack 1				; token with list scanning script						ENDif											set rCurRef to apple										; fix for apple bug						set rCurRef to getnextref						GOTO 10					ENDif			ENDif		ENDifend

Spoiler

scn IAPiggyBackScriptshort sListLengthshort sListIndexshort sIndexref rContainerref rTokenbegin gamemode	IF sListLength == ListGetCount IAPiggyBackList	ELSE		IF rContainer			IF sListIndex < ListGetCount IAPiggyBackList				set sIndex to sListIndex				set sListIndex to sListIndex + 1				set rToken to ListGetNthForm IAPiggyBackList sIndex				IF rContainer.getitemcount rToken				ELSE					rContainer.additem rToken 1				ENDif			ELSE				set sListLength to ListGetCount IAPiggyBackList				set sListIndex to 0			ENDif		ELSE			set rContainer to getcontainer		ENDif	ENDif	end

» Sat Feb 19, 2011 1:57 am

That was how I was handling the ref walks in Powered Power Armor - all of the conditionals were in the ref walk, but I had major stability problems, and problems with the conditionals failing. Moving as much as possible to the token script improved things significantly.

Good to see I'm not completely stupid then :laugh:

I tested out the AI glitch - you can add things to actor inventories during gamemode without a problem, but if you equip them the AI freezes. Good news in that it makes my scripts much simpler, but bad news when it comes to supermutants - I don't think you can tell them what weapon to equip via script, since you can't do the equip armor/remove armor bug fix on an actor that can't equip armor. But I think if you put a better weapon in their inventory they'll probably switch to it (just a guess).

Here's the code again, I think I'm ready to release once I've put together the documentation, unless somebody sees some glaring error or something that could be improved.

Spoiler

scn IAActorWalkerQuestScriptshort sUpgradeChanceshort sCounterref rCurRefref rArmorshort sWalkshort sCombatshort sEnableWalkbegin gamemode		IF IAREFCellMarker.getinsamecell player	; misc. item persistant ref., begins in AnchorageWM dummy cell		ELSE			set sEnableWalk to 1			IAREFCellMarker.moveto player		ENDif		IF player.isincombat == 0				set sCombat to 0		ENDif			IF sEnableWalk 		; if a ref walk has not yet happened since entering the cell			IF player.isincombat == 0 || (sCombat == 0 && player.isincombat) || player.getgrouptargetcount < 3 			; if player is outside of combat, or just started combat, or is in combat with fewer than 3 enemies				set sEnableWalk to 0				set sCombat to 1				set rCurRef to getfirstref 200 1 0		; actors, cell depth of 1, do not include taken refs (whatever that means)				LABEL 10					IF rCurRef						IF rCurRef.getitemcount IAPiggyBack						ELSE		; current ref does not have a PiggyBack token yet							rCurRef.additem IAPiggyBack 1				; token with list scanning script						ENDif											set rCurRef to apple										; fix for apple bug						set rCurRef to getnextref						GOTO 10					ENDif			ENDif		ENDifend

Spoiler

scn IAPiggyBackScriptshort sListLengthshort sListIndexshort sIndexref rContainerref rTokenbegin gamemode	IF sListLength == ListGetCount IAPiggyBackList	ELSE		IF rContainer			IF sListIndex < ListGetCount IAPiggyBackList				set sIndex to sListIndex				set sListIndex to sListIndex + 1				set rToken to ListGetNthForm IAPiggyBackList sIndex				IF rContainer.getitemcount rToken				ELSE					rContainer.additem rToken 1				ENDif			ELSE				set sListLength to ListGetCount IAPiggyBackList				set sListIndex to 0			ENDif		ELSE			set rContainer to getcontainer		ENDif	ENDif	end

I haven't done much with the AI so out of curiosity what is this bug you guys keep talking about that you have to equip an item when you add it to the npc?

» Fri Feb 18, 2011 8:16 pm

If you add something to an NPC's inventory and then equip it, via script, during gamemode, they'll just stand there with a stupid look on their face from that moment forward. But if you then equip an extra item - I use a model and slotless piece of armor - and remove it, it triggers an inventory reevaluation or something, and they'll go back to normal (shooting at you or whatever).

» Sat Feb 19, 2011 8:14 am

Why do you need to equip the item (assuming we are talking about tokens here...)?

» Fri Feb 18, 2011 7:42 pm

The token doesn't need to be equipped, but if the modder wants to use the script that's running on the token to change the NPC's equipped gear, its something they need to be aware of.

I went ahead and uploaded it, http://www.fallout3nexus.com/downloads/file.php?id=14342

» Sat Feb 19, 2011 8:08 am

I see, well good info to know if I do anything like that in the future