MrSanchez

Comrade, this section is for releasing modifications, it's not for getting help with a mod. You'll have to patiently wait in the TFAR thread. Kind regards, Sanchez

I love pookie and all his content full-homo of course, but the amazing animator Katie has very little spare time and creating custom animations takes a substantial amount of time so unfortunately we won't be able to help pookie in that regard. :P Kind regards, Sanchez

Outta curiosity I had a look in the Steam Subscriber Agreement and found nothing in there that would remotely suggest a mod like this wouldn't be tolerated on the Workshop. The only thing I would suggest is not to use a picture of a man with a gun aimed at his head as the mod's Workshop avatar. BIS got picky about that that kind of stuff in avatars in the past. For that reason Zooloo (Bloodlust) and myself (Headgore, which works quite well together with Easy Way Out :P ) censored those avatars while keeping the gallery uncensored (which was fine). Kind regards, Sanchez

Imho, Best case scenario: (Promotion of) monetization stops completely. A bit worse, but to ease some pain: Monetized servers not allowed to run any mods whatsoever Still worse but a nice idea: Find a way to please both server owner and mod makers. According to BIS' FAQ about running mods on monetized servers: You may, but ONLY if you have proper permission from all of the authors of such mods. Monetizing without it contravenes our licenses. This would imply that the mod makers have power, if a mod maker says no, then it's done deal, no monetization of his mod. Doesn't work that way in practice though. So many servers, so little control. BIS doesn't allow mod makers to charge server owners for the usage of their mods on monetized servers, nor are they allowed to demand a share of the monetization revenue. Mod makers are only allowed to say yes or no towards a server owner asking for monetization permission, that is, if they ask in the first place. And even then the server owner could just sneakily run the mod anyway because the chances of being found out are very slim and it's not like BIS is going to check on you either. There's uncertainty for server owners too: Even if a mod maker would demand a share of the revenue all sneakybeaky under the table, what guarantee does the server owner have that the mod maker isn't just going to "revoke" permission afterwards? In the end however, the server owners are the ones profiting from this uncontrolled/unchecked mess that is called 'monetization', at the expense of mod makers. (I don't think there's many content creators that like seeing others making money off of their creation, while they themselves receive nothing). To put it in a bit of a childish manner: If I can't make money off of my creation, others shouldn't be able to make money off of my creation either. (All or nothing) Find a way to govern monetization better (which is difficult, yes) or remove it entirely. TLDR; My initial opinion about monetization is that it's bad completely. No good. Money poisons communities. However, if BIS is absolutely 150% certain they want monetization, they should find a way to create a fair balance between server owner <> mod makers. Kind regards, Sanchez

While alive uh80_alpha do Sleep 5 Alpha_chopper setmarkerpos getposatl uh80_alpha Alpha_chopper setmarkerdir getdir uh80_alpha Try it

Hi, I believe that is a known bug, yes. Kind regards, Sanchez

A bit off topic but on the topic of say(2/3D) I found out something perhaps worth adding to the wiki. Sounds added to ArmA objects that are of type 'Person' (e.g. units spawned with createUnit or animals with createAgent) get automatically queued by the engine. Sounds added to other ArmA objects do not have engine queueing. Hence the presence of confusion in the past With sound queueing I mean, use say3D twice on the same object, the second sound will only start playing after the first one has finished. A very common technique in ArmA to control played sounds is to use a sound emitter object as intermediary. Often something like a local invisible helipad attached to the player. That helipad could then be removed at any moment to instantly kill the sound. But, unfortunately, as above stated, the helipad would not have sound queueing unlike the player object. Additional notes/rant: I had been working on a small multiplayer, locally-played radio-music script and I added four songs to the player using player say3D. I was absolutely delighted to find out that say3D automatically queued the sounds. This saved me a lot of code and made the script a lot more stable & usable, so I thought. However, upon changing player say3D to _soundEmitter say3D I found out that suddenly all sounds were playing at once. I can't have say3D on the player because e.g. I'd have to kill/delete the player to remove the sound. The only way to have this lovely engine queueing and have control over e.g. volume/play/stop is to attach a Person object to the player. Problem however, createAgent is global. createUnit is global. createVehicleLocal + soldier classname does not work, doesn't count as 'Person' apparently. That'd mean if 30 people have their radio on, there'd be at least 30 global AI units (hideObject'ed, but still..) It would be great if say3D got an optional parameter that enforces queueing on any object, or the ability spawn 'Person' entities locally, but that's unlikely. (haven't tested the local engine ambient-life agents). Not having sound queueing also means that a SQF queueing system would need to be written, which is complicated due to there being no way to automatically detect the length of a sound. The duration would need to be manually inserted in e.g. a separate parameter in CfgSounds of each and every single sound file. This would make the practical usage of such a script unnecessarily more complicated for the user. CfgMusic on a side note, wouldn't have most of these problems (it has a custom EH, playMusic can start from XX seconds). However, it has no 3D sound support & most importantly, the volume for playMusic is determined by the separate 'Music' slider in audio options, which probably a big portion of ArmA players have turned low or off due to their preference on the presence of menu music. There's no escaping that with playMusic either. My apologies for the rant, which I'm not sure will be read anyway, but my hope is that this could perhaps lead to some change (even if that's just updating the wiki w/ new info). To summarize, aka TLDR; In my rant here I more or less described three approaches for a script like a (local) radio-music script and all three approaches had a serious con. 1. say(3D) engine-queueing only applies to 'Person' entities, which can only be created globally. 2. There is no way of determining the length of an audio file in SQF 3. CfgMusic (playMusic) relies on the vanilla 'Music' slider in audio options, which is also used for the menu music, thus often turned low or entirely off. (also, CfgMusic has no 3D commands, but that's irrelevant for this issue) Thanks for reading, hope you have a nice day. Kind regards, Sanchez

Me gusta, love it. Kind regards, Sanchez

Triggers are evaluated and executed globally by default. That means each computer checks the trigger's condition and executes its code if it evaluates to true. RemoteExec executes functions or commands for every client by default. Combining them means every client is executing the remoteExec code which causes the function to be executed by all clients. (Client -> remoteexec -> function executed by all clients) x 6 connected clients = your problem. Fix is simple, use: call trigger1_fnc in trigger act box

Stormoffires wanting a fire dancing script huh :) What exactly do you want? People dancing around a campfire like natives? If so, do you have the animation name yet? Kind regards, Sanchez

We don't include modules for most of what you're describing regarding the spawn stuff. But you should keep in mind that our zombie AIs are very similar to regular AIs. I bet you can find scripts that make enemy AI spawn inside houses, on these forums, if you apply those same scripts on Z&D AI, there's a good chance it'll work flawlessly. Back in the "old" gamelogic days one could attach a zombie spawner logic to the player and it'd continuously spawn zombies around the player. Unfortunately that won't work anymore in the current released version. For now I recommend writing or finding your own scripts to make zombies spawn around the player continuously. I'll take it as a suggestion though :) The current deletion module indeed deletes alive/dead zombies if x distance away from any player. We have a module setting that allows dead zombie bodies to be deleted after a predetermined interval, not on distance. For distance I'd recommend using the ArmA 3 engine-incorporated garbage collector (corpse/wreck manager in description.ext) Kind regards, Sanchez

In initialization of leader unit { doStop _x } foreach units group this; 'This' refers to unit object Group this refers to unit's group ( used optionally here since units cmd allows object as parameter ) Units group this returns an array of all units in the leader's group Foreach runs code on every element in the provided array. _x is a magic variable that refers to the current element in the foreach loop. doStop should force an unit to stop. Otherwise use _x disableAI "MOVE" Also check if you have any AI mods running. Kind regards, Sanchez

Let's just say that that ship isn't the only one that's got wood right now.

Happy new year folks. Max, first off, great job on this mod. I know this is your mod so you have the right to provide a license of use but since this is a public forum I have the right to express my opinion about it. I think the measures you've taken are a bit excessive. You clearly want to control the usage of your mod. As most of your mods are oriented towards civilian stuff, which naturally interests the cancerous(pardon my french) Life communities, I can totally understand why you'd want to do that. However to add a while{true} loop on the bottom of a sqf script that sends an intrusive message and gets executed if isMultiplayer == true is just wrong. You are essentially denying anyone to use this mod in multiplayer. By saying "without my permssion", does that mean once permission would be granted you'd PM people a pbo that doesn't have this intrusive while loop present? I get you want to protect your mod from the aforementioned malicious communities that have a reputation of stealing and reclaiming modifications that aren't theirs to claim, but I think you need to relax a bit on the total-control attitude. Because right now you're not preventing your mod from being stolen by malicious communities, you're preventing your mod from being used by good-willing (tactical/co-operative) communities. I know your English isn't the greatest but I hope you understand what I'm talking about. Once again, great mod. Kind regards, Sanchez

Just randomly stumbled upon this thread. I believe the code in addEventHandler is a separate scope. Therefore _x in there will be undefined as well. (although, using a string as command may work as theend3r showed, not sure.) As shown on https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Hit- the hit EH passes 4 arguments via an array: unit, causedBy, damage and instigator. It states that unit is the object the event handler is assigned to. (the vehicle) so the code within the eventhandler should be: playSound3D ["A3\Sounds_F\sfx\alarmCar",(_this select 0)]; "A3\Sounds_F\sfx\alarmCar" explained: playSound3D expects a path to the sound file instead of the sound classname. The other sound related commands do expect a sound classname like "AlarmCar" though (e.g. say, say2D, say3D, playSound, createSoundSource) I found the path here: https://community.bistudio.com/wiki/Arma_3:_SoundFiles (_this select 0) explained: _this refers to the array of arguments that the 'Hit' EH passes. 'select 0' selects the first argument from that array, which is the unit. Also, it's select 0 and not select 1 because indexes are 0 based (0 = first, 1 = second). Idk if this explanation was over the top but hope it's useful :) Kind regards, Sanchez

Hehe, sorry for the dreams :P One does not simply rush out a mod update if there's at least 300.000 people using it. Needs to be perfect ;)

Unfortunately we won't make the halloween deadline, which is a shame, especially for all the communities using ACE3. For the past month or so we've been working on rewriting the >entire< mod including folder structure, yet keeping everything backward compatible to not break previously created missions. It is taking us far longer than expected to test and review all the niche features of our mod that have been affected by this change. Extra note: To be honest, mentioning deadlines for modifications is hardly ever a good idea. That's why 90% of mod projects simply don't do it. Modding is a hobby after all, we don't get paid for it, we still have work/education,etc. When dealing with a hobby there's too many things that can take precedence that could cause a deadline to be missed and let people down. (In fact, it's not allowed on these forums to even ask when an update is going to come out, iirc.) So my apologies for setting up a deadline in the first place, Halloween would've been perfect though :) In regards to when the update is going to be now, all I can say is soon :P Kind regards, Sanchez

We don't really remember this bug being reported before but we found it while testing a few days ago. Apparently that bug has been there since head popping was introduced :O I managed to fix the problem though :) The Z&D mod is now being tested in my community. We should be ready for a release very soon ^-^ Kind regards, Sanchez

You should be able to find them on the Virtual Arsenal in the same tab where stuff like mine detectors are found iirc. Eden editor loadout manager should have them as well under the items tab. There's no boxes that have them by default though. Kind regards, Sanchez

You should be able to use the pills and injector by double tapping them in your inventory. It is possible that some mods may overwrite that inventory behaviour, I had reports of Exile doing so in the past. Only if you disable the medical system by deleting ace_medical.pbo you'd be able to revert to the old damage. I'm not even sure whether that's possible though. Alternatively, if you have a private repo/redistribution for your squad, you can go a few pages back and use the hotfix posted by someone and push that through your repo. Me and Ryan will have another testing session tomorrow but I don't think we'll be ready to push out an update by then. Kind regards, Sanchez

I think the Cuerpo Nacionales Policia (CNP), a Spanish police mod has a reflective police vest. I may be mistaken though. edit: Turns out I was right. link: http://www.armaholic.com/forums.php?m=posts&q=27742&d=30 Here's a pic:

Hey guys. Me and Ryan have basically taken a break from more or less the internet in the last month, this break is now mostly over and we're resuming work. A few weeks ago the entire zombie mod has been rewritten (in a way that is backward compatibility). We've optimized various things and the ACE damage issue was already fixed. Due to the rewrite, we will have to test all of our features extensively again and this will take some time. It is a priority of mine to get this new update rolled out before Halloween this month. Best case scenario it could even be within a week. Kind regards, Sanchez

player switchmove ""

I don't have the time to script it but you'll need to loop the script every 10 seconds or so for all zombies. I wouldn't recommend changing anything in the mod pbo as david suggests, unless you want to privately redistribute a modified pbo to everyone you're playing with (quite annoying). If you disable the roaming mode, zombies will stand still until targets are spotted or waypoint is given. Using doMove on a zombie standing still should work. For what you want you need scripting knowledge, if you don't have that then I don't think you'll be able to get what you want, unless you find someone that can do it for you. edit: The script you posted used playableUnits. playableUnits only returns a filled array in MP. If you're testing in SP use switchableUnits. Kind regards, Sanchez

You could write a small script that would loop through all zombies, do a loop through all the players for that zombie to determine who's closest to him, tell the zombie to doMove to that player. Should work pretty reliably.