How did you "fix" that attacking through walls?
That might be super interesting for my map, too, because my dungeons are basically the same as your self created dungeons and atm my monsters go berserk through half the dungeon, if they are behind the wall in another room... :(
In general I would only know the structure or what you used to achieve a working result. I can figure out the details myself.
Posting battle.net complains here has no effect.
If you post your concerns in a friendly way in Blizzard's forums the developers have a chance that your feature request will be kept in mind when some Blizzard guy has to do an improved battle.net for the arcades.
Yes, that is what I want. Any explanation how sotis does it? :p
You create a dialog for each hero and attach it to the hero.
Then you create an action definition which updates the health bars and all information as images how you want them onto that dialog. The health bars would be resized images on the dialog.
You would update the dialog whenever the unit takes damage and/or within a neverending loop with waits.
Now you only need a way to hide the dialog, if the dialog is above the HUD of the game. I would ask Bibendus how that is done because I'm bad with trigonometry and didn't do much with cameras.
Also, you might need the player's screen resolution for that. Just search for get resolution and you should find a library where someone implemented a method to receive it.
I guess with HotS you could do that properly because that functionality (fully working dialog on unit in terms of default UI underlapping) is used in Blizzard Dota.
Show/Hide Game UI seems to have some hard-coded additional functionality like showing the credits.
Also I think I had a problem before with hiding multiple times and I think it worked again with showing again.
But I changed my code to hide/show only once per player which should be the general rule with that state (because of its strange behavior),
-> Don't do multiple show/hide Game UI for each player !
"pick each unit"... use that construct thing where you can define a unit variable. "Picked unit" is a big source of errors and strange behavior especially with waits. Just use a local variable and the loop where you have to set the variable. It might be called "For each unit in unit group".
Also, the design is bad because every second a thread will be created and you might not know which unit is already stutter-stepping, so you could have 2 units with the same stutter-step micro code running, so it will be order way to often.
In addition to that no more than 1 marine for each thread will stutter-step at the same time because you have a wait inside the loop.
Also, your closest enemy isn't necessarily an enemy unit, it could be an allied hover unit. But maybe all enemy units are hover units...
And your first if-condition doesn't really do anything.
A trigger that is active forms a "thread". One trigger can spawn multiple threads.
A slightly better approach for your trigger would be to:
0. Event is map initialization. Execute steps 1-5 in a never ending loop.
1. save marines in unit group
2. iterate through the unit group, find closest enemy unit, order to attack
3. wait ... game seconds
4. iterate through the unit group, find closest enemy unit, order to move
5. wait .. game seconds
Also, a loop might be better than a periodic event.
Just start the trigger at map initialization and let your code run in a loop with correct waits. This way it can't run in multiple instances and should have better performance than your first approach.
To improve it you could make the marine unit group a global variable and just add every marine that is spawned to it to avoid periodic searches for all marines.
Or maybe there is a way to make the difference between cursor colors "louder"?
You can edit the mouse image in data (cursors). Then you can have something different than the 4 colored target pointers.
At least I guess that modifying these works.
These are folders exported from the mpq.
These folders were added in the mpq file when Aiur Chef mod was released or on PTR or somewhere around then, if I remember it correctly.
Health is a property of the unit which can be read by triggers. It will return a real value, so make sure you save it in a "real" variable (real is a data type).
To make a bar which is fixed on the player screen, you need a dialog and a image.
Then you have 2 options:
- resizing the image (-> image stretches)
- resizing the dialog (-> image is cut off)
While creating the image, the anchor of the image is important.
If you want to make dialogs attached for something like heroes (as seen in SOTIS and Hive Keeper or in other MOBA games like League of Legends), you would need to calculate for each player, if the dialog needs to be set visible or not because it overlaps with the default's game UI.
If you want that, waiting for Heart of the Swarm and learning other things now instead might be better.
At least I hope Heart of the Swarm adds that functionality properly because they need this for their DOTA map.
If you are monitoring FPS, make sure the debugger is set to the threads tab because triggers and variables can cause lags like crazy. If you have messages displayed in the debugger (trigger starts, errors, ...) disable these. But best is to test it without debugger in fullscreen.
I was able to drop my FPS from capped 60 to 4 (!) with 1 trigger, 1 event which was unit attacked in my case and 2 zerglings of p1 and p15 which had a damage effect of 0 within the duration of a few minutes. That's how much the debugger can eat with the wrong settings (basically displaying everything and active trigger tab).
If the problem exists without having the debugger started with the map (just closing it is not enough), something on the map eats up the FPS.
Since you checked for actors, you might want to check the unit count before and after that level. Maybe there are dead units remaining that still eat up the FPS because of their presence (they don't even need to be on screen).
Other stuff that I could imagine:
- non-removed persistent effects
- buffs on some units that have very high stack counts
So try to remove all units for testing after that level. Maybe that will raise the FPS back to a high value again.
@achievement icons
No, you need to cut it into new files and import them. :(
@timings with while
Try to minimize the code (-> workload) that is executed. Normally that's the best way. Check the debugger's activity to see how much your implementation costs.
The best way really depends on what you are doing.
0
@Bibendus: Go
How did you "fix" that attacking through walls?
That might be super interesting for my map, too, because my dungeons are basically the same as your self created dungeons and atm my monsters go berserk through half the dungeon, if they are behind the wall in another room... :(
In general I would only know the structure or what you used to achieve a working result. I can figure out the details myself.
0
You forgot the ".On" and ".Off" after the behaviors in the actor events.
0
It doesn't crash for me. Only rarely when I try to close it after it was open for like many many hours.
It slows down like crazy over time, though...
0
Posting battle.net complains here has no effect.
If you post your concerns in a friendly way in Blizzard's forums the developers have a chance that your feature request will be kept in mind when some Blizzard guy has to do an improved battle.net for the arcades.
0
You create a dialog for each hero and attach it to the hero.
Then you create an action definition which updates the health bars and all information as images how you want them onto that dialog. The health bars would be resized images on the dialog.
You would update the dialog whenever the unit takes damage and/or within a neverending loop with waits.
Now you only need a way to hide the dialog, if the dialog is above the HUD of the game. I would ask Bibendus how that is done because I'm bad with trigonometry and didn't do much with cameras.
Also, you might need the player's screen resolution for that. Just search for get resolution and you should find a library where someone implemented a method to receive it.
I guess with HotS you could do that properly because that functionality (fully working dialog on unit in terms of default UI underlapping) is used in Blizzard Dota.
0
Did you try to show it twice? (I am serious)
Show/Hide Game UI seems to have some hard-coded additional functionality like showing the credits.
Also I think I had a problem before with hiding multiple times and I think it worked again with showing again.
But I changed my code to hide/show only once per player which should be the general rule with that state (because of its strange behavior),
-> Don't do multiple show/hide Game UI for each player !
0
"pick each unit"... use that construct thing where you can define a unit variable. "Picked unit" is a big source of errors and strange behavior especially with waits. Just use a local variable and the loop where you have to set the variable. It might be called "For each unit in unit group".
Also, the design is bad because every second a thread will be created and you might not know which unit is already stutter-stepping, so you could have 2 units with the same stutter-step micro code running, so it will be order way to often.
In addition to that no more than 1 marine for each thread will stutter-step at the same time because you have a wait inside the loop.
Also, your closest enemy isn't necessarily an enemy unit, it could be an allied hover unit. But maybe all enemy units are hover units...
And your first if-condition doesn't really do anything.
A trigger that is active forms a "thread". One trigger can spawn multiple threads.
A slightly better approach for your trigger would be to:
0. Event is map initialization. Execute steps 1-5 in a never ending loop.
1. save marines in unit group
2. iterate through the unit group, find closest enemy unit, order to attack
3. wait ... game seconds
4. iterate through the unit group, find closest enemy unit, order to move
5. wait .. game seconds
Also, a loop might be better than a periodic event.
Just start the trigger at map initialization and let your code run in a loop with correct waits. This way it can't run in multiple instances and should have better performance than your first approach.
To improve it you could make the marine unit group a global variable and just add every marine that is spawned to it to avoid periodic searches for all marines.
0
The "Conjoined" behavior type makes units share the damage they receive.
But if one dies, all other units die, too.
This has been used for the trains in the campaign.
0
You can edit the mouse image in data (cursors). Then you can have something different than the 4 colored target pointers.
At least I guess that modifying these works.
0
These are folders exported from the mpq.
These folders were added in the mpq file when Aiur Chef mod was released or on PTR or somewhere around then, if I remember it correctly.
0
Health is a property of the unit which can be read by triggers. It will return a real value, so make sure you save it in a "real" variable (real is a data type).
To make a bar which is fixed on the player screen, you need a dialog and a image.
Then you have 2 options:
- resizing the image (-> image stretches)
- resizing the dialog (-> image is cut off)
While creating the image, the anchor of the image is important.
If you want to make dialogs attached for something like heroes (as seen in SOTIS and Hive Keeper or in other MOBA games like League of Legends), you would need to calculate for each player, if the dialog needs to be set visible or not because it overlaps with the default's game UI.
If you want that, waiting for Heart of the Swarm and learning other things now instead might be better.
At least I hope Heart of the Swarm adds that functionality properly because they need this for their DOTA map.
0
@SkrowFunk: Go You can hit ctrl + alt + F to toggle sc2's fps display.
0
If you are monitoring FPS, make sure the debugger is set to the threads tab because triggers and variables can cause lags like crazy. If you have messages displayed in the debugger (trigger starts, errors, ...) disable these. But best is to test it without debugger in fullscreen.
I was able to drop my FPS from capped 60 to 4 (!) with 1 trigger, 1 event which was unit attacked in my case and 2 zerglings of p1 and p15 which had a damage effect of 0 within the duration of a few minutes. That's how much the debugger can eat with the wrong settings (basically displaying everything and active trigger tab).
If the problem exists without having the debugger started with the map (just closing it is not enough), something on the map eats up the FPS.
Since you checked for actors, you might want to check the unit count before and after that level. Maybe there are dead units remaining that still eat up the FPS because of their presence (they don't even need to be on screen).
Other stuff that I could imagine:
- non-removed persistent effects
- buffs on some units that have very high stack counts
So try to remove all units for testing after that level. Maybe that will raise the FPS back to a high value again.
0
@achievement icons
No, you need to cut it into new files and import them. :(
@timings with while
Try to minimize the code (-> workload) that is executed. Normally that's the best way. Check the debugger's activity to see how much your implementation costs.
The best way really depends on what you are doing.
0
Fix all players disconnect -> end game please
it just doesn't work on EU atm. Had a 3vs3, enemy names grayed out and that's all...
also, I would like to switch the blue color to green. I've a hard time seeing all blue projectiles good enough.
If people leave during victory screen (with teammates), you won't get the victory dialog to click on...
edit:
- ctf takes to long (had a 32 minute match... my first defeat on EU :S )
- spree stuff stops after a time... I had a spree of 19.