Hey all,
I'm currently working on a project called Reaper Madness, which will be a third-person shooter wherein your reaper can jetpack over bumpy terrain and even cliffs at a steady height. I currently have this working, less than optimally, without setting my unit to ignore the terrain using the command:
However, it would be much simpler and cleaner code if I could implement this UnitState. What I have found is that after setting this state, whenever I adjust the height of my unit, it acts as if this state were not set.
For instance: The default world height on flat ground with no cliff is 8.0. My unit will start at 0.0 height relative to the ground, which means he's at an absolute value of 8.0. If I set the UnitState to ignore terrain and give him a height of 8.0, he will start at 8.0 height relative to the absolute bottom of the map, which is exactly the same positioning. I can move around, and my unit stays on the ground. However, if I change the height of my unit AFTER setting the ignoreTerrain state, my unit will be positioned relative to the terrain despite the state I've set. I've done many tests to verify that the unit's height and all other related variables are correct and it is in fact the state being ignored.
Has anybody else dealt with this issue? If so, have you found a way around it or can we consider this a bug?
I'm not sure but i believe when you turn the Ignore Terrain Height flag on it resets your unit to the base height 0. What i would do is as soon as you turn the flag on set the units hieght to its previous height again.
Yeah, I'm not sure about that because I have a semi-physics trigger that's setting my height every 0.0 game seconds, so that's definitely not the issue. I've used the TriggerDebugOutput function to verify that my unit's height is correctly set. The flag is being ignored, and my unit is hovering 8.0 above the ground, which is already 8.0 totaling an absolute height of 16.0. As soon as I move, it's corrected and my unit is standing on the ground again. As soon as I change the height again, it breaks. When I move, it fixes.
To reiterate, I've tested my unit's height all points in the scenario I just described and it's always constantly at 8.0. The only thing that changes is whether or not it's relative to the terrain, which means the flag is being ignored in a certain case. That case seems to be any time I change my unit's height.
Oh wow you can change that? The constant flickering from auto-adjustments was driving me nuts
I don't know if you're doing all the movement from instant positioning or some combination of issue ordering, but if the former try reading from stored vectors/points at all times and only writing to the unit, like this:
gameloop(){
newposition = oldPosition + movement;
Turn ignore Height State On
Move unit instantly to newposition
Set unit height to Z-value of newposition
oldPosition = newposition
}
For anybody interested, I developed a cheesy little work-around that I'd rather avoid, but will be using until there's a fix or solution for this issue. Basically, I'm just moving my unit to his current position instantly every time I change my unit's height, so it always acts correctly as if I'm constantly moving, even when I'm not. It's redundant, wastes processing and creates lag I'm sure, but for now it seems to be the only fix.
Now if there were a way to apply this flag to the player's camera, my cliff ignore functionality would be completely seamless.
Oh wow you can change that? The constant flickering from auto-adjustments was driving me nuts
I don't know if you're doing all the movement from instant positioning or some combination of issue ordering, but if the former try reading from stored vectors/points at all times and only writing to the unit, like this:
gameloop(){
newposition = oldPosition + movement;
Turn ignore Height State On
Move unit instantly to newposition
Set unit height to Z-value of newposition
oldPosition = newposition
}
I'm moving by issuing commands, it seems smoother to me. Have you had success making WASD movement + mouselook aiming using instant moves? If so, I will test it out and see how it compares to issuing move commands. I've tested my map on BNet 2.0 and the 125ms minimum lag is looking to be an issue, so if there's any way to make movement more efficient in laggy situations I'm all for it.
In first person it's mostly smooth, once you bring your character on screen the camera does get jerky when turning the character.
Though I imagine you could do the same thing with issue'ing orders as long as the issue order and height offset are right after another in the game loop, I'll give it a go later
I'm moving by issuing commands, it seems smoother to me. Have you had success making WASD movement + mouselook aiming using instant moves? If so, I will test it out and see how it compares to issuing move commands.
I tryed both methods (for camera and for unit) and I perfer gradual move on the character, instant on the camera (as apposed to following the unit). Gradual on the unit because with 2+ players you can see each other and dont want it looking jumpy and instantly comming to a halt (without waitting for the polling timer) is not natural AT ALL. Instant on the camera because the only GOOD way I could find to have it move gradualy (look at and follow actor (actor attached to units head or centre) was smooth as silk BUT when I changed the direction my unit was moving it, the camera would pan around (as it was being dragged by the unit).
As a side note having the camera follow works realy well for first person perspective racing (where unlike a FPS you dont controll your camera/look in different directions to the one your moving) As it auto sets the camera to look at the same pitch/yaw/height/x/y position as the unit (from what ever attachment point position you want) and moves the camera smoothly with the unit rather than jumping it after the unit. (Msg me for code)
However, it would be much simpler and cleaner code if I could implement this UnitState. What I have found is that after setting this state, whenever I adjust the height of my unit, it acts as if this state were not set.
Has anybody else dealt with this issue? If so, have you found a way around it or can we consider this a bug?
I found that when you set a the units flag/place a unit with flag (iggnore terrain height) that the unit is initialy shown at Ground Height at Point + Data->Unit->Art-Height
This is a bug. If you then move your new terrain ignoring unit its height goes nuts, and becomes Max ( 0 OR Art Height - Terrain Height)
I.E. if your terrain is at 9 units heigh, your art height is 10 units heigh, your unit will become 1 unit off the map floor (8 units UNDER the ground)
The acutal unit value will read as it should in debug... verry stange...
To avoid this after creating a flaged unit / changing a reguler unit to have that flag. Just set the height to w/e you want (proberbly terrain height at point) and from then on it will be at EXACTLY that height, reset as you see fit.
This works smoothly, I have used it to make a unit which is normaly ground bound go Flag Active for jumps (so that it can move smoothly over terrain while running, but move un influenced by even the smallest terrain changes while jumping.
(if I used instant move I could ignore this but if there was a spike in the terrain < move distance w/o changing his flag he would ungulate with it.)
I have some thoughts on your other post (about cliffs and jerking) that ill put up in a minute.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hey all, I'm currently working on a project called Reaper Madness, which will be a third-person shooter wherein your reaper can jetpack over bumpy terrain and even cliffs at a steady height. I currently have this working, less than optimally, without setting my unit to ignore the terrain using the command:
However, it would be much simpler and cleaner code if I could implement this UnitState. What I have found is that after setting this state, whenever I adjust the height of my unit, it acts as if this state were not set.
For instance: The default world height on flat ground with no cliff is 8.0. My unit will start at 0.0 height relative to the ground, which means he's at an absolute value of 8.0. If I set the UnitState to ignore terrain and give him a height of 8.0, he will start at 8.0 height relative to the absolute bottom of the map, which is exactly the same positioning. I can move around, and my unit stays on the ground. However, if I change the height of my unit AFTER setting the ignoreTerrain state, my unit will be positioned relative to the terrain despite the state I've set. I've done many tests to verify that the unit's height and all other related variables are correct and it is in fact the state being ignored.
Has anybody else dealt with this issue? If so, have you found a way around it or can we consider this a bug?
I'm not sure but i believe when you turn the Ignore Terrain Height flag on it resets your unit to the base height 0. What i would do is as soon as you turn the flag on set the units hieght to its previous height again.
@Docablo: Go
Yeah, I'm not sure about that because I have a semi-physics trigger that's setting my height every 0.0 game seconds, so that's definitely not the issue. I've used the TriggerDebugOutput function to verify that my unit's height is correctly set. The flag is being ignored, and my unit is hovering 8.0 above the ground, which is already 8.0 totaling an absolute height of 16.0. As soon as I move, it's corrected and my unit is standing on the ground again. As soon as I change the height again, it breaks. When I move, it fixes.
To reiterate, I've tested my unit's height all points in the scenario I just described and it's always constantly at 8.0. The only thing that changes is whether or not it's relative to the terrain, which means the flag is being ignored in a certain case. That case seems to be any time I change my unit's height.
@rrowland: Go
Oh wow you can change that? The constant flickering from auto-adjustments was driving me nuts
I don't know if you're doing all the movement from instant positioning or some combination of issue ordering, but if the former try reading from stored vectors/points at all times and only writing to the unit, like this:
gameloop(){
newposition = oldPosition + movement;
Turn ignore Height State On
Move unit instantly to newposition
Set unit height to Z-value of newposition
oldPosition = newposition
}
For anybody interested, I developed a cheesy little work-around that I'd rather avoid, but will be using until there's a fix or solution for this issue. Basically, I'm just moving my unit to his current position instantly every time I change my unit's height, so it always acts correctly as if I'm constantly moving, even when I'm not. It's redundant, wastes processing and creates lag I'm sure, but for now it seems to be the only fix.
Now if there were a way to apply this flag to the player's camera, my cliff ignore functionality would be completely seamless.
I'm moving by issuing commands, it seems smoother to me. Have you had success making WASD movement + mouselook aiming using instant moves? If so, I will test it out and see how it compares to issuing move commands. I've tested my map on BNet 2.0 and the 125ms minimum lag is looking to be an issue, so if there's any way to make movement more efficient in laggy situations I'm all for it.
@rrowland: Go
In first person it's mostly smooth, once you bring your character on screen the camera does get jerky when turning the character.
Though I imagine you could do the same thing with issue'ing orders as long as the issue order and height offset are right after another in the game loop, I'll give it a go later
I tryed both methods (for camera and for unit) and I perfer gradual move on the character, instant on the camera (as apposed to following the unit). Gradual on the unit because with 2+ players you can see each other and dont want it looking jumpy and instantly comming to a halt (without waitting for the polling timer) is not natural AT ALL. Instant on the camera because the only GOOD way I could find to have it move gradualy (look at and follow actor (actor attached to units head or centre) was smooth as silk BUT when I changed the direction my unit was moving it, the camera would pan around (as it was being dragged by the unit).
As a side note having the camera follow works realy well for first person perspective racing (where unlike a FPS you dont controll your camera/look in different directions to the one your moving) As it auto sets the camera to look at the same pitch/yaw/height/x/y position as the unit (from what ever attachment point position you want) and moves the camera smoothly with the unit rather than jumping it after the unit. (Msg me for code)
I found that when you set a the units flag/place a unit with flag (iggnore terrain height) that the unit is initialy shown at Ground Height at Point + Data->Unit->Art-Height
This is a bug. If you then move your new terrain ignoring unit its height goes nuts, and becomes Max ( 0 OR Art Height - Terrain Height) I.E. if your terrain is at 9 units heigh, your art height is 10 units heigh, your unit will become 1 unit off the map floor (8 units UNDER the ground) The acutal unit value will read as it should in debug... verry stange...
To avoid this after creating a flaged unit / changing a reguler unit to have that flag. Just set the height to w/e you want (proberbly terrain height at point) and from then on it will be at EXACTLY that height, reset as you see fit.
This works smoothly, I have used it to make a unit which is normaly ground bound go Flag Active for jumps (so that it can move smoothly over terrain while running, but move un influenced by even the smallest terrain changes while jumping. (if I used instant move I could ignore this but if there was a spike in the terrain < move distance w/o changing his flag he would ungulate with it.)
I have some thoughts on your other post (about cliffs and jerking) that ill put up in a minute.