This would require updating every unit weapon. However, it seems that the great majority of weapons just work right out of the box using Photoless's solution. At the time he reported that you had to uncheck some of the weapon flags for it to work, but this does not seem to be the case, at least not any more. So far only a few weapons seem to not work right away because of idiosyncracies... ie the diamondback weapon effect validates for some reason that the diamondback is not hidden...
Anyways I think we can just have the APC weapon effect issue the APC an order to redirect attack(in this case a copy of redirect attack which does not include self). So no trigger needed for that. However I think triggers will still ultimately be required for modifying the range of the APC to reflect the lowest range among the loaded units.
Photoless apparently discovered the solution to this issue last year in this thread.
Basically just make a buff which enables the attack class of abilities. Make both an add and a remove behavior effect for this buff. Now change the transport ability of your APC so that the cargo load effect adds the buff and the cargo unload effect removes it. Now your APC will work while moving with most units. Fantastic! Good job Photoless!
Even though this very simple solution basically works we still need some polish. First we will need to give the APC a dummy weapon which does no damage so it will chase targets in the manner we expect. Also It would make the most sense if the range of this dummy weapon is the same as(or slightly less than) the lowest range of any unit housed within.
The second major control issue is properly handling any attack orders which are issued when we are outside of the range of some of our cargo units. What we want is for the APC to chase to within range, and then automatically issue an attack redirect on the target.
Anyways I intend to make a polished implementation for my map sometime this evening, and I will post it here.
I did some experimenting and apparently you can get loaded units to fire even with the attack - redirect button grayed out while moving if the units weapon is allowed to fire while moving and the weapon options Only Fire At Attack Target, Only Fire While Attacking, and Requires Enabled Attack Ability are all unchecked. At least I was able to get it to work with marauders. I am not sure if it has always been this way or if this only just now works.
So it should be possible to accomplish attack-while-moving-bunkers by simply giving every loadable unit a duplicate weapon with those flags unchecked and which validates to make sure that it will only fire when loaded or hidden or whatever.
However you would still need to solve the issue of how the player goes about ordering the loaded units to focus fire on a particular target while moving, since the attack-redirect button would be grayed out. Presumably this could be done with triggers.
Yes that medivac you saw was from my map Heaven Besieged.
The fundamental problem is that the redirect attack type ability of a bunker cannot be used while moving.
I spent quite a bit of time trying to figure out how to enable it while moving and decided that this was just not possible.
So I went around the problem. There are actually 2 medivacs in HB. The visible one which moves around like a normal unit, and an invisible, invincible copy of it which never moves, but is periodically teleported to the location of the visible medivac. The invisible medivac is the one with the actual redirect attack ability, while the visible medivac has instead a dummy weapon just to let you issue the attack orders and whatnot.
Anyways implementing all this takes quite a bit of work and even then will never quite work perfectly. You need triggers to turn the orders given to the visible unit into orders for the invisible unit, and you need to make sure that the units loaded in the invisible unit match those loaded in the visible one. It took me awhile to get right and I'm not really sure whether it was worth it in the end =P.
If you want to see exactly how I did it, Heaven Besieged is unlocked and can be downloaded from battle.net using the editor.
You can get two separate supply icons. You just have to custom make the one for protoss. Basically just make a small dialog with background image set to black.dds and add an image dialog item for the supply icon and a label item for the readout, and periodically update the label to read out the protoss supply usage.
I dunno then. You could have a trigger detect whenever that player created a protoss unit and then Set Unit State: Uses Supply off, and then manually handle the supply used with your own integer variable... but you still wouldn't be able to make a protoss unit if you didn't have sufficient spare supply. I guess you could go through each protoss unit in the editor and remove the supply requirement... but that might not be appropriate to your map.
EDIT: I just made a test map where i had no issue building marines via player 2's (ally with shared spending) barracks.
I just set up the alliances and made sure player 2 had enough minerals and supply. I do not seem to have run into whatever issue you are having.
Game speed does not simply control how fast the game plays out- it also affects how often SC2 must calculate a game frame. A game frame happens every 0.0625 GAME TIME seconds. Less game frames => Less CPU load. By lowering game speed we seek to increase the coarseness with which SC2 divides up time. However lowering game speed also slows down the game, so we speed it back up manually. I don't know how much simpler I can explain this...
I included a test map which demonstrates that this method works for loads just consisting of lots of units pathing. The test map has no significant background triggers. It just spawns units periodically(real time). Indeed there is no reason to think this would help at all for CPU-load caused by triggers. If for some reason you don't believe what I am saying, please examine the test map on low settings and monitor your frame rate as the map transitions to slower speed.
Also I agree that normal is a good speed to run at. But I think this is so because the coarseness with which it divides time up offers a good balance of smoothness and low load. I strongly encourage map makers to generally use normal speed and for only the most unit-intensive maps to use slow speed. I recommend against any map using slower.
Faster is the default speed, so most maps are not running on normal. Moreover most people have been operating under the assumption that game speed does nothing more than control the rate the game plays at. Thus they have seen no reason to switch off the default. It is my hope that some of them see this thread and learn otherwise.
I find it hard to believe that simply using a different gamespeed causes disconnects and desyncs.
My published map, Heaven Besieged, has long used a trigger to set game speed to slow and add a compensating timescale and has never had any desync or disconnect problems.
How did you implement the changed gamespeed?
Could you upload the map here so I can test this as well?
You seem to have misinterpreted the whole point of the discussion. We want to lower game speed because it can reduce CPU load due to less game frames happening per real second. However we do not want to change the rate that the game plays out. ie, We do not want units to move or attack any faster or slower. Thus we must compensate for all the timing changes that lowering the game speed will bring about.
Normal does have that nice attraction, but the default speed is faster, so most maps will just end up as that. Most map makers have probably thought game speed to be totally unimportant... that there was no reason to go through the effort of changing. I certainly thought that way until intractable lag issues prompted me to do some experimentation.
Romexiom, I would recommend not slowing things all the way down to slower; it is just too extreme. Slower was presumably designed as the absolutely slowest speed Blizz felt offered an acceptable game experience. I found slower to be unacceptable for Heaven Besieged. I ended up using slow with compensating timescale and no one has complained of stutteriness(and a lot less people now complain of lag). Anyways, I suppose Faster was also presumably optimized to be the fastest speed Blizz found which still offered meaningful responsiveness/smoothness improvement. As such it is also a fairly extreme value. If you are going to go through a lot of work to rescale all the timings in your map by hand, I would recommend trying for normal gamespeed first, as it is unlikely to cause significant responsiveness/smoothness issues.
Also there is a trigger that locks the gamespeed midgame... I would guess that means it prevents B.net from allowing players to slow down the game? You might see if that helps some.
0
@Doubleclick123: Go
What you suggest would actually require quite a lot of work. Photoless's solution is much more elegant.
0
@DrSuperEvil: Go
This would require updating every unit weapon. However, it seems that the great majority of weapons just work right out of the box using Photoless's solution. At the time he reported that you had to uncheck some of the weapon flags for it to work, but this does not seem to be the case, at least not any more. So far only a few weapons seem to not work right away because of idiosyncracies... ie the diamondback weapon effect validates for some reason that the diamondback is not hidden...
Anyways I think we can just have the APC weapon effect issue the APC an order to redirect attack(in this case a copy of redirect attack which does not include self). So no trigger needed for that. However I think triggers will still ultimately be required for modifying the range of the APC to reflect the lowest range among the loaded units.
0
Forget the above two posts completely.
Photoless apparently discovered the solution to this issue last year in this thread.
Basically just make a buff which enables the attack class of abilities. Make both an add and a remove behavior effect for this buff. Now change the transport ability of your APC so that the cargo load effect adds the buff and the cargo unload effect removes it. Now your APC will work while moving with most units. Fantastic! Good job Photoless!
Even though this very simple solution basically works we still need some polish. First we will need to give the APC a dummy weapon which does no damage so it will chase targets in the manner we expect. Also It would make the most sense if the range of this dummy weapon is the same as(or slightly less than) the lowest range of any unit housed within.
The second major control issue is properly handling any attack orders which are issued when we are outside of the range of some of our cargo units. What we want is for the APC to chase to within range, and then automatically issue an attack redirect on the target.
Anyways I intend to make a polished implementation for my map sometime this evening, and I will post it here.
0
I did some experimenting and apparently you can get loaded units to fire even with the attack - redirect button grayed out while moving if the units weapon is allowed to fire while moving and the weapon options Only Fire At Attack Target, Only Fire While Attacking, and Requires Enabled Attack Ability are all unchecked. At least I was able to get it to work with marauders. I am not sure if it has always been this way or if this only just now works.
So it should be possible to accomplish attack-while-moving-bunkers by simply giving every loadable unit a duplicate weapon with those flags unchecked and which validates to make sure that it will only fire when loaded or hidden or whatever.
However you would still need to solve the issue of how the player goes about ordering the loaded units to focus fire on a particular target while moving, since the attack-redirect button would be grayed out. Presumably this could be done with triggers.
0
@kogits35: Go
Yes that medivac you saw was from my map Heaven Besieged.
The fundamental problem is that the redirect attack type ability of a bunker cannot be used while moving. I spent quite a bit of time trying to figure out how to enable it while moving and decided that this was just not possible.
So I went around the problem. There are actually 2 medivacs in HB. The visible one which moves around like a normal unit, and an invisible, invincible copy of it which never moves, but is periodically teleported to the location of the visible medivac. The invisible medivac is the one with the actual redirect attack ability, while the visible medivac has instead a dummy weapon just to let you issue the attack orders and whatnot.
Anyways implementing all this takes quite a bit of work and even then will never quite work perfectly. You need triggers to turn the orders given to the visible unit into orders for the invisible unit, and you need to make sure that the units loaded in the invisible unit match those loaded in the visible one. It took me awhile to get right and I'm not really sure whether it was worth it in the end =P.
If you want to see exactly how I did it, Heaven Besieged is unlocked and can be downloaded from battle.net using the editor.
0
@GunGryphon: Go
Sorry, too late to be of any help I am sure, but hovering cliff jumpers can be caused by time scale > 1.
0
@Gradius12: Go
You can get two separate supply icons. You just have to custom make the one for protoss. Basically just make a small dialog with background image set to black.dds and add an image dialog item for the supply icon and a label item for the readout, and periodically update the label to read out the protoss supply usage.
0
@Gradius12: Go
I dunno then. You could have a trigger detect whenever that player created a protoss unit and then Set Unit State: Uses Supply off, and then manually handle the supply used with your own integer variable... but you still wouldn't be able to make a protoss unit if you didn't have sufficient spare supply. I guess you could go through each protoss unit in the editor and remove the supply requirement... but that might not be appropriate to your map.
EDIT: I just made a test map where i had no issue building marines via player 2's (ally with shared spending) barracks. I just set up the alliances and made sure player 2 had enough minerals and supply. I do not seem to have run into whatever issue you are having.
0
@Gradius12: Go
There is a trigger, set alliance aspect. One of the aspects you can choose is resource spending(distinct from resource trading).
0
@Gradius12: Go
Perhaps have a dummy ally player own all the protoss junk and have it give the user control?
0
@SouLCarveRR: Go
Game speed does not simply control how fast the game plays out- it also affects how often SC2 must calculate a game frame. A game frame happens every 0.0625 GAME TIME seconds. Less game frames => Less CPU load. By lowering game speed we seek to increase the coarseness with which SC2 divides up time. However lowering game speed also slows down the game, so we speed it back up manually. I don't know how much simpler I can explain this...
I included a test map which demonstrates that this method works for loads just consisting of lots of units pathing. The test map has no significant background triggers. It just spawns units periodically(real time). Indeed there is no reason to think this would help at all for CPU-load caused by triggers. If for some reason you don't believe what I am saying, please examine the test map on low settings and monitor your frame rate as the map transitions to slower speed.
Also I agree that normal is a good speed to run at. But I think this is so because the coarseness with which it divides time up offers a good balance of smoothness and low load. I strongly encourage map makers to generally use normal speed and for only the most unit-intensive maps to use slow speed. I recommend against any map using slower.
Faster is the default speed, so most maps are not running on normal. Moreover most people have been operating under the assumption that game speed does nothing more than control the rate the game plays at. Thus they have seen no reason to switch off the default. It is my hope that some of them see this thread and learn otherwise.
0
@egodbout: Go
I find it hard to believe that simply using a different gamespeed causes disconnects and desyncs. My published map, Heaven Besieged, has long used a trigger to set game speed to slow and add a compensating timescale and has never had any desync or disconnect problems.
How did you implement the changed gamespeed? Could you upload the map here so I can test this as well?
0
@SouLCarveRR: Go
You seem to have misinterpreted the whole point of the discussion. We want to lower game speed because it can reduce CPU load due to less game frames happening per real second. However we do not want to change the rate that the game plays out. ie, We do not want units to move or attack any faster or slower. Thus we must compensate for all the timing changes that lowering the game speed will bring about.
0
@TheZizz: Go
Normal does have that nice attraction, but the default speed is faster, so most maps will just end up as that. Most map makers have probably thought game speed to be totally unimportant... that there was no reason to go through the effort of changing. I certainly thought that way until intractable lag issues prompted me to do some experimentation.
0
@romexiom: Go
Romexiom, I would recommend not slowing things all the way down to slower; it is just too extreme. Slower was presumably designed as the absolutely slowest speed Blizz felt offered an acceptable game experience. I found slower to be unacceptable for Heaven Besieged. I ended up using slow with compensating timescale and no one has complained of stutteriness(and a lot less people now complain of lag). Anyways, I suppose Faster was also presumably optimized to be the fastest speed Blizz found which still offered meaningful responsiveness/smoothness improvement. As such it is also a fairly extreme value. If you are going to go through a lot of work to rescale all the timings in your map by hand, I would recommend trying for normal gamespeed first, as it is unlikely to cause significant responsiveness/smoothness issues.
Also there is a trigger that locks the gamespeed midgame... I would guess that means it prevents B.net from allowing players to slow down the game? You might see if that helps some.