zodd

Is the torrent download functional? Downloading (and seeding!) now but dont want to do the whole thing if it is corrupted

Taking off from outskirts and flying over the map FPS - Low - 25, Ave, 29-30 View: 8670 Object: 4290 Shadow: 100 i5-3570K stock 3.40 3.80 8gm RAM GTX Titan Arma 3 version - performs fine. A fair bit of flickering of buildings (LOD switching? Glass disappearing etc) but runs very smoothly Unable to find where I fell through the building but the design (internally) was the same as the one IVO 0215 0335 - I have spent 20 minutes running around all the ones like that with no further falling through the floor so either possibly a tiny glitch or just one tiny area you have to be exactly in the right place... probably just an Arma-ism though. Key 'issues' in vid form In order 'Sticky' road Objects disappearing in footpath Building window LOD flicker (Note - not too bad here but compounded when flying overhead) Shadow flickering - oddly enough only on some directions apprently

Runs fine for me Issues: I found you can glitch through the walls on some buildings - walked up to a window at about hip height but then slipped through the floor on the inside of the building. Found it hard to replicate but around the gutters grenades sometimes get sucked into the footpath - This was a rare occurrence (for me at least) so probably low priority. Ideas: Glass - including tinted windows (ie. can be shot out but not seen through from outside) Doors that can be destroyed (in line with this ticket - http://feedback.arma3.com/view.php?id=3376 and this forum post : http://forums.bistudio.com/showthread.php?130731-How-to-make-a-door-open-when-it-is-shot-or-recieves-damage ). Might be harder said than done. Overall looks very nice, zero performance issues but sometimes the ground felt a bit 'sticky'... like the physics surface was slightly below the model?

Gday all, Does anyone know of an elegant way to have an AI wounded and unconscious, able to be dragged and loaded into a vehicle? I am working on a mission that involves some CASEVAC aspects and it kind of relies on that... Worst case scenario, is it possible with a human player? I have looked into setUnconscious but that doesnt seem to be working in A3. A lot of the respawn/revive mods allow dragging etc before revive but cant load into vehicles. Basically this: https://dev-heaven.net/issues/8651 (ACE for OA feature) but with AI. Similar Qs http://forums.bistudio.com/showthread.php?74373-Load-wounded-soldiers-in-a-vehicle http://www.armaholic.com/forums.php?m=posts&q=15458 I am hoping there is a (relatively) simple way to do this that is MP friendly. Otherwise I guess it is rip apart revive scripts, addactions and public variables? Solutions/Hints/Thoughts etc appreciated!

Sounds great! Hanging out for it (haha nice teasing eh)

Just one more saying this is amazing - It is phenomenal how big the difference is and you have done really well lining it up in the demo to where the vegetation is... Really a pity BI doesnt run with this (or support you in it) Only thing I noted is the roads fading may be a bit of an issue - I originally thought the texture was covering the docks (southern side of airport) but as I flew closer I saw the road fade in - Is it possible to have the roads overlayed? You really want to be able to identify the roads/tracks a bit easier I think (only noticed it in the airport area) Awesome work overall... Wish I knew enough to be able to help you out - for now I am one more supporter though.

I would like to add another vote for Australia... pastor399 mentioned outback Australia and Scarecrow398's post touched on the north too... I think northern Queensland would be a good option - There are areas where the 'rainforest meets the reef' and around the cane farms it can go from jungle in the mountains, to cane fields and farmland on the flat to good old Aussie bush. Overviews http://www.qhatlas.com.au/sites/default/files/images/Cane%20fields%20and%20Pyramid%201954.preview.JPG http://www.starfieldobservatory.com/MapletonTramway/aerials/12a.jpg Mountains (Not quite jungle but you get the picture) http://farm5.static.flickr.com/4034/4391856140_bdc416ee6a_b.jpg Which lead into flatter terrain http://blog.queensland.com/files/2012/05/Central-Queensland-lakes.jpg Some scrub down low, mainly along the water lines http://4.bp.blogspot.com/-CXukRTVLdPQ/T-MADIuYGwI/AAAAAAAABW4/SLwME9qetFE/s1600/australia+etc+2012-+Cape+York+2+048.jpg Cane farms are big - Built up areas without being full MOUT http://www.rawfish.com.au/images/queensland-sugar-cane-farmers-australian-made1.JPG http://econews.com.au/wp-content/uploads/2012/02/sugar-cane-farms-queensland.jpg Extremely restricted visibility and movement, even to dismounts when fully grown - http://resources0.news.com.au/images/2013/06/17/1226664/809880-44e36914-d6cc-11e2-ab0c-29cd98e6adfc.jpg Much more open early in the season http://static2.bigstockphoto.com/thumbs/2/2/9/large2/922940.jpg (Unsure how difficult it would be to create two versions of the map - wet season and dry season one? But would REALLY mean weather/season affects gameplay) A quick duck into 'town' http://www.gdaypubs.com.au/images/photos/large/towns_44907.jpg Sparser vegetation out further http://metroworld.com.au/images/property/487/7030.jpg Leading into the desert http://blog.toyotires.com.au/wp-content/uploads/2012/08/Image-3.jpg https://www.hemamaps.com.au/en/Explore/4WD-and-Touring-Information/Location-Profiles/~/media/979B9DBEE17547129B2E9656DADA367B.ashx And on the coast - the reef! http://reefcatchments.com.au/files/2012/12/DSC01164-1024x684.jpg Now those pictures are taken from all over but gives a bit of an idea the terrain that can be within reasonably close proximity. Allows you to incorporate all aspects too; naval/diving off the coast, a dirt strip runway and you are good to go.

Ahhh worked great - thanks!

Old thread but does anyone know what the classnames are? I am trying the following: removeHeadgear this; this addItem "Kio_Santa_Hat"; this assignItem "Kio_Santa_Hat"; (tis the season!) I have tried others (using the names from the config.cpp) but no joy either. Mod is loaded no worries. Anyone have any idea on what I am doing wrong? (Or any other ways to get them in game?) Cheers!

I love this mod, as not only is it a bit more realistic, it is much more streamlined then the standard map cocoon you are normally in when referring to your map in Arma. I was looking at this to support an artillery mod where you send the grid ref (as opposed to clicking on the map) but have hit a bit of a snag... I originally thought the the grid lines are wrong from this: https://dl.dropboxusercontent.com/u/74159983/Arma3/TAO%20Map/TAO%20Map.jpg According to that screenshot, I am in GS 017 068 Also note - It goes from 069 to 080 The actual grid is 017 058 https://dl.dropboxusercontent.com/u/74159983/Arma3/TAO%20Map/BIS%20map.jpg What I have discovered from Altis and Stratis testing is (I believe) the numbering is actually accurate, it is just the font use means that 5 looks like 6 and 6 and 8 are quite difficult to differntiate (especially on the fly) https://dl.dropboxusercontent.com/u/74159983/Arma3/TAO%20Map/TAO%20Map%20numbers.jpg I havent seen anyone else report this issue so not sure if it just me or noone else has noticed... Is there any workaround for this at all? Or is it just me? ---------------------- Also - side note about the map v tablet version. While tablet style versions will no doubt be in use, the paper map will never not be used; it is cheap to mass produce and can be easily folded down and tucked into a pocket. Tablets offer more power for but the infantryman on the ground, the old paper map cannot be replaced.

How hard would it be to make a script based version of this? Would it be easier if there were no spawned AI?

Smithy. The standalone scripts you specify the airburst height, explosion size, shrapnel details when you call it so if you wanted to use those scripts alone for your own missions - most definitely. It also comes with preset shrapnel options but if you are willing to get a bit maths'y you can customise the shrapnel a fair bit too. For this mod specifically, it is up to Drongo and how he wants to implement it. Drongo: For the way you are running it I think you would need to use a public variable. If you wanted to set the airburst height for a specific fire unit type you might be able to have a public variable (constant) in init.sqf for each specific type? I am assuming your AirburstFire.sqf script (or a subordinate one) checks for fire unit type and assign the EH based on which unit type it is? If so you could have the airburst height specified in init for each unit and just refer to that. eg. fireUnitAirburstHeight[0] = Mortar fireUnitAirburstHeight[1] = 155mm Arty fireUnitAirburstHeight[2] = 230mm Arty Then in your assignment part of the script, when you determine the unit type instead of using the hardcoded value, you use the relevant array reference. As it is a mod rather than collection of scripts, you could check in the init.sqf for those values first, otherwise use the hardcoded (that way if a user wants to specify his own values, he can specify them in the init.sqf ?) Its late and I havent had a look through how you have done it so will revisit this tomorrow if it is not applicable!

Gday Thanks for the prompt reply! Like I said - far from a war stopper but thought it might be worth mentioning. Makes sense - I was using a lot of closer range artillery hence the longer splash delay I suppose. When calling via the support requester it gives the ETA prior to firing as is - even if it the pre calculated ETA isnt exactly spot on, ETA-5 seconds after firing first round would be a pretty good solution (And in line with reality!) Understood it might not be as simple as that behind the scenes! Cheers again!

I was working with the fired EH and tracking projectiles for some scripts I was working on and noticed that the "Splash" call is actually being called at the peak point in trajectory (ie. When the projectile's upward velocity peaks and it starts heading back to earth) Splash should be called approx 5 seconds prior to the round impacting - unsure if it was a misunderstanding or just a quick implementation by BIS (or other). The artillery computer tracks ETA so I would think it shouldn't be too hard to just have the splash call come 5 seconds prior to the first round impact. Far from a warstopper but something that could potentially be an easy fix?

Not sure - every time it was called exactly at the peak of the trajectory (regardless of range/platform/AI or player fired etc)

Airburst/Shrapnel preview

They are the same as normal topo maps - you make it more accurate by dividing each visible grid square into 10x10... if it is in the grid square 44 66, you know that 445 665 is right in the middle of it, 445 669 is middle top etc (ie. you should be able to fairly accurately (with practice) get 6 fig GR by visual alone.. That is when you are zoomed out fully and have 1km grid squares... Add to the fact when you zoom in with the mousewheel the grid squares become 6fig (100m square) instead of 4 fig, it is quite simple to get accurate 8 fig GR - 8 fig GR corresponds to a 10m square on the ground, accurate enough I reckon.

For weapon ranges: http://forums.bistudio.com/showthread.php?169847-VTS-Duck-Hunt

Yea - I guess ideally too it could be customisable (amount and accuracy/inaccuracy of information etc) Numrollen - refer to above for my thoughts why... I think its a great idea

I disagree with the above - The quick check (as I understand anyway) doesnt tell you exactly what is wrong with them - just the basics that you may reasonably be able to determine in reality. I find it a lot easier to tell in real life if someone is not conscious (unconscious or dead) or has a major injury (significant bleed, traumatic amputation, etc) than in this game... As long as the quick check only gives generic information I think it is good. Until graphics and in game perception match reality, we will need workarounds or will just not have the same level of awareness. I see it as a limitation workaround (no different from having someone's name flash up when you look at them and to a lesser extent, something like shark tac HUD). That said - if it is unerringly correct and detailed every time, I do agree with you.

This looks great and I think the quick check idea is bang on. In reality you can determine a lot more than you can in this game, I think the quick check (with the LOS check), assuming it gives you generics (and maybe an inaccuracy/error percentage) is a good way to cover the gap between game limitations and perceptions available in reality (eg, blood pools, not responding, obvious breaks etc) With regard to the treatment/revive, is it possible to define the time it takes? You mentioned the 'death' countdown is modifiable but is there scope for a more "arcade" version and full realistic version? (ie. can you complete treatment in 30 seconds?) Looking forward to a public test - I am keen to get this in missions on our server.

Quick airburst demos: Mortar airburst 10m 50-50 mission - Mortars (gnd) and Arty (airburst) (Sound a little buggered on this one) Check pm for info

I am referring to the accuracy of predicted v adjusted fires. The closest thing to hard data (unclass) for you that I can find is this: http://www.dtic.mil/dtic/tr/fulltext/u2/a221243.pdf (Study incorporating adjusted and predicted fires accuracy) The inaccuracy I was referring to is the first round accuracy- When you send a grid for a fire mission, the data is calculated based on all available information (charge info, met data etc) but it is only an estimation - therefore the first round can land some distance from where it was predicted - subsequent rounds will land close to the first one but the adjustment process is used to bring the rounds onto the target (ie. adjust the firing data to make up for the effect of all the unknown/unconsidered variables). That is why you fire one round, send the adjustment, fire another round... repeat until it is on target THEN fire for effect (ideally...) Basically not too dissimilar to zeroing rifle optics - bold adjust (predicted) followed by firing rounds to get it perfect (adjusting) eg. http://www.hardscrabblefarm.com/vn/artillery.html Different platforms will have different first round accuracy - eg. Mortars firing at close range will have the first round land a lot closer to the initial target grid than NGS (Naval guns) firing at longer range. The issue I have with the arty in A3 is they always fire right on the target. Whilst individual rounds have dispersion, there is no first round inaccuracy therefore no requirement to adjust fire. The other benefit of adjusting fire is regardless of whether it is AACFF or the FO calling it in, adjustment is still required! WRT The sheafs you are referring to - not something I have much familiarity with - Fire mission types (point, linear etc) are all you really need to know on the ground - the arty blokes will work out the guts of the details based on the target you send so cant really help you there. (Is it something that is required for gameplay or is it something that can be done behind the scenes instead? Comes down to previous question - What is the scope you want this module to do/simulate?) Will PM re: airburst etc.

I did something (kind of) similar for A2: http://www.armaholic.com/page.php?id=16625 V2 never ended up being released but i have it somewhere - works with multiple batteries, airburst etc. The big thing I wanted to bring in was the requirement to actually adjust fire - First round impact from 100-200m (Mortars) to up to 600m off for NGS from memory (different rounds have different defaults; can also specify own fire unit with munition type in editor with initial round accuracy, FFE #rounds and splash radius etc). The bit I liked about it is you have to work for your effect - it isnt just work out the grid and send the rounds dead on target. Adjusting fire is kinda redundant if first round accuracy is dead on eh... Pretty simple, basically just: GR for initial call - add large random offset (initial round inaccuracy) and set target point to that position move target point L/R/U/D based on FO input I dont have time to do it any more (at this stage anyway!) but I think it would add a lot if you worked that in too (re: argument of reality v fun; it actually adds challenge to the FO role without being super difficult - means the FO does a job instead of just being the messenger boy to the gun line)

Gday all, I am running the following script to set a waypoint: AddWaypoint.sqf _groupToAdd = _this select 0; _waypointLocation = _this select 1; _wp = _groupToAdd addWaypoint [_waypointLocation, 0]; _wp setWaypointStatements ["true", "_groupToAdd setVariable ['FinishedMoving', true]; hint 'Finshed now'"]; _wp setWaypointType "MOVE"; I get the Finished now hint but when I check the finished moving variable it is still false. Extract of script calling the function: Any thoughts on why this isnt working and how I can get it to function? Cheers all!