Need help with a simplified Mannequin Mod

Post » Sat May 28, 2011 1:32 pm

I've posted what I have so far, here : http://www.fallout3nexus.com/downloads/file.php?id=13560

Goal: I am trying to make one mannequin that can be placed as many times as wanted without the need for a Quest(optional, but prefer to avoid it) or scripts that reference specific Base IDs.

If you don't want to check that out, here is what I am having trouble with ...

1. The Mannequins seem to loose track of the fact that they have weapons sometimes. If I leave the cell they are in and come back, sometimes they have their weapons as they did when I left, sometimes they don't and have to be reactivated to show them. (the weapons are still in inventory, just not worn if missing)

2. The damn mannequins have a tendency to fall through the floor. I think this is related to having them activate their AI (so that they properly re-arm their weapons) then deactivating them again (so they "freeze"). I tried to solve this with a SetPos based on GetStartingPos (with a set of floats to store it) but all it did was make them disapear, I assume because they went to 0,0,0).
User avatar
mike
 
Posts: 3432
Joined: Fri Jul 27, 2007 6:51 pm

Post » Sat May 28, 2011 9:25 am

1. The AI Package you have on the NPC, do you have the 'weapon drawn' check box on the 'Flags' tab checked?
2. Did you put down a navmesh? The AI on NPC's look for the navmesh so it knows where the floor should be.
User avatar
laila hassan
 
Posts: 3476
Joined: Mon Oct 09, 2006 2:53 pm

Post » Sat May 28, 2011 7:54 am

1. The AI Package you have on the NPC, do you have the 'weapon drawn' check box on the 'Flags' tab checked?
2. Did you put down a navmesh? The AI on NPC's look for the navmesh so it knows where the floor should be.


1. I have 2 packages that it toggles between, one drawn, one on the back. both work fine while I am in the cell. If I leave the cell and come back, they seemingly randomly (I am sure it isn't, there must be a way to script this properly, but I am still quite novice), they sometimes put the weapon back into inventory. When I come back, those who had the weapon on their backs now don't, and I have to re-activate them to put it back. Those with weapons armed sometimes also put the weapon back in inventory, and instead have fists raised. I thought I resolved this by giving them ammo (since when I hadn't before, they would never arm the weapon) ... there seems to be some other issue.

2. there is a navmesh. I am testing this in the megaton player house, where other NPCs haven't had any trouble walking around.
User avatar
Kristian Perez
 
Posts: 3365
Joined: Thu Aug 23, 2007 3:03 am

Post » Sat May 28, 2011 12:47 pm

Maybe try setting them up so they automatically re-enable their AI, EVP, and disable AI each time the player enters the cell they're in.
Possibly...
short PlayerNearBegin GameMode  if (PlayerNear == 2)    SetActorsAI to 0    set PlayerNear to 1  endif  if (PlayerNear == 0) && (GetInSameCell Player == 1)    SetActorsAI to 1    evp    set PlayerNear to 2  endif  if (PlayerNear == 1) && (GetInSameCell Player == 0)    set PlayerNear to 0  endifEnd


I'm thinking the issue is probably because equipped/held weapons depend on the AI functioning (initially), so when you disable it and then leave and come back, the AI is still off when they and the cell they're in reloads... so no weapon gets placed.
User avatar
Robert Jackson
 
Posts: 3385
Joined: Tue Nov 20, 2007 12:39 am

Post » Sat May 28, 2011 8:17 pm

I'm thinking the issue is probably because equipped/held weapons depend on the AI functioning (initially), so when you disable it and then leave and come back, the AI is still off when they and the cell they're in reloads... so no weapon gets placed.


I had something similar to this theory in my original script, and it was a bit flakey... I looked at yours and made a few changes so it was easier for me to follow what was going on... Now it's working a lot better. still some issues. If I leave and come back multiple times, about 3/4 the time they are in the right pose, frozen, where they should be, and about 1/4 the time they have either fallen through the floor a little, or a lot (can't see them at all), and in a mix of either the wrong pose, the gun stuck to the side of their hand, legs all scrunched up, etc... doesn't seem to make a difference if I leave the cell for 1 second or 3 days, or anything in between.
They also seem to not go into the right pose after re-entering the cell for the first few times. After leaving and coming back 3-4 times it seems like about a 25% failure rate. An improvement, but hardly ideal. When they mess up, it's usually all 3 of the test mannequins I have out, very rare for the problem to be with just one of them. Does this suggest a timing issue? Script Lag?

current attempt at the script:

scn BIDMannequinScript01short Alertfloat Timershort StartTimershort Posedshort PlayerIsLocalbegin OnLoad	if Posed == 0		SetActorsAI 1		set Alert to 0		AddScriptPackage BIDMannequinWeaponHolsterPACKAGE		EVP		set Posed to 1		set Timer to 3		set StartTimer to 1	endifendbegin OnActivate	if IsActionRef Player == 1		SetPlayerTeammate 1		set Posed to 1		SetActorsAI 0		OpenTeammateContainer		if Alert == 0			AddScriptPackage BIDMannequinWeaponDrawnPACKAGE			set Alert to 1		elseif Alert == 1			AddScriptPackage BIDMannequinWeaponHolsterPACKAGE			set Alert to 0		endif		AddItem BIDMannequinAmmoList, 1, 1		SetActorsAI 1		evp  ;EvaluatePackage		set Timer to 3		set StartTimer to 1	endifendbegin GameMode	if  PlayerIsLocal == 0		if GetInSameCell Player == 1			AddItem BIDMannequinAmmoList, 1, 1			SetActorsAI 1			evp			set PlayerIsLocal to 1			set Timer to 3			set StartTimer to 1		endif	elseif PlayerIsLocal == 1		if GetInSameCell Player == 0			set PlayerIsLocal to 0		endif  	endif	if StartTimer == 1		if Timer > 0			set Timer to Timer - GetSecondsPassed		else			Set StartTimer to 0			SetActorsAI 0			SetPlayerTeammate 0			RemoveItem BIDMannequinAmmoList, 100, 1		endif	endifend


I'm slightly tempted to do away with the dialogue exchange and just have the mannequin get a copy of whatever the player is wearing. not lootable, but just makes a copy. any comments? bad idea? Usage would be like... every Activate replaces current outfit on the mannequin with a copy of what the player is wearing, activation would also toggle between alert and non-alert poses. I just want to keep this as a simple thing, prefering no dialogue / menus, etc.
User avatar
Heather Dawson
 
Posts: 3348
Joined: Sun Oct 15, 2006 4:14 pm

Post » Sat May 28, 2011 8:28 pm

Your OnLoad block code only runs if Posed == 0, and nowhere in there do you ever set it back to 0, so it only runs on the first cell load and never again.
User avatar
Emmanuel Morales
 
Posts: 3433
Joined: Sat Oct 06, 2007 2:03 pm

Post » Sat May 28, 2011 6:30 am

Your OnLoad block code only runs if Posed == 0, and nowhere in there do you ever set it back to 0, so it only runs on the first cell load and never again.


I did that on purpose. to set at least some kind of pose for the first time someone interacts with them. Is this not a good way to deal with it?
User avatar
Matthew Aaron Evans
 
Posts: 3361
Joined: Wed Jul 25, 2007 2:59 am

Post » Sat May 28, 2011 2:35 pm

I did that on purpose. to set at least some kind of pose for the first time someone interacts with them. Is this not a good way to deal with it?


Oh yeah that's fine, but I'm thinking since the OnLoad block runs every time the player enters the cell (first time or not), should probably take advantage of it. Try this...
Go to the armor list and R-click and make a new, blank armor. Give it the ID of "TestArmor" and whatever name you like. Set the weight to 0, under the type dropdown box set it to 'bodywear', and in the tall equip spot list select 'spare body slot 3'.. then ok and save it.
And this is for the mannequins...
scn BIDMannequinScript02short Alertfloat Timershort StartTimershort PickPackage    ;** -1 = off, 0 = no change, 1 = change **Begin OnLoad      Set PickPackage to 0      ;send to reapply current selected packageEndBegin OnActivate  if IsActionRef Player == 1        Set PickPackage to 1      ;send to apply newly chosen package  endifEndBegin GameMode  if (PickPackage > -1)      SetActorsAI to 1    ;processing ON so changes will stick      AddItem BIDMannequinAmmoList, 1, 1      ;ammo for equip weapon      if PickPackage == 0      ;***reapply package with no change***          if Alert == 0                AddScriptPackage BIDMannequinWeaponHolsterPACKAGE              set Alert to 1          elseif Alert == 1              AddScriptPackage BIDMannequinWeaponDrawnPACKAGE              set Alert to 0          endif      endif      if PickPackage == 1     ;***reapply package with a new one***          if Alert == 0                AddScriptPackage BIDMannequinWeaponDrawnPACKAGE              set Alert to 1          elseif Alert == 1              AddScriptPackage BIDMannequinWeaponHolsterPACKAGE              set Alert to 0          endif      endif      Set PickPackage to -1      ;turn off pick function      evp       ;re-eval newly acquired script package      AddItem TestArmor 1 1      EquipItem TestArmor 0 1      set Timer to 3      set StartTimer to 1      ;send to timed shutdown part  endif  if StartTimer == 1      ;** Timed Shutdown Part**      if Timer == 2          RemoveItem TestArmor 2 1      endif      if Timer > 0          set Timer to Timer - GetSecondsPassed      else          Set StartTimer to 0    ;clear var          Set Timer to 0      ;clear var          SetActorsAI 0      ;shut off processing          RemoveItem BIDMannequinAmmoList, 100, 1      ;remove excess ammo      endif  endifEND


Every OnLoad should just reaffirm what they were already doing, and every OnActivate should get them to switch to the opposite package. Processing gets turned on right after OnLoad or OnActivate starts, it gets passed off to the timer, and then shuts it down.
The blank, invisible armor thing is an equip trick that helps NPCs re-evaluate inventory, AI, weapons, and animation glitches.. it's invisible and you won't see anything so pay it no mind.
User avatar
Chris Guerin
 
Posts: 3395
Joined: Thu May 10, 2007 2:44 pm

Post » Sat May 28, 2011 9:18 am

I've been playing with a few ways to do all this stuff, and I keep coming back to one fundamental problem. I can't seem to figure out a way for the Mannequins to detect when I enter the cell.

I have them working the way I want when I first load a saved game into the cell, since that triggers the OnLoad. If I leave the cell for a long time, or travel through a few other cells, that seems to "disconnect" me from the cell, allowing me to reset them properly, but if I exit, then come back in, they have reverted back to a standing, unarmed position (no weapon showing).

If I can't use OnLoad to detect this, and I can't use "if GetInSameCell Player == 0" to detect when I leave, allowing me to use "if GetInSameCell Player == 1" to compare against it ( I have tested this by leaving and entering the same sell over and over and it only seems to trigger once out of maybe every 5-6 times I leave the cell, when I come back on the rare occasion that it does work, the Mannequins are set up perfectly), how do I get them to reset when I re-enter the cell?

The only thing I can think of is having a trigger at the entry point of the cell to force them to reset properly. I'd prefer not to do it that way, and suspect there must be a better solution.
User avatar
Aman Bhattal
 
Posts: 3424
Joined: Sun Dec 17, 2006 12:01 am

Post » Sat May 28, 2011 8:26 pm

If you used the script I posted above, then getting them to reset on one of those short re-enters wouldn't be much more than adding this to it..
Add back the variable 'short PlayerIsLocal' like you had..
and at the bottom, inside the GameMode block, paste in..
if (PlayerIsLocal == 0) && (GetInSameCell Player == 1)    set PickPackage to 0    set PlayerIsLocal to 1endifif (PlayerIsLocal == 1) && (GetInSameCell Player == 0)    set PlayerIsLocal to 0endif

GetInSameCell will work for this kind of check.. no problem. I use it in exactly this same wording all the time. I spaced including this part in that last script because.. well.. i was on about 22 hours uptime when I threw that together. If for some reason using GetInSameCell isn't working (though I've never seen it not work the way it should), you can switch that function out for a (GetDistance Player < 2048) for the first one, and the same only > 2048 for the second one to make it work.
The problem is having to use a powerful and disruptive function like SetActorsAI 0 for something like this, but I see why it's necessary.
What i pasted above should fix the problem for those short returns into the cell, where they get all stupid because they didn't have a proper cell reload.
User avatar
Hilm Music
 
Posts: 3357
Joined: Wed Jun 06, 2007 9:36 pm

Post » Sat May 28, 2011 12:37 pm

I tried this and some variations of the GetInSameCell stuff and it still doesn't seem to reset on re-entry :brokencomputer:

BUT!

The GetDistance stuff works like a charm. This will do what I need it to do. Thanks for all the help on this. I'll test a bit more then post on the nexus for anyone who wants to add Mannequins to their builds.

ok... so I did a little more research, adding messages to the different steps of what's going on. I take it scripts get a much lower priority when you're not in the cell with them?

when I leave the cell, the part of the script containing the GetDistance line would sometimes trigger 3-4 seconds after I exit, sometimes staggered as much as 2-3 seconds between each of the ones I have in the cell (I have 3 test Mannequins out), or sometimes it won't trigger at all. This appears to be the case with the GetInSameCell, or probably anything contained within the GameMode block.

And since the script isn't getting any kind of priority, it probably isn't getting cleaned out so that the OnLoad can retrigger.

This low priority may not be an issue on a Quest Script, since those don't seem to be effected by this (as far as I can tell). When you said "I use it in exactly this same wording all the time", do those happen to be Quest scripts?
User avatar
Angus Poole
 
Posts: 3594
Joined: Fri Aug 03, 2007 9:04 pm

Post » Sat May 28, 2011 10:44 am

I started messing around with mannequins recently and it worked great until i left the cell and re-entered - then they were usually in the floor or far above it or contorted into a pretzel.

The OnLoad bit only worked if I visit a few other cells and then re-enter the cell with the mannequins.

I'm trying to get away from having a quest script that checks each of them to see if they're in the same cell as the player for a slightly different reason than delay. But, like Messmer - I'm just wondering if there's a consistently reliable way to detect player re-entry without a quest script? Seems like that would alleviate the problem for us both :)

Like put a script on the door that changes a quest/global var to 1 when the player enters a room with mannequins. In the room is an activator that checks that val for 1, activates itself and then changes it to 0. If all the mannequins in the room have their activate parent set to this activator, you could check for it's id.

scn GenericMannequinDoor; door leading to cell containing mannequinsBegin OnActivate	if IsActionRef Player == 1 && SomeVar == 0		set SomeVar to 1	endif	ActivateEndscn GenericMannequinActivator; activator in same cell as mannequins and is all of their activate parentsref MySelfBegin GameMode	if SomeVar == 1		set MySelf to GetSelf ; or onload		Activate MySelf		set SomeVar to 0	endifEndscn GenericMannequin; a mannequinref ActionRefBegin OnActivate	if IsActionRef Player == 1		; normal stuff	else		set ActionRef to GetActionRef		if ActionRef.GetIsID GenericMannequinActivator == 1			; player is entering the cell		endif	endifEnd


Seems like there would be a simpler way though? :shrug:
User avatar
john palmer
 
Posts: 3410
Joined: Fri Jun 22, 2007 8:07 pm

Post » Sat May 28, 2011 12:20 pm

Seems like there would be a simpler way though? :shrug:


I thought about activators, and it seems like that may be the only way to get this done right. I was primarily thinking of doing it as a collision based activator, so if the Mannequins are set someplace deep within a build, they can be triggered to reset at whatever stage the builder wants, or the collision box or whatever can be put right at the entry of the cell. That way it doesn't have to use up a door script slot.

The frustrating part is the inconsistency of OnLoad or detecting distance. it seems like these things should behave the same way every time. I REALLY want to avoid using anything that requires specific references to specific mannequins. I by far prefer to keep this simple enough so people can simply drop in as many as they need without having to do a lot of prep / setup.
User avatar
Bee Baby
 
Posts: 3450
Joined: Sun Jun 18, 2006 4:47 am

Post » Sat May 28, 2011 9:48 am

I take it scripts get a much lower priority when you're not in the cell with them?

When you said "I use it in exactly this same wording all the time", do those happen to be Quest scripts?

Yeah they do get a lower priority. Making sure they're persistant references and set to 'no low level processing' seems to help.. although I'm pretty sure it won't help much when the AI processing's turned off.
Perhaps there may be a way to use a combination of PlayIdle, unconscious, and whatnot while leaving the AI on. I'd think you could interrupt any dialog right in the OnActivate block.

Some are in quests, but some are also on NPCs, objects, activators, doors, etc.. All persistant references, but beyond that I really don't know.
User avatar
(G-yen)
 
Posts: 3385
Joined: Thu Oct 11, 2007 11:10 pm

Post » Sat May 28, 2011 8:31 pm

I think I've come up with a solution that still keeps things relatively simple to set up, but also works the same way every time. What I ended up doing was making a cubic activator, putting this script in it

scn BIDMannequinTriggerSCRIPTfloat TimerBegin onTriggerEnter Player		set Timer to GetSecondsPassed		Disable		set Timer to 2	endifEndbegin GameMode	if timer > 0		set timer to timer - GetSecondsPassed	else		Enable	endifend

I put the "set Timer to GetSecondsPassed" to set an initial call since the way the function is described is by referencing the last time it was called. I figured without that it'd add a second to the process, and I want these to be relatively quick. I noticed less than 1 second on the timer had a tendency to not move on to the enable section.
...

the mannequins have this script in them, and are Just linked to the cube, the cube being their enable parent

scn BIDMannequinScriptshort Alertfloat Timershort StartTimershort Busyshort ammoBegin onload	set Busy to 1	set ammo to 0endbegin onactivate	if IsActionRef Player == 1		if Busy == 0			set Busy to 1			SetPlayerTeammate 1			SetActorsAI 0			OpenTeammateContainer			if Alert == 0				AddScriptPackage BIDMannequinWeaponDrawnPACKAGE				set Alert to 1			elseif Alert == 1				AddScriptPackage BIDMannequinWeaponHolsterPACKAGE				set Alert to 0			endif			set ammo to 0		endif	endifendBegin GameMode	if ammo == 0		set ammo to 1		AddItem BIDMannequinAmmoList, 1, 1		SetActorsAI 1		if Alert == 1			SetAlert 1		elseif Alert == 0			SetAlert 0		endif 		evp		set Timer to 3		set StartTimer to 1	endif	if StartTimer == 1      ;** Timed Shutdown Part**		if Timer > 0			set Timer to Timer - GetSecondsPassed		else			Set Timer to 0      ;clear var			SetActorsAI 0      ;shut off processing			RemoveItem BIDMannequinAmmoList, 100, 1      ;remove excess ammo			Set StartTimer to 0    ;clear var			set Busy to 0      		endif	endifEND


I suspect this can be streamlined further, but this works by simply placing the Cubic Activator at the entry to the cell, as the Enable Parent to all the Mannequins forces the OnLoad cycle. I did have to put the whole If Alert SetAlert thing in, because when disabled, then enabled, they reverted back to a standing (not alert) position. Other than having to make a Cubic Activator and linking up the Mannequins, the setup doesn't require much. This method also cuts out a lot of the processor intensive and unreliable aspects of the other attempts. Maybe this technique would be useful to others trying to figure out how to get uncooperative, low priority things to work out.

I'm going to test this a bit more then post the .ESP on the nexus for anyone who wants some simple to use and implement mannequins in their mods

I think the only thing that'd make this more ideal, at least to me, would be to be able to detect and add ammo based on the weapon, somehow referencing the ammo needed by the weapon, instead of having to use a form list. So it'd be compatible with all DLCs and user mods. As it is right now, if using vanilla weapons, no ammo needs to be added because it gets sneaked in, otherwise, ammo does need to be added.
User avatar
Natalie J Webster
 
Posts: 3488
Joined: Tue Jul 25, 2006 1:35 pm

Post » Sat May 28, 2011 2:17 pm

Damnit.... ok... so I got these Mannequins working how I wanted. I have a vault I am working on, and wanted to place these within it. I have the Mannequins listed before the Vault ESP I'm working on. I place the Mannequins, set up all the references, having them all persistent, and for some reason, after saving, they don't show in the vault. If I close the GECK, then reopen the vault ESP, the mannequins I placed are no longer in there, and the Vault ESP doesn't have the mannequin mod as a dependent. Yes I have the vault ESP set as active. It doesn't matter if I connect up the trigger or not.

Anyone have any idea?

edit: I went through with FO3Edit and saw that there were still a lot of phantom references to objects placed that I had removed. I cleaned these things out, and still had the problem. I then decided to try converting the ESPs to Master files with FO3Edit, and for whatever reason, in that process, it caused the mods to work, objects placing fine. Something occurs in this conversion, because even changing the flags back to ESP, non-master, the mods continue to work. Does anyone understand how FO3Edit fixes things, or do most assume it's magic and just be happy with the results?
User avatar
TASTY TRACY
 
Posts: 3282
Joined: Thu Jun 22, 2006 7:11 pm


Return to Fallout 3