Hello trigger master, I've been sent here by the data masters to ask you this. How by triggers can i transfer veterinary already achieved levels from one unit to another. This is how it will work: I have this one unit that have the levels behavior and after a while the player can upgrade to another much better unit but this unit will still be using the first unit level points since after all it will be the same unit in the end, just upgraded. Let me know ok? Thanks.
If you want to replace the unit entirely, then you would set up your event to fire whenever it was supposed to. Let's say you want your level 4 Grunt to become an Orc when he hit's level 5, and still BE level 5.
Then your trigger would fire when unit property changes. the property would be level. The condition would be that the level of the triggering unit is =5
Your trigger would replace the triggering unit with your new unit. And the very next action would modify the (property) of (last created unit), setting it to be 5. It would need to be a lot more complex if your hero is using an inentory, but since abilities and everything else data wise would already be set up on the new unit, the trigger would end there.
Forget most of what I just said. You can't use upgrades to change things more than once, because an upgrade does the same thing each level it's purchased. You could change upgrade levels with triggers, but it's probably better to simply make everything unique. Each Research ability can hold 30 researches, and each unit type can hold 32 abilities, so even using half of the ability slots on one building would give you plenty of combinations.
Changing build times, resource costs and supply costs are definitely possible, I don't know about changing the button tooltip and icons however, but it should be possible since you can change them when you upgrade them.
I can say from experience, or perhaps just lack of, that you can't use an upgrade to change it's "own" tooltip and Name. I was trying to use the same "Blank" upgrade multiple times, just so I could call it in a trigger, and making the only effect the upgrade have be to change it's own tooltip, name, and icon.
But for some reason when I tried to make the Level 2 version change the button info for the Level 3 version, it changed it immediately in the editor (The button itself). It may have been because I had it with a max level of 1, or perhaps I somehow tried to undo something and just hit it a couple of extra times, But I decided to go the Blizzard route and just make one upgrade for each upgrade level.
The only thing that would be saved would be the variables that generate the information you're putting on your units. Since they'll be Global Variables, the game will always remember them. I've never really played any large team arcade maps, so I was just warning you about the chat being flooded with the names people want for units. And if there is a lot of chat between players, then you have to make certain they understand that what their last entry was will be the names of newly created units once they hit that button.
I would be very careful if you plan to implement this into a multiplayer environment. It will probably create a lot of random chat messages popping up, and since it will have to save each chat entry as a variable, it may cause performance issues.
EDIT: And I totally intend to use this myself if I ever make a hero based map with Heroes the player can name.
If you were to create a trigger that went off every time someone entered chat message with text "" (click the text and leave it blank, or perhaps put a-z?) matching partially, you could have the trigger save the "entered string" as a separate global variable based on the player that typed it.
Finally, put a button for each unit type on a building(s), and add a new trigger to have each button swap in the saved variable to "name" all new units of that type to what was entered. You could also set a button on each unit, letting you change individual names to whatever that global variable is with a separate trigger.
He wants to be able to change the name to anything he wants, and since you can't change the behavior modification text (that I know of), you would have to make it limited to however many behaviors you felt like making.
EDIT: Instead of trying to remove the names through the UI, simply make a behavior that overrides unit name and leave it blank. Then apply that behavior to your unit creation trigger with the set unit info.
The Set Unit Info action will let you set the text that appears below the unit type name, where kills and rank usually appear, as well as the "tip" text that appears when you hover the mouse over a unit. Changing those would be a "simple" matter of setting up a record with a text variable for each unit type. You simply set the default value to the unit's in game name, and have a trigger that changes all created units info to these variables based on unit type. When you want the names to change, you set up a trigger that changes those variables based on how you decide to implement it.
Using the previous suggestion to go through GameUI/UIContainer/ConsoleUIContainer/InfoPanel/InfoPaneUnit/NameLabel and simply delete all of the names so that the only text that shows up is the name you choose. (not the unit's original name.)
I have a couple of wheels spinning, but to be honest I don't have it in me to dig into something I know so little about right now. I feel like an effect can modify a unit's name, so simply adding a trigger that applies that effect/behavior to unit types upon creation would be how I would start. I don't know enough about how to change the text the behavior would apply, personally.
DrSuperEvil will be along shortly to throw out a bunch of data stuff that I don't understand, so until then, you might look into effects and triggers that use player text groups to get you started.
I'm curious. Maybe I've just been off the internet for too long. Maybe I'm just getting too old. I know it's something that's been out for a long time, but I've spent the last 8 years out of touch with the gaming community beyond Fallout and COD. It's a meme that everyone understands as common knowledge, but MOBA and DOTA are words I know, but can't put a definition to.
I've been trying to learn a lot of new things for my project, but I'm so swamped with other things that I'm working on that this is something I'd just rather live without than learn from scratch. However, if someone already has something similar that I can borrow and adapt, I'd be eternally grateful.
I need two Inventory style boxes that appear when a unit type is clicked on. All they need to actually do is have an appropriate background icon and display an integer that would be set by triggers. If unit type 1 is clicked, the boxes show up displaying integers 1a and 1b. It doesn't need to be large or impressive. It's just meant to show the user some in game information.
Well, that's a lot different than a unit training units, like the TC was looking for.
For that, I'd need more information.
Are you "Reviving" a hero unit that died? There's an excellent guide by SCOneTwo (OneTwoSC???) that shows a workaround that prevents the hero from actually being killed, so you can simply keep your current level.
If you're just looking for a basic trigger idea then your event would be unit dies. The condition would be that it was the hero that died. You would need a local variable "Hero Level" that you would set equal to (Triggering unit) property(Level). Now, if you're creating your new hero in this trigger, then after whatever action creates your unit, you would set (last created unit) property (Level) to your variable "Hero Level". If you want to have to make your hero again at a building or something, then this trigger would simply set a global variable "Global Hero Level" to "Hero Level".
Then you would need a separate trigger to add the level to your new hero.
EDIT: I know the guide is on YouTube. I don't know if the guy that made it is in any modding communities. Or if he even still makes tutorials. But I do know that his tutorials are excellent and easy to follow along with as long as you pause the video and work with his step by step instructions.
He was speaking specifically of local variables. Basically, the logic of his argument was if there were more than 10-12 functions referring to a unit, even if it wasn't the same unit each time, to make a local unit variable and then change it as needed. Change it to unit 1, use it 3 times, change it to unit 2, use it 3 times, change it to unit 3, use it 3 times, and then let it be wiped clean when the trigger ended.
It made sense, and since I was already doing it anyway, it just kind of slipped my mind. But I was looking at a local variable list of mine that had over a dozen variables, and I was just wondering what makes a map or mod more efficient.
Because I'm still figuring out a lot of the Data side, most of the functionality of my map comes from triggers. My map isn't performance intense so it doesn't matter, but in a 8 player FFA, would it be better for most things to be done in the data window as opposed to my frequent trigger "workarounds".
0
If you want to replace the unit entirely, then you would set up your event to fire whenever it was supposed to. Let's say you want your level 4 Grunt to become an Orc when he hit's level 5, and still BE level 5.
Then your trigger would fire when unit property changes. the property would be level. The condition would be that the level of the triggering unit is =5
Your trigger would replace the triggering unit with your new unit. And the very next action would modify the (property) of (last created unit), setting it to be 5. It would need to be a lot more complex if your hero is using an inentory, but since abilities and everything else data wise would already be set up on the new unit, the trigger would end there.
0
@zuPloed: Go
Thank you both for the information. Now I feel like my map is a bit of a waste of time...
0
@BigDonRob: Go
Forget most of what I just said. You can't use upgrades to change things more than once, because an upgrade does the same thing each level it's purchased. You could change upgrade levels with triggers, but it's probably better to simply make everything unique. Each Research ability can hold 30 researches, and each unit type can hold 32 abilities, so even using half of the ability slots on one building would give you plenty of combinations.
0
I can say from experience, or perhaps just lack of, that you can't use an upgrade to change it's "own" tooltip and Name. I was trying to use the same "Blank" upgrade multiple times, just so I could call it in a trigger, and making the only effect the upgrade have be to change it's own tooltip, name, and icon.
But for some reason when I tried to make the Level 2 version change the button info for the Level 3 version, it changed it immediately in the editor (The button itself). It may have been because I had it with a max level of 1, or perhaps I somehow tried to undo something and just hit it a couple of extra times, But I decided to go the Blizzard route and just make one upgrade for each upgrade level.
0
@FunkyUserName: Go
If I ever have a trigger that runs long enough for the unit it created to be removed by the same trigger, something is wrong. lol.
I definitely know what you mean. Anytime you want to play an animation or sound on a unit 3 units ago, you're screwed without those variables.
0
@FunkyUserName: Go
The only thing that would be saved would be the variables that generate the information you're putting on your units. Since they'll be Global Variables, the game will always remember them. I've never really played any large team arcade maps, so I was just warning you about the chat being flooded with the names people want for units. And if there is a lot of chat between players, then you have to make certain they understand that what their last entry was will be the names of newly created units once they hit that button.
0
@zuPloed: Go
I didn't know any of those references beyond the names, but I'm assuming it's kind of like a scaled down WoW?
0
@hardball69: Go
I would be very careful if you plan to implement this into a multiplayer environment. It will probably create a lot of random chat messages popping up, and since it will have to save each chat entry as a variable, it may cause performance issues.
EDIT: And I totally intend to use this myself if I ever make a hero based map with Heroes the player can name.
0
@BigDonRob: Go
If you were to create a trigger that went off every time someone entered chat message with text "" (click the text and leave it blank, or perhaps put a-z?) matching partially, you could have the trigger save the "entered string" as a separate global variable based on the player that typed it.
Finally, put a button for each unit type on a building(s), and add a new trigger to have each button swap in the saved variable to "name" all new units of that type to what was entered. You could also set a button on each unit, letting you change individual names to whatever that global variable is with a separate trigger.
@FunkyUserName: Go
He wants to be able to change the name to anything he wants, and since you can't change the behavior modification text (that I know of), you would have to make it limited to however many behaviors you felt like making.
EDIT: Instead of trying to remove the names through the UI, simply make a behavior that overrides unit name and leave it blank. Then apply that behavior to your unit creation trigger with the set unit info.
0
@BigDonRob: Go
The Set Unit Info action will let you set the text that appears below the unit type name, where kills and rank usually appear, as well as the "tip" text that appears when you hover the mouse over a unit. Changing those would be a "simple" matter of setting up a record with a text variable for each unit type. You simply set the default value to the unit's in game name, and have a trigger that changes all created units info to these variables based on unit type. When you want the names to change, you set up a trigger that changes those variables based on how you decide to implement it.
Using the previous suggestion to go through GameUI/UIContainer/ConsoleUIContainer/InfoPanel/InfoPaneUnit/NameLabel and simply delete all of the names so that the only text that shows up is the name you choose. (not the unit's original name.)
0
@hardball69: Go
I have a couple of wheels spinning, but to be honest I don't have it in me to dig into something I know so little about right now. I feel like an effect can modify a unit's name, so simply adding a trigger that applies that effect/behavior to unit types upon creation would be how I would start. I don't know enough about how to change the text the behavior would apply, personally.
DrSuperEvil will be along shortly to throw out a bunch of data stuff that I don't understand, so until then, you might look into effects and triggers that use player text groups to get you started.
0
I'm curious. Maybe I've just been off the internet for too long. Maybe I'm just getting too old. I know it's something that's been out for a long time, but I've spent the last 8 years out of touch with the gaming community beyond Fallout and COD. It's a meme that everyone understands as common knowledge, but MOBA and DOTA are words I know, but can't put a definition to.
0
I've been trying to learn a lot of new things for my project, but I'm so swamped with other things that I'm working on that this is something I'd just rather live without than learn from scratch. However, if someone already has something similar that I can borrow and adapt, I'd be eternally grateful.
I need two Inventory style boxes that appear when a unit type is clicked on. All they need to actually do is have an appropriate background icon and display an integer that would be set by triggers. If unit type 1 is clicked, the boxes show up displaying integers 1a and 1b. It doesn't need to be large or impressive. It's just meant to show the user some in game information.
0
@JEGCPR: Go
Well, that's a lot different than a unit training units, like the TC was looking for.
For that, I'd need more information.
Are you "Reviving" a hero unit that died? There's an excellent guide by SCOneTwo (OneTwoSC???) that shows a workaround that prevents the hero from actually being killed, so you can simply keep your current level.
If you're just looking for a basic trigger idea then your event would be unit dies. The condition would be that it was the hero that died. You would need a local variable "Hero Level" that you would set equal to (Triggering unit) property(Level). Now, if you're creating your new hero in this trigger, then after whatever action creates your unit, you would set (last created unit) property (Level) to your variable "Hero Level". If you want to have to make your hero again at a building or something, then this trigger would simply set a global variable "Global Hero Level" to "Hero Level".
Then you would need a separate trigger to add the level to your new hero.
EDIT: I know the guide is on YouTube. I don't know if the guy that made it is in any modding communities. Or if he even still makes tutorials. But I do know that his tutorials are excellent and easy to follow along with as long as you pause the video and work with his step by step instructions.
0
@willuwontu: Go
He was speaking specifically of local variables. Basically, the logic of his argument was if there were more than 10-12 functions referring to a unit, even if it wasn't the same unit each time, to make a local unit variable and then change it as needed. Change it to unit 1, use it 3 times, change it to unit 2, use it 3 times, change it to unit 3, use it 3 times, and then let it be wiped clean when the trigger ended.
It made sense, and since I was already doing it anyway, it just kind of slipped my mind. But I was looking at a local variable list of mine that had over a dozen variables, and I was just wondering what makes a map or mod more efficient.
Because I'm still figuring out a lot of the Data side, most of the functionality of my map comes from triggers. My map isn't performance intense so it doesn't matter, but in a 8 player FFA, would it be better for most things to be done in the data window as opposed to my frequent trigger "workarounds".