puddlepond

make sure your file paths are set up correctly. they need to be relative to the game's directory: in the .nif your texture paths should look something like "textures\armor\hood\hood_d.dds" and that structure should be replicated in the game's data folder. if your model's texture paths start with "c:\users\etc" or something like that they won't work in game.

that should be fine? it's all hypothetical; i don't know if stewie's tweaks would let you set one of its values from a different (identically named) file in a different folder. the script above might not be 100% fit for your purpose but if it's possible at all it'd be down to some combination of ReadINIFloatFromFile and SetINIFloat functions.

the only conditions are the GetIsID condition that all his lines have and the GetScriptVariable condition checking that bJimmyKilledByRobots == 1. i tried removing both of them and it didn't make a difference. it's only marked as "Goodbye". i don't know what the last question means; this line is set up identically to every other line. i tried moving the topic under "Conversation" and "Combat" just in case that did anything (remembering to print $wahoo5 in the result script) and it didn't. i tried moving back to the Death topic and setting up the GetIsID condition paired with a GetIsCreatureType condition that runs on the combat target, and that didn't work either.

i can't set "Say" to 1 and i'm not trying to. the 1 after "aaJimmyCompanionREF.Say aaJimmyKilledByRobots" is a flag in the "Say" function that forces subtitles on, it's not a variable that i'm tracking. i took your advice and added a bunch more checks and moved $wahoo5 to the dialogue result script. $wahoo5 doesn't print, but every other $wahoo in this script does.

moved back to an event handler and a dedicated topic. here's the function: all the wahoos fire but jimmy doesn't say his line. if i'm understanding it correctly wahoo5 should only print after he says his line, but he doesn't and it does anyway. maybe it's just an issue with the subtitles; none of his lines are voiced yet and this is a relatively minor issue, so maybe it'll be easier to fix when i don't have to rely solely on subtitles to know if it's working.

this is an excerpt of the script i used in my nif-bashed armour collection. packaged with the mod in a folder named "config" there's a text file named "ArmoireConfig.ini" with "[Armoire Settings]" at the top and the line "sMechanicOutfit=1" below. if that line is unchanged, the block of code in the middle fires. if it's changed to 0 (or any other number) it doesn't. it's just basic if/else statements once you know the functions and syntax and stuff. hopefully having a working example is enough to get you started; if i knew what you were trying to do in specific i might be able to help further.

i'm making a companion. i put this block in their npc script (with a bunch of other blocks that do fire correctly, like the OnCombatEnd block that resets their health and stuff) and none of it works (except part of it, maybe, sort of) there's a few things i'd like to fix but what i'm most concerned with is the fact that nothing after "If HasBeenHired == 1" happens at all; his perk is never removed, none of the VNPCFollowers variables are updated, nothing. hiring jimmy sets HasBeenHired to 1 and there's a bunch of dialogue that relies on that being true that works fine, so that's not the issue. as far as i can tell my script is near-identical to the OnDeath blocks for vanilla companions so i don't know what i'm doing wrong. there's another less-pressing matter i'd like sorting out and that's the "bJimmyKilledByRobots" section. i want jimmy to have a unique death groan for if he's killed by a robot, so i added one in his dialogue quest under the "death" topic in the "combat" tab with the condition that the "bJimmyKilledByRobots" variable must equal 1. he never says it, is the thing. what's interesting is that he never says any of his other 2 death groans either even though they work fine when he's killed by anything other than a robot. they're set up with their only conditions being the "GetIsID NPC: 'aaJimmyCompanion'" thing that all his lines have, so it's interesting to me that he doesn't use them when he's killed by a robot when he's not using his special killed-by-a-robot line either, he's just silent. i'd massively appreciate any help in figuring this out. edit: i tried changing setting up the killed by robots line as a regular topic and changing the relevant part of the script to this. it doesn't work. i'm guessing the issue with this new script and the old one is that they can't pass their variables along fast enough in the instant between jimmy dying and jimmy saying his death line for it to have any effect, but i don't know how i'd fix that. i had a similar issue getting him to respond to being given cigarettes in the dialogue quest script that i fixed with SetQuestDelay, but this isn't a quest script so that's not an option. i think the issue might be having to wait for fDyingTimer? i think i could get around that by moving all the bJimmyKilledByRobots variable switching to a JohnnyOnDyingEventHandler, but that still doesn't solve the main issue that none of the OnDeath block works, not just the parts to do with this very specific voice line. edit deux: moving the bJimmyKilledByRobots section to a Johnny event handler fixed the main issue, when Jimmy dies his perk is removed and the relevant variables are updated. he still doesn't say his special death line for being killed by robots. i tried moving the line to a regular topic again and scripting him to say it as part of the event handler but that didn't work either. here's my handler script and function in case there's a mistake i've missed. also i moved the bJimmyKilledByRobots variable to the dialogue quest script since the companion script now wasn't using it at all. edit trois: i got rid of the death event handler. i tried adding these blocks to his companion script. i figured they'd be less accurate in determining whether he was actually killed by robots but they might have a better chance of actually working. they don't, and i don't know what's wrong. i also moved the killed by robots variable back to the companion script and made sure the death topic conditions reflected that, so that's not the issue.

super mutants usually have the clothes and stuff of every super mutant variant in their ModelList so. If you copied that you could maybe have a bunch of different dialogue options asking Ur companion to change into a specific outfit or whatever and use ToggleCreatureModel + Update3D in all their result scripts

usually scripts and stuff use EditorIDs and not FormIDs. have you tried doing VFSSergio.AddItem WeapNVStraightRazorUnique 1

i fear that my initial comment took on a sour tone that's not representative of my actual feelings. i don't really care about the new profiles. i like them well enough. i liked the old profiles better but these are... fine. i browse this site in a half-width window so i'm used to seeing 3 mods per row, and when i zoom the new profiles out to 90% it's the same as it ever was. there's nothing particularly egregious about the new design, at least not that i've noticed. the only thing (so far) that i really don't like is that the profile mods tab defaults to "most downloaded" when i'd much rather see "most recent". my search preferences are defaulted to "by recent files" but that doesn't seem to affect the way mods are displayed on a profile and i can't find any setting that would. also, not to sound harsh, but your choice to work outside of paid hours isn't my fault or my problem. you could just stop doing that.

i totally respect that this is just part of the forum migration and that the IPS suite upgrade was necessary for a multitude of reasons, but do we have to pretend that this change is desirable or that the opinions of the community hold any weight whatsoever? you're not looking for feedback, you're looking for bug reports; this isn't a change the community has any say in.

oh! i don't know that i ever would have thought of that. thank you very much n_n

that's the one i'm familiar with. when i move that model into the .nif it's just on the ground, not around the forearm. i could totally move it to be vaguely where i need it but i'd be approximating and if i'm approximating then its use as a reference is sort of nullified. like... when you copy a hat's model into another .nif it's quite high up where the head would be, whereas the pipboy is flat on the ground in its own .nif and when i copy it across it's very much the same. that's not really a rigging issue and i probably made a mistake using that word in the title, it's moreso just positioning. i'm looking for a correctly positioned pipboy.

i'm making armour. as far as i can tell there's no pipboy model in the base game's files that's positioned on the forearm where it'd be during gameplay, which would be a great help in making a pipboyon sleeve as i'd be able to tell exactly which vertices of the forearm are clipping and need to be smushed down. unless i'm missing something in the game files, does anyone have a resource that'd help? how is everyone else making good looking pipboyon sleeves without it being incredibly tedious?

you keep acting like there was previously this huge (or at least noteworthy) contingent of users with their government names on their nexusmods profile when 1) that isn't the stated reason for the removal of the "real name" box and 2) you don't know that there was any more than i know that there wasn't. in fact, you have less evidence that there were enough users with full legal names in that box to pose a genuine concern than i do that there wasn't, given that my evidence is several years on this site and having never once seen someone use their full legal name (besides a scant few "big names" in their respective scenes whose real names were also available on their artstations and twitters and such who shouldn't have been a concern in any case), and yours is "uh, enough people must've, or else this thing i made up wouldn't be true." i was trying to be kind in my first comment but i feel like i'm genuinely going insane reading your replies. like... you said (paraphrasing) that "the real name box was removed due to privacy / security concerns", lenawolfbravil replied "no one is using their full names in that field", to which you replied "you don't know that they weren't." as far as i understand lenawolfbravil misunderstood your point about "privacy / security concerns" as even common first names could be considered PII and, as i said, it makes sense that nexusmods would be wary of storing such information in the way that they were, and - i cannot stress this enough - it'd be fine if you just said that. that's what the admin response you linked said. i don't know why you doubled down on the idea that there was a sizable number of users with their full legal names in the "real name" box. there wasn't. you are the only person making that claim. your claim that "this happened three months ago, not during the forum update" directly contradicts the admin response you linked, which reads "this field was removed between 4-7 September" [...] "we are in the process of upgrading this forum to the latest version of Invision Community". the OP of that thread's complaint wasn't solely that their real name (that being whatever they typed into the relevant field, not necessarily their legal first and last names) had been erased, it was that the "real name" field itself was no longer displayed on nexus profiles, a claim that zanderat confirmed. the OP of that thread is not your smoking gun proving without a shadow of a doubt that people were using their full legal names in the provided field, and even if it turned out that they were it wouldn't mean anything. you seem to greatly overestimate what PII actually includes. PII can be your favourite colour. it can be your first name. the idea that the "real name" field was removed due to concerns over PII does not conflict with the reality of everyone only ever using it for their first name. we agree. the "real name" box was removed due to privacy / security concerns regarding PII. we agree.