drain resources equal to the damage dealt (multiplied by a factor)
Not really possible.
Well, it is possible..
But that would include that you create sets and validators for every vitality value the unit had before and every vitality value the unit had afterwards resulting in an effect. Basically you would branch out for each possible vitality value the unit had before, then deal damage effect and a set effect in each branch. That set effect would result in another branch for every possible vitality value.
In short: you create a graph/tree with every possible combination of outcomes and check each path, if it is the correct one.
That's a ton of data stuff just for 1 weapon (as this might result in thousands of entries for 1 weapon). This makes it possible with data, but it's just the worst solution you can imagine.
Warhound is in the base swarm mod. It was a unit appearing in campaign and beta.
The multi dependency that holds the multiplayer balance changes removes it from multiplayer.
Blizzard didn't tidy up that aspect before the release because it's not really required. Maybe they weren't sure if they won't have to patch the warhound back into multiplayer again, didn't want to spend time to do something that doesn't really effect anyone or they kept it because they knew they wanted to use the model for aprils fools.
The UI editor presents you all the UI layouts in the game in one place, so you don't need to find & extract them in all the MPQ files. Also, it provides you with a tree where you can easily check which frames are contained in another.
The code you use is exactly the same as in the old method. So, the transition mainly consists out of copy + paste. It's just the place where your UI code is is much nicer.
Well, basically, there is no new method. It's the same thing, just in a better working environment.
1. Events can't use functions in their definition. Use the conditions or the first few actions to filter for specific players.
2. Preload is a dummy action in the editor. The editor will remove the action internally and note down the player number and the used string to upload and share that player slot's bank file during map's loading screen among the other players.
You must write down the bank name and the player name as values and not function calls/variables/etc for the preload.
However, the other actions can use variables as they are real actions that are executed during the map.
3. New bank files are always unverified. But they were initially empty. I would suggest that you analyze the status of the saving at map start for the players instead checking that everytime you save something.
There is still one more expansion left so plenty of room for improvement as far as the game engine goes. Just hope they fix that one bug with the Create Persistent effect.
Ahli you work on diablo map i can't believe you didnt face such issues. What can you say about them?
I've no small changes, but pretty much for the things that could be effected by that like mana and life regeneration bonus, I calculate the amount when it is required and not only once.
So, instead of adding/subtracting the value, save the info that you need to calculate the offset. Then calculate the new value based on your default value. This way you will never have problems like this. At least you won't notice them as you can't do that much about it.
My approach in diablo is a pretty solid one as it stands on default values which it keeps using to calculate new values when something is changed. For example, the matter that you equip items does not matter unlike D2 where it matters. I'm checking things for item requirements as a whole. It has a much worse performance, but it cannot fail unless there is a clear bug in my code.
I finally managed to create a player colored image. I figured that my code will be helpful to others.
<!-- player colored image --><Frametype="PlayerFrame"name="PlayerColoredImageExample"><Anchorside="Top"relative="$parent"pos="Min"offset="5"/><Anchorside="Right"relative="$parent"pos="Max"offset="0"/><Anchorside="Bottom"relative="$parent"pos="Max"offset="-5"/><Anchorside="Left"relative="$this"pos="Min"offset="0"/><Widthval="350"/><VersusModePlayerSideval="Left"/><Frametype="Image"name="Image"><Anchorrelative="$parent"/><IgnoreParentColorval="false"/><TextureTypeval="Normal"/><Textureval="gradient.dds"/><Alphaval="191"/><Tiledval="false"/><RenderPriorityval="101"/></Frame></Frame>
But currently, it has a problem with updating its color when the observer changes the player vision with team colors enabled as seen here.
I'm a tad confused - do you map? You say you edit UI's... as in - UI's in maps or on websites?
Either way, welcome to Mapster, enjoy your stay! :)
He tinkered with Blizzard's interfaces and now got a task in his company to create an observer UI. Thus, he needs to learn it.
Also, I just found out that you can just test interfaces that are components folders without the saving error. Technically it's a mod and not a limited interface then, but it works better for testing.
Use a buff behavior with stacks to slow the unit for a percentage of the current speed. It will work just like your triggers (=same math), just the values are restored without calculation errors as it recalculates a new value instead of re-adding calculation errors resulting in permanently lost speed.
Oh, we met in reddit already when I gave you some feedback about your interface. :D
Also, yay, for information systems. I'm working on finishing my Bachelors degree in that right now. Well, sort of, the actual name is "Wirtschaftsinformatik" in German, my master would be called IS.
Welcome and enjoy the stay, learn and ask.
If you want to crash the editor and the game with a compiled interface, I know a way. ;)
Interfaces use xml code that was first used in a UI modification method we called "aiur chef method". With the UI module in the editor, you can write and create Layout files in there.
SC2 has an ingame UI editor that is available via editor tests ("test document" button). It's default hotkey is ctrl + alt + F12. It's great to alter a few values and find offsets to make things look right or to learn the structure of existing elements.
Use Blizzard's interfaces as a reference. They contain pretty much every aspect you can do with interfaces.
The best way to test interfaces is to take a map from battle.net, set player 1 and 2 to computer in the Map->PlayerProperties, set all other slots to "None", set the default observed player to Neutral, save the map without a space in a folder named "Maps" within your SC2 installation folder and put the file name like "InterfaceTestMap.SC2Map" in the options as default used map.
Then you can just "test document" your interface.
Ingame, you can write "speed #" with # = speed value. If you write "speed 8", the game runs with 8 times the "normal" game speed. This makes testing your interface much faster. With the "Numpad +" on your keyboard you can return to the default "Faster" speed.
If you alter the interface code in an external XML editor like notepadPP and it fails to save the file because the file is still in use (= map still loaded in sc2), then you need to re-paste your code into the layout and compile+save again after closing the map. The editor forgets that it compiled the pasted code. It even forgets that there is new code in the displayed layout file.
And I think that is everything that comes to my mind that you might want to know.
alter cliff levels: no
alter textures: place splat actors everywhere
alter water: hardcode all states you want. Water is limited to a 4x4 square now. Water can only switch its states. (I don't think we can alter it with catalog, but I didn't try it)
alter camera height: no, I don't think so.
alter pathing: create units with footprints
alter clipping of things (like terrain not rendered far enough around the screen creating problems): camera data should contain a setting to alter the clip ranges
Some people here made random terrain:
- iIiIiIiIiIi or however his name was made a pretty awesome random world that can change dynamically. In his mod, the player is some kind of god ordering people and casting spells.
- Zolden made one which visually simulates cliffs and tries to make them not too ugly. He also made another one before with rivers and simple mountains (doodads for mountains).
- TwoDie made one that can create rivers, places trees and mountains. It can be seen in his map "Age of Knights".
- I made random dungeon levels featuring 3 different styles and 1x1 tile based lava rivers.
In any way, random terrain will require you to use units and actors.
1. You don't need to iterate over the player numbers. You have triggering player and that's all information you need.
2. AND in conditions contains a list of conditions that it connects. OR does the same.
The contained elements within that list all need to return true for the AND to return true.
Every list with conditions automatically acts like an AND. So, you don't need to add an AND into the IF.
3. The "Zerg_Choose_Race_Button" 's visibility to the using player determines if the button was clicked or not.
4. The whole dialog's visibility to the player determines that the player didn't select a unit, yet.
5. Critical section doesn't do anything right now as SC2's triggers are executed after another. So there are no race conditions with variable states meaning deadlock's can't occur.
0
Not really possible.
Well, it is possible..
But that would include that you create sets and validators for every vitality value the unit had before and every vitality value the unit had afterwards resulting in an effect. Basically you would branch out for each possible vitality value the unit had before, then deal damage effect and a set effect in each branch. That set effect would result in another branch for every possible vitality value.
In short: you create a graph/tree with every possible combination of outcomes and check each path, if it is the correct one.
That's a ton of data stuff just for 1 weapon (as this might result in thousands of entries for 1 weapon). This makes it possible with data, but it's just the worst solution you can imagine.
-> Use triggers.
0
Made an example map a long time ago, too, and now I updated it for multiple players and bank version usage which allows you to patch your banks.
Here it is: https://dl.dropboxusercontent.com/u/4479839/bankTest.SC2Map
I added a lot of comments to it. I hope you can get an idea what is going on and what is done.
0
Warhound is in the base swarm mod. It was a unit appearing in campaign and beta.
The multi dependency that holds the multiplayer balance changes removes it from multiplayer.
Blizzard didn't tidy up that aspect before the release because it's not really required. Maybe they weren't sure if they won't have to patch the warhound back into multiplayer again, didn't want to spend time to do something that doesn't really effect anyone or they kept it because they knew they wanted to use the model for aprils fools.
0
The UI editor presents you all the UI layouts in the game in one place, so you don't need to find & extract them in all the MPQ files. Also, it provides you with a tree where you can easily check which frames are contained in another.
The code you use is exactly the same as in the old method. So, the transition mainly consists out of copy + paste. It's just the place where your UI code is is much nicer.
Well, basically, there is no new method. It's the same thing, just in a better working environment.
0
1. Events can't use functions in their definition. Use the conditions or the first few actions to filter for specific players.
2. Preload is a dummy action in the editor. The editor will remove the action internally and note down the player number and the used string to upload and share that player slot's bank file during map's loading screen among the other players.
You must write down the bank name and the player name as values and not function calls/variables/etc for the preload.
However, the other actions can use variables as they are real actions that are executed during the map.
3. New bank files are always unverified. But they were initially empty. I would suggest that you analyze the status of the saving at map start for the players instead checking that everytime you save something.
Have a look at my bank demo map. At least I hope this file was that.
https://dl.dropboxusercontent.com/u/4479839/bankTest.SC2Map
0
What bug?
0
I've no small changes, but pretty much for the things that could be effected by that like mana and life regeneration bonus, I calculate the amount when it is required and not only once.
So, instead of adding/subtracting the value, save the info that you need to calculate the offset. Then calculate the new value based on your default value. This way you will never have problems like this. At least you won't notice them as you can't do that much about it.
My approach in diablo is a pretty solid one as it stands on default values which it keeps using to calculate new values when something is changed. For example, the matter that you equip items does not matter unlike D2 where it matters. I'm checking things for item requirements as a whole. It has a much worse performance, but it cannot fail unless there is a clear bug in my code.
0
I finally managed to create a player colored image. I figured that my code will be helpful to others.
But currently, it has a problem with updating its color when the observer changes the player vision with team colors enabled as seen here.
0
He tinkered with Blizzard's interfaces and now got a task in his company to create an observer UI. Thus, he needs to learn it.
Also, I just found out that you can just test interfaces that are components folders without the saving error. Technically it's a mod and not a limited interface then, but it works better for testing.
0
Use a buff behavior with stacks to slow the unit for a percentage of the current speed. It will work just like your triggers (=same math), just the values are restored without calculation errors as it recalculates a new value instead of re-adding calculation errors resulting in permanently lost speed.
0
Oh, we met in reddit already when I gave you some feedback about your interface. :D
Also, yay, for information systems. I'm working on finishing my Bachelors degree in that right now. Well, sort of, the actual name is "Wirtschaftsinformatik" in German, my master would be called IS.
Welcome and enjoy the stay, learn and ask.
If you want to crash the editor and the game with a compiled interface, I know a way. ;)
Anyway, these Tutorials might interest you.
Interfaces use xml code that was first used in a UI modification method we called "aiur chef method". With the UI module in the editor, you can write and create Layout files in there.
SC2 has an ingame UI editor that is available via editor tests ("test document" button). It's default hotkey is ctrl + alt + F12. It's great to alter a few values and find offsets to make things look right or to learn the structure of existing elements.
The files/aspects you can alter in interfaces are shown here.
Use Blizzard's interfaces as a reference. They contain pretty much every aspect you can do with interfaces.
The best way to test interfaces is to take a map from battle.net, set player 1 and 2 to computer in the Map->PlayerProperties, set all other slots to "None", set the default observed player to Neutral, save the map without a space in a folder named "Maps" within your SC2 installation folder and put the file name like "InterfaceTestMap.SC2Map" in the options as default used map.
Then you can just "test document" your interface.
Ingame, you can write "speed #" with # = speed value. If you write "speed 8", the game runs with 8 times the "normal" game speed. This makes testing your interface much faster. With the "Numpad +" on your keyboard you can return to the default "Faster" speed.
If you alter the interface code in an external XML editor like notepadPP and it fails to save the file because the file is still in use (= map still loaded in sc2), then you need to re-paste your code into the layout and compile+save again after closing the map. The editor forgets that it compiled the pasted code. It even forgets that there is new code in the displayed layout file.
And I think that is everything that comes to my mind that you might want to know.
Enjoy. :D
0
alter cliff levels: no
alter textures: place splat actors everywhere
alter water: hardcode all states you want. Water is limited to a 4x4 square now. Water can only switch its states. (I don't think we can alter it with catalog, but I didn't try it)
alter camera height: no, I don't think so.
alter pathing: create units with footprints
alter clipping of things (like terrain not rendered far enough around the screen creating problems): camera data should contain a setting to alter the clip ranges
Some people here made random terrain:
- iIiIiIiIiIi or however his name was made a pretty awesome random world that can change dynamically. In his mod, the player is some kind of god ordering people and casting spells.
- Zolden made one which visually simulates cliffs and tries to make them not too ugly. He also made another one before with rivers and simple mountains (doodads for mountains).
- TwoDie made one that can create rivers, places trees and mountains. It can be seen in his map "Age of Knights".
- I made random dungeon levels featuring 3 different styles and 1x1 tile based lava rivers.
In any way, random terrain will require you to use units and actors.
0
As willuwontu explained, you need to add a condition for that. That condition needs to fail, when it was used before, so it only works once.
As you are hiding buttons after usage for all players, you can just use that as your condition, if the button's actions are executed or not.
Here is your trigger with a few changes:
1. You don't need to iterate over the player numbers. You have triggering player and that's all information you need.
2. AND in conditions contains a list of conditions that it connects. OR does the same.
The contained elements within that list all need to return true for the AND to return true.
Every list with conditions automatically acts like an AND. So, you don't need to add an AND into the IF.
3. The "Zerg_Choose_Race_Button" 's visibility to the using player determines if the button was clicked or not.
4. The whole dialog's visibility to the player determines that the player didn't select a unit, yet.
5. Critical section doesn't do anything right now as SC2's triggers are executed after another. So there are no race conditions with variable states meaning deadlock's can't occur.
0
new frametype:
PlayerRaceIconFrame
<BaseTexture val="texture.dds"/>
<PlayerId val="1"/>
<VersusModePlayerSide val="Left"/>
But PlayerId is currently crashing the editor and the game when it's trying to parse it.
0
Preset. Must be there.