Quote from varkarrus:
Hi. I have 2 attributes that each work fairly well. One increases a unit's attack by one for every attribute of that it has, and the other is supposed to multiply that unit's attack. The second one doesn't really work though.
What I want is Actual attack power = (Base attack + First attribute)*(1+0.3*Second Attribute).
However, it is giving me
Actual attack power = (Base attack*(1+0.3*second attribute)+First attribute)
Any ideas?
First Attribute
Modification - Damage Dealt (Unscaled) - Melee 1 : Range 1
Second Attribute
Modification - Damage Dealt Fraction - Melee 1.3 : Range 1.3
Or is that what you did? Haven't tested this out.
Should it be Damage Dealt (Scaled)? To be honest, I don't know the difference, but I always sort of assumed that Unscaled damage wouldn't be affected by the fractional modifier, while scaled damage would be!
Use the "Pick Each Unit in Unit Group Matching Condition" function. The Unit Group would be "Units in Region."
Then use "Picked Unit" function to reference the unit.
For instance, if I wanted to heal all of the units in the region, I'd use the Pick Each Unit function and apply the action "Set (Picked Unit) Life Perfect to 100"
Events
Unit - Any Unit Enters BottomLeft-Combination-In
Local Variables
Conditions
(Number of Living units in (Any units in BottomLeft-Combination-In owned by player 1 matching Excluded: Missile, Dead, Hidden, with at most 2)) == 2
(Unit type of (Triggering unit)) == Zealot
Actions
Unit - Kill (Triggering unit)
Unit - Create 1 BigZealot for player (Triggering player) at (Center of BottomLeft-Combination-Out) using default facing (No Options)
1 unit does =/..And for a couple of reasons, I can't do 'kill units in region'.
A) in case other units are in the region waiting to be a bigzealot or something or
B) someone finds the bug, and runs the first zealot out, saving however many minerals.
Again, thanks a lot for the help guys
Yeah, the "Units Matching Condition" doesn't work like it used to so I was confused when I recommended it (they changed how it functioned from War3 and to be honest the old functionality was WAY better).
The function you should try is "Find Units"
"Instance" maps would be a great way to do PvP. I know World PvP was mentioned, but it would be great to have a PvP instance i.e. a battleground, where teams of high level characters and go face to face with specific objectives and such. WoW meets DotA!
Second, even if XML data is encrypted, there is still potential for abuse. Unless the game automatically saves an XML every time an item or money is transfered, I can make a game, give my money to a friend, leave without saving, and then he can save. I can reload and I have all of my money back but my friend still has my money too. I'm not sure if saving after every transaction is feasible, and even if it is, the user can presumably copy the XML file and rename it, so that even if you overwrite the first XML after he gives away his money, he can just put the other XML back in. I know it's just a game, but given the scope of this project, I would give some thought regarding whether there is any way to prevent this.
Finally, on the issue of "instances" and maps specifically for higher leveled characters, I think it may be best overall not to make leveling up a huge grind in this game. Take a lesson from Guild Wars, where reaching level 20 and getting good gear was not difficult, but there were still plenty of things to unlock and tons of content to explore once you got there. It was very good for keeping players on equal footing, and allowing players even with vastly different amounts of time spent in the game to enjoy content together. I think one of the popular WarCraft 3 ORPGs did this. They basically had a single map for "leveling up" with a vast diversity of encounters available, and then made dozens of maps for maximum level characters to enjoy. If you are worried about "level up" content becoming unpopular, I feel that the key is in not making the "level up" content too lengthy. Just my two cents.
Yup. First, in the Data Editor, go to Behaviors, and create a new behavior of the type "Buff."
Let's pretend, for this example, that I want to make a buff that doubles damage. So I find the "Modification - Damage Dealt (Fraction)" field and set them all to 2. One other thing we need to do is give the buff a very short duration (how about .2 seconds). If the buff is not "reapplied" before this duration ends, it will drop.
Now, we want an effect that will add this behavior to a unit. Very easy to do! Go to Effects, make a new one of the "Apply Behavior" type and add the buff we just created to the "Behavior" field.
Now, we need an effect that will use the effect we just created to all allied targets in range. An effect like this is known as a "Search Area" type, so go ahead and create a new effect of this type. We need to set the Arc to 360, the Maximum Count to "-1" (which means no maximum). The radius to whatever we want. Go down a bit and find "Search Filters." This is important. Select the checkboxes that say "Player" and "Ally" so that the Search Area does not pick out enemy units and buff them. Then, go through the filters and disable anything that doesn't belong (for instance, Dead, though it probably doesn't matter in this case since the buff won't really have any effect on a Dead unit). You could disable Structure if you don't want the tower buffing things like Missile Turrets. Now we need to add an effect to the search. The effect is the "Apply Behavior" that we just created before.
Now, we need a behavior that will periodically invoke the Search effect we just used. Go back to behaviors, make another "Buff" and find "Period." Set this to .1 or so. It has to be less than .2, or the buff will drop from units before the tower reapplies it. The period count should be "-1" (which again means unlimited - it never stops searching). For "Effect - Periodic" set the Search effect we just created.
Finally, add this Behavior to the Sensor tower.
If we read this from bottom to top, what we have is that the Sensor Tower has a behavior which causes it to Search for friendly targets within radius of 3, every .1 seconds. All of the targets it finds are given a behavior. The given behavior lasts .2 seconds and doubles their damage. That's just what we wanted!
It's not a straight-forward process, but the beauty of it is that we have control over EVERY step of the process. Want to change the buff to do something weird like make units invisible but only when they are on creep? We can do that. Want to change the aura so that it only affects flying units? We can do that. The list goes on... The point is that the data editor is difficult to learn, but highly rewarding. Good luck! =)
However, I just made the weapon for him, and it's working fine, except there's no impact (blood, etc.) animation! It also upgrades fine now after editing the Zerg Missile Upgrades. The only thing missing is the impact animation (blood coming out of organic target, etc.), and I don't know how to fix that one.
That stuff is also handled by an actor.
Suppose I wanted to change the impact effect of the Hydralisk air attack, as an example.
I open the data editor and notice that there is an actor called "Hydralisk Air Attack." Let's look at it.
The events field shows two different events that can cause this actor to be created, "Effect.Bogus.Start" and "Effect.HydraliskAir.Start". "Bogus" is an effect that doesn't exist in the data editor. It's either campaign data or antiquated (you can find lots of examples of campaign data being referenced in actors. For instance, the Hydralisk unit actor has events that relate to his "Lurker Morph" ability which is presumably in the campaign data.) The fact that this effect doesn't exist in the beta is not cause for alarm because it won't break the actor, that event will simply never be called.
This is an "Action" actor which is really handy. The nice thing about Action actors is that you can specify sounds or models to occur at the launch site or the impact site. In this case, we want blood! But wait, we don't want blood every time the missile hits something. Who ever heard of a bleeding Mothership?! So, we use "Impact Map - Model Reaction." The reaction means that the creation of the model "reacts" depending on what got hit.
Let's open it up. They have fields for "Dirt" "Flesh" "Light Armor" etc. Most of these have generic "HydraliskAirAttackImpactReactionDirt(Unknown)."
This is reference, again, to data that doesn't actually exist. Most likely, it's all there just to accomodate future graphics engines improvements (if they were to add an effect for the hydralisk hitting Dirt, they could do a simple Find-and-Replace on the string "HydraliskAirAttackImpactReactionDirt")
However, one reaction in particular references data that actually exists. The "Flesh" reaction is "Blood Target Impact." As we would expect, this is a Model (go look it up if you want to see). And it makes the target bleed like we want.
I realize I didn't actually show you how to do anything, but hopefully by talking you through the Hydralisk attack and telling you how it makes it's blood will help you understand it enough so that you can look through the actors for your own attack and add the necessary stuff.
Unit models are considered "Actors" and the Actor's "Events" data field specifies what conditions cause the actor to come into being (among other things).
In most cases, "UnitBirth" is enough for the actor to appear. Units that are created, whether through ordinary means or through triggers, always send the "UnitBirth" event as a notification that the actor needs to appear. Actors are "destroyed" by a variety of events. I don't really understand most of them but I think the typical cause is "AnimDone.*.Missing"
This isn't the case with "Morph" abilities. Units that "Morph" apparently don't send a "UnitBirth" event, and they apparently don't do whatever it is that makes the actor delete itself either. What this mean is that a morphing unit just keeps it's original actor.
If you look at actor of units such as the Viking, they have seperate actors for each of their morphs. Each actor has events called "AbilMorph.*.Start" and "AbilMorph.*.Finish" And they have terms that check the name of the ability, so when a unit starts casting the Fighter mode morph, the Viking Fighter Actor is deleted. When it is finished, the Viking Assault actor is created. And vice versa.
As for the model which appears in between the morph beginning and ending, some other actor must be responsible, but I can't find it. If you are morphing a Ghost into a Dark Templar though, you probably don't have a suitable model for the transition. You should either make the morph instant, or change the events so that the new actor is created at the same time the existing actor is deleted (probably at the end of the morph).
I looked around a bit and found out more.
The Hydralisk Actor has some entries it's Events field which use the event:
"WeaponStart.*.AttackStart"
Both of them check the units animation, and each one sets a timer (the timer duration varies depending on the animation the hydralisk used).
Just below them is a an event for "Timer Expires" which checks the name of the timer and then creates another actor called "HydraliskMeleeAttackLaunch." If you look up this Actor, it's a sound actor, and the associated Sound data is probably what you are hearing.
So if you want to change the sound of the hydralisk's attack, just change the actor that is created by the "Timer Expires" event. The great thing about this is because the timer is starting according to the animation which played, the sound effects should still "line up" with the hydralisk's animations.
I'm not accustomed to Actors creating other actors, but I realize this is frequently the case with Sounds. Not so much with Models (I have more experience with the latter). This is why the information I gave earlier was not entirely correct.
Right now the intention is overhead camera. Since the Command skill allows players to potentially control multiple units (and the infected players may be able to control the Zerg units in some fashion) the standard RTS view is ideal.
There will be mechanics that are inspired by 3rd person games and utilize new capabilities of the StarCraft 2 editor. For instance, the data editor allows one to specify "Detection Arc" and "Radar Arc" which I will likely be taking advantage of. Basically, units will only be able to detect hidden enemies if they are in front of them (of course, the range at which they detect is related to their Perception attribute), and the biologist's "zerg radar" will likely follow this principle as well.
Well, I made their sight = 100, but that didn't change anything. Is that what you mean by giving them vision of the entire map? If I leave, they go back to their position they were told to attack. I have not tried SansRegret's suggestion of attacking a point instead yet, though.
Edit: No luck with Target Point either. They just go to that point and sit there. Is it possible to make a point move and follow a unit or something like that?
There is a hard-coded limit to unit sight (it's somewhere around 30). If you give them more than that, they will end up with a much smaller range in game (somewhere around 8, I think). Basically, increasing the sight beyond the limit causes it to revert to a default value.
So if you set the Zombie's sight to 100, it still probably can't see the target (let's also not forget that even if they were in sight range, there's no guarantee that their site isn't being blocked by cliffs or other obstacles).
Try using the "Auto-Reveal Region" action, and apply it to the entire map.
Create an actor with the effect in question, modify it's Events field and create an Event of the type "Effect," choose the Damage Effect of the zealot weapon, and add a "ValidatePlayer" term. Use a validator that returns true if the player possesses the upgrade (make one if you have to).
0
Should it be Damage Dealt (Scaled)? To be honest, I don't know the difference, but I always sort of assumed that Unscaled damage wouldn't be affected by the fractional modifier, while scaled damage would be!
0
Use the "Pick Each Unit in Unit Group Matching Condition" function. The Unit Group would be "Units in Region." Then use "Picked Unit" function to reference the unit.
For instance, if I wanted to heal all of the units in the region, I'd use the Pick Each Unit function and apply the action "Set (Picked Unit) Life Perfect to 100"
0
Yeah, the "Units Matching Condition" doesn't work like it used to so I was confused when I recommended it (they changed how it functioned from War3 and to be honest the old functionality was WAY better). The function you should try is "Find Units"
0
@MasterDinadan: Go
Okay, four things.
"Instance" maps would be a great way to do PvP. I know World PvP was mentioned, but it would be great to have a PvP instance i.e. a battleground, where teams of high level characters and go face to face with specific objectives and such. WoW meets DotA!
0
@NamesAreUseless: Go
I'm getting pretty good with Actors, Effects, and Behaviors. Let me know if you need any work like that for the project.
0
I have three things to say.
First, this looks great!
Second, even if XML data is encrypted, there is still potential for abuse. Unless the game automatically saves an XML every time an item or money is transfered, I can make a game, give my money to a friend, leave without saving, and then he can save. I can reload and I have all of my money back but my friend still has my money too. I'm not sure if saving after every transaction is feasible, and even if it is, the user can presumably copy the XML file and rename it, so that even if you overwrite the first XML after he gives away his money, he can just put the other XML back in. I know it's just a game, but given the scope of this project, I would give some thought regarding whether there is any way to prevent this.
Finally, on the issue of "instances" and maps specifically for higher leveled characters, I think it may be best overall not to make leveling up a huge grind in this game. Take a lesson from Guild Wars, where reaching level 20 and getting good gear was not difficult, but there were still plenty of things to unlock and tons of content to explore once you got there. It was very good for keeping players on equal footing, and allowing players even with vastly different amounts of time spent in the game to enjoy content together. I think one of the popular WarCraft 3 ORPGs did this. They basically had a single map for "leveling up" with a vast diversity of encounters available, and then made dozens of maps for maximum level characters to enjoy. If you are worried about "level up" content becoming unpopular, I feel that the key is in not making the "level up" content too lengthy. Just my two cents.
0
@SansRegreT: Go
There are Real functions called "X of Point" and "Y of Point" that do exactly this.
0
Yup. First, in the Data Editor, go to Behaviors, and create a new behavior of the type "Buff."
Let's pretend, for this example, that I want to make a buff that doubles damage. So I find the "Modification - Damage Dealt (Fraction)" field and set them all to 2. One other thing we need to do is give the buff a very short duration (how about .2 seconds). If the buff is not "reapplied" before this duration ends, it will drop.
Now, we want an effect that will add this behavior to a unit. Very easy to do! Go to Effects, make a new one of the "Apply Behavior" type and add the buff we just created to the "Behavior" field.
Now, we need an effect that will use the effect we just created to all allied targets in range. An effect like this is known as a "Search Area" type, so go ahead and create a new effect of this type. We need to set the Arc to 360, the Maximum Count to "-1" (which means no maximum). The radius to whatever we want. Go down a bit and find "Search Filters." This is important. Select the checkboxes that say "Player" and "Ally" so that the Search Area does not pick out enemy units and buff them. Then, go through the filters and disable anything that doesn't belong (for instance, Dead, though it probably doesn't matter in this case since the buff won't really have any effect on a Dead unit). You could disable Structure if you don't want the tower buffing things like Missile Turrets. Now we need to add an effect to the search. The effect is the "Apply Behavior" that we just created before.
Now, we need a behavior that will periodically invoke the Search effect we just used. Go back to behaviors, make another "Buff" and find "Period." Set this to .1 or so. It has to be less than .2, or the buff will drop from units before the tower reapplies it. The period count should be "-1" (which again means unlimited - it never stops searching). For "Effect - Periodic" set the Search effect we just created.
Finally, add this Behavior to the Sensor tower.
If we read this from bottom to top, what we have is that the Sensor Tower has a behavior which causes it to Search for friendly targets within radius of 3, every .1 seconds. All of the targets it finds are given a behavior. The given behavior lasts .2 seconds and doubles their damage. That's just what we wanted!
It's not a straight-forward process, but the beauty of it is that we have control over EVERY step of the process. Want to change the buff to do something weird like make units invisible but only when they are on creep? We can do that. Want to change the aura so that it only affects flying units? We can do that. The list goes on... The point is that the data editor is difficult to learn, but highly rewarding. Good luck! =)
0
That stuff is also handled by an actor. Suppose I wanted to change the impact effect of the Hydralisk air attack, as an example. I open the data editor and notice that there is an actor called "Hydralisk Air Attack." Let's look at it.
The events field shows two different events that can cause this actor to be created, "Effect.Bogus.Start" and "Effect.HydraliskAir.Start". "Bogus" is an effect that doesn't exist in the data editor. It's either campaign data or antiquated (you can find lots of examples of campaign data being referenced in actors. For instance, the Hydralisk unit actor has events that relate to his "Lurker Morph" ability which is presumably in the campaign data.) The fact that this effect doesn't exist in the beta is not cause for alarm because it won't break the actor, that event will simply never be called.
This is an "Action" actor which is really handy. The nice thing about Action actors is that you can specify sounds or models to occur at the launch site or the impact site. In this case, we want blood! But wait, we don't want blood every time the missile hits something. Who ever heard of a bleeding Mothership?! So, we use "Impact Map - Model Reaction." The reaction means that the creation of the model "reacts" depending on what got hit.
Let's open it up. They have fields for "Dirt" "Flesh" "Light Armor" etc. Most of these have generic "HydraliskAirAttackImpactReactionDirt(Unknown)."
This is reference, again, to data that doesn't actually exist. Most likely, it's all there just to accomodate future graphics engines improvements (if they were to add an effect for the hydralisk hitting Dirt, they could do a simple Find-and-Replace on the string "HydraliskAirAttackImpactReactionDirt")
However, one reaction in particular references data that actually exists. The "Flesh" reaction is "Blood Target Impact." As we would expect, this is a Model (go look it up if you want to see). And it makes the target bleed like we want.
I realize I didn't actually show you how to do anything, but hopefully by talking you through the Hydralisk attack and telling you how it makes it's blood will help you understand it enough so that you can look through the actors for your own attack and add the necessary stuff.
0
@Ripperlord: Go
Unit models are considered "Actors" and the Actor's "Events" data field specifies what conditions cause the actor to come into being (among other things). In most cases, "UnitBirth" is enough for the actor to appear. Units that are created, whether through ordinary means or through triggers, always send the "UnitBirth" event as a notification that the actor needs to appear. Actors are "destroyed" by a variety of events. I don't really understand most of them but I think the typical cause is "AnimDone.*.Missing"
This isn't the case with "Morph" abilities. Units that "Morph" apparently don't send a "UnitBirth" event, and they apparently don't do whatever it is that makes the actor delete itself either. What this mean is that a morphing unit just keeps it's original actor.
If you look at actor of units such as the Viking, they have seperate actors for each of their morphs. Each actor has events called "AbilMorph.*.Start" and "AbilMorph.*.Finish" And they have terms that check the name of the ability, so when a unit starts casting the Fighter mode morph, the Viking Fighter Actor is deleted. When it is finished, the Viking Assault actor is created. And vice versa.
As for the model which appears in between the morph beginning and ending, some other actor must be responsible, but I can't find it. If you are morphing a Ghost into a Dark Templar though, you probably don't have a suitable model for the transition. You should either make the morph instant, or change the events so that the new actor is created at the same time the existing actor is deleted (probably at the end of the morph).
0
I looked around a bit and found out more. The Hydralisk Actor has some entries it's Events field which use the event: "WeaponStart.*.AttackStart" Both of them check the units animation, and each one sets a timer (the timer duration varies depending on the animation the hydralisk used).
Just below them is a an event for "Timer Expires" which checks the name of the timer and then creates another actor called "HydraliskMeleeAttackLaunch." If you look up this Actor, it's a sound actor, and the associated Sound data is probably what you are hearing.
So if you want to change the sound of the hydralisk's attack, just change the actor that is created by the "Timer Expires" event. The great thing about this is because the timer is starting according to the animation which played, the sound effects should still "line up" with the hydralisk's animations.
I'm not accustomed to Actors creating other actors, but I realize this is frequently the case with Sounds. Not so much with Models (I have more experience with the latter). This is why the information I gave earlier was not entirely correct.
0
Make sure you give it a weapon.
0
@Adorielen: Go
Right now the intention is overhead camera. Since the Command skill allows players to potentially control multiple units (and the infected players may be able to control the Zerg units in some fashion) the standard RTS view is ideal. There will be mechanics that are inspired by 3rd person games and utilize new capabilities of the StarCraft 2 editor. For instance, the data editor allows one to specify "Detection Arc" and "Radar Arc" which I will likely be taking advantage of. Basically, units will only be able to detect hidden enemies if they are in front of them (of course, the range at which they detect is related to their Perception attribute), and the biologist's "zerg radar" will likely follow this principle as well.
0
There is a hard-coded limit to unit sight (it's somewhere around 30). If you give them more than that, they will end up with a much smaller range in game (somewhere around 8, I think). Basically, increasing the sight beyond the limit causes it to revert to a default value.
So if you set the Zombie's sight to 100, it still probably can't see the target (let's also not forget that even if they were in sight range, there's no guarantee that their site isn't being blocked by cliffs or other obstacles).
Try using the "Auto-Reveal Region" action, and apply it to the entire map.
0
Create an actor with the effect in question, modify it's Events field and create an Event of the type "Effect," choose the Damage Effect of the zealot weapon, and add a "ValidatePlayer" term. Use a validator that returns true if the player possesses the upgrade (make one if you have to).