I was hoping to add animation renaming to my very simple and small M3 model editor that nobody knows about, since the Dominion Kill Team Marauder has an animation labeled as (None) which is a two-handed attack that would have been perfect for a map I recently made. :P
Also there are no triggers to generate terrain so that work around doesn't work.
There is a type of actor called a Terrain Deformer, which can modify the height of a patch of terrain. Those and doodads can be created with the Create Actor trigger. So you can modify terrain to a fair extent via triggers. Water can also be changed via triggers, of course, along with thunder/lightning/fog/clouds/wind (again through Create Actor).
Everyone wants more cliff levels, and there are some fairly difficult ways to pull off the look of more cliff levels, albeit with some issues. I, personally, wanted to change the height of the cliff levels I already had access to. But when I attempted this, I always ended up with hideous black gaps, and the cliff faces always stayed the same height.
I thought, well, maybe the cliff mesh models need to be modified.
Then I made a new Terrain Cliff Mesh in the data edtor and set its heights to 2.5 and 5.0, made a new Terrain Cliff in the data editor to reference said mesh, and added that to the Agria texture set. If you did only this much, of course, you get huge holes in your terrain instead of any sort of cliff face where you apply this new type of cliff.
So I extracted the CliffNatural0 models. I spent a while researching, then I wrote a program to scale the height of all .m3 models contained within a given folder. I used this on CliffNatural0 (the program automatically renamed these files to CliffTall0) and imported the resulting files.
Voila. I've successfully changed the height of cliffs, with no bad graphical effects unless you connect the different cliff types (shown in the middle).
Speculation: There should be some type of cliff booster doodad or terrain object or whatever, or some way to get one, to cause the higher cliff levels to actually be treated as higher. What happens if you set Boost Cliff to 1 on a bridge on cliff level 3 that has cliffs of levels 2 and 3 next to it? Can units on the other cliffs see units on the bridge? If the game internally supports more than 3 cliff levels, and if that works, you can have quite a few. However, you can't smoothly stack these additional cliff levels atop one another unless you apply the old "cover the gaps with doodads" trick.
(This image shows the highest level of Tall cliff placed on top of the highest level of normal Agria cliff, with gaps in the cliff face and especially corners.)
This adds a few hundred kilobytes to your map size (since there are 156 models for CliffNatural0), and the transition is smooth going from one type of cliff to a different type on top of it, as long as you align their bottoms and make sure the difference in height is correct for the cliff models you're using. (In my case, I changed my Tall cliff's heights from 2.5 and 5.0 to 2.0 and 4.5 to verify this.)
Shorter cliffs, of course, are also doable.
The attached map contains CliffHuge0, CliffHuge1, CliffTall0, CliffTall1, CliffShort0, and CliffShort1 models, but it only has the data entries for a few of them.
I don't know anything about custom UI stuff, but that's what you'd be dealing with when trying to remove that button, I believe. Otherwise, doing the following could possibly remove the button.
You can disable resource trading with triggers. "Set Resource Trading Allowed" is the action. However, preventing the distribution of resources when a player leaves is more complicated. I haven't tried it as far as I can recall, but I think you'd need to track the player's current resources, then when a player leaves, you'd have to pick each active player and subtract [that player's resources divided by the number of active players] from the picked player's resources. I'm sure there are a few other ways of doing it, but I'm pretty sure it wouldn't be sufficient to just set the leaver's resources to 0 because the Player Leaves event is triggered (I think) after the resources are distributed.
Make the tree unit into a structure, with a structure footprint, for other units to path around trees correctly.
You shouldn't need a special "kill tree" actor term if you make a tree unit; simply make the tree unit's actor from a structure's/other unit's actor (you mostly have to change the model after duplicating it), and it'll automatically be set up to play the tree's Death animation when the unit dies. You do have to use the correct trees, though, since only the Agria tree models have a "chopped down"-looking death animation. See "Actors->Unit/GenericUnitStandard/DestructibleKorhalTree", which uses the AgriaTree Model, and for its death animations, the KorhalTreeDeath0# Models, where # is the number of the model's variation, 0 through 7. You'll want to copy its events that contain a DeathCustomize term to your tree actor.
Edit: Oh, heh. You don't need to do any of that. Korhal Tree - Destructible is already a unit. You just might want to uncheck its unit Unselectable property.
I believe you'll have to use the Actor data instead. For the sake of simplicity, you could probably use the Create Actor trigger at run-time rather than placing them on the map manually, if there aren't too many.
You could change the scale in the model instead of the actor. You can also change the unit's UI - Fog Visibility property so that it doesn't appear at all when the unit is not currently in sight. Either of these should fix it.
You might have put some space between them. Find and disable the random rotation feature for those doodads when you place them, or select all of them (click one and use the Select Special option from the Edit menu) and change their rotation to 0, so you can see how well you've placed them.
Additionally (and this is what the issue probably is), they will not block line of sight for any flying units or any units which have the vision height property set to a number above 0.
They are invisible in-game, but if they were invisible in the editor, you would have no way to see where you placed them.
I had a bunch of really stupid, random, and weird problems with AI on my map, and it seems it was partly due to the lack of cliffs and LoS blockers... The AI wouldn't expand to the center base, but they would long-range mine it, until I put a bunch of the curtain doodads on it. But I dunno about them only mining...
You can make a unit smoothly rise via the Modify Unit type of effect; it has a Height and a Height Time, and the Height Time tells it how long it should take to rise to the given height. I'd probably give the drone unit a behavior with this as the initial effect. However, if the drone is made through an Arm Magazine ability, you can skip the behavior and put the Modify Unit effect into the Effect - Launch section of that ability.
0
I was hoping to add animation renaming to my very simple and small M3 model editor that nobody knows about, since the Dominion Kill Team Marauder has an animation labeled as (None) which is a two-handed attack that would have been perfect for a map I recently made. :P
0
You can also make even deeper cliffs using the CliffHuge0 models from the map I posted here: http://www.sc2mapster.com/forums/development/terrain/31148-taller-cliffs/#p1
(Increasing the height of cliff models by 100% allows you to change the lowest cliff level of -8 to -16, for example.)
0
Okay, so, that guy necroed, but I've come into so many old posts looking for answers that I really want to say this.
There is a type of actor called a Terrain Deformer, which can modify the height of a patch of terrain. Those and doodads can be created with the Create Actor trigger. So you can modify terrain to a fair extent via triggers. Water can also be changed via triggers, of course, along with thunder/lightning/fog/clouds/wind (again through Create Actor).
0
Everyone wants more cliff levels, and there are some fairly difficult ways to pull off the look of more cliff levels, albeit with some issues. I, personally, wanted to change the height of the cliff levels I already had access to. But when I attempted this, I always ended up with hideous black gaps, and the cliff faces always stayed the same height.
I thought, well, maybe the cliff mesh models need to be modified.
Then I made a new Terrain Cliff Mesh in the data edtor and set its heights to 2.5 and 5.0, made a new Terrain Cliff in the data editor to reference said mesh, and added that to the Agria texture set. If you did only this much, of course, you get huge holes in your terrain instead of any sort of cliff face where you apply this new type of cliff.
So I extracted the CliffNatural0 models. I spent a while researching, then I wrote a program to scale the height of all .m3 models contained within a given folder. I used this on CliffNatural0 (the program automatically renamed these files to CliffTall0) and imported the resulting files.
Voila. I've successfully changed the height of cliffs, with no bad graphical effects unless you connect the different cliff types (shown in the middle).
Speculation: There should be some type of cliff booster doodad or terrain object or whatever, or some way to get one, to cause the higher cliff levels to actually be treated as higher. What happens if you set Boost Cliff to 1 on a bridge on cliff level 3 that has cliffs of levels 2 and 3 next to it? Can units on the other cliffs see units on the bridge? If the game internally supports more than 3 cliff levels, and if that works, you can have quite a few. However, you can't smoothly stack these additional cliff levels atop one another unless you apply the old "cover the gaps with doodads" trick.
(This image shows the highest level of Tall cliff placed on top of the highest level of normal Agria cliff, with gaps in the cliff face and especially corners.)
This adds a few hundred kilobytes to your map size (since there are 156 models for CliffNatural0), and the transition is smooth going from one type of cliff to a different type on top of it, as long as you align their bottoms and make sure the difference in height is correct for the cliff models you're using. (In my case, I changed my Tall cliff's heights from 2.5 and 5.0 to 2.0 and 4.5 to verify this.)
Shorter cliffs, of course, are also doable.
The attached map contains CliffHuge0, CliffHuge1, CliffTall0, CliffTall1, CliffShort0, and CliffShort1 models, but it only has the data entries for a few of them.
0
I don't know anything about custom UI stuff, but that's what you'd be dealing with when trying to remove that button, I believe. Otherwise, doing the following could possibly remove the button.
You can disable resource trading with triggers. "Set Resource Trading Allowed" is the action. However, preventing the distribution of resources when a player leaves is more complicated. I haven't tried it as far as I can recall, but I think you'd need to track the player's current resources, then when a player leaves, you'd have to pick each active player and subtract [that player's resources divided by the number of active players] from the picked player's resources. I'm sure there are a few other ways of doing it, but I'm pretty sure it wouldn't be sufficient to just set the leaver's resources to 0 because the Player Leaves event is triggered (I think) after the resources are distributed.
0
Try setting the tree unit's minimap radius to 0.
Make the tree unit into a structure, with a structure footprint, for other units to path around trees correctly.
You shouldn't need a special "kill tree" actor term if you make a tree unit; simply make the tree unit's actor from a structure's/other unit's actor (you mostly have to change the model after duplicating it), and it'll automatically be set up to play the tree's Death animation when the unit dies. You do have to use the correct trees, though, since only the Agria tree models have a "chopped down"-looking death animation. See "Actors->Unit/GenericUnitStandard/DestructibleKorhalTree", which uses the AgriaTree Model, and for its death animations, the KorhalTreeDeath0# Models, where # is the number of the model's variation, 0 through 7. You'll want to copy its events that contain a DeathCustomize term to your tree actor.
Edit: Oh, heh. You don't need to do any of that. Korhal Tree - Destructible is already a unit. You just might want to uncheck its unit Unselectable property.
0
I believe you'll have to use the Actor data instead. For the sake of simplicity, you could probably use the Create Actor trigger at run-time rather than placing them on the map manually, if there aren't too many.
0
It's an Action you can use in a trigger. You make a For Each Integer action, and inside that, you put the "Create Unit with Default Facing" action.
0
You could change the scale in the model instead of the actor. You can also change the unit's UI - Fog Visibility property so that it doesn't appear at all when the unit is not currently in sight. Either of these should fix it.
0
You might have put some space between them. Find and disable the random rotation feature for those doodads when you place them, or select all of them (click one and use the Select Special option from the Edit menu) and change their rotation to 0, so you can see how well you've placed them.
Additionally (and this is what the issue probably is), they will not block line of sight for any flying units or any units which have the vision height property set to a number above 0.
They are invisible in-game, but if they were invisible in the editor, you would have no way to see where you placed them.
0
65535 is the limit of a 16-bit unsigned integer. I highly doubt there is any way to raise it.
0
Use Status of Player instead. (Or maybe use a Player Leaves the Game event.)
0
I had a bunch of really stupid, random, and weird problems with AI on my map, and it seems it was partly due to the lack of cliffs and LoS blockers... The AI wouldn't expand to the center base, but they would long-range mine it, until I put a bunch of the curtain doodads on it. But I dunno about them only mining...
0
It's looking for the index of the town. Try Declare Town Specific Slot with an index of 0 and the start location you want, and then Set Main Town 0.
0
You can make a unit smoothly rise via the Modify Unit type of effect; it has a Height and a Height Time, and the Height Time tells it how long it should take to rise to the given height. I'd probably give the drone unit a behavior with this as the initial effect. However, if the drone is made through an Arm Magazine ability, you can skip the behavior and put the Modify Unit effect into the Effect - Launch section of that ability.