-dead-

https://www.c4isrnet.com/industry/2022/03/07/bae-systems-buys-military-simulations-firm-for-200-million/ First up, congrats to BI on the $200million price tag for Bohemia Interactive Simulations! I does make me wonder how the separation of the two firms and the (previously) closely related products will affect the development of game side especially Reforger? Will the cash injection help fund it along? Has it been sold to BAE? Or were the two entities compartmentalised ages ago? I for one would like to know at least the broad strokes ...

They have 2 years maximum, but whilst the Divided Kingdom would benefit from a prolonged exit, it's in the EU's interest to make the divorce as quick and unpleasant for the DK as possible, so I'd expect it to take a lot less than that. I suspect there's not much the DK can do about the timetable now that it has lost all clout in the EU.

Ahhhh! That's where I was going wrong! I had a sneaking suspicion I was being a total retard, but I couldn't figure out how or where and there's quite a few changes from A2! So the code I really want is: _kites =[]; _grp = group (_this select 0); _blokes = units _grp; { _kite = vehicle _x; _kites set [count _kites, _kite]; } forEach _blokes; Tested - does what I want! Sorted! Thank you, F2k Sel for putting me on the right track! You're a star! Off to remedial arma scripting for me... FPDR

Has anyone had drama with units group <name of group> and named units? I had a quick squizz through this post, but may have missed it I just tried using this in the latest dev version on steam (as of 4-4-2014) with a group full of named units (Flight1_1, Flight1_2,Flight1_3, Flight1_4) and the array comes back with an extra "d" on each name, which renders the result both useless and annoying. Previously when called with nul=[Flight1_1] execvm "script.sqf", this code: _kites =[]; _grp = group (_this select 0); _kites = units _grp; would give me an array _kites that was: [Flight1_1, Flight1_2,Flight1_3, Flight1_4] now it gives me _kites as: [Flight1_1d, Flight1_2d,Flight1_3d, Flight1_4d], which means the array can't be used to point to the planes. The workaround is to use the code below to remove the "d" and rebuild the array: _kites =[]; _grp = group (_this select 0); _bites = units _grp; { _bite = [(str _x),0,-1] call BIS_fnc_trimString; _kite = call compile format [_bite]; _kites set [count _kites, _kite]; } forEach _bites; But it's a convoluted annoyance, and I can't really see the point of the "units" array messing with the names in the first place. I'm guessing it's a budvar related typo. Please fix!

Phew! for a second there...

My first impressions of ArmA3: *sigh* I knew it was going to be like that the moment I saw the Jack Bauer countdown graphic. :) Let's hope next time they do it like sensible people: give us a couple of weeks before the download to sign up and pay, then feed us our codes, then finally put out the data on steam for the Jack Bauer moment. Finally got a download code, so we shall see. 1/10 for the poorly thought-out release faff. But you can't have everything, can you? Where would you put it?

_center = createCenter sideLogic; _grp = createGroup _center; if ((isNil ("DAC_Extern"))) then { DAC_Extern = _grp createUnit ["DAC_Source_Extern", [721.40936,1458.551, 0], [], 0, "NONE"]; publicVariable "DAC_Extern"; }; // Setup for West & East group reduction points (change coordinates for your mission) if ((isNil ("DAC_Pos_W"))) then { DAC_Pos_W = _grp createUnit ["Logic", [7083.2246,5390.5181,0], [], 0, "NONE"]; publicVariable "DAC_Pos_W"; }; if ((isNil ("DAC_Pos_E"))) then { DAC_Pos_E = _grp createUnit ["Logic", [-2799.2734,5066.0713,0], [], 0, "NONE"]; publicVariable "DAC_Pos_E"; }; I've just started trying to do the exact same thing, but so far haven't got around to testing it in anything other than the standard mission editor preview, so all I can say is that this does work without a headless client. Note: the positions in mission.sqm are Above Sea Level [x,z,y] but in createUnit they're Above Ground Level [x,y,z] so you should switch the positions around and set z to 0. Otherwise stuff will spawn about 30m above ground, which is not too good for the troops!

Ugh .cpp files! :butbut: they make my head bleed. :o OK so as far as code goes, it all seems OK, with one questionable thing: -- Any reason why the "works on vehicles only" call - class Extended_PostInit_EventHandlers { WarFXPE_PostInit = "[] execVM ""WarFXPE\ParticleEffects\SCRIPTS\init.sqf"";"; }; isn't done like this: class Extended_PostInit_EventHandlers { [color="Red"]class WarFXPE {[/color] WarFXPE_PostInit = "[] execVM ""WarFXPE\ParticleEffects\SCRIPTS\init.sqf"";"; [color="Red"]};[/color] }; Maybe the vehicle effects work when it's not called from inside a "class WarFXPE" statement because you haven't stuck the vehicle effects inside a "class WarFXPE" statement in the cpp or something like that? And so it doesn't work on the Weapons because they're inside a "class WarFXPE" statement, and the vehicle ones aren't? Or possibly the vehicle init should be inside a "class WFXPE_Vehs" statement, and the weapons init inside a "class WFXPE_Weps" statement, to keep them separate. class Extended_PostInit_EventHandlers { class WarFXPE { class WarFXPE_Vehs { clientInit = "call compile preProcessFileLineNumbers 'WarFXPE\ParticleEffects\SCRIPTS\init.sqf'"; }; class WarFXPE_Weps { clientInit = "call compile preProcessFileLineNumbers 'WarFXPE\ParticleEffects\SCRIPTS\init.sqf'"; }; }; }; Try ditching the "class WarFXPE" bit from the weapons one and see if that breaks the weapons but works on the vehicles: class Extended_PreInit_EventHandlers { WarFXPE_PostInit = "call compile preProcessFileLineNumbers 'WarFXPE\ParticleEffects\SCRIPTS\init.sqf'"; }; Sorry if I'm being really dumb asking these questions, but config.cpp addon stuff is a bit of a grey area for me.

First I'll warn you I'm no scripting genius, so this may not get you ahead at all. And without seeing the init.sqf, this is a shot in the dark too, but what's to stop you from splitting (or even copying) the init.sqf in to 2 scripts (eg init_veh.sqf & init_wep.sqf) and firing up each in the appropriate way that works? The only problem I can see cropping up is if there's a chance variables will get shared when they shouldn't. If the variables are internal to the script (ie they don't need to be known outside of it), then you should make them private in the first line of the script to avoid weirdness. private ["_varname1", "_varname2"]; It's an ugly solution, but sometimes the engine seems to demand the ugly method.

I assume it's basically just a matter of taking the Sahrani Electrical Grid code (see OFPEC's scripts section) and adapting it by changing the numbers which are basically locations for towns. Here's a snippet of the old SEG code: sleep .1; if (!isServer) exitWith {}; {_x switchLight "off"} foreach ([14475.468750,8576.005859,30.519976] nearObjects ["streetlamp",250]); // Gaula sleep .1; {_x switchLight "off"} foreach ([16571.910156,9363.751953,12.285000] nearObjects ["streetlamp",300]); // Everon sleep .1; {_x switchLight "off"} foreach ([14535.646484,10791.570313,43.965000] nearObjects ["streetlamp",550]); // Obregan sleep .1; {_x switchLight "off"} foreach ([13215.121094,11346.532227,25.965000] nearObjects ["streetlamp",635]); // Mercalillo All you need to do is place a unit in the centre (in terms of a circle that would cover the town) of each town you want covered, (name the unit after the town to make life easy), then save the mission, open up the mission.sqm file in notepad and cut & paste the unit's position numbers into a script, adjust the radius to fit the town, and add a comment to show which town is affected (to avoid later nightmares). Eg replace the red bits with the relevant numbers/names: {_x switchLight "off"} foreach ([[color="Red"]town_location1[/color],[color="Red"]town_location2[/color],[color="Red"]town_location3[/color]] nearObjects ["streetlamp",[color="Red"]radius_of_town_in_metres[/color]]); // [color="Red"]Town_name[/color] I will warn you: I haven't even remotely tested this in ArmA2 yet, so this method might not work at all. ArmA2 may have changed the name of "streetlamp" to something else, for starters. Try it on one town & see how you go.

As I have found out in scripting: if (isPlayer -dead-) then { Knowledge=false; }; Thanks for the correction. I figured it was paradrop, several versions older and wiser and renamed. Still at least I know who's the right person to blame now. ;)

Gaaah! I saw the after action report on Dslyecxi's site way back and lusted after this mission. So much so that in the end I bit the bullet and fired up the mission editor in anger for the first time and started making a mission along those lines... Only to find this thread whilst looking for similar missions to pillage for script answers. There goes a couple week's worth of hair pulling. On the other hand -- found the seriously cool mission! Happy! Happy! Joy! Joy! I'm going to have to carry on with my vastly inferior Bodgit & Run project -- if only because it's there now. So thanks a million for the mission :bounce3:, and frankly shame on you for making me read all that disparate, confusing and complex documentation; learn sqf; take apart the ACE mod to find out what muzzle the zu-23 should be; and look for all those &%$#%@ missing semicolons and brackets. :banghead: Honestly forcing people into the mission editor with this sort of sexy mission... shouldn't be allowed... mutter.. mutter. ;)

Here's how I got it to work: 1. Copy the "FDF_Sounds" folder into the "beta" folder. 2. Alter the beta shortcut so it reads "C:\Program Files\Bohemia Interactive\ArmA\beta\arma.exe" -mod=FDF_Sounds;beta -nosplash Presumably you can add any other mods using the same method: eg. -mod=FDF_Sounds;some_other_mod;yet_another_mod;beta

Yes and no. On the Yes tip: It works with 1.07b to some extent, and it doesn't stuff the beta in any way. So it's *sort of* compatible. On the No tip: Compared to using it with 1.05, some sounds have changed back to default BiS ArmA sounds (eg m16a2 still uses the FDF_sounds, m16a4 now uses the BiS sounds), I guess due to being renamed in 1.07b or something. Also the burst mode sounds like 4 shots instead of 3. On balance, I reckon the bits that still do work make it worth using the semi-working mod while the FDF guys fix it so it plays nice with 1.07. Try it and see if you can live with the glitches.

While we're at it - Foxholes, and the ability to dig them and maybe trenches would be cool too.