Wonder if this is consistent across different makes of computers?
Of course it is otherwise everyone would be out of sync all the time when playing multiplayer!
I used a stopwatch and compared 5 minutes real time to 5 minutes "Blizzard Real Time" and it doesn't add up.
In what way did they not add up? What was the test code and the result?
If you want to really wait 1 second, you need to wait .97 "Real Time" seconds via trigger.
Sounds a lot like rounding error. It is possible that game speeds are not nice whole numbers of internal fames per second (how the game tracks time) and so "Real Time" conversion is rounded down to the nearest internal frame count. In any case a 3% error in time is minimal and well within the variances of human cognition, especially if sound is not affected.
Look at how the melee AI is constructed. You basically need to make sure the build requirements flag is enabled and then order them to stock at least the desired number of that unit periodically. Unit stock orders have to be refreshed periodically (every 30-60 seconds) as well since the AI may forget them. If some units have particularly complex requirements it may not be possible for the AI to infer what must be done so one will either have to order they be stocked explicitly, or even design custom AI logic to help them meet the requirements.
For a simple AI a good idea is to design your stocking logic into different tiers. Tiers are advanced once certain requirements are met, such as building availability or game time. One can separate the base stocking and army stocking logic as usually a common base allows for many different army compositions that should be chosen dynamically based on the enemy composition, but this is a more advanced AI feature.
The main problems mentioned above with StarCraft II is a change in general player habits rather than anything to do with Blizzard.
StarCraft II engine was made during the early days of wide spread truly simultaneous multi threading. It edged on faster dual cores with only 2 heavy threads, as opposed to where computers actually went with slightly slower quad cores, and now going towards hex and oct cores. It was also created just before entering the era of the monster graphic cards so was designed to support some pretty old D3D9 style hardware as opposed to taking full advantage of the cutting edge D3D10 hardware. In fact the game engine was so optimized around this style of graphics it is one of the few game engines that has been known to cause hardware damage to GPUs due to it making them use so much power, although that is really a design flaw with the GPU hardware/driver.
All this means the game has not aged well, in fact it might even be aging worse than Warcraft III. Warcraft III will run extremely well on pretty much any modern computer that has a CPU and a GPU from the last 10 years, even integrated GPUs. StarCraft II on the other hand still needs a pretty decent computer to run well, and even then it can still cause modern GPUs to overheat under some conditions. It also seems that Blizzard has given up modernizing the SC2 engine, since HotS constantly receives performance optimizations and new features that will likely never be ported back to StarCraft II.
A lot of old Warcraft III players did not move to StarCraft II, instead moving on to discrete MOBA games, mobile games or even giving up gaming for social networking. A lot of old Warcraft III developers gave up modding StarCraft II due to early day problems. StarCraft II also did not attract the flood of "trash" content that populated Warcraft III custom game list for years since it has more strict publishing rules and the editor requires a little more intelligence to use. Many of the better Warcraft III creators grew out of this style of content creation entirely and moved on to creating their own independent games. The real nail in the coffin is the false news style dark cloud that constantly covers StarCraft II of all the "arcade issues" that were fixed early on but people still insist that they exist and constantly spam about them everywhere.
That said StarCraft II arcade should not be under estimated. If your map is good it can get access to thousands of players, far more than Warcraft III ever allowed (most players were there to only play DotA Allstars). Additionally if one works with the game engine rather than against it one can create some highly polished content. If enough people published decent new content to the Arcade StarCraft II could still take off, since playing the same old maps does get boring eventually.
StarCraft II also never got the technical expertise that Warcraft III got. There was no generation of people like Vexorian for StarCraft II early on. It took several years before the model format was finally cracked, and even then it was done largely by the Warcraft III technical community. The lack of such expertise is obvious and unfortunately does not help the game's image as there are many wide spread StarCraft II technical documents or tutorials that are just out right wrong. For example the belief that running actions in new thread makes them run in parallel on multi core systems and that synchronization is needed between threads is entirely wrong, as the game uses a similar trigger threading/scheduling model as Warcraft III so only 1 thread can run at any time and all state is consistent between threads so there is no concept such as synchronization.
The direct way would require triggering the damage, computing the damage amount based on the unit energy vital and other data. The indirect way would be to use triggers to add/remove buff charges based on the energy vital amount and each buff increases ability type damage by a small fraction.
StarCraft II does not support this as far as I am aware. Heroes of the Storm needed special mechanics added to it so they could efficiently create Li Ming Arcane Orb and other abilities that scale with distance travelled.
Both DrSuperEvil's approaches sound a sensible work around depending on which sort of scaling you want. However they might not be completely accurate in the case of projectile linked damage where a projectile is launched and the launcher moves. If the launcher moves away from the target it might increase the damage, and like wise if it moves towards the target the game might be decreased.
If a projectile is used another approach would be to periodically increment a buff/charge on the projectile unit and deal damage based on the number of such buff/charge. This is the travel time of the projectile which translates into a duration.
Make sure the building footprints are flush square with the placement grid. It is possible there are tiny gaps which are big enough for the path finder to find a route through but too small for any unit to practically fit through.
Units are not always factored in by the path finder since unit on unit collision is more physics based. In such case I recommend placing all player controlled units on a different collision layer so they cannot be used to block the walkers.
Instead of killing the players maze in the case of a blockage, detect when they try to make a blockage (eg placing the final building to make a solid wall) and then cancel that building. This is far more user friendly as it does not heavily punish accidental blocking.
The idea is to use a marker validator to test if search targets have been hit already. When you deal damage to a search target you add the same marker link to it as the marker you test for. On top of those recommended examples there is also the penetration rounds from WoL, Kerrigan charge and various other abilities from Heart of the Swarm and the laser sweep from LotV. One can be sure coop commanders use this functionality a lot however those mods are restricted so hard to view.
Is it an actual duplicate unit? Or a duplicate actor for the same unit? That trigger does not create any units at all so if a duplicate unit is created then it would be due to data.
I think the biggest problem could be that it blatantly violates copyright as I doubt you have permission from the Dragonball creators to make this. There is a reason so few maps exist based on popular branded content. Ones like Pokémon maps have been removed due to copyright infringement.
You could try using triggers to find a target closest to the spawner and ordering the attack wave there.
Keep the victim in a group and keep ordering the attack wave to them ever few seconds until dead or far enough away. This prevents them from being kited between multiple nearby units.
Suicide does work. The units may start with the main base but after that they will search and destroy everything.
It is also possible the reason they do not attack the nearest unit is because the AI player does not know there are units there but does know there is a base there. Maybe removing fog of war for the AI player could solve this.
It is also possible that suicide wave behaves differently from suiciding units individually as it tries to act more intelligently. Experiment with both.
It is getting the timer dialog template (used by all timer dialogs) to perform an animation event, or that is how it looks at least. I am guessing they added some functionality in void to flash the timer dialog or emphasise it and that is broken until one explicitly animates it.
0
Sounds a lot like rounding error. It is possible that game speeds are not nice whole numbers of internal fames per second (how the game tracks time) and so "Real Time" conversion is rounded down to the nearest internal frame count. In any case a 3% error in time is minimal and well within the variances of human cognition, especially if sound is not affected.0
Look at how the melee AI is constructed. You basically need to make sure the build requirements flag is enabled and then order them to stock at least the desired number of that unit periodically. Unit stock orders have to be refreshed periodically (every 30-60 seconds) as well since the AI may forget them. If some units have particularly complex requirements it may not be possible for the AI to infer what must be done so one will either have to order they be stocked explicitly, or even design custom AI logic to help them meet the requirements.
For a simple AI a good idea is to design your stocking logic into different tiers. Tiers are advanced once certain requirements are met, such as building availability or game time. One can separate the base stocking and army stocking logic as usually a common base allows for many different army compositions that should be chosen dynamically based on the enemy composition, but this is a more advanced AI feature.
0.963130173062453
The main problems mentioned above with StarCraft II is a change in general player habits rather than anything to do with Blizzard.
StarCraft II engine was made during the early days of wide spread truly simultaneous multi threading. It edged on faster dual cores with only 2 heavy threads, as opposed to where computers actually went with slightly slower quad cores, and now going towards hex and oct cores. It was also created just before entering the era of the monster graphic cards so was designed to support some pretty old D3D9 style hardware as opposed to taking full advantage of the cutting edge D3D10 hardware. In fact the game engine was so optimized around this style of graphics it is one of the few game engines that has been known to cause hardware damage to GPUs due to it making them use so much power, although that is really a design flaw with the GPU hardware/driver.
All this means the game has not aged well, in fact it might even be aging worse than Warcraft III. Warcraft III will run extremely well on pretty much any modern computer that has a CPU and a GPU from the last 10 years, even integrated GPUs. StarCraft II on the other hand still needs a pretty decent computer to run well, and even then it can still cause modern GPUs to overheat under some conditions. It also seems that Blizzard has given up modernizing the SC2 engine, since HotS constantly receives performance optimizations and new features that will likely never be ported back to StarCraft II.
A lot of old Warcraft III players did not move to StarCraft II, instead moving on to discrete MOBA games, mobile games or even giving up gaming for social networking. A lot of old Warcraft III developers gave up modding StarCraft II due to early day problems. StarCraft II also did not attract the flood of "trash" content that populated Warcraft III custom game list for years since it has more strict publishing rules and the editor requires a little more intelligence to use. Many of the better Warcraft III creators grew out of this style of content creation entirely and moved on to creating their own independent games. The real nail in the coffin is the false news style dark cloud that constantly covers StarCraft II of all the "arcade issues" that were fixed early on but people still insist that they exist and constantly spam about them everywhere.
That said StarCraft II arcade should not be under estimated. If your map is good it can get access to thousands of players, far more than Warcraft III ever allowed (most players were there to only play DotA Allstars). Additionally if one works with the game engine rather than against it one can create some highly polished content. If enough people published decent new content to the Arcade StarCraft II could still take off, since playing the same old maps does get boring eventually.
StarCraft II also never got the technical expertise that Warcraft III got. There was no generation of people like Vexorian for StarCraft II early on. It took several years before the model format was finally cracked, and even then it was done largely by the Warcraft III technical community. The lack of such expertise is obvious and unfortunately does not help the game's image as there are many wide spread StarCraft II technical documents or tutorials that are just out right wrong. For example the belief that running actions in new thread makes them run in parallel on multi core systems and that synchronization is needed between threads is entirely wrong, as the game uses a similar trigger threading/scheduling model as Warcraft III so only 1 thread can run at any time and all state is consistent between threads so there is no concept such as synchronization.
0
One can also modify experience with triggers so one could trigger an experience system that shares experience in the way you want.
0
The direct way would require triggering the damage, computing the damage amount based on the unit energy vital and other data. The indirect way would be to use triggers to add/remove buff charges based on the energy vital amount and each buff increases ability type damage by a small fraction.
0.9623944742901
StarCraft II does not support this as far as I am aware. Heroes of the Storm needed special mechanics added to it so they could efficiently create Li Ming Arcane Orb and other abilities that scale with distance travelled.
Both DrSuperEvil's approaches sound a sensible work around depending on which sort of scaling you want. However they might not be completely accurate in the case of projectile linked damage where a projectile is launched and the launcher moves. If the launcher moves away from the target it might increase the damage, and like wise if it moves towards the target the game might be decreased.
If a projectile is used another approach would be to periodically increment a buff/charge on the projectile unit and deal damage based on the number of such buff/charge. This is the travel time of the projectile which translates into a duration.
0.962680883472963
Make sure the building footprints are flush square with the placement grid. It is possible there are tiny gaps which are big enough for the path finder to find a route through but too small for any unit to practically fit through.
Units are not always factored in by the path finder since unit on unit collision is more physics based. In such case I recommend placing all player controlled units on a different collision layer so they cannot be used to block the walkers.
Instead of killing the players maze in the case of a blockage, detect when they try to make a blockage (eg placing the final building to make a solid wall) and then cancel that building. This is far more user friendly as it does not heavily punish accidental blocking.
0
To expand on what DrSuperEvil has said.
The idea is to use a marker validator to test if search targets have been hit already. When you deal damage to a search target you add the same marker link to it as the marker you test for. On top of those recommended examples there is also the penetration rounds from WoL, Kerrigan charge and various other abilities from Heart of the Swarm and the laser sweep from LotV. One can be sure coop commanders use this functionality a lot however those mods are restricted so hard to view.
0
Maybe another trigger is the cause? Or perhaps a create unit effect in data?
0
Is it an actual duplicate unit? Or a duplicate actor for the same unit? That trigger does not create any units at all so if a duplicate unit is created then it would be due to data.
0
I think the biggest problem could be that it blatantly violates copyright as I doubt you have permission from the Dragonball creators to make this. There is a reason so few maps exist based on popular branded content. Ones like Pokémon maps have been removed due to copyright infringement.
0
You could try using triggers to find a target closest to the spawner and ordering the attack wave there.
Keep the victim in a group and keep ordering the attack wave to them ever few seconds until dead or far enough away. This prevents them from being kited between multiple nearby units.
0
Suicide does work. The units may start with the main base but after that they will search and destroy everything.
It is also possible the reason they do not attack the nearest unit is because the AI player does not know there are units there but does know there is a base there. Maybe removing fog of war for the AI player could solve this.
It is also possible that suicide wave behaves differently from suiciding units individually as it tries to act more intelligently. Experiment with both.
0
It is getting the timer dialog template (used by all timer dialogs) to perform an animation event, or that is how it looks at least. I am guessing they added some functionality in void to flash the timer dialog or emphasise it and that is broken until one explicitly animates it.
0
Looks almost as if the countdown text is being blended in under the dialog frame. Does your map modify the standard UI?