Note: This is for my own reference, and also to help out others who may be wondering about this.
Data Module -> Units Tab -> Selected Unit -> Movement: Push Priority
This is a simple function. By default, units with a higher push priority can force units with a lower push priority out of the way. Units with a lower or equal push priority cannot push units of a equal or higher push priority.
We're going to be looking at EQUAL PRIORITY, which opens up some options for us.
Units with equal push priorities are a little unique. By default, they cannot push each other out of the way but this is where the trigger action "Set Alliance Aspect" comes into play which allows us to make them PUSHABLE!
Note: Remember, the default is OFF, not ON. When you realize you have to turn things ON, it becomes much easier because then you just deal with allies, not enemies.
Pushable Allies, Non-Pushable Enemies: Using Alliance Aspect
So we have our two units both with an equal push priority.
In the trigger module, we can setup our pushable in one of two ways.
Method One: Allies push each other
(Action) Set alliance
- This will set it up both ways, so setting the alliance to "allies with pushable" makes the all allied units with equal priority able to push each other out of the way when moving.
Method Two: Player X can push player Y, but player Y cant push Player X
Now lets say player 2 is a computer and we dont want our allied (or enemy) computer player to push us, but we want to push them. This is where we set the alliance aspect.
In the trigger module, first define a new (Action)
:: Set alliance between player 1 and 2 to Ally
Then add a new (Action): Set Alliance Aspect
:: Player - Turn Player 2 Pushable On towards Player 1
This will allow us (player 1) to push the allied computer (player 2) out of the way, but they wont be able to push our units out of the way.
Push Allies, Cant push Enemies
By now you should have the hang of it.
(Action) Set Alliance: Player - Make Player X and Ally Y treat each other as _allies and pushable_
(Action) Set Alliance: Player - Make Player X and Enemy Z treat each other as Enemy
The trick to remember is, a units pathing priority takes precedence. Units with a higher value will ALWAYS push lower priority units out of the way. However, EQUAL pathing DEFAULTS TO OFF (allies and enemies can NOT be pushed) but CAN BE TURNED ON VIA TRIGGERS (So allies or enemies CAN be pushed)!
Your information is a bit outdated. You can make inventory systems entirely without triggers now. See above link. :)
@Freddy2287: Go
The above link should help you some. You wont be able to use requirements for your item because, like you said, it detects the shop, not the player triggering the buy. The only downside to this is you cant gray out the button. However, using validators, you can spew out a custom error message if the triggering player doesnt have the correct amount of items.
Make sure youre adding a new layout file via the GUI and pasting the code there, and not trying to use the override method, which is outdated. The UI module can be access by pressing shirt+F6.
UI Panels are essentially dialog items that are pre-defined. If you want to make a new, non-standard one, youll need to use the usual trigger dialog commands.
As for editing the currently existing ones, youll want to use the "Hookup Standard Dialog Item" action inside of a trigger, and then modify your UI files in the UI module (shift+F6). Note: You cannot edit blizzards pre existing ones. You'll need to right click and click add new layout, name your layot and then start your changes there.
Actually, I plan on doing an in-depth tutorial soon which will (sadly) cause all previous inventory tutorials (including this one) to be outdated and obsolete in regards to the way items are bought. Give me some time and Ill pm you a link when Im done.
Shops & Items: New methods, Item Validation, Team Shops & More
Introduction
[A quick note: Using this method prevents the "inventory manipulation - unit BUYS item" event from working. However, you can still use unit gains/loses item. ]
Shops have been discussed a lot in the SC2 Comunity. Typically they use a train order command to purchase items. This tutorial isnt going to cover making an item or a shop. That has already been extensivly discussed in other topics. Instead, what we're going to be focusing on is new methods to use for item buying, selling, and using validators to control what's allowed or not when purchasing our items (ex. Limit 1 item type in inventory, Selling items with multiple charges, combining items, etc)
I'm going to assume you already have created some items and a shop and just need help limiting how a player can buy them. Lets start from there.
First, the Ability
Ignore what people have told you about the train ability. We do NOT want to train an item. We want to CREATE it. So, lets get started.
Create a new ability, type: Effect - Instant. Set the cost to what you want your item to cost. Leave the effect field blank for now. we'll get back to it. (You can check the Stats: Flags: Transient if you want units to purchase while moving, but I dont recommend it)
Lets name this ability "Purchase Rareity Item".
Now lets go to effects.
Create a new effect, type issue order. Name it "Purchase Item - Add to inventory".
Set the "Ability:" field to your hero's inventory ability, and the Ability command to 2. This will order our unit to pick up the item when its created. Set Effect: Unit to caster, Effect: Player to caster, and Effect: Target to Target Unit.
Create a new effect, type create unit. Lets name it "Create Rare item".
Set the "Unit" field to the item you want to create. Set Effect: Spawn to the effect we just created, purchase item - add to inventory. Set Effect: Select Unit to "Caster", and the effect in that field to "purchase item - add item to inventory". Uncheck the "placement" and "offset by radius" flags. We dont want our created unit to have a footprint, nor do we want it to collide with the unit thats creating the item. Set the spawn owner to caster, and target location to caster unit. For good measure set the spawn range to 0, and the offset to (0,0).
Validator
Now go over to our validators tab. Create a new validator, type "unit inventory contains item". Name it "Has Rare Item". Set the "Item" field to our item. Set Validator: Find to disabled (Enabled means its in our inventory, disabled means its not). Set the Validator unit to caster.
Go back to the create unit effect and add our new validator to its Effect: validation field.
Goto our ability and add our create unit effect.
Now goto your shop, add the ability to your unit's Abilities, then set up a command card button for it and you're done. You can now purchase your unit, and it will only let you buy one of that kind of item.
Additional validators
- If you want your shop's items to always be visible, but only purchasable within a certain radius, add a "Location Range" validator to your create unit (item) effect and set the shop's interact ability range to 500. For the Range validator, youll want to set the target location to "target" and leave the location value at caster.
- If your item is part of a group of unique units (example, you have several weapon items, but a hero can only have 1 weapon at any time), use a Combine validator. First, add a normal compare inventory unit validator for each of your units, then add a combine validator and add each item validator to the combine. Set the Type to "And".
- Want to have items with prerequisite items? Simply use the previously discussed validator "unit has inventory item".
If you want to combine items, youll need to use a series of effects and validators for the prerequisite items in order to destroy the old ones and create the new one.
Team Shops
If you want to have a NON NEUTRAL team shop, its pretty simple. You need one simple trigger, and a computer player to act as a host (otherwise things get tricky). First, add a new trigger on map initilization to set alliance one way. Tell Player (shop owner) to treat player (team player) as allied with shared control, vision, and spending. Set alliance one way to tell player (team player) to treat player (shop owner) as ally.
This lets the computer spend your resources to purchase items. The bought items will appear in your units inventory, and will cost you money. However, you wont be able to spend the shop owners money. Pretty cool huh?
Consumables
There has long thought to be a problem with pawning consumable items. This is not the case. People are accustom to setting the pawn fraction to 1 in the pawn ability. However, THIS IS NOT THE CASE WITH CONSUMABLES! In your pawn ability, youll notice it has about 20-30 fields. There is a REASON for this!
About consumables
Typically if your item is consumable, youll have a maximum # of charges. However, when the item is sold, the fraction is based on the MAXIMUM number of charges the consumable can hold. If you have a pawn fraction of 1, and your consumable can have 5 charges and starts with 1 charge when being bought, then when you pawn it youll only get back 1/5th of the amount you bought it for. In order to correct it, we need to utilize the excluded and required fields in the pawn ability
Pawn 01
- Set the refund fraction to 1 for all fields. This allows your typical items to be sold for their normal amount.
- At the bottom, set the classes excluded field to exclude "consumables" (or whatever class your consumable items use)
Pawn 02
- Set the Refund fraction to the MAXIMUM # of charges you item can use. In my case, My items start with 1 charge, and have a max stack count of 255. So here I set my refund fraction to 255.
- At the bottom, set class required to "consumables" (or whatever class your consumables is)
Using this method, youd get a full refund for every charge. In this case, if your item cost 25 minerals, youd get 25 minerals per charge back.
Using this method, you can have items with different classes and different stack counts, and control how items are refunded.
Thats XML. When you use the GUI, its adding XML. The GUI is just a interface. When in the data module, you can press ctrl+3 to view the xml. The answer I gave you earlier is basically the GUI version of what that XML does. (press ctrl+1 to switch back to table view)
You dont have to add command buttons to a command card for an ability to be usable (units just have to have them in their abilities field). I think you might also be able to link to each command card panel and show them, so in efect, you could have 12x4 = 48 command slots across your screen.
There only time I would use an inventory is if there is a specific reason for game function for all your abilities to be tied to items.
Remember, always always use the intended method for things unless there is almost absolutely no way around it.
0
Pushable Priorities, Allies, Enemies, and Units
Note: This is for my own reference, and also to help out others who may be wondering about this.
Data Module -> Units Tab -> Selected Unit -> Movement: Push Priority
This is a simple function. By default, units with a higher push priority can force units with a lower push priority out of the way. Units with a lower or equal push priority cannot push units of a equal or higher push priority.
We're going to be looking at EQUAL PRIORITY, which opens up some options for us. Units with equal push priorities are a little unique. By default, they cannot push each other out of the way but this is where the trigger action "Set Alliance Aspect" comes into play which allows us to make them PUSHABLE!
Note: Remember, the default is OFF, not ON. When you realize you have to turn things ON, it becomes much easier because then you just deal with allies, not enemies.
Pushable Allies, Non-Pushable Enemies: Using Alliance Aspect
So we have our two units both with an equal push priority. In the trigger module, we can setup our pushable in one of two ways.
Method One: Allies push each other
(Action) Set alliance - This will set it up both ways, so setting the alliance to "allies with pushable" makes the all allied units with equal priority able to push each other out of the way when moving.
Method Two: Player X can push player Y, but player Y cant push Player X
Now lets say player 2 is a computer and we dont want our allied (or enemy) computer player to push us, but we want to push them. This is where we set the alliance aspect.
In the trigger module, first define a new (Action)
:: Set alliance between player 1 and 2 to Ally
Then add a new (Action): Set Alliance Aspect
:: Player - Turn Player 2 Pushable On towards Player 1
This will allow us (player 1) to push the allied computer (player 2) out of the way, but they wont be able to push our units out of the way.
Push Allies, Cant push Enemies
By now you should have the hang of it.
(Action) Set Alliance: Player - Make Player X and Ally Y treat each other as _allies and pushable_
(Action) Set Alliance: Player - Make Player X and Enemy Z treat each other as Enemy
The trick to remember is, a units pathing priority takes precedence. Units with a higher value will ALWAYS push lower priority units out of the way. However, EQUAL pathing DEFAULTS TO OFF (allies and enemies can NOT be pushed) but CAN BE TURNED ON VIA TRIGGERS (So allies or enemies CAN be pushed)!
0
Sure. When I get a chance I'll upload one.
0
@megabuster33: Go
I havent had time to make a full example map. The one attached is for inventory images. I'll see if I can make one in the next few days.
0
@TrenchaunT: Go
Your information is a bit outdated. You can make inventory systems entirely without triggers now. See above link. :)
@Freddy2287: Go The above link should help you some. You wont be able to use requirements for your item because, like you said, it detects the shop, not the player triggering the buy. The only downside to this is you cant gray out the button. However, using validators, you can spew out a custom error message if the triggering player doesnt have the correct amount of items.
0
@MacSC2: Go
Actually I may not have time to write the inventory for awhile. If you have skype, pm me with your contact information and I can help you out.
0
@megabuster33:
Make sure youre adding a new layout file via the GUI and pasting the code there, and not trying to use the override method, which is outdated. The UI module can be access by pressing shirt+F6.
0
@megabuster33:
UI Panels are essentially dialog items that are pre-defined. If you want to make a new, non-standard one, youll need to use the usual trigger dialog commands.
As for editing the currently existing ones, youll want to use the "Hookup Standard Dialog Item" action inside of a trigger, and then modify your UI files in the UI module (shift+F6). Note: You cannot edit blizzards pre existing ones. You'll need to right click and click add new layout, name your layot and then start your changes there.
0
@MacSC2:
Actually, I plan on doing an in-depth tutorial soon which will (sadly) cause all previous inventory tutorials (including this one) to be outdated and obsolete in regards to the way items are bought. Give me some time and Ill pm you a link when Im done.
0
Quick Addition: Looking to customize how your inventory looks? How about keeping your inventory containers permanently open or adding an empty face icon to the container slots (ex. weapon/ammo specific slots with a background image). IT CAN BE DONE! See here: http://www.sc2mapster.com/forums/development/gui/40021-9-slot-inventory-always-open/#p11
Shops & Items: New methods, Item Validation, Team Shops & More
Introduction
[A quick note: Using this method prevents the "inventory manipulation - unit BUYS item" event from working. However, you can still use unit gains/loses item. ]
Shops have been discussed a lot in the SC2 Comunity. Typically they use a train order command to purchase items. This tutorial isnt going to cover making an item or a shop. That has already been extensivly discussed in other topics. Instead, what we're going to be focusing on is new methods to use for item buying, selling, and using validators to control what's allowed or not when purchasing our items (ex. Limit 1 item type in inventory, Selling items with multiple charges, combining items, etc)
I'm going to assume you already have created some items and a shop and just need help limiting how a player can buy them. Lets start from there.
First, the Ability
Ignore what people have told you about the train ability. We do NOT want to train an item. We want to CREATE it. So, lets get started.
Create a new ability, type: Effect - Instant. Set the cost to what you want your item to cost. Leave the effect field blank for now. we'll get back to it. (You can check the Stats: Flags: Transient if you want units to purchase while moving, but I dont recommend it) Lets name this ability "Purchase Rareity Item".
Now lets go to effects.
Create a new effect, type issue order. Name it "Purchase Item - Add to inventory". Set the "Ability:" field to your hero's inventory ability, and the Ability command to 2. This will order our unit to pick up the item when its created. Set Effect: Unit to caster, Effect: Player to caster, and Effect: Target to Target Unit.
Create a new effect, type create unit. Lets name it "Create Rare item". Set the "Unit" field to the item you want to create. Set Effect: Spawn to the effect we just created, purchase item - add to inventory. Set Effect: Select Unit to "Caster", and the effect in that field to "purchase item - add item to inventory". Uncheck the "placement" and "offset by radius" flags. We dont want our created unit to have a footprint, nor do we want it to collide with the unit thats creating the item. Set the spawn owner to caster, and target location to caster unit. For good measure set the spawn range to 0, and the offset to (0,0).
Validator
Now go over to our validators tab. Create a new validator, type "unit inventory contains item". Name it "Has Rare Item". Set the "Item" field to our item. Set Validator: Find to disabled (Enabled means its in our inventory, disabled means its not). Set the Validator unit to caster.
Go back to the create unit effect and add our new validator to its Effect: validation field.
Goto our ability and add our create unit effect.
Now goto your shop, add the ability to your unit's Abilities, then set up a command card button for it and you're done. You can now purchase your unit, and it will only let you buy one of that kind of item.
Additional validators
- If you want your shop's items to always be visible, but only purchasable within a certain radius, add a "Location Range" validator to your create unit (item) effect and set the shop's interact ability range to 500. For the Range validator, youll want to set the target location to "target" and leave the location value at caster.
- If your item is part of a group of unique units (example, you have several weapon items, but a hero can only have 1 weapon at any time), use a Combine validator. First, add a normal compare inventory unit validator for each of your units, then add a combine validator and add each item validator to the combine. Set the Type to "And".
- Want to have items with prerequisite items? Simply use the previously discussed validator "unit has inventory item".
If you want to combine items, youll need to use a series of effects and validators for the prerequisite items in order to destroy the old ones and create the new one.
Team Shops
If you want to have a NON NEUTRAL team shop, its pretty simple. You need one simple trigger, and a computer player to act as a host (otherwise things get tricky). First, add a new trigger on map initilization to set alliance one way. Tell Player (shop owner) to treat player (team player) as allied with shared control, vision, and spending. Set alliance one way to tell player (team player) to treat player (shop owner) as ally.
This lets the computer spend your resources to purchase items. The bought items will appear in your units inventory, and will cost you money. However, you wont be able to spend the shop owners money. Pretty cool huh?
Consumables
There has long thought to be a problem with pawning consumable items. This is not the case. People are accustom to setting the pawn fraction to 1 in the pawn ability. However, THIS IS NOT THE CASE WITH CONSUMABLES! In your pawn ability, youll notice it has about 20-30 fields. There is a REASON for this!
About consumables
Typically if your item is consumable, youll have a maximum # of charges. However, when the item is sold, the fraction is based on the MAXIMUM number of charges the consumable can hold. If you have a pawn fraction of 1, and your consumable can have 5 charges and starts with 1 charge when being bought, then when you pawn it youll only get back 1/5th of the amount you bought it for. In order to correct it, we need to utilize the excluded and required fields in the pawn ability
Pawn 01
- Set the refund fraction to 1 for all fields. This allows your typical items to be sold for their normal amount. - At the bottom, set the classes excluded field to exclude "consumables" (or whatever class your consumable items use)
Pawn 02
- Set the Refund fraction to the MAXIMUM # of charges you item can use. In my case, My items start with 1 charge, and have a max stack count of 255. So here I set my refund fraction to 255. - At the bottom, set class required to "consumables" (or whatever class your consumables is) Using this method, youd get a full refund for every charge. In this case, if your item cost 25 minerals, youd get 25 minerals per charge back.
Using this method, you can have items with different classes and different stack counts, and control how items are refunded.
0
@MacSC2:
Thats XML. When you use the GUI, its adding XML. The GUI is just a interface. When in the data module, you can press ctrl+3 to view the xml. The answer I gave you earlier is basically the GUI version of what that XML does. (press ctrl+1 to switch back to table view)
0
@rtschutter:
In 1.5, When you set up the trigger for planel templates, you can click over to "presets" and choose from a list of templates.
0
@rtschutter:
Are you sure that the template the panel is linking to is still valid? I know they occasionally like to reorder/rename templates and/or layout files.
0
@rtschutter:
http://www.sc2mapster.com/forums/general/general-chat/40030-1-5-ui-stuff-demo-1-control-built-in-ui-stuff-with/
0
@bradosia:
You dont have to add command buttons to a command card for an ability to be usable (units just have to have them in their abilities field). I think you might also be able to link to each command card panel and show them, so in efect, you could have 12x4 = 48 command slots across your screen.
There only time I would use an inventory is if there is a specific reason for game function for all your abilities to be tied to items.
Remember, always always use the intended method for things unless there is almost absolutely no way around it.
0
@rtschutter:
See 9 slot inventory thread here and 1.5 Patch UI in general forum.