8 réponses à ce sujet

[Rolo Kipp]

 <wishing he knew...>

Well, isn't *that* a fine how-do-you-do? Imported the a_da supermodel (from the HotU Patch) for use in the TaVFX templates...

That's two impact nodes attached to the torso. In different places.
Which one is correct? Might this not cause odd behavior in game?

Incidently, the OC a_da has only one impact node... but no cloak or belt/kilt goodness.

I need a vacation... :-P

<...the juicy-fruit twins>

[Pstemarie]

Only should be one - the engine will probably either consolidate them into one or ignore both and use torso_g as if it were the impact node.

[OldTimeRadio]

Just a guess: The position of the impact node from the p-model is what's being used.

[OldTimeRadio]

Speaking of impact node oddities, if you hadn't run into the issue before, there are rotation keys on the a_ba impact node that should have been fixed in 1.68 but were missed.  This came up again in a thread a year ago.  I identified the issue in the track view editor and then fixed it as carefully as possible.  Same work I think NWC_SNAKE did, but I went out of my way to be surgical about the fix.  Maybe he did too, I dunno.  The test module I allude to can be found here.

Everything seemed to work well for him but there may yet be other issues.

Modifié par OldTimeRadio, 13 juillet 2012 - 12:32 .

[Rolo Kipp]

<digging up old news...>

Just a note here, my Mounted Familiar VFX work a treat...except when they suddenly twist over onto the right arm.

So I suspect I'll have to bundle the above corrected a_ba model in the hak. Which might have repercussions if someone has a custom a_ba they want to use with Mounted Familiars :-P

<...under two new moons>

[OldTimeRadio]

New home (for the moment) here.  Another casualty of the FileFront file hosting change.  It's been a year or something, if anyone has problems with this drop me a PM to let me know.  Never did get any complaints and at least three people have used this specific file to solve their issues so if I don't get any contrary indications, I'll get it onto the Vault.

Modifié par OldTimeRadio, 19 janvier 2013 - 04:11 .

[Rolo Kipp]

<considering...>

So, opinions please:
Would it be better to include the bug-fixed a_ba model in projects that rely on the bug fix or to provide a link to the bug fix as a separate project?

Edit: In either case, credit to NWSnake & OTR will be given.

I'm leaning toward making the system self-contained, but I do abhor bloated haks...

<...redundancy>

Modifié par Rolo Kipp, 19 janvier 2013 - 04:27 .

[henesua]

provide a link. I think that is the most user friendly option.

i suspect that cep uses a different a_ba, and I know that q does.

perhaps documentation explaining the a_ba situation. and/or instructions on how to merge the fix using notepad?

i've got a similar merge issue with my project, as you know. my philosophy with this sort of thing is to be as low impact as possible with common resources because overriding common resources might be problematic for other users, and thus convince them that my project is buggy. not everyone reads the notes on the package, and so a Q user could be surprised to lose the Q goodies for example.

Modifié par henesua, 19 janvier 2013 - 04:40 .

[Rolo Kipp]

<rolling and rerolling...>

Verified that Q is safe.

Edit: I only checked to see if there were extraneous keys on the impact node.  I don't know if there are specific improvements to Q's a_ba. But I believe Pstemarie removed extraneous keys from all the dummies except rootdummy and lforearm.

CEP 2.4 has an a_ba_tav and an a_ba_coat, but no a_ba that I could find with a search through NWExplorer.

So now I'm leaning to providing instructions (uggh) and links for OTR's override and Project Q.

<...very long scrolls>

Modifié par Rolo Kipp, 19 janvier 2013 - 05:18 .