bushlurker

Hi guys! Firstly, a few downloads - example Dominations converted to user islands... I've posted two of these elsewhere, the Sbrodj one I made for OldBear before Christmas - we both went off to do Christmassy stuff, and it's out of date before I even post it! - one of the main reasons for the following guide!... Domination Panthera 1.17 Domination Sbrodj 1.22 Domination Duala 1.27 The Sbrodj version was previously unreleased and nicely justifies this thread here in User Missions where casual Domination Tweakers may spot it more readily than hidden in the bowels of "mission editing & scripting" where the guide part at least more properly belongs, I guess... 3 different versions of Domination above, but the procedure for porting to different islands is pretty much version-proof - though the files you need to edit are NOT! Xeno is liable to update these core files with any new version, so confident Domination Tweakers who've made a lot of personal changes - and who hasn't? - may find it more useful to know how to port their personalised version to the island of their choice rather than wait for me to release an updated port and then repersonalise that... On to the more interesting bit!... HOW TO DO IT YOURSELF I'm assuming that if you're interested in this then you already know how to DePBO a mission, access its files and rePBO afterwards... For this runthru I'm using Domination Everon West AI... All Domination versions are actually generated from a single mission, but for porting purposes I always start with basic West AI, and I use the Everon version purely to make things as easy as possible... ready setup for 18 main targets is usually fine for User Islands and throughout the scripts you can just keep looking for those "ifEVERON" lines... I'm by no means a coder so simple and easy is my rule at all times :) For that reason seasoned Domtweakers may find parts of this unduly simplistic... just shortcut thru those parts guys! OK - First stage is to actually get the mission assets physically on to the new island... *dePBO the Domination mission and copy the resulting folder into your users/<yourname>/MyDocuments/arma2/missions folder *Into the editor and load up the mission... switch to "markers" so you see them all as well - theres some hiding in corners - drag select EVERYTHING and hit <ctrl>C *Go to "load mission" and load a "new mission" on the target island of choice *Hit <ctrl>V - you should see everything pasted on to your new island... it needs rearranging now... but first... *Hit "Save" and save this mission as "tempdom" and back we go to windows... *Now - go to the missions folder - you'll see a new mission folder called "tempdom" - inside that is a "mission.sqm" file - this is your new mission, so now all we need is the rest of the domination code *Go to the actual Domination mission folder and select EVERYTHING inside - ALL the folders and ALL the files... <ctrl>LeftClick the "mission.sqm" file so you're NOT copying that and hit <ctrl>C *Navigate back to inside "tempdom" and paste - 411 files will be copied and we're done... *Rename "tempdom" now to whatever you want your mission file to be called. At this stage download and add THIS file as well - just drop it in the main mission folder... we'll call that later to get positions for stuff... (if you have a better way of getting map coordinates you usually use, go with that)... OK - Back into the Editor and load up the mission... This is where you can exercise a little creativity, so pick the airbase you'll be using as mainbase and arrange all the mission assets to your liking - remember the markers too... I'm not going to go into much detail here as it should all be fairly obvious what's what - one thing to remember is to edit all the soldiers individually - make them all "playable" for now... You need a temporary "player" unit too - so add a civilian or something - flag it as "player" for now and add... this exec "Position.sqs" to his init line... *remember to hit "save" every now and then... (watch out for the "boot hill" marker and the temp spawn units - hide them on an obscure offshore rock somewhere if you can)... By now it'll be obvious that some Domination assets are missing - the AI hut, the Ammocrate, Jet,chopper and wreck repair buildings, the radar and base defence... etc... All of these items are added via script so this is what the "position" script is for... You can preview the mission at any time - either position or walk your player guy to where you want the item to be - and note down the coords onscreen - they update every 2 secs... Obviously the ammocrate is best beside the teleport base flag, the repair buildings beside the repair points, etc... Heres a full list of the things you'll need to actually collect coordinates for (as opposed to physically rearrange in the editor)... AI Hut Ammocrate Factories for Jet, chopper & Wreck (3 locations beside the repair points) Radar and Base Defence (3 locations close together) Isle Defence (single set of coords basically the centre of the island) Parachopper Starts (3 sets of coords off out of sight of land near the edge of the map) Parachopper Ends (another 3 as above) AI Attack choppers and planes Start (one set of coords anywhere out of sight) Bonus Vehicles (3 positions somewhere neat on the base) Bonus Air (5 positions somewhere handy as above) OK... At this stage you should have the base as you want it, and have collected a bunch of coordinates for all the items listed above... we need one more set of coordinates - the Main Targets... we'll get these from the island itself... *dePBO the island (or if theres several files look for a likely config-containing one) - find the island config and look for a section where theres loads of entries like this..... class Mallaig { name="Mallaig"; position[]={8291.55,6025.1}; type="NameVillage"; radiusA=150; radiusB=150; }; There'll be a "NameVillage", "NameCity" or "NameCityCapital" entry for each named location on the map... obviously you can copy both the name and the position for each Main Target from here - so keep this file handy for ezee copy 'n paste later... Right - final stage now... we need to enter all these coordinates in the appropriate scripts... here's the scripts we need to edit and the bits we need to change... i_server.sqs *Bonus Positions... look for... #ifdef __EVERON__ d_bonus_create_pos = [4990.15,12084.1,0]; d_bap_counter = 0; d_bonus_air_positions = [ [[4182.3,2256.81,0], 0], [[4166.59,2256.81,0], 0], [[4150.93,2256.81,0], 0], [[4135.31,2256.81,0], 0], [[4120.28,2256.81,0], 0] ]; and... #ifdef __EVERON__ d_bvp_counter = 0; d_bonus_vec_positions = [ [[4237.67,2253.91,0], 0], [[4230.6,2253.91,0], 0], [[4223.5,2253.91,0], 0] ]; Change the coordinates to your collected ones - the FINAL "0" in each case is the compass orientation of the item - remember to set that too Next look for... d_airki_start_positions = [ [170.391,8480.83,400] ]; Change to your AI attack planes & choppers start Point, last figure "400" here is Start Height. Also in i_server.sqs... Parachopper Starts and Ends... look for... #ifdef __EVERON__ [ [648,9586,400], [484,4804,400], [496,789,400] ]; And change BOTH the starting 3 x positions, AND the end 3... again, the final "400" is starting height. ***EDIT*** With Xeno's Domination 2, the above items in red no longer seem relevant - you won't find them so don't edit them... Remember - this guide was really for the first version of Dom - 1.xx and badly needs updating... ***Theres another red bit below - if you're editing Domination 2 - ignore that bit too! As always - Xeno improves things all the time and things have been simplified for us normal humans in Dom 2 Next, look for... d_with_isledefense = if (d_params_WithIsleDefense == 0) then { [[5133,4803,0], 6000, 6000, 0, 3] Change the first two coords to your collected ones And finally... // position and direction of the AI HUT d_pos_ai_hut = #ifdef __DEFAULT__ if (isNil "d_with_carrier") then {[[4665.4,10203.9,0],325]} else {[[14509.6,364.861,15.9], 34]}; #endif #ifdef __EVERON__ if (isNil "d_with_carrier") then {[[4257.52,2133.27,0],270]} else {[[14696.9,543.778,15.9], 34]}; We want to change the FIRST set of EVERON figures - the "if (isNil "d_with_carrier") then" ones - remember that - we'll be doing that again later... the "270" is the orientation... Thats it for "i_server.sqs"... i_common.sqs 3 things to change in this file... the most obvious being Main Targets... look for... #ifdef __EVERON__ target_names = [ [[3788.06,2527.39,0],"Kinsella",250], // 0 [[3156.84,3910.89,0],"Djolan",250], // 1 [[4474.85,6699.12,0],"Bolabongo",250], // 2 [[1258.46,4403.18,0],"Bidora",250], // 3 etc, etc, etc Change the names and coordinates to the ones you found in the islands config... the "250" is the size of the red target circle and also the defences spawn circle - play with this if you like to suit the specific target... *while we're passing - look for this line... #ifdef __OWN_SIDE_WEST__ FLAG_BASE setflagtexture "pics\flag_afrene.paa"; and if you like you can change the base flag here... a 512x256 pic works nicely - even a .jpg, tho .paa is smaller - just include your pic in the "pics" folder and set the filename and path here... Handy for the Island National Flag, if it has one, etc... On to... // positions for aircraft factories (if one get's destroyed you're not able to service jets/service choppers/repair wrecks) // first jet service, second chopper service, third wreck repair d_aircraft_facs = #ifdef __DEFAULT__ [[[4097.22,2231.2,0],60],[[4397.26,10690.8,0],148],[[4405.52,2240.69,0],325]]; #endif #ifdef __EVERON__ [[[4650.07,2240.69,0],0],[[4330.54,2240.69,0],0],[[4405.52,2240.69,0],0]]; #endif As it says - edit the EVERON one with your 3 x new factory coords. and finally... // position base, a,b, for the enemy at base trigger and marker d_base_array = #ifdef __DEFAULT__ if (isNil "d_with_carrier") then {[[4560.96,10291.4,0], 220, 750, -30.6]} else {[[14716.3,542.458,0], 40,230,270]}; #endif #ifdef __EVERON__ if (isNil "d_with_carrier") then {[[4318.38,2248.12,0], 450, 500, 0]} else {[[14716.3,542.458,0], 40,230,270]}; The Infamous Enemy @ Base trigger and marker... change the EVERON "if (isNil "d_with_carrier")" one... Here, the "450, 500" figures control the width and depth of the trigger and marker - as you'd expect, but the final "0" which I think should control orientation - doesn't! Can't figure this one out - can't rotate the damned thing - I dunno... I went into non-coder headache mode at this point and had to go off and lay roads on my island for a rest :) - finally I cheated and just made the marker big enough to cover the base... Ok - nearly done now... on to... i_client.sqs Only one thing to change here... the ammobox... // position of the player ammobox at base (created only on the players computer, refilled every 20 minutes) d_player_ammobox_pos = #ifdef __DEFAULT__ if (isNil "d_with_carrier") then {[[4707.69,10232,0],320]} else {[[14490.3,365.406,15.9],180]}; #endif #ifdef __EVERON__ if (isNil "d_with_carrier") then {[[4162.67,2159.38,0],270]} else {[[14690.2,544.483,15.9],180]}; #endif You know which one to change here..... For the final script we need to delve into the x_scripts folder and open up... x_initx.sqf Slightly more complicated stuff going on in here - it's all kinda scary, but the bits we change are... if (d_own_side == "WEST") then { _x_objs = [[4452.74,10256.3,0], random 0, ["radar","usmc"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); } else { _x_objs = [[4452.74,10256.3,0], random 0, ["radar","ru"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); }; _dgrp = [d_own_side] call x_creategroup; _unit_array = ["basic", d_own_side] call x_getunitliste; [[4452.74,10256.3,0], (_unit_array select 0), _dgrp,true] call x_makemgroup; [_dgrp, [4452.74,10256.3,0]] call BI_fnc_taskDefend; 4 actual sets of coords here, since the Ruskys use the same position but different radar units - we only need to change the "if ownside=WEST" ones really, but if you're even slightly confused - just change ALL these coords to your collected Radar one and on to the next bit - directly after... if (d_own_side == "WEST") then { _x_objs2 = [[4210.8,10670.5,0], random 0, ["anti-air","usmc"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); } else { _x_objs2 = [[4210.8,10670.5,0], random 0, ["anti-air","ru"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); }; _dgrp = [d_own_side] call x_creategroup; _unit_array = ["basic", d_own_side] call x_getunitliste; [[4210.8,10670.5,0], (_unit_array select 0), _dgrp,true] call x_makemgroup; [_dgrp, [4210.8,10670.5,0]] call BI_fnc_taskDefend; Same idea again - we only need WEST but if you're unsure - do 'em all with your second coordinate pair and move on to... if (d_own_side == "WEST") then { _x_objs3 = [[4737.63,9774.83,0], random 0, ["anti-air","usmc"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); } else { _x_objs3 = [[4737.63,9774.83,0], random 0, ["anti-air","ru"]] call (compile (preprocessFileLineNumbers "ca\modules\dyno\data\scripts\objectMapper.sqf")); }; _dgrp = [d_own_side] call x_creategroup; _unit_array = ["basic", d_own_side] call x_getunitliste; [[4737.63,9774.83,0], (_unit_array select 0), _dgrp,true] call x_makemgroup; [_dgrp, [4737.63,9774.83,0]] call BI_fnc_taskDefend; Once more - all the same actual coordinate... just use your third BaseDefence coordinates here and save the file And - I think - that's it!!! Last couple of things to do... go preview the mission - check how the new spawned items look for positioning - retweak if necessary... all the scripts should be kicking in properly now - AI should recruit, radiotowers should be spawning, etc, etc... If you're happy - and you should be! - then delete your civilian position finding guy, and make one of the actual Domination player units "player", set the time to midnight, fill in the mission name and description to your liking (mention Xeno as Author prominently!) and save... Back to the mission folder - delete "Position.sqs" - run "setupcopy.bat" once just to be on the safe side and rePBO the damned thing! You should be done! B

Bush's Geotypical Microterrains - A Beginners Guide 1st Edition Finally, as promised quite some time ago :o , here's the first of my "microterrain" Source File packages, plus a fairly detailed Beginners Guide... (42 page/18,000 word pdf file with clickable main index). This guide is primarily designed to accompany the Bush's Geotypical Microterrains series of source files packages. As such, it's not really a complete, from-scratch, teach-you-everything-you'll-ever-need-to-know-about-terrainmaking tutorial. However, there is a pretty comprehensive "beginners" section which, after some initial install and setup instructions, directs you to Sgt Ace's Tutorial - thereafter, the rest of this guide is more like a mechanics manual - the simple mechanics of getting basic terrain structures working and in-game are discussed in some detail... the files you need, what they are, what they do and where to put them. After an introductory setup section for beginners, the main part of this guide takes the form of a walkthrough of the Afghan Valley - Ghor Province example terrain source files. As we consider each folder and file, there's instructions on repathing and renaming each of the example files into your own "Namespace" or "Tag Folder", including renaming the terrain itself. By the end of the guide, the reader should have a complete and working renamed version of Afghan Valley... your terrain now, and your working structure! You can use that as a basis for your own project - adding your own enhancements to that basic framework, or use the whole folder structure as a project template. Some of those enhancements will be illustrated by subsequent terrains in the series - with "advanced-level" appendices added to the end of the guide. Etah Plateau, for example, will include custom "terrainHit" sounds (footsteps to you and me), and appropriate discussion of the extra files and steps involved will be added to the guide. The Faffindale source files pack will contain its associated WorldTools project file, so there'll be some brief matching discussion of basic forest masks and importing vegetation, etc. What's not discussed much, if at all, is any of the truly creative stuff, like sculpting heightmaps, or painting Satellite or Mask files. Nor will I be covering roads, or placing buildings and objects, etc. When you get to that creative stage there's a wide variety of options - real or artificial heightmaps? satellite or hand-painted satmaps? Regardless of how you choose to actually make these parts of your terrain project, the final result will depend on one common factor - getting them into Visitor in a coherent structure it expects, then getting that terrain through binarization and into the game. This guide will focus on that basic, practical procedure at a very simple "entry" level. I'll release subsequent terrain source files packages plus a matching updated version of the guide as and when my other commitments allow... Download Bush's Geotypical Microterrains - A Beginners Guide. 1st Edition. Armaholic Mirror - Guide & Source Files Link Additional Downloads Bush's GM Heightmap Bonus Pack #1 Full details in this post Credits & Thanks B

A series (probably) of basic synthetic planetary surface terrains, loosely based on worlds depicted in Star Trek - The Original Series (for now), and primarily designed as simple playgrounds for the Star Trek: Road To The Stars Mod, by Abs. First terrain in the series is a loose depiction of Taurus II, as featured in the episode "The Galileo Seven". Located deep in the heart of the interstellar electromagnetic phenomenon known as Murasaki 312, Taurus II is a nominally "M" class world, lit by a bright blue-white star. Ionisation by exotic particles from the nearby Murasaki Effect colour the sky a lurid shade of green and, during the all-too frequent storms, colour the clouds an equally lurid shade of magenta/purple. Cadets: remember your sunglasses! Terrain Details 10.2km x 10.2km - 5 meter ground resolution 0.5m/pixel hi-res satellite layer (takes a few moments to load, patience please) Many unconvincing polystyrene rocks (Series 1 budgetary constraints) Complete absence of vegetation (see above) Low-budget lighting (see above) Rock, sand & sky colours sampled from original episode scenes Disclaimer Since Arma 3 is still in Beta, our knowledge of it is limited, and tools to match are still but a hope on the horizon, there's a few flaws and omissions with this terrain, for now... I haven't implemented the potentially funky new "satellite normals layer" tech on this terrain as yet... Thanks to a bit of Boldly Going by the Mighty Mikero, we do have that nominal capability now, but implementing it often seems to cause conflicts with ground surfaces in a way we don't fully understand, as yet... Also, there seems to be a wierdness - mentioned by others elsewhere - regarding the satellite texture on the Editor and In-Game maps... This seems to "scramble" annoyingly as you zoom further out, while working normally at closer zooms... Dammit Jim, it's some sort of land grid thing I haven't quite puzzled out yet! But since it was the only real flaw in the terrain I've decided to let it pass for now in this Beta 0.5 version at least... The Usual Suspects I've been around so long, and learned so much, from so many kind and helpful people, that my full credits list on any project would be longer than the project description itself. I stand, as do we all, on the shoulders of Giants... However, the indigenous anthropoids directly involved in this particular away mission include... The Mighty Mikero - from The M Continuum. JR Walker aka. Lt Cmdr Leveller. Aaron Torpy from the L3DT Cluster. Q - from The Q Continuum. Download Download from the Armaholic Page (thanks Foxhound! ) Server key & bisign files included (untested, but hopefully working OK) Boldly Go....... B

Carraigdubh, Co. Leitrim A 5x5km Geotypical Microterrain *** St Patrick's Day Special Edition - Beta v0.8 *** Introduction Once again it's time to inflict my obsession with landscape & natural environment modelling on a wider public! This time the excuse is, of course, St Patrick's Day, and the landscape in question is an entirely synthetic representation of a small area of County Leitrim, one of the northern Counties of Ireland - close to the border with Northern Ireland. Unlike my previous "Geotypical Microterrains" which were essentially public exercises in terrain modelling & texturing, this terrain is considerably more "finished". My central focus, as usual, has been on creating a believable natural environment (that part is mostly finished)... but this time there's actually a few typical locations to visit (these are considerably less "finished" and will be expanded and added to for the final version)... Geology & the Local Environment County Leitrim contains a great variety of landscapes.... TerrainmakersTechnical Details Missions! Pretty terrains are all very well, but without missions to actually play they're just so much scenery... I'm therefore particularly grateful to the Mighty Wolle, who selflessly sacrificed his couple of days off this week to convert some classic missions for Carraigdubh... co06 Cleansweep BAF A recreation of the famous OFP mission, set in the main town of Ballybrian. co06 Bardak's Toy Bardak has a new toy, it's up to you to break it for him... co06 Sgt Moore BAF After one guinness too many in Molly McGlone's, Sgt Moore has managed to get himself kidnapped - again! Fortunately we had him tagged after the last episode, so your team can track him down using your high-tech Beepy Thing. SP Steal The Tractor "You're in position Pat, so you are..." Someone has stolen Patrick O'Brien's tractor - he knows who they are and where they're hiding and he's going to get it back so he is! *** all missions included in the main download *** Requirements Arma 2 and Operation Arrowhead or Combined Operations is required! Download Carraigdubh BETA v0.8 @ Armaholic Also available on the Six Updater Network ***UPDATE*** Serverkey & V2 .bisign Files (Thanks to Jedra for the bug report!) *** EDIT *** Please note - Wolle has updated two of his missions which were included in the original terrain download... Please grab the updated versions below for tat Maximum Oirish Experience! Cleansweep v101- Fixed the missing notes and briefing text. Return The Tractor v101 - Removed cwr2_abel in the list of required addons. Additional Missions Coop04 - Rapid Rescue - Rescue Sean from the Brits! - Another fine mission by Wolle! ZK's BattleZone V3 MSO v6b - - A Warfare/Battlezone/MSO Multiplayer Mayhem mission by Kremator! Credits & Thanks Bohemia Interactive - of course! Foxhound & Armaholic - best hosting ever! CWR2 Team & Wolle - patience, models loan & advice and missions!! Mikero - absolutely essential tools!*** Shezan74 - equally essential World Tools Mondkalb - cunning techie tricks Tupolov - random intro script Roger Bodger - terrain playtesting Satnam Sagoo - original suggestion Happy St Patrick's Day! B

I - sortof - am... BI have received quite a lot of.... feedback... about the new "visual upgrade" so I think, like many other current terrain guys, that I'll wait and see if further engine tweaking takes place before getting involved in fundamental recolouring and reconfiguring of actual terrains to suit what may not yet be BI's "final take" on the lighting conditions... So, in short - no fix for these at this current time at least, sorry... B

If you're using Keypoints on your map to designate place names then you'll know that TB saves these out as a file in your Main Project Directory, eg "nameofproject.hpp" If you load this file into Notepad you can then edit the place names to use your odd characters, then - as you go to resave the file - look for a popdown menu on the save dialog called "Encoding". It'll probably be set to ANSI by default. Change that to UTF-8 and then save the file as normal That - should - allow "special characters" like accents above letters, etc to show in-game Whether it'll work for actual foreign characters, I'm not entirely sure, but it's worth a try... NB - REMEMBER!! - TB (Re)creates that NameOfProject.hpp file every time you save, or export .wrp or something like that, so remember that it may get overwritten automatically by TB at a later stage B

With terrains it's notoriously dodgy... One of its main dodginesses being - it doesn't report problems when it encounters them, which may be why you haven't been encountering any problems with it... ;) B

Whatever you do, DON'T blur your mask - that'll just create more colours at the borders between colours... Counting colours, on the other hand, is a Good Idea - when there's too many colours within a given area, the standard symptom is usually one ground texture overlaid/blended with another. You can also use Photoshops "indexed colour" mode to enforce a palette of only 6 colours... B

Hi guys... Yes - BI did indeed "semi-fix" the Outside Terrain tech, though since CUP reputedly switches that off anyway then it shouldn't matter, since you'll need AiA, or MUCH better still, CUP in order to run these old Arma 2 terrains... I've tried the standard A2 Carraigdubh in A3 with CUP and it seems to work fine for me with no errors Not sure what combination of "BI Semi-Fixed Outside terrain" and "CUP switching it off" is going on there - the Outside terrain starts just where that road ends and as you can see, seems to be a series of widely spaced low ridges with pretty flat areas in between, rather than the nice gently rolling hills we got in Arma 2... However - it's working - glitch free for me... Of MUCH more importance is the fact that there's a small pond up at the top left quadrant of the map - this WILL cause issues and would need to be disabled/removed or there's going to be visual glitches - or worse - over in that quadrant... (Actually, I thought CUP "removed" pond objects too???) Anyhow - until such times as I can - finally - get around to providing a proper Arma 3 version of this terrain, everyone has my Full Permission to mess with Outside terrain, Ponds or any other tweaks you find necessary to get this terrain working for your personal/team/group/clan use in Arma 3 - glad to see people still keen to have fun on what's really a pretty sparse little map... (it's the hedges, isn't it...? ;) Have fun! B

It's unusual that cluttercutter isn't suppressing this maverick clutter.. :( - that would've been a quick, if unsatisfying fix... Still - I have one - slightly longshot - suggestion you could try, but first - a question... In your mapframe properties panel "Sampler" tab - where you set the resolution for your Mask, Sat, etc - are you importing one size of mask file, but then using a different final mask size in the actual sampler properties... ie: something like - your imported satellite image is actually 20480x20480, but for one reason or another you have your Sampler settings for Mask & sat to be 10240x10240... that sort of thing... In a situation like that, as TB creates the Layers tiles - it's basically "resizing/resampling" as it goes, and just like in Photoshop, occasionally a sort of colour clash effect can occur on the borders between certain colours... It's very important to remember right here that TB doesn't really care what actual colours you use on your mask - as it creates each tile it looks the colour you used up in Layers.cfg - fetches the appropriate surface info for that colour - then it colours that pixel on the mask tile it's creating - BUT - IT DOESN'T USE YOUR COLOUR... If you look at the final Mask tiles TB creates in "Layers" folder, you'll see it uses RGBY and two other "shadings" for colours 5 and 6... It reassigns it's own colours using this palette combined with your mask info Moreover - it starts afresh as it moves on to each new tile, so Red might be used by TB in one tile for "Green Grass" and in the adjacent tile, Green Grass is "Blue" and "rock" is Red or something. Combine this with the potential for "colour dithering" at unspecified colour borders - which will vary from tile to tile, and somewhere in there - could - be an answer for you... I would..... Firstly - check to make sure you're not doing that "letting TB resize/resample" thing with your mask... It's always best to import the initial datafiles (heightmap, mask, sat, normals if used) in the actual res you intend to use them in - that avoids TB potentially doing a messy resample... Secondly - Take a look at your "Layers.cfg" file - Down at the bottom is where you list all your surfaces (which you defined above) one after the other and associate them with YOUR mask colours.. TB uses this as a lookup table - literally - reading the Colors list from top down as it searches to identify each pixel it encounters on your mask... Try changing the order in which the surfaces are listed... If you can identify the surface/s where the maverick clutter appears - move them to different positions relative to each other in that list, so they'll be "encountered" sooner or later... It might just shift the problem elsewhere, if all of this IS what's actually happening... I've seen this sort of problem in VBS with the early VBS terrain tools, and since TB is basically a "long-ago branched from the VBS original" version of those tools, it's possible the same thing can occasionally happen in Arma... It's a pretty straightforward fix to try - check sampler tab settings - adjust the Colors table item order - recreate layers folder, re-export wrp - pack and take a look.... B

It's a very big terrain, with a large "heightmap cell size"... The Heightmap tools can only be as precise as the heightmap resolution you've chosen, so what you're seeing is 20 meter spacing... Looking at your settings pic , the Satellite/mask imagery setting is horrifically low - that's going to look pretty terrible in-game, and the mask tiles & texture layer sizees are pretty low too.... Your main issue - the heightmap ground resolution, CAN be changed a little, to give you finer detail there... In your mapframe properties "Sampler Tab" - top left, try... Grid size 4096x4096 Cell size 10m You'll notice that gives you a terrain of the exact same physical size in meters - 40960x40960 meters - but instead of 20 meter "cells" you have 10 meter - MUCH better. Sadly, with a terrain of this size, that's about as low as you can go... TB DOES offer a 8192x8192 grid size, but it's.... problematic and best avoided... Moving down on that same properties page, your satellite/mask imagery is currently 2048x2048 pixels - that means that each pixel of that satellite image is being stretched to cover a 20x20m ground area... that's going to look horrible.... You need that to be 20480x20480 @ 2 meters per pixel as an absolute minimum, and even then it'll look quite "blocky"... Ideally you want 1 meter per pixel for Sat & Mask imagery, but since your map is 40960x40960 meters, that would mean a 40960x40960 pixel image - which is kinda beyond both Photoshop and the required formats (png, bmp, etc) capability. To do 1m/pixel properly you'd need to use 4 x 20480x20480 images, and arrange them in a 2x2 grid in TB... ,Definitely possible, but tricky to do... and finally, below those settings, the "Satellite/Surface Mask tiles setting - you have 256x256 currently - you'll need 512x512 in there once you start increasing the res in the other areas, and the bottom setting, "Texture Layer size" should be about 40m x 40m... A map this size is a Monumental Undertaking, even if you're aiming for a largely "flyboys" level of detail, and its a very big and unwieldy size for a "first terrain"... are you absolutely sure you want to wade into something this big right away? It's often a good idea to do a little map first, go through all the stages, make all the mistakes, ask all the questions, start to grasp the concepts and get a little, but fully working, completed result under your belt... That's going to give you some valuable experience and, more importantly, confidence. Since it's a little terrain, all those stages don't take so long, and it gets all the beginners level problems like yours out of the way, so that when you tackle that Big Project, your only issue is that its a Big Project, you're not struggling with beginners issues AND a gigantomap at the same time.... Whatever you decide, the settings I posted above should get your Big Project slightly more reasonably configured, and the ground editing will show 4 cells in a 2x2 grid where you only had one before - that'll allow some higher-res ground editing at least.... Good Luck B

This is exactly how it works in VBS - A selection of surface definitions are in there and "always present" since they're part of the core definitions, so your own surfaces just declare themselves to be a "child" of the "stock" ground surface which is nearest to the one you're using. Then, any aspects of your surface which differ from the stock one can be specified below... If you specify a unique parameter for your surface, you get that value - anything you don't specify, you get the value used by the stock surface. Makes it relatively quick and easy to define your own surfaces without having to declare every single parameter for every single surface... Like - if you have a custom concrete, but it will behave like stock concrete, same footstep sounds, impact sounds, dust factor etc, only the appearance is different, you can inherit from the stock concrete - specify your texture files as the only parameter and you're done - you'll get your concrete visual appearance, and stock concrete behaviour.... B

Jimbop's right on the money... Your cfgSurfaces looks fine - everything is where it should be, the concrete texture clearly has no surface character clutter assigned. You shouldn't be getting clutter on "Concrete2".. Even more suspicious is the fact that other areas of concrete are all ok - it's only this one area which is affected. By far the most obvious cause of that is stray pixels of another colour in among the concrete in this specific area. It should definitely be your first task to totally micro-check that mask area at high zoom - even a few pixels of an inappropriate colour are enough... Another way of visual checking would be to switch off objects view and check out the area in buldozer.... you don't see clutter in BD anyway of course, but you should be able to see the occasional small patch of "Pebble" or whatever the clutter is assigned to in among the areas of Concrete2 if they exist... Thats the first thing I'd check... Can't think of another reason offhand which could cause this effect,,, B

If you choose to use a "Normals Layer" along with your Satellite and Mask layers, then that "uses up a texture slot in the pixelshader", and you can only have 5 colours at once. If you don't bother with a Normals layer - and a lot of people don't - then you can have up to 6 colours. A "Normals Layer" is relatively new tech - they didn't exist in Arma 2 maps, and the tech is borrowed from the Take On Helicopters series... It's perhaps best thought of as a way of adding some additional overall detail to your satellite imagery layer at longer ranges and is probably best suited to larger, aircraft-orientated maps (Like Take On Helicopters ones, in fact ;) ), for smaller mixed-use maps, most terrain guys prefer to have that extra sixth ground surface capability instead, and skip the normals layer. So, in practise, you decide whether you're going to use a Normals layer or not, and, in the Mapframe Properties Processing tab, when you go to generate your layers, either check the "5 colours plus normals" box, or the "six colours" box as appropriate... B

Hi again... Well done! That all looks much neater! Lets look at all three of your files in turn and see what we can spot... Firstly - cfgClutter... This is great - you've got one clutter item correctly defined and it's classname is "bih_GrassGreenGroup" - you'll need to remember that name later when you want to call on this model as part of a "surface Character" or "ClutterMix" On to cfgSurfaces... The top "surfaces section" is fine. Adding that "_Surface" suffix to the end of the classname is a great idea - it labels the class clearly as a surface definition and it allows you to use the same name - without the "_Surface" part - in your layers.cfg classes. That makes it easy to check you're being consistent in both files. In one of your classes you've correctly referenced a "surface character", or "clutterMix" - character = "bih_grass_green_Character"; - and down below in the Surface Characters section is where that cluttermix should be defined... It's there, where it should be, and it's mostly OK, but lets take a closer look at it... class CfgSurfaceCharacters { class bih_grass_green_Character { probability[] = {0.92,0.07}; names[]={"bih_gass_green"}; }; }; The classname is fine - it corresponds to the definition you made above, so this is the surface character definition which wil be used for that surface... but... in the "probability=" line there's TWO numbers - there should be one number here for each clutter item named below, and since you only have one item named below, there should only be one number... maximum of 0.99... Worse still is the item mentioned in the "names=~" section... each name in here should be the classname of one of your cfgClutter definitions... you can have as many different clutter items piled on to a surface as you want, separated by commas, with each having a "percentage" specified by the probability number above, but the "name" MUST be one of the previously defined cfgClutter classnames... You've got your only clutter item defined as "bih_GrassGreenGroup", so that's the name which has to go here. Finally - Layers.cfg This also looks fine - 5 texture types specified - the paths to the materials in lowercase - great... Sometimes lowercase in a path doesn't matter, sometimes it definitely does, like here in Layers.cfg, so I usually try to make a habit of always using lowercase in all paths everywhere - even if the folders themselves actually have names with caps, the paths will still work, and that way you never get caught out... picture="cluster\zd1\sourcemapLegend.png"; There's a "\" missing from this path.... ;) Otherwise, Layers.cfg looks fine... Tweak those few problems and give things another go - regenerate layers, re-export .wrp and repack - get it in game and see if you have grass... B

Firstly - you have seven ground surfaces defined in cfgSurfaces - and seven matching surface types in layers.cfg - thats good, and correct... But - at the bottom of layers.cfg you only have 5 surface colours specified.... you're missing two - there needs to be 7 in all three of these areas Secondly and more importantly on the clutter front... Remove all CAPITALS from ALL of these "material=" paths in layers.cfg - lowercase\all\the\way B

Heightmap cell size is nothing to do with satellite or mask layer resolution... If you make a 1024x1024 terrain with 10 meter cells you get a 10240 meter x 10240 meter terrain (10x10km) If you make a 1024x1024 terrain with 1 meter cells you get a 1024 meter x 1024 meter terrain (1x1km) Thats how you control the actual map/terrain size - by picking the best combination of "grid size" - 512x512, 1024x1024, 2048x2048, 4096x4096, etc - and cell size - 4m per cell, 5 meters per cell, 10 meters per cell, etc.. You juggle these two parameters until you have a terrain of roughly the overall size you want, at the overall GROUND resolution you want.. But changing these numbers does nothing to the resolution of the satellite imagery, which is a different set of parameters entirely... "Draped" over the top of that heightmap grid go the satellite and mask layers - these two imagery layers should match each other in resolution for best results, but aren't tied to those above HEIGHTMAP sizes... For example, if I made a 2048x2048 grid heightmap with each cell representing 4 meters, then my final terrain size will be 8192 meters wide. If I use an 8192 x 8192 PIXEL satellite and mask image, then each pixel will appear to cover 1m x 1m on the ground... "1 meter per pixel"" - (that's considered "normal/good" resolution for a sat/mask pair) If I used a 2048x2048 PIXEL image, then each pixel of that image would be stretched to cover 4m x 4m of ground - "4 meters per pixel"... it would look much blockier and crude If I used a 16384 x 16384 PIXEL image, then each pixel of that image would only be stretched to cover 0.5m x 0.5m of ground - "0.5 meters per pixel" - That would be considered pretty Super-Hi res for a sat and mask pair... In general, 1 meter per pixel is considered to be more than adequate and it's what most people use.... So basically... Juggle heightmap grid size and heightmap cell size until you get the actual physical size of terrain you want. Do the maths.... Grid size x Cell size = physical size of terrain in METERS... (eg: 10240 meters) Then make Mask & Sat imagery of that same number, but in PIXELS... (eg: 10240 PIXELS) That will get you 1 meter per pixel imagery, which is what you want to aim for... B

For best results with L3DT you really need to spend a little time developing your own materials... Above = stock L3DT texture & bumpmap, below = custom material The stock materials are fairly.... bland, but with a bit of effort making custom ones you can squeeze pretty good results out of L3DT. Main thing to remember when making these textures is that you're not making "ground textures" - its not "the ground as seen from head height looking down", you want to try and imitate "the ground as seen from around 100 meters height" (which works out about 1pixel/meter) B

You should check out L3DT http://www.bundysoft.com/docs/doku.php?id=l3dt:about There's a free version which is fully functional forever, but limited to 2048x2048 max heightmap and 4096x4096 imagery. The full version is about $34 and can handle heightmaps bigger than you'll ever need, but more importantly can generate imagery up to at least 20480x20480 and well beyond if your computer has the memory, etc L3DT can generate heightmaps from scratch, and it has a full 3D view heightmap editing feature with all sorts of sculpting brushes, but one of its most powerful features is that it can analyse a heightmap that you load in, decide what sort of surfaces would go where... sand/beach, nice grass, slope areas, steep cliffs, etc - it will then generate images based on that which can be exported and used directly in TB as basic matching mask and satellite imagery...It's very popular with terrain guys who are making fictional places since then you can't just go and download the imagery like you would with a real place, you'd need to paint the mask and sat images manually - L3DT does it for you The best news is that you can get a download link and a free 90 day key of the full unrestricted edition as a demo - just fill out the form on the website and you should get a key and a download link in the mail, and then you have a free 3 months to figure it out ;) These terrains https://forums.bistudio.com/topic/152836-bushs-strange-new-worlds/ have entirely L3DT generated satellite textures, as do a whole bunch of other terrains which have been released - usually, if its a fictional place, it's an L3DT satellite layer being used... All you'd need to do is to "Export mapframe heightfield" which will get you an .asc file to load into L3DT - you can then analyse that and generate appropriate resolution mask and satellite imagery, export those images and load them into TB and they'll match your heightmap perfectly... B

Ritchie's right - the mask surfaces either have clutter assigned or they don't, and the usual best way to stop clutter poking up through models is to have the ground at that point assigned to a non-clutter surface - like the "general urban gravel" sortof surfaces you'll often see used as an "underlay" underneath roads, buildings, etc. However, this technique can only be as high-precision as the mask resolution itself, so sometimes it's difficult to achieve a small, neat result. In these instances, what you need is a "Clutter Cutter". These are basically invisible, untextured flat-plane objects which suppress clutter on otherwise normally cluttered surfaces... There's a couple included in the OA models, eg: "CA\misc_e\clutterCutter_small_EP1.p3d" Since those models are available as MLODS you can cop one, open it up in O2 (or whatever they're calling it nowadays) and take a look/edit/resize it to suit your needs... They work nicely and can be extremely handy for spot-area clutter suppression... The "invisible roads" models do the same thing, though they also carry info which declares them to the AI as "roads" which can occasionally cause unpredictable behaviour depending on the context they're used in (invisible road tiles are ideal for a runway underlay, for example). A Clutter Cutter is the basically same thing, without the Roadway LOD. B

Your screenshot is actually a classic illustration of how the various ground texture layers work in the Arma engine... Directly under the players feet are the ground textures themselves - tiled on a 1 > 2m grid, with or without associated clutter, and with the _nohq, or _nopx bumpmapping... As you look gradually further from the player, the same main ground texture tiles are shown in an increasingly lower level of detail, out to the maximum range you specify (or inherit) in your main terrain config. Beyond that point, you see the basic satellite image itself. As an additional helper, to smooth the trainsition from the ground textures area to the plain satellite image area, there's a sort of "transitional zone" where the furthest ground textures area (basically just a no-detail ground texture matching tint by that stage) and the nearest plain satellite imagery are "overlaid" with a special extra "detail texture" called the "middle_mco"... this is a special texture file which adds detail only (no actual colour or tint) and it's tiled according to the "Texture Layer Size" you set in your TB Sampler Tab settings... ie: its a small tile, like the ground textures, but stretched to cover about a 30-40m area... Beyond that, as I mentioned before, is your actual Satellite Image itself... If there's a distinct difference in the overall tone/tint/colour between the close up ground texture tile and the satellite image, you get the effect in your screenshot... You have two choices... Retint the satellite image in photoshop or something until it matches the overall colour/tint of the groundtexture, or... Retint the ground texture in photoshop or something until it matches the overall colour tint of the satellite image.. (You only need to mess with the "visible" ground texture file, the "_co", in photoshop. Technically, you're also on the right track with the .rvmat, there ARE RGB parameters in there you could mess around with which will also affect the overall tint of a groundtexture... personally I always find just messing with the _co texture file easier, but rvmat retinting IS a viable option if you prefer to try that) * In all cases, of course, back up your original file before messing with recolouring, so you can "return to zero" if it all goes horribly wrong... ;) So - pick which one is closest to the actual look you're trying to achieve, and recolour the other to match... If you're careful, then after a little trial-and-error and experimenting you should be able to achieve a pretty seamless result... B

Basically you have two choices - edit the plants pack, or provide the CA (Arma 2) content it's looking for, in the place it expects... Both options are a little tricky but perfectly possible if you're careful (always make backups). Checking thru the forum threads here for people doing or discussing similar things is a Very Good Idea too - this level of tinkering around isn't exactly beginners stuff... For either approach you'd first need a proper P:\CA folder with the Arma 2 content... Once you have that, if you wanted to edit the plants pack you'd... Ask whoever the author of the plants pack is if it's OK to do so, then... Create a new folder somewhere on P:\ for the new plants pack... If it's going to be associated with your terrain, then right beside your terrain and similarly named might be a good idea like, your terrain is P:\MyTag\My_New_Terrain then you could use P:\MyTag\My_New_Terrain_Objects\winterplants\ ... for the location. Then you copy all the winter plant models .p3d's to that folder - just the model .p3d's themselves. Then you need to get, install and read the read me for Mikero's "MoveFolder" tool. You can point that to that new models folder and run it and it will read all the paths in every one of the models, follow those paths (even if they lead to the P:\CA folder - which is why you need one), and fetch every texture and rvmat those plants will use, then it will create a \Data subdirectory in your new models folder, copy all the files there, then repath every path in both the models and the rvmats to point to that new "local Data" folder End result is a self contained plants pack which contains all the models, plus all their textures, all repathed to suit that new location.. The second option is to use AllInArma, or it's successor, the Community Upgrade Project mods AiA has stopped development, though it's 90%+ working where it matters, and CUP is picking up where AiA left off and is still WIP Basically, both of these mods effectively add ALL Arma 2 content to the main Arma 3 game... If that mod is running, Arma 3 HAS a "CA" folder... So you would just carry on using your current plants pack as it is... For TB and buldozer viewing, those pesky missing CA textures would be made available - because you added a proper CA folder to your P:\ drive And, in game, there'd be no errors either, because when the plants went looking for their Arma 2 textures in Arma 3, AllInArma, or CUP would be there, ready to provide them. This approach would make AiA (or CUP) a "required addon" for your terrain, people would have to have that mod and be running it in order to use your terrain.. That's not quite as horrific as it sounds - AiA was/is pretty popular, and a lot of people will have it already, and secondly, since it basically provides ALL Arma 2 content within Arma 3, you're free to use any and all of the CA (Arma2) content which you have on P:\ on your terrain.... For that reason, an AiA dependency is is something quite a few recent terrain guys have chosen to use... B

Sounds like you've picked a tricky addon to work with... To start with, "CA" is the "P:\drive prefix" for the Arma 2 game content. Just like you have a P:\A3\ folder, with basically the whole of Arma 3 unpacked and arranged properly in the correct folder structure, back in the Arma 2 days, modders had the same thing, except it was called P:\CA Your models sound like a typical "minimal" retexture from Arma 2. At a guess, I'd say what's been done is that the required models have been placed in a P:\plants_winter folder - almost certainly with a \Data\ subfolder for textures. Then, the required "visible to the player" original plant textures have been copied over to this new Data folder, and then retextured to look "wintery". Then, the models in P:\plants_winter had the paths to those visible textures redirected to this local \Data\subfolder, so they'd use the wintery textures instead of the stock Arma 2 ones and the player would see - winter plants. However, plants and veg have complicated textures which involve bumpmap and "mc" materials (textures), and also .rvmat files to control how all these textures are applied... There are paths to ALL of these files inside the model.p3d itself. Since it's not necessary to change any of that other stuff in order to make a plant look "wintery" there's really no need to change those other paths, this is an Arma 2 addon, being used in Arma 2, so those CA\Plants2\wherever\ textures will ALWAYS be there, since they're part of Arma 2 itself. Except now they're in Arma 3 and there is no CA - no Arma 2 content... so those textures can't be found... Without looking at the structure of the addon itself and checking all the paths to stuff I can't say for sure that's your particular issue, but in general, anything looking for CA\Anything is from Arma 2, and still wants to be in Arma 2... B

The first thing you have to realise with all Arma models is that they contain Hardcoded Absolute paths to their textures... Here's a quick fictitious example... The model "small_rocks.p3d" is found in the location P:\A3\Rocks\ The "P:\" part is removed, so inside that small_rocks.p3d model are paths to the textures which read "A3\Rocks\Data\<the texture.paa>" Regardless of where you put that model on your P:\ drive - it will still look along that path for its textures, So when you add that model to the TB library, place it on your terrain and check it out in buldozer - there's the rock, and, if the textures are present at the correct location, its a textured rock... Now... lets say you want to use Icebreakers plants package, which he created for his own terrains. Icebreakr's usually OK with that sort of thing (though it's usually considered polite to ask first) so, the first thing you need to do is to put the contents of that "ibr_plants.pbo" on to your P:\drive - somewhere - so you can add them to TB and use them.... So you unpack the .pbo and you get a folder called "ibr_plants"... So far, so good... Now, where do you put it? Lets say you just dump it in the P:\A3 folder, then you open TB and add the models to the library from that location... You add some trees to your terrain and check them out in buldozer... The models are there OK, but the textures aren't!... Why's that? Inside every one of the models there are paths to textures... the model is trying to follow those paths and it's not finding the textures where it hardcoded expects them to be... So - how do you know where to put the ibr_plants folder so it works properly?? Well... at some point in the past, Icebreakr made this models pack, and he did that - somewhere - on P:\... As you unpack his final result from that job, the ibr_plants.pbo, Mikeros ExtractPbo tool - should - create a file, probably called "PBOPREFIX.txt" ... This is a simple text file which contains.... The Original Path to the location where Ice made the plants pack... This is the path thats hardcoded in the models, this is where the models are looking for their textures... Since you can't edit those models and change the internal paths, you need to make sure you put the models and textures in their correct, original place, and use the models from THAT location when you add them into TB for use... That way, the model looks along its hardcoded path for the texture, finds it, and all is well... Better still, in game, when you load your terrain, it'll look along the same paths (basically, it'll look for that ibr_plants.pbo, find it, and use both the models and their textures successfully)... So - you look at the pboprefix.txt file, it says "ibr_plants\" and nothing else.... Imagine the P:\ back on to the beginning of that path and you have "P:\ibr_plants\" - THATS where the folder needs to go - directly on P:\ If you unpacked one of my pbo's like "afghan_city_objects.pbo", and the pboprefix.txt file read "bush\terrains\afghan\afghan_city_objects\" then you'd need to recreate that path on your P:\ drive... Make a P:\bush\folder, with "terrain" and"afghan" subfolders, then finally drop in the unpacked "afghan_city_objects" folder at that location, and add them into TB and use them from there.... Your terrain is an addon, all its paths to models (and their textures) are hardcoded too, so now you have paths hardcoded into your .wrp which read "look for ibr_plants for the models and ibr_plants\data for their textures" (the P:\whatever\if\anything\ part of the path is ignored, the game looks directly for "ibr_plants", or rather, its packed equivalent "ibr_plants.pbo")... Next... Since your terrain now relies on this "external pbo" you need to tell your main terrain config that, so it will error and prompt the user if that now essential extra .pbo is missing... Something like... requiredAddons[] = {ibr_plants}; would probably do... And, of course, you'll either need to include the ibr_plants.pbo with your final package, or inform your users that its a "required file" which they can get by downloading any Icebreakr terrain where it's used.. Or, if they simply have an Icebreakr terrain which uses that .pbo loaded at the same time as yours, that would also ensure that required file was available... B

Remember that the _co / _nopx (or _nohq) ground texture tech has been around since Arma 1... If you take a look through the back catalogue of Arma 1, Arma 2, OA and assorted DLC data which BI has released, you'll find a whole load more good textures from all the terrains which were included with those games/expansions/etc, all of which are basically ready-to-use in Arma 3. B