It was more of an example of how to set up a simple typical whirlpool.
In your case, the whirlpool could be a projectile unit with a behavior triggering the whole sequence above. The main differences would be the Search Effect searching around "source" rather than target, and Apply Force pushing units towards (none):Source instead of (Foobar):target.
The idea would be to simply find all units below height X, where height X would increase over time as lava raises, and apply on the units some behavior dealing damage over time.
If you meant UnitBehaviorRemovePlayer(), it doesn't pick one behavior from the stack that is owned by the specified player, I don't think you can directly remove a behavior owned by a specific player (dirty work-arounds might be possible with remove validators using the behavior's caster).
In all programming languages, Switch() is normally translated to an indexed jump tables. In Galaxy, it's translated just as a long list of if/else if/else if/else... so it's not really any more efficient.
The concepts for the map are good, different from most other maps. It sounds fun to play, especially if it's a 2 players map.
It's a long learning process but you'll find plenty of resources and people to help you along the way. Feel free to ask any specific question you want, that's what the forums are there for. The map sounds fun so I wouldn't mind giving you my Instant Messaging information if you want someone to ask questions to. There's also the IRC channel, of course.
You need to :
a) Create a Create Persistent effect (which we'll call FooBar for further reference), that will run over a couple seconds with a period of 0.0625.
b) The Create Persistent effect needs to call (every 0.0625) a Search Area effect around Target Point.
c) Have Search Area catch the units desired within a radius around Target Point.
d) That Search Area needs to call a "Set" effect which will contain two things : Apply Behavior, and Apply Force.
e) The Apply Behavior must apply a behavior on all target units that give them a minimum movement speed, or a maximum movement speed, or both, or whatever looks right for the kind of effect you want.
f) The Apply Force area must apply the force on every unit found by the search. So "Unit+" is set to Target. Now, the "Target: Location" must be the target point of the ability, hence you must specify the point that was the target of the effect we called FooBar in step 'a'. End result should be visible as (Foobar):Target Point, not (None):whatever.
You can trigger that whole sequence as the impact of a launch missile if you want, of course.
Ah sorry, I assumed you were talking about a doodad or other model of some sort.
Are you saying one of the floor's textures becomes transparent, letting you see other floor textures? This looks so weird, is the floor a mixture of multiple textures at that point?
If anything, one could open up the map with a MPQ editor and inspect the XML files to see what exactly is there. There has to be something to block pathing. King, just attach the map to the post.
0
It was more of an example of how to set up a simple typical whirlpool.
In your case, the whirlpool could be a projectile unit with a behavior triggering the whole sequence above. The main differences would be the Search Effect searching around "source" rather than target, and Apply Force pushing units towards (none):Source instead of (Foobar):target.
0
How often the texture repeats itself by unit of distance, it's the texture's scale.
0
Damage aura?
The idea would be to simply find all units below height X, where height X would increase over time as lava raises, and apply on the units some behavior dealing damage over time.
0
Close, it's actually "Change water to state X over Y seconds".
For that to work, you have to create multiple states for your water, which you can then smoothly switch between in trigger code.
0
If you meant UnitBehaviorRemovePlayer(), it doesn't pick one behavior from the stack that is owned by the specified player, I don't think you can directly remove a behavior owned by a specific player (dirty work-arounds might be possible with remove validators using the behavior's caster).
In all programming languages, Switch() is normally translated to an indexed jump tables. In Galaxy, it's translated just as a long list of if/else if/else if/else... so it's not really any more efficient.
0
First, don't despair!
The concepts for the map are good, different from most other maps. It sounds fun to play, especially if it's a 2 players map.
It's a long learning process but you'll find plenty of resources and people to help you along the way. Feel free to ask any specific question you want, that's what the forums are there for. The map sounds fun so I wouldn't mind giving you my Instant Messaging information if you want someone to ask questions to. There's also the IRC channel, of course.
I look forward to playing your map! :)
0
Thanks for the compilation of backgrounds and borders, very nice!
0
Every Damage-type effect has a reduction of damage per point of armor. Most attacks have 1 there, most spells have 0.
Furthermore, there's a global "minimum damage" setting that's 1 to default. If left unchanged, no unit can take less than 1 damage to an attack.
0
Okay, the whole setup is kind of incorrect.
You need to :
a) Create a Create Persistent effect (which we'll call FooBar for further reference), that will run over a couple seconds with a period of 0.0625.
b) The Create Persistent effect needs to call (every 0.0625) a Search Area effect around Target Point.
c) Have Search Area catch the units desired within a radius around Target Point.
d) That Search Area needs to call a "Set" effect which will contain two things : Apply Behavior, and Apply Force.
e) The Apply Behavior must apply a behavior on all target units that give them a minimum movement speed, or a maximum movement speed, or both, or whatever looks right for the kind of effect you want.
f) The Apply Force area must apply the force on every unit found by the search. So "Unit+" is set to Target. Now, the "Target: Location" must be the target point of the ability, hence you must specify the point that was the target of the effect we called FooBar in step 'a'. End result should be visible as (Foobar):Target Point, not (None):whatever.
You can trigger that whole sequence as the impact of a launch missile if you want, of course.
0
Ah sorry, I assumed you were talking about a doodad or other model of some sort.
Are you saying one of the floor's textures becomes transparent, letting you see other floor textures? This looks so weird, is the floor a mixture of multiple textures at that point?
0
Data editor, select the model object, set Occlusion to "Show".
0
If anything, one could open up the map with a MPQ editor and inspect the XML files to see what exactly is there. There has to be something to block pathing. King, just attach the map to the post.
0
Is the trigger debugging window active? Check in File->Preferences->Test map. Also make sure you aren't opening the debugging window from triggers.
0
Get a MPQ editor, open your map, open MapScript.galaxy
You'll see 3 times the line :
include "TriggerLibs/NativeLib"
Delete 2, keep one.
0
Well, there has to be *something*.
No doodads in area? (drag-select to see if there are invisible ones)
No explicit pathing? (select terrain pathing tool and look)
If all else fails, you could post the map or a simplified version of it.