25 réponses à ce sujet

[Jedijax]

Hey there! Me again, with more questions, cause what would the forums be without me asking silly questions!

 

First off, has anyone fixed that tile in City Interior, the one with a tavern entrance (or exit)? You know, the one that has a single lantern lighting up? Tin01_something something. I think Zwerk's rework of the tileset didn't fix it, and I went into 3DSMAX to see what was going on, but thing doesn't even have emitters, I think...

 

Second, Is it me or have the gnoll models always had their shadows broken? I thought it was the custom "dangling mane" ones which broke the model, but after removing them from override, I think the original one has broken shadows as well. Hope someone can confirm or deny this. The weird thing is they appear fine on the toolset, no errors, but in-game, I see it.

 

Finally... I don't remember what the last question was... -______-   mmm... Oh yes! Can someone tell me what the "Build Module" option in the toolset does? I looked it up to no success. I am guessing it has to do with updating resources in areas and palettes, but would much rather ask.

 

Thanks in advance to one and all who can help!

[Proleric]

 ...Can someone tell me what the "Build Module" option in the toolset does?

The most common use is to recompile all scripts; for example, to ensure they're all using the same version of an included function when it's changed.

You'll see lots of other options, such as checking for unused and missing resources, or doing refreshes and recalculations. These tend to be used when tidying up, just before releasing the module.

Not sure about your other questions.

[Shadooow]

Hey there! Me again, with more questions, cause what would the forums be without me asking silly questions!

 

First off, has anyone fixed that tile in City Interior, the one with a tavern entrance (or exit)? You know, the one that has a single lantern lighting up? Tin01_something something. I think Zwerk's rework of the tileset didn't fix it, and I went into 3DSMAX to see what was going on, but thing doesn't even have emitters, I think...

 

Thanks in advance to one and all who can help!

I cant say for certain because you dont know tile name, but you can try ma unofficial patch, I fixed few tiles from TNI there. Or just download the modified tileset files package from the project page (link in my sig) and put it into override if you dont want my patch.

[Jedijax]

Thanks for the help, guys! I am checking up the tileset package asap! Hope more developers can share their insight on these!

[Zwerkules]

Hey there! Me again, with more questions, cause what would the forums be without me asking silly questions!

 

First off, has anyone fixed that tile in City Interior, the one with a tavern entrance (or exit)? You know, the one that has a single lantern lighting up? Tin01_something something. I think Zwerk's rework of the tileset didn't fix it, and I went into 3DSMAX to see what was going on, but thing doesn't even have emitters, I think...

 

 

I'm sure I didn't fix it because I never saw it. I did fix a number of tiles with candles on them which didn't work properly, but never a lantern.

[Jedijax]

Hey Joern! Actually, of course, your haks were the very first I went to when I noticed this. You see, what I don't get is there is no emitter in either lanterns, yet one lights up and the other doesn't. I tried various things unsuccessfully. I even went and copied the entire other lamp to see if it would fix it. I tried to upload an image of the tile in-game for better id, but this site won't let me upload any of them.

[Jedijax]

Oh, and now we can't edit or remove our own posts! This gets better and better doesn't it? Here is the link to the pic: http://prntscr.com/3rtn4e

[Zwerkules]

If you open your area in the toolset and place the mouse over that tile you should see the name of the tile at the bottom of the toolset window. Knowing the name of the tile will make it easier to check out what's wrong with it. From the look of the screenshot I'd say that one lamp has a self illumination that is almost white and the other ones is still black. This is strange though because I haven't seen Bioware use selfillum much, whereas it is used alot in the DLA tilesets.

 

Edit: The tile is o13_01 and it is as I thought. Box1524 has a selfillum of 1.0 1.0 1.0 while Box1522 has a selfillum of 0.0 0.0 0.0.

Change that to 1.0 1.0 1.0 and you'll have the second lamp behave just like the first.

[Pstemarie]

Added these fixes to Q - both tiles tcn01_o13_01 and tni01_o13_01 have this issue.

[MannyJabrielle]

If you open your area in the toolset and place the mouse over that tile you should see the name of the tile at the bottom of the toolset window.

OOooooooh! I never noticed that before!  That makes it SO much easier to find specific tiles rather than going through each one in explorer!

[Jedijax]

I have already applied the change, but haven't checked it yet! Thanks for the solution, Zwerk! Your instructions were very clear!

 

It's also great you included them in the Q tilesets, Paul! It's great everyone can benefit from it! By the way, I've been looking at what you're doing with the tilesets, and it is amazing. I just wish modules wee using it. Is there a list of projects using Q? I think only PW's do nowadays, and unfortunately, I don't do PWs.

 

Finally, one new question! Does anyone know if the Gestalt camera thingie can be used as an override to the default camera zoom during conversation? Or can this option be modified to one's desire? I rather like how the camera pans and zooms-in during conversations in NWN2 and it seems to be a hardcoded thing, rather than something you have to manually add to every piece of dialogue. I was wondering if the same could be achieved via ini in the original NWN, or via some override using the gestalt camera modes.

[Jedijax]

Aaaand one more question, cause, why not?! See, in other games changes and modifications to "modules" take immediate effect. As we all know, such is not the case in good NWN (boo....) BUT... I seem to remember there was some way to actually hack your way into a module while keeping variables set or some other technical thingama, effectively using a character from where you left, but into the altered module. I believe it involved LETO and demon summoning of some kind, or something. If anyone can share or shed some light, please do so!

[Zwerkules]

The save files are a kind of module themselves, if you have a program that can edit them you can make changes that aren't just affecting your PC but also areas etc.

[MannyJabrielle]

I have already applied the change, but haven't checked it yet! Thanks for the solution, Zwerk! Your instructions were very clear!

 

It's also great you included them in the Q tilesets, Paul! It's great everyone can benefit from it! By the way, I've been looking at what you're doing with the tilesets, and it is amazing. I just wish modules wee using it. Is there a list of projects using Q? I think only PW's do nowadays, and unfortunately, I don't do PWs.

 

Finally, one new question! Does anyone know if the Gestalt camera thingie can be used as an override to the default camera zoom during conversation? Or can this option be modified to one's desire? I rather like how the camera pans and zooms-in during conversations in NWN2 and it seems to be a hardcoded thing, rather than something you have to manually add to every piece of dialogue. I was wondering if the same could be achieved via ini in the original NWN, or via some override using the gestalt camera modes.

 

I know you can turn *off* camera zooming for conversations, but I'm not sure if the actual zoom can be edited.  Gestalt's camera mod is a scripting package, and all the variables such as how close to zoom in, ect, are done through scripts  You could turn off zooming in the options, and attach a custom gestalt run zoom to every conversation, but that would be incredibly work intensive, especially if you don't want to muck up any conversations that already have a script attached to the initial node in the conversation tree.

As for SP projects using Q, I'm working on one.... however it'll be a long while still before it's ready for release.

 

However, for a decent portion of Q content, you can get it to show up in already made modules to a certain extent via hak-patching.

To do this, open your nwn.ini file in notepad, and find the line that says "PATCH=.\patch", and change it to "PATCH=.\hak".  Save, and close.  Then open the file "nwnpatch.ini" and have it read as follows:

 

[Patch]
PatchFile000=q_vfxgui
PatchFile001=q_tilesets
PatchFile002=q_sounds
PatchFile003=q_robe
PatchFile004=q_race
PatchFile005=q_portraits
PatchFile006=q_placeables
PatchFile007=q_items
PatchFile008=q_creatures
PatchFile009=q_2da
PatchFile010=q_!tilesets
PatchFile011=q_!tilereskins
PatchFile012=q_!fightingsfx

Save, and close.  Then, when you play NWN, Q content will be loaded in like normal game assets.

 

There are some pros and cons to this method however, due to how hakpatching figures into asset loading orders.

 

Pros.... you can access Q content such as armor and weapon appearances, character heads, ect, all without having to actually add the Q haks to each and every module.

 

Cons.... the Q content will be overriden by module content, so if a single player module you choose to play already employs it's own haks that happen to have it's own 2DAs, the game will use those instead of the Q ones.  The only way around this is to merge the Q 2da's with the module's 2das.  This is because of how hakpatch content is loaded.... which is after base game assets, but before a module's hakpak's assets.  The last asset to be loaded takes priority over assets with the same filename loaded earlier.

 

And another con.... ALL modules will have access to this content as well as the toolset, so if you BUILD a module with your game patch-haked like this, it will reference the content without the actual hak's, and will not necessarily work right for others who play your module without their client hak-patched as well.

 

However.... to solve this... simply rename your nwnpatch.ini when you decide to build in the toolset.

 

And a note on the patchfile list I gave... I did not include the !q_armoury hak in the list because I found it doesn't play nice with non-Q modules... for example, with the NWN OC, rings and amulets all had the same generic appearance since the armory hak changes them to a parts-based system rather than a single static icon format.  I also included the optional !q_tilesets hak and the q_tilesets base hak.... I can't recall what is in those specifically, but there's really no harm in adding them as far as I can tell.  The !q_tilereskins could be removed too if you would rather the original NWN dungeon and crypt textures.  Just be sure that if you remove any haks from the list, that you renumber the entire list properly.

 

And yes, this was a long and rambling explanation, but I'm confident someone else can give a more accurate and less babble-filled explanation of hakpatching should you need it (forgive me... it's past midnight, and my brain has been fried and refried several times tonight... be thankful I'm not typing in complete babble and riddles!)

[Jedijax]

Thanks for the instructions! I know the Gestalt being added line by line in conversation is insane, which is why I wondered if there was a way to stream-line it, as an override. I thought it could somehow plugged into the vanilla zoom-in during convo option, or there was some setting to modify the values of that one. As for the Patch-ing of haks, one day I may do so, but as you have explained there are quite a bit of concerns for now, especially the overriding of resources, which is why I mainly rely on personal haks and override folder! Thanks for the input, and let's hope someone comes up with a viable solution for the instant area changes (sort of) and the zoom-in thingies!

[MannyJabrielle]

Well, I might be wrong on the order, but I do believe that contents of your override folder override both base game assets and hakpatched assets.

Essentially, the load order is (where applicable) 1st, base game assets, the unmodified game (or the game with the community patch), then hakpatch assets, then attached haks, then override folder assets...

The loading order varies slightly with script files (nss and ncs), but I forget exactly how they figure in with the load order.  But essentially.... yeah, it's hak-patching is just like using the override folder, but is somewhat "cleaner" in that assets are all neatly packed into haks.  The biggest of the cons comes when you go into the toolset as I don't think override contents are loaded with the toolset.... but as mentioned, it's easy as could be to just rename the nwnpatch.ini file when you go to build to ensure you don't use any extra, non-replacing Q assets in your module.

[Zwerkules]

Well, I might be wrong on the order, but I do believe that contents of your override folder override both base game assets and hakpatched assets.
 

Haks have a higher priority than the override folder. If this wasn't the case everybody could change walkmeshes etc client side and do what they want in PWs.

 

Edit: Sorry, you said hakpatched, not hakpacks, so you are right. If you have a patch-hak the override folder contents will overwrite stuff in the patch-hak.

[Shadooow]

Haks have a higher priority than the override folder. If this wasn't the case everybody could change walkmeshes etc client side and do what they want in PWs.

fortunately this stuff is sent to client in multiplayer and is not loaded from client files otherwise client would only have to modify his hak files to exploit that

[Bannor Bloodfist]

Actually, the last 3 posts are all actually only partially correct.

 

file override order is handled differently by file type for one thing and is overwritten by ANY hak in the load order.

 

anyway this statement is wrong:  "Essentially, the load order is (where applicable) 1st, base game assets, the unmodified game (or the game with the community patch), then hakpatch assets, then attached haks, then override folder assets..."  As the HAK overrides the override except in one instance, which is graphic file related, where a dds no matter where in the load order, will override a tga, of course two dds or two tga of the same name do follow the corrected load order which is:

 

Base game assets, the unmodified game (or the game with the community patch), then hakpatch assets, then override folder assets, followed by attached haks, ...  IE, hak packs ALWAYS override the override folder, this was done to protect Servers. 

 

As to what content the server sends, it only checks for the existance of a hak, then assumes the content matches.  The only file(s) it actually sends to the client are .wok and scripts.  So, a client can modify anything in the attached haks, and those will display but no wok meshes are loaded client side, nor are they generated client side as is the normal case, meaning the client never loads a .wok at all, UNLESS it is sent by the server, otherwise, it re-builds the .wok on load of the tile mdl or placeable mdl, it does not read the actual .wok or .pwk file.  Try it, you will see what I mean, delete all .wok files from your haks, the tilesets will all still work as designed, using the built-in wok data of each tile .mdl file.  UNLESS you are loading it via server, then whatever the server sends the client for the wok will be what is used.  Graphics wise, the server mdl will still get overwritten by the client mdl, but the WOK will be protected.  Meaning, you can change the local look of any tile that you want, the server doesn't care, but you can't add new doorways etc as the server side WOK file takes priority.

 

A dds file anywhere it is listed in load order will ALWAYS override a .tga file.  Sorry, this is just the way the engine works.  So, if your computer can display a .DDS texture, and there is a dds named the same as ANY tga, the DDS will always take priority.

 

Basically, there is not a simple override order.  It all got jumbled up and mixed up when server admins complained about end users/players creating modified local files... The files they truly needed to protect were wok/walkmeshes and any/all scripts which are run directly from the server, NOT the client.  Otherwise, client can override the LOOKS of anything, regardless of server side content.  So, if a server admin decides that their server will NOT allow adult content, they can do so, yet the clients can use any adult overrides they wish and the display will work for the client.  (adult just mentioned to show the limitations and to be more easily understood), so the play can have nude folks running around, yet OTHER players and the server are NOT affected.

 

as to hak vs override, well the 'override' folder doesn't override anything except local bif content.  IE the override will take control of any base/update content but override will NOT take over for ANY hak content that is loaded.  IE the hak always wins, again except in dds vs tga relationship.

 

Also the toolset WILL use 'override' at load time, UNLESS the module also has a .hak with content that is named the same, then the HAK again overrides the override.

[Jedijax]

Yup exactly what he said! And that's why I haven't gone the patch way yet. Too much to take into consideration, and I don't even do multiplayer or pw's at all. I do believe override to patch is a great idea though! Only issue with that is I am constantly changing override files, which would be some steps longer!

[Proleric]

Can someone explain the term "hakpatch"? Google was not much help.

[MannyJabrielle]

Can someone explain the term "hakpatch"? Google was not much help.

Not sure if that's what it's officially called or what not, that's just what I call it.  It's where you can place haks into the "patch" folder in your NWN root directory (or modify your nwn.ini to use the hak folder instead of the patch folder), and then modify the nwnpatch.ini file to use those haks.  They're loaded after base game assets but before everything else, so it's very much like using the override folder.

It's the same method used in Zwerkle's NWN Facelift Haks @ http://neverwinterva...s-facelift-haks

[Jedijax]

One more question, guys! Does anyone know if there are high quality pelvis models other than Xaltar's? I've been trying to find some with more polygons to use as standard for all normal pelvises, but I only found two packs and they're both incompatible with other body parts. Also, if anyone has the demo for OldTimeRadio's robes as base models, please re-upload it, cause the link to the original one is kaput!

[Jedijax]

Guys, is there a way to use the HOTU and SOU henchmen system in the original campaign? Has anyone already tackled it? Been searching for a mod or info on how to do so to no avail. I would also like to have more than just one of the original henchmen. Hope someone can help!

[Michael DarkAngel]

Have you tried/looked at this -->> OHS Henchman System

 

 MDA