Use the trigger action "Hookup Standard Dialog Item" with a path of "UIContainer/ConsoleUIContainer/InfoPanel/InfoPaneHero/ExperienceBar" and a type of "Progress Bar". Then use "Last Created Dialog Item" to get the bar as a dialog item. As a dialog item, try setting it to hidden for all players.
There's a possibility that hiding it will also hide the level label, I don't know. If that's the case, then try fading the transparency to 100%.
You should be able to reference it with "Last Created Dialog Item", not "Last Created Dialog".
If you are trying the second method that I described above, you would need to hookup "UIContainer/ConsoleUIContainer/CommandPanel" as a panel, instead of the buttons. Then you would use "Create Dialog Item In Panel" to make the labels.
Regarding your last question, I'll have to know more about what you mean by "very specific set of buttons". Because you're hooking them up as dialog items, you can modify them on a per-player basis. But the modifications would certainly still be there regardless of what abilities were actually present on the buttons.
The first would be to try setting the text value of the button itself. This will result in the text you want sitting smack dab in the center of the button. I think you can probably reposition the text by changing the style value of the button as well (the font style, that is). For example, if you want the text to be in the top left, give it a font that is positioned at top left. I assume the standard font for the button is middle center.
The second way would be to hookup the CommandPanel itself as a panel type, and use "Create Dialog Item In Panel" to create a label for each button and position them over the buttons.
Obviously the reasons for making a custom function are to reduce the amount of code used and simplify the process of doing something that you expect to use in more than one place.
A lot of examples of good use of custom functions are for dialog creation. If you come up with a button design that you like and want to use in multiple dialogs it may require creating a button, getting the icon from an ability or item or something similar, applying that icon to an image, and positioning the image on top of the button. What would normally take several actions can be simplified to 1 with much fewer parameters for use in multiple triggers.
-
Writing code can become extremely fast if using them. Whenever I come along something that I need and expect to use again, I don't just slap it together there, I make it as a new "module" of sorts, with every function I expect to need for it. The result is that I can do things like create a dialog health bar that automatically updates for a specified unit's health using just a single action and a couple of parameters.
Creating the mines would consist of a Create Persistent effect with a period duration of 0, a period effect of Create Unit that creates the mine, and period offsets for the location of each mine, as well as a period count corresponding to the number of mines.
That should create them all in their locations.
Making the mines explode when a unit walks over them would be best be done by giving them a behavior with a periodic effect of Search Area with a target location of source unit and a maximum unit count of 1 and a minimum unit count of 1. This will make the effect run by the Search Area effect only occur if at least one unit steps over the mine.
That will handle the searching for nearby units. The explosion will be created in the effect run by the Search Area effect. Make a set effect. The first effect will do whatever you want to happen - be it damage the target unit, or run another search effect to damage all nearby units. The second effect will be a Damage effect with a target of source unit with a damage value of 0 but the effect flag "Kill" enabled. This will kill the mine after it executes its effect once.
I take by your use of the word dynamic that these things could change during the course of a game. In that case the solution is to use the "Hookup Standard Dialog Item" action to get each button as a dialog item, and then modify them from there.
The path that you want to hookup would be "UIContainer/ConsoleUIContainer/CommandPanel/CommandButton00" for the top left button, as an example.
Switch to XML mode and remove all the info in that actor. If the XML doesn't have any information, it should calculate it based on the parent exactly as you wanted.
To make things worse in Hearstone you can spend money, real money, to have more and better cards available which means new players have one more (strong) disadvantage.
To me, that alone is enough reason not to play it.
Over the process of developing my current project I have been creating a lot of trigger modules, in large part to simplify various interface components like making portrait images from the Starcraft 2 portrait sheets, making ability/item buttons with icons, making progress bars, more specialized progress bars that can be set up to automatically update for a unit's vitals, etc.
I was wondering if anybody has any interest in making use of such modules. If so, I would happily do the extra little effort of packaging them as libraries with GUI wrappers.
0
@sunyatasattva: Go
Try this:
Use the trigger action "Hookup Standard Dialog Item" with a path of "UIContainer/ConsoleUIContainer/InfoPanel/InfoPaneHero/ExperienceBar" and a type of "Progress Bar". Then use "Last Created Dialog Item" to get the bar as a dialog item. As a dialog item, try setting it to hidden for all players.
There's a possibility that hiding it will also hide the level label, I don't know. If that's the case, then try fading the transparency to 100%.
If that doesn't work, let me know.
0
@Duke1623: Go
You need to tell us more about how you're making the buttons.
0
@sunyatasattva: Go
You should be able to reference it with "Last Created Dialog Item", not "Last Created Dialog".
If you are trying the second method that I described above, you would need to hookup "UIContainer/ConsoleUIContainer/CommandPanel" as a panel, instead of the buttons. Then you would use "Create Dialog Item In Panel" to make the labels.
Regarding your last question, I'll have to know more about what you mean by "very specific set of buttons". Because you're hooking them up as dialog items, you can modify them on a per-player basis. But the modifications would certainly still be there regardless of what abilities were actually present on the buttons.
0
@sunyatasattva: Go
There are two ways you could do it.
The first would be to try setting the text value of the button itself. This will result in the text you want sitting smack dab in the center of the button. I think you can probably reposition the text by changing the style value of the button as well (the font style, that is). For example, if you want the text to be in the top left, give it a font that is positioned at top left. I assume the standard font for the button is middle center.
The second way would be to hookup the CommandPanel itself as a panel type, and use "Create Dialog Item In Panel" to create a label for each button and position them over the buttons.
0
@bulletbutter: Go
Obviously the reasons for making a custom function are to reduce the amount of code used and simplify the process of doing something that you expect to use in more than one place.
A lot of examples of good use of custom functions are for dialog creation. If you come up with a button design that you like and want to use in multiple dialogs it may require creating a button, getting the icon from an ability or item or something similar, applying that icon to an image, and positioning the image on top of the button. What would normally take several actions can be simplified to 1 with much fewer parameters for use in multiple triggers.
-
Writing code can become extremely fast if using them. Whenever I come along something that I need and expect to use again, I don't just slap it together there, I make it as a new "module" of sorts, with every function I expect to need for it. The result is that I can do things like create a dialog health bar that automatically updates for a specified unit's health using just a single action and a couple of parameters.
0
@drybonevalley: Go
Creating the mines would consist of a Create Persistent effect with a period duration of 0, a period effect of Create Unit that creates the mine, and period offsets for the location of each mine, as well as a period count corresponding to the number of mines.
That should create them all in their locations.
Making the mines explode when a unit walks over them would be best be done by giving them a behavior with a periodic effect of Search Area with a target location of source unit and a maximum unit count of 1 and a minimum unit count of 1. This will make the effect run by the Search Area effect only occur if at least one unit steps over the mine.
That will handle the searching for nearby units. The explosion will be created in the effect run by the Search Area effect. Make a set effect. The first effect will do whatever you want to happen - be it damage the target unit, or run another search effect to damage all nearby units. The second effect will be a Damage effect with a target of source unit with a damage value of 0 but the effect flag "Kill" enabled. This will kill the mine after it executes its effect once.
0
@Zolden: Go
Well done!
0
@sunyatasattva: Go
But of course.
I take by your use of the word dynamic that these things could change during the course of a game. In that case the solution is to use the "Hookup Standard Dialog Item" action to get each button as a dialog item, and then modify them from there.
The path that you want to hookup would be "UIContainer/ConsoleUIContainer/CommandPanel/CommandButton00" for the top left button, as an example.
0
@Terhonator: Go
Switch to XML mode and remove all the info in that actor. If the XML doesn't have any information, it should calculate it based on the parent exactly as you wanted.
0
@penguinwars: Go
You are in serious need of some for loops, my friend.
0
@Fullachain: Go
You're willing to use a trigger based physics system?
HMMMM. I hope you're prepared to suffer the delay.
0
Ah man, you're really pulling out the big guns, huh?
(Pun Intended)
No seriously though, given that there hasn't been a really successful shooter, if you can pull it off that would be quite a feat. Good luck.
0
You're on, bro. You're on..
0
To me, that alone is enough reason not to play it.
0
Hey all,
Over the process of developing my current project I have been creating a lot of trigger modules, in large part to simplify various interface components like making portrait images from the Starcraft 2 portrait sheets, making ability/item buttons with icons, making progress bars, more specialized progress bars that can be set up to automatically update for a unit's vitals, etc.
I was wondering if anybody has any interest in making use of such modules. If so, I would happily do the extra little effort of packaging them as libraries with GUI wrappers.
-Wrath