heyya, its just something ive noticed that hasnt been implimented
and i dunno if this is mod specific but i assume that this is to do with the engine (please tell me if i assumed wrong and ill post this in the correct forum)
anyway, when making a map you get to choose the speed at which units move accross different types of terrain.
what ive noticed is that when going over slow terrain (maybe steep hills also?) the animation speed of unit models isnt reduced, just the speed at which they move.
anyway
thanks for reading
D.R
not so much a feature request
Moderator: Moderators
-
Dead.Rabit
- Posts: 264
- Joined: 03 Sep 2005, 04:28
x and y coordinates have to be checked against values from other computers and constantly updated.
this could be calculated per computer. also i see more and more advanced computers online every month.
and because this is just an aesthetic thing it could be toggled in the game settings
all u have to do is multiply the leg animation speed of kbots by the terraintype. and possibly a constant. the way speed changes per terrain type must undergo a similar simple calculation.
D.R
this could be calculated per computer. also i see more and more advanced computers online every month.
and because this is just an aesthetic thing it could be toggled in the game settings
all u have to do is multiply the leg animation speed of kbots by the terraintype. and possibly a constant. the way speed changes per terrain type must undergo a similar simple calculation.
D.R
Terraintype?...
No it works like this:
Unit A is at position X1,Z1 (Y is irrelevant) now. 250ms in the future it will be at X2,Z2. Now we can measure the distance it moved in these 250ms. Since maxSpeed (divided by 4, because it's for 32 game frames/second) is known we can now calculate a multiplier to make animations slower or faster (if it goes downhill) automatically.
Lets say it's going to be put on every kbot in BA (which is a lot of work too). It would definitely lag the game on kbot heavy maps in the long run. At least I think so...
No it works like this:
Unit A is at position X1,Z1 (Y is irrelevant) now. 250ms in the future it will be at X2,Z2. Now we can measure the distance it moved in these 250ms. Since maxSpeed (divided by 4, because it's for 32 game frames/second) is known we can now calculate a multiplier to make animations slower or faster (if it goes downhill) automatically.
Lets say it's going to be put on every kbot in BA (which is a lot of work too). It would definitely lag the game on kbot heavy maps in the long run. At least I think so...
-
Dead.Rabit
- Posts: 264
- Joined: 03 Sep 2005, 04:28
it would only cause lag on slower computers. or before you do the calculation you could perform checks
i.e.
is this kbot within view of the camera
is the camera zoomed in more then x amount
is the game running at normal speed
is there more then x amount of kbots
and if not, dont perform the calculation.
when you think about how many lines of code that 1 kbot must go through already i.e am i firing, create bullet at xy relative to kbot which direction is my torso facing where am i going, pathfinding etc etc etc, 1 more line of code with aesthetic value doesnt seem like it'll add much harm, at least nowhere near as much lag as planes and 3-dimensional pathfinding.
D.R
i.e.
is this kbot within view of the camera
is the camera zoomed in more then x amount
is the game running at normal speed
is there more then x amount of kbots
and if not, dont perform the calculation.
when you think about how many lines of code that 1 kbot must go through already i.e am i firing, create bullet at xy relative to kbot which direction is my torso facing where am i going, pathfinding etc etc etc, 1 more line of code with aesthetic value doesnt seem like it'll add much harm, at least nowhere near as much lag as planes and 3-dimensional pathfinding.
D.R
