Bamse

Nope, just the dll and the pbo's

Does that actually do anything? Wiki says different as all values over 2047 falls back to 2047 source: https://community.bistudio.com/wiki/Arma_3_Startup_Parameters

Hiya! Quick question regarding ranging the M230 on the AH64. For me it seems like it is auto-ranging between 100m and ~1200m as in basically hitting exactly where you aim no matter the actual range within that span. What happens when you shoot at ~2km is that all rounds fall very very short and it seems like there's no way of manually setting the range. On a few other apaches out there you are able to enable the laser desig and lock the gun to that to get it to auto range and at the time of writing I haven't tested that on the CUP iteration. Is this the case here too? So, to my actual question then. How are you supposed in a properly range the M230-cannon? What's the intended way? :) Thanks in advance!

Check if you have your sound pack volume turned up like in the linked pic below. Sound will be silent if disabled or turned down. https://dl.dropboxusercontent.com/u/4170539/ts3_volume.png

This must be made into a music video. plz? :D

Oh shit, sry my brain farted a bit when typing and I only typed part of what I wanted. The HUD is 10/10 as is. What I meant was adding a HMD display ... now that the A10C utilizes Scorpion/HMCS like can be seen here: http://imgur.com/CVnI9pL Full video for anyone who likes some A10/CAS lovelyness: https://youtu.be/H4LOGfuuugc

If (when rather? ;D) your succeed with the RHS A10A, would you consider doing something similar for the USAF A10C?

Sry my english is a bit shoddy ... but in the youtube video you tell us one way of adding a repo to the client via the Create Repo screen. That screen is at this time of writing a bit, in lack of better words, daunting for some users with what looks to be quite a number of fields to fill out. The suggestion from my side was to eliminate as many fields as possible making it look and feel easier to add a new repo for the user. More making it look more like the Import procedure ... kinda like this: Create -> paste url -> done. If then someone wants to do more advanced stuff (90% of our player base wont touch a single additional thing) like change the repo display name, default addon folder and stuff or whatever it can be done by pressing the cogwheel once it's added. This is from my point of view and just a humble suggestion. Not requesting stuff in any way or form, so take what you will from it :) Oh, copy that. I've always put my mods in the Arma folder since back in the day. I didn't even know it was possible using the Documents folder as one of the default places to have them in. You learn something new every day, indeed :) Thanks for all the answers, I'll keep fiddling with Swifty and subscribe to the thread.

This is a really nice alternative for custom repos, really good job man! Some input from my point of view after trying it out for a short while When focusing on ease of use the less stuff to do when creating the repo on the client/player computers the better. * Imo, and if possible, when setting up the repo or repos for the first time as a player ... having something more in line of the Import screen would be a better choice instead of the quite daunting Create-screen. This also goes well with if FTP isn't to be used anymore like the YouTube-video hints since many of the fields wont even be used anymore. The name is supplied by repo.config so that seems a bit redundant to fill in just to get started. It's better to let the repo admins be able to set a set of defaults and let those who want to change stuff have the option to do it after the repo is created rather than requiring everyone to do it. * The default addon folder on each repo gets defaulted to the Documents folder if left blank, but isn't it rather standard to have mods installed into your "Steam\steamapps\common\Arma 3\"-folder directly? From my PoV it would be better to use the Arma 3 folder found in the general settings as a default folder and for those who wants to have them elsewhere they can click the browse button. The less required input the better :) I know you don't want to be a mod/repo manager that does everything, but stuff that we found to be a nice addition is; * Is there some way to synchronize folders over for instance ftp? Right now it seems like the only way to make sure you don't have any old files on the server is to delete and start uploading again. * Having multiple repos with different userconfig-folders is a bit of a battle. Right now the different repos battle it out and deletes stuff every time something is updated. Having the option to ignore other already existing folders would be a good thing. * Launch option for use with multiple repos. Our group has a main repo that is needed for everyone that joins, but also an optional client side repo and there's no option I can find to launch the game with both main and client repo. Maybe a tickbox in the upper left corner of the repo-logo could be one way to go? The build process is straight forward, streamlined and easy to automate for repo-admins and once the initial setup is done it really seems to be a sweet client for players to use. I'll present it for my group and see if the other find it as good as I do. Thanks for doing this!

Thanks for the explanation! Great to shed some light on this since my stuff was only assumption based. This behavior does however happen with GBU12, a few other GBU's (cant remember which, sry) and so on, and even when hitting dead bang on top of the turret. So the type and size of munition in my tests doesn't seem to have much of an impact :) But I do however agree on the hit-values, but as hinted this was more an example than an actual value to be used. I'm sure they are tweakable, and I'm happy to test it out further if there's an interest from Sgt. Fuller and lala14. Anywho, I'm open for PMs for further discussion so I don't dilute this thread anymore :)

Thanks for the explanation! Great to shed some light on this since my stuff was only assumption based. This behavior does however happen with GBU12, Mk82 and Mk84 (with guidance activated just to get it as precisely on targets as GBU's for testing purposes), GBU31 (hit =""; ranging from 2000 up to 8000) etc. and even when hitting dead bang on top of the turret. So the type and size of munition in my tests doesn't seem to have an impact :) But I do however agree on the hit-values, but as hinted this was more an example than an actual value to be used. I'm sure they are tweakable, and I'm happy to test it out further if there's an interest from Sgt. Fuller and lala14. Anywho, I'm open for PMs for further discussion so I don't dilute this thread anymore :)

Hey again! It's not that uncommon when dropping for instance a GBU-12, AGM65 or even a Mk84 on an armored target (no matter if it's a vanilla T100 or a CUP T72, BMP2 or BTR-70) that the tank gets disabled, the crew run out and that either it takes anything between 10 seconds to a few minutes for the tank to explode. It almost seems like even tho getting by visual means a very direct hit through lasing, it still doesn't count as a direct hit and indirectHit-damage comes into the equation. Please note that this is not unique to USAF-mod in anyway. If it's of any use and you think it's worth while; upping the indirectHit quite a bit and the indirectHitRange slightly will change this behavior and destroy the target on impact. I've tested these values for good repeatable results, but it could probably be tweaked down a bit: class USAF_AGM65E_AG: USAF_MissileBase_AGM { indirectHit = 1500; indirectHitRange = 13; }; I'm not looking for any replies or anything. Just a shot in the dark-kinda suggestion/hint/tip :)

Here's some values for the USAF-modpack A10: CCIP_Allowed_Weapons[] = {"USAF_GAU8_GUN","USAF_FFARLauncher_unguided","USAF_MK82_Launcher","USAF_MK82AB_Launcher","USAF_MK84_Launcher","USAF_MK77_Launcher","USAF_CBU100_Launcher","USAF_CBU78B_Launcher","USAF_CBU87B_Launcher","USAF_CBU89B_Launcher"}; CCIP_Weapon_Positions[] = {{"USAF_GAU8_GUN",{-0.0978186,7.75574,-0.391498}},{"USAF_FFARLauncher_unguided",{0,0,-1}},{"USAF_MK82_Launcher",{0,0,-1}},{"USAF_MK82AB_Launcher",{0,0,-1}},{"USAF_MK84_Launcher",{0,0,-1}},{"USAF_MK77_Launcher",{0,0,-1}},{"USAF_CBU100_Launcher",{0,0,-1}},{"USAF_CBU78B_Launcher",{0,0,-1}},{"USAF_CBU87B_Launcher",{0,0,-1}},{"USAF_CBU89B_Launcher",{0,0,-1}}}; I used the values found in the optional PBO for Perals' A10 since it is the same model (right?) and added the launchers whos bombs has no guidance as far as I could find on wikipedia ... feel free to correct me if I'm wrong :D Packed as a pbo: https://dl.dropboxusercontent.com/u/4170539/arma3/mods/source/bamse_ccip_usaf_a10.pbo

Tupolov: totally forgot some details, my bad. After noticing the issue and reporting it here I made a new empty mission, on Stratis. The only thing I did to have it as "clean" as possible I placed 1 player, 3 playable slots, a Zeus module and a arsenal box, exported as a multiplayer mission and uploaded to the server. So there's no Alive modules in the mission at all, and persistence is off on the server itself. Do I need to place the base modules for Alive in order for stuff not to break if I have it loaded, is that my issue perhaps?

I'm having some issues with Alive and ACRE2. I've tried a bunch of variations with different mods together with ACRE2, but as soon as I put Alive in the mix on the server I get quite a massive rpt-spam and ACRE2 stops working. The main error I get absolutely flooded with is: Error in expression < = diag_tickTime-2; waitUntil { [] call acre_sys_sync_fnc_perFrame_monitorFrameR> Error position: <acre_sys_sync_fnc_perFrame_monitorFrameR> Error Undefined variable in expression: acre_sys_sync_fnc_perframe_monitorframerender File idi\clients\acre\addons\sys_sync\XEH_post_init.sqf, line 25 This is a bit more info: http://pastebin.com/5SxDQ3hA I can paste the entire log but it's about 7000 lines generated in under the 5 minutes I was testing and it's 99% of the errors generated is as above. As you can see in the pastebin I'm running a dedicated windows server 1.54 stable running the latest version of Alive as per this thread, CBA 2.2.0.151130 and ACRE2 2.1.0.811 Is there anything I can do on my end?

according to the documentation -filepatching enables file patching on the server. In your server.cfg you specify the client settings by using the allowedFilePatching = X; setting. reference: https://community.bistudio.com/wiki/server.cfg

1. Stop using a potato computer with Arma. 2. It's totally forbidden to not read up on parameters you can use to skip splash screen, load with an empty world to make Arma start faster. Extremely prohibited so don't even try that. 3. Spew shit on the internet and clearly declare that you wont do any additional actions that might actually be useful for us to be able to help. I, like totally, wish you good luck in your quest on getting someone to help you. Totally.

I've tried using the radio channel name module found in the editor and what I'm basically trying to do is to change the name on the default channels found on the AN/PRC152. So I placed down a module, selecting West as side and just for testing changed the name of channel one to "Alpha 1-1" and then channel two to "Alpha 1-2". Then I get in-game, but no matter what radio I open it doesn't seem like any of the channel names on the radio sets are changed. I've tried syncing the module to the TL and/or individual units but no luck so far. I've also tried the other radios available but it doesn't seem to change on any radio. Am I using the module wrong or is the sqf-method the preferred way of doing what I'm trying to do? :)

Weapon names are all there, just start the editor and go into the config editor and check all stuff under CfgAmmo that starts with USAF. I get what you are saying when it comes to documentation but my assumption is that if the functionality would indeed meet the mod makers aimed quality goal it would 1. announced 2. documented. Since it's not it is probably not done. Mod making is done on ppls spare time so I'm grateful for every byte that gets released, and sometimes one doesn't get everything served on a silver platter so roll up your sleeves and start digging :)

There is for the A10 atleast; A10C_dynamic_loadoutscript = [_A10C,_station_1,_station_2,_station_3,_station_4,_station_5,_station_6,_station_7,_station_8,_station_9,_station_10,_station_11,_station_12,_station_13,_station_14,_station_15,_station_16,_station_17,_station_18,_station_19,_station_20,_station_21,_station_22,_station_23,_station_24,_station_25,_station_26,_station_27,_station_28,_station_29,_station_30,_station_31,_station_32,_station_33,_station_34,_station_35,_station_36,_station_37,_station_38,_station_39] execvm "\USAF_A10\scr\LOADOUTS\A10C_dynamic_loadouts.sqf"; So, for instance if I do it in the editor for quick'n'dirty SP use and want the loadout to be like this if you look at the A10 from the front, starting from the left: Mk82, Mk82, AN/AAQ-28, Mk84, GBU-12, GBU-31, GBU-12, Mk84, Mk82 x3, Mk82, AN/ALQ-131 A10C_dynamic_loadoutscript = [this,"USAF_1Rnd_ANALQ131","USAF_1Rnd_MK82","USAF_1Rnd_MK82RACK","USAF_1Rnd_MK84","USAF_1Rnd_GBU12","USAF_1Rnd_GBU31","USAF_1Rnd_GBU12","USAF_1Rnd_MK84","USAF_1Rnd_ANAAQ28","USAF_1Rnd_MK82","USAF_1Rnd_MK82","USAF_1Rnd_MK82","USAF_1Rnd_MK82","USAF_1Rnd_MK82","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty","USAF_empty"] execvm "\USAF_A10\scr\loadouts\A10C_dynamic_loadouts.sqf"; There's quite a bit of a detective work to be done to find out what station goes where. But it's quite satisfying ending up with a good result so pilots don't have to do anything before take-off (or just restricting munitions that the mission maker deems unsuitable etc). This is a undocumented feature afaik that I found when trying to do a temporary config patch for the cockpit sound bug in the A10 so use at your own risk. I haven't got a single error as long as I do it properly either on SP, local mp or dedicated MP but do not bug the mod dev team if it doesn't work :)

Hmm, wierd. I'm running borderless windowed (and have been for as long as I can remember) and are using my windows keys just fine so it kinda sound like a out-of-game settings thing to me.

Make sure you have the _latest_ version of CBA. If you're running some kind of repo system (PwS, Workshop) try downloading in directly from armaholic and completely delete the version you have from your hardrive (not just the repo system) before you extract it.

shomu1: ah ok, gotcha! (and also super OT, but since it was mentioned: https://forums.bistudio.com/topic/182435-bamses-mod-mods/ )

What's not working with the Mk18/M4B2 btw? I haven't used them that much, but apart from a small patch I've made making them use sounds from the the HLC AR15-pack (added as a patch requirement) I think they work quite nice along with ACE3, RH's acc.-pack and IanSky's scope mod :)

Intentional necro, just fyi :) I'm installing a new server for exclusive a3 use, and read this thread back when it was active. It has always been in the back of my mind somehow and ... well. Since I'm installing a new one I just wanted to check. Is this still an "issue"? Was there ever an actual issue in a form that running a3dedi on 2012 generally got worse fps than running on 2008 or was it just an oddity when the a3-server was idling and had no job to do? I've been googling a bit on it and this is the only thread I've found with some actual numbers ... so that's the reason for the necro :)