cctoide

As an addendum to the above, check out cB_Locations, this mission is already set up for highlighting all the BIS_fnc_locations areas on Chernarus.

Unfortunately Visitor 3 can only handle 10 degree curves, so most of the time you will end up with the problem you described when trying to recreate real places. I believe the dozens of unusable (in Visitor) road pieces that come in road PBOs might have other angles, but I don't think BI themselves ever managed to solve that problem completely as, going by the filenames, a lot of these pieces are one-offs for specific parts of a given map. To answer your question about AI, yes, they will be able to figure it out as long as it looks right to you, most of the time (both for curves and bridges).

Map grid square size is defined in the island config. For Chernarus the smallest grid squares are 100 meters, the larger squares are 1 kilometer and the largest squares are 10 kilometers. For the sake of consistency every island should really keep the above convention. If for some reason one doesn't, though, you can always go into the config file and find the section that looks like this, class Grid (this is from Chernarus): class Grid: Grid { offsetX = 0; offsetY = 0; class Zoom1 { zoomMax = 0.15; format = "XY"; formatX = "000"; formatY = "000"; stepX = 100; stepY = 100; }; class Zoom2 { zoomMax = 0.85; format = "XY"; formatX = "00"; formatY = "00"; stepX = 1000; stepY = 1000; }; class Zoom3 { zoomMax = 1000000015047466200000000000000.0; format = "XY"; formatX = "0"; formatY = "0"; stepX = 10000; stepY = 10000; }; }; The stepX and stepY values are the size of each grid square for that level, and the zoomMax value is the maximum zoom level they are displayed at. A note, though about the topic title: this has absolutely nothing to do with "terrain grid size", if that's what you're talking about. That's a more technical aspect of islands which defines the distance between two data points in the island's heightfield.

Yeah, check it out: CfgNames. However, Visitor 3 does not seem to support it. I suggest placing the key points in Visitor with the key points feature, and then manually copying the result with the correct position from the mapname.hpp into your own include file for the names class and writing in the name with the diacritics. The hpp file with the names has to be encoded in UTF-8. Whether the ArmA 2 fonts set has the necessary glyphs is a different issue. Obviously, there's the basic Latin alphabet as well as Cyrillic in there. There's acutes, graves, circumflexes and diaereses, and I've found there's also macrons (came in handy for transliterated Persian). I don't know about tildes on all vowels, nor ogoneks, but you can give it a try.

Make sure you've unzipped your plants2 PBOs into P:\ca\plants2\bush, P:\ca\plants2\clutter, etc., not P:\ca\plants2_bush, P:\ca\plants2_clutter, etc. plants2 is split up into several PBOs but they are all the same "virtual directory" and need to be unzipped as mentioned in the tutorials, or you will get the kind of problem that's showing up in your log file. That's all I can tell from your log file, there might be other problems that aren't immediately obvious.

The above is pretty useful; you might also want to check out Beton's tutorial.

Well, I'm about ready to release the roads. I've changed the roadway LOD texture for dirt1 and dirt2 so they sound like dirt roads. I also changed the named properties on the dirt1 roads so they show up properly as unpaved roads on the map... oddly, that seems to depend on the roads_e you have under P:\CA when you export/binarize the island rather than the roads_e the game actually loads.

I think I've figured out a way. I was sitting here earlier staring at Visitor when I thought I'd check out if any of the OA road pieces matched A2 ones. Fortunately, it seems BI basically recycled A2 road pieces with different textures to make most of the OA roads. And since we already have unbinarized A2 road pieces, I came up with an idea. Basically, this is how they match up: [b]A2 road type : road width[/b] asf1 : 12m asf2 : 9m asf3 : 7m city : 10m grav : 6m mud : 5m path : 1m [b]OA road type : road width[/b] asf1 : 12m asf2 : 10m dirt1 : 10m dirt2 : 7m path : 1m So: [b]OA : A2[/b] asf1 : asf1 asf2 : city dirt1 : city dirt2 : asf3 path : path I figured you could make "impostors" out of the A2 road pieces that fit the requirements, and create your own CA\roads_e to keep in P:\ and use only in Visitor and Buldozer. The binarization process would turn that into references to the files in roads_e and the game would simply load the relevant OA files, without ever knowing how they got there. I then thought that to make them actually look like the OA roads in Buldozer I could swap the textures in the unbinarized A2 road pieces. After a while texture swapping with Mikero's MoveObject (could have done it in O2, but it was simpler this way) I have a bunch of modified A2 road pieces with Takistan road textures. After all of this is done, I renamed my extracted P:\CA\roads_e and created my own. I put the altered A2 files in P:\CA\roads_e\Roads and copied the rest of the original roads_e to my own roads_e, including the CA config. I then added these roads to Visitor. There are a few problems with this method. First, some of the roads don't look exactly like they do ingame since they did some odd UVing with the OA asf2 using half of the asf1 texture. Changing the textures on the A2 city terminator pieces caused Visitor 3 to hard-lock (probably due to the curb mapping), so I left these unchanged. There's also no asf1_asf1 crossroads in A2, so I cheated with another asf1 crossroads which makes it look a bit odd. The most serious problem is the lack of 10 degree curves in roads_e. The altered Roads2 pieces look fine, though, so my solution for this for now is creating my own cct_tkroads pack with the altered curves for all road types. When/if BI releases their roads it should be a simple matter of using MoveObject on the PEW to replace my own roads. If they don't release 10 degree curves for whatever reason (which would also have to be added to the game files), then it'll just have to be a permanent dependency. My only doubt about this is whether I'm in the clear with regards to distributing my altered roads pack. I don't recall any guidelines against it, but I'm not sure if I'm allowed to redistribute altered (albeit unbinarized) BI models publicly. If someone knows whether this is OK, I'd like to know. Here's some screenshots of how it looks: - In Visitor 3. - In Buldozer, the hackiness is obvious. - In the editor, it looks nearly perfect. - Ingame, some of these intersections don't look like they're meant to be used. I should probably note that this I'm not giving any guarantees with this, and I can't really offer any support. I haven't run into any issues yet, but this might turn out to be a flawed, useless method. Worst case, you might have to re-lay all your roads when the official roads are released. Either way, if you're impatient to start using OA roads, this is one way of doing it. Backup your PEW and other important files before inserting the roads into your islands. Once I know whether it's OK to release the altered roads I'll look into doing it. Have fun!

There's two things you can do. First, for some maps people have already painstakingly taken mosaic screenshots of the map in the editor and pieced them together to form a complete map. I know there's one for Sahrani, not sure if anyone ever did that for Chernarus or Takistan. Second way is by using one of the "cheats". By going into the editor for the island you want then hitting Ctrl+Numpad Minus, releasing and typing "TOPOGRAPHY", the game will hang for a little bit and export a snapshot of the editor map to an .EMF file at the C:\ root. You then need to apply EmfToPng.exe (distributed with Visitor 3) to make this image usable. Unfortunately there are some (severe) limitations to this method - some aspects of the map do not reflect the actual map in the editor. There are no place names, spot elevations or runway outlines and some vegetation or other objects may not display properly. Apart from that, I know SprocketIdea offered some laminated maps of Chernarus and Takistan if you pre-ordered OA or CO from them. Obviously, though, that is no longer available.

The clutter objects are regular 3D objects (with slightly different lodding, I think), and they can be placed in Visitor. They're in plants2_Clutter.pbo. It's also worth noting that there are some variables in the island configs that can affect the clutter placement, like the "clutterGrid" variable (which is 1.0 for Chernarus, but 1.5 for Takistan).

This is probably too much work for a trivial benefit, but it'd be nice to have a "clutter simulator" tool. It would let you define clutter objects and set their probabilities (ensuring they add up to 1.0 or less), and then generate a sample clutter distribution for a small area that could be imported into Visitor, just for checking it out in Buldozer without having go through the compile process for every change. It could then either spit out a surface character config or you could just pop the values into your config by hand. I don't know whether the algorithm that BIS uses for clutter is simple or customized in some way, but having to recompile to see the changes leads to not really wanting to fiddle with it. I imagine this could reuse code from the mask mapper applications that are already available.

Well, for those interested I can say that changing the paths with MoveObject does indeed work, and doesn't crash V3 or cause other problems like I expected it to. Obviously there's no road outline shown and it's not something you want to do without backups, but it works. It does leave the road network defined as whatever road type you changed it from, though, which might cause problems later... I'm not sure. As far as I can tell, though (and I should have really noticed this sooner), there are no standard 10 degree road pieces in the roads_e PBO, unlike the Roads2 PBO. There's stuff like 15, 22 and 30 degree turns and the nomenclature is different, but no pieces that match the ArmA 2 roads, which would be necessary for the MoveObject method to work properly. So I guess waiting for the new tools is still the only way to go. Sucks since it kind of hangs up the rest of the island creation process... roads take a lot of heightfield editing and I have a feeling the time to re-import a heightfield grows along with the number of placed objects.

I think this is the most appropriate thread for this: I know it's a long shot asking for this here, but here goes. It'd be really great if I could find someone with knowledge of the following (doesn't have to be the same person for both): - knowledge of the (written) Persian language, able to translate simple words and phrases, and able to transliterate between Perso-Arabic script and romanized Persian. - knowledge of Modern Greek, able to translate simple words and phrases, able to transliterate between the Greek alphabet and romanized Greek. If you're interested, please PM me. It's absolutely no commitment and no stress. I only need to translate small phrases and individual words and names, not long texts or anything. I can't guarantee the project this is for will ever be publicly released, as it's pretty big, but if it is released you would obviously be credited for your contributions.

Regarding 1), check the instructions in the wiki for removing the blue edge on the exported image - if you have Photoshop, changing the canvas size is an easy way of doing this once you've figured out how wide the edge is. As for making the satellite mask, I haven't really reached that stage yet on any islands, but I had/have two plans: either copy and paste bits out of real satellite images and then use a lot of the PS repair brush, blur tools and airbrush, or manually draw in the features by starting with a base tiling texture for each area and then modifying it with the airbrush, grunge brushes and so on. You can also do it the easy way and just get your ground detail textures, tile them at a very small size and mask out the appropriate satellite areas, and this works fine, but you may find it doesn't look as convincing ingame since real terrain is more varied than that.

In the project parameters dialog, there is a button for the satellite grid calculator. Type in your sat/mask image size and it will tell you both the segment size and overlap (any color painted in the overlap area will count towards the color count for the neighboring segment).

Do you mean hex editing the references in the map file, or changing the ODOL version of the road objects? And are you saying you can place them in the editor with the roads feature? You can place them as regular objects if you're using OA Buldozer, but the problem here is being able to use them in the road builder, which needs snap-points defined in the model.

Thanks, Bushlurker. :) And obviously, thanks to HJ for making this tool.

Does anyone happen to have the zip files for the initial version and the camtest version of this tool? I'm getting started on my road laying and the camtest version would be really useful since I'm working on fictional terrain, and I get the feeling I'll need the X/Y coordinates from the first version eventually. The dropbox link for the camtest version seems to be dead, and I can't find anything for the initial version. Thanks in advance.

I was going to make a thread here some time ago because I'd just been going through the official island configs and I found all sorts of intriguing attributes in there that were never documented nor discussed. Usually beginner island creators get handed a premade config file by a tutorial, and I suppose more advanced users have to figure it out on a case-by-case basis. After that, it gets complicated. There's actually a few threads on the more obscure parts of island configs lying around, but they're strewn across the configs forum here, OFPEC, the PMC wiki, and personal sites. Knowing what all the different parts of a config do could make for higher quality islands, so I had a try at both collating documentation from existing threads, pages and tutorials, and adding some of my own speculation on what some values do, and I created a simple site that can hopefully be of use to someone, at least as a starting point. If see anything wrong on the site, please let me know. Some of it is educated guesses, but other parts are outright guessing based on attribute names and looking at what they refer to in the core PBOs.

I'm sorry if this answer seems a little vague, but the only research I've done on this was so I could write about it; I haven't actually done it on any islands yet. My understanding is that these modules require certain types of areas to be defined in the map's config.cpp. These areas are related to BIS_fnc_locations and seem to be mostly "hints" for AI and modules, and they're defined in the Names class under CfgWorlds, like map labels and symbols. Theses are some snippets of these areas' definitions in the Chernarus config (this is inside the Names class): class AFlatCS_Pavlovo_01 { name = ""; position[] = {1637.99,3942.0}; type = "FlatAreaCitySmall"; radiusA = 100.0; radiusB = 100.0; angle = 270.0; }; class AStrong_Msta_03 { name = ""; position[] = {11440.31,5497.8}; type = "StrongpointArea"; radiusA = 100.0; radiusB = 100.0; angle = 90.0; }; I don't know what all the different types do and I don't think they're explicitly documented anywhere, but their names are fairly obvious. I think Strongpoints are used by Domination (and possibly the strategic AI routines), and FlatArea might be something to do with flying AI, or simply another strategic hint. If you want to see how these are placed on Chernarus and other official maps, check this out. Again, I'm not entirely sure if these modules depend on this - for instance, I don't see any area types related to animals (though it might be that it simply spawns them away from City areas, or something). Give it a try.

If you're viewing a folder full of the files you want to pack in Eliteness, the second button from the left on the top toolbar will pack its contents into a PBO with the folder's name. You can also use BinPBO from the BI Tools to pack PBOs, particularly if you need to binarize them, as I'm not sure Eliteness binarizes when packing.

Get Eliteness and DePbo from here. Unpack Eliteness, then put the DePbo DLL into the same folder as Eliteness. Browse to the OA PBOs with Eliteness and double-click on them, it will unpack them to a folder with the PBO's name.

Ah, I see. I hadn't realized why the unbinarized versions of Roads2 were distributed with the tools. I'm eventually going to use both A2 and OA roads on this map, so hex editing the references in the PEW/WRP is probably not a good idea. I suppose I'll wait for the new tools and lay down the A2 roads in the meantime. Thanks for your replies.

The beeping noises are over01.wss, over02.wss and over03.wss from dubbing.pbo\ca\dubbing\global\radio\shared\static. You could either make blank WSS files and replace them with a custom addon, or maybe overwrite their definition - their config entries look like this: class RadioProtocolEN: RadioProtocolBase { class Words { micOut1[] = {"\ca\dubbing\GLOBAL\RADIO\shared\static\over01"}; micOut2[] = {"\ca\dubbing\GLOBAL\RADIO\shared\static\over02"}; micOut3[] = {"\ca\dubbing\GLOBAL\RADIO\shared\static\over03"}; }; }; In case you want to check them out yourself, these lines (5765-5767) are from the dubbing.pbo config.

I'm sorry, I usually post my solutions when I fix something like that. In this case it was a dumb mistake caused by not having used V3 in a while, I forgot to import dummy sat and mask images and it worked fine after that. :)