Map Size

#1 Yes. The terrains in TGE are constrained by mission size, though they wrap to seem infinite. ATLAS terrains are limited by the size of your hard drive, I believe.

Of course, making a map useful is more important than the sheer size of it.

#2 Mission areas are an interesting topic. Having done some experimentation I can give you this
information.

The actual mission area stretches as far as you want to go. I've taken a character out to 500,000
before I said "Ok, that's more than enough space for me..". Using 0 0 0 as the central location
however, the useful part of the mission area extends out to about 10,000 in any direction. Beyond
that there is a "jitter" that develops. It's possible that it's a rounding function within the physics
code, or just basic rounding for the position values, but beyond 10,000 the jitter becomes more
noticable the further out you go.

As for Terrain. The largest terrain supported (without engine modification) using 0 0 0 as the central
location again, extends from -2048, -2048 to 2048, 2048. Whatever terrain you place in this area will
repeat in all directions.

It's worth noting that even though the terrain size is limited, you don't have to stop placing objects at
the edge of your original terrain. Objects can be placed on the repeated terrain too, and as long as you
have a way for that terrain to look right, you can place objects as far out as you like (taking into
consideration the jitter that begins at 10,000)

Keep in mind, larger missions take longer to load. Even missions with average size terrains but many
objects placed in and outside of the original terrain can take a very long time to load.

#3 Hmm, interesting. Does this mean that if I create in 3dsMax a model of -5096 -5096, 5096,5096 size and import it into Torque that I can effectively have a map (terrain or whatever the proper word is) that is non repeating and 4 times as large as the original constraints? Or is this completely ludicrous because I don't understand the limitations of the tools I'm dealing with?

#4 You will want to use the built-in terrain as it is optimized by the engine and is why you can have large indoor and outdoor areas. You can however make a terrain in max using a heightmap and then export that heightmap as a bitmap and use that as the terrain (the bitmap size has a limit also).

Also something I'm not sure they mentioned is the shadows are baked into the legacy (tge) terrain and if it repeats the shadows are visable where it repeats. It looks weird to see a shadow where there is no building, tree or whatever.

As far as making it four times larger, you'd want to use TGEA's Atlas terrain as it can be super huge as David already suggested.

#5 I am not eager to use TGEA because:
1. AFAIK, it has the same or maybe even more bugs that TGE has;
2. the GG people themselves warn you away from using it if you don't want to deal with alot of source code (in so many words);
3. the MMO workshop tools are not yet available for TGEA in a tested form;
4. up until very recently the AFX pack was not available for TGEA.

I would like to use the built in terrain of TGE *because* it is optimized but then I will be size constrained and I will have to deal with baked in shadows.

So, is it possible to create my entire terrain in 3dmax and drop it into TGE, and avoid the size constraint this way? I guess I am hoping my 3dMax terrain would classify as a "object". Whatever torque did underneath it (ie,tiling) wouldn't matter since no one would ever see it.

The GG people have consistently said they will not/can not/ don't want to/ increase the terrain size in TGE because it can be modified in the source code (it appears that better coders than I have tried, many times, and given up) or "worked around".

So,is the method I am contemplating any sort of reasonable work around? Or am I gettin in way over my head?

#6 The method you are proposing could be "okay" with the opcode resource for polysoup collision, though you can only have one LOD and no visibility culling (unless you created a number of terrains and layered them along a plane). You will have to use C++ to implement the opcode resource and most likely you will have to do some C++ coding to work with occlusion and the like down the road.

You could try it, but I can't guarantee that it would be workable or usable. Though it might be. I recall someone in the past trying this with DIF files and having a number of problems. Or perhaps they just mentioned it and thought it was difficult. It was long before the opcode resource.