Last time I tried the beam VFX, I think NWMax was exporting a broken model. I had to edit the vaules manually.
NWNCX Suggestion - open "hard coded" visual effects to modification/addition
Débuté par
The Amethyst Dragon
, juin 04 2012 07:26
Retour en haut
#77
Posté 16 juillet 2012 - 11:45
OldTimeRadio
-
- Members
- 1 400 messages
Same experience here. I had had this problem before (years ago) and I switched to the Bioware Aura export scripts running under Max 5, where I had no problem. Unfortunately, somehow my Max 5 installation went poof...literally. Just gone. I think it happend when updating another version of Max. Which is major suck, BTW. So I can't go back and just export one now. However, at some point if nobody can get it done I have a couple of that type of emitter which I did export and save off. I'd have to find them to do a comparison. Not entirely sure where I put them though.
The way I look at it, an emitter is basically a constructor, in this case with a fx_ref target. Anyway, my general line of thinking was that the problem was probably because of NWMax either exporting blank values or not exporting them, whatever is the opposite of what it does now. That was my guess at the time.
NWMax is really closely based on the Bioware Aura scripts when whatever it was wasn't contained in the .DLL. The emitter stuff wasn't in the DLLs, which was just AABB and some unused NURBS code, IIRC. So there's probably some little tweak that needs to happen, not a big fix. Just not sure what that tweak is, at the moment.
Sometimes, compiling the VFX was necessary to keep it from crashing. Velmar or someone mentioned this and I had it happen to me, too. Will run 100% of the time perfectly if pre-compiled but will crash or crash some percent of the time if left as ASCII and compiled at run time.
Hope that's useful.
The way I look at it, an emitter is basically a constructor, in this case with a fx_ref target. Anyway, my general line of thinking was that the problem was probably because of NWMax either exporting blank values or not exporting them, whatever is the opposite of what it does now. That was my guess at the time.
NWMax is really closely based on the Bioware Aura scripts when whatever it was wasn't contained in the .DLL. The emitter stuff wasn't in the DLLs, which was just AABB and some unused NURBS code, IIRC. So there's probably some little tweak that needs to happen, not a big fix. Just not sure what that tweak is, at the moment.
Sometimes, compiling the VFX was necessary to keep it from crashing. Velmar or someone mentioned this and I had it happen to me, too. Will run 100% of the time perfectly if pre-compiled but will crash or crash some percent of the time if left as ASCII and compiled at run time.
Hope that's useful.
#78
Posté 17 juillet 2012 - 12:00
virusman
-
- Members
- 282 messages
Does anyone have the original Bioware export scripts? The Vault page just points to the nonexistent NWN site.
Modifié par virusman, 17 juillet 2012 - 12:01 .
#80
Posté 17 juillet 2012 - 02:24
MerricksDad
-
- Members
- 1 608 messages
ok tried compiled, same deal. Ran a comparison on a few exported files and there seems to be some differences in orientation and floating point accuracy. However if you manually set them to be duplicate files in notepad++ they still crash. If you copy the original file and paste it over what you manually made exactly the same, its no crash. Figure that one out. Sometimes when I set alternate textures instead of using fxpa_white, the animation plays but the rays go behind me to point 0,0. On the next use its a total self-shutdown.
I also noticed there is sometimes a pause or jerk before the actual beam graphics play. Beam graphics and hand graphics seem to be attached but play AFTER target hit graphics. Its at the point where the beam is calculated that I think something goes wrong. This may be the floating point accuracy difference. It may also be the color floats for all I know.
One thing I don't understand is why the direction of the beam goes screwy and points to 0,0. This happens when targeting objects or creatures.
I also noticed there is sometimes a pause or jerk before the actual beam graphics play. Beam graphics and hand graphics seem to be attached but play AFTER target hit graphics. Its at the point where the beam is calculated that I think something goes wrong. This may be the floating point accuracy difference. It may also be the color floats for all I know.
One thing I don't understand is why the direction of the beam goes screwy and points to 0,0. This happens when targeting objects or creatures.
#81
Posté 17 juillet 2012 - 03:25
OldTimeRadio
-
- Members
- 1 400 messages
Ah, here we go. I really hope this works for you. I managed to pull up my notes on lightning and I think this is essentially what we're talking about:
That's all I got for now. Give that a whirl, possibly in a text editor. I'm hip deep in skin mesh ATM, can you (or anyone else) post back here if that works for you?Clicking on the lightning emitter itself breaks the emitter.
Can click on the REF no problem
Birthrate MUST be nine. Just clicking on the Emitter changes the birthrate from 8 to 2. Apparently on lightning, the only way to get it to work is that the birthrate MUST be 9.
However, subdivisions plays into this. Apparently, if you have something like 12 subdivisions, the birthrate changes to 33 and that's apparently fine.
Is there some ratio that needs to be upheld?
#82
Posté 17 juillet 2012 - 01:14
MerricksDad
-
- Members
- 1 608 messages
It doesn't fit the bill of what's in the base files. The birthrate is what creates the subdivisions, but its a bit off. If you select 3, you only see 2. If you select 33, its a little less. The numbers 1, 5 and 10 always crash for me. I've not found any evidence to suggest that simply clicking an element in gmax changes anything on the panel or in the saved mdl. The only changes I did see were in floating point accuracy and that the first entry in orientation is set to 1 instead of 0. It may just be a simple mistake in their math functions, and would also explain the delay before the beam fx are fired, and in the targeting of point 0,0.
I was also thinking that using some trailing emitters would be a better maker for beams. Use a projectile that goes directly to target. So far I cannot even come close to making NWN make beams anything similar to diablo 3, but with projectiles I bet it would be easy. Back in 2007 I made a very good looking Aganazzar's Scorcher. Unfortunately I lost most of my files when I moved to this machine.
I was also thinking that using some trailing emitters would be a better maker for beams. Use a projectile that goes directly to target. So far I cannot even come close to making NWN make beams anything similar to diablo 3, but with projectiles I bet it would be easy. Back in 2007 I made a very good looking Aganazzar's Scorcher. Unfortunately I lost most of my files when I moved to this machine.
#83
Posté 17 juillet 2012 - 05:32
OldTimeRadio
-
- Members
- 1 400 messages
Hrm. MD, can you do me a favor? Make an emitter in NWMax and set the birthrate to something...say 10. Your choice as long as it's something other than 2, and probably higher than 2. Go up in the emitter properties and change it from whatever the default is to "Lightning". Now, scroll down and check out the birthrate again.
Did it change to 2? Mine changes it to 2. That's in my GMax install with NWMax. When I'm actually modding I use a heavilybutchered customized version of NWMax Plus so NWMax seems like a good common ground for testing this behavior.
My head is full of skin mesh/UV mapping nonsense at the moment so I want to be clear: We are not able to get a replacement beam effect out of NWMax at the moment using the workflow that should produce a beam as beam-y as all the non-flamelash beams, correct? From my experience a year+ ago, some types of emitters which should be possible to create in NWMax, aren't. I may be incorrect in holding that opinion but when I dropped down to the Bioware Aura scripts I recall everything being much more robust though obviously less elegant.
BTW, I think your emitter idea sounds wonderful. I dunno about beams as dynamic as the Diablo 3 ones, though, but one of the great things about this game is you can usually hack something into the rough shape you want.
Did it change to 2? Mine changes it to 2. That's in my GMax install with NWMax. When I'm actually modding I use a heavily
My head is full of skin mesh/UV mapping nonsense at the moment so I want to be clear: We are not able to get a replacement beam effect out of NWMax at the moment using the workflow that should produce a beam as beam-y as all the non-flamelash beams, correct? From my experience a year+ ago, some types of emitters which should be possible to create in NWMax, aren't. I may be incorrect in holding that opinion but when I dropped down to the Bioware Aura scripts I recall everything being much more robust though obviously less elegant.
BTW, I think your emitter idea sounds wonderful. I dunno about beams as dynamic as the Diablo 3 ones, though, but one of the great things about this game is you can usually hack something into the rough shape you want.
#84
Posté 17 juillet 2012 - 06:02
OldTimeRadio
-
- Members
- 1 400 messages
BTW, I'm not saying this is the case but you can't always count on a decompiled model to accurately reflect what is in a compiled model. This only crops up in the very tiniest sliver of cases, but you can use NWN Explorer Reborn 1.63's "Raw Model"/"Raw Model Hierarchy" (and sometimes "Binary") tabs (they're at the bottom of the window) to potentially get a clearer view of what's actually going on in the model. Either if you suspect that it is not being decompiled correctly or to make sure your settings were compiled correctly.
There are only a handfull of modders who would ever need to inspect things that closely, though.
There are only a handfull of modders who would ever need to inspect things that closely, though.
#85
Posté 17 juillet 2012 - 09:28
MerricksDad
-
- Members
- 1 608 messages
Woot! Offline today so I wasn't able to take your approach, but I worked out a lot already
ok, here's some data on beams
birthrate = number of segments in a beam minus 1
most numbers in the birthrate field seem to cause the game to crash as soon as math is performed to make a beam.
I have found these birthrate numbers to be ok: 3, 9, 33; and these numbers are bad: 1, 5, 6, 12, 22. I didn't bother with too many more yet.
Some beams with bad birthrate numbers shoot the beam off in random directions on first use, usually toward (0,0), while others close the game in 3-5 seconds without warning.
<x>Start = affects near hands
<x>End = affects near target
where <x> is color, alpha, size
so you can make a beam wider or thinner at the hand or target, but you cannot make the beam shrink or grow in place without adding animation
beams cycle through what looks like a random 3d point path where each segment is angled from the other based on lightningRadius and lightningScale. Setting both to 0.1 makes a larger width beam much like the lightning bolt effect in diablo 3
to get a good active looking beam effect, you need at least 4-6 lightning emitters. I used a big blue one, a medium cyan one, and 4 small white ones to make a really nice lightningbolt. framerate and game speed was not affected during beam play
it may be beneficial to mix a beam and a projectile that zips right to the target to produce diablo 3's pulsing beams.
the closer you are to your target, the smaller segments will be, squishing your texture. Pick a texture that looks good large and small.
beam segments overlap by a percent. A 256px texture was shown to overlap about 8-16 pixels. I suggest either cropping the edges of your beam texture more than fxpa_white was cropped, and/or alpha the edges. Cropping too far makes blank spots between plates.
since transparent beam textures or alpha'd emisions overlap, I suggest pill shaped textures with all corners rounded off UNLESS you have ZERO lightningRadius and lightningScale values, in which case all you need is the percent cropping
lightning takes textures that run top to bottom like fxpa_white. I can find no way to rotate the texture during lightning
a lightning emitter NEEDS a reference node which MUST be parented by the emitter. If the reference node is missing or parented incorrectly, the game will crash usually in 3-5 seconds of attempting the beam.
beams can accept new textures generally without issues. See percent clipping comment above.
beams can use animated textures. Be sure to clip all images on the sprite sheet by the same percent.
It is very possible to make some wicked awesome beams, especially by stacking multiple beams of different colors, textures and lightningRadius and lightningScale. I need to find a reliable place to post some images, but I basically duplicated the diablo 3 lightning bolt effect
ok, here's some data on beams
birthrate = number of segments in a beam minus 1
most numbers in the birthrate field seem to cause the game to crash as soon as math is performed to make a beam.
I have found these birthrate numbers to be ok: 3, 9, 33; and these numbers are bad: 1, 5, 6, 12, 22. I didn't bother with too many more yet.
Some beams with bad birthrate numbers shoot the beam off in random directions on first use, usually toward (0,0), while others close the game in 3-5 seconds without warning.
<x>Start = affects near hands
<x>End = affects near target
where <x> is color, alpha, size
so you can make a beam wider or thinner at the hand or target, but you cannot make the beam shrink or grow in place without adding animation
beams cycle through what looks like a random 3d point path where each segment is angled from the other based on lightningRadius and lightningScale. Setting both to 0.1 makes a larger width beam much like the lightning bolt effect in diablo 3
to get a good active looking beam effect, you need at least 4-6 lightning emitters. I used a big blue one, a medium cyan one, and 4 small white ones to make a really nice lightningbolt. framerate and game speed was not affected during beam play
it may be beneficial to mix a beam and a projectile that zips right to the target to produce diablo 3's pulsing beams.
the closer you are to your target, the smaller segments will be, squishing your texture. Pick a texture that looks good large and small.
beam segments overlap by a percent. A 256px texture was shown to overlap about 8-16 pixels. I suggest either cropping the edges of your beam texture more than fxpa_white was cropped, and/or alpha the edges. Cropping too far makes blank spots between plates.
since transparent beam textures or alpha'd emisions overlap, I suggest pill shaped textures with all corners rounded off UNLESS you have ZERO lightningRadius and lightningScale values, in which case all you need is the percent cropping
lightning takes textures that run top to bottom like fxpa_white. I can find no way to rotate the texture during lightning
a lightning emitter NEEDS a reference node which MUST be parented by the emitter. If the reference node is missing or parented incorrectly, the game will crash usually in 3-5 seconds of attempting the beam.
beams can accept new textures generally without issues. See percent clipping comment above.
beams can use animated textures. Be sure to clip all images on the sprite sheet by the same percent.
It is very possible to make some wicked awesome beams, especially by stacking multiple beams of different colors, textures and lightningRadius and lightningScale. I need to find a reliable place to post some images, but I basically duplicated the diablo 3 lightning bolt effect
#86
Posté 17 juillet 2012 - 09:36
MerricksDad
-
- Members
- 1 608 messages
http://www.facebook....52200912&type=3
thats my new NWNCX public facebook album. I will add to it until I get a packet up for nwvault
thats my new NWNCX public facebook album. I will add to it until I get a packet up for nwvault
Modifié par MerricksDad, 17 juillet 2012 - 09:37 .
#87
Posté 17 juillet 2012 - 09:45
OldTimeRadio
-
- Members
- 1 400 messages
Looks very nice!
Are you actually making these in NWMax, though, or editing them in notepad? From what I'm seeing, if you're on the modifier tab (which you're going to be on if you're editing an emitter) and you select the emitter, your lightning/beam is instantly hosed. Only editing in a text editor to change the birthrate manually will fix it. Can you confirm?
Are you actually making these in NWMax, though, or editing them in notepad? From what I'm seeing, if you're on the modifier tab (which you're going to be on if you're editing an emitter) and you select the emitter, your lightning/beam is instantly hosed. Only editing in a text editor to change the birthrate manually will fix it. Can you confirm?
#88
Posté 17 juillet 2012 - 10:12
MerricksDad
-
- Members
- 1 608 messages
These beams I am currently doing in notepad++ but I will be making my own beam software in the next few weeks. nwmax sucks for beams, and copy and paste in notepad is maddening with having to scroll way down and modify stuff all the time. Since its all tree structure, one of my old css tree scripts should be a good start for that program. I'll probably post it when its done, or at least the source.
So anyway, this is what I see: some beams import into nwmax and the birthrate is set to 2 even if you don't play with it. But for me not all of them do that. It may be because of my mods to nwmax. When I export anything from nwmax, a model is just as I had it except the model faces backwards, but if I understand correctly, that is actually something you can set in the import panel. And of course all integers are converted to ridiculous floats a fraction smaller than they need to be (why why why). I use a personally modified version of nwmax I modded when making 800+ tile tilesets with 4 variants of height and 8 types to choose from per edge. I modified nwmax so I could use it as a level editor because at 4 height variants, the toolset just doesn't understand you anymore. I also had to put in a lot of tweaks to work on my anatomy kit so nwmax would stop messing up my node weights. For all I know I put something in there to stop nwmax from messing with its own panel to complete a few of its rules.
So anyway, this is what I see: some beams import into nwmax and the birthrate is set to 2 even if you don't play with it. But for me not all of them do that. It may be because of my mods to nwmax. When I export anything from nwmax, a model is just as I had it except the model faces backwards, but if I understand correctly, that is actually something you can set in the import panel. And of course all integers are converted to ridiculous floats a fraction smaller than they need to be (why why why). I use a personally modified version of nwmax I modded when making 800+ tile tilesets with 4 variants of height and 8 types to choose from per edge. I modified nwmax so I could use it as a level editor because at 4 height variants, the toolset just doesn't understand you anymore. I also had to put in a lot of tweaks to work on my anatomy kit so nwmax would stop messing up my node weights. For all I know I put something in there to stop nwmax from messing with its own panel to complete a few of its rules.
#89
Posté 17 juillet 2012 - 10:36
virusman
-
- Members
- 282 messages
As I see, many of you have fixes and modifications for NWMax. Could you upload your code anywhere? I think everyone would benefit from that. Even if it's something you changed for yourself, others may find it useful.
Modifié par virusman, 17 juillet 2012 - 10:37 .
#90
Posté 17 juillet 2012 - 10:45
OldTimeRadio
-
- Members
- 1 400 messages
I don't actually have a fix for that yet. Currently it looks like it's just the birthrate that needs to be changed (to 9) but I'm looking over the code of aurora_helper_emitter.ms at the moment to make sure I need to make a change at all. I'll probably post something shortly. It may just be a workflow or it might be a couple of different solutions and let the modder pick.
Birthrate seems to be 2^lightningSubDiv + 1. Assuming someone tested this out at a point in time and it worked, I'm checking to make sure I just don't need some different workflow.
Gimme a few minutes. It looks like it might be just as easy to switch from Lightning type to some other type, then back.
Birthrate seems to be 2^lightningSubDiv + 1. Assuming someone tested this out at a point in time and it worked, I'm checking to make sure I just don't need some different workflow.
Gimme a few minutes. It looks like it might be just as easy to switch from Lightning type to some other type, then back.
#91
Posté 17 juillet 2012 - 11:10
MerricksDad
-
- Members
- 1 608 messages
Mine's undocumented right now but if I do make it more anybody-friendly, I'll put it up. Actually now that we're talking about it, maybe I should just mod the nwmax lightning crap....why didnt I think of that before? I'm much better at nwmax now than I was when I made the tileset and anatomy changes. Maybe I will just make a duplicator and modifier panel just for lightning?? Oh I could do a bit with a tool like that!
#92
Posté 17 juillet 2012 - 11:17
MerricksDad
-
- Members
- 1 608 messages
Modifié par MerricksDad, 17 juillet 2012 - 11:23 .
#93
Posté 17 juillet 2012 - 11:20
MerricksDad
-
- Members
- 1 608 messages
ok so lightning birthrate needs to be a binary number +1 then or is screws up?? that makes sense then why 3 9 and 33 are good. huh
oh and let me appologize now for turning this forum into a lets talk about lightning emitters forum
oh and let me appologize now for turning this forum into a lets talk about lightning emitters forum
Modifié par MerricksDad, 17 juillet 2012 - 11:22 .
#94
Posté 17 juillet 2012 - 11:30
OldTimeRadio
-
- Members
- 1 400 messages
@MerricksDad - Some useful information here, I believe. Also in the Omnibus.
Ok, just tried this on vim_rayodd and vim_raychain and it looks like regardless of subdivisions, NWMax is definitely borking the birthrate.
Solution(?) #1
If you do have an existing subdiv then change Lightning to Fountain, then back to Lightning.
If you do not have an existing subdiv then export the model and manually edit the birthrate to 9.
Solution(?) #2
OR you can also edit your aurora_helper_emitter.ms and change the line:
EmitParticlesRollout.spn_birthrate.enabled = false
to
EmitParticlesRollout.spn_birthrate.enabled = true
This will prevent the birthrate spinner from being grayed out when you select Lightning. However, if there is a subdivision it will only calculate the birthrate when the type is switched to Lighting from, say, Fountain.
Since emitters are basically open ended, either of those solutions could cause problems. Those are quick and dirty. These have just been tested as a placeable but they should work as replacment beams as well. I have to shuffle through my damned executables to find the right one to test with.
Ok, just tried this on vim_rayodd and vim_raychain and it looks like regardless of subdivisions, NWMax is definitely borking the birthrate.
Solution(?) #1
If you do have an existing subdiv then change Lightning to Fountain, then back to Lightning.
If you do not have an existing subdiv then export the model and manually edit the birthrate to 9.
Solution(?) #2
OR you can also edit your aurora_helper_emitter.ms and change the line:
EmitParticlesRollout.spn_birthrate.enabled = false
to
EmitParticlesRollout.spn_birthrate.enabled = true
This will prevent the birthrate spinner from being grayed out when you select Lightning. However, if there is a subdivision it will only calculate the birthrate when the type is switched to Lighting from, say, Fountain.
Since emitters are basically open ended, either of those solutions could cause problems. Those are quick and dirty. These have just been tested as a placeable but they should work as replacment beams as well. I have to shuffle through my damned executables to find the right one to test with.
Modifié par OldTimeRadio, 17 juillet 2012 - 11:32 .
#95
Posté 17 juillet 2012 - 11:46
MerricksDad
-
- Members
- 1 608 messages
Ok, just tried this on vim_rayodd and vim_raychain and it looks like regardless of subdivisions, NWMax is definitely borking the birthrate.
ok so the original nwmax emitter helper is having an issue with updating the value on the birthrate spinner because that spinner is disabled when lightning is enabled. the export script also does not calculate on the fly like it should and exports the lightningsubdiv entry and value instead, which I have to just assume NWN does not understand. So really the only thing needing changed is maybe the export script and to force it to recalc lightning birthrates on export.
One thing I forgot to mention is that NWN does not give a crap what the model base is named. I could name it jimbob01 and save it as vim_rayodd01 and make an entry for it and it works. I can also reuse vim_rayodd for its name and it will not override or otherwise screw up the original vim_rayodd if either are used at the same time.
I'm going to lose net for a few hours, but this is a great time to try a fire ray or finish my cold rays. Later guys
#97
Posté 18 juillet 2012 - 04:59
OldTimeRadio
-
- Members
- 1 400 messages
Hot damn! I was right. (kisses his notes)
Here is the beam model I used, my visualeffects.2da and the vfx_beams.2da from my testing:
There's nothing particularly special in that download. I took a beam and slowly, slowly stripped parts away and then tested every little change and it turned out what I mentioned in my notes from a year ago was exactly what was going on. Man I miss the Bioware export scripts when it comes to creating VFX. Oh well.
If your existing beam has lightning with subdivisions then, after you've entered your subdivisions, change the Update type from Lightning to Fountain (or something else), then back to Lightning. This should correctly update your birthrate. Keep an eye on it, obviously.
If your existing beam has lightning without subdivisions, manually edit the file in a text editor and change the birthrate to 9.
Important: These issues have far less to do with beams than how NWMax handles lightning. It's basically a coincidence (IMO) that these two things that NWMax is buggy about happen to be the two things beams are usually made of. I don't think beams have to be lightning at all. I believe Flame Lash is an example of this.
I need to play around with this a bit more to see if there are any other rough patches. There's an Emitter Archive rollout in Vel's Tools which will probably be a nice way to get out base emitters to people showing different "base" beams. So if you're hot to play with this, get Vel's Tools installed and we could swap goodies with each other pretty easily.
Here's a bezier beam. It's not lightning at all, but uses fountain updates instead. It has no such problems that require editing the birthrate or subdivisions or any of that because those are specific to lightning.
Whoops, a subdivision/birthrate thingie might have snuck in there. Definitely none below:
Here is the beam model I used, my visualeffects.2da and the vfx_beams.2da from my testing:
There's nothing particularly special in that download. I took a beam and slowly, slowly stripped parts away and then tested every little change and it turned out what I mentioned in my notes from a year ago was exactly what was going on. Man I miss the Bioware export scripts when it comes to creating VFX. Oh well.
If your existing beam has lightning with subdivisions then, after you've entered your subdivisions, change the Update type from Lightning to Fountain (or something else), then back to Lightning. This should correctly update your birthrate. Keep an eye on it, obviously.
If your existing beam has lightning without subdivisions, manually edit the file in a text editor and change the birthrate to 9.
Important: These issues have far less to do with beams than how NWMax handles lightning. It's basically a coincidence (IMO) that these two things that NWMax is buggy about happen to be the two things beams are usually made of. I don't think beams have to be lightning at all. I believe Flame Lash is an example of this.
I need to play around with this a bit more to see if there are any other rough patches. There's an Emitter Archive rollout in Vel's Tools which will probably be a nice way to get out base emitters to people showing different "base" beams. So if you're hot to play with this, get Vel's Tools installed and we could swap goodies with each other pretty easily.
Here's a bezier beam. It's not lightning at all, but uses fountain updates instead. It has no such problems that require editing the birthrate or subdivisions or any of that because those are specific to lightning.
Whoops, a subdivision/birthrate thingie might have snuck in there. Definitely none below:
Modifié par OldTimeRadio, 18 juillet 2012 - 05:40 .
#98
Posté 18 juillet 2012 - 11:01
MerricksDad
-
- Members
- 1 608 messages
Absolutely LOVE the new "more cow beam"! I am assuming that's also not a beam, but a fountain? My next step was to see if beams could use models instead of textures like other vfx. One thing I see lightning has over fountain beams is the lightningScale which sets the segments to variant lengths. Setting it to 1.0 seems to make the segment scale from 0 to 100% of its original size while 0 makes it always 100% of its size and looks blocky. See your "extremely simple" beam for blockiness. I don't believe we could duplicate the lightningScale effect with the bezier beam, but that is not to say the bezier beam is not a great starting point too, and one that does not need NWNCX.
So I was testing the binary numbers again last night. 0 really makes 0: the animation plays with 0 segments and does not crash. Didn't try 2 (2^0+1). 3 works fine especially for custom beam textures with stringiness in them and a high lightningScale. 5 is similar. 9 is good so long as the scale is also set higher, or the texture is not trans. 17 is getting better for electricity. 33 seems best for electricity and could use any lightningScale over about 0.2 and at least 0.1-0.5 lightningRadius. 65 is just overkill so I won't go any further, but there is no reason you couldn't and use a tiny round texture or maybe chain or a crystal and make it look good. Chain, now there is an idea I think diablo 3 already did. "Get over here!"
Ok so today, yes, testing model input in the texture field because for one fire beam I want a swirling circle intermittently around the length of the beam so I need something to orbit the particle. I'm pretty sure it would be easier to use an outside particle than try to animate lightning segments...
And about veltools. I have it installed but the emitter save and load is totally broken. Save never enables and load gives an error about being unable to convert a cone angle animator to a subanim, or something like that. I really need to get the omnibus package downloaded so I can just omniboogle this stuff.
So I was testing the binary numbers again last night. 0 really makes 0: the animation plays with 0 segments and does not crash. Didn't try 2 (2^0+1). 3 works fine especially for custom beam textures with stringiness in them and a high lightningScale. 5 is similar. 9 is good so long as the scale is also set higher, or the texture is not trans. 17 is getting better for electricity. 33 seems best for electricity and could use any lightningScale over about 0.2 and at least 0.1-0.5 lightningRadius. 65 is just overkill so I won't go any further, but there is no reason you couldn't and use a tiny round texture or maybe chain or a crystal and make it look good. Chain, now there is an idea I think diablo 3 already did. "Get over here!"
Ok so today, yes, testing model input in the texture field because for one fire beam I want a swirling circle intermittently around the length of the beam so I need something to orbit the particle. I'm pretty sure it would be easier to use an outside particle than try to animate lightning segments...
And about veltools. I have it installed but the emitter save and load is totally broken. Save never enables and load gives an error about being unable to convert a cone angle animator to a subanim, or something like that. I really need to get the omnibus package downloaded so I can just omniboogle this stuff.
#99
Posté 18 juillet 2012 - 01:07
MerricksDad
-
- Members
- 1 608 messages
Running into potential problem, but something probably easily fixable. beam 15 no matter what I do also casts a magic missile and often crashes. I counted the beam effects in NWscript and there are 20, so I think there are some other hardcoded beams in the machine we should determine first before adding to the beams.2da. The only one I am having issues with so far is 15, so progfx 615. I'm going to dig a bit and see if there is documentation on any off numbered beams around.
#100
Posté 18 juillet 2012 - 02:25
OldTimeRadio
-
- Members
- 1 400 messages
Do you mean beam 15 as listed in the vfx_beams.2da? I haven't seen that problem here yet, if that's what you're talking about.
Modifié par OldTimeRadio, 18 juillet 2012 - 02:47 .
