bushlurker

Yes - you're basically "scaling" the X and Y distances, but not the Z (height)... Sortof... a bit... yes... You have to make it the size it is... If a place is too big, either you pick another place, or you Scale (down)... Scaling has it's issues and rarely works well... I tried it once - with my very first island... :( (of course)... I decided I'd make a 200km x 200km chunk of Scotland - in a 20km x 20km size... It was a bad idea.... eg: - a runway which on the realworld map was 1km long became an unusable 100m long - the only alternative was to have a "toytown" runway no plane could use, or make it a "proper size" - unfortunately, making it 1km long meant it entirely covered the little "town" next to the runway. Towns which were 2km wide became villages 200m wide, houses would have to be the size of dog kennels - worse still - hugely impressive mountains with peaks over 1000m became 100m small hills (I scaled heights too - to keep things "in proportion"). That's an extreme example, but the concept is the same - scaling is dodgy at best and rarely works well... Because that's the size the "Real Altis" is, and thats the size of "box" it will fit into... Lets try an example.... You've spotted a nice little realworld island.... it's almost exactly 12km wide at its longest/widest point... To make this in a realworld size, we need to figure out what grid & cell sizes to use We're stuck with preset grid sizes - 1024x1024, 2048x2048, 4096x4096 - but we can vary cell size (though its best to try and stick to relatively "sensible" and easily divisible cell sizes, so - 7.5meters per cell = ok... maybe, whereas 7.14265meters per cell = Definite Bad Idea) so... the target is 12km wide - maybe allow for a little "sea" all around... lets guess at about 14-15km as a suitable "terrain width/height".... 2048 cells @ 10 meters per cell = 20480 meters width = too big 1024 cells @ 10 meters per cell = 10240 meters (10km) = too small 2048 cells @ 7 meters per cell = 14336 meters (14.3km) = Good! 2048 cells @7.5 meters per cell = 15360 meters (15.3km) = Also Good! Since the actual realworld island is only 12km wide, I'd probably settle for the 2048x2048@7m size (14336 meters). So now - all you need is a heightmap of that realworld island - a heightmap which is 14336 meters wide. Lets see how you've been getting your realworld heightmaps.... Sounds good - you grab the best and cleanest data you can find, the highest res you can get... Jakerod has already mentioned setting your Projection FIRST - before you load the data - that basically tells GM "This project is in UTM Zone <whatever>, WGS84", so any data you subsequently load will automatically be reprojected to the "project coordinate system" - which is the correct UTM, etc (and all measurements will now be happening in Meters, which will come in handy just shortly... Almost there.... Once you have the Digitiser tool active - Right Click on the area and choose the "Create Area/Polygon Features > Create Rectangular/Square Area (Specify Coordinates)" option. In the dialog box which appears, choose the "Corner w/size - Global Projection" option (since the Global Projection is already set to UTM, all measurements are in meters so - look at the required parameters for this Box Drawing Option)... There's "slots" for "North" and "West" - obviously these are for the X,Y coordinates of the corner of the box. And theres slots for "Width" and "Height" too... The North & West boxes will have values already - they'll be the coordinates of the point where you right-clicked - ignore them for now... The Width and Height slots will have values too - BUT - we know what Width and Height we want - we worked it out earlier, remember? So - for our example, you'd type "14336" for each of these values - then hit OK. Now you have a "Cropbox" which is exactly 14336 x 14336 Realworld Meters in size (It'll be out of position, but you can right click on it with the digitiser tool and choose "MOVE" and drag it until it neatly frames your target island on the overall heightmap data you loaded)... Now you can export just that 14336 meter "chunk". This is the procedure, except - DON'T change the X and Y sample settings!!! - Leave them at whatever crazy values they happen to be. Just export the heightmap as an Arc ASCII .asc grid file, using the box as a "cropbox" to define the output bounds. Of course - your actual heightmap data wasn't conveniently using a 7 meter cell size - maybe it was actually 70 meters, so instead of a 2048 heightmap file, you might end up with a 204 - THAT DOESN'T MATTER! It's 14336 meters wide - that's all that matters. Now you need to get rid of the built-in projection, since we have to force all data to that pesky TerrainBuilder "preferred location", so... If there was a *.prj" file generated alongside your main heightmap file - delete it! Then - import the heightmap into L3DT - then immediately - without doing ANYTHING ELSE - choose to export it again, as an .asc file - again... As you do so - notice that theres an "options" button at the export stage in L3DT - click that... Change the "UseProjGeoref (bool) value to "false" Export the heightmap file... Now you're ready to import into TerrainBuilder... Once the file is loaded into TB - right click it on the Raster images list, and choose "Terrain Coordinates & Properties" Set the Easting & Northing to TB's "preferred location) of 200000E, 0N and... Set the Width and Height to...... you guessed it - 14336 meters - 'cause that's what it is! Now - in your mapframe Location tab - make sure the Mapframe is using the same Bottom Left coordinates of 200000E, 0N Then - in the Sampler Tab - Top Left Terrain section... You guessed it again... You set 2048x2048 grid size, and 7 meters cell size - TB will report that this is going to result in a terrain which is 14336 meters wide... (At this point, take a moment to realise that a 4096x4096 grid with 3.5 meter cells, or a 1024x1024 grid with 14 meter cells would result in the exact same size of terrain - all three are potential viable settings, though I think we've chosen the best all-round values already) Go to the Processing Tab and hit "Rebuild Terrain", then hit "OK" to leave the Mapframe Properties and... You're done You have a realworld heightmap - of the exact physical realworld correct size, in the grid and cell size you want - forced into the location that TB demands... (Notice how, after the initial planning/concept stage, we didn't even consider grid or cell size until we got to the end and the TB stage - in between we were working entirely with meters) All of this stuff - explained in a bit more detail, and possibly even with an illustration or two, will - eventually - be one of the little "mini tutorials" that I'm currently working on, but in the meantime - this brief rundown should get you started... Good Luck! B

Equally obviously, I got this wrong...! :o I should have said... "obviously - the SMALLER the landgrid, the easier it is to go over the limit with dense object placement... Small LandGrid + many objects = overload Larger LandGrid + same number of objects = OK LandGrid isn't a parameter you can set directly, its size is influenced by the other sizes you CAN choose, such as Sat & Mask Tile Size, overall terrain size & resolution, etc... The basic concept is (vaguely) explained in The BI WIKI... Pretty confusing, huh? Be assured that nobody actually understands precisely what TB does exactly when it "Slices the Layers into tiles". However, even from the above explanation you can see why some of the parametrs you have control over are considered to have "reasonably safe values"... Notice... ie: keep "overlap" around 16 if possible, and... Texture layer (grid) size will vary, depending on other factors, but "close as possible to 40x40m" is a good rule-of-thumb for that one... In general, your posted terrain parameters are a little... odd... 1024x1024@2m = 2048 meters Thats a VERY small terrain, smaller than the range of some weapons, and compared to maximum viewdistance it's very small indeed... Arma doesn't like terrains that are excessively huge, but it also doesn't like terrains which are just TOO small... 2x2km is getting into "too small" territory, and - for an experimental first terrain, 4x4km or 5x5km might be a better choice 5120x5120@0.4m/px is an odd resolution for a sat image too - even with the above terrain size, 2048x2048@1m/px, or 4096x4096@0.5m/px would probably make for easier tiling and divisions Your map should still work in-game OK, but due to the small size and consequently non-standard parameters, you may run into occasional issues - like the "too many objects" one... And - 2048x2048 for Texture Layer size - given that your terrain is only 2048x2048 - doesn't really allow for "tiling" of the sat at all - were it not for the stated overlap. B

= "Too many objects in LAND grid rectangle 13,8" Landgrid size should be mentioned in your Samplers Tab... There IS a limit to the number of objects allowable per LandGrid, and - obviously - the bigger the landgrid, the easier it is to go over the limit with dense object placement... B

We're out of sync Jake... I blame the transatlantic time-difference... and possibly those Five Guys and their gift cards... ;) B

0:13 - Your Project Folder is called "LifeModMap", but your Project Name is "michigan" - they have to be the same. 0:14 - The "michigan.Cache, .Layers and .Shapes folders indicate that you've saved the Terrain Builder project in your main Project Folder - that means all of that data will be included in your final map which will bloat it enormously... The "Source" folder is ignored when packing - a "TerrainBuilder" folder inside "Source" is the place to save your Actual TerrainBuilder project, since it's only required for the TerrainBuilder stage. 0:26 - your ".wrp" file is called "michiganwrp.wrp - it has to be the same as the Project Name which should be the same as the Project Folder. B

HERE's some readymade 5x5km ones - ideal for messing around with in L3DT. P.S. - Since these are 16bit greyscale .png heightmaps, there's no "inbuilt maximum and minimum height values". So open the accompanying .pbl file in notepad and you'll see the two values you need. When you import it into L3DT, just use those Max & Min height values in the "Max & Min" slots provided, and they should all import in proper proportions... Have fun B

Looks pretty impressive if you're a C4D user! Seems to be around £250 UKP = #$380 I'm pretty sure that if you have the funds, TerraSim will be happy to sell you any of their tools. MaterialMap, DEM Tools and the pretty impressively clever RoadMap tool are all "standalone" and don't require the main TerraTools package to operate... They ARE "expensive as hell" though... I don't have current "single user" prices to hand, but you can expect these TerraSim tools to be around $6000-$7000 each.... B

This looks absolutely terrific so far! You're also absolutely correct to start with a small terrain... Like M1lkm8n says - a small starter terrain processes fast and is quick and easy to work with. There's not a huge area to fill so you can quickly progress through all the stages, from heightfield, mask & sat through roads & veg placement to object layouts. Before you know it, you've had a go and learned the basics of all the important skills - AND the end result is a nice little "infantry map" which is a nice "first release" in it's own right! Well done all round so far!!! If you need any help or get stuck with anything - make a thread in the Terrains Section, and you should also consider joining the Skype Terrainmakers channel sometime! B

Folders image - you have two "groundtexture sets" - correct folder - good so far. Layers.cfg - You define 2 surfaces - they refer via the correct path to the two groundtexture rvmats - still good so far. cfgClutter.hpp - 4 clutter types defined - looks OK again. cfgSurfaces.hpp - Now suddenly "Beach" has disappeared and we have "Forest" instead - which refers to "Forest*" groundtexture files which aren't present at all. (Also - the probability parameters for the grass character add up to 1.1 - that'll cause clutter problems - 1.0 maximum) config.cpp... This is Huge! - Unless you want to customise all these parameters you'd be better off inheriting from Altis or Stratis and just changing what you need... still, on a (very brief) glance thru... 12. class BiA_Michigan - "BiA" is "Bohemia Interactive Australia" - this class entry should read "A3_Map_Michigan" 2648. worldName = "\LifeModMap\michiganwrp.wrp"; - drop the leading"\" from this path. 2654. mapSize = 2048; But... on line... 2678. offsetY = 8192; - which should be your mapsize in meters too - which is it? 2048 or 8192? ... that's all the obvious flaws I spotted on a quick glance through, but since the config is 3086 lines long, it's not easy to check thoroughly... grass_green.rvmat & beach.rvmat - both "Stage" texture paths refer to the "_nopx" texture - "Stage 2" should path to the relevant "_co" texture file. I would also strongly suggest you use PboProject for packing - AddonBuilder saw all these errors, but it let them pass, and let you make a pbo and think that it might actually work, only to be disappointed in-game. PboProject would just have laughed, stopped immediately, told you where the problems are and refused to go any further until you fixed them... Which is a little harsh, maybe, but saves you time and frustration in the long run... B

Looks like a bad heightmap "seam" or "join"... is it a downloaded heightmap of a real place? - If so, then it's a dodgy one... You can either try to get a better quality heightmap of that area or - export it to .asc - load it into L3DT - manually smooth out the "crack" - re-export from L3DT as an .asc file - reload it into TB and use the Mapframe Properties Processing Tab "Rebuild Terrain" command to "re-inject" it back into the mapframe heightfield... B

Check all paths everywhere in all of your configs and groundtexture rvmats for paths beginning with "P:\" - remove all "P:\" from those paths - reGenerate layers, re-export .wrp - repack ... see if it fixes things... B

Could you maybe post a screenshot or two of this "crack"?? B

Sounds very much like a Floating Point Precision problem... You generally only see this sort of thing on "oversized" terrains. I'm guessing that it was happening when you tried to work on an area far to the North and East (Top Right) of your map - where you're furthest away from the "origin point" Basically, the engine stores the positions of things as coordinates... Down near the "Origin Point" (bottom left corner), the coordinates for a thing might be... X=12.345678, Y=12.345678 = Very Accurate positioning... But in a REALLY BIG terrain, up at the opposite corner of the map, coordinates start to get like this... X=123456.78, Y=123456.78 = much lower accuracy... Keep going further and you can guess what happens - accuracy is reduced still further... the engine starts to struggle... It's trying to keep track of the positions of things and it's having to work with very inaccurate coordinates... Object placement accuracy deterioriates, the engine can't decide if a thing is "here" or "half a meter over there" because - there's "no in between possible" I'm guessing it stopped happening when you moved to an area of the map where accuracy was better (nearer the Bottom//Left origin) Your terrain is probably just Too Big... B

I'm guessing you used a "soft brush" or resized your mask using something other than "nearest neighbour - preserve hard edges" or something similar and it did some "antialiasing" or "edge blending" between your colours Every pixel of colour on your mask is converted to a texture - the colours which have textures associated with them become those textures - the colours WITHOUT a texture associated with them are assigned one based on the "nearest colour"... Theres a border or edge of a "different colour" between those two areas - that "different colour" is being interpreted as "whatever colour is associated with concrete" B

Absolutely right. Normally at least, you get a BI terrain on launch, but once you go to the editor and load a different terrain, when you quit back out you get the "cutscene" for that terrain. The cutscene is basically like a mini mission, with a camera instead of a player, which is included with the terrain itself, and plays behind the menus when in-game. If you don't actually have a cutscene in your terrain, then it defaults instead to a fixed camera view set at the position dictated by the "seagullPos[]=" parameter in your main terrain config.cpp. That sounds like the current "seagullPos" then, though you shouldn't see it at initial start. That could be caused by a command in your start parameters, or possibly a parameter in your terrain config if you've copied Altis or Stratis configs and they have some sort of "priority" set... B

Try Exporting the heightmap from GM as Arc ASCII (.asc)... Delete any .prj file which is generated. Load the .asc into L3DT Immediately go to Export Heightmap" in L3DT - choose to Export as .asc and in the "export options", change "UseProjGeoref (bool) = true" to "=false" That should get rid of any projection info and allow TB to import the heightmap properly... B

Not sure if they have a WMS server, but you can download direct from the website - then just drag it into Global Mapper. If it asks for projection details on the way in, use British Grid OSGB36 (Best Transform) - NTv2 Grid and it should drop into place nicely. The Open Streetmap Data available via WMS in Global Mapper is raster-based - useful in itself if you crop it out at the same res as your sat and drop it into Terrain Builder as an additional (satellite) guide layer for object placement or whatever, but if you want the equivalent Vector based product - which may or may not contain some usable shapefiles for roads, etc - you can get that HERE. (There's whole world coverage there so you'll need to delve into the regional directories). I don't know offhand of a OSM vector data WMS server, but there may be a few around. Try Google?? The downloadable OSM vector stuff is Transverse Mercator - WGS84 - Degrees, if I remember correctly - it should autodetect as it loads hopefully. Remember after you've loaded all this differently projected data to reproject the whole deal (in GM... Tools > Configure > Projection) to UTM, WGS1984 Zone 31 before you set up your layers exporting... B

Try the UK Ordnance Survey "OS Terrain 50" product - I think it's free OS Terrain 50 They do a "Terrain 5" too - which, as the name implies, is 5m res rather than 50 - it's pretty expensive though. Still, the 50 is better than the equivalent SRTM, and may be less fuss than the often scrappy ASTER coverage too... B

Try... @Myisland/Addons/mbg_generic_african_buildings.pbo @Myisland/Addons/Myisland.pbo B

Sadly not... Clutter is defined in the cfgSurfaces section of the config - and all of that stuff is purely used at the "runtime" stage - it plays no part in the TB/Buldozer stage at all... It's actually not too bad testing clutter mixes at the runtime stage... You can open your final terrain.pbo with a Mikero tool - change a value or two - re-pbo and relaunch Arma and you're ready to text your next variation... Everything is already binarized by that stage, so there's no need for rebinarizing or anything - just open pbo - tweak numbers - close pbo - relaunch Arma Probably quicker than repeated launching of Buldozer :D If you find that your config.cpp is a config.bin - theres a Mikero tool for that too (DeRapify) which will return it to readable textfile form... While you're running your tests, you can just leave it as an unbinarized config.cpp - Arma will still use it no problem... B

Yup... If you really really want to, you can take a peek at a tile that TB has made - load the .paa into TexView and save it as a .tga. Then when you load it into Photoshop you'll find it's a 4-channel, 32bit RGBA image and, if there was a 5th or 6th colour happening in that tile, you should see shading in the Alpha channel... The clue is in the "suffix" - "_lca" - it follows BI's naming convention... _co = "Colour image" = straight RGB 24 bit image _ca = "Colour Alpha" = RGBA 32 bit image with an alpha channel and the "l" just stands for land - so if you see a mask tile which ends in "_lca" then its a "six colour" tile No need to mess with any of that really though - just use regular colours on your standard "mask_lco" and TB will do the complicated stuff for you at the tile crunching stage... B

It basically uses what would be the alpha channel to carry those two other bits of information for the final two colours (or one colour plus normal data) and you don't have to do any messing around at all. Back in the old 4-colour Visitor 3 days, the Extremely Clever Mondkalb figured out all of this stuff which happens "under the hood" and managed to do what you suggest - "post-edited" a 4 colour tile or two to use an extra couple of colours. At that time BI were using TerrainBuilder - and so Chernarus, etc had 6 colours here and there (and about 12 surfaces overall, using the "colour counting per grid tile) trick above). We didn't have TB back then - now we do, so all you have to do is use those 6 colours (per area) on your standard RGB mask - TB does all the crazy stuff for you. B

Hi guys.... Yes - the mask should be a 1:1 pixel-by-pixel recreation of your satellite image, but in a limited number of "simple colours", each of which represents a "surface type" as depicted on the "realworld" sat image. It's 4, 5 or 6 colours - per texture grid... could be as many as 12 actual colours/surfaces on the original mask. For example, the Arma 2 CWR2 "Everon" terrain has 14 different ground surfaces in use, and therefore used a 14 colour mask - and that was back in the days when only 4 colours were allowed - per texture grid. They're "recoloured" at the tile-slicing Generating Layers stage - as someone mentioned above. However - they're "recoloured on a tile-by-tile basis" which is why each tile looks different from the one next to it. This is basically why you can't simply stitch the mask for a terrain back together in the way you could with the Sat image layer. Just to complicate matters further - think for a moment... the mask visibly seems to consist of tiles coloured Red, Green, Blue & Black - that's 4 colours - but 6 colours are allowed "per tile" - where are the other two? Lets look at a quick example to see what's actually going on... Lets say you have a mask with Seven different surfaces - using 7 colours. The colours you use on the mask are irrelevant - as long as they're clear to you what's what, you can use anything you like, you just need to make sure you have the RGB values for each colour listed in your Layers.cfg file - one colour for each surface. In that layers.cfg you've listed these surfaces Ocean Floor = Blue Beach Sand = Yellow Ocean Rock = Cyan Green Grass = Green Dry Grass = Brown Rock = Red Urban Gravel = Magenta Now - that's 7 surfaces/7 colours - only a maximum of 6 are allowed per texture grid, so we need to be careful and make sure that in any particular texture grid sized area, there's no more than 6 happening at once. Best way to do that is to make a grid in Photoshop the size of your texture grids and overlay it on the mask - then count the colours in each "cell". (remember the overlap!) **See above for BadLuckBart's reference link to the BI Wiki where this stuff IS explained in reasonably understandable terms. Okay. So - you have your Layers.cfg & mask (assume a sat image and everything else is in place), you choose to "use 6 colours" at the Generate Layers stage and start the tile crunching process... First thing TB does is to slice your mask into terrain grid-sized chunks - allowing for the overlap you chose. (Overlap is important for tiling transitions, but 16px is usually enough & is "standard" - using more can result in performance loss since bigger overlaps mean more tiles required to cover the same area = more data to load, etc). Now it looks at the first mask tile - it looks at the very first pixel of that tile, finds that it's "Blue", so it goes to Layers.cfg and looks down the list of your surfaces - looking for that 0,0,255 RGB value. It finds it labelled as "Ocean Floor" - SO IT RECOLOURS THAT PIXEL BLACK AND MOVES ON TO THE NEXT PIXEL (Actually, there's simultaneous tomfoolery going on with matching rvmats and the routine actually likes to work in "texture layer-sized" chunks - usually about 40x40m, but lets just focus on the colours thing here) Notice the "recolours the pixel to Black" thing there... Regardless of what colours you actually used on the original mask image - the layers-generating routine will recolour each pixel it encounters in the following order... Black, Red, Green, Blue - plus TWO Alpha Channel "intensities" = 6 colours maximum (32bit image) So far - it's assigned one pixel - it was "Ocean Floor" and since it was the first pixel, the first of TB's "internal colours" - Black - was assigned to that pixel... FOR THE REST OF THIS TILE - OCEAN FLOOR THEREFORE = BLACK Next pixel it looks at is Cyan on your mask - so off it goes to your layers.cfg list again... It looks at the list - the first item is Ocean Floor and Blue - so that's not it - next on the list is Beach Sand - that's assigned to Yellow so that's not it either. Then it finds the third item on your list - Ocean Rock! Ocean Rock is assigned to Cyan, so TB RECOLOURS THAT PIXEL RED AND MOVES ON TO THE NEXT PIXEL It was a very small rock area, so next, TB finds a whole load of "Ocean Floor/Blue" pixels on your mask - it's assigned Black to that surface already so it just colours them all black and moves on again... Eventually, you get to the spot on your mask where you're nearing the island itself... The next pixel TB checks out is Yellow - that's a new one, so off to the layers.cfg list once more and - starting from the top of your list every time - it tracks down till it finds Yellow = Beach Sand, then - it colours that pixel GREEN on your mask tile... ... etc, etc, etc - until the entire tile is done... Now lets look at another tile - in towards the centre of the island.... TB starts the same routine all over again for each tile, so... First pixel = Green... Layers.cfg says Green = Green Grass, so TB recolours that pixel Black, and moves on to the next... We'll stop right there 'cause I hope you've spotted what's going on by now... In the first tile we looked at - once TB had recoloured it, Ocean Floor = Black... In this tile, we're only one pixel in and Black is now Green Grass! TB basically treats each tile individually and recolours the pixels it encounters according to that little list of its own - always in the order - Black, Red, Green, Blue and, if necessary, Alpha grey 1, Alpha grey 2 Just to complicate matters, it also uses the list of surface types & matching colours in your layers.cfg in the same way - reading down the list, in order, from the top. That means its perfectly possible to have two mask tiles side-by-side, and "Green Grass" is Black in one of them, but it's Red in the next tile because, just by chance, the very first pixel to be checked in that second tile was "Beach Sand", so IT got assigned to Black, which means that when Green Grass was subsequently recoloured, it used TB's "next available colour"... By now you've also probably spotted that in TB, if you choose to use a "Normals" sat layer, then it means checking the "5 COLOURS + Normals" box - you lose one of those two "Alpha channel intensities", and it's "slot" is taken up by the normals layer for 32bit pixelshader processing or some other complicated graphics thingy which we don't really need to understand. Actually - there's no need to delve too deeply into what TB gets up to when it's tile slicing either - most of the time. As long as you follow the basic rule of "No more than 4 (or 5 or 6) colours per <whatever your terrain grid size in mask pixels is>" - you remember to allow for the overlap between tiles - and count colours-per-tile carefully via a visual grid or something while making your mask - you should be able to squeeze in a few additional "spot effect textures" here and there. B

PboProject usually tells you errors pretty clearly - that's what makes it both a Complete Pain In The A** - AND a Totally Essential Tool... In this case it says... "Invalid argument P:\temp\p:" ...and that's exactly what the problem is... "P:\temp\p:" is NOT a valid path... You can see PboProject trying to use the path... "cannot copy p:\a3\plants_f\tree\t_pinus.p3d to P:\temp\p:\a3\plants_f\tree" It's trying to copy that file to "P:\temp\p:\a3\plants_f\tree" - but since there's no such location possible - it fails while "preprocessing" (ie: copying) this file... So it reports the error... "preprocessing files produced an error" B

One thing to watch out for when using ZeroG's 3D Editor pack is the "Editor Update"/"Editor Upgrade"/"Editor 101" or whatever its called, which is included in his pack. Basically what these "editor addon.pbo's" do is to add classnames to all those "terrainmaker-only" objects that don't normally have one. That allows them to actually show up in the 3D Editor object lists so you can select and place them. ZeroG's been AWOL from the forums for a while - consequently, his "editor addon" is a little out of date and doesn't include entries for quite a few terrain objects which have been added more recently. I noticed ZeroG back online on the Terrainmakers Skype channel just recently, so it may be he's back in business and will be updating/producing more goodies for us in the near future, but meantime, I've been using... CJTF101's Editor Update - which does exactly the same thing as the one included with ZeroG's bundle, but is a little more up to date. (Use one or the other of these addons when you're 3D editing, but not both at once ;) ) For everything else to do with the 3D Editor procedure - follow ZeroG's instructions - it works nicely and its a good alternative/addition to the usual basic TB/Buldozer placement options... B