You'll likely need to make an event handler for a unit move command. Assuming for a moment the unit is always sliding towards the angle it's facing, your event handler might look something like this:
Event - Unit Is Issued Order - Move
Target Point = Target of Order - Triggering Unit - Index 0
Issue Order - Triggering Unit - Stop
Make Triggering Unit Face Angle over 0.3 seconds - Angle between points - Position of Triggering Unit - Target Point
That's a very simplified version of what I've done for ice physics in my own map. Instantly telling the unit to stop prevents the actual move command from doing anything, then turning the unit via a trigger gives it a nice smooth animation.
Players are saved as integers, so anytime you reference a player you are using an integer 0-15.
When you update a dialog/dialog item, you update it for a player group. If you are only updating for one player, you can use the function Convert Player to Player Group. Thus you only need one dialog and not one per player.
The easiest way to run actions by player is using a Pick each player in Player Group loop, where you can then reference each player with the Picked Player function. The All Players group will cycle through all 15 players, so typically you want to use the Active Players group. If instead you are updating a dialog from an event handler, use things like Triggering Player or Owner of Unit(Triggering Unit) to get the player's integer.
Here is a completely arbitrary example of how you could change the text of a dialog item to show a player their own name.
Are you just referring to the popups ad the start of the game that link to the F12 menu? If so, this can be done with the Create Tip action. There are other similar actions like Create Tutorial and Create Cheat that further allow customization of the F12 menu but don't have the same popups. Might be more as well, not sure.
If you want complete customization, you'll likely have to make your own dialogs. If you go that route, there should be plenty of tutorials for setting up dialogs, and this thread in particular I found very helpful for leaning to customize the look of custom dialogs.
Does it make a 2nd unit every single time, or just sometimes? You don't seem to be disabling or hiding the button at all, so it would be possible to repeatedly click the button to continually spawn units. If that is the issue you could add a condition of the dialog item being visible/active, then set it to inactive/hidden in your trigger. If you don't want that aesthetic, you could use a boolean value for the same effect.
Edited the previous image to better show how I had set things up. I didn't think to try making the image within the minimap panel itself, but sadly this doesn't seem to have any affect even with the Set Render Priority action.
Looks like I'll either have to change the image or use the tedious workaround of 4 separate panels for each edge. Not ideal but perfectly doable. Thanks much for the help anyway, hope to have something fun to play soon.
I'm currently trying to make a custom border for the default minimap, so I want to have the minimap render on top of a dialog panel. Currently the only way I have found to do this is by setting the render type of the border image to HDR. However, this causes the border to look faded. Is there any other way to either force the minimap dialog to the front or force an image/panel dialog to the back?
Left side the border looks good, but rendering order causes the blue overlay. Right side rendering order is good, but border is faded.
The only other thing I can think of doing would be to stitch 4 separate border images together around the minimap, but that would be much more tedious to modify and I'm wanting to do the same thing for the command card.
I imagine the best way to do this is to turn your buildings into line of sight blockers, which can be done by modifying the unit's footprint in the data editor. Very quick step by step: open the unit's footprint, select the placement apply and placement check layers, click define sets, and check block vision.
If you need a more thorough explanation, just search around for "block line of sight" and you'll get a lot of results.
Your question seems a bit ambiguous. Are you trying to actually prevent attacking, or are you trying to fix an issue with pathing?
It sounds like the latter, so one trick I've seen people use is to create a dummy unit at the starting point, make it invisible, then issue a move command to the desired end point to find the most optimal route for the unit to take while avoiding obstacles. If you then wanted to have a unit attack in the same pattern, you could periodically save the location of your dummy unit then issue a series of attack orders to your playable unit to those respective saved locations.
This should be vary easy to accomplish with triggers. I'll explain how its done with the assumption you know the basics of the trigger editor. If that assumption is false then I could do something more thorough.
I would personally create an event handler for every event that gives gold to a player, and then create one action to give gold to players. There would be a player group for each team, and a constant for every gold amount given out. Also you may be thinking about this part incorrectly, there is no need to ever divide by three. Instead, you just want to apply an action to three separate players.
Event Handler -
The Unit Dies event should cover most if not all the gold triggering events. From there, you can assign the unit that died to a variable as well as the killing unit, and further you could then check the actual unit type of each unit. Unit type of dying unit would determine the gold amount, and unit type of killing unit would ensure its actually a hero that you want to give gold and not another creep (if you have the hero units saved to a variable, checking against that would be more accurate). You'd likely also need to compare the owners of killing and dying units to prevent teams from getting gold off their own minions. At the end it should call the add gold action with the parameters of player (owner of killing unit) and gold amount.
Add Gold Action -
This should have two parameters as just stated, player and gold amount. With the player, you check which player group they are in. Once you know that, you can then loop through each player in that player group and add the respective amount of gold to each.
Edit - There is a function to return players on a team as a player group, so you can use that if don't have your own groups set up.
Here is a very basic trigger setup that will would allow you to restrict commands to specific players.
If you are a programmer it should be pretty straight forward if you just read through slowly, but a few things to note. The OR statement is only necessary if you want multiple people to have access to the commands. As far as I'm aware you can't actually use slash commands, so what most people do is just create an event handler for chat messages with their own key (example only triggers when the message contains a hyphen). The player handle is a string and the player name is a text value as people were saying previously. You cannot use a text value in a comparison statement, but you can use it when you are actually displaying text to the user. Also if you were unaware, player variables themselves are integers.
Keep in mind that restricting commands by player handle means you would need to update the map anytime you wanted to allow more users to have access to certain commands. If you want to have players unlock access to commands over time just by playing, you'll need to look into bank files.
Assuming you are familiar with the trigger editor this is very easy to do.
You can reference default UI elements using the "Hookup Standard Dialog Item" action. The name for the objective dialog is "UIContainer/FullscreenUpperContainer/ObjectivePanel" and is the type, surprise, panel. You can then adjust it's position within the entire screen using "Move Dialog Item", or anchor it to something with "Attach Dialog Item to Dialog Item".
Sup dude. I think I understand what you are trying to do, just doing it a bit incorrect. I'd also suggest learning just a bit more, as you can make things a lot easier on yourself in the long run. Specifically you should learn arrays, for loops, for each loops, and custom functions.
How you add a unit to a unit group depends on when the unit is added. It seems like you are adding units via the terrain editor, which means they are on the map before the game beings. If that is the case, you need to use the Map Initialization event, then loop through all existing units with a for each loop. If you add a unit via triggers or it spawns while the game is running, you can use the Unit Is Created event.
In looks like you currently intend to have a set of triggers as well as one unit group per player. While that will work, you can make your triggers account for any number of players and use only one unit group variable if you just make your unit group an array. For a very very brief explanation, make a new unit group variable, check the box for array, and set the array size to 15 to count for the maximum number of players. Then instead of referencing "HeroGroupPlayer1" you will use "HeroGroup[1]" where the 1 is actually a numeric value. While a small change, it allows you to do things like use the OwnerOfUnit function to reference a player group.
I've attached a very simple map that shows everything I talked about. My map only has two extra things that your doesn't. First, it has a trigger that slowly kills off the 3 current players just to show the death trigger working. Second, I made a custom function to test weather a unit should be added to the unit group called "Unit Is Heroic". This allows you to keep your list of hero units in one location incase you need to modify it later.
Final tip, use debug messages (Debug Message action) when trying to find errors. Just placing one at the start of a trigger to see if the trigger even starts can be massively helpful.
This may be more explanation than you need, but getting things set up properly now will save you far more time in the long run.
In response to fishy77, anything in the units tab of either the terrain editor or the data editor is considered a unit and testing for being alive works fine. This includes buildings.
My current system is almost exactly what GlornII describes. What Tya is describing sounds really nice, however I don't actually plan to implement a damage as death is entirely collision based. Would it be worth it to try to scrap triggers and try to move to damage?
Basically there are friendlies (Players), hostiles (AI), and death markers. Friendly colliding with hostile, friendly dies and leaves a death marker at location. Friendly collides with other player's death marker, dead friendly respawns at level spawn. I'm currently using triggers to check collision quite rapidly which is working well, but I am worried about lag with many players/levels with many hostiles.
In theory I could have a hostile unit consonantly applying damage around itself that affects friendlies but not death markers, and the same for friendlies where it affects death markers and not hostiles. I would then probably still use triggers to detect friendly death to place marker and for detecting reviving when death marker dies.
Worth it to implement a system like this?
TLDR SOLUTION: Setting a unit's death time to -1 in the data editor allows you to use the revive unit function freely in the trigger editor. You may also need to change the unit revive type in data editor if you are not using premade units. Thanks TyaStarcraft.
0
You'll likely need to make an event handler for a unit move command. Assuming for a moment the unit is always sliding towards the angle it's facing, your event handler might look something like this:
That's a very simplified version of what I've done for ice physics in my own map. Instantly telling the unit to stop prevents the actual move command from doing anything, then turning the unit via a trigger gives it a nice smooth animation.
0
Players are saved as integers, so anytime you reference a player you are using an integer 0-15.
When you update a dialog/dialog item, you update it for a player group. If you are only updating for one player, you can use the function Convert Player to Player Group. Thus you only need one dialog and not one per player.
The easiest way to run actions by player is using a Pick each player in Player Group loop, where you can then reference each player with the Picked Player function. The All Players group will cycle through all 15 players, so typically you want to use the Active Players group. If instead you are updating a dialog from an event handler, use things like Triggering Player or Owner of Unit(Triggering Unit) to get the player's integer.
Here is a completely arbitrary example of how you could change the text of a dialog item to show a player their own name.
0
Are you just referring to the popups ad the start of the game that link to the F12 menu? If so, this can be done with the Create Tip action. There are other similar actions like Create Tutorial and Create Cheat that further allow customization of the F12 menu but don't have the same popups. Might be more as well, not sure.
If you want complete customization, you'll likely have to make your own dialogs. If you go that route, there should be plenty of tutorials for setting up dialogs, and this thread in particular I found very helpful for leaning to customize the look of custom dialogs.
0
There is an Award Achievement action in the trigger editor, but it explicitly states it only works on Blizzard-Signed Maps.
0
Does it make a 2nd unit every single time, or just sometimes? You don't seem to be disabling or hiding the button at all, so it would be possible to repeatedly click the button to continually spawn units. If that is the issue you could add a condition of the dialog item being visible/active, then set it to inactive/hidden in your trigger. If you don't want that aesthetic, you could use a boolean value for the same effect.
0
Edited the previous image to better show how I had set things up. I didn't think to try making the image within the minimap panel itself, but sadly this doesn't seem to have any affect even with the Set Render Priority action.
Looks like I'll either have to change the image or use the tedious workaround of 4 separate panels for each edge. Not ideal but perfectly doable. Thanks much for the help anyway, hope to have something fun to play soon.
0
I'm attempting to do everything from the trigger editor. The only thing different between the above two images is the line chaning render type.
And yes, I'm working on an Ice Escape.
0
I'm currently trying to make a custom border for the default minimap, so I want to have the minimap render on top of a dialog panel. Currently the only way I have found to do this is by setting the render type of the border image to HDR. However, this causes the border to look faded. Is there any other way to either force the minimap dialog to the front or force an image/panel dialog to the back?
Left side the border looks good, but rendering order causes the blue overlay. Right side rendering order is good, but border is faded.
The only other thing I can think of doing would be to stitch 4 separate border images together around the minimap, but that would be much more tedious to modify and I'm wanting to do the same thing for the command card.
0
I imagine the best way to do this is to turn your buildings into line of sight blockers, which can be done by modifying the unit's footprint in the data editor. Very quick step by step: open the unit's footprint, select the placement apply and placement check layers, click define sets, and check block vision.
If you need a more thorough explanation, just search around for "block line of sight" and you'll get a lot of results.
0
Your question seems a bit ambiguous. Are you trying to actually prevent attacking, or are you trying to fix an issue with pathing?
It sounds like the latter, so one trick I've seen people use is to create a dummy unit at the starting point, make it invisible, then issue a move command to the desired end point to find the most optimal route for the unit to take while avoiding obstacles. If you then wanted to have a unit attack in the same pattern, you could periodically save the location of your dummy unit then issue a series of attack orders to your playable unit to those respective saved locations.
0
This should be vary easy to accomplish with triggers. I'll explain how its done with the assumption you know the basics of the trigger editor. If that assumption is false then I could do something more thorough.
I would personally create an event handler for every event that gives gold to a player, and then create one action to give gold to players. There would be a player group for each team, and a constant for every gold amount given out. Also you may be thinking about this part incorrectly, there is no need to ever divide by three. Instead, you just want to apply an action to three separate players.
Event Handler - The Unit Dies event should cover most if not all the gold triggering events. From there, you can assign the unit that died to a variable as well as the killing unit, and further you could then check the actual unit type of each unit. Unit type of dying unit would determine the gold amount, and unit type of killing unit would ensure its actually a hero that you want to give gold and not another creep (if you have the hero units saved to a variable, checking against that would be more accurate). You'd likely also need to compare the owners of killing and dying units to prevent teams from getting gold off their own minions. At the end it should call the add gold action with the parameters of player (owner of killing unit) and gold amount.
Add Gold Action - This should have two parameters as just stated, player and gold amount. With the player, you check which player group they are in. Once you know that, you can then loop through each player in that player group and add the respective amount of gold to each.
Edit - There is a function to return players on a team as a player group, so you can use that if don't have your own groups set up.
0
Here is a very basic trigger setup that will would allow you to restrict commands to specific players.
If you are a programmer it should be pretty straight forward if you just read through slowly, but a few things to note. The OR statement is only necessary if you want multiple people to have access to the commands. As far as I'm aware you can't actually use slash commands, so what most people do is just create an event handler for chat messages with their own key (example only triggers when the message contains a hyphen). The player handle is a string and the player name is a text value as people were saying previously. You cannot use a text value in a comparison statement, but you can use it when you are actually displaying text to the user. Also if you were unaware, player variables themselves are integers.
Keep in mind that restricting commands by player handle means you would need to update the map anytime you wanted to allow more users to have access to certain commands. If you want to have players unlock access to commands over time just by playing, you'll need to look into bank files.
0
Assuming you are familiar with the trigger editor this is very easy to do.
You can reference default UI elements using the "Hookup Standard Dialog Item" action. The name for the objective dialog is "UIContainer/FullscreenUpperContainer/ObjectivePanel" and is the type, surprise, panel. You can then adjust it's position within the entire screen using "Move Dialog Item", or anchor it to something with "Attach Dialog Item to Dialog Item".
If you are trying to adjust other UI frames and trying to find the corresponding name, http://www.helral.eu/SC2LayoutFrames.html is a wonderful website.
0
Sup dude. I think I understand what you are trying to do, just doing it a bit incorrect. I'd also suggest learning just a bit more, as you can make things a lot easier on yourself in the long run. Specifically you should learn arrays, for loops, for each loops, and custom functions.
How you add a unit to a unit group depends on when the unit is added. It seems like you are adding units via the terrain editor, which means they are on the map before the game beings. If that is the case, you need to use the Map Initialization event, then loop through all existing units with a for each loop. If you add a unit via triggers or it spawns while the game is running, you can use the Unit Is Created event.
In looks like you currently intend to have a set of triggers as well as one unit group per player. While that will work, you can make your triggers account for any number of players and use only one unit group variable if you just make your unit group an array. For a very very brief explanation, make a new unit group variable, check the box for array, and set the array size to 15 to count for the maximum number of players. Then instead of referencing "HeroGroupPlayer1" you will use "HeroGroup[1]" where the 1 is actually a numeric value. While a small change, it allows you to do things like use the OwnerOfUnit function to reference a player group.
I've attached a very simple map that shows everything I talked about. My map only has two extra things that your doesn't. First, it has a trigger that slowly kills off the 3 current players just to show the death trigger working. Second, I made a custom function to test weather a unit should be added to the unit group called "Unit Is Heroic". This allows you to keep your list of hero units in one location incase you need to modify it later.
Final tip, use debug messages (Debug Message action) when trying to find errors. Just placing one at the start of a trigger to see if the trigger even starts can be massively helpful.
This may be more explanation than you need, but getting things set up properly now will save you far more time in the long run.
In response to fishy77, anything in the units tab of either the terrain editor or the data editor is considered a unit and testing for being alive works fine. This includes buildings.
0
My current system is almost exactly what GlornII describes. What Tya is describing sounds really nice, however I don't actually plan to implement a damage as death is entirely collision based. Would it be worth it to try to scrap triggers and try to move to damage?
Basically there are friendlies (Players), hostiles (AI), and death markers. Friendly colliding with hostile, friendly dies and leaves a death marker at location. Friendly collides with other player's death marker, dead friendly respawns at level spawn. I'm currently using triggers to check collision quite rapidly which is working well, but I am worried about lag with many players/levels with many hostiles.
In theory I could have a hostile unit consonantly applying damage around itself that affects friendlies but not death markers, and the same for friendlies where it affects death markers and not hostiles. I would then probably still use triggers to detect friendly death to place marker and for detecting reviving when death marker dies.
Worth it to implement a system like this?
TLDR SOLUTION: Setting a unit's death time to -1 in the data editor allows you to use the revive unit function freely in the trigger editor. You may also need to change the unit revive type in data editor if you are not using premade units. Thanks TyaStarcraft.