Chill xl

This map, inspired by the afghanistan mountain region ToraBora, is 100 square km and has altitudes ranging from aprox 2000 to 2750m. A remote and barren outback enviroment. The base of the map is the heightmap of my previous project Aiaktalik, altough reworked, tweaked and modified. The overall height of the map is reduced and roughened up. Also the sat map is completely redone to suit the Takistan textures i've used from OA. Furthermore all objects used so far are all from OA aswell, rocks, trees, bushes etc. This Sandbox Edition is the first release of this ToraBora map. It's not finished yet, roads and more human features should still be added. It does however offer mission makers a sandbox environment to build upon. Mission makers could add outposts, bases and even villages with the appropriate modules like RTE etc. Apart from the vast humanly untouched terrain there are this time two villages to be found. Download: The map is available on the excellent Six Updater Platform by Sickboy. (Check out the Six Updater Portal Site for the latest update, version, size and changelog information!) (Use this link to auto add it to the dynamic preset in six updater: sixupdater://mod=896a63c6-0dca-11e0-af75-001517bd964c FoxHound kindly published it on ArmaHolic: http://www.armaholic.com/page.php?id=12969

Altough i really like the floating zone concept and even the "feel" it gives ingame i have to admit i'm going back to a disabled freeaim. I'm kinda stuck in between, i love having the ability to aim / move your weapon "free" from your bodymovement but the way it's implemented and works together with trackir it doesnt allow me to aquire targets and engage them very quickly. Also moving around feels clumsy because without a crosshair its hard to notice what direction your body is facing. Because of this i moved back to a non-floating zone, that feels kinda weird atm too and makes me realise that freeaim is for sure the way to go, if it's implemented differently... Freeaim basicly means aiming freely from your body movement, which are usely tied strict together. When playing a FPS with freeaim you basicly have 3 parts that need / can be controlled: * Lower body (movement or main direction) * Upper body (aiming) * Head (looking - TrackIr) Atm, using a floating zone in Arma basicly means your aim is unlocked from you overall direction when inside a specifc area in the middle of the screen, once your aim outside this area your aim will be tied to your direction and you will be controlling your movement. Also the "look" direction is derived from your overall direction. In practise this means your overall movement is disabled untill your aim is at the edges of the screen, also your looking will be affected by the overall movement. All together it gives a unpredictable feeling... I think freeaim would work better when the main direction and look direction would be 3 controlled parts would be derived from your aiming direction or upper body. I think freeaim should be "inside out" so to say. Instead of moving your weapon freely on the screen it should stay fixed on the screen asuming you are looking straight ahead. In real life a soldier would keep his eyes / head close to the weapon and use this combination to look around, in other words, the weapon is always pointing where the soldier is looking unless his looking away from the weapon / around. Aiming / "moving the whole screen" a certain degree away from your overall direction would start to affect the overall direction or in other words your body starts to turn. This way the floating zone isnt affecting the aim but the movement. Hope you understand what the idea is all about, to make it more clear you can experience it in real life. Imagine your holding a rifle and aim it. Your hands would be somwhat in front of your head, and you will be looking over your hand with one eye. To look around you will move your head and upperbody together keeping your hands in place in front of your head. (Aim and look tied together). Move around, you will noticed that to turn, you actually use your upper body to give direction to your lower body. Looking around (like with Trackir or freelook) doesnt affect your upper and lower body. To aim in a different direction as your direction of movement is, doesnt mean you move your hands away from your head. You will use your entire upperobody and head to aim in a certain direction. Arma does this the otherway around and therefore feels weird to me...

My best advice would be to plan as much as possible ahead and just really start building the map and positioning objects later on. Photoshop would be your best friend, design the map as much as possible there and do it in such away that specific areas are easily selectable. Paint roads, urban areas, forests in different layers. Use these layers to make or add to the attribute and sat map, also use these for masks and backgrounds to be used in visitor and bulldozer.

It seems as if you have imported a heightmap picture into L3DT with a anti-aliased border and kept workgin with this "faulty" heightmap data all along. Anyway the outermost pixels where / are not matching the rest of the heightmap. To ("easily") fix i would do the following: Export the exact same / latest terrain (from l3dt, unless you have editted your terrain in Vis, then you need to export from there) to an heightmap png (perhaps you already used this in png) Import this heightmap png into photoshop and investigate the bordr of the picture, you should notice a distinct border that represents the lowered terrain (more or pure black around the edges). Figure out how much pixels this border is (how many pixels of the edge are not matching your terrain). Now first select the first row of pixels from the top that is "right", transform this row all the way up to the top edge of the picture. (you have now repeated the last "good" pixel row to the edge of the picture and thus removed any "faulty" heightmap data). Repeat the same for the other edges. Now the only area's the might need some specific attention are the corners where two edges meat each other, these might need some correction. You could make a transistion in Photoshop or do it in L3DT (export and import you "repeared" png as a heightmap in l3dt) The above procedure might give a slight "synthetic" look to your map at the edges, as there are several rows of the same heightmap data next to each other, but it is by far alot quicker then to repair it with l3dt by hand...

Haven't played Arma for ages, but after i saw some footage of your map i just had to login and send a message. Your map looks very impressive, great detail and it definitely "fits" my taste for maps. Thanks for your dedication to make this map! Chill out :)

Pledge 15 and get the game dead cheap! If the project unfortunally does not make it you get back your 15 dollars, nothing to loose and a great game to gain.

i think that would work, i was able to get a new formation class in but because the command menu was not adapted i couldnt make easy use of it. From my recent testing i believe the index numbers in the pattern section are relative to the current iteration. Each iteration of the pattern starts with a negative index nr that points to a previous (unit placement) and uses that as reference to place the new unit. So a negative index number, lets say -3 takes the third last unit placement as reference and positions the new unit with an offset to this one. The fixed section always starts with -1 and i'm fairly sure that has to do with the (odd) behavior when for example a vehicle is attached to the group. For some reason the vehicle is prioritised and based on the crew ranks either positioned in the group before or right after the group leader. Before would mean the vehicle has group number 1 and will take the -1 position of the formation and the leader moves into the 0 position of the formation. When the vehicle is right after the group leader in the group (number 2) it will take the 0 position of the formation where the group leader assumes the -1 position of the formation.

I'm trying to figure out how formations (collumn, wedge etc) for groups are configured / work, with the intent to modify them (if possible). From the Armaholic site i've picked up a message that these were set in config file (for OA), i believe KJU pointed into that direction. However i cannot seem to find the right files / pbo's that hold this information. Could someone help me out where i can find the configs or scripts that describe how formations are formed? Is it (at all) possible to mod formations? Thanks in advance :)

Thanks alot, you got me right into modifying formations! (Not sure yet how to add new ones, but that for later) Creating a formation is not that easy because it is highly relative and has no relation to roles only to unit number in the group. What i've dicsovered so far is that fhe formation formula describes where a unit goes in order of their number and relative to the previous unit position. First it places the formation leader (-1). The formation leader is usually also the group leader but often when a vehicle is involved the vehicle becomes formation leader. Then the second unit is placed using a x/y or x/z offset (-1 means 10 meter to left of the previous). Each unit can also be placed with an angle, this angle is relative to the group-direction and becomes "active" when the group is holding or stopped. FormationPositionInfo: {index number, X (side to side offset), Y (front to back offset), angle, unknown}. Negative X moves to unit to the left, negative Y moves the unit to the front. The last param is only used with delta or compact collumn, not sure what it does. Anyway, in my first attempt i've managed to create a squad collumn (US Army) where the first 4 units (fireteam 1) are in a wedge in front of the Squad Leader and the last 4 units (fireteam 2) are behind the leader in a mirrored wedge. The result is great apart from the AR being on the wrong side (because by default the Grenadier is listed before the AR). However when units are differently listed / ranked, the overall results are the same (unless a vehicle is involved which messes up alot) but the fireteams are scrambled all over the squad. This is apparent for example with the USMC squad which has a totally different group layout as opposed to the default US Army layout (OA). The Army (OA) layout which lists by FT respectively and the default USMC lists units by ranks (first the FTL's, then all the AR's etc). I think to get a more consistend formation result i should provide new group layouts that use the same placement order aswell.

Thanks for response, however i'm not using any software to modify the game executable.

i get the same error and im getting constantly kicked off the server. "Battleye: corrupted memory #3". What can be done to fix this annoying situation? Battleeye 1.148 OA 1.60.87580

not sure if my message should be here, but its battleye and troublshooting so here it goes: im getting constantly kicked off the server. "Battleye: corrupted memory #3". What can be done to fix this annoying situation? Battleeye 1.148 OA 1.60.87580

im getting constantly kicked off the server. "Battleye: corrupted memory #3". What can be done to fix this annoying situation? Battleeye 1.148 OA 1.60.87580

Great job m8, interesting location you have chosen. Nice progress screens, looking really good. The sea that shines trough comes from the tides which are rendered at a just above sealevel (0m-1m height). Basicly the tides are not completely level with the water rise a bit above and land is not taken into account. Which means that water, sea and tides come up when the land level is at or near sealevel (0). Only way to solve is to raise the whole land by 1-1,5m. My map, torabora uses a 5m cellsize and i believe not many have performance problems with it. I have a few map projects around that are on 3m and 4m cellsize, after i tested with a 1m cellsize. 1, cellsize is very tough but i believe a 4m cellsize should work pretty good for most and give nice detail to the map. I really like the small cellsize maps, the detail in the surface with small bumps and dips are really great for infantry fights. Keep up the good work :)

wearing opposing forces uniform is one thing to not be detected as enemy, behaving like friendly should make the difference. Meaning, running around should atract attention, hanging out around vehicles, high value targets, etc should attract attention... Too much attention and you will be discovered / revealed as enemy. Take the video for example, the guard in that tower thingy close the vehicle could have seen you around the boats. When "suddenly" the boats explode it should raise suspicion towards the player who was there, especially if you jump into a vehicle drive off without saying 'bye'. Anyway, in short to be undetected one should act as "normal" as possible. Hopefully behavior will be take into account.

Hmm, no not exactly... I do realise that TIR makes it complicated since headposition is involved, lets keep that out of the suggestion (for now) and focus merely on the freelook part. My idea is not to slave, but more "aimed" at what happens when you end the freelook "session". Releasing the freelook key, the look "rubberbands" back to the direction the body is facing. Often this is what you want, except when you spot a target on your flanks... Then you want to set the body direction to the direction where you were looking so you can aim at the just spotted target. In this case, the body should "rubberband" to the direction of look. An idea would be to use the "bring up sights" (often RMB) function to end the freelook session and set the body direction to the direction of look. The weapon will then be raised and pointing towards the target without the need to reaquire the target by moving the body back to where you were looking.

I would like to see the freelook (trackir or key / mouse) reworked a little so that one is able to also set the avatar in the direction you were looking instead of returning to body direction. Possibly two functions were you eirther return to the direction the avatar's body was facing and to set the avatar's body to the direction it was looking. The first function is currently present, the second is not (not to my knowledge). I believe the latter could be very handy, especially with TIR, to engage targets that you have seen on your flanks. With the present system you first need to return to the direction the body is facing and then you turn the avatar and re-acuire the target losing precious time... Humans tend to go where they are looking, focusing on a direction, point or target. I feel currently arma is the other way around...

just replace the tree objects with the same tree model but before doing so, first enable the random orientation and size parameters in the object parameters.

i always give the idea / visualisation of a cloth draped over a square, on that square are sticks distributed evenly on a grid that hold up the cloth. In this, the cloth is the surface and the length of the sticks determine how high the cloth is being held to form for example a bump or hole. The more sticks you have dsitributed over the grid, the more detail is in the surface. My map consists of 2048x2048 "sticks" to hold up the cloth, the sticks are spaced 5 meters apart from each other making it a 10.2 x 10.2 km/2 map.

awesome work as always shay!

I would like to see the compass being used ingame like a "real" object somewhat similar how weapons are used and not as the current "overlay" thing. Meaning, when you want to use it, the avatar slings or holster the current weapon and "pulls out" the compass and holds it infront (like a weapon), i would like to see the same for the map too.

retorical question... of course you will buy A3. I cannot imagine that, after buying A2 /OA and possibly its ancestors that, that one decides nah... i'm gonna skip this one. Nothing out there within it's league. You either are into these games / sims and you need to buy each version or you are here on the wrong forums to begin with.

I have had some occasions where the same happend, in visitor it all looked good but after binarizing and ingame the whole terrain occured to be white. Some research wat actually happend during binarizing showed me that the rvmat files (also located in the layers folder) werent copied to the bin temp folder to be binarized. This was due to a bad config file that for some reason stopped the binarize process from copying those files. You could check the bin_temp folder and see if the project there has the layers folder with all the appropriate files and thus if the files are actually copied...

Latest version (1.6) available trough the awesome six updater by sickboy. Some of the changes in this version: * Improved config (tnx to PvPScene) * Tweaked sat / mask map (big yellow dry grass fields are gone) * Two caves added in the west of the big mountain (Ai doesnt like them unfortunally...) * Propably more but i forgot :D Edit: v2 signature signed (tnx to sickboy) (Use this link to auto add it to the dynamic preset in six updater: sixupdater://mod=896a63c6-0dca-11e0-af75-001517bd964c

@Pandur, i'm not aware of this issue. Let me put upfront that i'm not familiar with blastfx, atleast not how it works, maybe theres a dependancy of this mod towards maps? I think you better notify the creator of blastfx and see what he says of it... @BoroFootball, we have and i believe many others succesfully used this map, placing / spawning units in mountains and in and around towns. Not sure what could cause this and if it is caused by the map. However, there are some config issues with the map that might be problematic. PvPscene has been so kind to provide me with a better version, this and some minor changes will be available in a new update of ToraBora very soon.