59 réponses à ce sujet

[Sir Roderick]

So far verified the cloak issue. its caused by a_ba.mdl which I got from here. Project Q uses the same one with more customizations, Looks like this fix brings more troubles than benefits :/. Its not my fix so the only solution is to remove this file from my patch. Maybe Pstemarie or OTR wil be able to fix this.

 

Good. Now we're getting somewhere.

 

I guess removing the modified file entirely is better that what we have now, and best of all would be if someone who knows this stuff really well, like OTR or Pstemarie, could make a version that fixes the present bug but also incorporates whatever other fixes or changes were supposed to be added into it.

 

 

As for heads. I see the mentioned heads low res whether I have CPP on or off.

 

How did you switch the CPP off? Earlier in this thread we said that it can be switched off by reverting to the unmodified backup of xp2patch.key, but that's not entirely accurate. When we're dealing with textures, we also have to restore the unmodified backup of xp2_gui.erf in the texturepacks folder.

[Shadooow]

How did you switch the CPP off? Earlier in this thread we said that it can be switched off by reverting to the unmodified backup of xp2patch.key, but that's not entirely accurate. When we're dealing with textures, we also have to restore the unmodified backup of xp2_gui.erf in the texturepacks folder.

Indeed. I didnt restored xp2_gui.erf as I dont have a backup at all. Im not aware I would have anything head related here though, afair there is only a barkskin texture, but maybe im wrong.

[Gruftlord]

Get nwn explorer reborn, it is awesome if you want to have a look at what is in which file. Afaik there are a few things more in the erf than the barkskin.

[Sir Roderick]

All your head plts are there (as well as in patch171.bif). The unmodified xp2_gui.erf contains no plt files. For testing purposes, you can just move the modified file out of the folder without restoring the original.

[Sir Roderick]

Get nwn explorer reborn, it is awesome if you want to have a look at what is in which file.

 

Certainly, in case you don't already have this program, get it. Besides being awesome it's also the most convenient way to browse through all the plt files (as well as all other unmodified and modified game files).

[Sir Roderick]

Since Shadooow doesn't have an unmodified version of xp2_gui.erf, I uploaded it:
http://s000.tinyuplo...779353437587941

Naturally this should be included in CPP's uninstall packs from now on.

It should also be uploaded to the Vault's texture pack collection:
http://neverwinterva...n-texture-packs
Currently the description there says that they're looking for this particular file. The post is by Henesua, so, Henesua, if you're reading this, feel free to update the texture pack collection on the Vault with this file.

[Shadooow]

Since Shadooow doesn't have an unmodified version of xp2_gui.erf, I uploaded it:
http://s000.tinyuplo...779353437587941

Naturally this should be included in CPP's uninstall packs from now on.

It should also be uploaded to the Vault's texture pack collection:
http://neverwinterva...n-texture-packs
Currently the description there says that they're looking for this particular file. The post is by Henesua, so, Henesua, if you're reading this, feel free to update the texture pack collection on the Vault with this file.

thanks

 

EDIT: human 143head still lowres (this head is not in texture packs in high res version at all), dwarven female heads are ok so its really CPP bug

 

EDIT2: you are absolutely right, PLT are the textures for the heads, not just colorization scheme as I claimed and they do have high res/ low res, damn Im off NWN for too long I guess sorry for false informations

[Malagant]

I generally answer this about once a year but, if the head "issue" for 50-63 hasn't been explained, it is no fault of the CPP:

The issue you are seeing with 50-63 comes from Biowares unused test helms that exist in the games core data for those slots. They are unfinished and essentially leftover files after Bioware decided to go a different route, therefore were never intended to be legitimate. Their presence causes minor issues. There is not direct work around other than overwriting those "head" models with replacements, but there are issues you need to be aware of when doing so to get the results you're looking for.

The issues you need to be aware of can be found here.

 

I do not recall if Project Q utilized the 50-99 slots (only available for character generation as I describe in that thread) because I do not currently have the game files installed while I do some movie encoding. Replacement heads need to be both in an attached hak (for the server / game) and must be in the override folder for character generation, after which they can be removed. The override also goes for NWNExplorer, as the viewer will grab the texture for those head models from the core files if those textures / plts are not in the override, which is why you aren't seing them there properly.

[Sir Roderick]

Thanks for the info, Malagant. That answers a few baffling questions.

The game data contains those unused test helmet models in human male head slots 50-81 and it contains helmet plts in slots 50-88. That means that human male heads 50-81 show up as helmets and 82-88 are headless. None of this ever shows up ingame in an unmodified game.

Project Q does not use slots 50-99 at all. CEP has heads in slots 50-63. What's happening in CPP's head slots 50-63 is that CPP has, by accident, taken head plts 50-63 from CEP, but it hasn't taken the head mdls, and that's why we get CEP head textures projected over Bioware test helmet shapes.

These grotesque heads aren't available at character creation if the game is not modified by anything except CPP. But other modifications will make them show up. Using a character customizer that modifies the crafting conversation will make them available. They also become available at character creation if something else, such as Project Q, fills up the missing slots 35-49 between the original heads and the test helmets.

Probably Shadooow has fixed this already by deleting those plts from his bif and erf.

Anyway, Malagant's information also clarifies that we can all replace the Bioware test helmets by putting our own custom heads in slots 50-99 with no bad consequences, since those helmets aren't used ingame by Bioware, and if they aren't available in the Toolset, then module builders can't have used them for NPCs either.

[Shadooow]

What's happening in CPP's head slots 50-63 is that CPP has, by accident, taken head plts 50-63 from CEP, but it hasn't taken the head mdls, and that's why we get CEP head textures projected over Bioware test helmet shapes.

 

Probably Shadooow has fixed this already by deleting those plts from his bif and erf.

Indeed thats whats happening, the head PLTs I have are from a source that included CEP heads as it seems and I wasnt aware of that.

 

I will remove them, but that will be in next 1.72 beta, I dont think this problem is that significal to fix retrospectively and reupload new 1.71 version.

[Sir Roderick]

I will remove them, but that will be in next 1.72 beta, I dont think this problem is that significal to fix retrospectively and reupload new 1.71 version.

 

Yeah. That's perfect.

 

 

EDIT: human 143head still lowres (this head is not in texture packs in high res version at all)

 

Yeah. I'd say this is a bug by Bioware (or Floodgate Entertainment, which made Shadows of Undrentide with Bioware). Probably they just forgot to include a good-resolution version of the desert man's head or got their plt's mixed up. So in my game I've got Yavel's reskin (or more specifically the Realms of Mythology version of Yavel's reskin, links are in my second post). And we can all get that if we want this head to look better. Of course I was kind of trying to suggest that wouldn't it be nice if this reskin was included in CPP and/or Project Q? If you'd need the author's permission, reaching him would probably be impossible (Yavel? Who is he and where is he? The reskin is dated 2003.), if just crediting him is not enough. And there's also the issue of whether this reskin meets the quality standards of CPP or Project Q: it's absolutely better than the original, but the eye positions on the plt and mdl don't match quite perfectly, they're just a little bit off.

 

 

EDIT2: you are absolutely right, PLT are the textures for the heads, not just colorization scheme as I claimed and they do have high res/ low res, damn Im off NWN for too long I guess sorry for false informations

 

No problem Shadooow. You're doing good work fixing things, and the patch will be better than ever.

Project Q hasn't caught up quite as fast. Not that I'm expecting them to fix the cloak issue very quickly: Pstemarie has retired from the project and The Amethyst Dragon is busy moving. And that's perfectly all right, real life is more important than this game. They can get back to this in due time, maybe months later, and that's fine.

But since Pstemarie stopped by to deny the cloak issue is caused by Project Q, I'll just say that he's wrong there. But since he's the expert with those files, people may tend to believe him even when he's wrong. That's why I've tried to encourage others to test the cloak issue in Project Q too, so we'd have more than just my word against his. Testing it is easy and quick: take a cloaked male dwarf / half-orc / gnome into the Q starter module and observe whether the cloak moves like cloth or whether it stays stiff.

[Shadooow]

I think that the reskin could be added. Its very close original and waaay better than this lowres crap we have there.

[Pstemarie]

Back to cloaks - I missed your mention of using it through patch.ini. When I tested it out I had Q attached directly to the module. Do you get the same results if the haks are attached directly to the module?

 

 

As you can see from this screenshot from my testing, the male dwarf cloak is animated correctly. Therefore, it would seem to be that preloading the animation supers through patch.ini is causing issues. I have no idea why, but this might be the reason Bioware abandoned patch.ini as the preferred method for updating the game and went to bif modifications.

 

I may still be wrong about this not being a Q issue, but without being able to replicate it, I really don't know what else to think. If I get the chance this weekend I'll run tests with the Q haks being preloaded and see what happens.

[Sir Roderick]

All right, I believe you Pstemarie, we get different results. This is very interesting.

 

Nwnpatch.ini is not the cause, I think. I wasn't using it in the test I did after your last reply. That's how I eliminated it as a possible cause.

 

If you look at the steps I followed in that test...

- I had a freshly downloaded and installed copy of the manual install package of Project Q

- I had override folder and nwnpatch.ini renamed and xp2patch.key and xp2_gui.erf restored from the originals

- I was using Q_Base_NoHorses, so the module-specific haks, Q haks, should determine how the animations work

- with the exact same setup, the cloak animations worked in the Prelude of the OC

 

That should be solid testing methodology, but I also believe what you're saying. So this is mysterious.

 

I don't suppose the animation supermodel files in the manual install package are in any way different from the ones you're using, since I'm not using the autoupdater?

[Sir Roderick]

I ran "q_update_v20.bat"... but I guess it was just the third time I installed the same version of Project Q. Poor dwarf, no change in his cloak.

So I'm ready to give up on this issue at this point. If no one else reports the same problems, then I guess the issue is somehow at my end - something here conflicts with Q's versions of a_ba, a_da, a_ba2 and a_da2, specifically. Something like... what? We've already ruled out all the usual suspects: patch-haks, overrides and the Community Patch. Frankly, there's nothing else I can think of. We did verify a similar bug in the CPP, and according to Shadooow, Project Q is using some of the same modifications in a_ba, but that by itself doesn't mean anything.

Case closed, cause unknown? Call it an X-File.

[Tarot Redhand]

Silly thought that may (or not as the case may be) help. Is it the GOG NwN diamond that you are using (I have been following this but I can't remember)? If it is, have you installed the 1.69 critical rebuild patch because without it all sorts of weird things have been known to happen in GOG NwN.

 

TR

[Pstemarie]

Silly thought that may (or not as the case may be) help. Is it the GOG NwN diamond that you are using (I have been following this but I can't remember)? If it is, have you installed the 1.69 critical rebuild patch because without it all sorts of weird things have been known to happen in GOG NwN.

 

TR

 

That was going to be my next question, as the version of Q I am testing with is the v2 download from the Vault - which also has the same files within it as those queued via the updater.  I have also checked for this issue on my son's PC and my wife's and cannot replicate it there either. I am just as baffled as to why one user would be experiencing it. 

[Sir Roderick]

Yes, it's the GOG Diamond Edition, patched first with the 1.69 Critical Rebuild, then with Community Patch 1.71 and then with the newest 1.72 betas.

I probably have backups of every modified game file, but what I don't have is a backup of the whole game in an unmodified state. I do, however, have a backup of the entire game directory that I made a day after installing the game. That day-old backup however already has the Critical Rebuild and 1.71 and a few other things. Well, I copied that old backup directory over to my main drive, installed Project Q into it and still got the cloak issue. So if I've got something in my game that conflicts with Q's supermodels, it's been there since day one. Also, if we think about what could possibly conflict with Q's supermodels, the modifications in my game are almost all in haks or the override directory, and haks and overrides are easy to switch off. The only modification which is not a hak or an override is Sawark's camera mod, which modifies nwmain.exe, so I even tested this with my backup of nwmain.exe, and of course the camera mod wasn't the culprit. About the only thing I could do to go further would be to uninstall and reinstall the entire game, and I won't go to that trouble since it would probably not change anything either, and I'm already ready to drop this whole matter. All possible explanations are just strange. What if Q's supermodels somehow conflict with my game settings or my operating system or my other software or my integrated graphics or my other hardware? I'm out of my depth and can't think of any reasonable explanation.

But if the issue hasn't showed up on other computers, it's simply not worth investigating.

[Pstemarie]

Found the issue - my bad for testing on a corrupt copy of the Q No Horse hak - my son removed the race haks from my copy. With them back in, the issue is indeed present. When I get the time I'll look into fixing it. 

[Pstemarie]

Issue is resolved - it was caused by compiling the animation models. I have the half-orc and dwarf males fixed. I'll upload it to the updater this weekend. For those that can't wait the hotfix is on the Vault. Inject the file directly into q_race.hak

 

http://neverwinterva...2015.7z&nid=308

 

Shadooow, try uncompiling the animation supers in the CPP and see if that fixes your issue.

[Sir Roderick]

Yay, good to know I wasn't hallucinating it!

 

The fix works!

 

Fat dwarves and half-orcs would probably benefit from the same fix for a_da2.mdl.

 

Good work, on this and all other aspects of Project Q.

 

By the way, since you were wondering earlier whether preloading could cause issues for Project Q, I'm happy to report that Project Q worked just fine for me throughout my OC game. I know it's originally designed so that the haks are meant to be attached to modules that use Q, but just using the haks in reverse-alphabetical order in nwnpatch.ini (with the vd_build and armoury haks excluded) makes them work perfectly in the OC (and probably many other modules that weren't designed with Q in mind).

[Pstemarie]

Yeah, I know it works with preloading - Shadooow and I kind of pioneered that approach a few years back (along with others I can't recall). I was thinking at the time that maybe something with preloading was messing up animation supers. I'll fix the other one this weekend.

[Shadooow]

Shadooow, try uncompiling the animation supers in the CPP and see if that fixes your issue.

Im not sure what you mean, but the original file from OTR is uncompiled and this file does the cloak issue itself whether compiled or not.

 

Do you maybe have a version of the vfx fix without additional modification from Q?

[Pstemarie]

Im not sure what you mean, but the original file from OTR is uncompiled and this file does the cloak issue itself whether compiled or not.

 

Do you maybe have a version of the vfx fix without additional modification from Q?

 

I was referring to the cloak animation errors that Sir Roderick was reporting were in the CPP, not any VFX. You might be able to fix the issue with cloaks in CPP by just importing the animations from the original BioWare models directly into your updated animation supers.

[Zwerkules]

Maybe that's almost enough bug reporting for one night. I'll finish with an observation regarding the Biorural facelift hak by Toro and Zwerkules.
Is that a bug or not? I mean, is that simply caused by the modified window texture being darker than the original, or is there something here, an illumination effect perhaps, that's supposed to work but doesn't? So, I can't say whether that's a bug or not. Zwerkules can decide.
 

The window texture is simply darker. If you use a torch you'll see that it gets more orange at night. If you like I can give you some files where those windows have a self illumination.