Talk:Movement (EU2012) - Revision history

Parogen: /* simplified approximation */ new section

2025-05-30T06:57:51Z

simplified approximation: new section

← Older revision		Revision as of 06:57, 30 May 2025
Line 26:		Line 26:

	:You're welcome. Btw these findings are from EW/Long War. I know that LW didn't change the way mobility/movement works in EW, and as far as I know it's the same as EU, so this should apply to all versions. [[User:Hazardass\|Hazardass]] 18:50, 4 April 2017 (PST)		:You're welcome. Btw these findings are from EW/Long War. I know that LW didn't change the way mobility/movement works in EW, and as far as I know it's the same as EU, so this should apply to all versions. [[User:Hazardass\|Hazardass]] 18:50, 4 April 2017 (PST)

			== simplified approximation ==

			For straight move, multiply by 2/3 (4/3 for dash) and round down but on whole numbers minus 1.
			:12*(2/3)=8 but that's whole so 12 movement is a 7 straight tile blue move.

			For diagonal move, multiply previous with 12/17, the rational approximation of 1/squareroot(2), (or 8/17 together, 16/17 for dash) but do not minus 1 on whole numbers.
			:17(2/3)(12/17)=17*(8/17)=8 and 17 movement is an 8 diagonal tile blue move.

Hazardass: /* Finding the exact scaling factor for #tiles per mobility stat */

2017-04-05T01:48:30Z

Finding the exact scaling factor for #tiles per mobility stat

← Older revision		Revision as of 01:48, 5 April 2017
Line 24:		Line 24:
	[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)		[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)
	:Thank you. I've given up trying to figure out Movement a long time ago :) [[User:Hobbes\|Hobbes]] ([[User talk:Hobbes\|talk]]) 20:28, 3 April 2017 (UTC)		:Thank you. I've given up trying to figure out Movement a long time ago :) [[User:Hobbes\|Hobbes]] ([[User talk:Hobbes\|talk]]) 20:28, 3 April 2017 (UTC)

			:You're welcome. Btw these findings are from EW/Long War. I know that LW didn't change the way mobility/movement works in EW, and as far as I know it's the same as EU, so this should apply to all versions. [[User:Hazardass\|Hazardass]] 18:50, 4 April 2017 (PST)

Hobbes at 20:28, 3 April 2017

2017-04-03T20:28:24Z

← Older revision		Revision as of 20:28, 3 April 2017
Line 23:		Line 23:
	I added more columns to the table for straight and diagonal moves, for half moves and dashes.		I added more columns to the table for straight and diagonal moves, for half moves and dashes.
	[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)		[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)
			:Thank you. I've given up trying to figure out Movement a long time ago :) [[User:Hobbes\|Hobbes]] ([[User talk:Hobbes\|talk]]) 20:28, 3 April 2017 (UTC)

Hazardass: some more explanation

2017-04-02T10:06:23Z

some more explanation

← Older revision		Revision as of 10:06, 2 April 2017
Line 15:		Line 15:
	Now, getting down to business. The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.		Now, getting down to business. The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.

	So after ~~trying out~~ several different factors in an attempt to match the observed data ~~with calculations~~, I narrowed down ~~the~~ exact ~~factor to~~ 0.666, with no fewer than three decimal 6’s. Values of 0.665 or 0.667 predict most but not all of the observed data; '''only 0.666 predicts ALL observed straight-line and diagonal tile movement values'''. Also, any number of trailing 6’s can be added without ~~any effect on~~ the results. I don’t know ~~the~~ floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.		So after testing several different conversion factors in an attempt to match the observed data to calculated data, I narrowed it down to an exact value of 0.666, with no fewer than three decimal 6’s (i.e. 0.66 doesn't work). Values of 0.665 or 0.667 predict most but not all of the observed tile data; '''only a factor of 0.666 predicts ALL observed straight-line and diagonal tile movement values'''. Also, any number of trailing 6’s can be added without affecting the results. I don’t know what floating-point precision is used in the game, but for calculation purposes a value of 0.666 works fine.

	It becomes apparent from these observations that the ‘intended’ ~~scaling~~ factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In ~~reality~~ this ~~ratio~~ is an irrational number, which ~~can’t~~ be programmed in the game as such. If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12. But since 12*0.~~666~~ = 7.99, it gets rounded down to 7 for blue move and 15 for dash.		It becomes apparent from these observations that the ‘intended’ conversion factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In theory this is an irrational number - it has an infinite number of trailing 6's, which cannot be programmed in the game as such. Since the game uses some finite precision, it truncates the value to some number of trailing 6's. If the game could, hypothetically, use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility stat of 12. But since 12*0.6666 = 7.999 (truncated), it gets rounded down to 7 tiles for blue move, and 15.99 rounds down to 15 for a dash. I believe this explains all apparent issues with the tile/mobility arithmetic in the game.

	Based on these findings the tabulated data posted on this page is off, since it was calculated using a factor of 1/1.625 = 0.615. E.g. mobility stat of 8 in the table was assigned a value of 4.92 tiles, which rounds down to 4 tiles for a blue move, and double value of 4.92*2 = 9.84 rounds down to 9 tiles for a dash, but these values don’t match the actual in-game movement of 5 tiles for a blue move and 10 tiles for a dash. But if we use a factor of 0.666, we get the correct tiles values of 5/10 tiles.		Based on these findings the tabulated data posted on this page is off, since it was calculated using a factor of 1/1.625 = 0.615. E.g. mobility stat of 8 in the table was assigned a value of 4.92 tiles, which rounds down to 4 tiles for a blue move, and double value of 4.92*2 = 9.84 rounds down to 9 tiles for a dash, but these values don’t match the actual in-game movement of 5 tiles for a blue move and 10 tiles for a dash. But if we use a factor of 0.666, we get the correct tiles values of 5/10 tiles.

Hazardass: /* Finding the exact scaling factor for #tiles per mobility stat */

2017-04-02T09:25:06Z

Finding the exact scaling factor for #tiles per mobility stat

← Older revision		Revision as of 09:25, 2 April 2017
Line 15:		Line 15:
	Now, getting down to business. The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.		Now, getting down to business. The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.

	So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s. Values of 0.665 or 0.667 predict most but not all of the observed data; only 0.666 predicts ALL observed straight-line and diagonal tile movement values. Also, any number of trailing 6’s can be added without any effect on the results. I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.		So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s. Values of 0.665 or 0.667 predict most but not all of the observed data; '''only 0.666 predicts ALL observed straight-line and diagonal tile movement values'''. Also, any number of trailing 6’s can be added without any effect on the results. I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.

	It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In reality this ratio is an irrational number, which can’t be programmed in the game as such. If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12. But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.		It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In reality this ratio is an irrational number, which can’t be programmed in the game as such. If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12. But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.

Hazardass: /* Diagonals */ Updated the correct conversion factor. All tile values are now correct and verified in-game.

2017-04-02T09:22:00Z

Diagonals: Updated the correct conversion factor. All tile values are now correct and verified in-game.

← Older revision		Revision as of 09:22, 2 April 2017
Line 7:		Line 7:

	: The difficulty is compounded by the fact the page announces two different ratios: Multiplying the movement stat by 0.625 is equivalent of each tile costing exactly 1.6 movement; while the formula "each tile costs 1.625" is equivalent to multiplying the movement stat by about 0.615 [[User:Medinoc\|Medinoc]] ([[User talk:Medinoc\|talk]]) 16:52, 14 January 2016 (EST)		: The difficulty is compounded by the fact the page announces two different ratios: Multiplying the movement stat by 0.625 is equivalent of each tile costing exactly 1.6 movement; while the formula "each tile costs 1.625" is equivalent to multiplying the movement stat by about 0.615 [[User:Medinoc\|Medinoc]] ([[User talk:Medinoc\|talk]]) 16:52, 14 January 2016 (EST)


			==Finding the exact scaling factor for #tiles per mobility stat==

			The movement page (before this edit) provides a few different scaling factors in the various sections, which is inconsistent. For example, it states that for “conversion purposes” it uses a ratio of 1.625 mobility points per game tile, which corresponds to 1/1.625 = 0.615 tiles per mob point. However, in the calculation for Dashing, a factor of 0.625 was used instead of 0.615. Later, in the “diagonal movement” paragraph, a value of 1.65 is used instead of 1.625, which corresponds to yet another scaling factor of 1/1.65 = 0.606 tiles per mob point. All this is guesswork, and none of these factors correctly predict the actual movement in the game (details below).

			Now, getting down to business. The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.

			So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s. Values of 0.665 or 0.667 predict most but not all of the observed data; only 0.666 predicts ALL observed straight-line and diagonal tile movement values. Also, any number of trailing 6’s can be added without any effect on the results. I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.

			It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In reality this ratio is an irrational number, which can’t be programmed in the game as such. If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12. But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.

			Based on these findings the tabulated data posted on this page is off, since it was calculated using a factor of 1/1.625 = 0.615. E.g. mobility stat of 8 in the table was assigned a value of 4.92 tiles, which rounds down to 4 tiles for a blue move, and double value of 4.92*2 = 9.84 rounds down to 9 tiles for a dash, but these values don’t match the actual in-game movement of 5 tiles for a blue move and 10 tiles for a dash. But if we use a factor of 0.666, we get the correct tiles values of 5/10 tiles.

			I added more columns to the table for straight and diagonal moves, for half moves and dashes.
			[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)

Medinoc at 21:52, 14 January 2016

2016-01-14T21:52:08Z

← Older revision		Revision as of 21:52, 14 January 2016
Line 5:		Line 5:

	It would be nice to have also a summary of the different items/armor and how much extra points/squares they give. Sprinter is described to add 3 extra tiles (or squares) movement, so that would correspond to 4.875 movement points, for instance. [[User:Hobbes\|Hobbes]] 10:36, 8 December 2013 (EST)		It would be nice to have also a summary of the different items/armor and how much extra points/squares they give. Sprinter is described to add 3 extra tiles (or squares) movement, so that would correspond to 4.875 movement points, for instance. [[User:Hobbes\|Hobbes]] 10:36, 8 December 2013 (EST)

			: The difficulty is compounded by the fact the page announces two different ratios: Multiplying the movement stat by 0.625 is equivalent of each tile costing exactly 1.6 movement; while the formula "each tile costs 1.625" is equivalent to multiplying the movement stat by about 0.615 [[User:Medinoc\|Medinoc]] ([[User talk:Medinoc\|talk]]) 16:52, 14 January 2016 (EST)

Hobbes: Created page with "==Diagonals== There's a bit more to this (diagonals for instance are a puzzle for me to figure out) but the 0.625 value is close to the truth, although I've seen a lot of discuss..."

2013-12-08T15:36:03Z

Created page with "==Diagonals== There's a bit more to this (diagonals for instance are a puzzle for me to figure out) but the 0.625 value is close to the truth, although I've seen a lot of discuss..."

New page

==Diagonals==
There's a bit more to this (diagonals for instance are a puzzle for me to figure out) but the 0.625 value is close to the truth, although I've seen a lot of discussion on this.

If you set that each game square costs 1.625 and the diagonal costs 2.298 points to move then it matches the ingame results (7 squares straight, 5 squares on a diagonal).

It would be nice to have also a summary of the different items/armor and how much extra points/squares they give. Sprinter is described to add 3 extra tiles (or squares) movement, so that would correspond to 4.875 movement points, for instance. [[User:Hobbes|Hobbes]] 10:36, 8 December 2013 (EST)

← Older revision		Revision as of 01:48, 5 April 2017
Line 24:		Line 24:
	[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)		[[User:Hazardass\|Hazardass]] ([[User talk:Hazardass\|talk]]) 02:17, 02 April 2017 (PST)
	:Thank you. I've given up trying to figure out Movement a long time ago :) [[User:Hobbes\|Hobbes]] ([[User talk:Hobbes\|talk]]) 20:28, 3 April 2017 (UTC)		:Thank you. I've given up trying to figure out Movement a long time ago :) [[User:Hobbes\|Hobbes]] ([[User talk:Hobbes\|talk]]) 20:28, 3 April 2017 (UTC)

			:You're welcome. Btw these findings are from EW/Long War. I know that LW didn't change the way mobility/movement works in EW, and as far as I know it's the same as EU, so this should apply to all versions. [[User:Hazardass\|Hazardass]] 18:50, 4 April 2017 (PST)