Glad you understand Ajijang2013, good luck. Also sounds like a indexing issue.

 

Dude, how did you maintain the speed of the missle? Mine is everytime I cast the spell the head's speed is increasing as I cast the speed again and again.

 

Dat-C3, my spell got a problem when I cast the spell, when the the one head is travelling when the second head is arrived at it's destination.. the second orb removed and the first one is not. Why? can you help me or anyone can help me?

 

• -------- This creates the entire beam besides the front --------
• Unit - Create 1 Dummy for (Owner of kameu99[kameloop99]) at kamep facing (Angle from kamep to kamecastp99[kameloop99]) degrees
• Unit Group - Add (Last created unit) to kamegroup99[kameloop99]
• Special Effect - Create a special effect attached to the origin of (Last created unit) using kamemissilesfx
• Animation - Change (Last created unit)'s size to (kamesize[kameloop99]%, 100.00%, 100.00%) of its original size
• Animation - Change (Last created unit) flying height to 75.00 at 0.00

^I think you know what I wanna say here.

Spoiler

use varible!

Maybe you can think of a boolean in config that allows user to destroy trees with kamehameha. yes/no

I've also stated it in Haley's kamehameha. I think doing a condition to prevent passing it higher cliff levels would be cool. So it would immediatly exploode then.
(or configurable at least)

I dont think following is really needed in your deindex part:

• Set kamespeed[kameindex99] = 0.00
• Set kameplayer[kameindex99] = Neutral Passive

• -------- So the caster isn't stuck --------
• Unit - Order kameu99[kameloop99] to Stop

Could you explain, please? With this the unit will ignore the 1st move order, if user aborts casting.

Else I think code looks ok and clean. Might be useful.

 

Heh, thanks. =)

If you tell me the line of setting a real to current Z/terrain height then I might add something extra. otherwise I will make it so it doesn't fly around cliffs.

Edit: If you noticed, I tried to make a terri-bad indexing system for them dummies. Kind of failed however I don't want to use someone else's work for this. I might change my mind soon if I can't find a solution though.

 

The tooltip is so-so and could need an improvement.

• Set kamepickedu = No unit

move this line out of the ForGroup loop. Below this loop you use "last created unit" multiple times. Here you could use your the unit variable, because variable lookups are faster than function calls.

• Set kamespeed[kameindex99] = 0.00

This doesn't do anything.

• Set kameplayer[kameindex99] = Neutral Passive

Delete this line aswell.

• Custom script: if udg_kamegroup99[udg_kameindex99] == null then
• //......
• Custom script: set udg_kamegroup99[udg_kameindex99] = null

The first condition is always true because you null the group in the end. So it's a needless check.

 

I'll fix it either today or tomorrow, thanks.

EDIT: Time for the fixed version, hopefully it is approvable now. =) Let me know if you find anything else wrong with it.

 

Not very effective, I guess.

• -------- We do this to enable it to work better then 0.03 and to be more precise. --------
• Custom script: set udg_kametimer = 0.03125
• -------- This is how you can add events through GUI/Triggering --------
• Trigger - Add to kameloop <gen> the event (Time - Every kametimer seconds of game time)

Since you're using timer to run period trigger, you need to do this way:

• Countdown Timer - Start kametimer as a Repeating timer that will expire in Period seconds

instead of

• Trigger - Turn on kameloop <gen>

and

• Countdown Timer - Pause kametimer

imstead of

• Trigger - Turn off (This trigger)

I've test about this thing and I realize:
Timer keep running even I turned period trigger off.
This thing very hurt CPU and RAM you know, specifically is CPU, CPU keep high level when timer keep running. CPU Hot (Also drain more battery) => Performance decrease => Slow down computer. So it's very important thing. You really need to fix it.

If you want proof, just tell me.

Forgot something?

• Set kameorder99 = (Order(flare))

<=>

• (Distance between kamep and kamecastp99[kameloop99]) Greater than or equal to 20.00
• (Current order of kameu99[kameloop99]) Equal to (Order(flare))

This is unsafe.

• Unit - Set life of kamequickunit to (Real(kamedumdumindexer99))
  • Unit Group - Add kamequickunit to kamegroup99[kameloop99]
  • Special Effect - Create a special effect attached to the origin of kamequickunit using kamemissilesfx
  • Set kame2sfx99[(Integer((Life of kamequickunit)))] = (Last created special effect)

You really need to do another way instead of get Life of kamequickunit and put it as a index.

GUI version and this are the same.

• -------- Creating and setting the unit groups because the GUI version doesn't work correctly --------
• Custom script: set udg_kamegroup99[udg_kameindex99] = CreateGroup()

you're wrong about this

GUI version perfecly fine to use it, but keep it in mind, do not destroy it if you want to use it as a Entrie Unit Group.

GUI is more cooler I guess, because even it's destroyed, it still can be use as a normal group but it can ONLY be used for

• Unit Group - Pick every unit in Group and do (Actions)
  • Loop - Actions

Proof: Simply

hook

native

CreateGroup

, and then create a variable as UnitGroup.

• Set kamereal1 = (X of kamep2)
  • Custom script: call SetUnitX ( udg_kamedummyu99[udg_kameloop99] , udg_kamereal1 )
  • Set kamereal1 = (Y of kamep2)
  • Custom script: call SetUnitY ( udg_kamedummyu99[udg_kameloop99] , udg_kamereal1 )

=>

• Custom script: call SetUnitX ( udg_kamedummyu99[udg_kameloop99] , GetLocationX(kamep2))
• Custom script: call SetUnitY ( udg_kamedummyu99[udg_kameloop99] , GetLocationY(kamep2))

Don't get more useless space.

• Animation - Change kamequickunit's size to (kamesize[kameloop99]%, 100.00%, 100.00%) of its original size
  • Animation - Change kamequickunit flying height to 75.00 at 0.00

You can just simply do it via Object Unit Editor.

I think this can be used as a spell global variable

• Angle from kamep to kamecastp99[kameloop99])

since your dummy or some stuffs still created from a same angle.

• Custom script: call DestroyEffect(udg_kame2sfx99[R2I(GetUnitStateSwap(UNIT_STATE_LIFE, GetEnumUnit()))] )

Even this is unsafe, but use

GetUnitState

instead of

GetUnitStateSwap

..

Sorry, no offence

Although I named variable very bad >.<, but I still have a good variables presentation than your (Lower case, Upper case, etc..)
2/5

 

I'll see about it, sure give low ratings all you want. Only petty people care for that, I am submitting stuff to help the community as well people. Since there is not a single Kamehameha approved yet well... yeah.

Lil Note

Well I decided try my luck and use my courage to get at least one Kamehameha approved even if it disgraces me. =)

Thanks for the post I guess, hopefully someone can comment on this and see if your claims are correct.

Edit: Didn't want to say this however I barely understood your post, could you try editing it a bit?

For example the lower case and upper case variable presentation, what does that even mean?

Sure you can do flying height through object editor, but I believe in one dummy unit(Unless slowing down the animation of the effect) only so yeah about that in my opinion your wrong. Shouldn't rely on object editor functions, we did that years ago. Most of what you have said is rather wrong or just silly unless you can provide more evidence.

I was kind of testing unit life, I will see what I can do to fix that.

Almost forgot, try using a unit group array in GUI.

Edit2: Just tested timer vs every seconds and every seconds is faster, it doesn't run when turned off either because if it did then it would trigger the actions wouldn't it?

 

• -------- Finishing/explosion effects --------
• Special Effect - Create a special effect at kamep using kamefinaleffect
• Special Effect - Destroy (Last created special effect)
• Special Effect - Create a special effect at kamep using kamefinaleffect2
• Special Effect - Destroy (Last created special effect)

in every 0.03125 sec, you create sfx in a point you have leaks
so maybe you just use tempoint here hehehe

 

Nope

 

Ahaha, depending on you and you are throwing water in my face.

Yup!, timer is faster than trigger timer but it's not about faster or not . I just noticed you:

Replace:

• Trigger - Turn on kameloop <gen>

with

• Countdown Timer - Start kametimer as a Repeating timer that will expire in Period seconds

and this

• Trigger - Turn off (This trigger)

with this:

• Countdown Timer - Pause kametimer

Trigger doesn't run when it turned off, but

timer

keep running,

timer

just have a job is execute, system ordered

timer

to do that and never stop even run for nothing until

• Countdown Timer - Pause kametimer

is called!.

No, they gives you a rating for two reasons:

- Resources quality (Inclued presentation, code, performance, optimizer, etc..)
- Resources very pretty

You should care about the first one to improve your experience since you're trying to become a programmer .

You really should listen more to the opinions of others .

What do you mean anway?.

Why one dummy?, you can do that with all dummies you have!. Blizzard will do it for you than you do it manually .

Since I have told you about this thing!, is this your style?.

• Set kameu99[kameindex99] = (Triggering unit)

=>

• Set KM_Caster[KM_Index] = (Triggering unit)

• Set kameatktype = Spells

=>

• Set KM_ATTACK_TYPE = Spells

This will look more readable. Don't forget you're submiting this to the public .

 

opps im something wrong

i dont see your RemoveLocation( udg_kamep)
in front lol

in the end of your Loop Trigger lol
idk if two point leaks can be remove it easy by RemoveLocation( udg_kamep) same var

 

Well it is just you kind of did the same, I barely understood you and I really want to know what is right because we both know WC3 works a little different then everything else. Sorry, Should of said it better I suppose.

How did you find this out? Like I really want you to show me proof, I never noticed it. Does it use up more RAM because it isn't noticeable in-game. Not to mention no mod has told me this.

Well rating from people is different then rating from officials which is kind of true in the real world since you want your boss to like it or the person you made the code for instead of random people. . .
Not to mention not many people rate fairly on here including you. I documented every single little thing with tips and even some more instructions so nobody could go wrong without knowing something at least.
Lol that one was funny, since when did this matter for code-based resources? Sure it is a nice visual bonus, but I didn't know everyone was into gigantic visuals for spells because you don't want spells blocking the gameplay of peoples maps when they use your spell unless it is a cinematic or boss spell.

Yeah I do care, its more of I don't usually care for capitals, which is bad of me. I will consider changing it, so far yeah lot of people complain about my style of variable presentation... =)
Thanks again, I didn't mean to offend you. Really appreciate the help, it is just I can't believe the timer thing without like a way to test it or something... Could you get a Mod to agree with you?
I don't like it when people rate my stuff really low, but at least I am able to handle it and see what to do to improve. Constructive critcism I think it might be called?

More dummies means more work for the person who wants to use your spell. Unless I am slowing down the special effect of the dummy it is not needed.
The public could learn to read better... hehe =)

 

I agree that it doesn't stop the timer. PeriodicEvent still runs in background, but without evaluating the trigger.

how anyone could test it Create 2 triggers with same periodic event Let both trigger display a message Logically they both will always display thier message at same time. Now for the test turn off one of these triggers, and turn it on again after (any) time. You will recognize that even after the temporary <TurnedOff> status, the messages again will display at the exactly same time. So the reason for this is obviously that the timer in background was not stopped.

It's sure a small optimization to work with timer and pause/start, but I don't think it's really noticeable or really a big deal for a GUI-system.

 

Sorry about this. Just a habit, CPU goes with RAM, so I use both, just skip those things about RAM.

Sound like very funny!
Why do I have to go through them while it is only my own opinion?. Skip or not depending on you, not a big deal for me.

Let's force 6 timers run with 0.00 seconds to see the different.


CPU: 9.60

CPU: 5.86

As IcemanBo said, not a big deal for GUI-System.

 

I see, thank you.

 

This could be configurable.

• Special Effect - Create a special effect attached to the origin of kamedummyu99[kameindex99] using Abilities\Weapons\SpiritOfVengeanceMissile\SpiritOfVengeanceMissile.mdl

• Custom script: call DestroyEffect( udg_kame2sfx99[R2I(GetUnitStateSwap(UNIT_STATE_MAX_LIFE, GetEnumUnit()))] )

--> GetUnitStateSwap should be the function GetUnitState instead.

 

Will update it as soon as I can, thanks BPower.