NifSkope 2.0 Dev

[KKthebeast]

Really i meant just show the total bounds so i could update the Object bounds in the Esp or is that there too?

[KKthebeast]

Also has your smart brain figured out how to view or move Collision yet? I heard it used to be in there but smt changed.

[hlp]

Hey Mr. Jon, Would it be at all possible to get a spell to Calculate object bounds. Have been doing a lot buildable objects and smashing together BSTriShapes. I know this feature exsists in CK but every time i run it, my esps end up shrinking by about 30k, Im not sure what the CK is deleting but it freaks me out, since the esp is 100% xEdit.

 

You can use xEdit to compare your esp before and after updating it with the CK to see the difference. And by the way you should assume the CK version to be the good one. Publishing ESP that have never been "validated" by the CK should not be done.

[TrickyVein]

@jon I have to ask, and it may be esoteric but I figure you have knowledge of this stuff, so:

 

are there any data in bhkRigidBody for NV-engine collision that determines whether an object floats on water?

 

is it buried in any one of the Unknown variables that I'm not seeing? Comparing one .nif which floats on water to one which doesn't reveals very little, unfortunately. 

[Jon]

I'm sure that information is somewhere.  Googling "bhkRigidBody water" brings up some results.  I would just copy the bhkRigidBody of something that does float, if you can.  It probably has to be Clutter for the collision layer.

 

Anyway, this really wasn't the thread to ask as it doesn't have anything to do with NifSkope. 

[TrickyVein]

I appreciate that, but I'm sure you would agree that NifSkope is in fact the only program that displays such detailed information about collision formats for the engine, and is probably the best tool for being able to edit such specifics of havok behavior. I'd hoped that would be relevant

 

There are a lot of details about collision which remain as unknown variables which I would think would be of interest, since the matter of dealing with Fallout 4's new collision format was and still is of some importance within the program.

[Jon]

NifSkope just displays what nif.xml tells it to, and nifxml is an entirely separate project.   This thread is about the development of NifSkope and help/feedback/bug reports for NifSkope.   You were asking for help with the NIF format (bhkRigidBody) specifically for F:NV, and just because NifSkope displays this information doesn't make that relevant to the development of the program.  If I were displaying certain values in the bhk* blocks incorrectly, in the viewport or otherwise, then that'd be something relevant. 

 

Any knowledge about the unknowns was likely written into the description for the field in nif.xml, which again is entirely separate from NifSkope.  If there is a description, NifSkope will display it in a popup when you hover on the field. 

 

Fallout 4's collision is entirely different.  It's an embedded binary file and thus nif.xml is not well equipped to define it and so I would have to handle the reading/writing of that entirely in NifSkope.   However, not only do the knowns/unknowns from previous collision blocks have zero bearing on the Fallout 4 format,  there is nothing unknown about the Fallout 4 collision format.  I have the embedded collision for every FO4 NIF file dumped to XML, meaning the format is more well defined than any previous collision.   The knowledge of the format (i.e. layout) is not the reason there is no FO4 collision support yet.

 

My recent builds have the option to import/export binary data that is embedded within a NIF file, so anyone wanting to edit the binary Havok file can do so. 

[KKthebeast]

Hello Mr. Jon, This latest release has been really stable (as have your last ones as well) Feel bad I can't find any bugs for you to squash. I have a few ideas or request for the list good sir.

 

-Bug? Did you have a chance to see what was up with that Glass I sent you before that was not showing Transparency in NifSkope but it was showing in game?

 

-Request, In options might it be possible to have zoom step setting? Would be really helpful for really zooming in on those vertices when manually moving groups by 0.1 so we could even more easily click on the vertex

 

-Wireframe View Mode (might be possible to select buried vertices with mouse "through" the mesh?)

 

-Ability to delete a BSConnectPoint::Parent member of the array. Don't know if i said that correctly. But 90% of the time is manually copying and pasting over points that are no longer needed which scrambles the list (if there was a way to ctrl up or down to reorder them THAT would be stupid awesome )

 

Sorry to make such specific requests. I know you prefer bugs. These are just a few things that would really increase productivity. Thanks as always for listening to us users and being interactive. It is a privilege to get to speak with you sir.

[Jon]

Bug reports are more important, but I definitely don't prefer them    I didn't look at it yet, no.  Since it was completely white I feel like it's more likely a path issue than a rendering one.  But I will actually try to look at it soon, since I'm going to have to be more active this month anyway (Skyrim SE).

 

Suggestions/requests are always welcome.  Yours are rather good as far as requests go.

 

Although the BSConnectPoint thing can't be that specific.  It'd be more generic, the ability to delete any member of an array.  Though there are some problems with doing this easily and safely, and I'd have to blacklist some array types (e.g. Vertices) where order is extremely important/reliant on other data.  The same goes with reordering.  Reordering and deleting inside of the current UI setup for arrays could be difficult.  I'd almost rather have a separate widget for this type of array manipulation.

 

Wireframe is something I've always wanted to do, plus wireframe+solid, meaning everything has a wire on top of it, not just the currently selected shape.  This would be good for seeing the topology of an entire mesh right upon open.

 

Zoom step is certainly doable.  Move/rot are configurable, but the zoom increment is currently hardcoded. 

[KKthebeast]

Yes yes! You're revisions are even better! So where do i download these changes? lmfao just kidding...but seriously . Hope you get some inspiration to look in to them for sure Thanks as always for listening sir.

[TrickyVein]

 

Fallout 4's collision is entirely different.  It's an embedded binary file and thus nif.xml is not well equipped to define it and so I would have to handle the reading/writing of that entirely in NifSkope.   However, not only do the knowns/unknowns from previous collision blocks have zero bearing on the Fallout 4 format,  there is nothing unknown about the Fallout 4 collision format.  I have the embedded collision for every FO4 NIF file dumped to XML, meaning the format is more well defined than any previous collision.   The knowledge of the format (i.e. layout) is not the reason there is no FO4 collision support yet.

 

That's very promising, if you are implying that there would be support for viewing and manipulating Fallout 4 collision at some point within NifSkope.

 

Also, completely unrelated, ousnius mentioned that he really needs to get in contact with you. 

[jsnider193]

Not sure if issue with NifSkope .. but when set up a glow efect in FO4 and then go back to nifskope the entire item glows with the color using.  The effect works in the game as should (parts want to glow do glow and not others) but when work with in nif entire mesh is orange/purple etc.  Probably related to the bgsm being used in FO4 as when edit that to turn off the bgsm and use the textures direct, the mesh shows as it should.

 

Just info and if already known .. missed it being reported.  As indicated it is not a big deal as easy work around in Nifskope for it

[Jon]

Are you using the 2016-09-15 build at the top of this page?  The issue you describe sounds like something I fixed a while back. 

[kingtobbe]

Have similar issues that some people have reported above with textures not showing up (just shows up white). This only occurs when I save with the Intel plugin in Photoshop though. Doesn't matter what compression I use either. If I save with any other application (ie. Paint.NET or Nvidia plug-in) it works fine. To make matters further complicated, the textures Nifskope doesn't show works fine in Outfit Studio and in-game. I've had the same problem with the all Nifskope builds, even including the "nightly" builds posted here and the latest one on Github.

 

Have deleted the Niftools regkey, but haven't been able to solve the issue. Going to reinstall Windows today  so will report back if something changed.

Here is a hardware summary also: http://i.imgur.com/I3F5KmZ.png

Discussed it with Ousnius on Nexus:
https://forums.nexusmods.com/index.php?/topic/3475760-material-editor/page-16

 

EDIT: Typos. Was on my phone.

Edited October 11, 2016 by kingtobbe

[Jon]

The Intel plugin saves them all in a DX11 header format which I don't think I support at all.  Depending on what Skyrim SE was going to have in terms of texture headers would have decided if I was going to support DX11 header format sooner, but it's looking like the DDS files will still use a DX9 header.

 

The Intel plugin has been out long enough now that I do need to support the files it outputs but I'd probably have to switch to a new texture loading library to do it. (NifSkope predates DX11 by many years)

[InsanePlumber]

I use these settings and I've never had problems with textures in the game (FO4) or NifSkope.

 

[Jon]

Yeah, I definitely don't support BC7 though, so they may exporting everything of theirs as BC7.   I will eventually get around to BC7 support, but there are no vanilla FO4 files that even use it so I didn't prioritize it very highly.

[Arthmoor]

Off topic, I know, but what was all the hoopla over BC7 about if none of Fallout 4's vanilla files even use it?

[TrickyVein]

Would it be possible to enable highlighting of selected SubShapes which employ different materials that are within the collision object?
 

 
It's possible to select/have highlighted the entire collision object, but distinct subshapes which use different materials from each other, as shown in the pic are not visible within the collision object. It's not critical, but this visual may help to work around trying to preserve material assignments when exporting collision. 

[KKthebeast]

Hey there Jon, I did find a "bug" depends on your perspective. If you delete an item that is on a NiNodes Extra Data List. it's entry does not get "removed" from the Extra data list, just nulled. As you know any null entry on the Extra Data List will Insta-CTD the game. At least it does in FO4

 

One way to look at it is... Well that's your responsibility to know what you are deleting and remove the appropriate entries.

 

2nd way. Lets make sure noobs don't break things lol

 

Maybe if you get a chance you might be able to work your magic here. seems like it might be a complicated fix though. like how could you even program it simply to be "Aware" of its parent and fully remove it? seems hard.

 

Anywho. Just thought I would bring it to your attention. I frequently am revisiting old nifs that i have already done snaps on and copy and pasting new ones. Sometimes i forget to manually adjust the list to remove the nulls, and end up CTD FO4. Not a problem for me now that i know what happens. but others might not be so lucky

 

Thanks for your ear my friend!

 

Removed Snap points. Extra null entry on Extra Data List. Insta CTD in FO4

[Jon]

That is always cleaned up if you have Auto-Sanitization on Save turned on, which I have re-enabled for FO4 in more recent builds.   Barring auto-sanitization you can always run the spell for it under Sanitize.   I'm not going to do auto-sanitization after every user edit, so if you want it done for you you need to have Auto Sanitize on Save turned on.

 

I also removed the spell from Auto Sanitize which could sometimes reorder blocks as this could cause a lot of problems.  If you need to reorder blocks it will no longer do so for you, but you can still run the spell for it.

[jsnider193]

thought was using latest will reload it and see what happens .. thanx for reminder on that.

 

edit:  loaded latest and still have the glow shade on the entire model ... disable bgsm and it goes away, so still no big deal as easy to work around.  Also might be the models as converting meshes from FO3 days to work in FO4 so could be some hidden wrinkle caused by the conversion.

[kingtobbe]

Yeah, I definitely don't support BC7 though, so they may exporting everything of theirs as BC7.   I will eventually get around to BC7 support, but there are no vanilla FO4 files that even use it so I didn't prioritize it very highly.

 

 

Sorry for the lateness of my reply.  I have tried all kinds of compressions which is why I'm somewhat stumped when people say it works great for them. Totally see your reasoning though and it's good to have some confirmation. Perhaps the DX11 header stays even if I save the file in different compression (ie BC1), pretty sure I haven't (not sure but with sound trancoding is generally a bad idea and thus I have treated dds files the same) but will try som PSD->DDS and see if I can get to the bottom of why I have these problems. Thanks for the answer thus far!

 

Edit: Here is a texture if you want to take a look. It's saved as BC1: https://1drv.ms/u/s!Ai4z0jNsozEnpLYfP5kdAfA4yJulUQ

 

It uses the mesh PiperCapM.nif

 

Edit2:

 

Tried with some textures and they all work as expected when using BC1. Not sure why I've had problems before, perhaps I have resaved textures and thus not updating the header if that is how the Intel plugin works. Anyways, mystery solved I suppose thanks for all the help everyone!

[tim-timman]

Hi Jon,

 

Thanks for continuing to improve NifSkope the way you are. It's a tool I've been using very extensively and with the previous version, your experimental 08-08 build, I never encountered any issues.

 

I just now fetched the 09-15 version but immediately encountered this "bug".

I can no longer have multiple NifSkope's open at the same time, which is a major drawback for me and very disrupting to my work-flow of having multiple instances with different files open. I don't know if there's a setting anywhere to fix this (I haven't found one) and since there isn't a "solution explorer" in the program as of yet, this for me seems like a bug.

 

I get no error messages when trying to open another .nif or the program itself. Nothing happens, not even a shift of focus.

 

Thank you for all you do!

[Jon]

This is likely some change in your OS between your use of the two versions.  I made exactly one commit between the two builds and it couldn't cause this.   Also I can open multiple versions of that build just fine. 

 

What you should do is extract the 08-08 build to another folder,  then double click the exe and then double click the exe again and see if you get two instances.  Make sure that you actually check as they appear directly on top of each other.   I'm guessing the 08-08 version is no longer going to open multiple instances for you either, and this has something to do with your firewall settings, as the request to open up multiple instances after one is already open is done over a local port.