zeidrich

Containers that are not set to respawn should hold your gear in them forever unless they're affected by some other script. The way you can test in-game if a container is set to respawn is to put an item in it, leave the cell completely (travel to some other interior cell to be safe, like, go chill with the Doc in goodsprings) wait at least 73 hours, go back and see if your stuff is still there. If your stuff is still there after you have been away from the cell for 73 hours, it is safe to store things in. A good place you can get access to early is the Prospector's Den: http://fallout.wikia.com/wiki/Prospector's_Den I used that as my home base for an entire playthrough. You have to clear it out of raiders at first, but after that your stuff is safe to store in a case that's marked "Storage Area". It also has an ammo reloading bench in it. I would say in New Vegas, the majority of containers are actually no-respawn. Not all of them though. Especially containers with junk, or empty containers that would normally contain junk are risky, as they're the most likely candidates to be set to respawn. Also, you have to be a bit aware of NPC behavior. NPCs generally don't do anything when you're not in their cell, but if they have sandboxing turned on they are liable to do things like steal food from your container, or possibly grab a weapon. You don't have to really worry about things disappearing when you're off halfway across the world, because all that AI doesn't get processed, but if you're in the room there with them, they might go over and eat your bloatfly slider or grab your fat man if you're not paying attention depending on their AI package. Abandoned areas with non-respawning containers and no funny scripting are pretty safe though. Do the 3 day test first, and if it passes, it should be fine forever.

Fallout 1 was in California. Fallout 2 was in California. Fallout 3 was done by a completely different group and was in DC, New Vegas was done by a bunch of the original team and it was in Nevada, right along the border to California. Most of the story of the game comes from around California. Utah, Arizona, New Mexico and Colorado make up the 4 States Commonwealth. From New Vegas there's a little bit of story about the followers of the apocalypse in New Canaan, Caesar's Legion comes from Flagstaff in Arizona. There's a lot of stuff that was written for Van Buren that was based around this area too. Brotherhood of Steel has people over there, and throughout the New Vegas story a lot of people headed east as they got pushed out of the desert by the creeping NCR. I'd expect and hope that if there's another fallout that it follows up in those states. There's just so much story to tell there, I'd be interested to see it play out. I'd be interested to see a game where NCR is cast more as the bad guy. New Vegas was kind of edging onto that scenario, where the NCR was taking land and power for it's own sake despite it's inability (due to lack of resources, and leadership) to govern those resources fairly. Maybe a situation where Caesar is dead, the Legion is scattered, but has instilled some strong and potent structure within some of the tribal communities out East. The NCR holds the Dam and that gives them resources to continue to conquer Eastward, and the remnants of the Legion have become reasonably civilized, structured communities trying to hold out against the Martial Law brought by the NCR. I think one of the things I find a bit interesting is the idea that the NCR have, up until New Vegas, sort of perennially been the "good guys". I kind of also like the irony that you helped set it up in the first two fallout games, and that it's kind of what becomes the big bad thing eventually. But that makes sense; the big bad Enclave was originally from the US government, but they were formed from the people in power trying to consolidate and maintain power. NCR is starting to behave the same way, seeking opportunities for growth and increasing their power (IE: Hoover Dam) with less consideration of the repercussions (IE: Martial Law and Bitter Springs).

There's a sentry-bot toy in the game files. You could do something similar with the NCR or BoS NPCs, and have them pop out when you activate them in your inventory and follow you around. Bonus points would be to add both NCR action figures and Caesar's Legion action figures, and script them to fight each-other when they are both out together.

I'd say try this: 1 - Set your monster to essential (http://geck.bethsoft.com/index.php/SetEssential). 2 - Periodically (I'm not sure if OnHit works for this as the geck wiki says it's attached to weapons now?) check the monster's PerceptionCondition (Head Health) http://geck.bethsoft.com/index.php/Stats_List , http://geck.bethsoft.com/index.php/GetActorValue 3 - If the monster's head health is below a certain threshold, set your monster as no longer essential. 4 - Optionally, run KillActor 1 to automatically dismember the head and kill the monster. (Otherwise you'd basically cripple the head, and then be able to kill it by any general means) 5 - Optionally, constantly set the health of the monster back to full. This will prevent regular damage from knocking the monster unconscious. How exactly you implement the monster dying is up to you. But I think the general way I'd do it is set the monster as essential, and then set him as unessential once the head is crippled. I'd probably use the OnHit blocktype on the actor's script and see if it works, but the wiki is a little confusing on that point. If that doesn't work you might have to do it in a GameMode block, which would be kind of annoying to sync up. Not sure.

Hi Kagstrom, First of all, don't have an Enable Parent set on either your door or your switch. It's just going to confuse things. You mentioned it in one of your other posts and I don't think you really knew what it meant. What an Enable Parent does is just tells the object whether or not it is enabled based on whether it's parent is enabled. If you have that set and you aren't actually using it that way you might end up with your door disappearing when you're not expecting it or something. In any case it's unnecessary. What you want to do, is have your activator run a script that sets the door to be open. The simple way to do this: Set your door to be a Persistent Reference, and give it a proper Reference ID. In your activator script, in an OnActivate block, use GetOpenState to see if the door is open (1) or closed(3), and use SetOpenState to open (1) or close (0) it. The more complicated way to do this: Make a generic script, similar to the ones in the Useful Scripts link above. Attach that script to any door switch that you make. Then ensure that your activator has its Linked Reference set to the door that you want to open. Instead of using the reference name, you use GetLinkedRef to set a ref variable to the door, but otherwise you do it the same way. The Useful Scripts that was linked above is probably confusing because it has more complicated things than you're trying to do. What you're trying to do is very simple. Very Simple Way: (Your door has a reference id of MyDoorREF) ScriptName MyDoorSwitchScript Begin OnActivate If MyDoorREF.GetOpenState == 3 MyDoorREF.SetOpenState 1 Elseif MyDoorREF.GetOpenState == 1 MyDoorREF.SetOpenState 0 Activate End Still Simple but more convenient way: (Your door is set to the Linked Reference of the activator) ScriptName DoorSwitchScript ref door Begin OnActivate set door to GetLinkedRef If door.GetOpenState == 3 door.SetOpenState 1 Elseif door.GetOpenState == 1 door.SetOpenState 0 Endif Activate End One thing to mention, if you're having trouble linking a reference, make sure that the object your trying to link to is set as a Persistent Reference.

If it won't save, it's because of a compile error. Unfortunately it won't say which line is in error. Remove each line one at a time and see what will allow you to save. My best guess is that it's your reference names. The fact that they are formatted like 000 and 000a might mean the compiler isn't sure if it's a reference name or the hex value of the object and is screwing it up. Try to give them more standard names maybe? I know that other people have had issues like that in the past.

Hi Orc, What Davidlallen said will help you, but I'll give you some more info as to how I'd go about doing it. http://geck.bethsoft.com/index.php/OnAdd - When you attach a script with an OnAdd block to an item, that block runs when the item is added to any container or inventory. You can have it when it is added to a specific container by adding a parameter to the block, otherwise it runs any time it's added to any inventory. For instance: scn MyNewSchematicSCRIPT begin OnAdd player AddNote MyNewSchematicNote player.RemoveItem MyNewSchematic 1 end Attaching the previous script to an item called MyNewSchematic will, when added to the players inventory, (whether picked up, purchased, or added through a script) add the MyNewSchematicNote to the player, and then immediately remove the MyNewSchematic item. If you want to add the note via a terminal, you have just the terminal selection run the script: player.AddItem MyNewSchematic 1 which should add the schematic to the player's inventory. The schematic's attached script will then run, adding the note to the player, and removing the item from the player's inventory.

Hello, I'm having a problem and I wonder if anyone has had the same problem before. Basically, in the mod I'm working on, you change the environment a bit depending on options you choose in the quest. In this case you choose to employ a Maize Farmer, and he, and his Maize appears in what was otherwise an abandoned house. The way I wanted to do it was this: I create an xmarker, the NPC, and in this case 5 Maize objects (2 activators, 3 statics). I set the NPC and Maize to all have the xmarker set as the Enable Parent. This works just fine, if I disable the xmarker, the corn and the NPC disappear. If I enable the xmarker again, the corn and NPC reactivate. The problem I'm having is this: If I set the xmarker to be Initially Disabled, the game crashes on start up. Before it gets to the title screen, before I can load a game, whatever. If I set the xmarker to be enabled, but set the 6 objects to have their enable state opposite the Enable Parent, the game crashes. If I set the xmarker to be disabled, and set the 6 objects to have their enable state opposite the Enable Parent, the game runs fine. So I thought maybe you couldn't have an Enable Parent with all of it's child objects initially set to a disabled state. I tested the xmarker to be initially enabled, the 6 original objects with their Enable Parent set to the xmarker, and 2 more statics (boards over a door) set with the xmarker as the Enable Parent, but with their enable state opposite the Enable Parent. This again worked fine. However, I set the xmarker to be initially disabled, so the 6 objects should be disabled (corn and NPC) but the boards on the door should be enabled initially, and the game still crashed. Eventually, I worked around it by just leaving the xmarker initially enabled, with all the objects set to the same state as the xmarker, and disable the parent in a gamemode block when initializing the quest. But I'd really rather not do it that way, in case for some reason that initialization doesn't run, or something funny like that. (In my limited experience with the TES engine you can't really expect anything to work in order, it typically seems to run correctly and completely when it runs, but always seems to be a chance that it wont run when you expect it to or at all) Does anyone know why it's doing that to me, or if there's a way around it (other than the way I'm doing it). I'll probably just have a sort of timed heartbeat that just makes sure the enable states of everything are set correctly as per quest objectives, but it just seems like that's excessive given what I'm trying to do seems like it should be straightforward.