st_dux

Init fields and scripts are essentially the same thing.

Pretty much, except you'll need to use "_this" instead of "this." As far as removing the respect system goes, I'm honestly not sure. But I figure I may as well leave the function in-tact if I can. Also, one disclaimer: I have tested this on a dedicated server, but not with a high player count and not with any JIP players. It's feasible that there are other parts of ALICE that will break when these two things are added to the mix. If I find out for sure, I'll post my my findings here.

Oh my god... I never knew about the enableAttack command. I can't tell you how many times I've been frustrated by AI leaders sending group members on one-man suicide missions, but I just figured there wasn't anything I could do about it. Thank you for enlightening me, CarlGustaffa.

Alternatively, just put the addAction in an if statement, e.g.: if (player == <guywhoshouldhavetheaction>) then {player addAction [blahblahblah..]}

Simply make a trigger that goes off automatically a few seconds after mission start (use a true condition with a short delay), and put this in the activation field: BIS_fnc_respect = {} Like I said, though, this destroys the whole respect system thing, so it's not really an ideal solution. Alternatively, you can set the ALICE_civilianinit variable to remove the hit event handler, which will remove the desync issue without wiping out the respect function. Civilian deaths will have no affect on a town's respect rating if you do this, but this usually isn't very important for MP missions, anyway. As for actually solving the root of the problem rather than working around it, I still have no idea why the respect function is causing desync. It is called multiple times in the ALICE initialization, and it seems fine here. It's only when it's triggered by the hit event handler that is causes desync.

Such as?

Yes, the RPG ballistics in ArmA have always been completely wrong. This has been brought to BIS' attention several times, but for reasons I do not fully understand, they insist on leaving them in the game like this. I wouldn't count on them changing their minds, but thankfully, ACE implements realistic ballistics modeling for these weapons.

There's really no need for a test mission. All you need is one unit and ALICE2. Put it on a dedicated server; shoot a civilian. Desyncs every time. After messing around with it for a bit, I've figured out that the problem lies with the "BIS_fnc_respect" function. When this function is called by the "Hit" EH given to all ALICE2 civilians, it causes the desync. If you assign the BIS_fnc_respect variable to a blank function ( {} ) shortly after the mission starts, it won't be run when the EH is fired, and the desync will not occur (however, this destroys the respect system). I am not yet sure why the respect function is causing problems, but it's definitely the culprit.

Garbage Collector is unfortunately broken in MP, but you can avoid ALICE's use of it by defining your own version of "BIS_GC_trashItFunc" in the init field of the ALICE logic. This will trick ALICE into thinking Garbage Collector is running when it's actually not, and it will allow you to define your own MP-friendly cleanup function that ALICE will call whenever a civilian is killed (passing the civilian that was killed as _this select 0). Whether or not Garbage Collector is fully to blame for ALICE's slowdown/screwups in MP, I am not yet sure. If so, then using ALICE in MP environment would be a simple matter of disabling GC, but I need to test more.

EULAs are not the law and their enforceability in court is questionable at best. This is nothing more than a publicity stunt for Blizzard, but to be fair, it's a pretty smart one.

Those last two lines are not meant to go in the init file; they would need to be executed during the mission by an admin. Someone will need to have access to a developer console (a place to input code on the fly) for the dedicated server in order for this to work. A player whose ID was added to the master UID array in this manner would not need to leave and rejoin the server for this to take effect.

If you can access the dev console for the dedicated server, this is very easy to do: masterUIDArray = masterUIDArray + [<newID1>,<newID2>,...]; publicVariable "masterUIDArray"

There is no legal basis for this case. This won't go anywhere.

I've modified the trigger activation code so that it stops restricting positions when the driver/pilot seat of a vehicle is occupied by a clan member. if (typeOf (vehicle player) in masterClassArray) then {if ((vehicle player emptyPositions "driver" == 0) && (player != driver vehicle player)) exitWith {};if (getPlayerUID player in masterUIDArray) then {hint "Clan member confirmed -- Good Hunting!"} else {player action ["getOut",(vehicle player)];hint "You are not authorized to use that vehicle!"}}

http://www.nist.gov/public_affairs/factsheet/wtc_qa_082108.cfm

@Iroquois Pliskin: You mention slashed interest rates after 9/11 as a problem, and then immediately afterward you blame deregulation for America's present economic situation. Slashed interest rates is the result of government regulation, though, so which one is it? You are contradicting yourself.

Just saw this post. Is this the case with ALICE2 as well, or just ALICE1? While the Ambient Civilian module is very cool, I don't want to risk using something that could cause desync.

When you say "isNull doesn't work," do you mean that it causes an error? If so, what is the error message?

1. Don't use "_x." It is generally reserved as a special variable in forEach statements. It may work anyway, but it's bad practice and can easily get confusing. 2. There is no loop in this script. That means that it will check the conditions of the if statement once and then proceed to the end and terminate. Since the conditions in this case are not initially true, the contents of the if statement will never be executed. 3. Joining the group of a unit that doesn't exist probably won't work (it only works when setup in the editor because the group join occurs before the unit is deleted). Use [_civDude] join (createGroup east) instead. 4. As for "evidence," what is it, exactly? Is it an object?

It's possible that the end trigger is firing before the "not alive" trigger has a chance to fire. Try putting a short delay on the end trigger. Failing that, make sure that you've actually named the unit in question "BORIS." Also, it's worth noting that: - objStatus is an obsolete command that does nothing. You shouldn't use it anywhere. - The variables "obj_1" and "obj_2" don't appear to be used for anything. You don't need to publicVariable them.

Are you in the editor by any chance? If it's just going straight to the game, then I'm guessing you are. Hold shift while clicking preview to see the map/briefing screen prior to mission start in the editor. Once you export your mission, this will happen normally.

Briefing.html is still used for debriefing messages, too, so it's a nice thing to have.

Lol Sira, those links are great. Thank you for bringing some proper conspiracy theorist nuttery to this thread; it's always entertaining.

Seriously, grenades are used in CQB all the time. They are an integral part of MOUT training IRL, and for good reason. IRL, it's very easy to crack open a door and toss a grenade into a room, or throw a grenade into a window without exposing yourself at all. Grenade control in ArmA is nothing short of absolutely terrible. I honestly can't think of a single tactical shooter that's done it worse.

Was the old Ambient Civilians module (the one that spawns European-type civs) fixed for MP as well, or it only the Ambient Civilians Expansion one that works?