There are a few avenues you can pursue to make this work.
First, try simply making an upgrade with multiple levels. Each level modifies the unit type's movement speed by a certain amount. Then you can add or remove upgrades using validators or triggers. Using upgrades is more or less the same as using Catalog triggers... the values are just hard-coded.
Another thing you could do is run a loop that picks each unit of type X in the playable map area and modify the picked unit's movement speed. This is basically a walk-around to using Catalog triggers.
Third, you can pick all units as above and apply a buff or debuff which modifies the picked unit's movement speed. If you use this method, I recommend stacking multiple buffs so it's easier to change the movement speed to multiple values.
Create a search behavior that applies a separate behavior on units within radius X with duration 1 and apply the search behavior to every unit. Then in triggers, pick each unit in Entire Map and check if (picked unit) has behavior#2. If TRUE, kill the picked unit, ELSE do nothing. Run this on a loop that repeats every 0.25 seconds or something similar.
Just a tip for future reference, though. You can save a few precious seconds by using the Modify Variable function to increment a variable. For example, you could have used Modify (Hero Current Level[Player] + 1) instead of Variable - Set Hero Current Level[Player] = (Hero Current Level[Player] + 1).
Alternatively, you could have set Hero Current Level[Player] = Experience level of (Triggering unit) at the end of the trigger, outside of the Repeat loop. To make this work, you would have to reference Experience level of (Triggering unit) instead of Hero Current Level[Player] inside your Repeat loop. Either way is fine :)
It doesn't really matter. You could have it checked periodically on an infinite loop, if you wanted. You only need to do the level-up functions when the variable != the unit's level.
It should, since if it fires again and the unit's level is the same as the variable then nothing should happen. You just need to make sure everything is included in your Repeat X loop. Basically you're just having the game check how many levels the unit gets when the level-up event occurs, so the number of times that event occurs is irrelevant if the unit doesn't actually gain any levels.
Create a global integer variable to track the unit's current level. When this event fires, subtract the value of your global variable from the unit's current level. Use a repeat loop, repeating for (level_tracking_variable - unit's current level). At the end of the trigger, set the tracking variable to the unit's current level.
You can give units footprints which block LOS. So when the unit enter's the specified region you can replace those units with others that don't block LOS.
I think I suggested this before, but I would recommend you ask the player what his resolution is the first time he plays the game, then store his answer in a bank. From there, adjust the position of the following image based on the player's resolution. The bank would be useful for avoiding the intrusive dialog every game.
For example, you would move the image to "Position of mouse * offset" where offset is the proportion by which the image is in error. For a resolution of 1920, this proportion offset would be ( 1920 / 1600 = 1.2 ) so when the players mouse X is at 1920, the position of the image is moved to 1600 * 1.2 (which equals 1920.)
I imagine the other resolutions would be done in the same way. You first need to calculate the offset by dividing (X resolution / 1600.) Then multiply that offset by the current position of the image.
Use just actors for doodads that don't require footprints, and units for doodads that do require it. I suppose it depends on how badly you need to improve performance.
It's possible, but if you're getting 180 fps on a "toaster" then performance may not be the real issue with the crashes. Try playing your game online, then look at the debugger log to see if there were any errors. This would be especially valuable if a player happened to crash during the game. You can also track the FPS during the multiplayer match (either write it down periodically or have triggers spit it out.)
Yes but there's no reason he couldn't use both. Using only an actor would be more efficient than a unit but it comes with limitations... it just depends on what the mapmaker needs in a given situation.
0
@Chris97Ong: Go
There are a few avenues you can pursue to make this work.
First, try simply making an upgrade with multiple levels. Each level modifies the unit type's movement speed by a certain amount. Then you can add or remove upgrades using validators or triggers. Using upgrades is more or less the same as using Catalog triggers... the values are just hard-coded.
Another thing you could do is run a loop that picks each unit of type X in the playable map area and modify the picked unit's movement speed. This is basically a walk-around to using Catalog triggers.
Third, you can pick all units as above and apply a buff or debuff which modifies the picked unit's movement speed. If you use this method, I recommend stacking multiple buffs so it's easier to change the movement speed to multiple values.
0
How is the damaging behavior being applied?
This thread might be useful to you.
0
@tatatatate: Go
Alternatively just have behavior#2 kill the unit after a short delay ;)
0
@tatatatate: Go
Alternatively just have behavior#2 kill the unit ;)
0
@HapticMaster: Go
Create a search behavior that applies a separate behavior on units within radius X with duration 1 and apply the search behavior to every unit. Then in triggers, pick each unit in Entire Map and check if (picked unit) has behavior#2. If TRUE, kill the picked unit, ELSE do nothing. Run this on a loop that repeats every 0.25 seconds or something similar.
0
@Zero0018: Go
Swell :)
Just a tip for future reference, though. You can save a few precious seconds by using the Modify Variable function to increment a variable. For example, you could have used Modify (Hero Current Level[Player] + 1) instead of Variable - Set Hero Current Level[Player] = (Hero Current Level[Player] + 1).
Alternatively, you could have set Hero Current Level[Player] = Experience level of (Triggering unit) at the end of the trigger, outside of the Repeat loop. To make this work, you would have to reference Experience level of (Triggering unit) instead of Hero Current Level[Player] inside your Repeat loop. Either way is fine :)
0
It doesn't really matter. You could have it checked periodically on an infinite loop, if you wanted. You only need to do the level-up functions when the variable != the unit's level.
0
@Zero0018: Go
It should, since if it fires again and the unit's level is the same as the variable then nothing should happen. You just need to make sure everything is included in your Repeat X loop. Basically you're just having the game check how many levels the unit gets when the level-up event occurs, so the number of times that event occurs is irrelevant if the unit doesn't actually gain any levels.
0
@Zero0018: Go
Create a global integer variable to track the unit's current level. When this event fires, subtract the value of your global variable from the unit's current level. Use a repeat loop, repeating for (level_tracking_variable - unit's current level). At the end of the trigger, set the tracking variable to the unit's current level.
0
You can give units footprints which block LOS. So when the unit enter's the specified region you can replace those units with others that don't block LOS.
0
Version 1.6
0
I think I suggested this before, but I would recommend you ask the player what his resolution is the first time he plays the game, then store his answer in a bank. From there, adjust the position of the following image based on the player's resolution. The bank would be useful for avoiding the intrusive dialog every game.
For example, you would move the image to "Position of mouse * offset" where offset is the proportion by which the image is in error. For a resolution of 1920, this proportion offset would be ( 1920 / 1600 = 1.2 ) so when the players mouse X is at 1920, the position of the image is moved to 1600 * 1.2 (which equals 1920.)
I imagine the other resolutions would be done in the same way. You first need to calculate the offset by dividing (X resolution / 1600.) Then multiply that offset by the current position of the image.
0
@MaskedImposter: Go
Use just actors for doodads that don't require footprints, and units for doodads that do require it. I suppose it depends on how badly you need to improve performance.
0
@TheLazzoro: Go
It's possible, but if you're getting 180 fps on a "toaster" then performance may not be the real issue with the crashes. Try playing your game online, then look at the debugger log to see if there were any errors. This would be especially valuable if a player happened to crash during the game. You can also track the FPS during the multiplayer match (either write it down periodically or have triggers spit it out.)
0
@MaskedImposter: Go
Yes but there's no reason he couldn't use both. Using only an actor would be more efficient than a unit but it comes with limitations... it just depends on what the mapmaker needs in a given situation.