423 réponses à ce sujet

[Killmonger]

(In the same way that names/tags can be used for NPC activities)

Could skilled scripters use the 0-255 range(s) as place holders pointing to some larger dynamic library?

[Pstemarie]

This is way off topic - but the thread seems to be heading that way in general. Let's first just toss CEP2.x aside for a moment since TAD clearly has a handle on that.

Considering that you guys are talking about automated tools, I propose consideration of the following:

1. A central repository for custom content organized by author.

2. Under each author, content is divided into primary subcategories - PC parts, placeables, creatures, etc.

3. People come to the repository, shop for content, select what they want, then go to a final "Check-out" routine.

4. During the checkout routine, the content is filtered into an organized hak structure, 2da files are created, and the content is then packaged for release to the "buyer."

I'm not even sure if this is possible or even feasible because of the glaringly obvious DRAWBACK - literally hundreds of custom haks being created for every little project, but maybe that's what we need. Its really a trivial thing to move hak collections into sub-folders when not in use.

[The Amethyst Dragon]

Proleric1 wrote...

For NWN, the biggest obstacle is the limited 0-255 range for body parts. I guess the 2DA merge tool would have to respect priorities, on the same principal as a top hak.

The CEP still has 111 spots for chest pieces (parts_chest.2da has the most entries of any of the parts_* 2das).  Still room for some expansion.  

The biggest current limit on expansion is in the areas of shields and weapons.  Evidently shields are pretty much filled out.  There are work-arounds that are relatively easy to handle.

Weapons...expand into "color channels" 5-9.  Already started with a couple of weapons, but there's lots of room for expansion.  It means that 5-9 won't necessarily be color variants based on color channel 1's appearance, and there's also the fact that regular NWN can't handle scripting of color channels other than 1-4, so it'd all be for toolset use.  There's a NWNX2 plugin that is supposed to remove the scripting limitation, it just won't work on my server for some reason (none of Terra777's plugins work for me, unfortunately).

Shields...switch to 3-part shield models. Copy all the current shields to make them "bottom" parts and the game engine will automatically use just that bottom section for shield items made with the standard 1-part shields.  To use the "middle" and "top" parts, just be sure to include a non-rendering "blank" shield appearance for each part (b/m/t).

I did the switch to 3-part shields with my PW when I added Project Q a little over a year ago, and it was a much smoother transition than I anticipated, thanks to NWN handling existing shields for me.

[OldTimeRadio]

@Pstemarie - I love the idea but the weakness has always seemed, to me, to be that it assumes that a module builder will have a good idea of what they're going to use, CC-wise, at the outset of their project.  Based on what I have to admit are subjective observations, I don't think they generally do.  Which is why packs like CEP or Project Q or things like that are more appealing to the average builder.

@Amethyst Dragon - Your fourth paragraph, about shields and backwards-compatible transition from 1-part shields to 3-part shields: That method is confirmed or has at least been tested and appears to work with existing blueprints?  If so, that's really slick.  What're the plans for the top two pieces? Other shields or modifying "effects" of some sort?

Modifié par OldTimeRadio, 04 février 2014 - 04:46 .

[Estelindis]

PSM, it sounds like a good idea in many ways, but it wouldn't mean redownloading content for every module's unique combination of content? Have I misunderstood?

[henesua]

My take on what Pstemarie is talking about is the future of NWN custom content bundling due to the vast amount of it.

There is another piece required for this however, and that is PainofDungeonEternal's automatic content downloader. Pain was working on this along with our project to back up the entire vault. We have mirrors of the entire vault on a few hard drives (each is a mirror - the total content is about 500-600 GB), but we never got around to implementing an automatic content downloader.

So this is how it could work:
- a builder checks out content as Pstemarie describes. The names for the HAKs would be set ahead of time by the CEP team, and follow some CEP 3 conventions. (The CEP 2 HAK structure and names should probably not be followed for this purpose)
- builder builds and releases module, then posts the "master" repository used by the module.
- player downloads the module, and launches it using Neverlauncher. When the module launches, an application checks the builder's master repository against the player's custom content. If anything is missing, it is injected into the appropriate HAKs. When this is done, the module finishes launching and the player plays the module.

Modifié par henesua, 04 février 2014 - 05:49 .

[The Amethyst Dragon]

OldTimeRadio wrote...

@Amethyst Dragon - Your fourth paragraph, about shields and backwards-compatible transition from 1-part shields to 3-part shields: That method is confirmed or has at least been tested and appears to work with existing blueprints?  If so, that's really slick.  What're the plans for the top two pieces? Other shields or modifying "effects" of some sort?

When I added Project Q to my PW module, I decided that the 3-part shields were very cool and decided to make existing shields work with the system. So, what I did was...

1. Copied any CEP/Aenea/other normal shield models and icons that I wanted to keep using.  The copies were renamed to fit the 3-part model names format (ex: ashto_051.mdl became ashto_b_051.mdl, and iashto_051.tga became iashto_b_051.tga).

2. After adding the renamed files to my hak, I updated baseitems.2da to change the shields to use 3 parts instead of a simple appearance.

3. When I opened my module in the toolset to manually update all of the existing shield blueprints, I found that the game had defaulted to take the shield model number that had originally been assigned to the blueprint and used the new bottom part model with the same number.

4. I then took a break to sit down and relax (I stand to use the computer) and watched some TV since I suddenly had hours of time free that I'd planned on using to do drudge work to fix what I thought would be broken.

The conflict that might likely come from switching CEP to 3-part shields would be for those builders that have added standard single-part shields to their own haks that aren't already in the BioWare resources or in the CEP.  Such shields would need to be duplicated/renamed in order to not show up looking like brown bags on a character's arm.

I'm thinking this conflict might make moving to 3-part shields more of an optional hak for builders to decide individually to use, just like with !q_armoury.hak for Project Q users.  Those not using the option would just have fewer shields appearances to use if/when new appearances run out of space as single-part shields.

As far as plans for the "middle" and "top" shield parts, I'd make part1/color0 as a "blank" non-rendering model and empty icon for each, so that new shields created with the haks have a basis to start with.  I'd also add a bottom part1/color0 as a blank.  The middle and top parts could then be used to add all new shield appearances and "effects" that can be layered onto other shield parts (flaming shield? decorative skull? whatever)...it would open up another 508 potential appearances for each shield type.

Of course, like other 3-part items, if you add a part1/color0, you also need to add color0 for every other part# that gets used for that section...so if you have a shield with appearance 021 (_b_021), it won't show up in the toolset if you don't have one with part2/color0 (_b_020).  Also, you'll need to include a part1/colors0,5,6,7,8,9 if you want to use those "color channels" for higher numbered appearances.

When I switched to using 3-part shields, I mixed in the Q appearances and only kept those CEP shield appearances that I personally felt like using.  We wouldn't be able to eliminate appearances that builders might have used or want to use for a CEP version, but a "guide" image I made for my own use should help illustrate the concepts with part numbers being needed.

Aenea Guide: Large Shield, Bottom Parts

So, yeah. 3-part shields are possible and easy to use from a builder standpoint, just a bit more work for builders that use non-BioWare/CEP shields, so they'd have to be an optional hak.

Modifié par The Amethyst Dragon, 04 février 2014 - 06:52 .

[Proleric]

It strikes me that both compatible 2DA numbering and a 2DA merge tool have merit, regardless of how content is delivered to players.

I hear what people are saying about a central content repository, but authors who prefer to build and distribute their own hak (plus one or two major public haks, perhaps) would also benefit from a common 2DA approach.

Since storage and bandwidth become less important over time, and old sites fade away, availability and risk are now relatively more important, so, without prejudice to better ideas which might be in the pipeline, I'm building my own hak + CEP for now.

So, in this thread, I'd welcome a common approach to 2DA and CEP.

The wider discussion about Q, CTP, Foundation or whatever probably needs a bigger canvas, as it raises much bigger questions of effort, risk, licensing etc. I'd like to understand how to press on with the here-and-now of updating the CEP, in ways that don't preclude subsequent integration.

[Zarathustra217]

Due to the limited success of my first relentless running the CEP content through CM3 and the compiler, I've started focusing on one hak at a time, fixing all the errors it leaves behind manually. If anyone is interested in helping out testing, here's a link for my updated version of the cep_core0.hak:

dl.dropboxusercontent.com/u/16677912/cep2_core0.7z

Simply let it override your current. It should be fully backward compatible, so you can just continue what you usually do, but be on the lookout for errors.

It fixes lighting settings in roughly 1000 models (not all equally relevant though), as well as cleaning up models, resolving various shadow casting issues, welding verts and tverts, removes duplicate models and fixes a few textures. Plus, all models are now compiled (about 300 models didn't compile priorly due to various issues.)

Let me know if you find any errors, using the NWNCEP wiki page here: http://nwncep.wikia....iki/CEP_2_Fixes

Modifié par Zarathustra217, 05 février 2014 - 12:23 .

[TheOneBlackRider]

@ Zara: Oh! I just sent 3 fixed models to TAD yesterday (or so): nw2merch3, which had a totally unusable PWK (a house model) and dag_tnocliff1+2 with new PWKs (they were VERY ROUGH boxes) and fixes. It went out to the nwncep_AT_gmail adress. Did TAD get them to you? Are they included?
I thought this would be organized via TAD. Or is your aim to fix existing CEP2 stuff and TAD+helpers go for 2.6 with additional content only?

Modifié par TheOneBlackRider, 05 février 2014 - 05:18 .

[The Amethyst Dragon]

I just got the email and downloaded those files, TheOneBlackRider.

Zarathustra217: Do you have a set of just the files that were fixed/updated? cep2_core0 has 10,702 files in it, and there's no easy way to tell which are updated and which aren't if they're in a hak. Usually I could look at the date the files were last modified, but when extracted from a hak all the files get dated/timestamped with the date they were extracted.

[Zarathustra217]

The file I linked in the mail I send you should actually contain just the updated files. All models are updated however, but since most fixes are minor, other fixes send in should hold priority. I can always run those files through the same processes later if deemed necessary.

It would be nice though if we could distribute all fixes send in to everyone fairly regularly, so we all have the most updated version to work with. Perhaps the new vault could host it?

Modifié par Zarathustra217, 05 février 2014 - 05:08 .

[TheOneBlackRider]

Fixing old issues is good! But maybe this should be kept seperate from a CEP2.6.
Instead of updating the original HAKs, which would mean, that players would also have to redownload these HAKs, why not create a eg. CEP2_core_fixes, CEP2_tiles_fixes, ..., which holds all fixed for CEP2.3/2.4.
And CEP 2.6 is for new additions.
Well, if you cleaned up most of the core0 models, one topping "fix"-HAK for all the core-HAKS would be a bit huge.
(If this was discussed here before, I missed it and I apologize.)

[Pstemarie]

TheOneBlackRider wrote...

Fixing old issues is good! But maybe this should be kept seperate from a CEP2.6.
Instead of updating the original HAKs, which would mean, that players would also have to redownload these HAKs, why not create a eg. CEP2_core_fixes, CEP2_tiles_fixes, ..., which holds all fixed for CEP2.3/2.4.
And CEP 2.6 is for new additions.
Well, if you cleaned up most of the core0 models, one topping "fix"-HAK for all the core-HAKS would be a bit huge.
(If this was discussed here before, I missed it and I apologize.)

If you create additional HAKs to house the fixes, then you still create additional burden for builders and users. As fixes, these files MUST override content in the original HAK files. New HAKs should only be added as an absolute last resort. This is the criteria used for Project Q and was very well received by Q Users. In the absense of an automatic updater, the best method to deliver fixes is to unfortunately, force end-users to redownload HAKs. On the plus side, at least they don't have to worry about integrating new HAKs into their module structure.

Furthermore, in the case of modules where the author has moved on, the module never benefits from the fixes because the module never gets updated to the new HAK structure. For me this is what sucked the most about CEP 2.x - it left MANY excellant modules in the dust. Sure, I could play the old modules, but I had to manually update CEP 1.x to work with NWN v1.69 and keep two versions of CEP on my PC, needlessly bloating my HAK folder. Now you want people to potentially have 3 versions?

[Zarathustra217]

Yeah, I think we've agreed on updating the existing haks rather than making new, mainly to maximize backward-support. It's being discussed though to restructure the content between the haks to make it more rational. You can follow that discussion (and take part in it) on the wiki page.

[Pstemarie]

Zarathustra217 wrote...

Yeah, I think we've agreed on updating the existing haks rather than making new, mainly to maximize backward-support. It's being discussed though to restructure the content between the haks to make it more rational. You can follow that discussion (and take part in it) on the wiki page.

Yeah, I know, but this question seems to keep popping up every other page or so. Hopefully my explanations seals the coffin for good - it's a dead issue. 

To TAD and Zath and anyone else toiling away already - keep up the good work. 

[Zarathustra217]

Thanks

And yeah, it's good that you help clarify it. Truth is, there's likely several thousands of players on various PWs and playing modules who benefit from the CEP every day. so it is a task demanding a good amout of reflection before we settle on any form of change.

[TheOneBlackRider]

OK, I do agree. You are right! This "fix-HAK" might work for a single project like a server, which does use other non base HAKs/systems, but not for wide ranged (= in use) basic systems like Q or CEP. And adding a new HAK would of course break the backwards compatibility.
Again: Sorry for loosing track and thanks for summing it up (again ).

Modifié par TheOneBlackRider, 05 février 2014 - 10:05 .

[Pstemarie]

If you guys can get an updater working like the rsync one we had for Q, it'd make your lives much easier. You could add fixes, update HAKs automatically, and fix things on the fly. My ultimate goal for Q when I took over was to move away from the occasional annual updates and into a smaller, more timely update system through rsync - I was aiming for monthly. Unfortunately, we lost our ftp host and the guy taking care of it.

[Proleric]

Pstemarie wrote...

If you guys can get an updater working like the rsync one we had for Q, it'd make your lives much easier. You could add fixes, update HAKs automatically, and fix things on the fly. My ultimate goal for Q when I took over was to move away from the occasional annual updates and into a smaller, more timely update system through rsync - I was aiming for monthly. Unfortunately, we lost our ftp host and the guy taking care of it.

Frequent CEP updates would be great for adding value to the community quickly, and maybe reduce the old dilemma of CEP being out of step with artists' current work. We need to discuss the release process, though. How do we agree content? How do we test it? Needs to be pretty slick, to remain open to all, yet deliver updates that builders can trust.

I'm not keen on auto-update. All change has inherent risk, so I'd rather manage version and quality control of my module manually.

[Pstemarie]

Proleric1 wrote...

I'm not keen on auto-update. All change has inherent risk, so I'd rather manage version and quality control of my module manually.

The builder still has ultimate control - after all added content would only appear if the builder allowed it to. The main idea of rsync was to enable the Q Team to inject bugfixes without making people wait for a new release to get them. Each release of Q goes through a pretty thorough testing process, but we still miss things. 

[Carcerian]

When CEP had auto-update before it was a nighmare trying to keep everyone up to date however, as there was no clear way to determine what daily "build" someone had. The update constantly added new content, not just bug fixes, and could take quite a while to inject hak files on older computers and slow ISPs.

With NWNCX or a similar launcher CEP could check for updates on startup via dll, as an option, as long as the content was kept digestible in size...

Modifié par Carcerian, 06 février 2014 - 12:55 .

[NWN_baba yaga]

If you want AD you have my permission to add my content to your next CEP release. I dont think that adding tilesets was a clever idea from the start within the CEP but do what you want;). Now i think the CEP is finally back in good hands.

[The Amethyst Dragon]

NWN_baba yaga wrote...

If you want AD you have my permission to add my content to your next CEP release. I dont think that adding tilesets was a clever idea from the start within the CEP but do what you want;). Now i think the CEP is finally back in good hands.

Thanks, NWN_baba_yaga. :happy:

[The Amethyst Dragon]

I've added a few options to vote on to the possible additions for 2.60 page and one to the page for possible overhauls to existing CEP content.  Feel free to vote and/or leave feedback.

I'm planning on running each individual little poll for two weeks

CEP Wiki