search

niftools / nifxml

A repository for the nif.xml file, which contains the nif file format description.
http://www.niftools.org
GNU General Public License v3.0
37 stars 43 forks source link

Add LEGO Universe version #84

Closed luxaritas closed 1 year ago

luxaritas commented 3 years ago

LU-Reference-NIFs.zip A few folks I've been working with have looked into this, and are not aware of any user version or extensions. Once this is merged, I plan on submitting some patches to the Blender plugin.

neomonkeus commented 3 years ago

Can you supply some reference nifs.

Also in regard your other comment not related to this repo, it won't have the desired effect as this version of the nif.xml is not used by that tool, it requires a large dependency update.

luxaritas commented 3 years ago

Sure! I've put a few on GDrive, lmk if you prefer something else. I'd love to get this game added to the plugin "properly" (vs my current ugly hack), if there's anything I can do to help make that happen let me know!

neomonkeus commented 3 years ago

I was talking to @HENDRIX-ZT2 about this, apart from adding the version, this change doesn't do anything functional that would warrant merging. Normally we would expect to see new blocks being added or existing ones edited to accommodate version specific differences.

Do you have a use case which this has helped resolve an issue?

luxaritas commented 3 years ago

The intent here was mostly for modifications to the Blender plugin. In addition to wanting to have this as a valid option for imports/exports (vs having to select Warhammer or such), there were a couple changes which I made on a branch in my fork specific to LU nifs, namely overrides to the textprop flags and texture count (the texture count was already hardcoded, it's possible that there is something else mishandling the flags). I also had a change in there for conditionally adding block properties, but my understanding is that's a general bug in the plugin not specific to LU.

Some additional things on our todo list is importing and exporting with the correct orientation (LU is Y-up, Z-forward), changing default material settings (back color, white alpha), and supporting KF export (though I can't remember if there's anything LU-specific there)

luxaritas commented 2 years ago

@neomonkeus Wanted to check in about this. You had made a couple comments on my fork which I had responded to but hadn't heard back since (and I had completely forgot I had this pending honestly!)

Candoran2 commented 2 years ago

Just looking through this, you seem to have V20_3_0_9 defined twice in the versions list. Would it not make more sense to add LEGO Universe as one of the games for the already existing V20_3_0_9 like so:?

<version id="V20_3_0_9" num="20.3.0.9" user="0 0x10000" ext="nft item">{{Bully SE}}, {{LEGO Universe}}, Warhammer, Lazeska, Howling Sword, Ragnarok Online 2, Divinity 2 (0x10000)</version>
luxaritas commented 2 years ago

@Candoran2 As far as I know, the extra parameters (user/ext) don't apply (could be wrong, but I haven't seen any discussions of those being relevant from the folks I've talked with who've investigated it).

Candoran2 commented 2 years ago

@Candoran2 As far as I know, the extra parameters (user/ext) don't apply (could be wrong, but I haven't seen any discussions of those being relevant from the folks I've talked with who've investigated it).

Whilst they may not be relevant for LEGO, user="0 0x10000 means that user version can be 0 or 0x10000 - it's 0 by default, so your lego nifs would be covered under that. Likewise ext="nft item" simply means that the extension can be .nft or .item in addition to .nif. This means that LEGO nifs would fall under the existing V20_3_0_9.

Maybe it's possible to separate 0 from 0x10000, but I don't know enough about the other games to do so. And even then, it would only be possible to separate based on user, not based on ext.

If LEGO nifs are, for some reason, differently formatted whilst having the same version numbers as the other nifs, then that might be resolved differently (either with extra conditions, adding a new verattr or something else). If that does happen to be the case, I'd love to know.

luxaritas commented 2 years ago

Ah! Ok. AFAIK there's nothing special going on in the user version and I haven't encountered any situations with any other file types. I'm happy to adjust since AFAIK it shouldn't cause any downstream issues to be more permissive.

If LEGO nifs are, for some reason, differently formatted whilst having the same version numbers as the other nifs, then that might be resolved differently (either with extra conditions, adding a new verattr or something else). If that does happen to be the case, I'd love to know.

See my blender niftools fork (also linked above) for the changes I had to make to get everything working properly. I imagine the only thing that's actually relevant is nitextureprop having different (default?) flags and texture count on export. Neither of those seem relevant here

Candoran2 commented 2 years ago

Ah! Ok. AFAIK there's nothing special going on in the user version and I haven't encountered any situations with any other file types. I'm happy to adjust since AFAIK it shouldn't cause any downstream issues to be more permissive.

If LEGO nifs are, for some reason, differently formatted whilst having the same version numbers as the other nifs, then that might be resolved differently (either with extra conditions, adding a new verattr or something else). If that does happen to be the case, I'd love to know.

See my blender niftools fork (also linked above) for the changes I had to make to get everything working properly. I imagine the only thing that's actually relevant is nitextureprop having different (default?) flags and texture count on export. Neither of those seem relevant here

Cool. I'd implement the flags change a bit differently than you have there (there is only one place I can find which calls the function, which uses explicit flags=0x0001, i.e. same as the default, so I'd change that instead), but that's a discussing for a PR on the addon instead.

I should note that, as neomonkeus mentioned, the nif.xml used by the addon is not this one, but a much older one, so changes to this won't be reflected in the addon. We are in the process of doing an overhaul of the underlying library so that it can use the newest xml, but it's slow goings.

luxaritas commented 2 years ago

Made the change. If it really shouldn't have the user/ext item, I assume the direction to go would be an ID like V20_3_0_9__LU, but this should work fine.

I should note that, as neomonkeus mentioned, the nif.xml used by the addon is not this one, but a much older one, so changes to this won't be reflected in the addon. We are in the process of doing an overhaul of the underlying library so that it can use the newest xml, but it's slow goings.

Sure. I'll keep an eye on the addon and look into PRing the relevant changes once it's actually there. If there's any help a relative newbie to the ecosystem can provide, let me know and I'll see what I can do. :)

Candoran2 commented 2 years ago

Made the change. Sure. I'll keep an eye on the addon and look into PRing the relevant changes once it's actually there. If there's any help a relative newbie to the ecosystem can provide, let me know and I'll see what I can do. :)

Neat. The updated library is actually in a workable state, and I've crudely ported the existing pyffi non-generated code, so the next step would probably be to try to change the addon to use the new library, and then see what breaks. If you have discord, it's probably easier to communicate via the NifMania server: https://discord.gg/JjHKVNc