I would advise looking into how Blizzard has made the Skeletal Mage ultimate for Xul in Heroes of the Storm. The most recent version of it summons units in an orientation that are rotated by dragging your mouse cursor before releasing. Since HotS is based on the same engine as SC2 it is possible the same mechanics can be used, assuming there have not been too many major diversions between the game engines.
If using such mechanics is possible, one would create a unit at the initial target and then rotate it to the drag vector, using triggers if required.
Edit: Will we not lose the ability to use hotkeys for inventory slots in that case? The number of item slots seems to be maxed out already - attempting to add an item slot would require some of the slots to be converted to a container, no?
Possibly. As I said before, there did not appear to be any non-trivial solution and hence why the issue still exists.
This has always been a problem in the map. At some stage it was high priority for me to fix however it did not seem easy so my time was better devoted elsewhere.
I would suggest trying to add a hidden inventory slot that only accepts magazines. When one is picked up into that slot you move it into inventory, or drop it if the rest of the inventory is full.
The problem is your color randomization system. The way you implemented it has a chance to create too many nested trigger threads. The result is that the main initialization thread does not manage to fully execute.
After disabling the action to run the color randomization trigger, initialization worked all the time.
To assign players a unique random color, start by adding all available colors to a list (array). Then for each player who you want to have a random unique color you pull out the color at a random index from the list. To pull an element out of a list, all subsequent elements are shuffled down 1 position and the list size is decremented by 1. Since order is not important during random selection, you can simplify this to moving the last element of the list to the position of the element that was just pulled. This approach allows a unique item to be chosen at random with a complexity of O(1) and with invariant runtime duration.
I will start looking into the problem. Although I will try to prioritize it, it may take a few days depending on how difficult it is to find the cause.
How can I see if there are any script runtime errors being logged?
Usually they appear in the error log window at the top of the screen when testing the map. Error logging can be explicitly turned off however, using one of the map settings
And I don't think I can see when and where the triggers are going wrong - since it happens "Only" in the map's very first second - and every single trigger with "Map Initialization" Events doesn't work. AND this doesn't happen all the time but randomly.
Break points you insert from a previous test of the map are remembered when you restart the map. This allows you to break during execution of the map initialization functions.
What you are describing is symptomatic of a thread crash. The initialization is being stopped at some stage before completion. This can be caused by a fatal galaxy error or if the thread is hitting its operation limit. This is a common problem with Warcraft III maps however I have never seen it reported in a StarCraft II map before.
EDIT: I've tried to use the Debugging window and didn't work as well. The game stays in a black screen and never progresses until I turn off the debugging window.
This sounds like the debugger is set to break on error. The first galaxy runtime error that occurs will cause the debugger to pause execution at the point of the error. Useful for identifying the cause of a specific error.
You can resume execution by right clicking on the script window and selecting the appropriate button (something like "resume"). It will then continue execution until either another script error occurs, or a break point is reached.
Although I don't like this idea, I could send you the map to your Email if you want to take a look, since with this error persisting, the map can't go on.
This is usually the best way to diagnose such obscure problems such as this. Simplest approach is to upload the map and all required mods to a free cloud storage service like DropBox, OneDrive or Google and share a public link to it via Private Message, and then delete it from the cloud after it has been downloaded. The reason this is generally better than email is because some email services, especially those that are free, limit the maximum size of received attachments and some maps can be several hundred megabytes in size.
In case you are worried about my credibility, I have worked on maps such as Undead Assault 3 and Special Forces Elite 5 under the name DrSuperGood.
Can you create an example map where this problem can be recreated? Otherwise the problem could be due to a conflict with the system in your map and not with the system itself.
Are there any script runtime errors being logged? These often reveal why triggers are not working.
Try debugging what is happening. Enable the trigger debugger (editor preferences, test in windowed mode and turn on trigger debugger). You can insert break points and inspect variable values to try and identify what is going wrong and where it happens.
Check the bank contains the appropriate number of kills for your user account. Different regions and map test account are all separate so have separate banks.
I advise preloading the bank using the appropriate preload system instead of using those deprecated actions. They might not be reliable.
I advise not saving the bank immediately after loading it. Nothing will have changed that needs to be written.
There are 2 types of drop pod. You have not made it clear which you are referring to.
For trained unit drops, eg Raynor barracks dropping at rally point, the drop pod works by instantly hiding the trained unit, doing the drop pod art, and then unhiding the trained unit after the impact time.
For units created after the drop pod lands, eg Zagara drop, the drop pod art is created and then the unit is created after the impact time.
For trained drops you can move the hidden unit anywhere you want at any time after training. It should even unhide automatically after the drop art finished. You could also force it to unhide immediately by removing the buff used.
For drops that create units then you cannot move the units until after the drop has completed. It can be done the instant the drop finished but not before because no units exist yet that can be moved. One could alter such drops to allow movement by using a dummy unit (the drop pod?) and always spawning the units at the unit location rather than the original target location. One can then move this dummy unit around with triggers and the drops will be move appropriately.
To create multiple unit types from a drop that creates units you use a set effect to run multiple create unit effects at once.
You should be able to move them immediately as they are created but hidden until the drop pod lands. They might only become visible at their new location after the pod lands however.
Mineral Income
Events
Timer - Every 1.0 seconds of Game Time
Local Variables
unit = No Unit <Unit>
Conditions
Actions
Unit Group - Pick each unit in (Any units in (Entire map) owned by player Any Player matching Excluded: Missile, Dead, Hidden, with at most Any Amount) and do (Actions)
Actions
Variable - Set unit = (Picked unit)
General - If (Conditions) then do (Actions) else do (Actions)
If
(Unit type of unit) == Zergling
Then
Player - Modify player (Owner of unit) Minerals: Add 1
Else
Every second pick each Zergling unit in the region and add 1 mineral to the owner of picked unit player. A more efficient approach might be to track entry, exit and death however for now simply picking the units should be sufficient.
Why must they be attackable? If you want them to be destroyed you can give them an ability to self destruct, see the bunker salvage ability for an idea how to make one. If they are to act as gates you can give them a morph ability that morphs them into a lowered or raised form appropriately. Otherwise you can stop them taking all damage from anyone but the owner by giving them a buff behaviour to reduce all such damage to 0.
0.967391304347826
I would advise looking into how Blizzard has made the Skeletal Mage ultimate for Xul in Heroes of the Storm. The most recent version of it summons units in an orientation that are rotated by dragging your mouse cursor before releasing. Since HotS is based on the same engine as SC2 it is possible the same mechanics can be used, assuming there have not been too many major diversions between the game engines.
If using such mechanics is possible, one would create a unit at the initial target and then rotate it to the drag vector, using triggers if required.
0
0
This has always been a problem in the map. At some stage it was high priority for me to fix however it did not seem easy so my time was better devoted elsewhere.
I would suggest trying to add a hidden inventory slot that only accepts magazines. When one is picked up into that slot you move it into inventory, or drop it if the rest of the inventory is full.
0
The problem is your color randomization system. The way you implemented it has a chance to create too many nested trigger threads. The result is that the main initialization thread does not manage to fully execute.
After disabling the action to run the color randomization trigger, initialization worked all the time.
To assign players a unique random color, start by adding all available colors to a list (array). Then for each player who you want to have a random unique color you pull out the color at a random index from the list. To pull an element out of a list, all subsequent elements are shuffled down 1 position and the list size is decremented by 1. Since order is not important during random selection, you can simplify this to moving the last element of the list to the position of the element that was just pulled. This approach allows a unique item to be chosen at random with a complexity of O(1) and with invariant runtime duration.
0
I will start looking into the problem. Although I will try to prioritize it, it may take a few days depending on how difficult it is to find the cause.
0
The download link produces a 404 error. I do not think it is set to allow public downloads.
0
Usually they appear in the error log window at the top of the screen when testing the map. Error logging can be explicitly turned off however, using one of the map settings
Break points you insert from a previous test of the map are remembered when you restart the map. This allows you to break during execution of the map initialization functions.
What you are describing is symptomatic of a thread crash. The initialization is being stopped at some stage before completion. This can be caused by a fatal galaxy error or if the thread is hitting its operation limit. This is a common problem with Warcraft III maps however I have never seen it reported in a StarCraft II map before.
This sounds like the debugger is set to break on error. The first galaxy runtime error that occurs will cause the debugger to pause execution at the point of the error. Useful for identifying the cause of a specific error.
You can resume execution by right clicking on the script window and selecting the appropriate button (something like "resume"). It will then continue execution until either another script error occurs, or a break point is reached.
This is usually the best way to diagnose such obscure problems such as this. Simplest approach is to upload the map and all required mods to a free cloud storage service like DropBox, OneDrive or Google and share a public link to it via Private Message, and then delete it from the cloud after it has been downloaded. The reason this is generally better than email is because some email services, especially those that are free, limit the maximum size of received attachments and some maps can be several hundred megabytes in size.
In case you are worried about my credibility, I have worked on maps such as Undead Assault 3 and Special Forces Elite 5 under the name DrSuperGood.
0
Can you create an example map where this problem can be recreated? Otherwise the problem could be due to a conflict with the system in your map and not with the system itself.
Are there any script runtime errors being logged? These often reveal why triggers are not working.
Try debugging what is happening. Enable the trigger debugger (editor preferences, test in windowed mode and turn on trigger debugger). You can insert break points and inspect variable values to try and identify what is going wrong and where it happens.
0
Check the bank contains the appropriate number of kills for your user account. Different regions and map test account are all separate so have separate banks.
I advise preloading the bank using the appropriate preload system instead of using those deprecated actions. They might not be reliable.
I advise not saving the bank immediately after loading it. Nothing will have changed that needs to be written.
0.966292134831461
There are 2 types of drop pod. You have not made it clear which you are referring to.
For trained unit drops, eg Raynor barracks dropping at rally point, the drop pod works by instantly hiding the trained unit, doing the drop pod art, and then unhiding the trained unit after the impact time.
For units created after the drop pod lands, eg Zagara drop, the drop pod art is created and then the unit is created after the impact time.
For trained drops you can move the hidden unit anywhere you want at any time after training. It should even unhide automatically after the drop art finished. You could also force it to unhide immediately by removing the buff used.
For drops that create units then you cannot move the units until after the drop has completed. It can be done the instant the drop finished but not before because no units exist yet that can be moved. One could alter such drops to allow movement by using a dummy unit (the drop pod?) and always spawning the units at the unit location rather than the original target location. One can then move this dummy unit around with triggers and the drops will be move appropriately.
To create multiple unit types from a drop that creates units you use a set effect to run multiple create unit effects at once.
0.966165413533835
You should be able to move them immediately as they are created but hidden until the drop pod lands. They might only become visible at their new location after the pod lands however.
0
Something like...
Mineral Income Events Timer - Every 1.0 seconds of Game Time Local Variables unit = No Unit <Unit> Conditions Actions Unit Group - Pick each unit in (Any units in (Entire map) owned by player Any Player matching Excluded: Missile, Dead, Hidden, with at most Any Amount) and do (Actions) Actions Variable - Set unit = (Picked unit) General - If (Conditions) then do (Actions) else do (Actions) If (Unit type of unit) == Zergling Then Player - Modify player (Owner of unit) Minerals: Add 1 Else0
Every second pick each Zergling unit in the region and add 1 mineral to the owner of picked unit player. A more efficient approach might be to track entry, exit and death however for now simply picking the units should be sufficient.
0
You can stop them taking damage from non-owners, but I am not sure it is possible to stop them being attacked by non-owners.
0
Why must they be attackable? If you want them to be destroyed you can give them an ability to self destruct, see the bunker salvage ability for an idea how to make one. If they are to act as gates you can give them a morph ability that morphs them into a lowered or raised form appropriately. Otherwise you can stop them taking all damage from anyone but the owner by giving them a buff behaviour to reduce all such damage to 0.