Are you using the protoss pylon system in that map? It could be much easier to give all structures an energy field: then the ability will only have to check one validator.
Oh wait, stupid me. Ofc I don't need to save it... sorry. Just got scared of the number :D
Btw, can't figure out what does the "next" param of "CheckForCreep" function mean?
>> btw: i don't think checking 256*256 points for creep will cause any lag.
Maybe it won't, but I'll need some way to store the value for each point. And 256^2 = 65536. That's just crazy. The limit for an array lies much, much lower. That's not how the things should be done.
And this way we'll either lose at least a half of creep or get the same result as above, depending on how this loop works (it can copy the unit group or work with the original).
Ok heres an algo i came up with:
1). Take an emitter;
2). Check how many other emitters are in its spreading radius and the distance to them;
3). Use geometry to find the size of the figure made from a chord on which the other emitter lies and the arc of that horde;
4). Deduct it from the emitter's spreading area.
>_<
Problem is - that algo won't work for intersections of more than 2 zones of influence. And it's already too damn complicated to cause lag. #lifeispain
Maybe i'm not getting your idea. If I make a loop through all emitters and count their creep, the result will be the same as if I just counted the emitters. To get past this i'll need to prevent one cell from being counted twice, the question is how to do it.
>> i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
>> Count it just near active creep emitters.
Let's imagine a player got the idea how the creep is counted. Then he'll just place a lot of tumors in a safe place as close to each other as possible and the balance will be screwed up.
>> btw sounds interesting will this be a multiplayer map?
Hopefully
A bit better, but there's a problem: how to separate creep which belongs to different emitters?
The idea behind this was to make players spread creep by rewarding them proportionally to the covered area size.
Looks like i'm going to need a function that returns the amount of terrain cells currently covered by creep. Just counting the creep emitters won't work in my case, and checking each cell each time on a big map is going to make it unplayable. Any other ideas?
Well, that doesn't seem like a good idea, but you can force each unit to change color by actor messages. I've tried it once: made upgrades "black color", "Red color", etc, and used actor messages + validators to change units' colors. However, in that game I only had 2 colors and 4 possible units... In theroy, i can imagine doing such a system purely through data, but that would look quite weird.
>> BTW are you wanting to randomize the races in game or something but with certain requirements? Or could you use variant/s to accomplish your objective? E.g. every odd player is zerg, every even is terran in a variant. Or must the races be changeable in-game?
I ofc can make races freely selectable in lobby, but then i guess too many matches will be ruined by idiots or trolls who all select the same race. There must be a system to maintain balance (by triggers, which means that races must be changeable in-game), and variants don't seem to do what i need.
As far as I know these questions have nothing to do in data. All lobby things are defined in "Game variants". You can enable and disable colors there, as well as hardcore them to certain players.
Also there's a data type - "User interface data" in "advanced data" (hope they're called so in your locale). Might be useful to look there.
And finally, you can completely disable the classic color selection and make your own using "Player attributes" and triggers.
UPD: just bumped into another data thing. Advanced data > Data recordings > Default SC2 settings > Team colors. Hope that works.
2). There's an actor called FoliageFXCreepDevour. Clear its events and the creep shouldn't affect foliage anymore, at least in theory.
3). Validators are the most obvious solution. Make a validator that checks if target is not your unit type, then add it to all abilities.
>> Are you wanting to change the race of the UI?
Optionally - not only UI, but also notifications and other stuff. When you're building a turret as a terran and get a "mutation complete" notification... hell.
Will look through the tutorial, thx, but that method looks really weird to me.
P.S.: checked the mod out. It doesn't even change the buttons T_T Is that really all we can do?
P.P.S.: tried to change cursor via triggers, getting an "access denied" error 0_o
0
Are you using the protoss pylon system in that map? It could be much easier to give all structures an energy field: then the ability will only have to check one validator.
0
Set buried units a cargo value different from 0 i suppose.
0
Hmm, i'm not yet sure how this algo works, but looks like... it really does work. Thanks!
0
@FunkyUserName:
Oh wait, stupid me. Ofc I don't need to save it... sorry. Just got scared of the number :D
Btw, can't figure out what does the "next" param of "CheckForCreep" function mean?
0
>> btw: i don't think checking 256*256 points for creep will cause any lag.
Maybe it won't, but I'll need some way to store the value for each point. And 256^2 = 65536. That's just crazy. The limit for an array lies much, much lower. That's not how the things should be done.
0
@FunkyUserName:
And this way we'll either lose at least a half of creep or get the same result as above, depending on how this loop works (it can copy the unit group or work with the original).
Ok heres an algo i came up with:
1). Take an emitter;
2). Check how many other emitters are in its spreading radius and the distance to them;
3). Use geometry to find the size of the figure made from a chord on which the other emitter lies and the arc of that horde;
4). Deduct it from the emitter's spreading area.
>_<
Problem is - that algo won't work for intersections of more than 2 zones of influence. And it's already too damn complicated to cause lag. #lifeispain
0
@FunkyUserName:
Maybe i'm not getting your idea. If I make a loop through all emitters and count their creep, the result will be the same as if I just counted the emitters. To get past this i'll need to prevent one cell from being counted twice, the question is how to do it.
0
>> i don't think you can disinguish the "owner" of creep, but in most cases the closest emitter is also the owner. also the best algo would be to search in a circle around the emitter. first left, then top, then right then down then left +1 etc. (just came into my mind right now)
>> Count it just near active creep emitters.
Let's imagine a player got the idea how the creep is counted. Then he'll just place a lot of tumors in a safe place as close to each other as possible and the balance will be screwed up.
>> btw sounds interesting will this be a multiplayer map?
Hopefully
0
@FunkyUserName:
A bit better, but there's a problem: how to separate creep which belongs to different emitters?
The idea behind this was to make players spread creep by rewarding them proportionally to the covered area size.
0
Looks like i'm going to need a function that returns the amount of terrain cells currently covered by creep. Just counting the creep emitters won't work in my case, and checking each cell each time on a big map is going to make it unplayable. Any other ideas?
0
Well, that doesn't seem like a good idea, but you can force each unit to change color by actor messages. I've tried it once: made upgrades "black color", "Red color", etc, and used actor messages + validators to change units' colors. However, in that game I only had 2 colors and 4 possible units... In theroy, i can imagine doing such a system purely through data, but that would look quite weird.
0
>> BTW are you wanting to randomize the races in game or something but with certain requirements? Or could you use variant/s to accomplish your objective? E.g. every odd player is zerg, every even is terran in a variant. Or must the races be changeable in-game?
I ofc can make races freely selectable in lobby, but then i guess too many matches will be ruined by idiots or trolls who all select the same race. There must be a system to maintain balance (by triggers, which means that races must be changeable in-game), and variants don't seem to do what i need.
0
As far as I know these questions have nothing to do in data. All lobby things are defined in "Game variants". You can enable and disable colors there, as well as hardcore them to certain players.
Also there's a data type - "User interface data" in "advanced data" (hope they're called so in your locale). Might be useful to look there.
And finally, you can completely disable the classic color selection and make your own using "Player attributes" and triggers.
UPD: just bumped into another data thing. Advanced data > Data recordings > Default SC2 settings > Team colors. Hope that works.
0
2). There's an actor called FoliageFXCreepDevour. Clear its events and the creep shouldn't affect foliage anymore, at least in theory.
3). Validators are the most obvious solution. Make a validator that checks if target is not your unit type, then add it to all abilities.
0
>> Are you wanting to change the race of the UI?
Optionally - not only UI, but also notifications and other stuff. When you're building a turret as a terran and get a "mutation complete" notification... hell.
Will look through the tutorial, thx, but that method looks really weird to me.
P.S.: checked the mod out. It doesn't even change the buttons T_T Is that really all we can do?
P.P.S.: tried to change cursor via triggers, getting an "access denied" error 0_o