For a maze type of thing i would set the camera bounds to a radius of N around the selected unit(s). Minimap and camera problem solved. Minimap still available but contains primarly a big green block which is your unit(s)
Alright so we don't have access to mouse move, and with how triggers etc work there are valid reasons for it not being an event. But then again camera moves are events, er.. well when i think about it it doesn't make sense but we have what we have.
Anyways so just use
CameraForceMouseRelative
right?
Well i need y mouse motion to translate to camera z in that case, any suggestions?
@kozm0naut: One region encompasses the area that should be evaluated as multi-plane. When a unit enters this region it’s cliff level is checked and either. a) Nothing happends if it’s on the lower plane. b) The unit is on the upper plane and ignores terrain height (SetUnitState), and receives a new height from the point set.
Each cliff level has a region that defines the collision, touching this region is considered a collision and the unit is denied movement. This is the same behavior as the normal collision has, the path finding does try to take the shortest path however, and in this case takes the wrong choice the unit is closer to the bridge than the ramp.
@ezbeats:
Those just define which planes a unit can be attacked on (Gravity Beam works by changing this to Air).
I’ll post the map later, already trying a different approach.
0
For a maze type of thing i would set the camera bounds to a radius of N around the selected unit(s). Minimap and camera problem solved. Minimap still available but contains primarly a big green block which is your unit(s)
0
Check Camera Move and just clamp the values?
0
Alright so we don't have access to mouse move, and with how triggers etc work there are valid reasons for it not being an event. But then again camera moves are events, er.. well when i think about it it doesn't make sense but we have what we have. Anyways so just use
CameraForceMouseRelative
right?
Well i need y mouse motion to translate to camera z in that case, any suggestions?
0
Considered the max level dial box on the upgrade itself? -.-
0
Or just use score values
0
The Create Dialog is bugged, just edit the field manually after creating.
0
i.e
0
CatalogFieldValueSet
0
You can change the mover for a unit type through catalogs but not for a unit.
0
Use conditions.
0
Thread has not been deleted.
And i already gave you a solution.
0
PortraitCreate
Create a dummy dialog or just detect screen clicks.
0
Been working on a survival map for some time now(which deals with timers constantly), never ran into any issues.
0
@kozm0naut:
One region encompasses the area that should be evaluated as multi-plane.
When a unit enters this region it’s cliff level is checked and either.
a) Nothing happends if it’s on the lower plane.
b) The unit is on the upper plane and ignores terrain height (SetUnitState), and receives a new height from the point set.
Each cliff level has a region that defines the collision, touching this region is considered a collision and the unit is denied movement.
This is the same behavior as the normal collision has, the path finding does try to take the shortest path however, and in this case takes the wrong choice the unit is closer to the bridge than the ramp.
@ezbeats:
Those just define which planes a unit can be attacked on (Gravity Beam works by changing this to Air).
I’ll post the map later, already trying a different approach.
0
<<reply 97621>>
PathingModify(region inArea, int inType, bool inAdd);
PathingUpdate();
PathingReset();
What do you mean working properly? timers work just fine