123 réponses à ce sujet

[Shadooow]

well, lets say that nwncx or its abbreviates (since you made source public, i will be later hopefully able to include this code in my own PW-client - and im not the only one there with his own NWN client app) becomes standard, and the more features like this nwncx brings the higher are chances that this will happen. Then it becomes obsolete I think.

Well nevermind, its not really important and Im not even modeller just user in this case

Modifié par ShaDoOoW, 13 juillet 2012 - 02:38 .

[virusman]

NWNCX is still very far from being a standard. There have been no CC releases utilizing these new features, so I'm not sure if it'll ever be a standard.

[Shadooow]

virusman wrote...

NWNCX is still very far from being a standard. There have been no CC releases utilizing these new features, so I'm not sure if it'll ever be a standard.

well there is quite a problem for PW based modules that its client feature and this is not easy to distribute to the players.

Im working on a custom NWN launcher/updater application for my PW that will automatically connect to my server. But not really c++ programmer and all I can is copy&paste. From your nwncx modifications Ive managed to initialize only master server hook yet. Also my client is probably only for windows which is main problem I have with this approach, but this way its easy to distribute to my players as my testing server is passworded and the only way to join is using the client then (while pass can be found out, there is no reason why would anyone tried to join without client as it allows to pick new base classess already).

Modifié par ShaDoOoW, 13 juillet 2012 - 02:58 .

[The Amethyst Dragon]

virusman wrote...

NWNCX is still very far from being a standard. There have been no CC releases utilizing these new features, so I'm not sure if it'll ever be a standard.

I do plan on making some CC for NWNCX besides the weapon VFX you opened up last year.  I'm going to soon be testing out new beams and texture effects (my one texture replacement test in a pretty much blank module worked quite well) for my PW, and will be experimenting with the helmets in the near future.  I just have several other things a little higher on my to-do list (like finishing the next section of reforged weapon models).

I wish NWNCX could be seen as a standard download.  It's such a simple installation and it opens things up that have been closed off for so many years...things I think should have been open to CC from the start.  I recommend it to all the players of my PW.

[The Amethyst Dragon]

virusman wrote...
Open face helmets:
...As I don't have any suitable helmet models for testing, the current implementation may have some bugs: i.e. disappearing head when re-entering area or logging in with helmet equipped.

I did some testing on this.

I grabbed two default helmet models and extracted them with NWN Explorer.  Pulled them into gmax, removed the front of both, but added the dummy node to the 2nd model.  Dropped them into override and opened a basic module that had both helms ready to grab in-game.

Results:

Test 1: Basic Equipping
Helm 1 (normal) - helm appeared, head vanished (normal behavior)
Helm 2 (with new dummy) - helm appeared head remained (desired behavior)

Test 2: Transistions
area transitions with helm 2: head and helm remain

Test 3: Loading saved PC
loading PC in module that had been saved with helm 2: helm visible, head missing

Test 4: Direct item swapping (not, "unequip one, then equip the other")

test 4a:
put on helm 1: head vanishes, helm 1 appears
swap in helm 2: helm 2 appears, head remains missing

test 4b:
put on helm 2: helm 2 appears, head remains visible
swap in helm 1: helm 1 appears, head remains visible

So...direct item swapping seems to keep whatever head state comes with the first one being equipped.  Going back to doing a full unequip, then equip different helm causes the game to reset the head model.

Other observation (not NWNCX-specific): It looks like the default helms were originally made to go over the default human male head model.  Both helms I tested left some space around all sides of the default head (most notably at the top of the head), and not even the ears clipped through the sides of the pot helm (the narrowest of the helm models, I think).  So, if anyone redoes a helm to be open-faced, it should have some faces added to the interior so that a player doesn't see the sky by looking under the edges of said helm.

Modifié par The Amethyst Dragon, 13 juillet 2012 - 11:50 .

[virusman]

Thanks!
Is it possible to convert HaVFX to open helmet models? Is it just a matter of realigning the model or something more tricky than that?

[The Amethyst Dragon]

It might be. One would have to work on scaling, replace the VFX's texture with a plt, and align the model with the helmet location. Then hope the helm scaling settings in appearance.2da are accurate enough to make the new models look good in-game for the different races/genders.

[virusman]

How do HaVFX solve the scaling issue?
Why plt texture?

[Failed.Bard]

Head aligned VFX use tga or dds files for texture mapping. All character parts use plt files.

Admittedly, being able to use plt mapping on vfx and creatures in the first would eliminate the need for a number of workarounds that have been thought up.

Modifié par Failed.Bard, 14 juillet 2012 - 07:40 .

[The Amethyst Dragon]

virusman wrote...

How do HaVFX solve the scaling issue?
Why plt texture?

Yes, body parts all use plt textures, which allow tinting in the toolset.  VFX use tga or dds, so their color is built in and not changable in the toolset.

Head aligned VFX solve the scaling issue by being pre-fit to head models, when the models are made.  Each such VFX is actually a set of 12 visual effects, one for each PC race and gender (half-elves use the human models)...so we use one for human males, one for human femals, one for dwarf males, etc.  It's a lot more work when making the models, but it means the VFX can align much more closely with the default heads.

Of course, this also means that:
a) a VFX isn't guaranteed to fit nicely with all head models for each race/gender (clipping)
you need a different set of 12 models (and 12 lines in visualeffects.2da) for every color variation you want available for use (that's where plt use in a VFX would be nice)
c) VFX alphas don't support shininess, only transparency (as far as I know)

[The Amethyst Dragon]

Failed.Bard wrote...
Admittedly, being able to use plt mapping on vfx and creatures in the first would eliminate the need for a number of workarounds that have been thought up.

It is possible to use plt on creature models, but those models have to be altered to use a particular plt.  There are currently a few of these sort of models in the CEP (link to how they use these).

[virusman]

Currently open-face helmets use a single model that scales according to appearance.2da values. If it's not accurate enough, it might be possible to modify it to use multiple models when available.

Modifié par virusman, 14 juillet 2012 - 09:15 .

[Failed.Bard]

The Amethyst Dragon wrote...

Failed.Bard wrote...
Admittedly, being able to use plt mapping on vfx and creatures in the first would eliminate the need for a number of workarounds that have been thought up.

It is possible to use plt on creature models, but those models have to be altered to use a particular plt.  There are currently a few of these sort of models in the CEP (link to how they use these).

  Finally got around to taking a look at the tintable tail creatures in game, and the lack lack of displaying weapons is a huge drawback to that method.
  That's not even taking into account that the method for setting the colours makes them less dynamic than an option where the colours could be set in toolset. Admittedly, the colours can be set by variable in toolset then applied on spawn, but as far as workarounds go I'd put it below my robes tests, and those aren't overly promising either.

  Really, just an internal switch to where it checks plt >> dds >> tga for all model types, using the highest priority type found, would be the ideal solution.  Then you could do all sorts of extra things not easily done now.

[The Amethyst Dragon]

Failed.Bard wrote...
Really, just an internal switch to where it checks plt >> dds >> tga for all model types, using the highest priority type found, would be the ideal solution.  Then you could do all sorts of extra things not easily done now.

Definitely would be great.  Would make for even more variety without having to make all new models to go with new plts.

[The Amethyst Dragon]

virusman,

I've downloaded NWNCX version 0.2.5 several times now, and every time I open the .rar archive, winrar spits out a "diagnostic error" report, telling me about an unexpected end of the archive.

When decompressing the content, almost everything comes out fine, except the patch/vpatchprompt.exe, which it tells me is a corrupt file.

Since the patcher from the 0.2.4 version works (and appears identical in date and file size) and it just seems to be a change in one or two of the .dll files, I've been able to use the 0.2.5 changes (I was able to do the testing with the helms yesterday).

Just thought I'd let you know. I don't know if anyone else is having the same problem.

Modifié par The Amethyst Dragon, 16 juillet 2012 - 04:03 .

[Failed.Bard]

Have you tried extracting it using 7-zip, TAD? That's what I'd used when I downloaded it.

[MerricksDad]

WinRAR 3.9.3 had no issues with 0.2.5 for me.
Also just wanted to say thanks to Amethyst Dragon for writing up some stuff for me to view on how to use this, and a very special thanks to virusman for making it possible. I got out of doing NWN work 6 years ago because what I wanted to do was either impossible or extremely time consuming and not worth the effort. Between this and OldTimeRadio's tutorial on plt+tga on the same model, I can now do just about everything I ever wanted! Now, as soon as the nwvault validates my posts I can start posting all my models and conversions. Thanks again

[MerricksDad]

I'd like a little kick to wrap my mind around these changes a bit, and here's what I see from my perspective. If I want to add beams, and because we have a 'range' in the engine from 600 to 700 noninclusive, that then means we have only a possibility of 99 beam animations total? Same with envmaps from 101 to 199, yes? And what is the internal limit on weapon vfx lines?

[virusman]

Yes, it's 100 lines per ProgFX type. If this limit ever becomes a problem, I can assign other number ranges.
Weapon VFX are limited to 255 FX types.

Modifié par virusman, 16 juillet 2012 - 02:16 .

[MerricksDad]

Not that I need more yet, but if somebody collects up a butt-ton of useful envmaps and texture covers, it might be nice to have another digit there. Not sure exactly what you are tinkering with, but it seems like the engine could be recoded to start with 0 and increment in the 1000's instead of 100 and increment 100. I do have a tendency to mass produce stuff when I get rolling But again, no need yet, and if the weapon vfx system can't support my 200+ vfx I need to convert, I'll get back with you. Again thanks a ton for this change.

[virusman]

Changing it this way would break compatibility with the original 2da.
By the way, I just checked and edited my previous post: weapon VFX are limited to 255.
Maximum ProgFX value is 65535. Everything above 1400 is unassigned.

[MerricksDad]

ok so 255 weapon vfx, I can live with that.
I hadn't thought about the needs of the original game when I mentioned that...
good news on the progFX. So I assume we could have another range coded into the engine, say 6000-7000 for 999 more beams, at some point. Not that such is needed, but hypothetically yes? or would it affect the code less to simply use 1400-1500 for another beam set? And is the engine reading strings out of the beam 2da or otherwise limited to 255 currently? Not sure why I am even talking about this yet as NWNCX is too new to be messing with 100+ beams, but its a fantastic proposal.

[virusman]

Yes, we can assign hundreds or thousands to new vfx when it becomes necessary.

[MerricksDad]

I guess my only thought why I might ask this right now is maybe some numbers should be set aside early on to avoid ick later. It seems other graphic or effect limit has been requested lengthened at some point, and they started with more than 99 entries. While I haven't come up with models for 99 replacement effects yet, nor would anybody want to use all 99 of my textures if I did, I can easily think of reasons to have nearly 100 models for just beams at this very moment, even more for texture replacements. Not so much the envmaps personally, though I see its enormous potential.

Just in case anybody is interested in what I am getting at, here is a list of things Ive been working on since 2007:

1) Armor as robes + location models as accessories. For instance, you have robe 0-9 be nudes and undies. 10-20 might be clothes. 20-30 be actual robes. 30-40 fancy dress...50-60 light leather, 60's light chain, and so. Using the locational model parts, you could change just the bracer/gauntlet, necklace/pendant, boots, belt etc without changing a whole fleshed part. Using the info OldTimeRadio showed using TGA with PLT on the same model part, I can now go even further, having a non colorable portion, with a standardized portion. And now using NWNCX I could potentially switch out an entire model skin for another (shown in the video where the troll is made bloodied). Dungeon Siege 1 only had 4-5 base robes (per sex) that were textureable (not exactly how they did it but close). Even if you examine the models for Guild Wars 1 or even the newer TERA, you can easily see the base model is the same, just the applied texture and its transparency changes the overall look so much you don't see the lines anymore. To fully make use of that, lets say I have 10 models each of 10 different armor/clothing categories. If I want 10 textures I can put on each model, I then need 1000 total textures. So 1000 minus the base texture on each model is only 900 2da lines I would need. That's not including spell induced skins like bark/stone/diamond. I could easily reduce that number if I segregated content into mods, reusing the numbers in each mod for some other effect and changing all my scripts, and limiting armor types to specific mods, but not having to do that would be even better.

1.5) Bloodied hell! : I love the bloodied effect shown in the troll video, and after playing 4e, I really think the bloodied marker is an important use of texture replacement. I think every creature should have a bloodied visual, except where an actual model swap is warranted (hunched, limb missing, etc). But I do so hate the fade in fade out during model swaps. Its infuriating how much it takes you out of game immersion when your character goes faded blue just to change basic appearance. So lets say I have 100 creatures in a module that I would actually use during that module, I need then another 100 2da slots for texture replacement. But now think of 2-5 stages of color for people who might want to make monsters that power up or otherwise change color much like nintendo or capcom games of the 80's or even on the wii today (see donkey kong country or mario wii).

2) Long beautiful hair! : trying to find the best method for hair as a helmet, or even hair as a node (tried switching left shoulder up with good success rate). Hair needs a non-angular look to be best accepted now days. I strive for the hair you see in games like sims2 or newer, not this hair from 90's video games. Flowing, transparent-bounded textures is now the norm. I tried allowing the user to change their left shoulder (my hair node) model by using a mirror tool, or a comb, similar to how the sims does it. It was...ok. So now, how do I combine this with OF helmets and also make use of the transparency now available through TGA+PNG. (by the way I moved shoulder props to the bicep prop since they pretty much moved that way already and already looked goofy). I am actually thinking of trying hair as vfx! [adhd] Has anybody experimented with the monster nodes with placing hair, helmets or extra equipment? I personally think those nodes should be standardized on the player base to things like: back (to load equipment on your back), center chest (think iron man chest burst), at the feet (for making effects that touch the ground as part of the character). I know the base spell locations have a few spots, but variety is always good.

3) Beams to 4e and beyond: [rant] I dislike the limited ability to change and accept new things that I hear from a portion of the NWN community. "No no you gotta use only 3e and/or 3.5 stuff." I'd personally like to diversify the spell selection as well as racial and class abilities. If you look at how 4e spells are structured, you can easily see (at least until 10th level) what makes up a spell and why it fits its level. Using that as a base, Ive developed a ton of spells that could easily be patched into NWN. No they don't balance with 3e, but there is no reason to just keep using the base spells in the game just because they are ready made. This ability to make new beams opens a huge door that, at least for me, finishes a goal of making a huge array of energy beams, mixed type beams, and just wicked looking effects using the beam type as a base. I see absolutely no reason if one game has a spell effect that is sweet, that you cannot somehow port it over to DND and make it fit. DND isn't about fitting the books, its about creativity.[end rant] So we will probably need at least 99 beam slots for NWN in 2013-2014.

Sorry. If nobody can tell yet, I'm not into simple 2da and tile retexture changes. I need big big changes to keep me happy

[MerricksDad]

ok, found an issue (I think) with rays. If I import a ray into nwmax and then save it back out without changing anything, it seems to work fine. However, if I change the base name say from vim_cold to vim_cold001 and redirect the animation to the newly named base it crashes the engine. However, its not every time. Sometimes the ray animation plays. The beam having two arcs sends one high and one low on the first fire. On the second fire it usually crashes. Getting it to even work on the first fire is rare. I'm not sure what is up there, but I am still trying to track it down. Any input?