Just to clarify: by "moving" i mean that the dialog actually moves across the screen (as in you can see it moving, it doesn't just pop up at the distination).
I've been trying to write a function to do this, but it's becoming a bit too mathy for me (especially if I'd like to add a custom duration and acceleration/deceleration for the movement) and I feel like I'm reinventing the wheel. I bet this kind of algorithm is taught to 1st year CS students :(
I suppose you could try a recursive function that receives the x,y coordinates that your dialog should move to. Then have it recurse according to the duratio of the slide. You could probably add acceleration etc in somewhere.. Only problem is that the minimum time interval is 0.0625 seconds.. which is like.. 18 fps? Not fast enough to appear like a smooth slide to the human eye unfortunately.
You should find that duration gets shorter and shorter until it hits 0 or less than 0, then the function just returns all the way back and terminates. The pseudocode I've scribbled out here will auto-scale the speed of the slide depending on the duration.
Check post #6, it has the supposedly correct pseudocode
Man.. that took awhile, I'm gettin rusty. But it should do the trick. Rest is all playing with numbers to get the effect you want. When the function is first called, CurrentDuration should always be 0. There are a lot of ways to do this really.. This might not be the best one, just keep that in mind yea?
The acceleration should just be a simple linear function (y = mx + b) where b is the starting speed, m is the modifier (where you would put in your custom speed) and x is the current position of the function in time. Y is then the distance of movement, or the current rate of speed.
Actually moving the dialog then would require an integer loop using the acceleration function to determine the distance per tick the dialog will move and storing that in a variable, let's call it "Distance." Then you just move the dialog to (X Position of dialog + Distance), (Y Position of dialog).
EDIT: Rewrote the trigger as an action definition, adding a parameter so you can choose the direction you want the dialog to move. More directions can be added later (like diagonals) but they're a little more complex. Also, an ending wait time of 0.05 seconds is a bit smoother than 0.1. Offset determines how the dialog will move. For example, Top Left will anchor it to the top left of the screen and move based on that, just like a normal dialog offset anchor.
You can set the starting X and Y positions to the dialog's current X and Y positions if you want or put new ones in. If you use the dialog's current X and Y you need to keep the same anchor though, otherwise it might move to an undesirable location.
You can determine missing values (namely duration to reach a certain distance) using this function:
So if you want your dialog to accelerate to the right at 3 offset units per second until it reaches a displacement of 500 offset units, you can find the duration required by using the function:
If you want to decelerate a dialog by 3 offset units per sec from a certain starting speed until it reaches a displacement of 500 you can do that too:
#Firstyoumustdeterminewhatthedurationwillbe.Youcandothisbysettingavariabletothefunctionoutputusingamockaccelerationplanfrom0to500(yourdesireddisplacement.)Variable-SetDurationTemp=(DetermineAccelData(500.0,3.0,0.0,0.0,0.0,Duration))#Then,usingthedurationyoujustfiguredout,findwhatthefinalspeedwillbe.Variable-SetFinalSpeedTemp=(DetermineAccelData(500,3.0,0.0,0.0,DurationTemp,FinalSpeed))#Nowinitiatethemoveactionusingthesevalues-onlyyou're going to invert the acceleration to -3 (since you'redeceleratingnow)anduseFinalSpeedTempasyourStartingSpeed.MoveDialog(MyDialog,0,500,Left,"RIGHT",FinalSpeedTemp,-3.0,DurationTemp)
And that's it. Not too bad, eh? :P
Now if only I would actually apply these math skills to my calculus homework, I might bring my GPA up...
BasharTeg, how do you control the end location of the dialog?
On a side note: What I provided earlier is just a very rough pseudocode. It's not specifically galaxy and thus can be implemented into GUI. I'm used to scripting, so forgive me if it looks like script. Its supposed to calculate the distance per step gradient dynamically depending on the specified end location. I'll fix my version later, I have some work I need to finish first.
The end location of the dialog is the result of some combination of starting speed, acceleration, and duration. You might be able to calculate it using functions but this requires a bit of complex math. With a little trial and error I got it to about where I want it after maybe 5 minutes. I'll see if I can compile some suitable functions to determine the settings necessary for a certain end position... though when you start getting into quadratic equations it becomes a bit of a headache :P
Function allows you to define the up and down ramps, the ratio of the starting velocity to the maximum allowed velocity etc etc. Commented most of the stuff. Simply put, the input parameters are just the dialog, the current time which should always start at 0. The total duration (t), the ramp duration (tRamp), the initial velocity ratio (vInitFactor) and the distance X and Y you wish to move from the current dialog position. You should calculate these before inputting them into the function by checking the distance between the end and start points.
If anythings not clear, please refer to the figure
That should do it...Good luck! Hope theres no bugs. Bloody hell, now I understand why you say it's like reinventing the wheel.
Fuzzy, I did it pretty similar to you, just skipped the acceleration/deceleration so my mind wouldn't explode from the math :P
I hate math...
Check out the attachment. The dialog is always a bit off and it has to be corrected after the loop finishes (the bigger the move distance the more visible the "skew" is). I guess it's because the step has to be an integer and the remainder from the division adds up over time.
Also, the execution time is never even close to the chosen duration... it's always at least 1sec longer (gets bigger when setting larger duration), can't figure it out :/
Btw, not only am I illiterate in math, but I also don't understand math terminology in english (not my native lang). I had to look up what "magnitute" means =D I guess it's this, at least that's what I used...
Yeah, your guess is spot on. Its a rounding error of sorts.
Edit: Investigated this.. The distance per step method is going to mess up because of rounding errors.. Only one other way.. Have to calculate the exact position at each time step according to the speed gradient i attached to my post earlier.. Thats the only way to get the most accurate result.. I'll really gotta get to sleep.. so I'll probably work it out tomorrow. Simply put, you just need to calculate the area below the curve at every point in time, given the calculated value of Vmax. That is your dX and dY value that you need to add to the initial dialog position. I'll correct the solution from my earlier post and repost it once i have an answer.
The duration seems perfectly find to me though. (I'm testing with 5 seconds and a stopwatch) I'll take a look at it for awhile.. then i gotta go zZz
Yeap. Magnitude, thats what i was referring to. Absolute distance. :)
Edit:
Quote:
Crap, didn't notice your edit :P
Whoops :P
If the second version doesn't work, I'll personally give the coding a try when i have time and post the solution here. I hope you don't mind a custom script solution though :| I'll create a gui function and link it as well if it'll make it easier.
The duration was my bad, I was testing with the trigger debugger on, made the game lag. Duration is perfect without the debugger and in fullscreen mode.
If you really want to fix the rounding error, go ahead, but I've got everything I needed right now. My dialogs will only move sideways or upwards (no diagonal movement), so no rounding error there (or rather, not that visible). I'm working on a gui version with acceleration right now.
Just to clarify: by "moving" i mean that the dialog actually moves across the screen (as in you can see it moving, it doesn't just pop up at the distination).
I've been trying to write a function to do this, but it's becoming a bit too mathy for me (especially if I'd like to add a custom duration and acceleration/deceleration for the movement) and I feel like I'm reinventing the wheel. I bet this kind of algorithm is taught to 1st year CS students :(
Has anyone done or tried something like this?
@Tolkfan: Go
I suppose you could try a recursive function that receives the x,y coordinates that your dialog should move to. Then have it recurse according to the duratio of the slide. You could probably add acceleration etc in somewhere.. Only problem is that the minimum time interval is 0.0625 seconds.. which is like.. 18 fps? Not fast enough to appear like a smooth slide to the human eye unfortunately.
You should find that duration gets shorter and shorter until it hits 0 or less than 0, then the function just returns all the way back and terminates. The pseudocode I've scribbled out here will auto-scale the speed of the slide depending on the duration.
Check post #6, it has the supposedly correct pseudocode
Man.. that took awhile, I'm gettin rusty. But it should do the trick. Rest is all playing with numbers to get the effect you want. When the function is first called, CurrentDuration should always be 0. There are a lot of ways to do this really.. This might not be the best one, just keep that in mind yea?You can do this in the GUI if you wish.
The acceleration should just be a simple linear function (y = mx + b) where b is the starting speed, m is the modifier (where you would put in your custom speed) and x is the current position of the function in time. Y is then the distance of movement, or the current rate of speed.
Actually moving the dialog then would require an integer loop using the acceleration function to determine the distance per tick the dialog will move and storing that in a variable, let's call it "Distance." Then you just move the dialog to (X Position of dialog + Distance), (Y Position of dialog).
It will basically look like this:
EDIT: Rewrote the trigger as an action definition, adding a parameter so you can choose the direction you want the dialog to move. More directions can be added later (like diagonals) but they're a little more complex. Also, an ending wait time of 0.05 seconds is a bit smoother than 0.1. Offset determines how the dialog will move. For example, Top Left will anchor it to the top left of the screen and move based on that, just like a normal dialog offset anchor.
You can set the starting X and Y positions to the dialog's current X and Y positions if you want or put new ones in. If you use the dialog's current X and Y you need to keep the same anchor though, otherwise it might move to an undesirable location.
You can determine missing values (namely duration to reach a certain distance) using this function:
So if you want your dialog to accelerate to the right at 3 offset units per second until it reaches a displacement of 500 offset units, you can find the duration required by using the function:
Simple, right? :P
If you want to decelerate a dialog by 3 offset units per sec from a certain starting speed until it reaches a displacement of 500 you can do that too:
And that's it. Not too bad, eh? :P
Now if only I would actually apply these math skills to my calculus homework, I might bring my GPA up...
@BasharTeg: Go
BasharTeg, how do you control the end location of the dialog?
On a side note: What I provided earlier is just a very rough pseudocode. It's not specifically galaxy and thus can be implemented into GUI. I'm used to scripting, so forgive me if it looks like script. Its supposed to calculate the distance per step gradient dynamically depending on the specified end location. I'll fix my version later, I have some work I need to finish first.
@FuzzYD: Go
The end location of the dialog is the result of some combination of starting speed, acceleration, and duration. You might be able to calculate it using functions but this requires a bit of complex math. With a little trial and error I got it to about where I want it after maybe 5 minutes. I'll see if I can compile some suitable functions to determine the settings necessary for a certain end position... though when you start getting into quadratic equations it becomes a bit of a headache :P
@BasharTeg: Go
Let the mathcraft begin! lol. I'm trying to derive a function for the dynamic steps per 0.0625 wrt to a specified duration and distance right now :D
The function would be as follows:
Function allows you to define the up and down ramps, the ratio of the starting velocity to the maximum allowed velocity etc etc. Commented most of the stuff. Simply put, the input parameters are just the dialog, the current time which should always start at 0. The total duration (t), the ramp duration (tRamp), the initial velocity ratio (vInitFactor) and the distance X and Y you wish to move from the current dialog position. You should calculate these before inputting them into the function by checking the distance between the end and start points.
That should do it...Good luck! Hope theres no bugs. Bloody hell, now I understand why you say it's like reinventing the wheel.
Fuzzy, I did it pretty similar to you, just skipped the acceleration/deceleration so my mind wouldn't explode from the math :P
I hate math...
Check out the attachment. The dialog is always a bit off and it has to be corrected after the loop finishes (the bigger the move distance the more visible the "skew" is). I guess it's because the step has to be an integer and the remainder from the division adds up over time.
Also, the execution time is never even close to the chosen duration... it's always at least 1sec longer (gets bigger when setting larger duration), can't figure it out :/
Btw, not only am I illiterate in math, but I also don't understand math terminology in english (not my native lang). I had to look up what "magnitute" means =D I guess it's this, at least that's what I used...
Crap, didn't notice your edit :P
Is it possible to change the location of a dialog.... never tried
I thought they were static at the position they are created at.
@Tolkfan: Go
Yeah, your guess is spot on. Its a rounding error of sorts.
Edit: Investigated this.. The distance per step method is going to mess up because of rounding errors.. Only one other way.. Have to calculate the exact position at each time step according to the speed gradient i attached to my post earlier.. Thats the only way to get the most accurate result.. I'll really gotta get to sleep.. so I'll probably work it out tomorrow. Simply put, you just need to calculate the area below the curve at every point in time, given the calculated value of Vmax. That is your dX and dY value that you need to add to the initial dialog position. I'll correct the solution from my earlier post and repost it once i have an answer.
The duration seems perfectly find to me though. (I'm testing with 5 seconds and a stopwatch) I'll take a look at it for awhile.. then i gotta go zZz
Yeap. Magnitude, thats what i was referring to. Absolute distance. :)
Edit:
Whoops :P
If the second version doesn't work, I'll personally give the coding a try when i have time and post the solution here. I hope you don't mind a custom script solution though :| I'll create a gui function and link it as well if it'll make it easier.
@SouLCarveRR: Go
Yep. Its possible. Theres a function DialogSetPosition i think it was.
@FuzzYD: Go
The duration was my bad, I was testing with the trigger debugger on, made the game lag. Duration is perfect without the debugger and in fullscreen mode.
If you really want to fix the rounding error, go ahead, but I've got everything I needed right now. My dialogs will only move sideways or upwards (no diagonal movement), so no rounding error there (or rather, not that visible). I'm working on a gui version with acceleration right now.
There I fixed it :D
Ok, my method should be finished. You can use the new function, "Determine Accel Data" to find a missing component such as duration or distance.
I updated it all to post #3 (http://forums.sc2mapster.com/development/triggers/21034-moving-sliding-a-dialog/?post=3)
Well, that was fun. Off to something a bit more productive now...