MrCopyright

From my understanding of the command, it doesn't cut sound off at exactly x meters, but it starts to fade at that distance. Also note that in the description.ext the parameters are filename, volume, pitch and distance. You may be inadvertently setting the volume to 15 which may render the max distance fairly useless. I use this command in my mission and I haven't encountered any issues with it.

@gossamersolid, that theory would work if the Arma community stayed consistent, but it hasn't. The code that myself and others would have learned from years ago is still available... not obfuscated. Newcomers to scripting are more than welcome to learn from the same material that we did. Someone will probably mention that the newer, more contemporary commands will not be included in these older missions, but we also had to learn from the Wiki once they were introduced. Unfortunately, times have changed and stealing is now a common part of Arma mission making which needs to stop. Sitting back and allowing the theft to continue will only make this problem worse. Or as some very ignorant person once said, we could 'ban the life community'.

I couldn't agree more with killzone_kid.

@simon1279, that's extremely ignorant. I have been involved in the 'life' scene since Chernarus Life back on Arma 2. Although I enjoy the military aspect of Arma, I adore the fact that you can create whatever you want. This series would not be where it is without DayZ and the life mods. It has generated millions in sales which has enabled BI to create something far more than just an upgrade from Arma 2. It has allowed funding to go into additional projects, like Project Argo and the DLC packs. Unfortunately for you, life mods are here to stay. As mentioned earlier, the only way to remove this toxicity is to clamp down on the illicit behaviour by having BI enforce their terms more efficiently and by reducing theft. Once this behaviour is not normalised, content creators will not need to worry about scrupulously protecting their work.

The fact that BI created EBO files completely destroys anyone's argument about encryption going against the community. Since Arma 3 Life, the community has become very toxic with a dramatic increase in intellectual property theft and copyright infringements. I will agree that encrypting and obfuscating mission files prevents some people from learning, but it also helps to root out this normalised behaviour that stealing is okay. Hopefully, the Arma community will regress back to the times when you didn't need to protect your work, but until that time comes, I think the positives of encryption far outweigh the negatives. If BI feel the need to protect their work, then so should content creators.

Nearly 2 years later you reply, brilliant.

Since when did the Apex files switch? They are still very much .ebo files for me.

A general rule of thumb is to use the spawn command if there is script suspension or indefinite loops inside it and to use the call command if there are not.

If you want to see what addons a mission relies on, you can load the mission.sqm into a text editor and refer to the addons[] section (approximately line 30). This won't display all of the addons but it may give you a rough guide.

I apologise for my hostile reply, that text must have looked like a bipolar meltdown, lol. I can assure you that it was all consistent on my screen.

Excuse me, how is a paragraph an eyesore? Would you rather I construct my reply in bullet points so you can actually understand it next time?

@Dr. Rick Titball, there is nothing wrong with looking at other people's code to learn from it. That's how I learned years ago. My problem was that the OP wanted to know if there was a server with those specific features so he could download their mission. He stated he had no scripting knowledge. Therefore, he wasn't going to learn from that downloaded code, he wanted to put it on his mission. And with regards to you blaming BI for "making it difficult to create missions", that is completely ludicrous. Scripting a mission is an advanced form of mission creation, which allows the creator far more freedom. You can't just blame the game developers because scripting is a naturally difficult skill to learn. Perhaps these "life" servers shouldn't contemplate editing their missions if they have absolutely no knowledge on the subject. You shouldn't run before you can walk.

What R3vo said about the images being cached is correct. If you want to prevent the stutter, simply have a script display every image to cache it.

The 4-5 players leaving once you kicked him was probably a coincidence. And as long as your server isn't being blown to pieces then I wouldn't take too much notice of this. Just keep an eye on him in the logs to see if he's cheating or not.

You can use serverCommand to execute commands such as #mission, #kick, #ban and so forth. If you want to include dynamic mission names, use the format command as well.

On the event scripts page of the wiki you will see the 'Arguments' column. The first argument listed can be referenced with _this select 0 and the second one with _this select 1 and so forth. Or alternatively you could use the params command depending on your preference. Here's an example: And if you add the initPlayerServer.sqf event script to your mission directory, the server will run the contained code every time a player joins. I hope that answers your questions.

A cheater could set a global event handler with their own code inside it. To avoid this, you can simply block the use of the command with BE filters.

It is definitely more secure to have the server execute code. It is far less likely to be injected into or interfered with when compared to client-side code. However, if the code is not optimised, the server's performance can decrease significantly. This ultimately leads to vast amounts of desync and slower response times. As harmdhast mentioned, correctly configuring CfgRemoteExec in addition to the BE filters will render cheating almost null. It is impossible to completely stop cheating, but you can make it extremely difficult.

player addAction ["Set Loadout (Target)", { player setUnitLoadout (getUnitLoadout cursorTarget) }];

Unfortunately there aren't any grid control types, but I'm sure you could use a list box to add multiple columns.

Variables cannot be set on simple objects as well. I guess these are the draw backs of having low network traffic models.

You are allowed 2:1 dimensions for loading screen images. Also, try and place the image in the root of the mission file. So in the description.ext it should look like this: loadScreen = "mission_picture.paa"; overviewpicture = "mission_picture.paa";

If you look at the Wiki page for a command you will see certain icons near the top of the page. These indicate whether the command has a local or global effect. It can even tell you if the arguments/parameters need to be local to the client or not. - This icon means that the command has a global effect. Every client currently connected to the game server will experience the effects. - This icon means that the command has a local effect. Only the client executing the command will experience the outcome. Even if this command is executed on the server, the effect will not be global. From looking at the createVehicle Wiki page, you can see that it has the first icon. Therefore, the vehicle will be visible to every client, regardless of whether the server did or didn't spawn it. However, the createVehicleLocal command has the second icon near the top and the vehicle will only be visible to the client executing the command.

From what I remember, the mission is renamed to __CUR_MP.Altis when you play on that mission. Thus the file path should be: mpmissions\__CUR_MP.Altis\epoch_config\VEMFr_client\gui\hpp_mainVEMFrClient.hpp Also note that the file path will be different if you are hosting the mission via the editor.

A system like this would never be implemented by BI. They have given us plenty of ways to resolve the issues you have outlined. You can easily create a team damage detection script which punishes those who team damage too often. And a flaw in your system is that a group of 'trolls' could easily set up their own server, legitimately kill each other to improve their team kill ratio, and then they'd be on your server.