Matrix Games Forums

I did some testing as you suggested. Results are interesting.

Created map:

Height map:

Inf. movement:



Well from results you can see that height map is calculated with discrete square parts with some 10-100m side lenght(dont know for sure). It seems that the center of such map square part is taken for the value of the whole part. If there would be some averaging of that square into a discrete single value involved, I'd suspect that would be shown at least to some level by height map.

So, if you keep all the contours in 100m interval, so that points on both side (that are used in terrain calculation) are on the same contour (same height). Then the terrain height will be continous.

It follows from this that you are limited with the maximum inclination achievable by this discretization. Say ("Max Contour Height" - "Base")/100 (or the distance from one discrete value (center of discrete map square) to the one adjacent) is the maximum possible inclination achievable for any given map.

Is this correct?

Oh and another question regarding multiplayer.
How much the calculation is divided between the participating pcs? Say Maleme airfield scenario with around 300 units. Am I correct that my pc is calculating only routing tables and all that goes with moving and resuplying only for my 150units plus additional interaction with the enemy, or is there some processing that is doubled.

I am just thinking that MP only scenarios could be larger (at least unit wise if not area) due to not needing supreme comander AI for the other side and also splitting the calculation between pcs. Could that mean that 500 or 600 units MP only maps could run equally fast as SP Maleme airfield (300 units)?

Re Map. We use a 100m grid for movement and spot heights.
 
Re MP. We use peer to peer networking with both machines doing exactly the same calculations. This means that all the calculations for both sides are done on each machine. Now yes this does mean that we are not optimising processor loads. But it does reduce network traffic down to a minimum - ie just for the transmission of orders and not for state changes of entities. There is a significant amount of data on each entity that it stored. Having to transmit this each minute of game time certainly was not an option when we designed the networking back in 1996. With fast broadband it just might work. But that's not high on our priority list at the moment.

ORIGINAL: Zorchi

@Arjuna

You say I need to cut valleys in by going in, make the vally and then retrace as near as possible the original line that lead me to the valley.

There is an easier way to make valleys without following a line. You can overlap on the same contour level as much as you like, allowing you to create an inner doughnut and then close it off with an over lapping figure. Use this feature also to make "clearings" in patches of forest, etc.:

Way to go Richard! Thanks for enlightening us. I had completely forgot about that technique. [:)][&o]

@Arjuna & simovitch

Thanks for the info. I'll put it to good use.

http://www.globalsecurity.org/military/ ... 0.htm#par6

You appear to be discussing creating a depression, rather than a valley, although the first example used a extremely narrow valley (which was ignored by the LOS tables generation) to link the depression to the lower ground surrounding the elevated portions of the map.

The linked 'Land navigation' document has good descriptions and diagrams of the various feature types.