Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

667 Excellent

About NeoArmageddon

  • Rank
    Sergeant Major

Profile Information

  • Gender
    Not Telling
  • Location

Contact Methods

  • Steam url id

Recent Profile Visitors

1639 profile views
  1. Community Factions Project

    Nice project and a great addition to the Armaverse.
  2. co10 Escape

    I think it is quite challenging even with not limited revives. Adding a limit poses some gameplay problems I don't really like, especially players being unable to continue to play and forced to spectator, while the rest can keep playing. Also thiswould encourage reconnecting to cheat the system. I don't like limited revives, but I will keep it in mind as additional feature for the future.
  3. co10 Escape

    Do you mean revive or really respawn?
  4. Wrong cpu in config file

    Delete the file and restart Arma. This is most likely just the same cfg from before you changed your CPU (as I assume you have not reinstalled Arma in between). But more importantly I would not relate those settings to any performance problems. A3 will run with any clockrate your CPU delivers regardless of what the autodetection says. AFAIK this is only for the default graphic and view settings for when you first start Arma3. If you get the same FPS than before the CPU upgrade, you have a bottleneck somewhere else that didn't changed. For example your graphics card, your RAM, etc. Try different settings in A3 that are either graphic or CPU heavy and check where your bottleneck is.
  5. Help with creating music mod

    Get the A3 Tools from Steam, mount the WorkDrive (aka P: drive) and create a folder in it with a structure like this: - Tag - - AddonName - - - config.cpp - - - music - - - - All your music files While "Tag" is a custom tag you define for yourself, or your squad. Edit config.cpp (basically an description.ext for an addon) with an editor of your choice and add a class CfgPatches and a class CfgMusic. It should look like this: class CfgPatches { class TAG_MyMusicAddon { name = "MyAddon"; author = "Me"; url = "http://xkcd.com"; requiredVersion = 1.80; requiredAddons[] = {}; units[] = {}; weapons[] = {}; }; }; class CfgMusic { tracks[] = {MyMusic1,MyMusic2}; class MyMusic1 //This is arbitrary { name = "My first track"; // filename, volume, pitch sound[] = { "\Tag\AddonName\music\filename.ogg", db + 0, 1.0 }; }; class MyMusic2 { name = "My second track"; sound[] = { "\Tag\AddonName\music\filename2.ogg", db + 10, 1.0 }; }; }; Now start AddonBuilder from tools and use it to pack this AddonName-folder (not the Tag folder!!!) to a PBO. Keep an eye on the virtual path so AddonBuilder packs it correctly under \Tag\AddonName.
  6. Can't use #include?

    How are you calling your scrpt/function? You need to execute it with a command that supports preprocessor command, for example preprocessFileLineNumbers or execVM. See here: https://community.bistudio.com/wiki/PreProcessor_Commands For example: Supports stuff beginning with "#". If you don't want to rely on the preprocessor you can also write this: As the array in gearWhiteList.sqf is the last statement, it will be returned when it is called as a function. Youtr post also misses some information on where you are storing your scripts. /addons/gear sounds like you are referencing an addon. pathes starting with a slash are considered addon pathes, while all others are mission pathes. If your script is in a mission with the subfolder "addons/gear/" your path needs to be "addons/gear/gearWhiteList.sqf". If it is in an addon it needs to be "addontag/pboname/gearWhiteList.sqf". And as a general remark: you might want to declare your local variables private, otherweise you could run in some strange bugs that are nearly impossible to solve later in developing.
  7. co10 Escape

    It will have no effect, aka no fighting between the factions.
  8. Maybe a better approach than just removing magazines from enemies: Attach a InventoryClosed-Eventhandler to the player and everytime he closes his inventory, you run a script that moves all weapons and ammo in a newly created WeaponHolder (an invisible ammo box used to place items on the ground). So the result will be: When the player picksup a weapon, he instantly drops it on the ground again. Maybe with a radio message like "Why can't I hold all these weapons?" :P The script could be like this (just from the top of my head, not tested): params["_unit","_container"]; private _holder = "WeaponHolderSimulated" createvehicle getpos _unit; { _unit removeweapon _x; _holder addweaponcargo [_x,1]; } foreach weapons _unit; And the players init: player/this addEventHandler ["InventoryClosed", { _this call tag_fnc_dropWeaponsScriptAbove; }];
  9. co10 Escape

    There might be problem with relabeling units side in the editor. If you run into problems like AI not shooting you, not getting kill(point) or can't entering vehicles with squadmembers, you can try this aswell: A3E_VAR_Side_Blufor = resistance; A3E_VAR_Side_Opfor = west; A3E_VAR_Side_Ind = west;
  10. co10 Escape

    I fixed some possible spawning and seach leader problems. I assume it is just that the AI responds a little bit better to detecting the players and sending reinforcement. Patrol density also is highly correlated to the terrain. This one is simple: Take a radio from the enemies :P I changed the start so you have nothing except your uniform. You need to take radio and watch from the enemy (I were just thinking: Why should they leave you the radio, when they capture you). I might tweak the difficulty a bit. Having the statistic collection since some build in 1.9 I have a pretty good overview of how hard the mission is right now and the most sessions are under 200 seconds.
  11. co10 Escape

    Heyho and thanks for your feedback. Regarding hearing: That mostly depends on your server settings and installed addon. My impression is, that the AI in vanilla arma is quite capable of detecting the player. Also I'm a little reserved to modify AI to heavy from the mission side, as it may either break when people install addons that tamper with the AI or in future Arma updates. Regarding the total AI control it works right now like this: There is a trigger that fires when a player was detected by an enemy. When the trigger fires, the so called Searchleader AI is querying which unit detected the players. After a certain time (a few seconds) the AI have reported the players position and a so called knownposition is generated. This known position contains the time the players were seen the last time, the number of players spotted and the accuracy of the spotting AI. These knownPositions are updated everytime an AI spots a player. The SearchLeader inspects these known position and decided if there is the need for redirecting patrols, guards, choppers, airstrikes or artillery. When AI detects players via hearing and not visually, the accuracy of the knownPosition is worse. You can sometimes see this while in urban combat, when an arty or airstrike goes nowhere near your real position. This is the reason it is always a good idea to shoot sniper or people with binoculars first ;) The search chopper behaves exactly as any other AI in this regards. It is just the difference that the crew is mostly out of your reach and in the air.
  12. Who would make such an effort on a holiday?
  13. @HazJ What bothers me directly about GitKraken is the need to register an account to use the Desktop app :(
  14. I use SmartGit. It offers a clean GUI to Git and has a lot of convenient functions. Maybe interesting for you: SmartGit supports SVN repositories aswell (but AFAIK it can not cross push between Git and SVN). But for the redmine export to github: no idea, sorry. Edit: @HazJ had a look at GitKraken and it looks quite nice. Will test that out myself.
  15. Local vs Global

    You are absolutly right, but to make it absolutly clear with the init field: private _weapon = primaryweapon this; this removeweapon _weapon; This will query the primary weapon of a player, store it in a local variable _weapon and will remove it in the next line. After the init is run, the _weapon variable is kinda thrown away. Same example: unitsWeapon = primaryweapon this; this removeweapon unitsWeapon; This does the same, but this time unitsWeapon is global. If now several units run this piece of code at the same time it could happen that, for example, a sniper runs this code, and unitsWeapon is filled with the type of his rifle. Right after it, before the next line is reached, another unit runs its init and the unitsWeapon variable is globally filled with this units weapon. When the init of the sniper comes to his line, it will try to remove the weapontype of the second unit, maybe a machine gun, which will obviously fail. Now you sit there in your mission and wonder "When I only have one unit, everything works, but when I add another one, the first one keeps his rifle.... strange". But enough bashing of global variables, here an example where you actually want to use global variables. Sometimes, mostly in multiplayermissions you want to know the group the players are in. You can of course name the player units like "p1,p2,p3,p4,..." and everytime you need the group you can just type group p1; This is obviously a problem when p1 is not occupied by a player in MP. You could now check everytime which players are connected, but it quickly gets hard to read and confusing. Instead you can add this to every possible players init: playerGroup = group this; playerGroup is a global variable and when the init field of one of the players is run, their actual group is stored in the variable. When another player, maybe he connects later, runs the unit, it is executed again, but jusst filled with the same value. I have to add that nowadays I assume setVariable (especially example 3 on that bikipage) should be used for setting global variables in multiplayer. Oh and when you want to sync trigger, waypoints, etc, globalvariables are a good way (or even needed): Place two triggers, one is activated when the player is detected by the enemy and sets "enemyalert = true;". In the second trigger you replace the condition "this" with "enemyalert" and set maybe a timeout and an effect for an alarm. Now, when the player is detected, it will set the global variable true, the other trigger will fire, because his condition (the variable being true) is fullfilled, it will wait the timeout and sound an alarm. Another interesting idea here: Give a speaker pole a name, like "pole" and make the second triggers condition "enemyalert && alive pole". Now the alarm will only sound, if the pole with the loudspeakers is still functional. You can than go ahead and add another global variable to the second trigger, like "alarmsounded = true" and make this a condition for some waiting enemy reinforcements waypoints. The result: When you are detected an alarm sounds and enemy troops are coming your way except you destroy the speaker pole before you get detected.