bushlurker

You don't need a config for custom roads at all.... Well, maybe something like.... class CfgPatches { class MyRoadsPack { units[] = {}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {}; }; }; ...if they're going to ultimately live in a roads.pbo of their own or something... There are a couple of things you need to remember to include with road models - within the .p3d itself... First is a couple of "named selections" eg.... class=road map=main road (or "road" or "track") these should be in the "LOD 0"... The second thing to remember - which should fix your "rigid road" problem, is to set all LODs to be "on surface"... In each LOD in turn, select all, then hold shift and press "e"... choose the "on surface" radio button and OK back out of there... B

Hi! A lengthy logfile is pretty normal actually... a lot of the time what you're seeing is "reporting" rather than actual "errors"... All these lines... Cannot register unknown string STR_etc,etc,etc0 ... can be safely ignored. Likewise, all lines like these... Warning: CfgVehicles missing in PreloadConfig - may slow down vehicle creation ... are known P:\ drive misbehaviour errors that shouldn't actually slow down anything at all - just ignore these too... However - there's a slight problem with all lines like these... Updating base class ->Default, by p:\cha\WRP_PROJECTS\ca\anims\Characters\config\sdr\config.cpp/CfgMovesMaleSdr/States/Crew/ ... the actual "Updating Base Class" thing IS normal and SHOULD happen... this is BinPBO taking into account all the new updated configs extracted from your game files... thats a Good Thing... the one problem is the path where they're being found... You shouldn't have this "little configs only CA folder" actually inside a WRP_PROJECTS folder - it just gets created there by Arma2P since it's a conveniently named folder for you to fetch it from... you only really need the "CA" folder that's inside there - at that level in your projects folder... So you're almost correct.... just lose the actual "WRP_PROJECTS" folder so you just have..... p:\cha\ca\<lots of folders with config.cpp's only> P:\cha\bushveld\<all your project files & folders like Source, Data, etc> right beside your project folder... When you get to the project-of-your-own stage it can slot right in here alongside the "bushveld" one... P:\cha\MyNextProject\<all of that projects folders 'n files, etc> and that one "ca" folder with all the configs will work for all the project folders equally, so once it's there in position you never need worry about it again... This is a sneaky error... it wouldn't affect your test terrain at all, but if you were to place say, a house on the landscape and binarize a new in-game copy you'd find the ladders and/or doors wouldn't work... You'd find that out when you got to that building towns stage so it's an error waiting to happen and therefore worth fixing now... Finally - you guessed it - the "assertion" error is another weird one that BinPBO seems to occasionally throw... I'm not entirely sure what the many variations of it actually mean, though, like M1lkm8n, I've noticed that if you run binPBO a second time it often goes away :) Since I've never seen any specific adverse effects definitely attributed to that error I'd guess and say, ignore that one too... B

Even though there are alternatives nowadays, it's a good idea to have a fool around with the basic Visitor built-in Roads Network Tool... sometimes it's still pretty useful for making neat city grids, for example, or for when you just want a quick road or two.. besides, it's good to understand the basic default concepts... If you haven't already come across a link here on the forums, then you might want to briefly read the old but still relevant Alliexx's Roads Installation Guide, which you can find in the "resources & tutorials" section of my little website. That explains which road parts are useful and which aren't, plus how to install them all correctly in Visitor... Follow that up with a quick scan thru this equally old but relevant thread and you should be pretty much covered on the standard road tool basics... At the other end of the scale is Homers Roadpainter 2 - that tool abandons the "road network" concept entirely and allows you to lay roads freestyle in the main game editor, smooth the terrain to match, and import the lot back into Visitor again... Deeply impressive! The slight downside is that, in Visitor 2D view, the resulting road pieces don't "look joined up" - a quick check in buldozer and you'll see that, visually, they are - and crunched to a working file and put in-game, the AI will follow these roads just fine, but it does make it a little tricky to just quickly edit or tweak a "roadpainter road" in Visitor, or just quickly add a new small section... Which often brings you back full circle to the old built-in road tool - which is why it's useful to learn the basics of that in the first place ... Just to confuse things further, there was a "Roadpainter 1" ;)... This was Homers previous Roadpainter incarnation, and it was a sort of "halfway house" tool... it had the ease of use and brilliant freestyle roadlaying stuff using the in-game editor, but its output was basically in the form of Visitor Road Network import files, so you had to slightly laboriously place appropriate keyparts, then import the road sections one at a time. The upside of that was, once they were in, they were regular Visitor Road Network roads, with all the fairly easy editing and visual accuracy features they have (they look joined up)... If you want to have a go with that version of Roadpainter, you can also find it in the same section on my website... It's handy to know about all these alternative ways of laying roads - they're all useful in different contexts... It's generally considered wise to begin and end all road sections with a "keypart"... if you read the above basic roadtool stuff you'll have seen that a "keypart" doesn't necessarily have to be a "konec/terminator" piece, but often is... B

This might be the reason for your odd proportions in Visitor... With a 5m cell size you'd need a 1024x1024 grid - 1024x5 = 5120m/5.12km map... If you forced that into 512x512 all heights would seem exaggerated... B

One of the first things I tried with V4 was importing some A2 work... my "Carraigdubh" terrain... Visitor 4 has .pew and .wrp import capability (File> Import > Maps) That should get the basics in there, though some restructuring will no doubt be required... Extended Visitor 4 or even VBS discussion is generally discouraged around here, and the VBS forums rarely mention Arma 2 "crossover" projects... your best bet is probably to PM or Skype with the few people around who have a foot in both camps... Using V4 is my main employment nowadays, so you're welcome to PM me with questions on any specific stuff you're stuck with... Mondkalb knows his way around V4 too nowadays, he's usually amenable to a well-aimed PM too, so you're not entirely on your own... In fact, a while ago now, Mondkalb started up a Skype "V4 users making Arma2 stuff" channel... I think there were only about 3 or 4 of us initially, and I can't remember the last time anybody posted in there, nor do I even have the link anymore... Might be worth asking Mondkalb if he'd care to revive that channel, or there's nothing to stop you starting a new one - invite a few people... then at least there IS a forum where such things can be discussed, and the people involved might even know a thing or two about the topic... B

Yes... The Sample Models are hugely useful... As far as things like basic buildings, walls, fences, huts etc are concerned, virtually nothing has changed models-wise since Arma 1, so they're still very relevant as examples. Doors, windows, ladders, stairs - they all work in exactly the same basic way in the model itself... The one thing that HAS changed which you must be aware of for this sort of class of objects, and which confused us all a little in the early A2 days, we've already covered in this thread... that "Land_" prefix I added at the beginning of your Warehouse class definition... remember...? In a nutshell... If your building has any kind of animation - doors, ladders, windows, rotating satellite dishes - then.... The model itself MUST have the "class=house" named property In it's config entry, it MUST inherit from "House" (but see ** below) It's classname MUST be prefixed by "Land_" The rest of the classname should be IDENTICAL to the actual .p3d modelname ie: class Land_MyNewHouse: House model= \in\my\new\folder\mynewhouse.p3d; For specific detailed modelling questions you're probably usually best asking in the dedicated "O2 Modelling" thread, but there are occasional weirdnesses like the above which you need to be aware of - purely for models destined to be embedded IN a terrain, as opposed to stuff which is placed ON a terrain later, via the editor, for example... ** (Told you I was a little out of my depth here ;)) I've just been informed by Synide (who does know about these things), that - technically, you don't have to inherit from "House", but you do have to inherit from a CfgVehicles class that has the class attribute/property... simulation="house"; Thanks to Sy for that additional info...! B

Afternoon Gentlemen! On behalf of the Redoutable Tess Butler, our Mighty PR Guru, I'd like to draw your attention to the following survey... ITEC 2015 Survey We'd very much like to see the 2015 ITEC show to be hosted in Prague ;), so I'd like to ask you all to take a few seconds to vote, using the above link... Our "recommended" responses are... 1. Czech Republic 2. Prague 3. May ... and for the final question, we are members of the "National Training and Simulation Association (NTSA)" We'll probably only get one shot a decade at making this happen, so please take the time to vote, and also pass on the link to friends, community, etc... ....our Thanks to you all..... B

If you wanted to look inside the models themselves - which WILL be "binarized/encrypted" then you'd need to ask the author themselves, but config.bins can be "derapified/unencryped" easily enough - with Mikero's "Eliteness" for example, and it's perfectly legit to take a look for learning purposes... We all spend a lot of time looking at BI's configs to see how they do stuff... that's fine, and it's a completely different matter from copying the models themselves - which IS breaking the rules... Sometimes of course, it'd be REALLY helpful to see inside a BI model - to see all those tricky "map=" properties and all that confusing stuff actually in-place in a working model... Unlocked Arma 2 models are a little thin on the ground, but BI DID release a huge amount of Arma 1 models in unlocked mlod form... You can get those HERE... Grab the "environments models" pack and - READ THE EULA! Then take a look at some of the buildings models... you should find properly set up and working examples with ladders, doors... all the tricky stuff... Great learning material... and perfectly legitimate to use - WITHIN ARMA 2 PROJECTS only... What's not included is textures, config.cpp's or model.cfg's... you'll need to research those separately... *edit* I'll just correct myself before someone else does... ;) config.cpp's and model.cfg's are included with the Arma 1 sample models... B

class cfgVehicles { class HouseBase; class House : HouseBase { class DestructionEffects; }; class [color="#FF0000"]Land_[/color]Warehouse : House { displayName = "Armory"; icon = "\ca\misc2\data\Icons\guardshed_ca.paa"; mapSize = 10; model = "\Warehouse\Warehouse.p3d"; scope = public; nameSound = "house"; accuracy = 0.2; armor = 200; destrType = "DestructBuilding"; vehicleClass = "Warehouse"; }; }; should work..... I'd suggest you take a look inside any competently-made buildings pack... any of Mondkalbs Building packs, for example... you can unbin the config and take a look... B

Getting a little out of my depth now.... ;) displayName = "Name Of Thing"; should be in your object config class definition and will show up in the in-game editor if you set up the rest of that stuff correctly in the config, but for the "DisplayName" to actually show on map mouseover.... eeeh.... someone correct me if I'm wrong, but you might have to class your object as "House" to get that to work..... ...well - stuff classed as "house" shows the displayName on mouseover... whether there's other classes that also do, or whether there's another way to achieve it, I'm not sure... B

There was a thread about this recently...... HERE Mondkalb's Terrain Tutorial is also worth a read... it covers this topic briefly.. and most others too, so it's well worth reading... B

I'm not sure of the current trial package contents now that the new 2.0 has been released, but in general terms, the "Trial" version carries the same "dongle protection" as all other versions, so the process is pretty much the same as PE... There'll be the same "waiting for dongle to arrive in the post", activation, etc... Hence the cover charge... I'm sure Vandrel or one of the Sales guys will chip in with exact details if I'm hopelessly wrong, but if you think of the Trial Version as PE with an "Evaluation Version" watermark onscreen, and a 60 day time limit, then you won't be far wrong... B

Take a look at the "map=" named properties Wiki info HERE Pick the most suitable one and add it as a "map=whatever_you_chose" Named Property in the GeoLod of your model... B

This is definitely the right place for any and all Visitor/Terrain questions.....! :).... you'll get used to V3's "oddities" in time, and even get pretty fluent with it... just a question of practise.... OK.... First and most obvious way of setting a particular thing at a particular height is via a Visitor Script... Vis has a few of these hidden away in a "scripts" folder inside the main Visitor install folder... you access them via the "Scripts" menu item... Notice the "Manage Scripts" item - you can load and arrange all your frequently used scripts with that, and have them more readily available within the Visitor menu... For now - just click "Add & Run Script" and navigate to your Visitor/Scripts folder...... You'll see two scripts of interest... "show absolute height" and "set absolute height"... Both of these do exactly what you'd think, and require an object or objects to be selected - then you run the script... that simple... There's also a couple of "Buldozer Key assignments" which - I think - allow you to twitch objects up or down in set increments - while in "buldozer view"... Not sure what the default keys are for that.. I've never bothered with them, but you should be able to check via the "profile file" that buldozer is using.... Briefly - just like the main game, buldozer uses a ".ArmA2OAprofile" file to keep track of its settings... unless you've specifically told Buldozer to use one of its own and set that all up, then Buldozer will be sharing your game file! This means you can launch your game - go to controls assignment, and then - in the popdown list at the top where you can choose to view only "infantry" or "vehicle" key controls - choose "buldozer".... now you'll see all the key assignments buldozer is currently using and you can note them down, change them or whatever... If you want to be really clever, you could set these controls to whatever you want, then copy the resulting .ArmA2OAprofile file and assign buldozer to use it exclusively... that way you have separate control over all aspects of buldozers appearance... This trick is usually done in conjunction with a specific buldozer "config" file too... There's a reasonably detailed explanation of this more "advanced" Visitor/buldozer setup milarkey in this Beginners Guide Main thing to remember when nailing stuff to an Absolute Height is that - you can move the rest of the World if you like - that object ain't going anywhere! So if, for example, you line up a bunch of bridge sections, or a bunch of pond objects to make a lake surface - it'll work to the millimeter!, but any - ANY - tweaking of land heights anywhere near those objects could and will throw them off! You have to be totally done with areas levelling, roads smoothing.... anything that might jiggle the ground at all - before you start setting stuff to specific heights, other wise you just end up repairing the damned things endlessly.... The other main thing to remember with "absolute height" stuff is - should you have to export and then reimport those objects for whatever reason, then the absolute height setting - just like the "rotation angle" - will be lost, and they'll all be back at ground zero again.... Absolute heighting is a neat trick that's handy for a lot of things... not just the obvious bridges and ponds... if you take a look at eg: CWR2 Everon, you'll see all sorts of little signs... pub menus, "Fresh Eggs" and "potatoes sold here" around farms, etc.... all done with the "set absolute height" script and a little patient tweaking... but make this sort of stuff pretty much the Last thing you do - once any and all landscape adjustments are done and dusted..... There's nothing worse than having to tour an entire heavily populated map trying to remember every sign, every damned beercan you put on a table, just cause you've changed heights accidently... :( Have fun B

That's probably not a good idea either... I'd seriously suggest that you back up all your own work so far somewhere safe and start from scratch with a nice clean tools install, followed by a run of Mikero's "Arma2P" supertool... that will get you a fully functional and correct P:\ drive with everything in place exactly where it should be... I'd suggest you download This Beginners Guide (use the Armaholic link and grab the Source Files pack while you're there)... Follow the first part of that guide - it'll explain in detail everything you need to do to set up your Dev drive correctly... I'd also suggest that once you've done that, you follow thru the second part too... the whole thing will take you a few hours - maybe an evening or two, but at the end of it all you'll have been thru all the stages necessary to get a fully working terrain in-game, and you'll have a complete working project structure which you can adapt or copy and use to assemble your own project... and as a bonus, you'll have all the Arma2 models and assets properly unpacked automatically by Mikeros tool, and therefore everything should be in the correct place, tested and working perfectly... Doing this now will save you a lot of unnecessary grief & confusion later.... ;) B

Welcome to the forums!!! That's the problem right there... user content in "CA" - NEVER do that!... CA is where BI stuff lives... Read THIS POST which just happens to use Berghoff's African trees as an example ;)..... B

Could be any number of things... it's a little difficult to tell without further info... An outright buldozer crash could be... eeeh... missing Sat & Mask files??? Check your "Layers" folder is being created in the correct place in P:\yourtag\project\data\<layers folder should be here> The "buldozer.rpt" file on P:\ might hold some clues... Maybe you could take a look at that - post anything that seems relevant... I'm not familiar with the tutorial you've followed I'm afraid... at a quick glance some of it seems a little dodgy... There's some severely non-standard Layers folder conversion trickery (dating from 2007!) suggested, and the fact it dismisses the whole concept of having roads on your terrain as "not possible yet" is a bit scary too! If you're dipping a toe into terrain making for the first time then - well done! - it's a fascinating aspect of modding - a real jack-of-all-trades hobby that you'll have endless fun with, but it might be a good idea to start out with a basic tutorial thats a little more up-to-date and coherent... For a "Quick Guide" covering all the necessary steps for creating a simple terrain, your current best bet is Mondkalb's Terrain Tutorial That - quite briefly - covers just about everything you need to know... however, as it says in it's opening paragraph, it doesn't explain every mouseclick you need to make in detail. Sometimes it's good to have an ultra-simple, click-by-click explanation - and a full set of working example files - right at the very beginning... For that, you might want to take a look at this Total Beginners Guide (Use the "Armaholic Mirror" link for downloading, and make sure you grab the Source Files package from the link on the same Armaholic page)... B

This probably isn't helping... ;) Try 150 instead, see if that helps.... B

Right! - it's like a "historical" problem then.... I thought you'd only just done it, so backtracking was a viable alternative... Bummer! - it's a Repair Job then I guess... You can certainly export the heightmap back out to L3DT... Use the "Export Terrain to Picture" option - as it's exporting - NOTE DOWN THE TOP SET OF NUMBERS - these are the Real max/min height values you need - you'll get a .pbl too as part of the export process - throw it away... Just use the .png to import to l3DT and when it asks for max/min height values - use those two numbers you wrote down... that'll preserve all heights exactly as they were in Visitor. Now you're in L3DT, ready to try some repairs..... When you export again - just use L3DT's .xyz output - that usually works fine and when you're (re)importing to a populated terrain it'll be a LOT faster than the .pbl & .png combo B

Hi again! Ouch! I see what you mean!! This looks very much like there might have been some sort of "area selection" going on while you were smoothing, or possibly something to do with the export stage.... Looking at your picture, I'm guessing that somehow you've managed to induce a column of "null values" or something down one edge of your heightmap.... that's causing this "Grand Canyon" effect... There's a very sharp cutoff on the left hand side which would suggest that... On the right hand side the Outside Terrain tech is trying it's best to match the "overall character" of the rest of the heightmap - ramping up from that accidental canyon and thereafter looking like not too bad a representation of the general landscape to the left... Tricky one to "repair".... Backtracking to a version BEFORE you somehow induced this column of nulls would be my first choice... or... Wilbur has a "Basin Fill" feature - you could try just selecting the "canyon" area and simply filling it in... might not look quite like what you want though. I'd be a little wary of simply cropping that edge off your heightmap and then stretching the rest to fit... that's likely to throw off spot heights in the main body of the map... not something you really want to do with a project that's already progressed to the "objects on the ground" stage... B

Hi SmokeDog! Hmmm..... that sounds weird! The Outside Terrain is supposed to match directly to the edges of the main heightmap, of course... Could you manage to post a picture? B

Yeah...The "Exporting EMF info" trick is really handy - particularly when you don't have a "real" satellite image and/or the terrain is a "geotypical" one... You're effectively painting a Satellite layer - and matching mask - from scratch, so any and all information and visual detail you can glean from Visitor is a big bonus - especially since it's detail that matches assets on the ground! You could colour-code all your veg in "Natural Objects"... maybe have all actual "forests" in dark green, and all the bushes & "incidental veg" in light green....Export just that image on a plain background... now you have two "vegetation" layers of valuable info to use... Dark green areas could be used on your Mask - maybe to control a "forest floor" texture just for the forested areas - use the same layer to add corresponding "forest floor" shading or tint on the Sat. For the "incidental veg" you maybe can't afford a separate mask colour, but still - you can still use that layer as a "Satellite shader", and darken the areas "under bushes" (my favourite place! ;)) - just on your satellite image only... Roads are the most obvious use, as you've already guessed... you'll probably want to pull the same trick - a "shader" on the main Sat layer so roads are still depicted in-game at distances beyond which the road models themselves disappear...Using the same info on the mask means you can assign a basic "urban" or "gravel" ground texture "underlay & roadside verge" for your roads... That cuts down on clutter intruding into the road... By exporting Buildings positions as an image from Visitor you can do almost the same thing on Mask & Sat... that "general urban" texture and tint again... handy for the same reasons... it defines your "urban" areas a little more nicely, you can assign an actual minimal/no clutter texture to stop clutter popping up thru floors indoors. Of course, most of these layers you export will need a little work... The roads layer might benefit from expanding by a pixel or two, so you get that "roadside verge" effect. The Veg & Buildings layers will be a series of sharp-edged squares and circles... you might want to make them look a little more ragged-edged and "natural"... maybe for example, select those areas in Photoshop or Gimp, convert them to paths and "stroke" the paths with a natural brush (a favourite Mondkalb trick)... Starting to wander off-topic slightly now.... take a look at Mondkalb's Basic Terrain Tut if you haven't read it already - he's produced some pretty impressive synthetic Satellite layers using these sort of techniques... B

You can export an .emf vector file of whatever view you currently have showing in Visitor.. So, for example, you could fiddle with the background to get an all-white display, switch off all object layers except roads - then export that image at your full satellite image resolution - PLUS BLUEDGE... There's an .emf to .png converter utility in your Visitor install folder... just drag the .emf file to that and it'll automatically be converted to .png Then you can load that file into an art program - REMOVE BLUEDGE, and the resulting image should be a perfect fit roads overlay for your Satellite - and Mask - images There's a thread about this - HERE You could export other stuff as images... buildings, for example, or vegetation... both can be handy layers to have when painting a sat layer & making a matching mask.... ;) B

Hi! Best way to check if your intro is working or not is to go into the Editor - choose your terrain, and when you get to the main editor screen, quit back to the main menu... Your terrain is now the "last one loaded" so it's intro will play in the background of the main menu screen... I'm not sure about adding your terrain to the list of Default worlds,but if you're using eg: Spirited Machine's Arma2 Launcher, then there's an "additional parameters" slot where you could add -world=YourTerrainName That should play your terrain intro at the main menu when you load the game..... B

I'm pretty sure there's at least one olive tree model in the Arma 1 Sample Models "environment" bundle Not brilliant, but enough to get you started at least..... B