Nicholas Bell

Use can use the "pond.p3d" object for creating lakes and rivers. However, one cannot swim in them nor do they cause the player to drown. Boats will ride on top of them. They just look like water. One good thing about them is that they do not have waves, which isn't realistic on a river. A work around I was experimenting with was to create a very deep trench at the bottom of a river. You couldn't see it, but if a player tries to walk across the bottom of the river, he fell to the bottom of the trench and was killed. When creating a river or a lake with the Pond, you can increase it's size to 500% of original. Be sure to overlap the objects a lot, or boats will fall to the bottom occasionally. Use the SetAbsoluteHeight script in V3 to get them all at the same level. As far as road creation in V3, simply lay the roads on the mountains and use smooth roads script. You need to experiment with the settings. Moving average at 25 is good for normal terrain, but not so for mountains. Lowering the value to 11 or 12 will give you smoother results in mountains. If you want a constant grade use the Simple Average, or Slope settings. You may need to tweak the elevations around the grades a bit in Buldozer to eliminate the saw-tooth effect of the elevation changes. These did the trick for Razani mountain roads. There is no need to attempt to create the road elevations by hand if you use the smooth road script.

I do have ruin.p3d in the the razmisc file - but why would your map be calling it's use? Especially since you are saying you didn't use the ruin object? Weird. The obvious solution is to delete the razmisc.pbo

delete double post

Most likely a problem in the config.cpp file - incorrect punctuation, missing punctuation, etc. Might look specifically at the lines defining the weather conditions. I had a problem there which involved an additional space in a line. Caused a horrorible HDR whiteout when the mission started. I found the reason only when I copied the section from a good config over the bad part and solved the problem - it's hard to see an extra space (which in theory should have no impact anyway!) Although I am a horrible proofreader, post your config file and maybe we can spot the error.

Have you tried binarizing the BIS Ramadi sample map to see if the problem still exists? If it doesn't you could study it to see what the difference is between it and other islands. (if you have the source files). Looking at the sample map mask file the bottom of the sea is sand - same as much of the island.

Cfgsurfaces defines the characteristics of the new, non-BIS textures, and links the texture to the CfgSurfaceCharacters, which in turn defines the types of clutter assigned. Check out these useful links: http://community.bistudio.com/wiki/Layered_Terrain_Surface_Representation http://tactical.nekromantix.com/tactical/wiki/doku.php?id=arma:modeling:grass_tutorial The program uses the lower left hand corner segment (both mask and sat) to cover the area around all edges of the map to infinity. Before you binarize the map, manually repaint that .paa file so it blends in with all edges of the map. Best to use TexView to convert the paa file to tga or png, edit, then resave as the paa file. Do this for both the mask (m type file) and the satellite image (s type file).

Here, here. I second the motion to maintain this thread...somewhere else. ACE is not everyone's cup of tea all the time.

Yeah, I think it's big enough  That's a lot of area to place objects and detail properly.  Looks interesting. The heightmap looks fine, but without knowing what elevation parameters and the environment, it's hard to comment.  I personally would recommend not going wild with high elevations - there are plenty of islands out there with totally unrealistic elevation extremes.  Plus the vehicle path-finding AI doesn't consider elevation changes. Keep at it, the fun part of the process is over. Glad you were able solve some of your issues with Wilbur.

Have long given up attempting to use the V3 erosion filter. Â Use Wilbur instead - it has comprehensive erosion routines. Â Wilbur Homepage How are you creating your heightmap? Â I have not seen this issue using a variety of heightmap editors. Â Using a smoothing tool in an editor does a fine job of deceasing the slope.

SoLo (member of the Test de Cazzo Clan) has created three very nice planning maps for the current version of Razani.  These jpeg images are created from the ingame map, and are 2268 x 2259 pixels. Useful for mission building, mission map graphics or in-game land nav if you don't hitting the 'm' key  They are of course much sharper than the tiny images below.  Thanks SoLo! Download the pack here:  Planning Map Pack (15 mb)

I've sent links for the files to Sgt Ace and Mr G-C for their use, and am looking forward to their take on the color issue. It's a bit frustrating for me, given I cannot fix what I cannot see. Â Especially something as subjective as color. Â I was reminded by my wife that I am "color blind". Â Well, not truly color blind - deficient is perhaps a better term. Â Actually "Anomalous Trichromat". Â This affects me in daily life in problems distinguishing between similar colors. Â Honestly can't see how it is affecting this work, but it must. Â Whether regarding this map or Schmalfelden, no one has ever come out and said the colors are "spot on." Â So the issue is there - whether I see it or not. So I appreciate Sgt Ace and Mr G-C willingness to take a stab at something I can't get right. Those switchbacks are always going to be a problem. Â The vehicles will negotiate them with enough waypoints, but everything goes to hell once the shooting starts. Â And wondering out loud about how vehicles handle pathfinding - is there a difference between a group of vehicles where the crew is integral as opposed to an empty vehicle which is driven by a separate unit. Â As silly as it sounds, perhaps making the vehicle drivers high ranking officers with super skill levels might make a difference(?).

Thanks for posting the images TankCommander.  I will see if I can adjust the streambed color, maybe just a little desaturation will help.  I'm just not seeing blue.  Your image looks totally washed out - and I have  checked it on 2 monitors.  Maybe you should have Mr G-C examine your monitor to see if it is up to his standards There is nothing wrong with my roads and the AI, unless you think this is too many waypoints: I created a tank platoon group, changed the vehicles to HMVEEs and let them go.  The only place they had a problem was on the last leg.  When they got close to the switchback they wanted to shortcut and go up the hill.  But otherwise the 4 vehicles stayed on the trail just fine. Mr. G-C, you don't need to put my name in quotes. It's my real name, not a handle. I'm sorry that I am unable to please everyone with how I create my satellite maps and textures.  Mr G-C reminds me that some were (or are still) not happy with my Schmalfelden colors.  Given my apparent lack of skill/talent/knowledge of Photoshop, etc, I propose a challenge to anyone who is willing to step up to the plate - publicly of course, like me - and redo/adjust my work to what *they* think is best.  We can post all the versions and have a poll or some such thing.  I will provide the PSD files to those who are interested.  Please don't PM me, let me know here in this thread so everyone knows who is on board. The PSD file is over 1.2 GB - lots of layers.  I will have to upload groups of layers and you will have to reassemble them.  When complete you can flatten the image and provide a link to me, and I will integrate into the map.

Not sure to ask about this one  Thinking about it, it likely is not the road object itself, nor a config issue as both simply refer to BIS files.  That "only" leaves the texture the road sits on, which is merely a copy of an existing BIS texture, with the rvmat changed.  The problem of wandering AI has been experienced and questioned by others building islands too.  I wonder if appears on any other non-BIS islands other than mine and Opteryx's - something to compare to. I'm not seeing blue, TankCommander.  Could you post an in-game image so I can better understand?  Is it just the sat image or is it the transition area between the texture and the sat map.  I agree with what the river bed is composed of, and I created it using the GE image so the colors would be right.  I also made it transparent (70%) so the underlying color would tint it. I'll test making the streambed texture more "sticky" and see it that changes the AI behavoir on the trail.

Never heard of that movie - "The Beast". Â Pretty nasty start. Â At first glance those do look like T-62s (the mid-barrel smoke evacuation system), but as noted above they are rebuilt captured T-55s with US 105 mm guns. The film was also shot in Isreal. Well, when I said a lot of waypoints, I meant several around every corner. Â This has been my experience all the while with ArmA - Â whether the BIS maps or my earlier Schmalfelden map. Â If you are saying you can give a unit a couple of waypoints on other maps and it will follow curves and take the correct turns, then I am doing something wrong here. One thing that may play into the trail you mention (I assume you mean the east-west one in river) is that the "roughness" factor of the terrain is barely worse than the trail because it was pointed out during testing that it seemed wrong, ie vehicles could not travel quickly in the river beds. Â Maybe the AI is calculating that it takes less time off road than following the trail because of this (?). Anyone have any real world experience driving on a rocky dry stream bed? Â I'd be happy to bump up the streambed roughness if this would help the vehicles stay on the road. Yeah, the damn things will try and climb a cliff to avoid following the road unless you explicately waypoint each and every hairpin. Â I've seen then go up slopes and tip over backwards. Â The invisible object idea is intriguing, but is there any real evidence that the vehicle AI pathmaking routines actually make vehicle go around walls (which is what this invisible object would be)? Â Seems most of the time they just bash into objects and get stuck - or knock them down and keep going straight if they are able. Â Â Maybe I'm wrong about this, I pretty much gave up using vehicles a long time ago in my little missions because of their unrealistic behavior. Â Heck the infantry AI doesn't even slide along a wall until it finds an opening.

These are images from the Afghan side of the border, but it is same range of mountains and terrain type. Â Not light tan or pink sandy color. And this from a tester who said the terrain reminded him a lot of Afghanistan - a personal shot. Â Without having this image before, I think I got the dry river beds pretty close.

Yeah, I'm not making sh*t up as I go along. Â Attempting to recreate reality here, best I can. Â Admittedly, the angle of the sun, time of year, quality of photo can have a bearing on the color of the ground. Â Heck, the map looks different in-game on my 2 computers. Â That is why I am using the high resolution Google Earth image of the area as a basis for the project. Â The color on it I confirmed with other true color satellite imagery (Aqua and Terra via Modis). Â If you check Pakistan on Google Earth you will see a wide range of terrain - any colors. Â Even the Razani sat-map has a wide range of colors. These are obviously greatly reduced images, and much is lost in converting to jpg, but you can see that the satellite image I have created is actually lighter than the GE image (apart from removing shadows). Â This is because I have to take into the account how the ArmA engine changes the appearance of the satellite image by overlaying an .MCO file over the sat image to add variation. Â This darkens the sat image at certain ranges. Sat Map: Google Earth Image: BadBenson posted a few images I referred to - here are a few more which show this is not sandy desert, rather semi-arid mountains:

Thanks, Miles! Been waiting for this - so much for working on Razani tonight. Will have to wait while battles rage

Other than using the road smoothing script which I've done, there is no optimizing. Â These are standard, non-modified BIS roads and trails, placed on the map in accordance with standard Visitor protocol. Â Nothing fancy here. I use a lot of waypoints when I plot vehicle movement in a mission which get them where they need to go and keeps them on the road. Â When the shooting starts they drive all over creation. Â I long ago gave up being attempting to command tanks or tank platoons because of my inability to control units, on or off the road. Could you give me a location where you are seeing the AI ability to stick to the road repeatedly fail? Â I could add some hidden roadways at the those spots to see if they will smooth things over.

Good to see no complaints about performance (yet) – and I guess the issue of structure color/saturation levels is acceptable.  Still on my list to tweak a bit. Must admit I am stumped on the configuration files – I don’t really know what I am doing.  Or why.  Basically modifying Opteryx’s stuff to fit the renamed objects (necessary to prevent problems between the addons).  While his stuff works, mine doesn’t.  If it were across the board wrong with all my objects it would be a lot easier to figure out, but not the case.  Obviously I have more work to do. Good point – I only check them based on firing on them.  Unfortunately increasing the armor solves one problem only to make another, which is to make objects more resilient to HE fire.  Fastest way to bring down a structure is firing sabot, which is a** backwards.  Opteryx’s Bigwall1 objects convert to a neat rubble object when destroyed.  As noted in the readme, I am unable to duplicate this – another configuration file issue.  Hopefully once I get this resolved I can consider creating similar type rubble or breached wall models which are much nicer than just tipping the object over. There are metal roofed structures in the area, so the “Army Storage Hut†(not a bus stop) is not totally out of order, despite how it looks.  Practically all of the buildings in the qalats are built into the walls, with no gap at all.  I will look at widening the space where I can.  Eventually hope to have models which can be placed adjacent to the wall with no gap without stuff appearing on the outside wall of the qalat. The parallel roads and the shape of these structures are there because that is how it is.  You will see odd shaped qalats where there are odd shaped qalats.   While I may have to slightly move or modify structures (given what objects I have to work with), I do my best to follow reality and not just make up sh*t. NB:  The farm field areas are an exception.  The actual fields are tiny walled areas, often terraced.  Terracing is not doable, and having 2 dozen walled fields instead of one makes no sense when the AI can’t handle the walls as they are. Opteryx has AI paths built into the wall doors and gates, as he does in his structures.  I am as frustrated as you with how the AI fails to make use of them.  I’ve gone to the extent of placing additional BIS “standard†hidden pathway objects  in the entrances to see if that would help.  The only way I saw noticeable improvement was if I doubled the size of the pathway object – and then AI soldiers would then go through the wall.  Evidently the hidden pathway object kills the effects of the geometry LOD.  I want to experiment with placing additional pathways through the doors and gates.  My thought process here is that a pathway has an entry and exit point, and the problem may be that the AI is not hitting that point when it passes by.  Maybe more points would improve the chances of getting the guys through a gate. This is why I personally stick mostly to “open field†type engagements and leave the qalats to air attacks. Yes.  First I need to get the config file “right†before proceeding.  Once that is done I will continue to add structures and fix problems.  It takes a great deal of time to convert a “working†map to one presentable to you.  For example, there’s no need to change the sat image and mask when I am just placing objects, but those definitely need to be updated for your use.  Plus I need to add enough content so that one is not downloading a 235 MB + file just to add one or two qalats. No, building it in Visitor.  I’m not smart or patient enough to get 3DE to work.  Hopefully folks will be kind enough to post some templates of their work.  If I had the time I would create a mission with sandbagged positions all over the map in spots where they would make sense.  Then the user could simply pick the ones he needed for a mission and delete the others.  If I had time. On a different note, sandbagged positions on top of the tower roofs seems to be a fairly common practice.  I’ve found several images with these.

Not sure what you mean by "one hit"? Do you mean clutter? If so, then the amount of grass clutter is controlled by the config file associated with the project.

Having a hard time understanding your description of the first problem. Could you post an image? About the missing textures (white squares) I would start by manually going into your Data | Layers folder for the map and deleting everything. Then reload the pew and start over getting it into buldozer, ie import your config, sat & mask, etc.

Same values I have in all my maps, so I don't think that's an issue (although I would like to know what it all means also). You are talking about the standard ces_d* series of dirt tracks, right?

Not sure I can help on this - the road speed is set in one of the main ArmA config files, which I doubt you touched. Â However, I had the same problem on my Schmalfelden map - off-road speed was faster than on dirt tracks. Â Turns out my problem was the "rough" factor I had used in my custom map terrain was too low. Â In the map config file the class CfgSurfaces define the surfaces. Â The "normal" rough factor is 0.1 and I had 0.01 (the larger the number the greater the amount of friction, thus lower speed). Â I had this small value because I used it from a tutorial which was obviously incorrect.

Is there a reference for the various errors that appear listed in the log when one uses BinPBO to binarize an addon? Â Some are self-explanatory. Â Others are over my head, like: Error while trying to generate ST for points Error in statement: ar.SerializeEnum(RSB(pixelShaderID),_lod[0]._pixelShaderID,0,PSNormal) ....CfgConvertFileChng.exe returned error 1 very small normal Unknown flag AlphaInstancing What's really interesting is that everything works despite the errors, which says a lot for how forgiving the program is. Â But I would sure appreciate any help in determining how to eliminate these bugs.

1. Â I have not found a work-around to needing at least one symbol on the map to prevent the crash. Â So mark some other terrain on your map with the appropriate symbol. Â See: http://community.bistudio.com/wiki/Map_Symbols 2. Â Sounds like there is anti-aliasing on the edge of the colors in the mask_lco.png. Â Need to use pencil mode if you are using PS. 3. Â They are stored in the *.hpp file in the folder with your .wrp file. Â There is supposed to be an "include" command which goes in your config file which brings this data in. Â I simply copy and paste it into the config file. Â Check my Schmalfelden source files. 4. Â Look in the config file and delete the lines associated with the runway and ils. 5. Â The unbinarized pbo files of the 3rd party objects have to have the same file paths. Â See the "opx" thread in this forum. 6. Â I can't remember the fix other than reinstall V3. Â Do a search of this forum and you will find answers. Â Just make sure you change the default "search from" to "the beginning".