[aps]gnat

Does the mod folder also have the mandatory "Addons" sub folder ?

Exactly. Way to go to promote more people jumping on their offensive, my-issue-is-most-important, my-own-thread, soap box. .... maybe people should try a little more CAPS and expletives in the BugTracker ..... Greatest respect for the Devs, but IMHO this was a bad move.

Nice zooloo Reduces the altitude grabs by AI, but doesn't stop an aircraft climbing. (Tested on my C185)

Excuse my disappointment that an in-your-face thread about just ONE game aspect gets some much attention from the developers .......... All my previous understand about what structured/formalised player/mod'er feedback (systems etc) BI browsed/listened to, has been destroyed.

.... based on your reaction to "hacking" and your lack of response to kylania I still say you're the exception to the rule. I'm done here. Oh, I should say: If you want that feature, open a Ticket in the Bugtracker, or use one of the generic threads that collect such requests.

No sure but heres an example A3 working rvmat ambient[]={1,1,1,1}; diffuse[]={1,1,1,1}; forcedDiffuse[]={0,0,0,0}; emmisive[]={0,0,0,0}; specular[]={1,1,1,0}; specularPower=20.4; PixelShaderID="Super"; VertexShaderID="Super"; class Stage1 { texture="gnt_c185\tex\C185fuse_nohq.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage2 { texture="gnt_c185\tex\c185F_dt.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage3 { texture="#(argb,8,8,3)color(0,0,0,0,MC)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage4 { texture="gnt_c185\tex\c185F_as.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage5 { texture="gnt_c185\tex\c185F_smdi.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage6 { texture="#(ai,64,64,1)fresnel(2.68,3.69)"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage7 { texture = "a3\data_f\env_land_co.paa"; uvSource = "none"; }; class StageTI { texture="gnt_c185\tex\c185F_ti_ca.paa"; };

All that means is some general investors found the BISim group to be on a winning formula and wanted to help out ;) Should mean bigger and better things for BISim.

While I understand you want to sit on the source code, I also understand peoples security concerns. Maybe you should detail a little better what the program is doing (re data in-outs) so users can verify against connections its making. Nice work anyhow! GJ

Suggest you are the exception to the rule. I don't see too many people here wanting to "tweak" addons to suit their mission. Except hacker ;) A "speed" mod? Sure, 1 config. Then make it a separate PBO and distribute like every one else does. .... depends where you live ......... the worlds a big place.

.... think you are playing the wrong game if this annoys you. My simple rule for this; If you can do it to the AI (i.e. snipe them at 400m, which you can) then they are allowed to do it to you. It is after all a "military simulator".

Sorry, no disrespect but you seem to have missed the 10 years of a VERY success OFP/ARMA1/ARMA2/A2OA community with 10's of thousands of community made addons and missions .... much of that history without addon "auto-downloaders" That being said, yes, the game would benefit for a little extra usability for the gaming generation that can't/don't like to manage downloads and mod folders. Unfortunately with thousands of DLC potentially becoming available ..... it could actually backfire and become a NIGHTMARE for some players.

Yep, do. Some cool ideas come from these threads.

My first thought is this is not possible with the current hard code. Pretty sure you can only define an array of get-on and get-off points along the centre-line. Don't know of any way to "exit" .... except death.

Been this way for 10 years ...... Addons are always via addon PBO's Missions are always via mission PBO's ... and scripts can exist in both. The only thing missing is while you ingame download/synch the SAME/current mission PBO from the Server, you can't/don't download/synch addons. First reason comes to mind ..... file size.

thanks hcpookie, yeh, I guess the M134 probably kills it. I44: Yep, thanks, got those ..... plus a 1000 others touch-ups :)

Always looking for a reason to bring back the Northrop/McDonnell Douglas YF-23 :D ...... ! Love the look of this machine ..... shame it lost the race. http://aviationintel.com/wp-content/uploads/2011/05/YF-23A-2.png (522 kB)

Probably because you didn't actually define it in the model.cfg. EVERY model (p3d file) must have its own entry in the file, and the entry MUST = the file name. class cfgModels { class default; class CSJ_P38 : default { .... .... .... }; class CSJ_P38_2 : CSJ_P38 { .... .... .... }; }; In this example there are 2 P3D files. CSJ_P38.p3d and CSJ_P38_2.p3d RECOMMEND If you only have 1 or 2 textures different between 2 models, don't actually copy the model, its easier to use built in engine features to swap textures on ONE model. Steps: In your model, name the faces that have the texture(s) you want to change. Call it something like "skin" (and "skin2", "skin3" etc) In the section[] part of the MODEL.CFG add these definitions. class cfgModels { class default; class CSJ_P38: default { sectionsInherit=""; skeletonName="CSJ_P38Skeleton"; sections[] = { "skin", "vrtule staticka","vrtule staticka" ... ... Then in CONFIG.CPP, in your first CFGVehicle entry; class I44_Plane_P38_S : Plane { scope = public; displayName = "P-38 Model S"; model = "\CSJ_P38\CSJ_P38.p3d"; hiddenSelections[]={"skin"}; hiddenSelectionsTextures[] = {"\csj_p38\data\p38_skin_A.paa"}; ... ... Then in your second CFGVehicle entry; class I44_Plane_P38_Z : I44_Plane_P38_S { displayName = "P-38 Model Z"; hiddenSelectionsTextures[] = {"\csj_p38\data\p38_skin_B.paa"}; }; Thats it. Thats the whole cfgvehicle entry for the second unit if the only difference is a texture. Much simpler. Good luck.

..... and thats me ;) While I use I44 Multi-Barrel on all fighters with fixed forward firing guns, I have not bothered with simulating multi-barrel on the B17 because of the complexity of the whole model as it is. Thats not to say the below script can't be used to do it for each and every turret, because it should. (interestingly the script notes "primary turret only", but it certainly works where a plane has multiple different gun groups firing forward) Tracers work fine. Invasion44 Teams Multi-Barrel Fired-EH scripted Note that Weapons are config'ed Example; class I44_8xBrowning303Mk2_mounted : I44_Browning303Mk2_mounted { .... .... .... I44_isMultiBarrel = true; I44_BarrelCount = 8; I44_BarrelName = "mg"; Then the model must have MEMORY LOD points like "mg_1", "mg_2" etc (typically a couple metres forward of the barrel muzzle) Multi-Barrel Fired-EH script //----- Credit I44 Mod team -----// //----- Note: this only works on the primary turret. -----// _unit = _this select 0; _weapon = _this select 1; _muzzle = _this select 2; _mode = _this select 3; _ammo = _this select 4; _multi = 1; _multi = getNumber (configFile >> "CfgWeapons" >> _weapon >> _mode >> "multiplier"); _bullet = nearestObject [position _unit, _ammo]; _rd = ((_unit ammo _muzzle)/_multi) - 1; if (_rd < 0) then { _varName = format ["I44_rdCount_%1", _muzzle]; _rd = _unit getVariable _varName; if isNil("_rd") then {_rd = 1} else {_rd = _rd + 1}; _unit setVariable [_varName, _rd]; }; _BarrelCount = getNumber (configFile >> "CfgWeapons" >> _weapon >> "I44_BarrelCount"); _BarrelName = getText (configFile >> "CfgWeapons" >> _weapon >> "I44_BarrelName"); _BarrelConvergence = getNumber (configFile >> "CfgWeapons" >> _weapon >> "I44_BarrelConvergence"); _n = _rd % _BarrelCount; _newPos = [0,0,0]; if (_BarrelName == "Array") then { _BarrelOffsets = getArray (configFile >> "CfgWeapons" >> _weapon >> "I44_BarrelOffsets"); _pos = position _bullet; _vel = velocity _bullet; _vDir = vectorDir _bullet; _vUp = vectorUp _bullet; _offset = [ _BarrelOffsets select ((3*_n)), _BarrelOffsets select ((3*_n) + 1), _BarrelOffsets select ((3*_n) + 2) ]; _newPos = _bullet modelToWorld _offset; } else { _modelPos = _unit selectionPosition format ["%1_%2", _BarrelName, _n + 1]; _newPos = _unit modelToWorld _modelPos; }; _bullet setPos _newPos; exit

Unfortunately not correct Starky. Been doing my own testing also. Cross fingers for BIS improving it over time.

I wouldn't write it off, the Physx mode should make it much simpler for them to add it to the RV engine. But post release? I'm OK with that. ..... just look at the differences between A2 initial and A2OA final .........

Far too early to say "never" for ArmA3

Already there for a long time Dan ..... same old story since forever, only VBS offers walking on moving vehicles.

@kju OT, but gotta say thanks for all the community resources you tirelessly provide/update, all the time ..... along with this mod. *hat off to you* Cheers.

The All-In-One configs are up to date and much easier to explore ......... http://forums.bistudio.com/showthread.php?150548-AllInOne-config-from-A3

Tried reproducing JDogs experiement http://forums.bistudio.com/showthread.php?157367-The-answer-you-were-waiting-for-carriers-are-possible-in-arma-3&p=2426734&viewfull=1#post2426734 by attaching them to the LCS, unfortunately it doesn't seem to work the same. Man class simply falls off the training bridge.