|
On August 24 2011 08:12 MMXMoto-X17 wrote: Interesting.
did u forget to add ur integration constant ?
E = M*C^2
Will this equation maybe help?
How incredibly smart and funny. Please share more of your infinite wisdom with us.
|
On August 24 2011 07:48 Simberto wrote:Show nested quote +On August 24 2011 07:33 Torik wrote:On August 24 2011 06:55 Simberto wrote: Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it? I agree. It's best to leave the zero-case out. Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident. So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution  . That would not really be a problem, it would just mean that you only have one acc/dec phase per round instead of two, meaning you would have to redo some calculations, if it really keeps the same velocity. However, obviously best would be if someone who knew how to do that would produce a script that either makes the SCV go to some place, with usual acc/dec behaviour, or return the exact time with good accuracy (1/10th or 1/100th of a second) for the time spend travelling. Another important thing is to really look at when the units do decelerate, and when they simply ignore all that. So far: Patrols keep speed (Delivering minerals maybe also keeps the speed up) Queued move orders decelerate at each point Mining decelerates The point is that since it is not clear how it works it's difficult to isolate a single component. The acceleration seems ok, but there are two different deceleration-effects (approaching minerals and CC). We have two unknown factors into one equation, so the total amount of time of the harvesting cycle could not be used.
I think I'll follow Excalibur_Z and your suggestion about writing a script. I need a better testing environment. I'm reading some documentation about the Galaxy language for the Map Editor. It should not be too hard to write the scripts I need.
|
On August 24 2011 08:37 Torik wrote:Show nested quote +On August 24 2011 07:48 Simberto wrote:On August 24 2011 07:33 Torik wrote:On August 24 2011 06:55 Simberto wrote: Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it? I agree. It's best to leave the zero-case out. Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident. So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution  . That would not really be a problem, it would just mean that you only have one acc/dec phase per round instead of two, meaning you would have to redo some calculations, if it really keeps the same velocity. However, obviously best would be if someone who knew how to do that would produce a script that either makes the SCV go to some place, with usual acc/dec behaviour, or return the exact time with good accuracy (1/10th or 1/100th of a second) for the time spend travelling. Another important thing is to really look at when the units do decelerate, and when they simply ignore all that. So far: Patrols keep speed (Delivering minerals maybe also keeps the speed up) Queued move orders decelerate at each point Mining decelerates The point is that since it is not clear how it works it's difficult to isolate a single component. The acceleration seems ok, but there are two different deceleration-effects (approaching minerals and CC). We have two unknown factors into one equation, so the total amount of time of the harvesting cycle could not be used. I think I'll follow Excalibur_Z and your suggestion about writing a script. I need a better testing environment. I'm reading some documentation about the Galaxy language for the Map Editor. It should not be too hard to write the scripts I need.
Good call, make sure you document your findings in the liquidpedia database.
|
|
You are absolutely right, Torik. I assumed you meant that there is simply no deceleration at the the CC, but obviously you can't really tell that just by bare eye. The ideal test would be one with large accuracy while minimizing the amount of movements involved. So you should probably avoid any repeated movements, and any interaction with other objects. But i don't think you can get good enough data for the time without repeating the movement some times. Also, when you change your method you need to find another way of measuring distance if you move between unspecific points instead of minerals and CC.
However, if you don't find a good way with scripting, one could test the behaviour at the CC seperately, for example by comparing the movement of one SCV that moves double the amount of spaces and comparing it with one that delivers minerals to a CC half the amount of space away. So far my theory is that there are two types of movement change, one with deceleration, and one where the object simply keeps its movement speed, but i have absolutely no proof at all for that.
Don't you have something more useful to do than coming in here and spouting unrelated nonsense?
|
Just a little update.
I'm running several tests this evening and the big issue seems to be the top speed of the unit. The value I used for my previous simulations (16) is by far greater than the top speed of any units, which for the most part are below 4.5 (the interceptor is the fastest with 7.5). My first impression is that the engine is not able to handle high speed and a deceleration value different from zero, but I need more data to be sure (or at least "almost" sure...). I also verified that the Commend Center is not treated like a way-point in the mineral gathering cycle. The anomaly I observed yesterday should be another side effect of the speed too high of the SCV.
About the script for Map Editor, I haven't found yet a method to simulate the user input (mouse or keyboard).
|
I don’t know if there is someone still interested in this argument. Anyway, I did a lot of tests and research on Internet about movement (something I should have done earlier) and I think I found why things appeared so odd.
For what I read, SC2 should use a steering behavior algorithm to control the path and the movement of the units; in particular, in order to simulate the slowing down of a unit when it’s reaching its destination, the arrival steering behavior is used to calculate when the unit needs to start to decelerate. You can find more information about this at http://www.red3d.com/cwr/steer.
So I think that, partially like I wrote in the previous post based only on empirical observation, the system messed up because the speed was too high compared to the distance between the mineral patch and the Command Center. The engine probably couldn’t calculate in the right way how to decelerate the unit properly, so other effects took the control of the movement. Another confirmation I obtained is that the deceleration value acts like a tweak parameter rather than the actual deceleration; this also explains why all units (besides Motherships and High Templars) have a deceleration value of zero.
Since the units decelerate before stopping, there is for sure a deceleration value defined in some place. May be it is buried into the Map Editor and I haven’t found it yet, or it is simply not available. In this last case I’ll have to figure out a way to measure it.
|
Interesting find, thanks for the update.
So if I understand correctly, things only appeared odd because of the high speed, but in reality they do make sense? Please forgive my lack of scientific knowledge.
|
There is no such thing as deceleration. Only negative acceleration.
|
but can you make air units do a moving shot that's not ridiculous?
|
On August 26 2011 05:48 kushm4sta wrote: There is no such thing as deceleration. Only negative acceleration. I think you spend too much in in academia my techie friend. Let's talk practically and not worry about such trivial semantics.
|
On August 26 2011 05:45 AlBundy wrote: Interesting find, thanks for the update.
So if I understand correctly, things only appeared odd because of the high speed, but in reality they do make sense? Please forgive my lack of scientific knowledge. Yes, it seems so. In some way the algorithm uses all the parameters (acceleration, top speed and deceleration) to establish how much space a unit needs to accelerate, to move at maximum speed and to decelerate. If one or more of these data is outside a specific bound, then the algorithm does not function properly, I think mainly because other effects become stronger (such as obstacle avoidance or other described at the link I posted). I too don't know too much on this field, I started reading on this subject just few days ago .
|
If somebody can help me make the leap from this to play.... How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything?
|
Here is a test you can run so you can see what I mean for "odd" and what make me think that there have to be some safety boundaries for the parameters. Using the Map Editor set for the SCV:
- Acceleration = 16
- Deceleration = 1
- Speed = 16
- InnerRadius = 1
- Radius = 1
Now test the map, select a bunch of SCV and start to move this group around the map. Don’t make a multi-waypoint path, just click and move them towards a location. If you do this just two or three times, you should see that at some point the SCVs start to freak out when they are reaching the destination, wandering around or bouncing back and forth with each other.
|
On August 26 2011 06:10 Sir Snoopy wrote: If somebody can help me make the leap from this to play.... How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything? A warp prism has an acceleration value of 2.125 (like the observer and the voidray for example) that is quite low. It has a speed of 2.5, so it takes more than a second to reach its maximum speed. A zealot or a stalker have an acceleration of 1000, which means that they hit the top speed almost immediately.
|
On August 26 2011 06:10 Sir Snoopy wrote: If somebody can help me make the leap from this to play.... How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything?
Acceleration is important when you try to micro stuff. For example, when you try to move a mothership so that it does not get hit, while cloaking something beneath it, and the enemy comes at you from different angles. Not only is the mothership extremely slow, it also has a very low acceleration, meaning everytime you want to get away from something it takes some seconds slowly starting to move before it reaches its maximum velocity. This might be an obscure example, but it applies in the same way to every kind of action where you move and stop.
For the Warp prism, you have dropped something, the enemy comes, and you want to get away. You grab your guys and start flying, and since you have a relatively low acceleration it gives the enemy more time to hit you. For example, assuming units accelerate linearly, if you take 1 second to accelerate to your top speed, you are half a second behind the place you would be if you accelerated instantly. Which, in this case, might me where these evil stalkers shoot you in the face as opposed to chilling safely over the sea.
|
|
|
|