I noticed That after longer period of time like few hours it goes crazy. Like melts down. Hard to describe, it's like graphic stop from being drawn, can't click much, modules are showing big black square etc.
(it noticed that usually when i have SC2 minimized at the same time)
killing unit = the unit that killed the dying unit (triggering unit).
why you just don't use region? explanation is very poor. Hard to guess what you try to achieve with the wait etc.
if you mean that for 5 seconds after unit dies there's an area that will kill everything you need to make wait and move back action within the unit dies trigger. But it may also mess up when another unit dies in meantime.
then it also depends can region, point move when another unit dies in meantime, or should it crate another of those areas etc
So I started working with your region idea, but I can't get it to properly find the unit that enters the region now.
Here's the portion of the code that has it:
Attach means attach. What you currently doing is just creating region at current position of unit.
Also add EventUnit() != RegionGetAttachUnit(EventUnitRegion()) to your trigger to prevent unit triggering itself initially
EventUnit() = unit entering/leaving
RegionGetAttachUnit(EventUnitRegion()) = unit to which region is attached
so initially first time this unit enters the region since it's in middle of it.
Just check the map. In triggers click Data -> View Script if you prefer galaxy
there is easily missable search box when choosing function.
For functions with return, create local variable of given type, click it's value and search, all listed will return this type.
There's no list as it's fairly sorted already by categories
I got confused at what you wrote, can you comment on what each variable does?
How I understood: first I get variable count parts, which is like max units hp/200; then I got confused what is current parts variable and part*x calculation... what is x? Anything else I quite got :) Thanks!
current parts would be global int variable holding last index of last health bar part dialog item (ofc per player/unit)
part*x was actually offset part*x where x would be offset X of image from left. For example first bar part would be at offset 0*20 = 20, another at 1*20=20, so they all position themselves right next to each other. Yes you would have to calculate offset from 'parts' amount and resize old ones or simply create another part of code to resize and reposition all bars. It's just one way of doing it, also i didn't put much effort into this, it was more of pseudo code.
EDIT: Actually now i realized it should not be shown when exist.
You could use my List <T> library if your familiar with it. Since dialog item is integer it would be a lot easier to add/remove and iterate thru them all.
It would be best to wait for HotS to come out, it will simplify things like this a lot.
How? You expect function like "Create health bar dialog with separate health blocks" ?
Whatever added will just provide more core functionality. Blocks for you to build from, not prebuilt structures.
I could build this and it would be not much larger than what i already typed here but in case like this i really don't feel to do someone's homework when he just neglects any suggested ideas.
No matter what problem you have to solve it you need to think in steps.
Identify the problem (or design)
Split it into basic steps. What should happen first from code perspective, what's next and so on.
Type it in code form step by step task after task.
The only limitation ever you can hit is if the language does not support something, but we are at stage were any language provides more than enough functionality to create anything, It's just matter of design.
Games on NES had such health bars and they didn't had "HotS"
I guess it's assumed you know the source unit because the event itself only allows for direct unit reference.
Otherwise you could try to pick all units around triggering unit and check is distance between triggering and picked == your trigger distance. This obviously could be inaccurate in rare scenarios.
Even though that is nothing that I want, I will probably use it, if no one really knows the good way to accomplish that. Thing is (I dunno if you're unable to understand or I fail at explaining, in which case I'm very sorry) - what if a unit suddenly gets another 200hp, and now has 6 bars instead of 5? The solution you said counts % of HP per bar, and I need flat amount, PLUS fit them all in a fixed width.
I know some programming, but I just can't find the right events/actions.
concept is similar, it would just require some additional dynamic check and setup, something like:
count parts: simply by max hp / 200 rounded up
WHILE: (current parts amount < parts)
IF: bar[current parts amount] == no dialog item
create new image ... at offset part*x
save last dialog item as bar[part]
ELSE: set show bar[part]
modify current parts amount + 1
while (current parts amount > parts)
hide bar[current parts amount]
modify current parts amount -1
Something like that, it would probably require some tweaks. After this you go into setting part where you first set up width of each bar up to 'bar[current parts amount]' to dialog (width / current parts amount) and then check the health and hide/show it in similar way i shown in my last code.
Thanks. But that seems like it changes the total width of the main health bar, doesn't it? I want the width to be the same, but to increase the amount of small bars in the big bar. Like that:
No it does not. It just hide/show given health block.
so at 60% it will be [###__] and at 100% [#####]
you can simply put some background image behind the area of bar
0
Or just use my N's Talent System :p
0
I noticed That after longer period of time like few hours it goes crazy. Like melts down. Hard to describe, it's like graphic stop from being drawn, can't click much, modules are showing big black square etc.
(it noticed that usually when i have SC2 minimized at the same time)
0
killing unit = the unit that killed the dying unit (triggering unit).
why you just don't use region? explanation is very poor. Hard to guess what you try to achieve with the wait etc.
if you mean that for 5 seconds after unit dies there's an area that will kill everything you need to make wait and move back action within the unit dies trigger. But it may also mess up when another unit dies in meantime. then it also depends can region, point move when another unit dies in meantime, or should it crate another of those areas etc
0
You checked the map i attached earlier?
Attach means attach. What you currently doing is just creating region at current position of unit.
Also add EventUnit() != RegionGetAttachUnit(EventUnitRegion()) to your trigger to prevent unit triggering itself initially
Just check the map. In triggers click Data -> View Script if you prefer galaxy
0
there is easily missable search box when choosing function. For functions with return, create local variable of given type, click it's value and search, all listed will return this type.
There's no list as it's fairly sorted already by categories
0
i don't understand what moving a unit have to do with attaching region to it. Attached is attached. it moves with unit.
just add some unit filter condition to trigger to exclude missiles and other crap.
0
you could attach new region to created unit, add simple unit enters region event and use 'Unit attached to trigerring region'
see the map
0
where did you get those numbers? :p
3 / 5 = 0.6 so mod = 6
11 / 5 = 2.2 so mod = 2
14 / 5 = 2.8 so mod = 8
1337 / 666 = 2.00(750) so mod = 00(750)
or is not how it works ? :p
EDIT: actually it does not. lol and i thought it works that way.
0
here, i made it just for sake of it. The visual part is basic tho
both versions.
Second uses my List <T> so you need to get familiar with it
in my sig or libraries section
(sigs are by default shown only in first post per thread)
0
current parts would be global int variable holding last index of last health bar part dialog item (ofc per player/unit)
part*x was actually offset part*x where x would be offset X of image from left. For example first bar part would be at offset 0*20 = 20, another at 1*20=20, so they all position themselves right next to each other. Yes you would have to calculate offset from 'parts' amount and resize old ones or simply create another part of code to resize and reposition all bars. It's just one way of doing it, also i didn't put much effort into this, it was more of pseudo code.
EDIT: Actually now i realized it should not be shown when exist.
You could use my List <T> library if your familiar with it. Since dialog item is integer it would be a lot easier to add/remove and iterate thru them all.
0
How? You expect function like "Create health bar dialog with separate health blocks" ?
Whatever added will just provide more core functionality. Blocks for you to build from, not prebuilt structures.
I could build this and it would be not much larger than what i already typed here but in case like this i really don't feel to do someone's homework when he just neglects any suggested ideas.
No matter what problem you have to solve it you need to think in steps.
The only limitation ever you can hit is if the language does not support something, but we are at stage were any language provides more than enough functionality to create anything, It's just matter of design.
Games on NES had such health bars and they didn't had "HotS"
0
I guess it's assumed you know the source unit because the event itself only allows for direct unit reference.
Otherwise you could try to pick all units around triggering unit and check is distance between triggering and picked == your trigger distance. This obviously could be inaccurate in rare scenarios.
0
concept is similar, it would just require some additional dynamic check and setup, something like:
Something like that, it would probably require some tweaks. After this you go into setting part where you first set up width of each bar up to 'bar[current parts amount]' to dialog (width / current parts amount) and then check the health and hide/show it in similar way i shown in my last code.
The only limitation is initial bar[] array size
0
you can detect 'triggering effect point' and use Destroy effects action
0
No it does not. It just hide/show given health block.
so at 60% it will be
[###__]
and at 100%[#####]
you can simply put some background image behind the area of bar