bushlurker

As you load your heightmap files - one at a time - they'll go to the bottom left corner (eg: coordinates 200000E, 0N), but once each heightmap tile is loaded you can right click it in the Raster Layers list and access it's properties... There you can set it's actual final position coordinates (eg: 2001024N, 0N) That way, eventually - you can load in all your seperate heightmap tiles and grid them up the way you want... Then create a single mapframe covering the actual overall map area you intend to make and off you go.. The same load and relocate procedure can be used for multitile Satellite, Normal and Mask layers too.. It's slow - especially the bigger you go... but it works ok - so far at least.... B B

Well the Skype Terrainguys channel has been full of excitement since Terrain Builder arrived - everybodys been trying out different things and figuring out what everythings for and what works and what doesn't... Theres a basic VBS2-version Visitor 4 guide which was linked to previously - I'll link to it again below - if you ignore anything to do with "Landbuilder" then most of the rest of the basic info is vaguely applicable. I'm fairly familiar with that version of Visitor 4 and Terrain Builder shares quite a few features - though it has some variations on how things work, and some exciting new features, such as a "6 colours per segment" option for Arma 2 maps, and an even more interesting "5 colours per segment plus Terrain Normals layer" option... Landbuilder and it's scripts suite are understandably missing, but the new "fill polygon with objects" option has had M1lkm8n excited and busy loading huge numbers of trees in and out to see how that aspect of things stands up in practise... Looks to be a very useful option! There seem to be a few immediate snags - there's occasional crashes when doing certain operations, buldozer sometimes doesn't seem to work "out-of-the-box" with just a basic Default P:\ install, but in general theres a whole new world of V4-inspired or unique-BI options to fool with... It's likely to take some time before our understanding is complete enough to tackle writing a decently comprehensive guide, though no doubt as soom as we've mastered the basic functions and got a few basic maps successfully built, there'll be a "quickstart" tut or two will appear to help people get started... Expect to feel a little noobish at first - TB is a whole quantum leap more complex than 'ol V3 and even if you have some prior V4 experience, getting to grips with TB's unique blend of features will involve some learning, and relearning.... *edit* Visitor 4 Manual - Some Parts Are Worth Reading (Until something more TB-specific turns up) B

Might take a few days for one to appear.... If you define a default mapframe first and then cancel out you should then be able to import or drag in an .xyz or .asc heightmap... the mapframe will be the wrong size probably, but you can then set that properly once the heightmap is in... ** A few aspects ARE currently dodgy it seems - the otherwise Pretty Funky "automatic config creator and surfaces definer" tool creates the config successfully, but crashes midway thru writing the layers.cfg... There's a few other oddities as well, all currently being noted for posting as bug reports... PS... This is Terrain Builder, not Visitor 4 ;) - .pew (and .wrp) import fine, with the usual pre-that_quote Visitor 4 limitations... Objects are categorised into the Templates library as either "circle" or "rectangle" (natural or artificial) and roads are imported as a separate basic objects category too... The heightmap WILL be imported and added as a "mapframe heightfield", but Satellite & Mask files aren't imported or retrieved.... B

Terrific job on the heightmap aaglo! - L3DT? You should definitely have a go at putting one in-game... If you're familiar with L3DT then you're at least 2/3 of the way there... Follow thru the rest of it's render procedure, generating a basic Attributes layer and Texture layer and you have a "Mask & Sat" to match your heightmap... From there all you need is a handful of suitable groundtextures (BI ones can be used) and a few config files and you're pretty much ready to go! Arma 3 terrains are a little trickier right now since we lack some of the fundamental tools required... there's a few tricky workarounds available which will produce a working result, but it's perhaps not an ideal situation for a "First Go"... However - if you have Arma 2, then we DO have a fully functional set of terrain tools, with tried and tested procedures to match, which you'd probably find fairly straightforward to follow. That would quickly get you all the way to your first "in-game solo terrain" (A massive personal buzz when you get it working for the first time - believe me), and 99.9% of the experience gained in doing that will be relevant for Arma 3 terrains when the appropriate tools - finally - arrive... Take a look at This Tutorial... it's basically an L3DT heightmap, Attribute layer (Mask) and Texture layer (Sat image), plus the absolute basic necessary procedures and additional files necessary to get it in game and running... It's well worth a try and, if you've grasped something as tricky as L3DT, you shouldn't have too much trouble following thru the rest of the procedure... B

As far as performance is concerned, both the Size and the Number of "ground cells" are factors. The "new" 4096-size has always been there really, but due to a bug in the "Visitor 3" tools series, it's never been possible for us to effectively use that size. Presumably, BI have always had that size available, yet they've never actually chosen to use it until now - with Altis. The two new - and pretty all-round excellent - Arma 3 terrains are great examples... Stratis has a pretty small groundcell size (4m I think), and as everyone knows from playing on it, all those small-scale ups and downs and little dips 'n bumps make for some terrific gameplay! Altis, on the other hand, uses the full 4096-size heightmap, but with 7.5m groundcell size - comparable with Chernarus, but of course since there's 4096 of those cells instead of 2048 it's effectively the size of 4 Chernarusses in a 2 x 2 grid. Not quite the same close-up, tight detailed ground features as Stratis, but still pretty good, and with the new - and seemingly pretty playable for most people - 4096 size, it allows for noticably bigger terrains than we've been used to before. As and when the new community terrain tools arrive, we'll doubtless see a flurry of different sized terrains appear, as the terrain guys go crazy experimenting with all these new scale possibilities... The 4096 option in particular, which we've never really had effective access to, will open the door for some interesting sizes... eg: 4096x4096 x 12.5m groundcell (12.5m is probably the upper limit for an infantry-style map. That's the size used, for example, on the CWR2 Arma 2 terrains - you won't be depicting any small scale features like roadside ditches with that resolution, but for something like a "rolling hills / afghan / whatever" style map, it would allow for a fairly huge 51.2km x 51.2km terrain, which I'm guessing would still perform pretty well). Large-scale map guys will be looking at these sort of scales... 4096x4096 x 2.5m groundcell (The other end of the scale - this size would yield a 10.2km x 10.2km sized map - a decent "standard" size, but with a previously unattainable and impressively high-res 2.5m ground resolution it's potentially even more detailed than Stratis... you could make a decent attempt at little roadside ditches, etc with this sort of res). The hyper-detailed terrain brigade will be all over these sort of sizes.... When the tools arrive - watch the map scene explode! ;) PS. Meantime, you could have a little peek at my crazy experimental Strange New World terrains for Arma 3. Don't be misled by the "Star Trek Cover Story" - in actual fact, both of these empty experimental terrains are really, in effect, "pre-tools testers" - experimenting with precisely the sort of thing discussed above. I deliberately didn't really mention the fact, but they're NOT the same... The first "Taurus II" terrain is basically a very traditional sized 2048x2048 heightmap, with a 5 meter groundcell = 10x10km The "Rura Penthe" one, on the other hand, is actually a 4096 x 4096 heightmap with 2.5 meter groundcell size! - twice the resolution of the other one - higher res than even Stratis... Yet, it seems to have been the more popular of the two and nobody seems to have noticed any hugely significant drop in performance compared to the 5 meter one! Interesting!, and bodes well for more fully finished hyper-detailed terrains once we have the tools to dress them properly..... B

the BlueEdge only applies to EMF exports from Visitor... You calculate your size - eg: 10 pixels - ADD THAT to the "normal" satellite size you're using, and export the EMF... Using your numbers above - you'd export a 10250x10250 px EMF... Then - head for your Visitor 3 install directory, where you'll find "EmfToPng.exe" - drag the EMF file you saved onto that - it'll convert to a 10250x10250 .png bitmap... Then load that into your graphics program and crop off the 10 pixels "Blue Edges" That gets you back to a 10240x10240 which - should - overlay your actual Sat image perfectly.... B

700km x 700km terrains simply aren't possible with current Arma tech - even with Arma 3. As far as we know, 4096x4096 cell heightmaps are the Limit. Our current Visitor 3 has a bug which prevents effective use of 4096 heightmaps, tho we're hoping that'll change with the new tools. Doubtless BI have had 4096 capability all along, but Altis is the first time they've ever actually used it - probably due to performance concerns up till now. To make a 700x700km terrain with a single 4096 cell heightmap, each cell would be representing an #170 meter area - that's going to be Very Blocky and crude! The nearest you're likely to see to that sort of size is Rip31st's enormous WWII map, which I think he's pushed to about 153x153km - at the expense of pretty low detail terrain and some dodgy engine behaviour... It's simply not designed to handle terrains that big... B

I'm not sure if you can actually REload a heightmap back into an existing project... The option for heightmaps is limited to "import" I think, and thats usually the start of the process, and it unloads the old project before starting a new one... I think it assumes that if you've changed the heightmap externally then you'd want to recalculate anyway...... One workaround that you could try is to export the important layers individually, then start a new project with your latest version heightmap, and then import the other layers... I think before you import a layer - eg: Attribute Map, you have to have generated one beforehand, then you can import over the top... The same may apply to the other map types... B

Hi again.... Aha! - Sorry... I assumed from your post count you were a New Guy... Apologies... OK... Try this... [color="#FF0000"]class DefaultClutter;[/color] // assuming it's not been declared somewhere else already... class clutter { class bp_grasssmall [color="#FF0000"]: DefaultClutter[/color] { model = "A3\plants_f\clutter\c_grass_Bunch_small.p3d"; affectedByWind = 0.7; swLighting = 1; scaleMin = 0.85; scaleMax = 1.1; }; and add the ": DefaultClutter" inheritance to ALL your clutter defs... See if that helps... B

There's no need to have Plants_f.pbo in a modfolder - it's part of the game already, so the clutter models are already available... Assuming you've followed standard terrain procedure, you should have made a CfgClutter.hpp file at some point, which defines all your clutter types. A common beginners mistake is to copy the stock BI terrain clutter definitions - that in itself is fine, but you MUST change the classnames... EG: class GdtGrassDry: Default If you use this definition as it stands in your terrain, then "GdtGrassDry" is basically being defined twice - and that causes conflicts, and problems such as clutter not showing on one or the other of the terrains which use that definition... Something like... class BPmapGrassDry: Default .. would work fine though... Check your clutter definitions - make sure you aren't using BI classnames - if you are - personalise them, rebinarize and try in-game... B

I think it's slightly different... The floating point precision thing technically gets worse the further you are away from the 0,0 origin - which IS the SW corner... Arma does suffer from that too, but it doesn't seem to be nearly as bad as the Cryengine issue... It tends to show up at the extreme NE quadrant of very big maps, and even then you only really notice with hyper-precision placed stuff like Sidewalks, etc... The "4096 bug" seems to affect the "outer edges" of a 4096x4096 map - You can add objects to the list as normal - place, manipulate and rotate, etc - all as normal - in the Middle of the map - but as you stray towards the corners, suddenly there comes a point where you can place objects, but no longer manipulate them... The same bug seems to affect the VBS2 Visitor 3 "Non-PE Version" as well, but not any of the V4 variants I've tried... B

I de-confusd person915 on this point via PM, so no need to reply to this one, guys... B

The layers.cfg shouldn't be referencing the "_co" textures... - in the older days that would have been the place where you pathed to the "_mco" texture, but since individual groundtexture mco's are no longer in use (but the system still expects them) you can either use "dummy" _mco textures - and refer to them in layers.cfg, or you can use a simple set of parameters, like this... class sand { texture=#(rgb,1,1,1)color(0.5,0.5,0.5,1,cdt); material= "grmrl_yutz_data\grmrl_yutz_sand.rvmat"; }; That in itself is unlikely to be causing a crash though.... the Visitor log might hold a clue - you - should - find that in Visitors own install directory in your tools folder... worth a look... * edit Usually, the number one cause of a crash on importing is when someone has been using indexed colour on their mask and forgot to switch back to RGB... From the looks of previous posts, png format has been mentioned already, but I guess it's always worth checking again... the format should be 24 bit RGB (8 bits per channel, R-G-B = three channels = 24 bit) - a "standard" .png picture file basically - and "no interlace" if you get offered that at the saving stage... B

Hi there... got your PM... I'm afraid there are no Arma 3 terrain tools released as yet, so there's not really any hope of tutorials or guides until we get some tools that are actually designed for the job - then people will try them out, figure out a workflow and start writing guides.... There's a few Brave People who've struggled together some partly-working workflows, using the old Arma 2 tools plus some clever messing around with files, and managed to get the basics of some terrains working for A3 but it's a Massive Struggle - Arma 2 Visitor doesn't understand the Arma 3 models at all, for example, so you may need to place simple dummy objects, and swap them for the real ones later, or pull some other equally clever tricks, just to get some objects on the ground and arranged the way you want... I've lost track of the different subterfuges people have evolved to trick the tools we currently have into playing ball sufficiently to muster a functional PseudoA3 terrain... They're all very clever, and it's a testament to that essential terrainmakers skill - sheer dogged bloody-minded persistence, but it's still a shame to see so many talented people spending so much precious time fighting against the Toolkit instead of working with it... It's a waste of that most valuable commodity of all..... enthusiasm... From what we can tell, SOME things are likely to be very similar to Arma 2... the basics of Heightmaps, Sat & Mask layers, clutters & surfaces, the "layers.cfg" (more or less), the main config.cpp (similar, but often more elaborate)... I'd seriously suggest that you spend some time with the A2 tools and an A2 terrain project for now... I believe you struggled a little with the configs stage of things before, so this "gap time" while we wait for the actual A3 terrain tools would be an ideal time for you to get a firm grip on the basics of that, and perhaps also produce some basic terrain files - all of which are likely to be directly transferable to a proper Arma 3 project once they're actually possible.... B

To add object definitions from another project, just Import Templates" using your previous project's .pew file - that'll add all the definitions as they were in your previous project (Except Road Tool Definitions!)... Or, if you just want everything that's currently available (For A2 and OA anyway), theres a "Visitor Objects Template" .pew file on my website, in the "Resources" section... * For Arma 3 - I think - that ZeroG made a handy set of files for the 3D Editor/Visitor combo which - I think - included a Visitor Templates importer .pew as well - not absolutely sure, search this new Arma 3 Terrain section for ZeroG stuff - you should find it pretty easily... For BlueEdge - it's nothing to do with the actual cell sizes - all you need to know is - the NUMBER of cells (or pixels) in your heightmap, (4096) and the NUMBER of pixels in your Sat Layer (20480?) BlueEdge = The number of Sat layer pixels it takes to cover ONE heightmap pixel... EG: 20480/4096 = 5, so for you - BlueEdge = 5 With a 2048 heightmap and a 20480 sat layer it would be... 20480/2048 = 10, so that projects BlueEdge would be 10 B

Hmmm.... You shouldn't really have to struggle with this... it's one of the bits of Visitor that usually DOES work without problems... Lets step thru the whole procedure just to be sure you're not missing anything... * Prep your image - as Atsche says - Vis likes a bog-standard 24bit (that's 8 bits each RGB) windows bitmap .bmp file for this job... Technically you should be able to match your Sat Image size, even with a pretty hefty 20480x20480, although since it's usually mostly a rough guide image, I'd suggest trying with a reasonably sized 10240x10240 for now. As you've noticed, Visitor fetches the image from wherever you provide it and copies it into it's project folder - then uses it from that location. I've found that, since it wants to do that it's a good idea to let it do just that, so I just dump the image somewhere convenient, like the desktop. Once Visitor has secured its own copy you can just delete that desktop one... OK - image on Desktop & ready - launch Visitor and load your project... * On the same Popdown Menu as Artificial & Natural objects, etc - select "Background Images" and hit the "New Image" button... At this point, it starts to become apparent that Visitor can handle more than one background image, plus you can see that the image(s) you load don't necessarily need to be of the whole terrain - it's perfectly possible to load up detailed ground plans of small areas, individual towns, for example, in quite hi-resolution, and have them appear just in that town locale as a placement/planning guide... Anyhow - it's a "whole area" background image we want for now so lets look at the parameters.... Name: - give this image a name so you can select it from a list later if you load more than one... "Main_Background" or something will do... BMP file: - Use the "..." navigation to point to your image on the desktop. Placement X/Y: - Notice how this is a "meters" measurement - not pixels! In the case of a whole area background image, this coordinate pair should point to the Bottom Left corner of your terrain - the 0,0m point, so "0,0" for these two params Width/Height: - Again - this is in meters... I'm guessing your terrain is 4096@5m = 20480 meters wide/tall, so you should put 20480 m for BOTH these parameters... * Notice how it doesn't matter what actual resolution your image is - it's not mentioned here at all - whatever res it is, what we're specifying here is that it's bottom/left corner should be placed at 0,0 and then it should be stretched to cover 20480m wide and high. Finally - Transparency is usually OK at 50% and of course the "visible" box should be ticked... Then click OK and... You WON'T immediately see your image - what you probably will see is the entire terrain covered with a white crosshatch "selected" indicator... That's OK. At this point - Save your project, then completely close Visitor. Now restart Visitor, reload your project and... assuming backgrounds are switched on ( the "BK" icon), you should now see your background image filling the entire area... The background image should have been copied to your Project folder by Visitor now, so you can delete the temporary one on the desktop and you should be ready to go.... Give the whole palaver another go with the procedure above and let us know how it goes..... B

Go for the same settings if possible...In the "Calculator" section - enter 20480 as the sat size and accept whatever values it offers, then in the Base Texture Layer size parameter, use the nearest to 40x40m you can get that still comes up flagged as "valid"... B

Yes - you've got the idea... 2048x2048@10m and 4096x4096@5m ARE directly interchangable/compatible... Distances, scales and sizes will all be the same - the only difference is that, where you had one 10x10m "groundcell" before, now you'll have Four 5x5m groundcells... Because it's just a direct replacement like this, you should find that any object placement/roads, etc you've already made should be unaffected, so although it's best to make these sort of decisions at the beginning of a project, you should be able to change your mind even at this stage without too much trouble... If you have L3DT, then it's ideal for this sort of job, although I've noticed a slight "bug" in my version when I do this procedure - I'll mention that below - it's not a big deal, and it may only happen in my version since I haven't updated in a while... * Export your heightmap from Visitor - Project > Export Terrain into Picture.... When presented with the "Export Into Image" popup window - WRITE DOWN THE TOP SET OF MAX/MIN NUMBERS... * Load into L3DT - when asked for max/min values - use the numbers you wrote down..... * From the topline menu > Operations > Heightfield > Resize heightfield = set to 4096x4096 * At this point you'll be asked if you want to retain the same physical map size - which you DO, so say "Yes" and the horizontal scale (groundcell size) will automatically be reduced to half the previous size * This is where the "bug" appears in my L3DT... It seems the heightfield resize HAS taken place, but if I look at my display, and the scalebar below - it LOOKS like it's actually made the heightfield BIGGER - as if I'd said "NO" in the previous dialog. * If I now go to... Topline menu > Operations > Heightfield > Change horizontal scale, it reports that my horizontal scale (groundcell size) is still 10 meters! However - if I set that horizontal scale value to 5 meters and click OK, L3DT's display seems to "catch up" - no processing takes place - it just resaves the heightfield internally and the display and scale bar at the bottom of the screen change appropriately... I'm pretty sure this is just a display issue, and quite possibly only happens in my oddball old L3DT version... In general, L3DT makes a good job of this sort of scaling procedure... * Now export the new heightfield - as an .xyz file - and you should be ready to import into Visitor... There's an additional complexity to watch out for - at the moment - with 4096x4096 heightmaps... The infamous "4096" bug... (There's a reasonably good summary of what that's about in THIS POST... Notice how that link takes you back to the Arma 2 section? That's 'cause it's basically an Arma 2 Visitor 3 PE bug - we're all hoping that, when we finally get an appropriate Arma 3 Visitor, this severely limiting bug will no longer be present, but right now, with the tools currently at our disposal, it's something you should be aware of that affects 4096x4096 heightmaps specifically... More generally, ZeroG's advice is well worth noting... Smaller cell sizes are an increasing trend, even with BI themselves... Proving Grounds (A2) and even Stratis (A3) are around 4 meter cell size, and manage some pretty terrific small scale height variations, making them an absolute bitch and/or pretty awesome fun to play on! At the same time, you really need to keep performance issues in mind, and it's generally not a brilliant idea to go much below 3 or 4 meters cellsize, particularly on a map which will be carrying a lot of objects or vegetation... *EDIT* Thanks to Jakerod on the Skype Terrainguys Channel, we now know that this L3DT "bug" is simply the display not "refreshing" properly - the operations DO take place, as I suspected, but it seems you might be able to skip the step I suggested above - going thru the motions of changing the Horizontal scale just to "jolt" L3DT into refreshing.... Using CTRL + R, or from the Topline menu - View > Refresh should accomplish the same thing... Thanks to Jakerod for that Important Safety Tip! :) B

The main limitation with these sort of things is the resolution of your underlying heightmap... If you're using, eg: a 5 meter "cellsize" then it's simply not possible to create eg: 1 meter wide trenches.. The absolute minimum width trench would be 5 meters wide, but even that would look pretty "jagged" since there'll be no smooth "ramp down and ramp up again" - it would be a sharp "dip" in the ground with probably pretty jagged edhes. To make things smoother you'd need to gradually ramp down and then up again using several "ground cells" to get smoother "banks" or "trench walls" and, if you're using eg: 5 meter cells, then you're now talking about a 20 meter wide feature, which is more like a river than a roadside ditch! Small ground features like this, and particularly narrow trenches, have been discussed a lot in Arma terrainmaking, but as yet, there's no fully adequate solution - the heightmap cellsize is the limiting factor I'm afraid... B

New destructible walls look terrific SmokeDog, and seem to work just nicely as well! Thanks for all your hard work on those! And also of course to M1lkm8n, who's really pushed the boundaries recently with his work on interactable/destructible stuff in general! Fantastic job - that sort of thing can really open up gameplay possibilities! B

Hi Korneel! Thanks for the update! That's clarified a couple of the most-discussed topics recently - particularly the CBA issue which had a lot of people wondering... Could I just take this opportunity to draw your attention to another as-yet unclarified point which has a lot of the Terrainmakers Brigade unsure as to where they stand re: the Contest Categories... ie: Which category, if any, do basic standalone terrains come under... There's a thread in the Q & A section HERE which has had no official response as yet... It would be nice for the Terrain Guys to know whether they have to join forces with a Total Conversion team in order to be involved, or whether they can happily Solo Mod on and produce a terrain which can compete as a basic "Addon" in it's own right... Official clarification on this topic would be much appreciated by all.... well, all the terrainmakers anyway... ;) B

I remember Favslev! - Looks even better in Arma 3! There's been a fair bit of discussion and experimenting with the Outside Terrain going on with the Skype Channel Terrain Crew over the last few days - with mixed results so far. But the most common terrain reaction is an outright crash to desktop, which is why I was so quick to reply in your case... ;) B

Try disabling the outside terrain - it's currently not working properly in A3... Change... enableTerrainSynth = 1; to - enableTerrainSynth = 0; in the main config... Repack the pbo and give it a go.... B

Rightly so! It's perfectly understandable that some internal discussions & development should remain.... internal! - that's the Nature of Business sometimes... Thanks for dropping by with your updates Edge! We're all, of course, waiting patiently - dancing bananas readied... Some more patiently than others, it seems :D - but, hey! - that's the Nature of Modding Communities! :D Looking forward to your next update, once you have more news to share.... B

Hi Indigowd! Glad you found my old guide helpful, or at least a useful starting point.. First thing - DON'T worry at all about that "Assertion Failed" error... that's a well-known "glitch" which crops up frequently in logfiles, but which can be safely disregarded. A second minor point worth noting is this bit... world = "p:\joj_tiunda\Tiunda.wrp" It used to be a requirement that the "project folder", the "project name" (.pew and .wrp) and (in the main config), the "classname" all be identical, or else your users can encounter save game issues and possibly other odd behaviour. world = "p:\joj_tiunda\joj_tiunda.wrp" It's extremely likely this is still a requirement for Arma 3 terrains... I'm afraid that my old guide nowadays is just that - old... It's really intended as a guide to Arma 2 terrains, where it works 100%. As far as we can tell so far, it seems that 95% of the basic terrainmaking structure and procedures hasn't/won't change with Arma 3 terrains, but until we finally receive Arma 3-specific tools there's still a considerable amount of guesswork going on... Your "bad version 58" error above isn't really an error at all, it's basically just the Arma 2 tools way of saying that they don't quite understand how to handle the Arma 3 models. Take a look at this thread... The "AddonBuilder" it refers to is the new version of BinPBO for Arma 3. It's part of the limited subset of Arma 3 tools released so far. I haven't messed with these tools much as yet, but that thread would seem to indicate that at least they understand the A3 models version - which might help eliminate those errors... If you really are following my guide to the letter - and using the old BinPBO, then I'd take a look at the new one... I mentioned before that 95% of Arma 3 terrainmaking is pretty much identical to Arma 2 stuff... Most of the remaining 5% is basically in - the main config.cpp. Configs are very specific to the engine version, and although once again, the basic structure and a considerable part of the contents are just the same as A2, there are several important new Arma 3-specific areas to consider... from the above behaviour it sounds suspiciously like a config problem, so if checking out the new Addonbuilder solves your other problems, but this booting-to-editor behaviour persists, then it might be a good idea to look more closely at your config.cpp, or maybe even post it here so people can check it over and assist if necessary.... Good Luck!! B