Rommel

{(vehicle _x) setfuel 1} foreach playableunits This may not work in SP. It was designed to be played in MP. You can just set up a LAN server. The best reason is the fact that you can die quite easily if you go to fast. :p If you must use SP, just change playableunits to switchableunits, and you should be fine.

To help show how its done (not my best though) : zky_cxsAYpM

I originally got a burnt copy of OFP from my mates, we all played it a LAN once, and I was hooked. I then went out and bought the GOTY edition; and haven't looked back since; getting ArmA1 on the day it came out, it was in German :P; then ArmA2 the day it came out (if not before hand?); and Arrowhead a few days before it came out (review copy), as well as two copies thereafter. I think it comes up to 7.5 years that I've been playing now... ;)

Outpost BASRAM - Multi-Session Operation by Tank Commander

Sqf 2 Sqm - File Converter (v0.7) Project Page Documentation Issue Tracker Download(6KB) FAQ What is it? It is a Ruby script program run through either Six Updater or the stand-alone Ruby interpreter to convert Sqf files from the 3D editor (accessed via Alt-E in the main menu) to Sqm files which can be accessed from the default ArmA 2 mission editor. It is currently in beta, units are not supported for conversion, nor triggers or markers. But they will be soon. How do I use it? Best read the documentation, it has lots of pretty pictures to help you through, I won't be assisting people with already-answered questions. Either read the thread or ask another community member. It doesn't work? If you have any serious issues, post them on the issue tracker provided below, as so far as it has been tested without any issues. Please provide your mission.sqf file and the output mission.sqm if possible. The window disappeared straight-away!? This means you are either: missing files, installed incorrectly, edited your mission.sqf file so it is no longer compatible, or BIS have done a sneaky on me in which case you need to post an issue on DH.net so I can fix it. Credits Thanks to Delta51 for asking for this, while I was drunk, Sickboy for pushing me to learn Ruby, and pointing me in the right direction (most times), and Ordeal, DMC and Hooves for putting up with me.

UNSUNG

So what happened. :confused:

A recent screenshot from before a 40 player JO, it was later likened to the photograph below. Sorry for the poor quality, I was trying to keep my FPS up for the play; not expecting such a great pic. :rolleyes: http://blogs.amctv.com/movie-blog/hot-shots-560.jpg

Same result, different config value :P, either way, the concept remains the same. As long as that value is consistent in addons; all is good.

Nevermind ---------- Post added at 02:25 PM ---------- Previous post was at 02:19 PM ---------- _pistol = {if (tolower(getText(configFile/"CfgWeapons"/_x/"nameSound")) == "Pistol") exitwith {_x};nil} foreach (weapons player); if (isnil "_pistol") then {hint "no pistol";} else {hint ("you have an " + _pistol);}; Since they all inherit from the pistol class. :rolleyes: Thanks to http://browser.dev-heaven.net/cfg_weapons/config/glock17_EP1?version=27 for allowing me to find a value that was inherited from the pistol class, and pretty much is consistent with ALMOST ALL pistols. Tested with all OA pistols.

To help the new guy, might want to let him know that the isPistol function should be declared before the main script is run. ;)

I've noticed a lot of people do complex IED scripts, when really, the simplest and best (from my own experience) is having actual AI detonate a satchel charge on the road. It has the best 'average' stopping power, not always killing, but not under powerful either. It can be stopped by killing the suspect who planted it; without any scripting. It has to be planted during game play. Giving two elements to an objective. Attached a mission on how this can be done. ;) http://dev-heaven.net/attachments/download/7928/ied_example.Takistan.7z

Hehe, I don't question what people who have specific situations or requirements want. But I'd say 99% of the mission makers who don't have those requirements, would prefer something simpler. Such as this example. ;) I'm not vindicating those who use more complex solutions; simply saying this is an easy one for those who are looking for an easy solution.

No. You can do some interesting things with the description.ext, but you are not AFAIK able to load external config classes that are not defined prior to the mission. If you want to use different flags, why not just place all the textures in the mission folder, then use them that way?

Could you be a little more explicit. Are you implying that both Chernarus\Takistan etc is missing, and henceforth your missions also? Check your profile folder to see if you haven't lost it all. As to the maps... well, check your Addons and Expansion\Addons folders. :rolleyes:

You should NEVER have put custom addons in your addons folder... and if your running ArmA2 Dependant mods, of course they won't work. :rolleyes:

WHY SQS?!!! Oh the horror

Yes it is possible. Special usage of select player command on a newly created local unit. On my iPhone ATM but let's see how I go... Run this script in a killed eventhandler. _group = creategroup resistance; _unit = _group createunit ["classnameofunit", getmarkerpos "indespawn", [], 0, "NONE"]; selectplayer _unit; add a private statement in too. You could modify that to give the effect of 'replacing' another unit. Or you could change the locality of a unit via groupings and then switch the player

Haha, cars take it down, tanks don't... thats ridiculous. :P

Perhaps it loads the A2 content still because it loads the 'Addons' folder, like I said, move that and the 'Dta' folder out of your ArmA2 directory (perhaps to ArmA2\Tmp) and load the OA exe. This is how I disabled my CO until I decided to just get rid of it. :p So far all I miss from CO is the M4s...

Correct, lets presume your trigger fires off on an OPFOR Not Present. The trigger has an OPFOR man at the start. Lets look at the following (common) case. As long as that trigger condition is still true, (ie OPFOR not present), then it will fire the onAct for the JIP. If another OPFOR man has entered that trigger during his reconnection, then it will not fire off, as it is not true. If you want it to go off regardless once it has done it once, then you need to setup a way for the server to tell clients that, this can be done by two triggers, one with the briefing and the original OPFOR not present. I updated the example mission for you so you can see how to do this. For more information on how to updating tasks, see the following: http://forums.bistudio.com/showthread.php?t=73424 Especially the taskhint function found in a link in that thread is very useful. :rolleyes: Again though, the point of this is simply to ease the creation process, updating tasks/briefing remains the same. So if your reading that thread, and want to use this (simple) system, start reading from 'other commands' onwards. OTHER GOOD INFORMATION: http://www.kylania.com/ex/

"C:\Program Files\Bohemia Interactive\ArmA 2\arma2OA.exe" -world=empty -nosplash -mod= According to BIS, this should work.

My best suggestion (I did just write up a script that allowed for task dependencies, but it was too linear), is to simply write multiple task.sqf files, naming them maybe taskset1.sqf, taskset2.sqf, and then executing them at different times (perhaps via triggers), obviously it depends on how dynamic your mission is, if your doing something more complex, then perhaps it may be better for you to spend the time making it yourself. This does not and isn't made to handle the UI or the handling of tasks past the initialization.

As far as stability goes, ALICE2 module has lasted in a mission for over 4 days, without causing memory issues like the ALICE1 (non-OA) module did.