skittered

In FO3Edit .. weapon and armor records tell you what the stats are .. and are found in the weapon and armor trees ... as for finding them in game .. select a record .. look at the bottom of the right pane near the pane divider for a tab labelled "Referenced By" .. that tab will tell you where those records are referenced .. double click one to take you to the referencing record .. , note the name of any cells. In the GECK .. weapon and armor record branches are found under the 'Items' tree .. find a record from the mod , right click it "Use info" .. that will tell you where or what .. if any .. the record is referenced by .. if it's used in a cell, you can double click that to open that cell in the Render window, where the top left corner of the frame should show the cell name, and the Cell view window should also show the cell name.

Thanks for trying.

They all start with at least one letter .. as far as my reading recalls, nothing in a mod should be prefixed with a number.

So .. I've created a rather large stack of dialogue; lots of topics and choices; lots of specific conditioning; lots of begin-/-end and quest stage result scripting .. I've done all of this in non-fose G.E.C.K .. with the express purpose of avoiding accidentally introducing any erroneous fose so that this dialogue will work correctly in non-fose Fallout 3 (it's one of those things) It is not voiced in any way .. no use of vanilla assets or otherwise. The max number of choices in the largest topics are 16, and the largest number of response lines in a choice is 3. The geck doesn't complain about any of the conditions and all of the scripting also compiles without complaint. The problem is, the geck has no problems with it .. but when I head in to test in-game some strangeness happens. Running non-fose Fallout 3 .. .. the dialogue Greeting works correctly and the first options are presented without issue; unfortunately that's where the strangeness starts; .. one topic that leads to one with 16 choices works just fine .. .. but another leading to one with fewer choices, or another to the same number of choices, will cause an immediate CTD .. .. testing with one choice at a time in an offending topic reveals that there are specific culprits, but the geck reports no issues, nor are there any apparent issues while looking at it and checking it for errors in FO3Edit, and comparing the seemingly offending entries to existing vanilla entries for missing data However .. all of it will work just fine running fose Fallout 3 .. even though there is no specific fose scripting or reliant conditions anywhere .. .. I've been testing as I've been building, adding topics, choices and scripting in chunks at a time and suddenly this issue has presented itself with no apparent reason I can find .. If anyone has any guesses .. or insight .. it'd be appreciated .. the only other option seems to be to rebuild the dialogue and hope it doesn't happen again ..

thanks for the reply I can and have whitelisted the entirety of the nexus before asking .. the problem .. which script specifically is making the data request and populating the page, and if the stats are stored off site, which site? .. my suspicion is that the script runs when allowed , but it doesn't get any data to work with because the site the data is coming from is in one of the blacklists I'm using. .. disabling the extensions themselves sorts out the issue .. but also means there's no way to figure it out well .. .. through a lucky pick of one of the scripts that loaded while watching the page load in developer tools, i found the issue .. .. blocked web workers .. really? .. alrighty .. guess i'll try to find a way to allow them only on the nexus .. apologies for the stupid questions. --------------------------------------------- -> uMatrix -> My rules no-workers: nexusmods.com false

I'm curious as to how the "Unique DLs" and "Total DLs" are populated into a mods information on the mod site pages. I can't for the life of me figure out what script / site / allowances are needed in uMatrix or uBlock to get them to show up, short of disabling them completely.

short idestroyed IF object1Ref.getdestroyed == 1 && idestroyed == 0 ;action, for example showmessage set idestroyed to 1 ENDif

Ah, so that's how it was done. Hadn't gone looking for that as I posted just before going to sleep and it was a bit of an afterthought at the end of the post.. I should have thought longer before I posted that example. There are enough things wrong with it that it probably won't work as is unless you kill what you're aiming at very quickly. getCombatTarget only gets one target at a time, so you'd need to find a way to target and store a bunch of them 'before' killing them .. there is a check in there that checks to see if the target was killed by you. There are also various other things that could be used to narrow down the result to just the specific type you're trying to track, but it may get quite convoluted. The game seems to already track kills by type, along with a whole bunch of other things, so it might be easier to just look up that value and track it till it reaches +(##) of the kill count you need for yourself. Apologies. My first post was off topic .. As far as I've found looking through the built in functions for my own purposes, there doesn't seem to be a way to 'generally' track "objects" that you're aiming//shooting at. There may be a way to track things 'specifically', but it most likely requires making specialized changes and/or items for doing those things, and would most likely also end up creating a lot of conflicts with other mods. .. the only other thing I can suggest is reading through the available functions yourself to see if you can figure something out. (it also looks like fose wouldn't be able to do exactly what you want without a lot of specific scripting)

.. purely vanilla .. http://geck.bethsoft.com/index.php?title=GetCombatTarget http://geck.bethsoft.com/index.php?title=GetIsCreatureType .. whole slew of useful information in the functions listings to figure out if it's possible to do other things .. (a very simple example that should work for kill counting .. this would be used attached to a high priority, low delay running quest) ref Rcreature short iKilled Begin GameMode set Rcreature to player.getCombatTarget IF (Rcreature.getIsCreatureType 1) == 1 IF (Rcreature.getDead) == 1 IF (Rcreature.IsKiller player) == 1 set iKilled to iKilled + 1 ENDif ENDif ENDif END.. to think of it .. there may already be an example of something similar in the scripting for the Quest where you test the Molerat Repellent for Moira

GECK was made for modding, not merging .. everything loaded, including mods, seems to be considered the 'default' state of things until something is changed, and then only those changes are saved .. It is possible to 'merge' mods using GECK, but it is NOT easy .. .. because GECK only saves changes / differences .. the only way to get all the content from several mods saved into a single mod without 'mod' dependencies seems to be .. Set your 'main' file up as the first mod in the load order .. sort all other mods to be included after it .. Load your main file as the active file in GECK .. with all the mods to be included also selected so that they are also loaded .. Make some sort of small change to every part of every mod that you want included in your main active file .. save .. exit .. load your main mod in GECK all by itself and check the results. Rinse and repeat until you've got everything in one file .. (trial and error until you get it figured out) EDIT: Upon further thought .. using purely Vanilla GECK, this may not even be possible without a LOT of editing. It's likely you'd need to do it one mod at a time, and make sure you get ALL the changes the first time, otherwise you'd end up with a whole bunch of duplicates if you were try to load your combined mod and the child mod together again. The reason for that being that each child mod that you want to 'merge' into your combined mod would otherwise need to have that mod as a master, so that when they are loaded after your combined mod differences are considered changes rather than duplicates. This is especially true for mods with unique / new assets and entries. ;----------------------- Being able to use FO3Edit would make it slightly easier to do, but even that still requires a decent understanding of how the assets and changes are handled.

It looks like the whole piece has no collision. In G.E.C.K .. with your room open in the editor, use ... View - Collision Geometry (F4) .. the red lines you see on the pieces you can walk on in game mean they have static collision, and it seems VDnWallWindow01 has no collision, so it will appear in game, but it will not have anything 'solid' that you can walk on, or to block you from walking through it's wall. You could use the method mentioned above to prevent falling through the floor, but you would still be able to walk through the wall. The only real proper fix for it is to add collision to the piece itself, and that's a whole other can of worms. (it doesn't look like that piece was used anywhere in game, so that might explain why it was never noticed that it has no collision)

The majority of that is done in the \menus\ "..".XML files that contain the layout information. The 2 mods that comes to mind as an example of how the pip-boy menus can be altered are DarnUI and VanillaUI-Plus. There may also be an example of adding that information to the pip-boy in the XML files include in Vicious Wastes. This may provide some extra understanding also .. https://www.loverslab.com/topic/53411-reading-ui-hud-xml-files/ The difference between the vanilla stats_menu.xml, the one from DarnUI and the other two mods should provide a decent example of how the tabs 'might' be able to be rearranged, or new ones added. You'll likely have to do a lot of reading of the code, and extra research to understand XML in general and specifically how it's used by Fallout 3 for the pip-boy. If you're really ambitions, you can compare the vanilla start_menu.xml to the DarnUI one for an example of how something completely new was added there also. (the start and pause menu)

Did you copy those file paths directly from your explorer window? It looks like you're trying to use a custom path to your texture ... the GECK only recognizes the default base paths to assets. ... (install directory) \ Data \ Textures \ (your mod-texture folder) ... (install directory) \ Data \ Meshes \ (your mod-mesh-folder) .. which in your case should probably look something like this .. C:\Program Files (x86)\GOG Galaxy\Games\Fallout 3\Data\textures\armor\headgear\(your custom folder) C:\Program Files (x86)\GOG Galaxy\Games\Fallout 3\Data\textures\interface\icons\pipboyimages\apparel\(your custom folder)

Here for one .. http://geck.bethsoft.com/index.php?title=String_Formatting .. and there's a whole host of other places you can find useful information if you search for it. Glad it's working.

While I'm here .. Seems the error creating a SCOL with custom pieces is related to using mesh shapes ... NiTriShape The solution seems to be converting to NiTriStrips This is what finally allowed my custom pieces to be grouped at least.

... was your skill at least being changed to 100 using ForceAV or ModAV ? .. your console command is incorrect .. the %a won't print anything as it's a specific fose variable meant to print something specific passed to it, something to do with ascii code .. .. use %g edit ..(deleted)( blah, too much for one post prior to knowing more details )

Just remembered a fourth thing that can cause custom meshes to fail to appear ... failing to do "Archive Invalidation" ... Put in the right place (as per it's own install instructions), the nif from that mod is meant to be an override for the vanilla minigun.nif .. no esp needed technically. Beyond that, check your work. As I mentioned, some of the weapons use multiple meshes and it's likely you missed changing one. If you have some idea how to use F03Edit .. have a look at the records in that esp, see what was changed, might give you an idea what else 'might' need to be changed. Can't offer much more sorry. The problem you're having is one of those things that once you understand it, you'll wonder why you had that problem in the first place.

Well that's not much help. ... you're getting the vanilla third person model in game at least .. there's only three reasons i'm aware of that causes that to happen when trying to use custom meshes .. an unchanged record .. a later record override or a file load order override .. otherwise you'd get no model at all and the game would spit a red square out at you ..

Are you using an esp for your mod? ... did you point the record at the correct file? .. if you want to use it as a direct file override without an esp you need to make sure the file path and name are identical to the one you want to override .. .. also, a bunch of the weapons use different models for first and third person view, the minigun and the flamer being two the come to mind right away, so you need to be sure to include/change the third person view model that you want as well.

No, I still have no idea why the geck is throwing that error when trying to create the SCOL with my custom pieces. .. However, I'm not entirely surprised as the geck has thrown all kinds errors at me even when using unmodified vanilla meshes. Fortunately I already had a plan in mind for reducing the number of pieces after build completion anyway. Hope you're successful with you're next attempt at removing the DLC requirement from Clarity. Once you get the hang of it it'll seem plenty easy.

Glad it works. You can change the Timer check to partial seconds if needed ... IF Timer >= 1.5 ... >= 2.5 ... >= 3.5 ... etc. .. or you could just consider the extra bit of delay 'stunned' time from having just been transported who knows how far.

Pretty much yeah ... ;First trigger, teleport out Begin OnTriggerEnter Player If TeleportSwitch == 0 DisablePlayerControls PlaySound DRSDLC05TeleporterClose IMOD DLC05TeleportOutISFX Set TeleportSwitch to 1 ENDif End Begin GameMode If TeleportSwitch > 0 If Timer >= 3 set Teleportswitch to 0 ;always best to zero just to be safe set Timer to 0 Player.MoveTo NEWCELLTeleportMarker01REF ELSE set Timer to Timer + getSecondsPassed ENDif ENDif End ;Arrival Trigger ;Second script, close to the first. Same duration, not quite done in reverse. Begin OnTriggerEnter Player If TeleportSwitch == 0 PlaySound DRSDLC05TeleporterOpen IMOD DLC05TeleportInISFX set TeleportSwitch to 1 ENDif END Begin GameMode IF TeleportSwitch == 1 ;<--- Arrival trigger RE-Fire prevention IF Timer >= 3 EnablePlayerControls set Teleportswitch to 2 ;<--- Arrival trigger RE-Fire prevention set Timer to 0 ELSE set Timer to Timer + getSecondsPassed ENDif ENDif END .. untested of course. Come to think of it, there may be another check required on arrival, being you may end up standing on the arrival Trigger for an extended period of time which could cause it to fire again. ... edited the thought into the script.

Do you not have the DLC's? ... otherwise it's quite simple .. Go through the records and remove any record that overwrites a record from the DLC ESMs and leave only the ones that overwrite the Fallout3.esm .. after that .. still in FO3Edit .. right click the "Clarity - Dark Nights.esp" .. "Clean Masters" .. then check the "File Header". If there are any "Masters Files" left other than Fallout3.esm it means you missed some records .. just go through them again and remove those, then do the Clean Masters again. Once the only master that's left is Fallout3.esm you're done.

I'm doing this purely as a thought experiment, so I haven't tested it and I could be wrong .. As I understand, as soon as you leave the cell, the script for the teleporter is terminated so there's no way for the original teleporter to know when you're in the new cell. It occurred to me shortly after posting last time that you can probably break the script in half and drop the player on a new trigger. Use the first half on the first trigger .. the fade out, sound out and moving the player to the new cell. Put a trigger in the same place you're dropping the player in the new cell and attach the second half of the script to it .. the fade in, sound in and enable player controls. When the cell is finished loading the new trigger event should fire because the player has been dropped on it. The quest method would work similarly except you'd be using quest variables to track things rather than a new trigger. It may even be a little more complicated because of timing requirements.

It's more likely a case of the Trigger and it's script instance being specific to the starting cell. What you probably need to do is track it with a small quest in order to be able to tell when the new cell is finished loading so that you can play the required sound and FX and re-enable the player controls once that's done.