bushlurker

I'm still awaiting a Final Official Ruling too!, though an initial unofficial pre-holidays word or two with Dwarden seemed to indicate that the general feeling may be that a traditional basic standalone terrain should indeed count as an "Addon"... Now the holidays are over I'm hopeful the Big Bosses will get around to providing us with a proper ruling in due course.... B

US Army "Gaming" System gets upgrade.... ;) .... and on a lighter note, some interesting experimental stuff by one of our UK Office guys, Ben... B

Merry Christmas & Happy Holidays all! B

I'd been thinking about the whole music aspect of things myself recently and come to some similar conclusions... There IS a reasonable range of "Default A3" music tracks to work with - pretty good ones at that!" - I've been quite impressed with the standard of music in the new release - but if everyone's using the same tracks they're likely to get quite "stale" after a while... plus, the essence of a good soundtrack lies in it's ability to complement and enhance the action on-screen, whether it's atmospheric in-mission background music, an intro, a cutscene or promo video... you want it to fit... Sounds like a terrific idea, NeuroFunker! I'm pretty sure a "Generic Soundtracks Pack" would be a hugely welcome addon - I'm not sure if there's actually any other similar addons around at all! Like Rydygier says, there's very few "composer-modders" around! If you're interested in your music being part of a competition submission it might also be a good idea to offer your services to a Mod Team (or two) as "in-house composer", which would allow you to work in conjunction with other team members - "storyboarding" your music sections into their various cutscenes, etc for a really professional result, specifically tailored to the purpose... With a different modteam, it might be a similar workflow, but a whole different style and ambience of music to suit their particular atmospheres... Plenty of creative opportunities! After a decade or two gathering dust, I've just recently dusted off my old synths & guitars collection and started messing with some incidental music myself!... I bought a cheap(ish) Audio Interface for the PC and got a freebie basic Cubase with it! :) - Wow! Last time I used this program it was on an Atari ST... heheh... Results have been fairly cheesy so far :D... it's been a lot of fun though! B

Yeah - I sortof covered that with the... bit... I was more interested in Terrains as a "Modification of the game delivering new context of gameplay and setting " ... ie: as an "Addon" in their own right, and their status thereof. As for the rest - kinda straying considerably from the original purpose of my post, but... ... and 3DsMAX owners have an advantage over those who don't, Photoshop owners have an advantage over GIMP users (?) I bought an L3DT license a few years back - unfair!!! :)... And, as far as TerraTools is concerned, firstly it doesn't "make Arma terrains", (nor does VBS2 Visitor 4, for that matter), and even if it did, you'd be sorely disappointed by the output, which I would rate as "average/decent Arma 1-era quality" - at best... It makes relatively simple training environments for VBS - a Training Tool... There's a thread for (extended) VBS discussion HERE B

An Old Favourite finally makes a long-awaited return! And with Ice doing the job we're guaranteed Quality Work! A double-win situation!.... Great news indeed! B

Here's one... maybe not quite what you were looking for though... still, there's snow... ;) I suspect the choice of good terrains will increase dramatically once the new tools arrive.... B

10m C.A.R. data???? where??? :confused: :):bounce3: B

BI did Krk way back in the Operation Flashpoint days..... ;) B

This is another one of those inexplicable problems that occasionally seems to appear - and disappear - for no visible reason. A quick search of this section will turn up dozens of similar posts - most of which seem to resolve themselves simply by going thru the motions over again once or twice... Having said that, in this particualr case I'd try dropping the leading "\" from all your paths in Layers.cfg... Notice the error you're getting? - "Error loading - p:\\PCH_Arcadia\etc\etc that double "\\" is likely to cause problems... Try fixing those paths and try again - see if it works.... It's not a totally infallible rule, but in general, with terrains, assume that the engine will slap a "P:\" automatically at the beginning of all paths, so all you need to type is "the rest of the path after the P:\ part" B

That particular type of missing rvmat error seems to be quite common... If you check, for example, Sgt Aces classic Stickied Tut Samplemap thread you'll see the same problem reported multiple times. M1lkm8n is correct in his advice - it seems to be one of those issues which nobody has ever adequately explained, but which seems to often just disappear if you simply clear things out and "go thru the motions" over again once or twice... I'd... * Delete your TUT\Savos\Data\Layers folder * Delete the entire contents of P:\bin_temp (or whatever Temp Folder you have BinPBo set to) * Reimport Sat & Mask * View in Buldozer (should look OK) - Export .wrp (while Buldozer is still open) * Binarize & check in-game If the error is still there, then without doing anything else or clearing anything else out - binarize again... sometimes it takes a second go over the top of the first... In general - your configs look fine - a straight inherit from Takistan means they're short and to the point, and minimises potential for errors... I'd take another look at your cfgSurfaces though... The first class - "SavossandSurface" is fine, but the next two are BOTH simply called " class SavosSurface" ... that's not good, and may well cause odd behaviour or errors... Change those two classnames to "SavosslopeSurface" and "SavosrockSurface" or something appropriate before you slog thru the whole retrying palaver suggested above... Good luck! B

Hi Giorox! Hmmm... Looks like Mikero has updated his Arma2P tool to 2.5.1c, so you'll need that to start with... In the enclosed ReadMe Mikero says... Recently, Mikero has started converting all his tools from simple files to self-installing packages, so "extractpbo" refers to the ExtractPbo2.10.0.3.Installer.exe package... However - as you've noticed, "convertp3d" seems to be missing from the current lineup... ! Depbodll refers to the DePbo4.21.rar from the current list... Not sure about that missing ConvertP3D fileset though - I'll ask Mikero about that later tonight if I see him online... Meantime, HERE's a little package with the latest Arma2P, DePbo.dll and my currently-in-use versions of ConvertP3d and ExtractPbo - with a bit of luck this little folder should be all you need to get progressing again... Good Luck! B

NouberNou figured that concept out and implemented it in A2/A3 without too much trouble, it seems... Clever Nou! - as usual.... ;) B

You're welcome, as always... Sounds like you have plenty of additional content work to keep you busy! - always a good thing... Sounds promising too! Take a look at these two demo terrains for a start. (there's a second terrain on page 3 plus more screenshots) (note the total lack of A3 objects and even clutter tho... ) Feel free to download these and open 'em up if you want a peek at configs or anything you think might be relevant.... Technically, these two terrains were made entirely with the current A2 toolkit, and a standard A2 P:\drive setup. Since there were no A3 objects - or clutter - involved, the only "A3 involvement" was right at the end, where an "Arma 3 P:\drive" was used at the binarizing stage, so all binarize calls to "A3 data or configs" find the relevant data in the correct place. So there's a hack/workaround right there I suppose, though it's not really - one way or another we'll all need that P:\ drive configured appropriately with all the A3 content - just like we do currently with A2 stuff and it's "CA Content". Traditionally, BI have left us to our own devices in that regard, and so the Mighty Mikero evolved his "Arma2P" tool to make the whole "unpack entire game to P:\ and arrange it properly" job a "click once and go make coffee" experience. Of course, Mike has followed that up with an "Arma3P" tool, which does exactly the same job with the Arma 3 content. :)That's a good start! But, since there's no official Arma 3 toolkit (or buldozer) to match that P:\ drive setup, you're going to have to use your current Arma 2 toolkit with BOTH P:\ drives. Time for another hack/workaround, though - again - not really... I do this sort of thing all the time at work where I need to be able to switch easily between at least three different "P:\ drives"... Anyone who's intending to be able to make Arma 2 AND Arma 3 addons will require some sort of "environment switching" setup anyway... BI make this pretty easy... Since the entire contents of your Arma 2 P:\ drive is actually a folder in the Tools Install directory called "ArmaWork", it's not difficult to make another folder in there, called "Arma3Work", then set up a couple of desktop shortcuts which simply switch the contents of P:\ between one or the other of those two folders! Then you can switch to "Arma 2 P:\" for the majority of your construction work, and flip to "Arma 3 P:\" for that binarizing stage... This Post explains setting up that "Alternate P:\ drive" in detail and supplies some ready-made files to help you along. Note that at the end of that post there's some out of date info which describes manually unpacking stuff to your new "Arma 3 P:\" once it's established... that info dates from before Mike released Arma3P utility, so the procedure now is pretty simple... Establish an empty "Arma3Work" folder - set up switching - run Arma3P..... and you should be good to go... An added bonus of this procedure is that you'll be able to go digging around in that new Arma3 P:\ drive's "A3" folder (The Arma 3 equivalent of the "CA" content folder), where you'll find Stratis and Altis groundtexture sets ;), and configs, with clutter info etc, etc... all very handy... So - now... having done all of that setup fuss, you can switch back to Arma 2 mode, establish a P:\yourtag\projectname\ folder and make a start... - Yup - Yup (Arma 3 uses extra materials on the sat layer, but - for now - that IS a Big Hack... I didn't bother with it for my A3 demos) - Yup...All of the above can be achieved without moving outside the "normal" Arma 2 tools P:\ drive environment - so that's quite a lot to do already, and is as far as I took my little demo trek terrains... If you're ready for a Test Binarize, or if you've completed all of the above and you want to have a go with some clutter, then at this stage you'll have to copy your entire "NameTag\ProjectName" folder with all contents over to your "Arma3Work" directory - run your Tools Switcher and - you're in an A3 environment!... You can use paths like "A3\Blah\Blah\etc" (or whatever) for your clutter or configs and the required data will be found in the appropriate places by BinPBO and it should all work. If you want to go any further in this A3 environment however, then for now you'll need to start looking at some of those "workarounds"... The "Roads Technique" as described by M1lkm8n & ZeroG should actually work pretty well, so that's a hack, but a straightforward one... ;) and could be fun to try... So - a little bit of a fuss, but nothing major as long as you avoid actually worrying about placing any actual Arma 3 objects - for now... Who knows? I figure that - at minimum - some sort of Visitor that understands the A3 objects - with a buldozer to match... If we're lucky, then additionally, an "Import Sat & Mask" option that reads "Import Sat, Normals & Mask" and maybe even some sort of basic integrated shapefile creation process to cover the new roads technology... We'll have to wait and see, I guess... *EDIT* - oops! Looks like ZeroG beat me to it...! His post above basically follows on from what I've said... if you want to take things further than I've outlined above, I suggest you follow what ZeroG's been up to closely - you should be able to take things even further than I've suggested, and pretty much everything will still be viable when "proper" tools arrive.... B

Hi Wedge A) No (unless you have plenty of free time), and... B) Technically, Yes (if you have plenty of free time), though precision is hard to achieve and its an even slower process than usual. Personally, I'm waiting for the appropriate tools rather than get involved too greatly in all the admittedly ingenious object-placement workarounds, which doesn't preclude working on heightmaps, satellites & masks, groundtextures and even clutter mixes in the meantime - all of which work pretty much as normal for now, and which should plug-n-play into whatever new tools we're eventually given. On the Trees topic, SpeedTreeMAX has a very good reputation and can produce some visually stunning output - can't speak for the translation to RV Engine process, or how well the output would perform in-game. TreeGenerator 2 output looks - adequate, and considering just how polyplaned most of the Silvador/RV trees end up, is probably worth a look - certainly the free 1.2 version has to be worth a download if you're interested in that sort of thing. For creating unique little locations and vignettes, hand placement (with a little careful copypasting) is still the best way and still produces the best results... For larger areas of vegetation, and even for smaller, more focussed stuff (eg: all those hedgerows in my little Irish terrain), there's a new Community "random placer" tool - Shezan74's World Tools which I think you might find quite versatile and which can be used quite creatively to pseudorandomly place all sorts of stuff... B

I've noticed that too - it's like it can only remember so many, or so long a "string" or whatever... Definitely the sort of thing that should be checked in the New Tools before they appear... ;) B

You should be able to access This Manual which should help a little... also, as a (PE?) User, you're entitled to join the BI Sim/VBS2 Forums - there's a link to register HERE... There's a PE Users section and also an O2-specific section you should also be able to browse. The Forums aren't as jam-packed with info as these Arma ones, but when you're just starting out it's all useful reading... B

Sounds as if it could be a problem with the heightmap size or resolution, (I'm guessing the first error turns up in the BinPbo .log?), and the second one in game when the engine can't cope with the number of groundcells, or the viewdistance is too high for that resolution of heightmap... Only guessing... Could you maybe post more details about your project... eg: Heightmap size Heightmap cell size Sat & Mask resolution B

That's two people so far have taken a look and said that! - you must be doing something right! ;) B

Glad you got it working! Yeah! - there's nothing quite like standing on your very own first terrain, looking around and thinking "Holy S**t! I MADE this!!!" You're one of US now - and you'll never be free (or have any free time ever again) ;) ... a little more on clutter since I have time... Well - be careful! I'm not sure of the exact range of that particular parameter, but it's pretty "narrow"... The values I quoted above were taken directly from Stratis, since I assumed they'd "balance" with the A3 clutter reasonably well. The "default value" for VBS is "4", and their terrain clutters are so "thin" they're almost non-existent. What you don't want is to overdo it to the point where people turn clutter off as a matter of course, because it's "too dense" or "affects performance significantly" or "can't see a damned thing when I'm prone", cause then people are running around on the "bald" terrain you had before which looked just so..... bald... One trick I use quite a lot is to initially copy BI "density" - a "1.5" value or something, but then - in the actual clutter model definitions themselves, I drop the "size" slightly... In the individual definitions, where you see something like this for each specific clutter model... scaleMin = 0.8; scaleMax = 1.2; I'll change things to... scaleMin = 0.6; scaleMax = 1.0; Still the same range of randomised sizes, but just that little bit smaller on average. If necessary you can then crank the density microscopically, maybe to 1.4/3/2?... The goal being so that when people try out the terrain at first they think "wow! - looks Great" - then they go prone and think "Hey! Looks great AND I can still almost see when I'm prone! - I'll leave clutter on for my multiplayer mission!" ... a little advanced for your current stage, but something to think about and experiment a little with when you get to that "final polishing" stage... Finally, I really haven't messed with any of the current "temporary tricks" for A3 terrains, in particular, the "Roads" stuff, so I'll let some of the more informed guys take over for that aspect of things... Well done so far, again! and Good Luck! B

Hi again! It's the weekend!! :) - so I actually had time to take a look! OK - I dumped your source files to P:\ - binarized, loaded into the Game and the first thing I hit was this.... This is a very, very common error that turns up all the time... It tends to panic beginners a little, and you'll see the Tutorial threads littered with errors like this... In almost every case, it can be cured simply by reimporting the Sat and Mask layers - so that's immediately what I did, and it went away as expected... So no problems there, and I mention it purely in case you see the same error yourself and think it's something serious - it isn't! - Reimport Sat & Mask and it - should - go away... So - then I binarized again, and - sure enough - no clutter! Now - lets think theory for a minute.... You don't actually see clutter at the Buldozer/Visitor stage... that's because it's purely a "runtime" thing... It's specified and controlled by the config, and the config likewise plays no part in the proceedings until the final binarize/runtime stage. So if there's a problem with clutter - it MUST lie somewhere POST-Visitor... That means, the config entries themselves, or the Binarizing stage. Since the rest of your terrain seems fine in-game to me (apart from the clutter), and seemed fine for you too, I'm guessing by now that the Binarizing procedure you - and I - followed was also OK... That leaves the config, so time for a proper look at that... Sure enough, after actually looking closely, I found this section... clutterGrid = 10; clutterDist = 1; noDetailDist = 40; fullDetailDist = 30; Here's the problem right here.... these numbers are Waaay off... I substituted some "safe" values.... clutterGrid = 1.5; clutterDist = 125; noDetailDist = 65; fullDetailDist = 15; and.... Lets look at these numbers and what they mean.... [color="#FF0000"]//this is the size of the "clutter grid", lower numbers will create higher density clutter, but may affect performance[/color] clutterGrid = 1.5; [color="#FF0000"] //this is the radius around the player that will be filled with clutter[/color] clutterDist = 125; [color="#FF0000"] //this is the distance from the player at which detailed ground textures begin to fade to sat layer[/color] fullDetailDist = 15; [color="#FF0000"]//should always be BIGGER than the heightmap cell size[/color] [color="#FF0000"] //this is the distance at which the detailed ground textures disappear completely and the satellite layer takes over[/color] noDetailDist = 65; Not sure where you got your original figures from but they were seriously out of the ballpark... Try substituting the values above and you should be good to go! Otherwise - Damned Fine Effort All Round!!! It's looking Very nice, and is a terrific first attempt! - Looking forward to seeing you take things further when the tools arrive!!! B

Not sure if it'll help with the clutter, but at an initial Fast Glance.... In your Layers.cfg - you're correctly pointing the surface classes to the "mco" and the "rvmat" for each surface - that's correct! But - in the actual .rvmat itself you're pointing the two paths to - the "nopx" = correct, and... the "mco" again = wrong.... make that second path point to your "CO" texture... Otherwise - things look OK, now you've implemented M1lkm8n's suggestions... It's a common mistake when starting out just to copy those clutter classes directly - and this DOES cause the "disappearance" of clutter - either on the terrain you copied the definitions from, or on your own... M1lkm8n's other suggestion - clear out "bin_temp" is also a good one - BinPbo tries to be clever and save time on packing by reusing stuff that "hasn't changed" since your last packing run, and sometimes it can get confused and skip new changes that have been implemented - deleting the entire contents of that folder means your next packing run will be slow, but "clean"... Finally - I'm not sure which guides or tutorials you've been following - you seem to be doing exceptionally well so far!, but one step you'll often see mentioned which is worth doublechecking... When you import your sat & mask in Visitor, you'll be asked if you want to make the resulting .rvmats binarised, or as text... If you choose "binarized" then - that's them done! and so - when you get to the binPbo stage you don't want to be binarizing them again, and so you'd make sure that "*.rvmat" is INCLUDED in that "list of files to copy directly" within BinPBO. If on the other hand, you chose the (more usual, in case you want to mess with them later) "text" option at the Import Sat & Mask stage, then you WILL want to binarize them at the binPBO stage, so "*.rvmat" should NOT BE on that "list of files to just copy directly" - I see that it isn't on your list, so am I right in thinking that you chose "text" back at that import stage?... Binarising them twice, or not at all, by mixing up these options can lead to occasionally unpredictable results with ground surfaces, so it's worth being sure... It's a "set once then just follow the same procedure" situation though, so once you're sure you're correct you can just follow the same choices every time.... B

:( Bad Santa! :( B

Yeah... M1lkm8n's absolutely correct... we need more detail Biggins... Especially if you're just starting out - and maybe even following this guide - there could be multiple reasons for errors... Take a little time and detail what you've done so far, and precisely what error you're getting, and we'll see if we can narrow things down to a specific problem... B

I had to explain this whole "on surface" etc properties thing, in painful detail, with pictures, to one of my fairly beginner-level VBS customers recently - so I just happen to have a couple of screenshots handy... (You can safely ignore the fact that these are actually VBS screenies - it's actually a crazy mishmash of "Arma 1" models, on my "Arma 2" Carraigdubh terrain, in the "old" - to all intents and purposes "Arma 1-era VBS")... :confused: As far as these model properties are concerned, I'm pretty sure there's no difference between then and now, or between "old vbs" and "current Arma"... A pretty extreme slope there, just for illustration purposes... but you can see that verticals are preserved, though as you rightly note, the "skewing" might play havoc with detailed horizontal features... If your slopes aren't so extreme, you might just get away with it... I guess the only way to know is to try... B