neok182 Posted December 30, 2011 Share Posted December 30, 2011 decided to make a post just on this error, since my other topic was another issue that i've since figured out. i'm using nifskope from here: http://sourceforge.net/projects/niftools/files/nifskope/ it loads skyrim nifs without any problem, but if i try to save i get this warning: 'link points to wrong block type' i get this error even if just open a file and try to save it. i don't have to do anything. so i'm really hoping that someone can help me out here because i have a mod i'm really looking forward to putting out, but i need to be able to save it lol. Link to comment Share on other sites More sharing options...
Ghogiel Posted December 30, 2011 Share Posted December 30, 2011 (edited) it's more a warning than an error, it should highlight the block in question when you get it too. Without stating what block exactly is linked incorrectly it's not much help. however you can probably ignore it. Nifskope might not realise that the link does point to a correct block type, it should still save even if you did get that warning, saying that I don't get that error. So it's down to your nifskope/xml setup soemwheres Edited December 30, 2011 by Ghogiel Link to comment Share on other sites More sharing options...
neok182 Posted December 31, 2011 Author Share Posted December 31, 2011 well you were right, it does save what i've changed. but it doesn't work. game crashes when loading the dawnbreaker. and considering my changes were just to texture paths, i'm assuming it's crashing because of the error. so the firstperson file says link points to wrong block type and highlights under 14 nitrishape bloodlight 20: properties--> properties ref<niproperty> 17 [nifloatinterpolator] the main nif has the same warning and it highlights under 9 nitrishape bloodlight01 [5] properties--> properties ref<niproperty> 12 [bSLightingShaderProperty] any ideas? or am i just going to have to wait for another new version of nifskope to do anything here. Link to comment Share on other sites More sharing options...
dxraptor Posted December 31, 2011 Share Posted December 31, 2011 (edited) Yeah I have the same problem when saving in nifskope. But only when i try to save nif's modified in max. Even with the error modified armor seems to work just fine. Hopefully its like Ghogiel said and it's nothing to worry about. Sorry, though i just stated my "similar" problem, I can't really be of any help since i have no idea how nifskope works. :unsure: Edited December 31, 2011 by dxraptor Link to comment Share on other sites More sharing options...
neok182 Posted December 31, 2011 Author Share Posted December 31, 2011 thats okay. i have a feeling that nifskope just isn't fully skyrim compatible yet. though i see lots of people getting new models in and i'd love to know if nifskope works for them. this mod will eventually get done, i was just hoping to do it before my break ended. and looks like that may not happen unless someone can get in this topic and help. Link to comment Share on other sites More sharing options...
bobbythehacker Posted January 3, 2012 Share Posted January 3, 2012 I have the same "link points to wrong block type" warning when saving NOT modified FNV nif's since i changed my version number from 20.0.0.5 to 20.2.0.7 ... I suspect the culprit is in the .XML (my Skyrim meshes don't give me this warning only the Fallout ones...) I'm using nifskope-1.1.0-rc1-i686-w32 (rc4 does work for me) Link to comment Share on other sites More sharing options...
vixyn Posted January 9, 2012 Share Posted January 9, 2012 Hopefully this post isn't too late to be useful to those of you with the error, but there is a very, very simple fix for this error and issue. As follows: Open NifSkope.In the upper left corner, click "File".Go down to the fifth option - "Auto Sanitize before Save". Uncheck this.Profit. The issue is caused by Skyrim needing, apparently, a specific block order. NifSkope's auto-sanitize reorders these into the Oblivion block order... which is not the order that Skyrim meshes need. Link to comment Share on other sites More sharing options...
Ghogiel Posted January 9, 2012 Share Posted January 9, 2012 The issue is caused by Skyrim needing, apparently, a specific block order. NifSkope's auto-sanitize reorders these into the Oblivion block order... which is not the order that Skyrim meshes need.apparently being the key word here.. the only thing I heard anyone said that might be specific in skyrims block list order is that bones in vanilla skyrim nifs are ordered above the trishapes in skinned meshes. Nifskope will reorder those to be at the bottom of the list. this has zero function in game and doesn't seem to matter either way as witnessed by myself and the hundreds of modded skinned meshes out there at this point. Link to comment Share on other sites More sharing options...
vixyn Posted January 9, 2012 Share Posted January 9, 2012 this has zero function in game and doesn't seem to matter either way as witnessed by myself and the hundreds of modded skinned meshes out there at this point. Yeah, for most things it doesn't seem to matter. With some of the default meshes I've played with - changing textures paths and other very basic changes - the game has crashed. Turning off sanitize and resaving them with the meshes original order has stopped the files from crashing the game (mainly the jewelry meshes, if you want to try and replicate the crashing. I'm working on making the rings a bit less... bland, so these are what I did the most testing with. Oh, and fixing the stupid mirrored UVMap.). Link to comment Share on other sites More sharing options...
throttlekitty Posted January 9, 2012 Share Posted January 9, 2012 The issue is caused by Skyrim needing, apparently, a specific block order. NifSkope's auto-sanitize reorders these into the Oblivion block order... which is not the order that Skyrim meshes need.Unchecking auto-sanitize also removes the sanity check related to this error. The actual issue is partly related to the current nif.xml, should have a fix soon. I'm fairly sure that structure-based crashes like that are mismatches in _0 and _1 versions of the file. Link to comment Share on other sites More sharing options...
Recommended Posts