blackmamb

Maybe not apparent problems, but you're probably not gaining much by running both of them, except for a bit of useless script overhead. For example, both mods run around a custom danger.fsm, which will trigger most of the other features. One mod loaded after the other will overwrite most of it. I guess you could have some form of combination by loading ASR first to benefit from the config changes, then bCombat for the combat behaviour, but I don't know what bCombat does in terms of config from memory. You certainly wouldn't get ASR features like group intel sharing anyway, plus each mod is tailored to work with a certain set of configs. All in all, those are two different mods that tackle the same issues, and you should definitely choose one over the other.

I think murk_spawn does exactly that. Have a look!

You can't define CfgMagazines classes in description.ext. The only attributes you can use in description.ext are listed here.

Hmmm. Maybe I've changed something else. Damn me and not documenting my stuff. How many units do you spawn each wave?

The loop responsible for spawning in this script is at the very end of the script. Here's a modified version I used to somehow limit the number of units: http://pastebin.com/3eYYgGm5 Note that this doesn't really limit the number, it just waits until the total count of units is under 200 before starting a new wave. Knowing about how many units you spawn each wave, it's enough for me. Let's add that this script was originally written by Igneous01.

onMapSingleClick "vehicle player setPos _pos; onMapSingleClick '';" Should teleport the vehicle and its crew/cargo as well.

Seems pretty obvious that the dude you'd pay would be making a commercial profit from it.

Well, in any case, if anybody ends up interested in it, I can post an old script that I made a long time ago for A2 to modify the weapon/firemode selection. It's messy and not really pretty, I never really bothered to polish it as it was never released to the public, but pretty much what it does is use one key + mousewheel to select the weapons, and another to change the firemodes. The firemodes are memorized, so if you switch your AK to single, then switch to an RPG, and get back to the AK, it will still be in single mode. Obviously it would need a few modifications, but it would definitely allow for a more flexible use of firemodes.

Can't you just change your controls? Like assign your right-click to both Optics and Toggle zoom in?

A "Fired" EH should be enough to add the remaining bullet after the first is shot. You can't go to 31, but you can get back to 30 from 29.

Assuming that the issue would be that you'd have to cycle through deployed/folded firemodes to get to the one you want, wouldn't it be a good idea to rearrange the way you select weapons and firemodes? So that deployed modes could only be accessed from other deployed modes or the corresponding folded mode. Obviously that would be a bit of work but that's still pretty easy to do.

Assuming that you can indeed broadcast compiled code, you can't broadcast a local variable. Factories needs to be a global variable.

Awesome. Great news. I'll create another ticket related to what I wrote earlier.

<execute expression='string'>Text</execute> or <executeClose expression='string'>Text</execute> iirc.

And that. And fix the AISFinishHeal, document setAIS and generally fix the handleHeal that's completely broken by the new engine-side healing.

Any chance of having the same behaviour for HandleHeal? It's quite complicated to handle healing right now.

Well, until now, it didn't have any interest in MP since it would always cause massive stuttering. Now, they changed the way it works recently, does it work smooth on a hosted game?

I'm not sure that's completely true, Iceman. The basics of it are pretty well explained, in the link you posted and here. Certainly some people understand things better when they read them, some understand better when they do them, different people, different ways of learning. Stating that explaining it is impossible seems wrong to me. There really is nothing complicated in the basics of locality, it's always the implementation that can get a bit tricky when you're entering more complex systems. The general idea is to always have in mind what scope you're working in: if dealing with a unit, where is that unit local. If dealing with a script, where is my script executed. Then, as cuel mentioned, keep the biki opened in a tab and regularly check where the commands I need to use should be executed from relatively to that particular scope. BIS_fnc_MP is way better than the MP_framework from A2 and allows to easily handle any locality issues by executing code where you need it to be executed. Example: I want one vehicle to change texture ten minutes in the game. Obviously you don't want each player to have its own countdown, as it would result in everybody having the texture change at a different time, depending on who loads first, etc. So you make it server-side only: if isServer then { sleep 600; On the other hand, now you have a problem as setObjectTexture as th AG (Global Argument) and EL (Local Effects) icons: It means that you can change with that command the texture on a remote object (not handled by the player's computer), but this needs to be executed on your computer for you to see it. So you need to execute the actual texture change on everybody's computer. [vehicle, TAG_fnc_changeTexture, true, true] spawn BIS_fnc_MP; }; where vehicle is the object you want to change, the first true meaning everybody will execute that code, the second meaning it will be executed by JIPs as well. Now you need to define that TAG_fnc_changeTexture function. TAG_fnc_changeTexture = { if !hasInterface exitWith {}; // on computers that don't have an interface (a dedicated server or an Headless Client), the script is aborted: we don't need them to change a texture they cannot see or display. _veh = _this; //retrieves the parameter you gave it in BIS_fnc_MP, the vehicle _veh setObjectTexture [1,"\pboname\texture2.paa"]; //Do whatever you needed to do locally }; Now remember, that function will be executed by everybody, so it needs to be defined everywhere: the easy way is to stick it in the init.sqf, as you know it will be executed by every client. Obviously this is a very basic example, but at first, I believe this is the way to go, and you should repeat that analysis for every script command you use. Then, when stuff is working, you can start optimizing all this, mostly by reducing as much as possible the amount of times you need to "artificially" switch locality (using BIS_fnc_MP).

Of course. You just have to replace: _marker setMarkerColorLocal "ColorBLACK"; by deleteMarkerLocal _marker . Edit: that's going to remove it immediately. To remove it ten minutes later, keep the first one, add a sleep, add the second: _marker setMarkerColorLocal "ColorBLACK"; sleep 600; deleteMarkerLocal _marker . Now it turns black the target is dead, and disappears after ten minutes. If you want to keep it red, just remove _marker setMarkerColorLocal "ColorBLACK";

Huh. Do you have your 4 civies named c1, c2, c3 and c4?

So, I knew the HandleHeal was pretty much broken. But now, I'm not even sure to understand how it's supposed to work. If anybody's familiar with it, afew clarifications would be much appreciated. So, I can get it to fire, (almost) no problem (it fires only if assigned to the unit getting healed, and does not work when a unit is healing itself, and also the third returned value is always false), and executes all kinds of code. But is there a way to actually manipulate the way the healing is done? For example, if I assign an eventHandler that only does setdammage 0.3, the unit getting healed will be set to 0.3, until the healing is done. Then engine side healing is applied. setAIS [true]; fa_mmfn_handleHeal = { _unit = _this select 0; _healer = _this select 1; player sidechat str(_this); _unit setdamage 0.333; AISFinishHeal [_unit, _healer, true]; true }; testeh = dude addEventHandler ["HandleHeal", {_this call fa_mmfn_handleHeal}]; nul = [] spawn { while {true} do { HintSilent format ["%1", getdammage dude]; sleep 0.1; }; }; There are to commands that seemed relevant to me: AISFinishHeal and setAIS, although none of them seem to do anything. Am I missing something, or should another ticket be created? Edit: By the way, I do have a working workaround to this. I'm just curious to see if it's just me not understanding properly how this works. Edit some more: Also, the fact that it does work as inteded when using setdamage 0 makes me think the AISFinishHeal command is broken.

Working just fine for me, so I'll assume I didn't understand what you wanted to do in the first place. Is your player a civilian?

There were a shitload of typos and leftovers from your code. Lemme fix that real quick. First post edited.

Untested, but here is a possible way of doing it (assuming I understood what you wanted properly, which isn't always my best skill) MS_fnc_localMarkers = { private ["_target", "_marker", "_name"]; _target = _this; _name = name _target; if (side player != civilian) exitWith {}; _marker = createMarkerLocal [_name, getposATL _target]; _marker setMarkerTypeLocal "hd_dot"; _marker setMarkerColorLocal "ColorRED"; _text = format ["TARGET: %1",_name]; _marker setMarkerTextLocal _text; while {true} do { _marker setMarkerPosLocal (getPosATL _target); if (!alive _target) exitWith {hint format ["Task failed: %1 is already dead", _name]; _marker setMarkerColorLocal "ColorBLACK";}; sleep 2; }; }; MS_fnc_actionMarkers = { _array = [c1,c2,c3,c4]; { if ((!alive _x) || {_x == player}) then { _array set [_forEachIndex, -1]; }; } forEach _array; _array = _array - [-1]; _target = _array select floor( random (count _array)); [_target, "MS_fnc_localMarkers", true, true] spawn BIS_fnc_MP; }; You addaction would go, I guess, something like : player addAction ["Choose a target", MS_fnc_actionMarkers];

On the page just before that one: Here.