keithinhanoi

In Dark One's extremely insightful and prophetical post last month, he pondered this: There's no need to name names, it is a fact that a number of the initial set of paid Skyrim mods now available on Steam Workshop make use of other people's work. Models, textures, scripting functions, translations, etc. Valve thought of this, and so they allow a paid mod uploader to add Contributors, as explained on the Steam Workshop's web page explaining paid user content. However, I don't see any evidence that there's an vetting process for mods uploaded as paid content. Valve's approach is not pro-active, but rather user-dependent, by way of a DCMA Takedown Notice form that anyone can use. This form is a bit scary, as it makes it clear that people can be liable for damages if they "knowingly" make a false infringement claim. But I wonder who actually handles the burden of proof? Further to that, if someone takes ("steals") a mod freely available here on Nexus and then uploads it as paid user content on the Steam Workshop, will DCMA Takedown requests be ignored if the original mod author hasn't included a clear written copyright notice? And how is it handled if a mod author has used the work / resources of others with permission - but that permission was only given while the mod using those resources was given freely, and no permission was secured again before the mod was uploaded as paid user content. And then, even after securing permissions, if a user has opted to use Valve's add Contributors feature to share any revenue, what happens with contributors who do not have Steam user account (and do not wish to have one, for that matter)? How will they receive what is due to them? I see this all being very very murky and unclear.

If it's an issue with the NifTools exporter plugin for 3DS Max, then why not post in their forums, here? Alternatively, posting in the NifTools Skyrim Modding forum area might be helpful. Just thinking out loud here...

Please excuse my complete and total ignorance, but I see that there's a 3DSMax script called Autoweight which helps with weight painting and setting up transitions between regions of the creature's skin. I notice it mentions it will work with custom bone hierarchies, so it is not limited to biped creatures. There are tutorial videos for version 1, but the newest version works with 3DSMax 2015. Unfortunately, the full version does cost $30 US, but it has a feature limited demo mode to try it out. Also there's a free "Lite" version. I notice in the comments of one of the tutorial videos (from almost a year ago) that the script does the auto-weighting before the bones are animated. I don't know if that would be a deal-breaker for you, or if the newest version of the script includes auto-weighting after the bones are animated, but I thought it's worth pointing out. I hope this helps! EDIT: I see there are other Max auto-skinning scripts for free, but they may only work with biped creatures.

Well, the USKP-fixed version of the lvlpredatorscript has not changed since USKP 1.3.3, so what steve40 says in the OP for this thread is still true: To confirm "The USKP script won't fix errors on mods that add their own predators and override vanilla ones," you can look at the USKP version history change notes, and see this: Although lvlpredatorscript doesn't cause CTDs, I really don't want Papyrus log spam from it when I am trying to hunt down scripts that are actually causing problems besides CTDs. Since I use a good number of mods that add their own predators, I've chosen to use steve40's script. As for recompiling steve40's script, it actually can be done in Notepad++, but you need to set some things up first for it to work. This is explained in this Creation Kit wiki page. I hope that helps.

Since the time I last posted on this thread, I have learned that after making these kinds of edits to navmesh records, it would also be a good idea to rebuild the Navigation Mesh Info Map (NAVI) record. The only way to do this is to open up CornerofTheSkyrim.esp in CreationKit and then save it. Using the "finalize navigation meshes" tool may also help with that 5th deleted navmesh record, but as soupdragon1234 explains, an even better solution is to do some editing to the navmesh triangles in CK - still something I haven't tried yet, despite having read up on it and watched some tutorial videos. Even if someone fixes it, the real issue seems to be how to get permission to share a fixed version with others, because the author, alaken, seems to have gone inactive. S/he was last online a month ago, and still hasn't replied to my PM to her/him. I suppose if a fixed version is made, then the author could be contacted to ask permission to distribute a fixed replacement or patch .esp plugin. EDIT: Also with regards to TES5Edit not showing where deleted NavMesh records are, if you are using the latest svn release of v3.0.33, obtained here, then when you use the Apply Filter for Cleaning, followed by Undelete and Disable References, you will see output like this in the Messages tab: [00:00] All Done! [Filtering done] Processed Records: 890323 Elapsed Time: 00:02 Skipping: [NAVM:000FFDE3] (in GRUP Cell Temporary Children of [CELL:0000BBF2] (in Tamriel "Skyrim" [WRLD:0000003C] at 33,-17)) Skipping: [NAVM:000FF811] (in GRUP Cell Temporary Children of [CELL:0000909A] (in Tamriel "Skyrim" [WRLD:0000003C] at 18,9)) Skipping: [NAVM:000FBFCC] (in GRUP Cell Temporary Children of [CELL:00009625] (in Tamriel "Skyrim" [WRLD:0000003C] at 25,-4)) Skipping: [NAVM:000EB002] (in GRUP Cell Temporary Children of [CELL:000096D3] (in Tamriel "Skyrim" [WRLD:0000003C] at 6,-9)) Skipping: [NAVM:00106CED] (in GRUP Cell Temporary Children of [CELL:00009236] (in Tamriel "Skyrim" [WRLD:0000003C] at -14,27)) [Undeleting and Disabling References done] Processed Records: 1643, Undeleted Records: 0, Elapsed Time: 00:00 <Warning: Plugin contains 5 deleted NavMeshes which can not be undeleted> That should tell you everything you need to know about where to find the deleted NavMesh references. EDIT #2: Looking at it again in TES5Edit, I see that I probably choose the wrong replacement for the 4th deleted NavMesh: Actually record XX016368 in CornerofTheSkyrim.esp has very little NavMesh triangle data in it, while XX016368 is very similar to 000FFDE3. Therefore, I'm quite sure that after removing 000FFDE3 from CornerofTheSkyrim.esp, the FormID of XX016368 should be changed to 000FFDE3. Apologies for that error! I have a couple days off from work in this coming holiday week, so I will try opening up a "fixed" copy of CornerofTheSkyrim.esp in the CK, and take a look at those four areas to make sure there aren't any breaks between the changed NavMeshes and the surrounding vanilla ones.

First off, those warning messages have nothing to do with CTDs in your game. They would appear just after loading a savegame, when there are plenty of other reasons for Skyrim to CTD, and it's just coincidence that they are the last things you see the Papyrus log. With what this script does, it's pretty much impossible to cause a CTD. I also see dozens of warnings like this when I turn on Papyrus logging for my current game, but I don't get any CTDs when loading my savegame, and they're very rare for me in general, despite having near 250 plugins in my load order and numerous script "heavy" mods. The reason why this "fixed" script exists in the first place is to reduce the amount of "log spam" that lvlpredatorscript causes in the Papyrus log, which is really only helpful to people debugging their papyrus scripts, or users who are supplying their Papyrus logs to a mod creator for the purpose of debugging. Papyrus scripts serve no real purpose in helping Skyrim users troubleshoot reasons for CTDs. Now that this has been cleared up, let's look at why these errors are showing up. If you were in the middle of an already started game in Skyrim with the USKP (Unofficial Skyrim Patch) installed, it had already provided a "fixed" lvlpredatorscript, which was being used and attached to predators. These have references (also called FormID) which get written into your savegames for your current player character. In that edited lvlpredatorscript that the USKP provides, it sets up a number properties (think: variables) for each instance of the script, and two of them are named LinkCustom09 and LinkCustom10. Every time you load a savegame, Papyrus has to initialize script instances that are attached to references saved in your savegame, and the properties listed for the attached script have to match the list of properties in the master script itself. If you later install steve40's version of the lvlpredatorscript, all of the predators' references that have the lvlpredatorscript attached to them in your savegame will not have a matching list of properties to the master script because steve40's version of the script does not use the LinkCustom09 and LinkCustom10 properties. If this really bothers anyone, I'm pretty sure the warnings can be suppressed by adding unused LinkCustom09 and LinkCustom10 property definitions to the the source code of steve40's version of lvlpredatorscript, and then recompiling it. In version 2.2 of his script, he's already added a few unused property definitions to reduce log warning spam for USKP users, so I'd suggest adding the LinkCustom09 and LinkCustom10 definitions just after the definition for USKPPredatorInverseEnableParent as follows: Keyword Property USKPPredatorEnableParentInjected Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used - STEVE40 Keyword Property USKPPredatorInverseEnableParentInjected Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used - STEVE40 Keyword Property USKPPredatorEnableParent Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used - STEVE40 Keyword Property USKPPredatorInverseEnableParent Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used - STEVE40 Keyword Property LinkCustom09 Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used and you installed Steve40's script to an in-progress game. - keithinhanoi Keyword Property LinkCustom10 Auto ; NOT USED. Added to prevent warnings in the log if USKP is being used and you installed Steve40's script to an in-progress game. - keithinhanoi Note that the above text is just the relevant section of steve40's script, not the whole thing. After adding the LinkCustom09 and LinkCustom10 property definitions to my copy of steve40's script, recompiling it, installing it, and opening my current savegame, I see that all of those warnings are gone from my Papyrus log, and I now just have 3 errors like this: [11/10/2014 - 02:43:21PM] Error: Failed to read basic script data for lvlpredatorscript attached to (00082644) Although that's an error instead of a warning message, it wont lead to any game-breaking problems. I could use one of the two savegame "cleaner" programs, like Papyrus Data Transfer (AKA "Savegame script scalpel") to get rid of those 3 attached script instances, but I wouldn't be too worried about it, honestly. EDIT: A few savegames later, I checked and even those "Failed to read basic script data..." errors are gone, so those four attached script instances have been flushed out.

Apologies, because I had to cancel after 20 minutes. I am currently seeing speeds from 200KB/s to 800KB/s when I try downloading from a variety of sources. I could try starting a full test tomorrow when leaving for work... -------------------------------------------------------------------------------- Proxy detected: none -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Diagnosing http://filedelivery.nexusmods.com/1/2/256MB-1-0-1.rar?ttl=2147483647&setec=94cadea35b83be28c03f37ee675c2373 -------------------------------------------------------------------------------- Keep-Alive: timeout=10, max=100 Connection: Keep-Alive X-HW: 1415282963.dop007.la2.t,1415282963.cds007.la2.c Content-Disposition: attachment; filename="256MB-1-0-1.rar" Accept-Ranges: bytes Content-Length: 268435456 Cache-Control: max-age=31324225 Content-Type: application/octet-stream; charset=binary Date: Thu, 06 Nov 2014 14:09:23 GMT ETag: "1413035840" Last-Modified: Sat, 11 Oct 2014 13:57:20 GMT Status Description: OK. -------------------------------------------------------------------------------- Average speed: 16.7 KB/s for 100.0 KB. Total: 100.0 KB. Average speed: 22.4 KB/s for 84.5 KB. Total: 184.5 KB. Average speed: 13.8 KB/s for 15.5 KB. Total: 200.0 KB. Average speed: 7.8 KB/s for 5.6 KB. Total: 205.6 KB. Average speed: 6.5 KB/s for 15.5 KB. Total: 221.1 KB. Average speed: 3.7 KB/s for 2.8 KB. Total: 223.9 KB. Average speed: 4.0 KB/s for 12.7 KB. Total: 236.6 KB. Average speed: 2.7 KB/s for 4.2 KB. Total: 240.8 KB. Average speed: 1.6 KB/s for 1.4 KB. Total: 242.2 KB. Average speed: 1.7 KB/s for 5.6 KB. Total: 247.8 KB. Average speed: 5.3 KB/s for 26.8 KB. Total: 274.6 KB. Average speed: 4.5 KB/s for 11.3 KB. Total: 285.9 KB. Average speed: 5.1 KB/s for 16.9 KB. Total: 302.8 KB. Average speed: 5.4 KB/s for 16.9 KB. Total: 319.7 KB. Average speed: 8.1 KB/s for 32.4 KB. Total: 352.1 KB. Average speed: 4.7 KB/s for 4.2 KB. Total: 356.3 KB. Average speed: 9.2 KB/s for 40.8 KB. Total: 397.1 KB. Average speed: 10.0 KB/s for 32.4 KB. Total: 429.5 KB. Average speed: 12.0 KB/s for 42.2 KB. Total: 471.7 KB. Average speed: 8.8 KB/s for 16.9 KB. Total: 488.6 KB. Average speed: 4.7 KB/s for 1.4 KB. Total: 490.1 KB. Average speed: 5.4 KB/s for 18.3 KB. Total: 508.4 KB. Average speed: 2.9 KB/s for 1.4 KB. Total: 509.8 KB. Average speed: 2.2 KB/s for 4.2 KB. Total: 514.0 KB. Average speed: 3.0 KB/s for 11.3 KB. Total: 525.3 KB. Average speed: 1.9 KB/s for 2.8 KB. Total: 528.1 KB. Average speed: 2.9 KB/s for 11.3 KB. Total: 539.3 KB. Average speed: 2.6 KB/s for 7.0 KB. Total: 546.4 KB. Average speed: 2.7 KB/s for 8.4 KB. Total: 554.8 KB. Average speed: 2.8 KB/s for 8.4 KB. Total: 563.3 KB. Average speed: 2.8 KB/s for 8.4 KB. Total: 571.7 KB. Average speed: 3.3 KB/s for 11.3 KB. Total: 583.0 KB. Average speed: 1.9 KB/s for 1.4 KB. Total: 584.4 KB. Average speed: 1.2 KB/s for 1.4 KB. Total: 585.8 KB. Average speed: 3.6 KB/s for 18.3 KB. Total: 604.1 KB. Average speed: 3.0 KB/s for 7.0 KB. Total: 611.2 KB. Average speed: 5.0 KB/s for 21.1 KB. Total: 632.3 KB. Average speed: 3.4 KB/s for 5.6 KB. Total: 637.9 KB. Average speed: 2.9 KB/s for 7.0 KB. Total: 645.0 KB. -------------------------------------------------------------------------------- Expected size was: 256.0 MB. Downloaded 645.0 KB in 1414 seconds. Calculated speed: 467.0 B/s. Maximum instant speed reached: 33.3 KB/s -------------------------------------------------------------------------------- http://www.speedtest.net/result/3888558397.png

Nope. No reply yet. :sad:

i diden't becouse i also thought countless people probably already have LOL. That's the kind of thinking that leads to nobody contacting the author. :) I will do it.

I thought it might be too obvious to ask - but has anyone contacted the author of the mod to find out if he/she can go back and fix the Nav Meshing? I see that he/she was last active on Nexus back in July, which isn't too long ago.

Hi again. Firstly, I have to admit that I am much more comfortable in TES5Edit than in CK, and I basically have no experience with working with navmeshes in CK, but hope to learn very soon. So, when I've fixed deleted vanilla navmesh records in past, and there were more than two new navmeshes supplied by the mod in that same cell, I looked at the size of the original copy (in Skyrim.esm, etc) of the record and other aspects of it to help me decide which of the mod's navmeshes was accidentally set to "replace" the vanilla navmesh. I looked at the CornerofTheSkyrim.esp plugin supplied by the main v1.2 download of the mod, with the note "With NPC ver. Dirty edits and NPC faces Fix". Using my quicker but less effective method of deciding which new navmesh replaces the vanilla one with the deleted flag, I can recommend trying this for four of the five deleted navmeshes: Remove 000EB002 and assign XX00BE3B to be 000EB002 Remove 000FBFCC and assign XX005274 to be 000FBFCCRemove 000FF811 and assign XX010507 to be 000FF811Remove 000FFDE3 and assign XX016369 to be 000FFDE3 (note that XX should be the hex prefix of CornerofTheSkyrim.esp as displayed in TES5Edit. Since it was the only 3rd party mod I loaded when I looked at it in TES5Edit, the prefix for me was 01....) However, when I look at the cell with the deleted vanilla navmesh 00106CED, I do not see any new navmesh supplied by the mod that should replace it. So in this case, I suggest editing the flags for the copy that record in CornerofTheSkyrim.esp, and turn off the Deleted flag. I think it should work, in theory, because when I check that record in Skyrim.esm, there are no other records that refer to it. Generally speaking, though, just from what I'm seeing in TES5Edit, it would be a much better idea to look at things in CK. But if it involves actually editing the navmeshes, be prepared for learning something new, and not very easy, from what I understand. I hope that helps - best of luck with it!

Hmm, although that's the correct method, there's no guarantee that the navmesh record directly under the original one (marked as deleted) will be the correct replacement. Looking at them in CK would be a better way to make sure of it. I'll download the mod and take a look myself. Might take a day or two to get back to you, though.

Basically what you are doing is looking for the original "vanilla" that was accidentally marked as deleted, and the new version of it with the author's changes, and then assigning the original navmesh's Form ID to the new one - but you have to actually totally remove the record for the original before you do that. In those last two steps, you have already removed the record for the original navmesh which was accidentally marked as deleted, and you should have written down its FormID. Now you are going to assign that FormID to the new navmesh that the author created. You have to right-click on the FormID of the new navmesh, in the left-pane of the TES5Edit window, and choose "Change FormID". Type in the FormID of the original navmesh record that you just removed. Then you get another pop-up window, which shows all of the other records that make references to the FormID of the author's new navmesh. All of those need to be updated so they refer to the FormID you've just changed to. So that's why you right click on one of the items in the list, choose "select all", and then hit "Okay". I hope that makes sense. Perhaps I will try making a video tutorial for this, since I recently got a new GTX 760 and Nvidia provides software that makes it pretty easy to do that.

Announcement good. Concept better. Team members best. It's simply amazing to see this kind of collaboration on high quality DLC-type content three years after the game's release. Looking so forward to it, and thanks so much on deciding to work together!

Hi - steve40, if you're still checking this thread, I have a question about the fxfakecritterscript.pex script that is included in skyBirds, but not in your critter script fix collection here. I see that fxfakecritterscript.pex is found in your mod skyBirds, which I use, and it's also included in USKP v2.0.X, but I have to assume since skyBirds' assets load after USKP's (according to the BSAs following plugin load order,) that either skyBirds makes some necessary changes over the one in USKP, or it's the same thing. I'm currently getting set up to start a new game, and have seen that bluedanieru's Flora Respawn Fix v2.1 has come out of beta, so I'm planning on using it, but it also includes fxfakecritterscript.pex. I asked him about it, and his reply was: It's different from both. Use whichever you like. I included that so critter respawns behave like the flora respawns, where the time starts when you harvest and leaving the area or not doesn't matter. Since it's a loose file, it would win the overwrite "battle" when Skyim is run, but I'm hesitant to start the game not knowing which of the three versions of this particular script is the one I should be using. Could you shed any light on this? TIA