Speed scaling

[Elvish_Pillager]

I'll compile it and post a mac OS X binary for those that are interested.

http://www.cis.rit.edu/~slk8779/wesnoth/

I played it, and I like the feature.

[Viliam]

Beware of division by zero! Is there any unit that has zero movement, but can somehow be moved (e.g. by a scenario script)? Will movement also affect combat speed?

[Elvish_Pillager]

Beware of division by zero! Is there any unit that has zero movement, but can somehow be moved (e.g. by a scenario script)? Will movement also affect combat speed?

Don't worry! 0 movement ALREADY causes errors, you don't have to worry about creating more!

[Invisible Philosopher]

Units moving across water look like they're walking on water, then they sink in at the end of their movement. This is noticeable because they go slower in water now. I suggest that when a unit goes through a terrain that submerges it, the unit is submerged while moving. There are various ways this could be implemented:

* Wherever there's a height of submersion for either hex that a unit is moving between, have it gradually go from one to the other.

* Same as previous, but put it halfway between for the whole movement.

* Take the minimum submersion of the two hexes and use that.

I hope this wouldn't be too hard to implement, although I don't know what other people would think of it either.

P.S.:

Beware of division by zero! Is there any unit that has zero movement, but can somehow be moved (e.g. by a scenario script)? Will movement also affect combat speed?

I just thought of something - would [move_unit_fake] be affected too? If so, the Galleon will need a reasonable number of moves...

[move_unit_fake] should be affected. This has the side effect of letting the Galleon and other such units (like the Fireball) be any speed the designer wants, but also requires them to have moves and a movetype specified.

[Elvish_Pillager]

* Wherever there's a height of submersion for either hex that a unit is moving between, have it gradually go from one to the other.

* Same as previous, but put it halfway between for the whole movement.

* Take the minimum submersion of the two hexes and use that.

* Switch the submersion halfway through the move.

[scott]

Ok changing the speed constant from 50 to 25 is too fast! Just so you know.

On the other hand there might be something to this - accelerated movement, normal speed combat/healing... hmm

[Dave]

* Wherever there's a height of submersion for either hex that a unit is moving between, have it gradually go from one to the other.

This is how I originally wanted to implement it when I first implemented submersion.

However, unfortunately, it is actually rather difficult to implement. That's the reason it's not done, and honestly, it's highly likely it never will be.

David

[Dave]

* Wherever there's a height of submersion for either hex that a unit is moving between, have it gradually go from one to the other.

This is how I originally wanted to implement it when I first implemented submersion.

However, unfortunately, it is actually rather difficult to implement. That's the reason it's not done, and honestly, it's highly likely it never will be.

My mistake...I worked out a way to implement it, so now it's in.

David

[Elvish_Pillager]

We could try it though I guess.

David

What's the news on this?

[scott]

I liked playing with speed scaling. On the other hand, I can see some players really hating it.

[autolycus]

OK, after playing with this feature for a while, I must admit that it does give one a sense of the accompanying frustration that should go with moving through difficult terrain...

However, occasionally I find myself thinking of it as 'irregular slowdowns on my computer'. I guess it slows down turns quite a bit. I could live without it - nice to have for some people, a pain for others - it should be an off-by-default option, perhaps?

[Elvish_Pillager]

it should be an off-by-default option, perhaps?

Good idea.

[Dacyn]

I don't think we need another option...

[Elvish_Pillager]

I don't think we need another option...

Neither do I. I think we can implement this feature unconditionally. However, if other people don't like it...

[scott]

The only think I dislike about the current method is that the terrain acts as a multiplier, slowing down the default move rate, but never speeding it up. Speed scaling OR increasing the base move rate are options and I can live with either.