bushlurker

Yeah - that option seems to be non-functional currently - Works fine with Polygons, but not polylines... I reported it on the bugtracker - HERE a while back, but it doesn't seem to have been picked up on yet... Feel free to vote it up! B

I've tested this problem and reproduced the same crazy "jittering" effect with a bunch of different objects... There's definitely a problem since the update... If you can't place an object with any real degree of ease or accuracy then it's a pretty Big Deal for what is essentially an Object Placing Tool... ;) Bugtracker Ticket created for this issue HERE... Feel free to vote it up for a (hopefully) quick resolution to this pretty fundamental problem... B

You have to draw the roads on the Sat layer as well, so that as the actual road model fades out, the grey "painted roads" on your Sat layer take over and you don't see the transition... Same deal with runways, etc... like this sort of thing... EMF export of an image with just the roads visible for use as an accurate "roads template" for painting was the "old" V3 approach... With TB we have "Export shapes to Imagery" so all you need to do is export an image of all your roads polylines and you can use that as a template for painting them on the Sat (so they're visible at distance) and also on the mask (so you have a non-clutter "gravel" underlay).. Any large concrete area like runway aprons, taxiways, car parks,etc, etc can really benefit from being painted on the sat layer (and usually on the mask as well)... A good general rule is - "if you have a landscape feature and its big enough to be seen from a distance it should probably be depicted on the Sat Layer"... B

Aha! I recognise that guide - written by my good friend Allan Campbell from the Aussie VBS office! :) It's 100% accurate - for the current VBS2 Visitor 4 - that means there's one or two bits which don't correspond exactly to the facilities and features we have in TB. However - the bit you're interested in - the instructions for colouring via surface types and exporting shapefiles to imagery (section 7.5.2 Creating a Surface Mask) should work just fine in our Terrain Builder and is ideal for creating a basic "starter mask" based on any handy shapefiles you might have (eg: roads, forest polygon areas, etc etc)... B

There's no need to get involved in all that "sharing" palaver... Probably won't work anyway, since the P:\ drive doesn't really exist anyway... it's just a "ghost" of your actual "Arma 3 Tools" folder which has been given a drive letter and allowed to pretend it's a "real drive"... Lets try the "minimalist" approach... Copy this... subst p: /d subst p: "E:\SteamLibrary\SteamApps\common\Arma 3 Tools" ... into Notepad. Change this bit ONLY... E:\SteamLibrary\SteamApps\common\Arma 3 Tools ... make it YOUR drive letter and YOUR path to where YOUR Arma 3 Tools folder is... Save the file as "AnythingYouLike.bat" (use the "*.* All files" option in Notepad, so you don't end up with "AnythingYouLike.bat.txt" ! ) ... doubleclick it - see what happens... All this .bat file does is... * - Remove/dismount any P:\ drive that currently happens to exist. * - Remount a new P:\ drive with the contents of the folder the path points to That - should - be all you need... B

Hmmmm.... Those look like solid, dependable values - should work OK... Try turning the texture layer size up another notch - 80x80m will be the next available size, thern recrunch layers > re export wrp > repack and check ingame again.... No need for this at all any more - once you import the sat & mask & heightmap they become part of the project fileset and the originals don't need to be in the project folder at all.... B

Did you remember to do this bit? B

This may be the problem... the "subst" command used to create the Virtual P:\ drive is basically a "per user" command... I'm guessing that your P:\ drive was created in "normal" mode whilst you have TB in "admin" mode - or vice versa... I'd suggest that you take a look here... Copy that entire Text block into notepad - save it (in "all files" mode) as something like "new_mapdisk.bat" - drop it into your Arma 3 Tools main directory and use that batch file to assign your P:\ drive instead of the supplied BI "mapdisk.bat"... That should force the P:\ drive to be created in both "admin" and "non admin" modes, so it should show up either way... PS - you shouldn't need to run anything in "admin" mode at all.... B

set this to the default value of "16" (you MUST have an overlap) I assume you mean "10m x 10m" - set it to "40m x 40m" Remember that, since you've changed the tiling parameters for your Sat & mask layers by doing this, you'll need to RE Generate Layers" on the Mapframe Properties processing tab... PS... with a 2048x2048 heightmap / 10m cellsize, and only a 2048x2048 Sat & mask, each sat pixel is stretched to cover 10m x 10m in game - that will look.... pretty bad... I'd suggest a 20480x20480 pixel sat & mask - thats 1 meter/pixel which is considered more or less "standard"... B

Hard to tell from the image, but I - think - what you're actually talking about is the circular area around the player where you see the closeup ground textures under your feet... They're visible - directly under your feet, obviously, but also out to a specific distance around the player (as specified in your main config), after which they fade to your Overall Satellite Image... For this reason, its quite important (and often quite tricky) to make sure that the general colour and tone of the groundtexture you use in - eg: a "sandy" area is basically the same general colour and tone of the equivalent "sandy" areas on your Satellite Layer. Otherwise the differently-tinted Ground Textures visible area will appear as a "halo" on the ground around the player... B

Basically - Yes. Export .wrp (important!) and then binarize to .pbo as usual to test in-game... You should find that after several "tests" the packing process becomes much faster since the packer program will recognise what parts have changed and only re-binarise the new stuff - while reading unchanged stuff from the packing "temp" folder... Some packers are smarter than others - I'd recommend Mikero's PboProject for terrain packing.... B

If you use the 5 or 6 colours option then you're using 32 bit mask tiles instead of the usual 24 bit - that adds a fair bit to the Layers folder size. If you're using the 5 colours + Normals option then you have all the Normals files in Layers too - adding a whole lot more. Its the downside of bigger and/or more detailed terrains - they can get Big. Just to be sure, you could unpack your PBO sometime and take a peek - make sure no .png's have been copied over alongside the .paa's - it can happen occasionally with a faulty pack. Some packers are better than others... ;) 1-2GB isn't a huge amount for a good sized and detailed terrain - especially with all these fancy extras. If you're using custom objects then a separate .pbo for them of course. You might also want to try experimentally rar'ing your runtime .pbos - that'll give you an idea of actual download size for your end user... My current Terrain Builder Tester is 4096x12.5 (51km) - 6 colours so its using alphas on the mask tiles, but no normals layer. I've got the Layers folder & textures, etc and the actual terrain wrp+extras in two separate pbo's - currently 870Mb and 246Mb... 1.06GB in total... not unreasonable really... 2GB is the Limit for a single .pbo file and it's unlikely anyone will hit that barrier... Packed to a rar, a user can expect a fairly hefty 936MB download for my terrain when it's done... a few extra objects and it might make the 1GB download size :) Big MEANS Big - it's just the way it is... If its an attractive terrain, people won't worry too greatly about the download... What they might get annoyed about is - frequent huge updates! - so plan carefully and test thoroughly guys! B

Probably best NOT to have "*.wrp" on that list, since if you're making terrains then you need the .wrp to be binarized - not "copied directly"... Conversely, if your terrain has a cutscene, then it'll contain a "mission.sqm" (*.sqm), which you WILL want "copied directly", and also possibly a "description.ext" (*.ext) which should also be on the list... Then, with Terrain Builder and the new Roads Tech, there's "shapefiles" involved - these also really don't want binarized, and therefore should also be "copied directly". A "shapefile" consists of a set of four files - "*.shp", "*.shx", "*.prj" and "*.dbf" Finally, if, during your Terrain Builder "generate layers" procedure, you chose to save the corresponding "*.rvmat" as "text files", then they'll need binarized at the packing stage, so they should NOT be on this list (so they WILL be binarized). If, however, you chose to generate "binarized rvmats", then, of course, they're already binarized, so you DON'T want to binarize them again, so you DO want "*.rvmat" to be on this list... I think that covers the lot.... ;) B

In the "Samplers" Tab in Terrain Builder > Mapframe Properties panel there's a "Texture layer Size (m) parameter on the bottom at the left hand side... It's a popdown list and you'll notice it offers a range of sizes based on multiples of your heightmap cell size... Pick the size closest to 40x40m that you're offered. At this stage you've changed the way the satellite image and mask are to be sliced up, so you'll need to now go to the "Processing" tab and re-generate the layers according to your new setting - then Re-export the .wrp, repack the map and - it should - be fixed... B

Ignore these - not a problem... Good! - it found your project OK - packer paths are probably correct... Essential stuff probably missing from P:\ drive This ones a puzzle since it refers to your objects as "non-binarized" which isn't actually possible... My guess is that your P:\ drive hasn't been properly populated - though there may be other problems as well (those non-binarized objects are a puzzle)... Sky, stars, weather - all of that stuff is "read" from configs on P:\ during the packing process... if those configs are corrupt, wrong, or just plain unavailable then you'll get errors like above... I'd suggest you run Arma3P - let it repopulate your P:\ drive (don't worry, its smart enough not to delete any of your own personal stuff) - that should copy all the necessary configs n stuff to your P:\ drive and locate it properly so the packer can find it during the binarizing process... Assuming no other problems elsewhere, that - should - fix it... B

That's a "DevP.bat" error... Notice I didn't mention using that ;) "mapdisk.bat" should create your P:\ drive for you... And then Mikero's Arma3P will fill and configure it properly... No need for DevP.bat at all... B

Both of these mean Arma3P DIDN'T complete.... if it doesn't run all the way reporting "no errors" and end with "success" then it failed... All of this unpacking bins, copying dta's from other people and steam ID's is completely unnecessary - Arma3P should - and does - do ALL of that for you... Here's a basic installation checklist... **TURN OF WINDOWS UAC - COMPLETELY * * Download ALL the Latest Versions of the required Mikero tools... Arma3P ExtractPbo DeRap DePbo * Use the auto installers to install them all to the default location (C:\Program Files(x86)\Mikero\DePboTools) * Install the Arma 3 Tools to whatever Steam Library you like (Mine is E:\SteamLibrary\SteamApps\common\Arma 3 Tools), for example... * Now go to armamapmaking.info and COPY all the text for NeoArmageddons "mapdisk.bat" replacement... * Open Notepad and paste it in there - save as (all files) Mapdisk.bat" (Not "mapdisk.bat.txt) * Open - Not Run - Mapdisk.bat and edit this line near the top of the file.... set ArmAWorkPath=C:\ArmA3Work * Change it to be Your Path to Your tools - eg : set ArmAWorkPath= "E:\SteamLibrary\SteamApps\common\Arma 3 Tools" NB** Look VERY carefully at that line... Notice how theres Spaces in that path? "Arma-space-3-space-Tools" ?? DOS DOESN'T LIKE SPACES!! But they're OK if they're in "quotes" like you see I've done..... * Once Mapdisk.bat is repathed and ready - navigate to your Arma 3 Tools directory - you'll find there's a mapdisk.bat already - RENAME that one to "mapdisk.bak" and drop your new, improved one in there instead.... * Now - run that new Mapdisk.bat by doubleclicking it and your P:\ drive will appear - it will have the entire contents of your freshly installed Tools folder in there already.... Now - because in certain versions of Windows, merely turning UAC off doesn't actually mean it actually IS off, it's sometimes necessary to run stuff which is in what Windows thinks of as "protected" areas (like Program Files(x86), for example) as "Administrator" - so thats what we'll do next... * Navigate to your C:\Program Files(x86)\Mikero\DePboTools\bin\ folder - find Arma3P... * Right Click on it and choose - "Run as Administrator" ... go make a coffee and wait... Arma3P should run all the way - with No errors, and report success... Because Terrain Builder relies on a couple of registry keys, it's necessary to run TB once from the Steam Tools menu - so go to Steam, call up the arma 3 tools and doubleclick - choose "Run Terrain Builder" and - once you see Terrain Builder open - just close it again and close Steam too - you're done with that... * From now on - forget where your Arma 3 Tools actually are - from now on EVERYTHING happens on P:\ ! ... and - that's it! You should be good to go with no further fuss... When you want to run TB - always run it directly from the Terrain Builder folder on P:\ B

Normally when you start the game and get to the Main Menu, you see one of the default BI terrain "cutscenes" - this is indeed an actual "mission" which you'd make in the Editor and then include with your terrain... The fact you're booting directly to your terrain means you've overridden that default behaviour with your config and set the game to boot to your terrain instead of the default BI one... That's ok, if thats what you want. More normally, you'd see the cutscene for a terrain after you EXIT the editor, when the default intro cutscene at the main menu is replaced with the one from "whatever terrain you loaded/used last"... If you don't actually have a cutscene, then what you see is a "static view" of that terrain - which is what you're getting, (I'm guessing). That can be quite an effective "quick substitute" for a full-blown cutscene - especially if its a nice view of a nice area of your terrain... You can specify that view, if I remember correctly, in your config.... seagullPos[] = {Xcoord, Ycoord, Height}; (I think), should do it... B

Following on from some discussion on the "Terrainmakers" Skype channel, it would be good to have some Official Clarification as to the status of "Terrains" within the contest category structure... Obviously, a terrain - by itself - doesn't fall under the category of "Total Conversion", though they may well form a significant part of the assets of such a TC... The most obvious alternate category for a "simple" Terrain addon would be...... "Addons"... however, the rules state..... No mention of terrains here - in fact, it seems to specifically exclude them! So - If I were to spend the next nine months making a terrain that utterly blows Altis out of the water, it would be ineligible for the competition, whereas if I make a pair of glasses, a silly hat or a scope attachment then - technically at least - I'm able to compete? Seems kinda unfair, and excludes a sizeable and particularly ingenious and creative section of the community... It'd be awfully nice if some kind BI rep could wander by and give us some Official Word on this aspect of the rules.... there's a whole bunch of talented guys currently in the dark on this subject.... B

Not sure if it actually creates a log file or just reports activity in the accompanying DOS window.... If it reports a fail - then it has definitely failed though, and that shouldn't happen... It would be helpful if you could post the full text of the fail error message, or even a readable screenshot of that DOS window if you can manage that... Since Mike's stuff is all quick 'n easy auto-installers nowadays it might also be a good idea to quickly make sure you have the very latest Arma3P, plus the installers for "ExtractPbo", "DePbo" and "Derap" - all of which Arma3P requires in order to run properly... Mikero is constantly updating his tools, so it's always a good idea to make sure you have the latest everything.... B

Additionally, I'd DEactivate "Outside Terrain" in your config for now... enableTerrainSynth = 0; Outside terrain tech seems to be semi-borked at the moment and occasionally causes freezes or crashes... Though, of course - at the moment - it looks like you're not getting that far anyway, so I'd definitely follow M1lkm8n's advice and run Mikero's Arma3P on your P:\ drive, plus consider using Mikero's PbpProject packer as well - it's particularly well-suited for terrain packing and is pretty forthcoming about any error details it encounters during the packing process... B

If you used Mikero's Arma3P to populate your P:\ drive - try running it again... B

Mikero's PBOProject is the most ruthless, unforgiving ba*@$%d of a packer on the face of the planet - which is exactly what you want... If theres the slightest thing wrong with your project it'll simply refuse to pack it - but it will also tell you WHY, and usually, WHERE to look for the problem... It's well worth getting it up and running properly - particularly for terrain packing since there's just so many different files & paths, etc involved in the process... B

Try.... midDetailTexture = "mymapnamegoeshere\data\mid_range_mco.paa"; without the leading "\" at the beginning of the path..... B

Everything's a little "small scale", which probably isn't helping... Terrain Builder is a little less forgiving of "odd sizes for stuff" than good 'ol V3... Your heightmap is - 1024x1024@4m = 4096 meters Try making a 4096x4096 sat & mask (= 1px/meter - generally regarded as a "minimum res")... This part is fine... This part isn't... Texture layer Optimum Size is around 40m x 40m - however, the sizes you're offered are tied to your heightmap cell size... so you'll be offered sizes like 4x4m, 8x8m, 16x16m, etc, etc... At the Very Least - you should choose a size that is LARGER than your heightmap cell size - and preferably as close to 40x40m as you can get... Have another go with the settings above and see if there's any improvement... Remember to delete your old ProjectFolder\Data\Layers folder+contents and then recrunch the layers with the new settings before checking them out in Buldozer.... B