mfree80286

(TLDR need help connecting 16 mod/new settlements to each other, and to external container in another cell, in CK) I've read quite a few threads here from others finding solutions to their particular issues, but I'm doing something a bit different and that will need a little different solution, I think. This is for an upcoming update to Vault 201 - Skeleton Crew, http://www.nexusmods.com/fallout4/mods/23634 I'm not going to dive in to what I've tried yet because I may or may not have been on the right path and don't want to color any of the potential responses. So, this is what I have and what I want to do: - There are 16 settlement cells in the vault, each treated separately. That means obviously that each has it's own unique workbench and resource container. They have been "treated" as external workshops due to the size of them and desired capabilities. - There is another interior cell that is loaded with items and resources, but is one extra interior cell zone away, and the path isn't short. Warehouse upper level to warehouse lower level by a long walk down a ramp, then zone via load elevator to Vault Core, which each of the 16 cells attaches to in 4 levels and there's a narrow stairway to get down to each of 4 levels. That's a long, long, LONG walk. - Connecting cells via provisioners works fine, but takes a settler per connection and introduces brahmin into the vault.... a bit odd, in my opinion. - Provisioners still don't solve the issue of having a fortune in resources a LONG distance from where they're needed. What I want to accomplish: 1 - connect the inventories of all the cells together, by whatever is the best method (star, ring, etc), and 2 - link that pooled inventory to a container inside the warehouse, so the player can load 100 steel and immediately use it in whatever vault cell they're working on. I am open to turning the warehouse cell build-able if that makes the process easier; I'm not good with scripting so accomplishing this with the right keywords/links in the right places would be a huge bonus. So.... ideas?

It may slow adoption on two platforms, *but*, this seems like a handy sidestep to Sony's disallowance of external assets. Curated content on a completely different format from the public mods, how exactly could Sony say no to this?

Well, this is for the first expansion to my Vault 201 mod, it's 'Black Site Epiales'. Story's still all in my head, but so it goes: This is a facility where all the captured suspected Chinese and foreign operatives were brought, interrogated, and tested. Tested? Medically, yes. Those with certain results are tasked to different categories. If they were determined to be of no intelligence value, some were shipped live or 'intact' to various other facilities, others were 'resourced', and others deemed unsuitable were simply euthanized and disposed of in the facility incinerator. Those 'resourced' were basically parted out for transplant and research materials. Acula Med Transport handled a lot of the local shipping, DOD did the more remote moves. One of the big bonuses to operating this way was that the entirety of the blood content of the subject could be retrieved and utilized, so there was a lot of shipping of whole blood to local facilities. There were some inconsistencies in inventory at one of the local hospitals, and the founder of AMT was on-site (already having been read in to the program) to state his case and help with the investigation. That's when the bombs dropped, and that's when the older reactor in the facility's lowest level went prompt critical and popped it's top off, absolutely bathing everything with a lethal amount of radiation.... and you know how that goes in this game. You may very well find AMT's founder "alive" in the facility, surrounded no doubt by lots of empty blood packs and organ containers, but you're not likely to get much else beyond grunts and roars from our esteemed and rather ghoulish Dr. Vladimir Acula... which is the crux of the logo, btw... not only is the upward arrow a symbol of ambition, consider that old nickname 'Vlad the impaler'. Turn it upside down and there are two red fangs under the red cross in the leading A, that arrow now pointing to the depths of hell... EDIT: Other work that continues is Prison Clothes, faded orange shirts/slacks, and I've managed to get orange rags on ferals. I have lots of notes to write but the plot's laid out and the list of facilities and such are made and waiting, the facility's done in floorplan and just needs fluff and inhabitants, made a red phone for the 'secure line', and I'll have to plant some other notes in strategic locations (DIA, hospitals, SB Mil Checkpoint will have a warning not to detain or process a particular odd British agent from MI6 who DIA knows of and is working with... a reference to previous fallouts). I've also brought back Mama Dolce's sweet and sour stroganoff and like the first V201 mod, lots of other little odd-and-end items that make references. Also making a glowstick that's supposed to have some cast light, specifically so the player can drop them to either act as breadcrumbs or so they don't backtrack while exploring. Oh, and I've engineered some code so it's tied to the original Vault 201 Skeleton Crew mod, but it'll work just fine all by itself as well :)

Just to re-iterate for anyone who has a similar issue and comes looking, here's the issue: This material and texture for the pre-war vault-tec van: VaultTecVan_PreWar01b.bgsm logo strip sheetmetal vehicles/automotive/vaulttecvan_prewar01b_d.dds ...is tied to shape #37 in the NIF. #37 ONLY affects the 'logo strip' on the driver's side of the vehicle, and there is no counterpart shape for the passenger side. If changing colors on the prewar van, you must either set the above material to the same as the main body of the vehicle and draw your own strip in the main texture, or copy the texture file (or just the stripe within) from 1a to 1b and follow through with the 1b material file. This all probably happened because the developers pulled the triangles out to a separate shape on one side, neglected the other, and realized it made no difference anyways as their displayed vans were a solid color. Since they were on display such a short time in the vanilla game, there wouldn't be a real need to correct the issue.

I got it; just set the 1b material to use 1a so the new red stripe on the 1a texture didn't get overdrawn. Logos need tweaking, but that was expected. CK view leaves much to be desired; but the stripe should follow the bodyline that you can't see because CK's rendering suuuuucks.

Certainly did. I have material swaps for everything listed in the original post except the tires. Went through and double checked the material files for the logos and made sure that nothing had changed from the vanilla BGSMs except the pointer to the diffuse texture (and checked that the vanilla norm/spec weren't actually in use), then I checked both my logo texture files to make sure the alpha channel was correct and in place, and they were saved DXT5 ARGB with MIPs... Both logos are present, it's just that the passenger side (01) logo decal is white and the background it's drawing is white instead of the desired red. Swapping 1a and 1b BGSMs results in a red ambulance with both decals shown correctly. I think the actual problem is that BSTriShape 37 *only* contains the logo strip for the driver side; there isn't one for the passenger side. I'm going to have to very carefully draw a red stripe down the side of the panel in the 1a texture, and ignore 1b. Which is all well and good because I'm not happy with the shade of red there, a result of changing the color map in order to keep the vanilla contrast details intact... I think Bethesda let this one slip because it's a rarely used object, and in their usage everything is the same color anyways... that there's no 'logo strip' coloration for the passenger side would go unnoticed because the main body shell texture is the same color as their logo strips. I'm changing that color, which is where the problem popped out.

Ah, no... it's just a storyline clue, but it's based off a vanilla asset. The problem with the thing... I can see why it either wasn't discovered or wasn't fixed, they only used this van in the game in the intro scenes, and even then the "bad" panel is the same color as the panel that's supposed to cover it. Nobody would have noticed anything wrong. I'll check the opacity settings in the NIF and in the material files. Maybe I can tweak an offset somewhere and get the logo base to supercede the main body.

(resolved) Good evening, I'm trying to turn the pre-war vault-tec van (vehicles/automotive/VaultTecVan_PreWar_01.nif) into an ambulance, and I've gotten everything nailed down with regard to new textures and material files, but the passenger side of the van isn't picking up the color defined in VaultTecVan_PreWar01b.bgsm. Here's a quick chart of what I found affects what parts and which files; VaultTecVan_PreWar01a.bgsm main body sheetmetal vehicles/automotive/vaulttecvan_prewar01a_d.dds VaultTecVan_PreWar02a.bgsm interior sheetmetal, seats, etc vehicles/automotive/vaulttecvan_prewar02a_d.dds VaultTecVan_PreWar01a_e.bgsm exterior chrome trim vehicles/automotive/vaulttecvan_prewar01a_d.dds VaultTecVan_PreWar02a_e.bgsm Forward and upper window frames vehicles/automotive/vaulttecvan_prewar02a_d.dds VaultTecVan_PreWar02b_e.bgsm wheel arches and running boards vehicles/automotive/vaulttecvan_prewar02a_d.dds VaultTecVan_PreWar01b.bgsm logo strip sheetmetal vehicles/automotive/vaulttecvan_prewar01b_d.dds VaultTecVanLogo01.bgsm passenger side logo Vehicles/Automotive/VaultTecVanLogo01_d.dds VaultTecVanLogo02.bgsm driver side logo Vehicles/Automotive/VaultTecVanLogo02_d.dds VaultTecVanTires01.bgsm tire rubber vehicles/automotive/vaulttecvantires01_d.dds VaultTecVanTires01_e.bgsm hubcaps vehicles/automotive/vaulttecvantires01_d.dds Now, looking at the mesh in nifscope, there are a set of triangles in the main body BSTriShape (# 22) that cover the 'logo strip' on the passenger side, but not a matching set on the driver's side. The passenger side logo strip BSTriShape is #42 and driver side is #46. I'm *theorizing* that the triangles in #22 are overriding the shape in #42 and drawing it's white texture "on top of" #42's red texture. Would that be the case? If so, how do I get rid of these triangles and eliminate the issue? My little ambulance is looking pretty good except for the screwed up passenger side logo... Could it be something simple that I'm not seeing?

I had an idea earlier today and started whipping things together to make a 'glow marker', just an item that can be constructed, carried, and dropped where you want to mark that you've been (this is for hardcore explorers and such). But, I have a problem. I started out just making a material swap for the 'blood test tube' MISC object that added a glow DDS and requisite settings. That part, works great. (see attached). Problem I have is, I can't figure out what settings in the BGSM would brighten that enough to light up a small area around itself, or if that's even possible. I would like to keep this as functionally simple as possible, since my scripting skills aren't strong and the only other ways I can think of doing this would be to treat it as a projectile with a light source, or somehow script in the spawning of a LGHT object on that location once it's been set down, and disable it when picked up. Not sure how I'd keep the light *in* it though. Ideas?

I resolved the issue by taking the vanilla mesh in NIFSkope and 'knocking it's block off'. In other words, I just removed the collision block and node. In the mod, I used this mesh to create a mod-version part, made a new SCOL for WharfWall, and swapped the offending parts. Then I placed 2 collision planes on each to avoid fallthrough, because... no collision anymore. Play-testing pending, though I don't foresee any problems.I'll pipe back up if there are.

EDIT: Not talking about extending the collision, I aim to remove a couple nodes from the collision mesh on the vanilla part. This is an interesting one, if you're the kind that likes to help resolve unusual issues. I have a mod where in one interior cell, there is a vault stairwell leading down right on the edge of a seawall. Nobody can walk down the stairs; the component ParkPierStr01 (and all SCOLs made from that, such as the wharf wall parts) have an extended collision mesh leading off from the top of the mesh, horizontally, on the other side from the sloped section. Presumably this is there to avoid anyone falling through boardwalk-like parts with imperfect collision geometry. Unfortunately, the vault stairs are not movable at this point, and that extended collision penetrates them and makes a 'fake floor' that cannot be passed from the top. Is it possible to edit down or remove collision meshes from a vanilla static object, with tools that don't cost an arm and a leg? I'm somewhat familiar with NifSkope; I have an older release of Blender but can't seem to wrap my head around the UI...

Found/fixed an issue with some of the custom misc items where they did not appear in inventory preview or examination; this was due to a missing preview transform. Anybody got anything else? Also dumped all the custom items in another mod as a resource pack, just search 'vault 201' and you'll find it.

Oh yeah, where it really counts everything was decked out to the hilt... meshed, covered, waypoints, and by your def, precalced. If you want to just dig in it, you can't really screw anything up... there's no questline, no magic scripting. Just the activation scripts for the 15 rooms (and 1 bonus), and a couple scripts for managing airlocks, teleporters, and one creepy little easter egg. You might find yourself stuck somewhere due to not having a key, but hey.. that's what console unlock is for :smile: I was *very* programmatic with naming, so if you want to poke at the building cells they're levels 1-4 and sectors A-D, so you get 'coc Mod01Vault201vltL3SA' or L4SD and so on. L1SA isn't buildable, the crew already got to that and it's loaded up with enough items that I was concerned that if I made it buildable some nasty performance issues could crop up. Every cell already has 1000 power with radiance over the entirety and registers 100 water, they're literally ready to jump in and start dropping stuff. Never did figure out power over snap points though, but a vault connector to the existing power connector (it's on top of the power control box, which is just a dressy cover that matches equipment outside) and some select/drop on the atrium floors should cover you. Each cell should fit a grid of 30x46 vault parts , 10 or 11 stories tall... or whatever else you want, that's why precalc was important. Otherwise nothing would snap to the floor. The whole thing was made for these reasons: 1 - provide a ton of vault-style building area 2 - cover for itself through backstory and 'realistic' structure and location 3 - satisfy further any story hounds with a nearly complete documentation of what happened to the crew through written diaries, notes, and terminal entries (with technical sensor logs that back everything up) 4 - provide for a fully underground travel method that's to scale with the surface 5 - fill some holes in the vanilla story (it's tied in to the CoA, very early Enclave activity, and why the Institute has their relay/how it works)

I have not done any heavy building tests, no. I have done basic feature testing with a few builds... there are images of a running 'mini-settlement' on the mod page./ These cells stem directly from the experiences I had with Vault 88 and troubleshooting an occlusion culling issue with frame refresh failure, causing a hall of mirrors effect. I figured out the max distances trying to get that fixed, and then selected dimensions for these cells that shouldn't approach anything problematic. As far as building the cells... they're pretty straightforward concrete boxes. I'm not sure what you mean by a new pre-calc system, I've not worked with any of the other Fallout versions. After I cleaned the navmesh, checked it, and generated cover and waypoints, I did run the precombined geometry and visibility routines. All that was necessary to be able to build on the concrete floor and get settlers/provisioners/companions in and out. Performance 'empty' though, pegged at 60. Wouldn't make sense to not be running flat out, there's very little "there" there. Game runs above 50fps pretty much everywhere but the vault core, warehouse, and physical plant... those regions are extremely object heavy but I did try and occlude things with planes and cut back on the shadowed lights. I'm running an i5-2320 with 12gb and a slightly hobbled RX470 8gb (PCIe 2.0 is limited since Haswell architecture/potato-esque motherboard). EDIT: The rest of the cells, the non-buildable ones? I actually can't remember if I've precombined those or not. I think I tried once in the warehouse and crashed the CK, and then again and managed to royally hose up a vanilla interior cell (normality restored there, no issues). Everything worked well enough in playtesting that I didn't pursue it, but it was still necessary for the buildable regions. And yeah, I actually did forget things. There are a couple dozen separate interior cells, for work of at least an hour a day from Jan 9 until I uploaded the current version May 31... almost 6 months straight. It's why the changelogs are so nitpicky, to remind myself :)

Well, after 6 months of learning curves and a DEEP dive straight into a massive project, my first mod is up and I have a problem. I've been working on it and playtesting so long that I'm concerned I'm blind to some of it's issues, and have gotten startlingly little technical feedback. I know it's functional, but I also know it *has* to have fixable issues, there's no way it's as good as what I was after ( "DLC grade" ) given how much I had to pick up on the run. Specifically, scripting needs improvement; I got it working but it's only functional, I never got my head around animations and using states rather than hardcoded actions, so the look/feel suffers a bit. I will *gladly* take suggestions, or even outright repairs (and you'd be credited for that, no issues sharing glory here). There's also some strangeness with a few of my customized items since I had to ride on vanilla meshes, never managed to interpret Blenders' UI and only picked up enough NIFSkope to be able to point to a new texture file. The area and number of cells also means that it's so big that I literally do not have enough time to adequately playtest all the ways in and around. All the teleporting between cells was checked multiple times, but there are so many locked doors and one-way routes that I could have missed leaving a key somewhere important. There are *purposeful* dead ends, but I'd found one situation early on where coming into a room from the 'back way' left the player well and truly trapped, and obviously those are suboptimal situations. So... up for a challenge? This is the last session of bug-fixing before I call it final and move on to a couple of expansions to this mod, and I don't want to start any of those before this one is well and truly nailed down. http://www.nexusmods.com/fallout4/mods/23634

Just for reference, here are the tested functional scripts. Yes, they need improvement, but they step through the startup and shutdown processes and the trigger sends the player off to the other end with no discernible issues. Attached to trigger volume: Scriptname M1V201TeleportTriggerScript extends ObjectReference import Form Sound Property TeleportNoise auto ObjectReference Property RemoteTargetMarker auto Event onTriggerEnter(objectreference akTriggerRef) Actor PlayerRef = Game.GetPlayer() TeleportNoise.PlayAndWait(self) Utility.Wait(2.0) PlayerRef.MoveTo(RemoteTargetMarker, abMatchRotation = false) EndEvent Attached to button: Scriptname M1V201TeleportButton01 extends ObjectReference import Utility ObjectReference property TPTargetTerm auto ObjectReference property TPadTrigger auto ObjectReference property TPadLowLight auto ObjectReference property TPadMidLight auto ObjectReference property TPadReadyIndicator auto Event onInit() GoToState("TPadInactive") EndEvent EVENT onActivate (objectReference triggerRef) If(TPTargetTerm.isLocked()) GoToState ("TPadOffline") Else GoToState("TPadTransitionUp") EndIf EndEvent State TPadOffline Event OnBeginState(string asOldState) Debug.Notification("Device inactive - missing target data") TPadTrigger.disable() TPadLowLight.disable() TPadMidLight.disable() TPadReadyIndicator.PlayAnimation("Red") EndEvent EndState State TPadBusy EndState auto State TPadInactive Event OnBeginState(string asOldState) GoToState("TPadBusy") TPadTrigger.disable() TPadLowLight.disable() TPadMidLight.disable() TPadReadyIndicator.PlayAnimation("OFF") EndEvent EndState State TPadTransitionUp Event OnBeginState(string asOldState) GoToState("TPadBusy") TPadReadyIndicator.PlayAnimation("Yellow") Wait(3.0) TPadLowLight.Enable() Wait(3.0) TPadMidLight.Enable() Wait(3.0) GoToState("TPadActive") EndEvent EndState State TPadTransitionDown Event OnBeginState(string asOldState) TPadReadyIndicator.PlayAnimation("Yellow") Wait(3.0) TPadTrigger.Disable() TPadLowLight.Disable() Wait(3.0) TPadMidLight.Disable() Wait(3.0) GoToState("TPadInactive") EndEvent EndState State TpadActive Event OnBeginState(string asOldState) TPadReadyIndicator.PlayAnimation("Green") TPadTrigger.Enable() Wait(15.0) GoToState("TPadTransitionDown") EndEvent EndState

Little tweaks and it works, needed to use onBeginEvent with the states instead of onActivate because the latter required a button press for every state change. Also switched up the state targets for that first onactivate branch so TPadInactive is default and a successful press goes to TPadTransitionUp, that lets TPadInactive and TPadOffline just sit forever if need be. Stuck a sound script in the trigger box with an onTriggerEnter, going to test that out first and then it's on to teleporting.

This is still in the loose idea stage, so if there's a better way I'm open. What I need is essentially a 'glowing one' in a hazmat suit, or most of one preferably. I can't figure how to dress a glowing one in anything though, so I thought about it and remembered... well, the magician in Nuka World who's name escapes me (edit: Oliver?). That guy, he can be re-dressed, and a duplicate of that character can likely be 'reformed' with no speech or feral ghoul noises and immediate aggression. Having the inventory available is a bonus because he needs to be carrying his ID card, radio, and trailer key (plot items). Sounds like a viable idea, or do I need a different approach here? I'd love the hazmat suit to be damaged in some manner, broken facemask or missing helmet, to expose the nature of the occupant... not sure if that's possible with the existing outfits, but it needs to be a hazmat suit. Fight animations and such are open because the guy's a special case, not necessarily 'feral' just extremely powerful, off-his-rocker insanely aggressive lvl200+ ruin-your-day thumping machine soaked in radiation. I'm a world-builder, never messed with NPCs before (this will be my first, asides from some simple renames/tweaks on simple mobs). Any snafus, things I'm liable to trip over?

If I use a "holotape" key to unlock the target terminal and attach this to a console button next to them... god I hate scripting. Is this workable, or have I done something untenable? TPTargetTerm is the target terminal (locked, requires key that looks like holotape) TPadTrigger is a trigger box that sits on the pad itself, it'll have the COC script attached to it. I'm just enabling/disabling to make travel possible or not. Disabled by default. TPadReadyIndicator is a ref of 'EmergencyLightAnim01' which has red/yellow/green/off (not sure what names to use with PlayAnimation, the Gambryo anims or the script events?) TPad****Lights are just show lights, on when 'working' I missed some Busy states... not exactly sure why the CK's example has onActivate events for every state but I used them, would love to know why... Scriptname M1V201TeleportButton01 extends ObjectReference ObjectReference property TPTargetTerm auto ObjectReference property TPadTrigger auto ObjectReference property TPadLowLight auto ObjectReference property TPadMidLight auto ObjectReference property TPadReadyIndicator auto EVENT onActivate (objectReference triggerRef) If(TPTargetTerm.isLocked()) GoToState ("TPadOffline") Else GoToState("TPadInactive") EndIf EndEvent State TPadOffline Event onActivate (objectReference triggerRef) Debug.Notification("Device inactive - missing target data") TPadTrigger.disable() TPadLowLight.disable() TPadMidLight.disable() TPadReadyIndicator.PlayAnimation("Red") EndEvent EndState State TPadBusy EndState auto State TPadInactive Event onActivate (objectReference triggerRef) GoToState("TPadBusy") TPadTrigger.disable() TPadLowLight.disable() TPadMidLight.disable() TPadReadyIndicator.PlayAnimation("OFF") gotoState("TPadTransitionUp") EndEvent EndState State TPadTransitionUp Event onActivate (objectReference triggerRef) GoToState("TPadBusy") TPadReadyIndicator.PlayAnimation("Yellow") TPadLowLight.Enable() TPadMidLight.Enable() GoToState("TPadActive") EndEvent EndState State TPadTransitionDown Event onActivate (objectReference triggerRef) TPadReadyIndicator.PlayAnimation("Yellow") TPadTrigger.Disable() TPadLowLight.Disable() TPadMidLight.Disable() GoToState("TPadInactive") EndEvent EndState State TpadActive Event onActivate (objectReference triggerRef) TPadReadyIndicator.PlayAnimation("Green") TPadTrigger.Enable() GoToState("TPadActive") EndEvent EndState What's supposed to happen: 1 - player presses button 2 - if player hasn't unlocked the target terminal with the fake 'holotape' key, the pad goes offline with lights out and red light on indicator 3 - if player *has* unlocked the target terminal, then the pad enters transition up (lights on, indicator to yellow) 4 - when transition up is done, pad goes active... indicator to green, trigger box is enabled 5 - the player can now step into the trigger box and transport to the other pad, or wait X seconds (not in code yet) and pad enters transition down (indicator yellow, trigger box disable, lights out) 6 - pad goes inactive (lights out, indicator off, trigger disabled) to wait for another input attempt Valid question: Do I need to do anything with the script when the player initiates teleport (coc) to the other pad, or is that automatically managed when the cell unloads (we're in an interior)? EDIT: Hell, ignore the last line in State TPadActive, I was copy-pasting and was just happy the damned thing compiled... I'm not where I can test it yet (physically, not at a machine capable of running FO4 at the moment, will be in a few hours)

Well, the issue seems to me that if there's no way to use a holotape in this manner, then a substitute object falls under the same limitations. I need to rethink how I'm going to handle this... maybe look deeper into how terminals can change their own text options by script, if text replacement can change one line and add a menu option depending if a particular holotape is inserted *or* the right substitute is placed in a dedicated separate container. Or since I have two terminals for each pad, maybe I'm overthinking this and just need to figure how lock the targeting terminal with the specific holotape as a key, and just not have all the extra text on that holotape. Then I can start figuring out the object activation for the trigger and how to safeguard against loops... probably just drop back to activating by switch when everything's right on the terminal, and have it disable itself after both a short wait and on unloading (which should be automatic anyways if the trigger is set to be disabled on load).

tl;dr How does one go about restricting a holotape so that it only functions in a single given terminal? ------- Instead of diving deep, I'm just going to describe the desired outcome, since there may be an easier way than what I'm starting. There are two locations of teleporter pads, each has two terminals parked side by side. First terminal is the master control, it's just glitz with a text screen of basically 'device ready, fine targeting enabled, targeting control set remote, bla bla) Second terminal is the targeting control. Initially, it contains a message about test mode, prototype this, etc, 'please insert target data holotape'. There are 'B MODE TARGET DATA' holotapes, each has text basically saying it points to the other teleport pad. This was done by duplicating the targeting control terminal object, editing it slightly, and assigning the new terminal object to the holotape. Now, let's consider these teleport pads as 'outside' and 'inside'. The inside pad, "02", already has the targeting holotape pointing to "01" inserted and loaded. The outside pad "01" has no targeting holotape inserted, and instead has a "I'm so dumb" note next to the skeleton of a researcher who's facepalmed himself to death, because target holotape 02 is sitting on the table next to pad 02 and there's no way back inside (right after the bombs fell). You however can 'run the gauntlet', retrieve the tape, insert it, and have a handy shortcut inside for later use. Other teleport pads and/or functionality may be 'induced' later. Hilarity ensues. But there's a hitch. These targeting data holotapes contain the full text of the targeting control terminals... even though I see no reason they couldn't be loaded in any terminal, or the pip-boy. How does one go about restricting a holotape so that it only functions in a single given terminal? There will be other scripted things to worry about (activating the trigger box when the tape's inserted, but making sure coc'ing on to the other pad doesn't drop you on it's trigger box and coc you right back out to the other one and loop/crash) but that's the major question of the moment... I need the holotape pointing to pad 02 to only ever work in target control 01, and the tape pointing to 01 only on targeting control term 02. Don't particularly care if other tapes play on the terminals, but popping 'B MODE TARGET DATA 01' into a subway information terminal and getting the complete targeting control screen would be weird and confusing, since nothing at all would happen.

Ok, now that I had time to test it there was an error in door selection in the inside button code, and the outside button code (thanks to using near/far) didn't even need a single if statement, I just simplified it down to "close the far door, wait 5 seconds, open the near door". At that outside button there's never a reason to want to close the door you're standing in front of, that's for someone else on the other side to call for, and the interior button does the closing when you're in transit. Suppose I answered my own question...

I haven't tried this yet and can't for a few hours (since I'm not actually *at* my PC with CK/FO4 on it), but here's the deal. Imagine a short room with two submarine bulkhead doors. There's a button at each door outside, and one button in the middle. The outside buttons use the same script, and another script runs the inside button. If this works as-is, fantastic... also always looking for improvements/recommendations, and I will be sticking a translation for water level and a teleport command into a second version of the inside button script later. Behavior-wise, this is an airlock, and only one door should be open at a time. Outside button script: used near and far for the door descriptions since this gets used locally for both external buttons Scriptname M1V201AirlockIntScript extends ObjectReference ObjectReference Property ALNearDoor auto ObjectReference Property ALFarDoor auto Event OnActivate(ObjectReference AkActionRef) int ALNDState = ALNearDoor.GetOpenState() int ALFDState = ALFarDoor.GetOpenState() if (ALFDState == 3) if (ALNDState == 3) ALNearDoor.setOpen(true) else ALFarDoor.SetOpen(false) debug.notification("Airlock is already open") ALNearDoor.setOpen(true) endif else ALFarDoor.SetOpen(false) ALNearDoor.SetOpen(true) endif endevent Inside button script: Door A is the 'inside' door and door B the 'outside'. Wanted to give a preference that in the case, somehow, that both doors were closed, door A opens on the first press, then it will toggle as usual. Also wanted to wait a short time during the 'toggle' with both doors closed, because that's what airlocks would seem to do. Scriptname M1V201AirlockIntDoorInsideButton extends ObjectReference ObjectReference Property ALDoorA auto ObjectReference Property ALDoorB auto Event OnActivate(ObjectReference AkActionRef) int ALDAState = ALDoorA.GetOpenState() int ALDBState = ALDoorB.GetOpenState() if (ALDAState == 3) if (ALDBState == 3) ALDoorA.setOpen(true) else ALDoorB.SetOpen(false) utility.wait(5.0) ALDoorB.setOpen(true) endif else ALDoorA.SetOpen(false) utility.wait(5.0) ALDoorB.SetOpen(true) endif endevent So... have I done anything spectacularly stupid? Also, I want to make these bulkhead doors accessible only by the button, is that a matter of locking them inaccessible, and do I toggle the inaccessible flag on the main edit tab as well or not? Going to have further work later when I have the external door placed as teleport target, which should always be open after teleporting but I think I've got a handle on that (setting it open with event onLoad , right? Script is added to the door object itself?)

Oh, and here's what these scripts are going to end up being for; I'm OK with everything about the mod-making process except working with models outside CK, and scripting.

OK, I got it functioning... I was making it much more complicated in my mind than it actually was. Added script in activator's object edit pane, gave it a name, wrote in following (ex, I've been playing with this and tried translateToRef, moveTo works fine) Scriptname M1V201TestTeleportScript2 extends ObjectReference actor property playerRef auto objectreference property MVTestTeleMarker1 auto event onActivate(ObjectReference TriggerRef) playerRef.TranslateToRef(MVTestTeleMarker1,5000.0) endEvent ... and then just assigned the references from the script properties screen. Easy enough, though I tried a countdown with debug.notification and utility.wait that doesn't work quite right. Time to play around, I suppose. I do understand that using MoveTo with an unloaded reference requires a bit more backend work, and that'll be part and parcel of the end usage.