Camera rotating

[Bboy Moose]

How can i make a camera once locked, unable to zoom it, or rotate because i made the camera lock to the target unit but when i scroll with the mouse it always gets to the normal camera position, and im able to zoom in and out

(I hope someone can understand that grammar)

Thanks for help

 

[TwoVenomous]

Create a trigger that resets the camera periodically (you need to create a camera on that position).

• reset
  • Events
    • Time - Every 0.03 seconds
  • Conditions
  • Actions
    • Camera - Apply (your camera) for (any players) over 0.00 seconds

This way, when you scroll or zoom the camera, the camera will be back to its position before zoomed or scrolled

 

[Bboy Moose]

Create a trigger that resets the camera periodically (you need to create a camera on that position).

• reset
  • Events
    • Time - Every 0.03 seconds
  • Conditions
  • Actions
    • Camera - Apply (your camera) for (any players) over 0.00 seconds

This way, when you scroll or zoom the camera, the camera will be back to its position before zoomed or scrolled

Thank you, going to try it

edit: there's a problem with it, now the camera does not lock to the unit:S

 

[Anvil]

• Camera
  • Event
    • Time - Every 0.01 seconds of game time
  • Conditions
  • Actions
    • Camera - Reset camera for Player to standard game-view over 0.00 seconds
    • Camera - Lock camera target for Player to YourUnit, offset by (0.00, 0.00) using Default rotation.

 

[sentrywiz]

Using every 0.01 as an event not only creates unimaginable lag but is also a bad solution. use 0.05 - 0.03 a maximum value for loops if you must.

But a better solution would be a for event that checks if the camera's values aren't what you want them to be and if they are, to reset them back.

Something along these lines:

• Untitled Trigger 001
  • Events
    • Time - Every 0.50 seconds of game time
  • Conditions
    • (Distance to target of Camera 001 <gen>) Not equal to 0.00
    • (Field of view of Camera 001 <gen>) Not equal to 0.00
    • (Angle of attack of Camera 001 <gen>) Not equal to 0.00
    • (Rotation of Camera 001 <gen>) Not equal to 0.00
  • Actions
    • Camera - Set Triggering Player's camera Distance to target to 0.00 over 0.25 seconds
    • Camera - Set Triggering Player's camera Field of view to 0.00 over 0.25 seconds
    • Camera - Set Triggering Player's camera Angle of attack to 0.00 over 0.25 seconds
    • Camera - Set Triggering Player's camera Rotation to 0.00 over 0.25 seconds

 

[Anvil]

Right, but for a camera is better 0.01 than 0.03 because if you use the arrows or put the mouse in the border on the screen the camera will move for an instant and doesn't look good.

Also your trigger needs a "Or" (multiple conditions) because now for restore the camera, the trigger wait the 4 conditions return true. So you can rotate de camera and make a zoom in and never goes to restore the camera.

 

[defskull]

Right, but for a camera is better 0.01 than 0.03 because if you use the arrows or put the mouse in the border on the screen the camera will move for an instant and doesn't look good.

Have you created a map before ?
Not cheap ones, but a nice map - with the use of these triggers ?

If you did, you'll know that by using 0.01s interval would lag out the entire planet (even if the game is single-player, you should avoid it).
If it doesn't lag out at the first 10 minutes of the game, it will sooner.
Because a game usually lasts for more than 10 minutes (that doesn't count as Single-player maps).
And you're gonna use that trigger until the end of the game, very unefficient and should be avoided at all costs.

You said that using 0.03s interval will "if you use the arrows or put the mouse in the border on the screen the camera will move for an instant and doesn't look good." ?
I have created a test map, you should try it.
The "screen budge" can be accepted by user's visual, don't worry.

Test map is here, Moose23.

 

[Garfield1337]

Using 0.01 interval doesn't cause "unimaginable" lag by itself, just saying.

Unless you're performing many operations which isn't the case here.

 

[defskull]

Unless you're performing many operations which isn't the case here.

This may be true but we don't know what others triggers does he runs on that map which could be running at the same time as the Camera Handle trigger - which would lag out when combined operations with another trigger functions.

Also, there's no harm in using 0.03s interval, it's a good practice.

And there's also no harm in using 0.01s interval, but if you really wanna use it, make sure the trigger doesn't run for a long period of time in that game (which in this case, it can't be used because I believe the camera handling would last permanently throughout the game).

 

[sentrywiz]

Using 0.01 interval doesn't cause "unimaginable" lag by itself, just saying.

Unless you're performing many operations which isn't the case here.

Only adjusting the camera. And that by far is something not even jass can manage on its own. Not only does that cause lag and slow response for simple operations, but with camera... that isn't unimaginable lag, its a certain failure in short period of time.

Just like... a shadow priest :3

 

[defskull]

Just like... a shadow priest :3

Why Dazzle is holding a camera ???

 

[Garfield1337]

Only adjusting the camera. And that by far is something not even jass can manage on its own.

It obviously can; how else would you manipulate the camera?

 

[sentrywiz]

Do you use jass to code camera variables and rotate the camera via it?
If yes, then I know of nobody else but you that does it. Even full-blown hardcore jass coders have admitted before that gui is still the easiest way to handle a camera object.

@defskull - Not referencing the dota Dazzle, but a WoW shadow priest. He puts little insignificant dots here and there, people don't like it but it doesn't cause mass panic. Until the dots start to add-up and mass panic doesn't get you anywhere. And suddenly you die, and the priest was long gone doing his dishes while you suffocated in damage over time. That analogy is the same principle for the 0.01 loops, it starts insignificant but adds up really fast and hits heavy after.

 

[Anvil]

Have you created a map before ?
Not cheap ones, but a nice map - with the use of these triggers ?

If you did, you'll know that by using 0.01s interval would lag out the entire planet (even if the game is single-player, you should avoid it).
If it doesn't lag out at the first 10 minutes of the game, it will sooner.
Because a game usually lasts for more than 10 minutes (that doesn't count as Single-player maps).
And you're gonna use that trigger until the end of the game, very unefficient and should be avoided at all costs.

Yeah, I used it in a map. Also 480x480 with animate doodads and third person camera, nothing happens. Anyway, I use always 0.03 for spells or other things but for camera never brought me any problem. I know that short times can cause lag but is only one trigger with 0.01 periodic event.

 

[Garfield1337]

Setting camera fields uses natives directly, no BJs involved, so there isn't much work. Since the camera field names are intuitive, it's not more work than in GUI.

Also, that trigger doesn't pile up memory so the performance wouldn't drop over time.

 

[sentrywiz]

Setting camera fields uses natives directly, no BJs involved, so there isn't much work. Since the camera field names are intuitive, it's not more work than in GUI.

Also, that trigger doesn't pile up memory so the performance wouldn't drop over time.

Not sure, if you have worked on camera heavy maps with such loops and you experienced no lag at all, then its my error.

But 0.01 loops -> never a good solution. Maybe a temporary solution, but never a good one. You can survive through multiple loops like those if you and all the people that play such a map have great machines, but someone else might crash in the 3rd minute in-game.

 

[Garfield1337]

I haven't worked that much with cameras so you might be right.

For the usage of 0.01 interval, I think we can agree that it's not advisable, but viable in some cases.