Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

703 Excellent

About phronk

  • Rank
    Master Gunnery Sergeant


  • Interests
    Gaming, drawing, designing, and more gaming. :D
  • Occupation
    ArmA 3

Contact Methods

  • Website URL
  • Biography
    I have a YouTube channel with quick instructional ArmA 3 videos for aspiring mission builders!
  • Twitter
  • Youtube
  • Steam url id
  • Twitch.Tv

Profile Information

  • Gender
    Not Telling
  • Location
    : USA, New York
  • Interests
    ArmA 3: mission building / scripting.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Always wanted to make something like this, but never had the patience. You're a saint. Can we knife hand general locations on the map?! Jk, good work.
  2. Defining CfgDebriefing in your mission's description.ext just helps you customize what the endMission # shows the player if the command is executed on them. Example: In the example shown above, if you execute endMission "End1" then they'll see a Blufor flag icon, blufor colors, with the "All caches destroyed!" text while also accompanied by the default Arma 3 mission completion sequence (Music, greyout, etc.) whereas endMission "End2" would display a mission failure message with some text about TPW being disallowed. This allows you to assign multiple custom messages for why a mission ends, such as a "You are banned" message or whatever you want.
  3. I've been taking a break from Arma to deal with family shit but once the VON script commands hit Main Branch (Useful for my AFAR project), that'll motivate me to get back to work on this also.
  4. To be fair to BI, it only took 3 years since the creation of my feature request ticket. Better late than never, as they say. Will definitely play around with it once it hits Main Branch! As long as it performs well, it should be the last piece to the puzzle to finalizing AFAR.
  5. I'll definitely look into it once it hits main branch! If the command acts like a volume control for specific players, it should be just what the script has needed. Hopefully it is lightweight since I'll likely need to remoteExec the command everytime a player talks to adjust volume based on certain parameters, such as current channel and lifeState. I haven't had any bug reports since the last AFAR update, so the next version will definitely focus on reintroducing distance factors and possibly other aspects like weather, "distortion", and Line-of-sight (LoS). This will likely also come with new bugs but I'll actively fix whatever comes up until it is stable and smooth. Performance will be prioritized over quality, so things like LoS and other features may be removed for optimization purposes. I want to minimize the load the code has on the network.
  6. No problem, glad you were able to get it working.
  7. Not totally sure why it won't work, but it's possible you need to change: ["PlaceIED.sqf"] remoteExec ["execVM",2]; to "PlaceIED.sqf" remoteExec ["execVM",2]; //Script being called doesn't need to be within brackets and also the false isn't necessary to add because it is false by default.
  8. Thanks, it should now be available to anyone.
  9. Download Link (Google Drive) Download Link (Steam Workshop) Download Link (Armaholic) Version: 0.95 Size: 52 KB ADDITIONS: • Added: Option to allow players to use radio while incapacitated • Added: Mouse button inputs now block PushToTalk keybinds • Added: Text advising player to equip a radio, if trying to talk without one ADJUSTMENTS: • Tweaked: "fuzz.sqf" & "fuzz2.sqf" now takes incapacitation into consideration • Tweaked: Replaced name with getPlayerUID in fuzz functions and "out.sqf" FIXES: • Fixed: Code didn't block talking in radio channels without a radio equipped • Fixed: Radio UI would pop-up from channel switch keys, when r_chOn is enabled • Fixed: Issues when multiple players connected with the same name • Fixed: Script error upon being killed, due to invalid argument with "r_out2" • Fixed: Possible script error due to inconsistent disabling of Spectator channel OPTIMIZATIONS: • Optimized: N/A REMOVALS: • Removed: Text pop-up when pressing channel switch keybinds KNOWN BUGS: • High ping players, server, or desync can cause code delays __________________________________________________________________________ Cleaned up a lot of bugs. Everything has been working as intended without issues in small play tests (Up to 9 players). As always, if you find any bugs, issues, or have any suggestions, please forward them to me! Thanks & enjoy! PS: Happy Independence Day! 🗽
  10. "No gender neutral bathrooms, 0/10" - IGN Coming along nicely, the videos display it all well too. Keep it up!
  11. @icarium r_alertOn is a setting that the mission maker can toggle in the 'CFG.sqf' and it enabling it means players can alert nearby AI of their presence when talking -- applies to all channels, except Vehicle. This description is also next to the setting.
  12. @icarium To be honest, that setting was sort of a placeholder in case I add a better option later. All that option does is set your Radio volume (Also found in Audio settings) to 0% or 100%. So technically, all you have to do is just add 0 fadeRadio 0; to the init of your mission or something to get the same effect you're looking for. My radio script checks the radioVolume, so that's why it doesn't check a custom AFAR volume variable.
  13. Instead of typeOf, use (getModelInfo _x#0) and filter for an array of strings (.p3d names). It's the best workaround I've found so far, but keep in mind that nearestTerrainObjects is heavy over longer distances and getModelInfo is heavier than typeOf.
  14. A heavy script in the background may be filling up the scheduler, which is what is causing other scripts to run slower or pause. Usually bad while{true}do loops can cause this. As for the sounds issue, I had a bug where setting damage to all trees in Livonia would freeze/crash the game with really loud tree falling effects (Plays a tree falling sound per tree which destroyed the game) I doubt the handleDamage eventHandler had anything to do with it, but it may be failing due to how slow everything began to run? Also doubtful since you said server FPS was around 40 so most likely find the code/script thats choking (Review server and client RPT logs) and should fix the problem.