Wc3C.net

Wc3C.net (http://www.wc3c.net/forums.php)
-   vJass Spells (http://www.wc3c.net/forumdisplay.php?f=647)
-   -   Overgrowth (http://www.wc3c.net/showthread.php?t=104647)

FriendlyPsycho 02-21-2009 10:01 AM

Overgrowth
 
4 Attachment(s)
Zoom (requires log in)
Overgrowth
version: 1.05

Spell Information:
  • Overgrowth
  • Summons an overgrowth of vines and roots which entangles the target enemy unit and bounces on to other enemies. Entangle lasts 4 seconds, deals damage per second and prevents movement and attacking. Overgrowth can bounce infinitely as long as there's at least one target not entangled.
    • Level 1: Deals 12 damage per second
    • Level 2: Deals 24 damage per second
    • Level 3: Deals 36 damage per second

The above libraries are included in the map, but updates to them might come in the future so be sure to update as well. They are all available at Wc3c's Resource section.


I've included the code here in this post in case that a person wants to view it immediately without WE.
Expand JASS:

Changelog


=== v1.05 ===
- Optimized code a bit
- No longer uses EventTargetLib
=== v1.04 ===
- Inlined TimedXefx
- No longer uses TimedXefx as a separate library
=== v1.03 ===
- No longer uses GroupEnumUnitsInArea
=== v1.02 ===
- Used xecast in a more efficient manner
- Optimized the code in doing so a bit
- Renamed a modified version of TimedEffects into TimedXefx to prevent failure in maps which used TimedEffects
- The issue stated above has been addressed
- Added a Duration() constant
- Recoded how you configure the effects. Should be pretty versatile now.
=== v1.01 ===
- Included documentations
- Now picks the nearest target instead of a random unit within range
- Cleaned the spell code a bit, a few optimizations
- No longer uses a dummy unit for effects
- Now requires TimedEffects (Uses an unofficial, modified version)
- Now requires xefx
- Now requires GroupGet
=== v1.00 ===
- Initial release



Please feel free to comment and report bugs. Thank you very much for your time!

sephra 02-21-2009 01:57 PM

nice spell i like it. +rep and credits

The Grey Knight 02-21-2009 03:37 PM

hum, isnt there a similar spell in ToB vO?

Tekal 02-21-2009 03:41 PM

Looks pretty big....and laggy

FriendlyPsycho 02-21-2009 04:45 PM

You can't judge a spell by it's screenshot :P It works fast, clean and efficient.

Quote:

Originally Posted by The Grey Knight
hum, isnt there a similar spell in ToB vO?


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.

FriendlyPsycho 02-22-2009 12:38 AM

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.

FriendlyPsycho 02-22-2009 02:11 AM

Ah grand idea, thanks! I'll try to do some newb editing, hopefully it would turn out well.

Anitarf 02-22-2009 11:24 AM

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.

FriendlyPsycho 02-22-2009 11:45 AM

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.

Anitarf 02-22-2009 12:33 PM

Quote:

Originally Posted by FriendlyPsycho
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,.

Or you could use a timed effects library. Creating units is a lot less efficient than creating effects.

Quote:

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.
This is no high level math, I'm just talking about squaring both sides of the equation to get rid of the SquareRoot call.

Quote:

5.) The size of the "projectiles" are scalable. You just need to modify it in Object Editor, it's the roots dummy unit.
I was talking about the triggered "size", the 50 distance units at which the projectile hits the target.

FriendlyPsycho 02-22-2009 12:41 PM

Quote:

Originally Posted by Anitarf
Or you could use a timed effects library. Creating units is a lot less efficient than creating effects.


Hmm, fair enough.

Quote:

Originally Posted by Anitarf
This is no high level math, I'm just talking about squaring both sides of the equation to get rid of the SquareRoot call.


Oh I must have misunderstood, now I understand. Will fix that right away!

Quote:

Originally Posted by Anitarf
I was talking about the triggered "size", the 50 distance units at which the projectile hits the target.


Ah yes yes yes the hard-coded collision size, I'll get to that too.

FriendlyPsycho 02-22-2009 01:41 PM

UPDATED

Now conforms to all of Anitarf's requests.

Anitarf 02-22-2009 09:06 PM

Quote:

Originally Posted by Litany
Effects can only be displayed at their default orientation. He should keep units and randomize their facing.

That's a good point. This justifies using units.

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.

FriendlyPsycho 02-23-2009 01:46 AM

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.

xombie 02-23-2009 04:22 AM

I have a suggestion, if I may?

FriendlyPsycho 02-23-2009 04:27 AM

I see no reason not to.

erwtenpeller 03-04-2009 12:13 PM

Callahans roots have a fuckload of polygons though... Way, way too many for practical use in warcraft three, especially when used repeatedly.

Viikuna- 03-04-2009 08:11 PM

Using images instead of effects/units is pretty nice also because images cant cover units, which makes it look more clean and clear and everything.

erwtenpeller 03-04-2009 11:11 PM

Everything in the game is a model, basically. If you put an image on a plane, it'd still go through stuff.

What you mean is a splat or ubersplat, a texture superimposed over the terrain texture wich has the same in-game qualities as the terrain texture.

Anitarf 03-15-2009 04:24 PM

I take issue with your use of resources that haven't gone through our approval process yet. I am refering to GroupEnumUnitsInArea and your modification of TimedEffects in particular. TimedEffects is especially problematic because you kept the library name which would break any map that tries to use it along any spells that require the original. That was really the wrong thing to do.

The quickest solution is to inline the code into the spell, both libraries are very short and especially GroupEnumUnitsInArea gets considerably shortened once inlined into a GroupEnum filter.

Also, you create and destroy an xecast object for each spell instance individually, yet you store it in a global variable, making your spell not multi-instanceable. Also, you don't seem to use xecast's recycledelay even though you're using a damage-over-time spell.

Flame_Phoenix 03-28-2009 03:36 PM

1 Attachment(s)
This leaks ....

Please fix it.

Other than that I believe it would be a very nice unbalanced channeling spell =P

Pyrogasm 03-29-2009 12:12 PM

Well that was descriptive, Flame. xD What exactly is leaking?

Flame_Phoenix 03-29-2009 01:04 PM

1 Attachment(s)
Quote:

Well that was descriptive, Flame. xD What exactly is leaking?
I posted the replay; seriously you will only lose a few minutes of your life to find it out....

*sight* Arrghghhhh *sight*

Maybe this image will make it easier for you ...

Attachment 41708

How's that for descriptive now? xD

Anitarf 03-29-2009 03:03 PM

That error message doesn't mean it leaks.

FriendlyPsycho 03-29-2009 04:19 PM

First post being updated. Sorry for the long absence, but this now conforms to what you mentioned Anitarf. Although, I do disagree on the fact that I should exclude the GroupEnumUnitsInArea library and just copy paste it inside the spell scope. That part, I did not do. I figured that people might find it handy, and some people may already have the library in their maps so I'll just be adding worthless lines of code.

EDIT: Updated. Hope all is well now.

Anitarf 03-29-2009 05:07 PM

The point is that GroupEnumUnitsInArea is incredibly inline friendly, it would add a total of 6 lines of code to your spell (a globals block with two reals for coordinates, setting of those reals before a GroupEnum call and a IsUnitInRangeXY call in your enum function) not to mention that it'd be considerably more efficient that way.

Flame_Phoenix 03-29-2009 06:28 PM

Quote:

That error message doesn't mean it leaks.
So double type free is not a leak ?
Even if it is not a leak, it is something that should be fixed (I assume you agree with this statement).

Please fix it.

akolyt0r 03-29-2009 06:38 PM

most of the time the existence of a double free means that there is a leak somewhere aswell, but that is not true all the time ... (depends on the structure of the code.)

Pyrogasm 03-29-2009 11:53 PM

A double free is exactly the opposite of a leak. It's destroying the same object twice.

FriendlyPsycho 03-30-2009 04:26 AM

Updated, removed the use of GroupEnumUnitsInArea. Anything else to fix? I don't know what's causing that double free, but it's nothing map-breakingly huge of an issue.

akolyt0r 03-30-2009 05:09 AM

Quote:

Originally Posted by Pyrogasm
A double free is exactly the opposite of a leak. It's destroying the same object twice.

sure, but pretty often a double free means you most probably missed to destroy one object, but destroyed another one twice instead ...

So the first object will leak.
Havent looked at the code though ..so i dunno if this applies to your code aswell.

FriendlyPsycho 03-30-2009 05:22 AM

I don't get the double frees when I test it though..

Anitarf 03-31-2009 06:55 PM

Quote:

Originally Posted by Flame_Phoenix
Please fix it.

Update your xe, you nab.


As for the spell, TimedXefx is still an issue. It hasn't yet gone through our review process yet so you can't use it in a spell you submit here. Since it's such a simple library, I'll review it right now: The struct data is useless, you could have just as well attached the xefx to the timer directly. The end result is such a short code that you could just as well inline it into the spell entirely and thus avoid me telling you again that you can't use it.

Also, you should remove the earlier versions of the spell from the post since only the last version will actually be the one to be approved.

Flame_Phoenix 03-31-2009 08:16 PM

Quote:

Update your xe, you nab.
Actually if you bother enough to see my replay and my screen, you will notice that I got the "double free message" using the test map provided by the creator. I tested the most recent version (at that time) and so I assume that the demo map had the most recent xe (at that time). If anyone has to update something, that someone is not me, but the creator in the demo map, because the error was found in the test map.
On the other hand, if you don't care about that problem, than it is also not my problem as well. The fact is that (at that time) I got an error message I didn't like and I reported in a friendly way. By ignoring my report you risk your credibility as a mod, because if someone tests this spell in the future and if the tester finds the problem again, the tester will think that Anitarf is a nab mod because he approved a spell with a problem.
I see the version was updated, I am happy by that, I didn't test the latest version yet, so I can not say if the problem was fixed or not. I will just remove myself from this thread, I can obviously see my reports are not welcome here.

Btw, Thx to ako for the explanation of the error. I would give you rep++ but it looks like I have to spread some more rep =S

Anitarf 03-31-2009 09:02 PM

Quote:

Originally Posted by Flame_Phoenix
Actually if you bother enough to see my replay and my screen, you will notice that I got the "double free message" using the test map provided by the creator. I tested the most recent version (at that time) and so I assume that the demo map had the most recent xe (at that time). If anyone has to update something, that someone is not me, but the creator in the demo map, because the error was found in the test map.

I know what a double free error is so I didn't really need to look at any screenshots or replays to know what was going on.

Quote:

On the other hand, if you don't care about that problem, than it is also not my problem as well. The fact is that (at that time) I got an error message I didn't like and I reported in a friendly way. By ignoring my report you risk your credibility as a mod, because if someone tests this spell in the future and if the tester finds the problem again, the tester will think that Anitarf is a nab mod because he approved a spell with a problem.
You didn't consider the possibility that I tested the map before assuming the error was on your side. Apparently, the xe in the spell map (or maybe the spell itself, I don't know and don't care enough to bother finding out) was updated between our tests and this led to the misunderstanding.

FriendlyPsycho 04-01-2009 04:04 AM

Quote:

Originally Posted by Anitarf
As for the spell, TimedXefx is still an issue. It hasn't yet gone through our review process yet so you can't use it in a spell you submit here. Since it's such a simple library, I'll review it right now: The struct data is useless, you could have just as well attached the xefx to the timer directly. The end result is such a short code that you could just as well inline it into the spell entirely and thus avoid me telling you again that you can't use it.


Right'o, I'll optimize the library. Should I submit it as another resource instead, might come in handy for those who want to use xefx but are stuck with TimedEffects, or maybe should I just tack in the code with moyack's TimedEffects thread?

Again, I'm sorry if this bothers you, but I kinda disagree with inlining it. What if someone wants to use two variations of it? Even though inlining only takes up very few lines, it is still redundant code, and I might as well just use a library for added modularity.

Anitarf 04-01-2009 04:25 AM

As I said, you should inline it. It's not much of a library once you write it correctly, and it wouldn't get approved as such. Modularity is all nice and good for coding but when it comes to the end user having a ton of libraries in the map can be a pain.

FriendlyPsycho 04-01-2009 04:36 AM

Ah, now I see your point.

Updated! Sorry for making your job any harder by trying to prove some of my points. My bad :P

Anitarf 04-03-2009 02:10 AM

Just a few minor issues remaining:
  • There already is a max collision size constant in xebasic, no need to have another one in your spell.
  • You should use a local trigger variable instead of the GUI global, so users don't have to get the trigger name exactly right.
  • tx and ty could have been local variables instead of struct members, which are a bit less efficient.
  • The same is true for the .a member, like tx and ty you calculate it in loopfunc every time so there's no need to store it.
  • With that in mind, the EventTargetLib is kind of unneeded since the only thing it shortened in the spell code was the angle calculation.
  • You forgot to include a IsUnitInRangeXY check in the enum function.
  • You never use temploc. I assume you meant to use it for the IsUnitInRange check but you could just reuse the GG_Distance's members for that instead.

FriendlyPsycho 04-03-2009 04:20 AM

1.) Ok done.
2.) What GUI global? The gg_trg thing? Well, it is created anyways so I just used that.
3.) Done.
4.) Done.
5.) Removed usage.
6.) Um I don't need to? Pretty sure about that..
7.) Oops, forgot to clean that up heh. Done.

First post/spell updated to conform to the aforementioned stuff.


All times are GMT. The time now is 09:53 PM.

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services