DocClox

Can you think of any reason that nifskope might not remember the resource paths I give it? I set the paths, save, exit the setup window, and when I go back it's forgotten them. It's most frustrating. Do I need to create a .nifskope folder somewhere to store setup data or something? (Then again, it remembers the game path just fine...)

It's always useful to know something about how a system works at a low level. If nothing else, it helps a lot when it comes to working out why something isn't working further down the line.

And that ought to include being able to offer the fruits of our efforts for free if we so choose. Nevertheless, there are people out there who take the position that offering anything for free is immoral, and I think that comes out a lot in these discussions. The worry is that once a corporation has a revenue stream, there is pressure to maximize that income. And the way to do that for paid mods is to make it progressively harder to release mods for free. No one is going to buy a value pack of sixteen vibrant mudcrab retextures for actual money if there's half a dozen equivalent mods on Nexus for free. But if those mods can be made to go away... Now, if I was the Evil Overlord, I'd look at changing the engine to only accept cryptographically signed mod packages. I'd set it up so the only way to get your mod signed would only be through the "verified creators" program. So if you wanted to publish your mod, you had to set a price and let Bethesda take a slice of the money. And I'd set it up so you could always run your own mods on your own machines. That way new modders could still learn their trade. And I'd encourage posting screenshots of unpublished mods, because peer pressure then encourages new modders to register, publish, and make money for Bethesda. And in due course, I'd change the EULAs to forbid distributing non-verified content, and use take-downs and the threat of lawsuits to force modding sites to either respect the licence or else go out of business. If I was the Evil Overlord that is. This isn't a prediction. But I believe it is a risk.

And of course, once there are enough "verified" modders, it's going to be hard to argue against a band on non-verified modders. Because security, malware, lions and tigers and bears! Oh my! And the fact they they've finally managed to tax the hobby community will be quietly swept under the carpet.

It's good at managing large open worlds with large numbers of NPCs and large numbers of parallel evolving quest-lines, and AI so that the NPCs can react to those quest-lines without everything having to be done in a set order.

TSP would make sense here if the provisioners were physically carrying goods, and supplies didn't arrive until the provisoners did. As it stands though, all you need is connectivity. It doesn't matter where the provisioner is, or how often he visits his settlements, just so long as he works the route, So TSP doesn't really apply. The only case where you are actually interested in where your provisioners are, is if you're using them to flush out hostile spawns and keep the area around the route pacified. But if that's the intention, then what you really want is redundancy. Instead of a minimum connectivity tree, set up a mesh with each settlement having a route to all its near neighbours. That maximises the provisioners in the fiel, and again TSP doesn't really apply.

HI O WISE PRINCE. WHT TOOK U SO DAM LONG? Also, it's "deepness". It's maybe not that complicated. You know it's not nifscope, and it's not the nif files. So what other variables are there? How are you using the two files in-game? There's either a difference in the in-game objects that two meshes are attached to, or else there's a difference in how you're triggering the animation. Or possibly, they're both the same, but it's not set up quite right so it doesn't work in all cases.

Furniture is not so dreadfully hard. Make the static mesh, make the idle, and then the rest is CK work. Here's a tutorial. It explains it all in terms of taking poses from pose mods and linking them to vanilla meshes, but it works just as well for hand made meshes and animations.

It might be simpler (if less elegant) to have a separate enable parent for the two objects in question.

You could take a look at the Devious Devices mod over on LL, Highly NSFW, but has the "impossible to take off" thing well and truly solved.

Been doing some work on this as well. I found a Max plugin HavokMax, and the library that drives it: HavocLib. I've got a modified version of Anton's Skyrim scripts to export from Blender to JSON. So if I can just get Havoc lib to compile and link with my own code, I can read the JSON and generate HKX files using (hopefully) proven code. Major hurdle at the moment is that CMake hates me. There are a doze different ways to configure a CMake build, almost all of which fail to compile at some point. The one that does compile, generates no output - which wouldn't be so bad, but it breaks if I try and compile for debug, so I can't debug into the library to see what needs doing. Oh well, if it was easy, everyone would want to do it...

Same as any software project ever. Everyone would love to take the time to overhaul the system and Do It Properly, but doing that takes time away from working on the game and deadlines take priority. So they work around problems and until such time as they get an opportunity to upgrade something. It's frustrating as hell for us modders, mainly because we can't lean back in our chairs, tap the guy responsible on the shoulder and say "how the hell do I do this?" But, that's the hobby. What can you do?

Are you talking nif files or materials? Emissive Multiple changes the brightness in nif shaders Although it only seems to change how bright the node appears to be, and not how much light is thrown - that's a separate mechanism, I believe.

Do you know if Code extensions work for Studio proper? I tend to assume not, but trying to google for it just brings up a mess of VS Code extension github pages.

I am sorry for the "n00b" question, but how do I do that? I haven't really been doing much with "functions" in scripts ... Like this: scriptname statemachine extends quest int START_STATE = 0 const int STEADY_STATE = 1 const int END_STATE = 2 const CustomEvent State_Changed int state_variable = START_STATE property StateVariable function get() return state_variable endfunction function set(int value) ; ; transition checking ; if value == END_STATE if state_variable != STEADY_STATE return ; in any other language we'd raise an exception endif ; as it is, there's no way to communcate the error elsif value = STEADY_STATE if state_variable != START_STATE return endif else return ; can't transition to start state, so anything else is an error endif ; ; set the state ; int old_state = state_variable state_variable = value ; ; raise the event ; var[] args = new var[2] args[0] = state_variable args[1] = state_variable SendCustomEvent("State_Changed", args) endfunction endproperty That's for a simple 3-state machine, where START_STATE can only transition to STEADY_STATE and STEADY_STATE can only go to END_STATE. You'll want something more sophisticated, and probably end up putting the state checking in one or more separate functions. The property thing is the way all properties work "under the hood". Saying int property foo autois just shorthand for int _foo int property foo int function get() return _foo endfunction function set(int value) _foo = value endfunction endproperty ... but you can use the long form to add extra processing to getting and or setting the value.