NifSkope 2.0 Dev

[InsanePlumber]

I asked this question on the Geck beta forums, but being what they are, focused around the Geck beta, I thought here would be more appropriate to refrain:

 

In my experience using earlier NifTools versions for 3dsMax Design 2009 and currently for modding Fallout 4 for 2012, consistently accurate vertex color export has always been and remains an issue. It was stated that this issue only exists with specific tools versions and incorrect export settings.

 

What versions of NifTools are recommended and which export settings are recommended for achieving the best results where it concerns handling vertex colors?

 

Thanks, and I do apologize how it looks and may be interpreted asking the same question twice.

 

 

Maybe this guide will be helpful.

[Jon]

I asked this question on the Geck beta forums, but being what they are, focused around the Geck beta, I thought here would be more appropriate to refrain:

 

Not really.. Not just because I'm on the NifTools team.  This is still a thread about the development of NifSkope.  IP provided a link though which may help you.  You should redirect any discussion about vertex colors and Max there. 

[TrickyVein]

Not really.. Not just because I'm on the NifTools team.  This is still a thread about the development of NifSkope.  IP provided a link though which may help you.  You should redirect any discussion about vertex colors and Max there. 

 

Even better. So to ask a relevant question:

 

Who's idea was it to put the undo button right next to the save button? 

 

My aim isn't always true, sad to say and undoing some action more often than not crashes the program at the exact time I want to save my work.

[Roy Batty]

When exporting more than one mesh to obj, it uses the previous loaded file for the filename suggestion instead of the current one.

[lmstearn]

This is very rudimentary, but it works-ish.

class Program
{
	static void Main(string[] args)
	{
		using (BinaryReader b = new BinaryReader(File.Open(args[0], FileMode.Open)))
		{
			b.BaseStream.Seek(500, SeekOrigin.Begin);
			byte[] byteArray = b.ReadBytes(500);

			string sHex = ByteArrayToString(byteArray).ToUpper();
			if (sHex.IndexOf("C200", StringComparison.CurrentCulture) > 0)
				Console.WriteLine(args[0]);
		}
	}

	static string ByteArrayToString(byte[] ba)
	{
		string hex = BitConverter.ToString(ba);
		return hex.Replace("-", "");
	}
}

Nice. Consider this... Ew C#!!! Well in that case MSDN insists on try / catch: 

 

class Program {
	static void Main(string[] args)
	{
		using (BinaryReader b = new BinaryReader(File.Open(args[0], FileMode.Open)))
		{
                    try
                    {
			b.BaseStream.Seek(500, SeekOrigin.Begin);
			byte[] byteArray = b.ReadBytes(500);

			string sHex = ByteArrayToString(byteArray).ToUpper();
			if (sHex.IndexOf("C200", StringComparison.CurrentCulture) > 0)
				Console.WriteLine(args[0]);
                   }
                   catch(EndOfStreamException e)
                   {
                   Console.WriteLine("Error writing data: {0}.", e.GetType().Name);
                   }

		}
	}

	static string ByteArrayToString(byte[] ba)
	{
		string hex = BitConverter.ToString(ba);
		return hex.Replace("-", "");
	}
}

And to be nicer implement a dispose method? Edit: Not to mention locale concerns with UTF8 and UTF16 etc.

Could a C++ version of something like this be even added to the Creation Kit Extender wishlist?

[fireundubh]

Well, that program is very rudimentary in the sense that it produces false positives. It's just looking for "194" in 500 bytes from a safe position, but it doesn't account for any extreme variability. Honestly, the right way to write such a program would be to load the header block and look at the value of BSXFlags directly, but this worked for my purposes.

[hypno88]

What am I doing wrong? NifSkope doesn't want to load a fallout 4 mesh for me

- Fresh copy of NifSkope 2.0 Pre Alpha 5 (2016-04-20)

- Using B.A.E I extract "Meshes/SetDressing/FalloutShelter/FalloutShelter.nif"

But when I try and open it in NifSkope it says it cannot load the file. Then a second message says the file could not be read and "failed to load file header (version 14020007, 20.2.0.7)". What am I forgetting? All I wanted to do was just delete the sliding door from the nif but I'm falling at the first hurdle

- Hypno

[TrickyVein]

If you've used NifSkope in the past (1.1.3) are you absolutely sure that you're using the correct version (2.0)? Maybe you still have the old one installed.

[hypno88]

If you've used NifSkope in the past (1.1.3) are you absolutely sure that you're using the correct version (2.0)? Maybe you still have the old one installed.

I'm pretty sure it was saying 2.0 Rev 5 at the top while I was pulling my hair out last night, but now you've got me doubting myself lol. I'll scour my system for any sneaky old versions and download the new one again just to be sure. Either way, I'll report back soon

EDIT: Nope, definitely the latest version. For me it starts up with errors about the shaders not working. Then when I open up the FalloutShelter.nif it doesn't like the header. I'm stumped?

Shot in the dark: Any chance of a charitable soul taking pity on my frustrations by deleting the door out of "SetDressing/FalloutShelter/FalloutShelter.nif" and PM'ing me a link?

- Hypno

[fireundubh]

I've been trying to figure out how to assign impact sounds to objects in Fallout 4.

 

Take the Broom as an example.

• PHYWoodBroomImpact [iPCT:001D4A5D] is referenced by PHYWoodBroomImpactSet [iPDS:001D4A5E]
• PHYWoodBroomImpactSet [iPDS:001D4A5E] is referenced by MaterialWoodBroom [MATT:001D4A52]
• MaterialWoodBroom [MATT:001D4A52]'s parent material is Material_Wood [MATT:00043DCC]
• Material_Wood [MATT:00043DCC]'s parent material is Material__GenericMaster [MATT:000223D2]

There are no further links within Fallout4.esm.

 

Is it possible that the bhkPhysicsSystem blob specifies the MATT used by a NIF?

[zilav]

Is it possible that the bhkPhysicsSystem blob specifies the MATT used by a NIF?

In Skyrim MATT records correspond to havok material value you set in nif collision nodes. 100% sure it is the same in Fallout 4.

[Jon]

@hypno88 ...  PM me the file you are trying to open.  I am guessing it's somehow been corrupted.  Because if you're actually using the latest version there is no possible way you can't open the vanilla file with that name.   In fact, try to open it directly from the BA2 using the Archive Browser from inside NifSkope.   If you already are, or do and still get the error then I'm extra stumped.   And you also claim shader errors which seems very odd.   Where did you extract the package to?   Was it an existing NifSkope directory?   If so,  install to a new directory.

 

@fireundubh ...  The materials are defined in the bhkPhysicsSystem on a per-triangle basis.  If consecutive triangles are the same material, it groups them.  So it says something like Tris 0-5 are Material #1,  Triangles 6-7 are Material #2,   Triangles 8-24 are Material #3,  and Triangle 25-26 are Material #1.   I haven't yet written a binary parser to read this block's data, but when I do it will likely just be displaying a subset of the data (incl. rendering the collision).  No editing.   But I do know how to parse it at least.

[jsnider193]

Registered primarily to say thanks for the work on this  ... feel the luv for this project.  Was able to start moving some of my FNV items over to FO4 using it  ... great even.

 

Oh and for the nif (@hypno88) .. I did check it out once read and was able to open same with alpha5 with no problem.  One thing though on same, i open the nif's from within NifSkope if try to click on the nif and have it bring up skope fails for me but once open the program able to open all the nifs.

[Jon]

> One thing though on same, i open the nif's from within NifSkope if try to click on the nif and have it bring up skope fails for me but once open the program able to open all the nifs.

 

I don't really understand.  At first it sounds like you're talking about opening via the Archive Browser, but then you say "once open".   Are you talking about double clicking on NIFs in Windows?   If so, is it opening the correct instance of NifSkope or is it pointing at an older version?  If so you should move that older version and put 2.0dev5 in its place.

[Kesta]

If this somehow help : with previous version (haven't used nifskope since 2.0.5), on my system, opening a nif by double-clicking on it worked properly, but nifskope would take several seconds, sometimes even up to 1 minute, to open.

Once opened, double-clicking in explorer on an other nif opened it instantly, despite the fact that it was in a "completely new" instance of nifskope.

[TrickyVein]

If you're rendering textures in nifskope's " view then depending on your system it can take longer. Try disabling rendering textures or materials.

[Jon]

You're right.. There's something weird with double clicking to open NIFs.   It shouldn't be hanging like that (mine hangs for just a few seconds).   I assumed dragging a file directly to the executable would be the same as double clicking, and dragging works fine.  But apparently it's not synonymous.   My double click to open association was still with NifSkope 1.1.x so it's not something I've ever witnessed.

 

I'll look into it.

 

Edit:  OK, so after double clicking several files and closing NifSkope each time,  it no longer seems to pause oddly during loading the file.  I have no idea how I'm going to debug this when it seems to have stopped for me.  

[Arthmoor]

I thought I was just stressing my system when that happened.

 

For me, it's always JUST the first one that's opened. Depending on the complexity, it's anywhere from about 10 seconds up to 2 minutes before it loads to a display. Every other nif opened during the same session loads up almost instantly.

 

Close all the open tasks, and it seems to be fine for awhile but eventually goes back to a super long load time if it's left closed long enough.

[Jon]

Can anybody say for sure when it started for them?   Or has 2.0 always done it?

 

Can you confirm that it doesn't take long the first time if you only ever drag files to the EXE or if you open NifSkope first and then open up files?  

 

I just really have no idea what is so different about double clicking it from Windows vs dragging the file to the shortcut/exe. 

[jsnider193]

Ah never to clear the bane of my life ... I open NifSkope up 1st then use the 'open' button to get to/navigate to the nif want to have fun with.  When dclk get similar results to above with every now and then an error, never have the issue with opening from within nifskope and since that has always been my preferred method never gave it much thought (bad tester I know).

 

Now if could just understand the convert in block better .. works for some meshes but not for others ... oh well still a fun game program is nifskope.

[Jon]

NifSkope 2.0 Experimental Build (2016-05-07)

 

Could anyone that reliably gets the "long pause on double-click-to-open issue" please test this build and tell me if the issue persists?  I disabled some things that could be causing it.   It also fixes an issue where some parts of the app thought the current directory was the directory of the file you opened when double clicking.  This was breaking shaders namely.

 

Please make sure to replace the NifSkope that Windows associates with the Open With menu so that double clicking NIFs actually opens the above build!

 

Anyone using the previous experimental build from 2016-04-23 should also upgrade.  @kikaimegami ... if you still want to try to break things I would appreciate it.  I believe all the random issues you reported are resolved (file marking/not marking modified,  Transform > Apply issues, etc).  

[Kesta]

Seems fixed. Obliviously I can't say it just improved the startup time to something less noticeable or if it's now behaving exactly as you thought it did, but after rebooting my PC, it took barely 2 or 3 second to open a nif by double-clicking on it.

 

Before updating, I also tried the drag'n'drop and yes, it worked without delay.

 

 

If this is of any use for you, I know that the xEdit script I wrote a few weeks back to open .nif also suffered from the "ultra-long first time opening a .nif" issue. It started a process for nifskope with the nif as parameter, which is also how shortcut with double-clicks behave in windows.

 

Edit: By the way, when you say previous version could break the shader, could this be the cause of this issue:

 

 

I created the nif by just copying The two NiNode of the cooking plate and the pot under a parent node in an other nif, and the pot is purple in CK and in-game, while it's properly rendered in NifSkope: 

 

The CK used to give give an error about shader when I opened the preview of the object, but he don't want to give me any error anymore 

 

Edit2 : If it was an issue with nifskope, it's still here, rebuilt the mesh with alpha6 didn't help. But considering how good I am when it comes to nif, it's probably an user error ^^

[TrickyVein]

Most of bethesda's own resources when previewed in the CK generate the same MODELS:BASE error, '...has a envmap which is not a cubemap which will cause D3D errors,' so I think it can be ignored, if that's the one you're referring to.

 

Also, the mesh is probably not rendering in the game because the BSShaderLightingProperty has to be named a filepath to a valid material. Even though NifSkope will render maps in BSShaderTextureSets, these are actually redundant and completely ignored where a material is used.

 

Some special effect meshes still make use of texture sets, but static objects and most other things require a material. 

[Kesta]

Most of bethesda's own resources when previewed in the CK generate the same MODELS:BASE error, '...has a envmap which is not a cubemap which will cause D3D errors,' so I think it can be ignored, if that's the one you're referring to.

 

Also, the mesh is probably not rendering in the game because the BSShaderLightingProperty has to be named a filepath to a valid material. Even though NifSkope will render maps in BSShaderTextureSets, these are actually redundant and completely ignored where a material is used.

 

Some special effect meshes still make use of texture sets, but static objects and most other things require a material. 

 

Thanks, it worked. The hotplate part displayed properly because it's apparently not using material (at least the BSLightingShaderProperty in the original property isn't named after a bgsm)

 

And yep, I think the error was the one you're mentioning.

[InsanePlumber]

I did not experience the described problems. (Windows 7 x64)

Delay when opening NIF files by double-click on NIF, and then another double-click on the next NIF while maintaining previous NifSkope window, or drag a few or more NIF files (tested with 20 files) on shortcuts to the application.

Even on the old laptop with 1GB graphics card.

 

 

When we have associated applications to a file, change the association for the file can be troublesome if you want to use the application with the executable file that has exactly the same name but is located in a different location.

Here's a quick way to force Windows to change the default application for the file in this case.

 

- RMB on NIF file in Windows Explorer.

- Open With

- Choose default program

- Now select for example Notepad, Yes choose Notepad to open NIF file and select  >>> "Alwys use the selected program to open this kind of file" <<<

- Click [Ok]

- Wait until Notepad to open NIF and close Notepad

- Restart PC

 

After the restart.

 

Now do the same thing again, but this time choose NifSkope.exe

- RMB on NIF file in Windows Explorer.

- Open With

- Choose default program

- Select >>> "Alwys use the selected program to open this kind of file" <<<

- Browse... and point new locations for NifSkope.exe

- Click [Ok]

Done.

 

Reset all NifSkope Setings

 

- Create a new file, for example (NifSkope.txt)

- Add this content

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\NifTools\NifSkope 2.0]

- Change the extension of file to (NifSkope.reg)

- Start with administrator privileges.

 

Thank you for the update Jon.