69 réponses à ce sujet

[Nissa_Red]

First, thank you for your valuable feedback, and time. I think I understand better now what your goal and priorities are.

In essence, your tool is the manager of a huge ("virtual"/"distributed?", I want to avoid using too much lingo) hakpack, without the limitations of a hakpack.

1- It would take as input :
a/ a collection of hakpacks, downloaded from the Vault or elsewhere, like today.
b/ a list of "identifiers" associated to unique content, regularly updated online as new content is released
c/ module/user dependant data (customized 2DA, renaming or renumbering schemes, etc.)

2- It would deliver as output :
a/ one or several hakpacks

For players, everything is transparent (and simply downloaded online through your tool). Builders will have to intervene at 1-c/, to provide the data (manifests) for hakpacks and modules that already exist, or that will be avalaible tomorrow, and record them in a community-moderated online "database" (like a wiki).

It comes as a batch/API, that can be expanded upon.

Hopefully, I got that right. Please don't hesitate to correct me if I'm wrong.

Of course, despite some slight skepticism that remains in me about how you intend to proceed at point 1-b/ to obtain the identifiers in a fail-proof way (and I have ideas to submit about alternatives or complements if you were interested, but that'll come in another message, to keep this one short), I believe you know what you're doing, and I can see the immediate value of such a tool for our community as a whole.

Of course, you saw right through my (now with some hindsight, naively stated) "expectations" in my previous message, and it's all to your credit that you tried to get me back on a more reasonable track in a very diplomatical fashion ^.^

I would, indeed, love to convince you (or maybe someone else, but one has to take the chance when the opportunity arises, yes ?) to add to your tool :

3- It would allow the user to add personal documentation to identifiers of 1-b/

The point of my suggestion would not be to duplicate downloaded content in a local database. The database (SQLite should suffice) would only ever contain documentation that will always remain subjective, like categorization, or that is simply not worth being centralized, like annotations or links to local documents (.pdf, .doc, .xls). The purpose of such an evolution would be to enable builders to easily construct the manifests needed at point 1-c/, much more easily than any current tool allows. This in turn would allow us to feed your tool with it, and obtain customized hakpacks within minutes.

It's my feeling that we're basically swimming in custom content and can't take full advantage of it, because we can't properly categorize, catalog and ultimately manipulate it. It's a pretty frustrating one, hence why my plea, but I'm the first to realize the burden that you put yourself on your shoulders with such a project, and  would hate to compromise it with something that doesn't do anything to alleviate it >.<

Modifié par Nissa_Red, 09 mars 2013 - 10:36 .

[Rolo Kipp]

<listening...>

@ Nissa: Just a quick note, the synergy between so many projects under active development excites the blazes out of me :-)

One of the initiatives I've started (that is waiting breathlessly for the Never Launcher API) is the Custom Content Conservancy (which is one of several projects under the VPP).

The intention of the CCConservancy is to catalog - with proper attribution and screenshots and (if I can interest someone who has already demonstrated a java3d model viewer into figuring out a web embedded version... ;-) even a model previewer. It will recursively spider through all the stored content, find identical files and attempt to determine who the initial author was. This would be the root of a resource tree. Improvements would be versions up the trunk, variations would be branches (and might - in Launcher - be offered as choices to players (depending on builder settings, I'd imagine).

Eventually, I want every texture, every model, every sound indexed, cataloged, commented, and available, complete with listings of dependencies (these file use this model, this model uses these files, this model can be found in these archives).

This dialogue is simply wonderful, and I really hope you continue to give input into all these eggs I'm brooding over =)

<...ovidly>

[AndarianTD]

HeavenStar wrote...

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?

Not only is it possible, it's been done. See my recently released remake of Sanctum of the Archmage 1: The Sight, which integrates CEP 2.4, Q 1.5 and other haks with some module specific content as well.

While I haven't pulled out the haks as a separate release to the community, anyone who wants to develop a CEP/Q integrated module is welcome to use my merge 2DAs. Just download the main Sanctum archive and pull out the Sanctum_QCEP_top.hak. That should give you most of what you need.

(A side warning: There's no easy way I know of to handle the conflicting CEP/Q blueprints as part of the hak system without painstakingly re-making them and adding them to it. The Sanctum/Q/CEP merge is designed for Q content to take precedence over CEP content in those cases, and I resolve conflicts as I need them for my work in the module file. You may have to do something similar as well.)

Andarian

Modifié par AndarianTD, 09 mars 2013 - 02:37 .

[painofdungeoneternal]

Nissa_Red wrote...

I like that description, what i am doing is very hard to get across, as though it's copying many existing things, it's actually a completely new animal which includes features which already exist, but designed to work together. ( and how you described seems apt and yet beyond how I've tried thinking of it yet )

Nissa_Red wrote...

3- It would allow the user to add personal documentation to identifiers of 1-b/

The point of my suggestion would not be to duplicate downloaded content in a local database. The database (SQLite should suffice) would only ever contain documentation that will always remain subjective, like categorization, or that is simply not worth being centralized, like annotations or links to local documents (.pdf, .doc, .xls). The purpose of such an evolution would be to enable builders to easily construct the manifests needed at point 1-c/, much more easily than any current tool allows. This in turn would allow us to feed your tool with it, and obtain customized hakpacks within minutes.

The term is open API. Lets say i refuse to listen to you, and that you have the chops to do it, or just get frustrated ( which is why i ended up doing this, probably not the best person to do it, but no one else listens ).

You can make a program, which matches up what I've done, and it's unique identifiers, and uses those as keys in your local program. Your local program keeps notes and additional information as desired, and you can replicate my installer if you so wish. ( how it works will be documented, and the file formats are all documented and available as source code classes for various languages )

This idea is the same as what i am doing on the vault, since i am indexing the vault content, and adding it to my api, i can correlate the ip on the vault of a PW, with skywings gamespy api ( past or present ip, or perhaps name ) and allow worlds to be listed by vault rating, thus letting players get a means of choosing a PW besides player count.

Of course I do listen, and plan on adjusting, just wanted to underline what open means, and that when i am done it won't just be up to me.

( Manifests would be constructed not manually, but based on what is installed or in use, NWN2 for example builds a xml file describing the download requirements each time you save a module inside the module, simple things would be auto created. I will have manifests, and data inside the API, entirely done via batch processing initially, but the language I am using allows for conditions, and custom commands inside these manifests - ie instead of set a row on a 2da, the language lets you append a row and i cannot automate this easily ( for some feats being in use by a class )

The results would be similar to mac ports in how it works, but by indexing things and knowing the folder they were in, and the file type, it's possible to automate it.

Modifié par painofdungeoneternal, 09 mars 2013 - 02:49 .

[OldTimeRadio]

Rolo Kipp wrote...
...and (if I can interest someone who has already demonstrated a java3d model viewer into figuring out a web embedded version... ;-) even a model previewer.

See, this is a great idea but...Well, I tried this sort of thing out two different ways in the past and IMO, it's one of those "better on paper than in practice" ideas, IMO.  I came at it from both VRML and using Acrobat 3D, FWIW.  What happens in both cases is you wind up going through a lot of bandwidth, in the form of streamed data or filesize, just to duplicate content (models, textures) that you're not really getting all that much of a payoff for duplicating. 

IMO, as pedestrian as it sounds, a good 3/4 isometric screenshot made with something like NWN Explorer Reborn with the appropriate "Initial viewing angle YPR" settings (in options) is going to net you something almost as good as a full 3D model with just a fraction of the bandwidth/processing power.  And that work can also be crowdsourced much more easily, to boot.

[Tarot Redhand]

Building on what OTR just said, take a number of shots in sequence of the same object at differnet angles and combine them into an animated gif for the best of both worlds.

TR

[henesua]

I agree with the screenshot.

I could write a web based NWN explorer for a database of resources, and think it is possible to do so without running into serious bandwidth problems BUT I've got other fish to fry so am definietly not signing up to write such a thing at this time.

Why not just start with posting screenshots and if I or anyone else ever gets around to writing a web based NWN Explorer you can plug that aspect in.

[Nissa_Red]

Rolo Kipp wrote...
@ Nissa: Just a quick note, the synergy between so many projects under active development excites the blazes out of me :-)

You and Painofdungeoneternal (and everyone else working on the project that I'm not aware of too, of course) have my gratitude for taking such a project at heart. I'm really happy you do.

I'll admit I didn't know about CCConservancy till very recently. I thought that barring a complete copy-over to the Nexus or maybe a static "emergency" backup of the Vault stored somewhere, we'd never have as favorable a situation as the one we're currently experiencing in matters of custom content available to ones of my fav' games, NWN. Now, and thanks to Painofdungeoneternal's thorough explanations, I think I have a better and more optimistic perception of how things could evolve, and I am really starting to like the "CCCs" : they tend to bring us good things around these parts ^.^

As a module builder, I try to make mine the following preoccupations :

- making the best out of what we've been so generously provided with by people that shared the fruit of their talent and work with us, to preserve it (not at the level CCConservancy may do, of course, just for myself or friends I play with) and to further enhance it if at all possible (through fixes, but also through a more pertinent use in modules)
- being able to reliably identify content, to be aware of where it comes from, not only for the sake of integrity (avoiding duplicates, or benefitting from enhancements that might have already been done by the community), but also to acknowledge the original authors, so that I can show them the respect and gratitude that they deserve

For me, these concerns go hand in hand. Achieving the first isn't possible without the second, and working on the second would have no point without the first in sight. So, to do this, my current workflow looks something like this :

1/ I download content from the Vault (or elsewhere), and archive it on my hard drive in a way that I can trace back to it easily (URLs for example)
2/ I gather similar content by type and then categorize it through Excel/OO sheets
3/ I inspect the content more closely, either through NWNexplorer or MDLviewer, and document it
4/ I attempt to identify potential duplicates or synergies
5/ I take advantage of this time to also gauge the quality of the content : are any fixes needed, or further customizations desirable/possible ?
6/ I then take decisions as to what kind of content I intend to keep, and what I need or want to remove
7/ I use a batch to extract/reorder the content that I've previously identified
8/ I construct the 2DA/Set files needed for the extracted content to play well together
9/ I generate the final hakpack(s) out of 6/ and 7/

At this point, I should finally be able to start building, with near optimal knowledge of the content in the hakpacks of my module, of its sources (so that I can give proper credits), of its weaknesses (what kind of fixes I still need to make, or to be on the lookout for), qualities and potential (how I further could customize it to bring my "personal" touch).

All of this I can already do as of today, but since I've read Painofdungeoneternal's messages, I wonder if I couldn't do it better, meaning faster and especially more reliably.

5/ and 6/ will never turn into automatic processes. They're my "added value" as builder.

1/ as automatic process is of no direct value to me as builder (but would be as player!).

7/, 8/ and 9/ are already more less automatic for me, and while I don't doubt that it could be further improved, I believe that the tool will adequately handle these parts, without further conforming to what I perceive as personal preferences on my part.

2/, 3/ and 4/ are *the* processes that can be painfully slow, and really bring me to a halt sometimes in my building. Here third-party assistance is desirable to me.

4/ is already within the scope of the tool, so that leaves us with just 2/ and 3/.

So what is that the tool could do for me as a builder ? Without further petitioning for my "cause", as I've already said more than my piece of pie about it, and Painofdungeoneternal has shown remarkably patient about enduring it, I would just like to add the following :

2/ It's good that the tool will come as open (API) and documented. I don't know if I'll be able to take on the challenge to expand upon it, but I really see a huge potential there for any builder, and I hope it will be taken full advantage of (like the aforementioned "Set Editor").

Being able to properly assess of what is available, annotate, to sort and filter through it, to make the best possible decisions during the "keep/eliminate" stage is an inherent and essential part of any merging process. This does not change for modding games.

3/ I might go against the majority here, but previews that are automatically generated for *every* model, like static screenshots or even animated gifs, would actually provide very little information to me, plus they appear as having a good number of "show-stopping" inconveniences :

- a serious impact on the bandwith (if stored online) and/or drive space (if stored locally) of the end-user
- the inability to display the full extent of the model's features : WOK, PWK, animations, fixes, tintable textures, I'm sure there's more
- the render may or may not correspond to what one actually experiences in game (this already happens with NWNexplorer and the toolset)
- they need to be updated (which could arguably also be part of an automatic process, but process + process + ... ends up in a lot of processes!)

What I do find useful are screenshots of the packages as a whole, ideally accompanied by demo modules/erfs to quickly try them out, like they currently exist on the Vault. NWNexplorer, or MDLviewer (for animated creatures/phenotypes), are usually more than enough for me to get a pertinent perception of the model (through visuals and source). These tools have the merit to already exist, and any builder worth their name should be using them anyway. Furthermore, they could also serve in the cases where the identification of duplicates cannot be automated and requires user intervention. So, maybe would it be sufficient to just plug into these tools locally, and leave in the online "database" only the manifests, comments and any extra data that has been collected by the community ?

So just these two addons :

- being able to categorize, filter and sort content, directly in the tool (without making it a little brother of Excel), to generate or manually feed manifests
- a split NWNexplorer window, visualizing existing content on one side, new content on the other, with the usual NWNexplorer trees (ideally the v11 one, which I can scroll through with direction keys, contrary to the v163 one)

would definitely rock, err, I mean significantly change for better my world as NWN builder.

I apologize for the repeated lengthy posts, but I'm quite passionate about the topic, and equally so about the project that Painofdungeoneternal (and Rolo?) initiated. I happen to be a part of another community (the BG2 one), which has developed tools that seem quite similar to me in purpose : "BWS"/"BWP". I can relate (at least from the outside) what kind of challenge it is to create, and maintain them. It's not my intent to show inconsiderate of what is already "on the plate" for us in the future, just to offer (subjective, but hopefully motivated) feedback. It's also not my intent to further worsen my reputation as local train "derailer", so I will stop here for today.

Whatever comes out of it, thank you again for doing this for the community!

Modifié par Nissa_Red, 10 mars 2013 - 02:25 .

[Nissa_Red]

Please don't put me to shame just yet, but to be less "wordy", and a bit more specific about my workflow :


To illustrate 1/


To further illustrate 1/


To illustrate 3/ & 4/


To further illustrate 3/ & 4/


To further illustrate 3/ & 4/


To illustrate 9/

PS : these forums are horribly user-unfriendly with images >.<

Modifié par Nissa_Red, 10 mars 2013 - 03:18 .

[Lightfoot8]

Nissa_Red wrote...

Please don't put me to shame just yet, but to be less "wordy", and a bit more specific about my workflow :

147X148http://thumbnails102.imagebam.com/24237/15061c242365939.jpg[/img]
To illustrate 1/

320x320http://thumbnails102.imagebam.com/24237/1ddf2b242365024.jpg[/img] 
To further illustrate 1/

320x100http://thumbnails101.imagebam.com/24237/a4a2de242365026.jpg[/img]
To illustrate 3/ & 4/

300x100http://thumbnails106.imagebam.com/24237/da80c3242367946.jpg[/img]
To further illustrate 3/ & 4/

300x150http://thumbnails103.imagebam.com/24237/042d20242367948.jpg[/img]
To further illustrate 3/ & 4/

300x300http://thumbnails101.imagebam.com/24237/259d06242365021.jpg[/img]
To illustrate 9/

PS : these forums are horribly user-unfriendly with images >.<

eeeks    Still no good.

Modifié par Lightfoot8, 10 mars 2013 - 05:37 .

[T0r0]

Good a place as any to ask this question being that the CEP forums are quiet.
So regarding the ttr01 set file (or ztr01, as the case may be), is the thinking behind all the padded lines that they are reserved for CEP or reserved for other projects that may have used those lines?
I've seen it done both ways so *shrugs* any ideas ?

Usually in 2da's for example, they'd say "xxx reserved"

[Lightfoot8]

T0r0 wrote...

Good a place as any to ask this question being that the CEP forums are quiet.
So regarding the ttr01 set file (or ztr01, as the case may be), is the thinking behind all the padded lines that they are reserved for CEP or reserved for other projects that may have used those lines?
I've seen it done both ways so *shrugs* any ideas ?

Usually in 2da's for example, they'd say "xxx reserved"

Perhaps I am not understanding what you are asking?   

Prehaps I am also not the best one to answer the question since I gave up on CEP a long time ago.     


To answer you question the way im reading it.  A .set file is in the "Windows INI file format".  The only thing padding would do is bloat the file,

Modifié par Lightfoot8, 12 mars 2013 - 07:03 .

[OldTimeRadio]

T0r0 - Could it be that Acaos was trying something like Den of Assassins was describing in the Omnibus thread "Padded Tilesets"?  The last message in that thread holds a decent synopsis of the idea.  I believe the "padded" entries you describe should give clues whether this is the case or not.

Modifié par OldTimeRadio, 12 mars 2013 - 06:36 .

[T0r0]

Let me rephrase. It is padded. From 283~500. The text in the padding doesn't reveal much. Just says tpad which is prob short for tile padding. What I was asking was if anyone knew if cep had any plans to use those padded lines themselves.
now that I think on it, it would make sense if they did add tiles, they would add to their last line , tile 501-652.

[OldTimeRadio]

T0r0 wrote...
Let me rephrase. It is padded. From 283~500. The text in the padding doesn't reveal much. Just says tpad which is prob short for tile padding. What I was asking was if anyone knew if cep had any plans to use those padded lines themselves.
now that I think on it, it would make sense if they did add tiles, they would add to their last line , tile 501-652.

Ok, I see what you're talking about now. 

Well, to explain the reasoning behind my answer: From everything I've seen, read and know, the guy who jingles the keys to the CEP 2.x Vault entries appears to have locked himself in a room with the project and made it pretty clear that he's going to shoot it in the head if anyone tries to open the door or, perhaps, knock too loudly.

He has stated that he doesn't have the skills to add further tiles and I know that at least one of the two people who show up to pretend they're active members of the team while making ambiguous legal threats do not know how to make those changes, either.

Unfortunately, the person who worked on those .set files bowed out several years ago and, barring unforseen miracles, will not be returning any time soon.

So...I am thinking the most accurate answer is "No".  I thought about trying to gloss over the situation but all that would have done is seem to contradict my answer.

[cervantes35]

I have started an online wiki Project Q, which I hope to have all instuctions and documentation as well as peeks of version published materials.  Please don't kill me on this as it is in its very early infancy stage at this time, but good feedback and ideas are very welcome.

project-q.wikia.com/wiki/Main_Page

Modifié par cervantes35, 14 mars 2013 - 02:22 .

[NWN_baba yaga]

OTR´s view is so accurate it´s a point blank shot + 10 ... But no... i dont want this to happen again... no i dont want precious... YES YO DO ...tasty little topicses

Modifié par NWN_baba yaga, 14 mars 2013 - 05:29 .

[cervantes35]

OTR is spot on and is one of the reasons I gave up on making any of my haks CEP compatible as I no lomger even it use it.

[The Amethyst Dragon]

I (finally) updated the original post in this thread with Project Q version 1.6 information.

Modifié par The Amethyst Dragon, 11 septembre 2013 - 04:07 .

[The Amethyst Dragon]

Bumping back to the front of the CC section in case someone new needs the info at the start of this thread.