Bon

Hi Uhpam, glad to see you joined this great community. First post for me since, well, feels like forever - had a lot of stuff going on in 2012. Apart from this... ...and regarding your question: The variables tfor_advanced_*_funds define the funds available to your team, so setting them to 0 would make you not being able to request any special vehicle anymore. A natural way seems to be to reduce the costs for a vehicle to 0, but I just checked, this I did not make generic (the costs for a vehicle are always 1, period). So why not just setting tfor_advanced_*_funds to a very high value, lets say tfor_advanced_vehicle_funds = 9999; tfor_advanced_aircraft_funds = 9999; That should do the trick. Also make sure you select "Advanced Aircraft/Vehicles Available" in the mission parameters. hf.

Try this: _grp = createGroup tfor_friendly_side; _pilot = _grp createUnit [tfor_rescuepilot_pilottype, _pos, [], 0, "FORM"]; ... if((count _houses) > 0) then { ... }; [color="#0000FF"]_pilot2 = _grp createUnit [tfor_rescuepilot_pilottype, position _pilot, [], 0, "FORM"];[/color]

Are the units you're using capable of using OA backpacks? To test, open the ingame editor, place a backpack on the ground and try to pick it up.

Hi psvialli, sorry but I can't reproduce. Tested with the current beta and all works fine for me. Hi Yokhanan, to me, there is nothing that justifies an addon dependency in my work. Sorry. But in case you succeed with adding it to the mission by yourself, don't hesitate to share it with us or send me a howto so I can put it to the wiki of the TFOR project page.

Hi Cetreen, many thanks for the hint. I can confirm this issue and was able to narrow it down to the playertags - basically, moving an "is alive" check in the code fixed the problem. Just in case you want to fix it by yourself until I get to release it here is the edited bon_playertags\playertags.sqf: Hey JuggernautOfWar, I am currently spending the very small amount of free time I have to prepare v1.08. It does not come with a lot of changes, however, it will make switching to ACE easier, specifically, simply by uncommenting a line in two script files. I am going to put for each edition a corresponding ACE version to the download list. Can't say when exactly, as some more tests need to be done, though. hf.

Hi failtolawl, guess you missed some of those evil camps. The camps are "populated" with at least 15 bad guys, that's how you can distinguish them from regular camps, and they can be located in a range of up to 1200m around the target area. Most easy to detect them would be having a commander to use the UAV. However, I am wondering if it would be best to drop this task for the next update - you are not the first one who reported being stuck on that task. Regarding to marking the weapons cache, well, there is no such mission task. If you mean marking the fuel dump you need to be within 25m to place the strobe properly. hf.

Try this: t = nearestLocation [getpos player, "NameCityCapital"]; _name = text t;

Look at this piece of code, I'm sure it'll give you the idea. You know that the access to the dialog is provided by an addAction command put into the init of an object. Check the corresponding BIKI article for the commands extended syntax, particularly for the condition parameter. hf.

Rather a shame to assume everybody plays with ACE these days. You should have asked for ACE explicitly. :cool: Anyway, added an ACE version of the Clafghan port to the archive. Didn't test it tho... download link again

I ported an FHW edit of the mission to Clafghan a while ago. You can download it here: CFOR Clafghan Camp Branca FHW edit The Clafghan map is awesome, vast, versatile with high mountains and deep valleys, a few nice locations providing an intense and authentic environment for certain scenarios. But be aware, it doesn't really collaborate with the TFOR mission, as for the mission the terrain is too bumpy and lacks of free and empty spots. hf.

In the "mini-insurgency" task, enemy units drop small objects, such as files, maps, which remain next to a dead body's position even after the body disappeared. All you need to do is walk over to them and hold for 1 to 3 seconds - then check the map. I admit, those objects may be a bit difficult to spot because of their size (would be worth trying out to replace them by fairly larger objects such as suitcases...). A trick that works great here is simply to disable the grass (at least temporarily). Also the objects tend to shine bright in both sunlight and NVGs. Nevertheless, I am going to add some detail to the task description. Regarding to the pilot telling you where the wreck is, that's a good idea. But is it really troubling you to locate it? Cannot remember a time we didn't spot it immediately.

+1. I really appreciate the effort. Rather going with time than holding on old stuff. But this new appearance... all I can see on the forum viewing pages are big, red rectangle icons. Please, at least give me an option to change it back for myself.

Hi, of course, no need to ask. I added a respective comment to the remarks in the OP in hope nobody ever would ask me for permission again. People who expect others to ask before using their stuff or have a certain policy regarding this issue should be banned from this community. :p As long as credits are given to the original author, all is fine. hf.

Hi all, @Armach Any vehicle already placed at the base (via editor) no matter what map, is only for atmosphere. So that particularly large bases don't look that empty. They are sort of "dead objects". They are locked and don't send any updates across the network. All vehicles you are actually supposed to use has to be constructed at the respective construction site. Regarding to the enemy precision thingy since 1.60, yes, I am aware of it and it makes me very sad. And I was playing with the idea to make general skill and precision skill of enemy AI adjustable, however, not all of the other skill types. My philosophy is to keep number mission parameters below 25. @Zuff Your problem is the WaitUntil command. Imo, it is a crime to have any wait/sleep/loop/whatever structure in the init.sqf. The file is to initialize scripts only (and setting variables etc.). One script requiring to wait for something else and thus delaying the initialization of another script is a no go (except for places you have to deal with locality)! So my suggestion is to either move all the mando init stuff into an own script and just call this script from init.sqf or move it to the very end of the init.sqf (below the endloadingscreen command). hf.

Imagine you want something to happen on the server machine when a player defuses an IED. Then you would have to uncomment the lines in defuse.sqf and extend the ied_defusion_handler.sqf with your code. For my mission I commented out these lines because I had no use for this feature and could save another publicvariable call. Btw, I updated the IED script available on dev-heaven.net. You may want to give it a look. hf.