69 réponses à ce sujet

[Rolo Kipp]

<thinks twice about getting on a high horse...>

The forums here are... quirky, to say the least.
+1 to sticky

+1 The Amethyst Dragon for forum moderator!

Seriously, think about it, he's active <hyper-active>, he's sensible, he stands by his posts, he's *obviously* dedicated, and generally well-liked, if not idolized <ooh! boss! can we make a TAD idol? huh? can we?>...

Hmmm, I'll post this in a new thread tomorrow.
Needs discussing, IMONSHO.

<...and gets on a soapbox, instead>

[Pstemarie]

Slight fix needed for Q instructions (see text in bold) -

Builders:
1. Download desired version (latest recommended, of course).
2. Decompress files
- .hak files go into your NWN/hak folder
- .tlk files go into your NWN/tlk folder (if you don't have one, just add it)
3. Add Project Q to your module in the toolset (after making a backup copy)
- Open module in the toolset.
- Go to Edit > Module Properties > Custom Content
- Add latest Project Q .tlk file (projectQ.tlk)
- Add q_ hak files (use dropdown list)
- Move hak files into correct order:
- - q_!armoury.hak (optional -- enables modified inventory systems)
- - q_!fightingsfx.hak (optional -- enables modified combat sound effects)
- - q_!tilesets.hak (optional -- enables custom tilesets)
- - q_2da.hak
- - q_creatures.hak
- - q_items.hak
- - q_placeables.hak
- - q_portraits.hak
- - q_race.hak
- - q_sounds.hak
- - q_tilesets.hak
- - q_vfxgui.hak
- Click OK to begin module build.
- Save when finished.

You also might want to note that the preferred method of getting the files is through the rsync automatic updater - which places all Project Q files in the correct locations, provided that NWN is installed in the root drive (usually C:\\\\NeverwinterNights\\NWN).

Modifié par Pstemarie, 19 janvier 2012 - 02:39 .

[The Amethyst Dragon]

Pstemarie: Fixed original post. Thanks for the info.

[Pstemarie]

Anytime and thank-you for adding us to the OP.

[Lightfoot8]

Hmm, Wonder why this was unstickied,

+1 to resticky.
+1 For AD Mod.

You would think that with CEP being in the board title, they would at least leave a way to find them.

[The Amethyst Dragon]

Updated original post with new CEP forums link.

[The Amethyst Dragon]

Bump up from page 4.

[SuperFly_2000]

WoW...first now realised that CEP had a new very neatly structured site and finally neatly structured forum as well!!!

Congrats to us (the NWN community)!!!

...and yes...this thread desperately needs a sticky...

[The Amethyst Dragon]

Bump up from page 8.

[Rolo Kipp]

<trying to clean up...>

Sticky bump!

<...the honey on his warts>

[The Amethyst Dragon]

I guess it's testimony to the life of this game that in two weeks this thread had already been pushed to the middle of page 3.

[Bannor Bloodfist]

@The AMethyst Dragon;

I have started a thread and a corresponding poll to answer these types of issue, we obviously need some new moderators that actually pay attention.

Prospectcive New Community Forum Moderators

Please note that your name has so far risen to the top of the list of folks voted for

Modifié par Bannor Bloodfist, 12 juillet 2012 - 03:43 .

[Rolo Kipp]

<holding his hands out...>

I've been *saying* that forever <i must have told you a million times not to exaggerate...>
*double-take* Heh. <*raven chuckle*>

<...and pleading>

[Bannor Bloodfist]

Well, I intend to keep the Poll open until Sunday evening sometime, then create a message that has links to the poll itself, the poll thread, and the various folks accounts that have been suggested and have agreed to help us out.

So far we have 4 folks still in the running, AD, Rolo, Shia, and henesua - in that order of votes. Some of the folks that were suggested via comments have already stated they are not interested so I won't add them to a newer poll or suggest them to Bioware Super Mods. And of course some folks on the pole directly stated they were not interested either.

Anyway, intending to keep poll thread going until Sunday to give folks a full week of voting options so that I am as fair to the community as possible while also limiting the votes to folks that actually VISIT at least once per week.

[OLHLdr_StrikerB]

awesome thank you fir this

[HeavenStar]

Is it possible to build a mod with both CEP 2.4 and Project Q 1.5? I saw in Project Q document that they may not be compatible. Is there a way to work around that?

[Nissa_Red]

There is a workaround, but it's not something trivial, neither in matter of knowing how the toolset resources operate (achieving compatible 2DA files is only the tip of the iceberg/difficulties ahead, if you want to do it properly), nor in matter of time required to proceed to such an endeavor. No one has done it so far, or at least officially released anything, to my knowledge.

Honestly, unless you really had a huge amount of time ahead, you'd be better off with just picking one package, and building/adding on top of it, accordingly to your needs.

EDIT: Also let's not forget that whenever either team releases a new version of their package, the "merge" will have to be updated if it's to be an "official" one. All this really doesn't make it look... uh, very reasonable to be expected to happen anytime soon.

Modifié par Nissa_Red, 07 mars 2013 - 11:22 .

[The Amethyst Dragon]

A module can include both large hak packages, but you will need a customized "top" hak as well, which contains various 2da files that merge entries from the 2da files from both packages.

In some cases, they have lines that don't overlap.  In other cases, you'll have to move some lines around in the 2da file to get them to work.

I did the work, but my merges won't work for anyone else's module, since I rework both CEP and Project Q 2da lines around my own custom content.

It takes a bit of patience.  I make heavy use of Syrus Greycloak's NWN2daTool Excel Spreadsheet.

[painofdungeoneternal]

Nissa_Red wrote...

There is a workaround, but it's not something trivial, neither in matter of knowing how the toolset resources operate (achieving compatible 2DA files is only the tip of the iceberg/difficulties ahead, if you want to do it properly), nor in matter of time required to proceed to such an endeavor. No one has done it so far, or at least officially released anything, to my knowledge.

Honestly, unless you really had a huge amount of time ahead, you'd be better off with just picking one package, and building/adding on top of it, accordingly to your needs.

EDIT: Also let's not forget that whenever either team releases a new version of their package, the "merge" will have to be updated if it's to be an "official" one. All this really doesn't make it look... uh, very reasonable to be expected to happen anytime soon.

I plan on doing a test case with this with my merging tool, sounds like it's complex enough to stress test what I am doing, and it's only 2 packages so it won't be too confusing. Imagine what you describing beyond compatible 2da files involves migrating 2da rows, adjusting blueprints to match the moved 2da rows, and the dialog.tlk merging. I'd basically be downloading multiple projects based on a manifest, and merging like files such as 2da's and tlks automatically initially. The migration of conflicts for the same rows, or the same file which require migration is the second stage after that, the hardest part of that being where should the new rows be, so it's semi reserved so it minimizes the impact on modules and bics reliant on those rows.

Do you know of other areas of the iceberg which need to be dealt with? ( I am sure I will encounter them soon enough, but it helps to know what the mess is going to be ahead of time )

( I am not sure if there are similar issues like NWN2 has with mdb files, where you have to rename the file and have resources inside the file have matching names. )

[henesua]

Andarian also did the merge of Q and CEP for his rerelease of Sanctum of the Archmage.

[Nissa_Red]

It's probably not very reasonable to write about such a complex topic that late in the day (err, night, yes ?) for me, so you'll have to forgive me for any shortsights on my part >.<

Anyway, here goes : first, we would need to agree that we're talking about a "public" release of a merger. While it's perfectly possible to merge both packages in a way to fit the situational needs of a PW or a module builder, by customizing it and doing compromises, a "public" release entails that each and every *unique* resource of both packages remains avalaible through the merger. That's how I see it at least.

On top of my head, I can think of two types of resources that are extremely problematic : clothes (or rather bodyparts, to be accurate) and tilesets. Bodyparts don't come with a 2DAs that allow us to shift the models around like we want. Clothes, robes, helms, cloaks, even heads, wings and tails, would need to be renumbered. While renumbering would be possible for some of these resources, some others are limited to 255 (clothes and heads, for example).

Next, tilesets, even more problematic. CEP has one version of the "same" tileset (tin01, for example), Project Q another. Will such tilesets get duplicated, which wouldn't have much value to a builder and might cause issues with the maximum number of tilesets avalaible in a module sooner or later, or will they be merged too ?

Even creatures will show problematic, since the supermodelled ones can share animations, some phenotypes will come with robes and others not, etc.

Finally, what about duplicates ? Let's ignore for a moment the difficulty to identify true duplicates (I could elaborate on that if needed, but at a later time). Let's imagine the CEP has a version of the Balor, and Project Q another. Which version should we pick ? If we pick both versions, we might face content bloat again, which isn't helpful at all to a builder (at least, to me, it isn't).

So we might decide that one package systematically overrides the same versions of the other package. However, what if we prefer a version from the first package for one model, and a version from the second package for another model ?

I'm not saying a "public" merger without any heavy compromises is totally impossible (even if my little nose, err builder's intuition, tells me that it comes very close to it). What I'm saying that it's not a worthwhile endeavor given :

1/ how much time is required as initial investment
2/ that all the builders will never agree with each other on the compromises that need to be done
3/ that no one will accept to reliably maintain such a merger throughout time, making it effectively pointless to builders with each new release of the two packages.

There you have it. I don't mean to discourage anyone to undergo such a challenge, please prove me wrong by all means ^.^ I also certainly do NOT want to discourage anyone to use either of these fantastic packages, or both of them at the same time, by tweaking them themselves, but I think we should all keep in our mind if it's really worth it in the end to have it ALL.

We have a local saying here where I live : sometimes, "better" is the enemy of "good".

Modifié par Nissa_Red, 08 mars 2013 - 01:56 .

[painofdungeoneternal]

Sounds to me like a good test. Your description is quite helpful, very similar issues as I am dealing with in NWN2 -- and yes i understand it's skipping a lot of details - it's nice to have an idea of what i am getting into from someone with experience.

I don't think it's possible to do it perfect, the goal would make it so a deranged person who decides to use everything, would be able to use it for his PW or other project, and really stress the issues in my system to the point where it's easy to spot them for me. Really doubt it would ever assemble in the same way twice, and each mashup would need a custom set of instructions on how to deal with required choices, and anything built with it would need to recreate it as it was.

My preference though is that such a tool would not be for merging Q and CEP, but rather it could be used to make bits of Q, and bits of CEP, and a lot of other bits, can all be downloaded and merged dynamically in more granular pieces to create custom packages. Eventually you'd select the individual creatures, clothes, tilesets, scripts, whatever you want to use, and the compilation would be built as needed. Ideally compilations would be less sets of content, and more instructions as to what content is needed, and any post processing, and injection needed.

Perhaps make it so certain things are reserved/standardized, so a desert using Q or a desert using CEP would tend to use the same slot/row, a balor tends to use a certain row in appearance.2da, and other similar things tend to be marked as versions of the same thing which are interchangeable. This is a future idea, but thinking if you use little content, and most people have a demon on row 9999, then as you add lots of content or swap areas with others, its less likely to be a problem if I can make demons magnetically attracted to a given row unless it's already in use.

[Nissa_Red]

painofdungeoneternal wrote...
My preference though is that such a tool would not be for merging Q and CEP, but rather it could be used to make bits of Q, and bits of CEP, and a lot of other bits, can all be downloaded and merged dynamically in more granular pieces to create custom packages. Eventually you'd select the individual creatures, clothes, tilesets, scripts, whatever you want to use, and the compilation would be built as needed. Ideally compilations would be less sets of content, and more instructions as to what content is needed, and any post processing, and injection needed.

Perhaps make it so certain things are reserved/standardized, so a desert using Q or a desert using CEP would tend to use the same slot/row, a balor tends to use a certain row in appearance.2da, and other similar things tend to be marked as versions of the same thing which are interchangeable. This is a future idea, but thinking if you use little content, and most people have a demon on row 9999, then as you add lots of content or swap areas with others, its less likely to be a problem if I can make demons magnetically attracted to a given row unless it's already in use.

You appear to have a very reasonable take on the question.

As a builder, and if I correctly interpreted what you said, your tool would have an immense value to someone that tries to patch together different hakpacks on a "project" level, rather than a "public" level. While I am not eager to support any kind of "mega-ultra" merger project, like those we've seen in the past and which were all doomed to fail eventually, I'm eager to provide you with whatever personal experience I have acquired during my own toolset "adventures", however modest it might be, if you found it useful.

At its core, I consider a NWN resource as "an appearance", or rather as "an appearance + associated functionalities", because sometimes stuff like WOKmeshes or animations are not immediately visible. As I see it, the issue with building from a huge pool of NWN resources is not only to manage to make them all work together, but also to identify and catalog them (to avoid content "bloat"). That has always been THE true issue to me, and I'll spare you all the lamenting of me finding yet another instance of Lisa's clothes in yet another cloth hakpack, for example ^.^ Since Lisa's cloth models were mostly near perfect to start with (in the way of a toolset resource, anyway), no one ever retouched them. Therefore, there is no added value to find them in separate hakpacks over and over again.

It would be a huge time saver to me if some kind of tool could somehow identify these models when inspecting/importing a hakpack, and associate them with a catalogued base model, if relevant. But how could we identify models of a common pool, with plenty of potential duplicates, through a unique way ?

Well, unfortunately, I haven't found any easy way. The model name, size, time of creation or MD5/SHA are not reliable enough. The way I still do it is through visual inspection of the "appearance", and then model file, to detect additional "functionalites", like updates, corrections, or added value (animations, phenotypes, icons, etc).

So what I'd consider as next best option would be to be able to import hakpacks as a whole, visually inspect models (with an interface like NWNexplorer), catalog models once and for all in a local database with a proper key if I identified them as unique, so that extra documentation could be added. This extra documentation could be automatically generated, for at least a good part of it, from the 2DA or directly from the model/texture files. If it can't be generated (the setting or style, for example : oriental, modern, medieval, etc.), it can be added by the user. It would also help pinpointing models with issues. For example :

• this bodypart model has a PLT texture with C1/C2/L2/M1 channels
• that creature comes with a reflection map
• that tile lacks the proper lighting nodes
• that placeable lacks the proper use nodes

I should then be able to export the model (and any associated textures or models, like phenotypes, reflection maps, doors or tileset groups) "on the fly" with whatever toolset identifiers ("001", "002", "tcn01", "race", etc.) fitting my needs, along with the properly constructed ".2DA"/".set" files. There is my hakpack.

The next time I find interesting resources on the Vault, or elsewhere, I will import it, compare it to existing/catalogued resources, and eliminate duplicates. Since I would only ever be keeping unique models, new stuff would play nice with the old from the get go. It just would take some efforts to get it all catalogued at the beginning.

Basically, it would be a "Set editor" (updated here), expanded for any kind of NWN resources, but with a database.

Why a database ? Because builders operate with entities at the "object" level, rarely if ever at the sub-level. If I want to merge clothes in a hakpack, it should come with everything needed to find "clothes" in the toolset, without the risk of forgetting anything or wrong human manipulation/operations (for example, "pmh0_chest38.mdl", an existing BW model, which should have been "pmh0_chest038.mdl"). The same for tilesets, creatures (which have footstep sounds, sizes, races, etc.) or placeables (which have soundsets, portraits, etc.).

Why a local database ? I've thought of an online database, but there is the lingering question of who will maintain it, pay for the upkeep costs, etc. If some common repository could be agreed upon however, the database could be fed and monitored through community effort, and the advantages would be immediate :

• like you suggested, cc artists could reserve "lines" (that models are "magnetically" lured to) and would get proper credits as original source when their model is used somewhere
• their models could be fixed or enhanced throughout time and ALL the builders would benefit from them
• since almost any resource would be uniquely identified (except recently released stuff), the risk of duplicates would be significantly lowered

Working hakpacks could be generated "on the fly" from anywhere, for almost any kind of project (PW/SP modules). Local databases would be a fallback solution, or perhaps the first step towards a more centralized option.

I think this post is probably long enough as it is though, and I'm perhaps too optimistic and overlooking stuff, so before I get further carried away, I'll stop for now ^.^. Thank you for undertaking this project. If (and I really hope it will) it takes off, you'll have solved about 95% of the issues the community ever had with custom content.

Sending you my encouragements, and kind regards.

Modifié par Nissa_Red, 09 mars 2013 - 02:11 .

[painofdungeoneternal]

I see the duplicate issue as key to what i am doing. CRC and the like is the first line of defense, but frankly my aim is to just inventory all the current content, and set it up so it can be annotated by anyone, using an open API ( which can be accessed by websites and applications. ) What you are describing will not be done up front, but rather crowdsourced on an ongoing basis. However, getting the use nodes, level of details in the models, and related 2da information up front will be part of the initial processing.

It needs manual control to work well, and making this easy is key. But all the work is going to be labeling the data, with preview images eventually added, and the data fields being changed to support the latest ideas of the community. How the data is used, i think should be open to the end users, hence the data won't be in a database, but in a open web service type API. The data is going to correlate to the vault and the nexus, and be maintained as these update so it's always in sync. If you have a file on your system, with a crc of suchandsuch, my api could identify all the original sources for this content. Likewise, it creates a system to allow the community to access overall data on what is in the vault, what is duplicated, what is unique, and further to add information, commentary and annotations to that data.

In addition this is in association to the Vault Preservation Project, which has much of the vault content safe on hard drives, but does not have it usable. Rolo Kipp invested in 2 years of hosting ( and he really could use contributions and support, most of us just don't have a lot of cash to get this going. ). The idea here is we cannot just reupload the vault willy nilly, but if the vault dies, and we have a backup we throw up which has the same content, by some folks associated with the vault ( hence sidestepping the lack of permission ). I am not backing up the vault, but inventorying the content of the vault, with names, dates, crc's, and even preview images, and including information I am adding on where this content should be installed to, and plan this to support the VPP.

My primary purpose at first is the installation of packages, either as a whole or in part. Installation will be driven by manifest files, which describe the original content, but also allowing dependencies, which will download from the vault, nexus and private sites. The player hits play on a module, I see the crc of the module and the modules name, can use this to look up the data related to this module in the API and thus get it's dependencies, and know it needs certain override content to run right, and where that overide content needs to be downloaded from.

But the way I am doing this, is designed to allow others access to the same API ( similar to how people use the facebook api to make games, or the google maps api to show location information, or skywings api to make new ways of hopping into NWN ).  Others will come up with things I have not thought of, and marking content which relates to other similar content, or which is part of a given set, or which uploads/downloads content easier, or which manipulates the data in new ways.

What you are describing, can easily be done with my API, probably by me, or by anyone else who has a hankering and can't wait until i get to it. Since i already note the crc of unique content, and the dates and names, some of the work will just be data processing. Despite it being a different flow, it seems entirely possible to do what you describe to the raw data, and really this seems to me to be annotating of what is out there.

Further, manifests I see as being used to patch content of others, thus allowing community fixes to old content ( or even official content such as adding things to the OC modules ). The old legacy content is going to take a long time to sort out, but upgrades, and new content, as it's done can be tracked while it's done, especially if my app is used to sync versions on a authors system with the vault and nexus. A user can just request all the content that fixes a given package ( which is marked at a given quality level ), the query can be done in the API, and the end user gets the latest and greatest.

Similarly, if I see a new version of a piece of content, i keep the old and new crc's for the pieces, thus being able to track the old version, and using matching names to know a piece is an improved version. This should allow me to correlate the various crc's and names, and identify whenever that older crc is present, that it likely can be replaced with the new version. Again this is largely just data processing, once the raw data is stored this is just leg work.

The key i think to doing what you describe, is to have a table of packages, which might be on either the nexus or the vault, or both.

Then have a table of files as seen in the file system, haks, erfs and other loose files - these are the containers.

Deeper in have a table of loose files, but also the contents of erfs, haks and such - these are the actual files. A indivual 2da row almost belongs at this level as well.

Finally to come back to what you brought up, to have a separate table listing items - placeables - clothes - tilesets, ie the smallest pieces people actually deal with. IE a model comprising it's animation, it's texture, 2da adjustments, etc and a picture so it's easy to identify it. But further have these list what is variations on the same piece. And give certain people authority in the community to help organize these, specify rows and indexes this content prefers to use, and which is the most ideal version of the specific content, whether it's greek or other tags, and who the actual author is. ( further when installed the ability to easily renumber, but make it so it tends to use certain rows to increase compatibility )

Reserving rows is a big issue, and after the data previously described is setup, well this likely will build on that.

( the tlk file issues I think i have much better handle on, and hope to have a system which indexes all the used tlk entries on the vault, and the text involved, as well as the various translations and official tlk entries. My hope is here to crowdsource translations and get it so even minor content gets a translation, perhaps even get the game translated into entirely new languages, but kind of leery of getting into this at the moment as this is going to be hard to get set up right away until quite a few other things are completed. )

Again thanks for your input, going to be reviewing your comments more in depth as I develop this. Still going to focus on the CEP and Project Q, using the system I described, and seeing how much i can get both of them working together ( pulling this off topic detour back into it's original topic ). This is going to be how some people use my tool initially. ( need to see how Q does the rsync as well, just so i use the latest versions of their content, never tried recreating rsyncing yet )

( done editing finally )

Modifié par painofdungeoneternal, 09 mars 2013 - 08:52 .

[Nissa_Red]

I will let you finish before answering.

Mostly however, I agree 99% with you, and very enthusiastic about your project/goals.

Please take your time, still sipping morning coffee here.