| 02-21-2009, 12:57 PM | #2 |
nice spell i like it. +rep and credits |
| 02-21-2009, 02:37 PM | #3 |
hum, isnt there a similar spell in ToB vO? |
| 02-21-2009, 02:41 PM | #4 |
Looks pretty big....and laggy |
| 02-21-2009, 03:45 PM | #5 | |
You can't judge a spell by it's screenshot :P It works fast, clean and efficient. Quote:
Oh yeah I think it was called Kudzu. It used ubersplats and branches/forks to other targets, this spell only chains/bounces to other targets. |
| 02-21-2009, 11:38 PM | #6 |
Well you got a good point there, but I can't use images since that would be totally copying Kudzu and I know it's a hassle to code, at least in my perspective. If I could get a good roots/vine model that looks better, I'll update the aesthetics. In the meanwhile, entangling roots can suffice, to say the least. |
| 02-22-2009, 01:11 AM | #7 |
Ah grand idea, thanks! I'll try to do some newb editing, hopefully it would turn out well. |
| 02-22-2009, 10:24 AM | #8 |
You should note the spell requirements in the code comments as well as the post itself, and the requirements in the post should have links to resource threads. The code could also use a brief description of the spell. The spell should pick the nearest valid unit when selecting the next target instead of a random one. Why are you using units instead of effects for the wines? Don't use squareRoot, compare the squares instead since that's more efficient. The "size" of the projectile should be a calibrateable constant. d.tx and d.ty could have been local variables instead of struct members. Instead of using globals and GetFilterUnit in the target calibration function, you should use a wrapper to pass this information to the calibration function as parameters. It would be more efficient if you kept a static xecast in a private global variable instead of creating one every time. |
| 02-22-2009, 10:45 AM | #9 |
1.) Okay, I'll gladly update to include the requirements in the code's comments and link to them in the first post. 2.) I designed it to look for random units, but now that you've mentioned it I believe bouncing to the nearest target would be better. 3.) I use units so that I can just apply timed life to them, and effects would be a hassle since I'd have to create an array of them and check if their lifetime is up and destroy them, etc,. 4.) ..Hm? I don't seem to follow, I haven't taken up the higher levels of math and this is only formula I know to get the distance between two coordinates. Can you rewrite it for me instead? Thanks. 5.) The size of the "projectiles" are scalable. You just need to modify it in Object Editor, it's the roots dummy unit. 6.) Okay, I shall conform. 7.) Oops, forgot to clean that up. Thanks for reminding me, I will fix it. An update will be ready ASAP. |
| 02-22-2009, 11:33 AM | #10 | |||
Quote:
Quote:
Quote:
|
| 02-22-2009, 11:41 AM | #11 | |||
Quote:
Hmm, fair enough. Quote:
Oh I must have misunderstood, now I understand. Will fix that right away! Quote:
Ah yes yes yes the hard-coded collision size, I'll get to that too. |
| 02-22-2009, 12:41 PM | #12 |
UPDATED Now conforms to all of Anitarf's requests. |
| 02-22-2009, 08:06 PM | #13 | |
Quote:
In this case, since you're already using xecast, you should use xefx for the effects; that way, you can get random orientations for your effects while not needing an extra custom unit. |
| 02-23-2009, 12:46 AM | #14 |
Oh but I am using xefx ;) I also used it in conjunction with TimedEffects, but I modified TimedEffects to use xefx instead of effects directly. |
| 02-23-2009, 03:22 AM | #15 |
I have a suggestion, if I may? |
