General Discussion (dev branch)

[Jackal326 1158]

Isn't that how it is already? In a pack I'm working on I have an MP5SD6. I have defined 2 types of 30 round 9mm magazines for it, one "regular" with the sonic cracks, and one "subsonic" with no sonic cracks. Both seem to zero fine, and the initspeed change is made at the magazine level. Am I missing something, or am I just misreading the discussion?

[roberthammer 582]

Isn't that how it is already? In a pack I'm working on I have an MP5SD6. I have defined 2 types of 30 round 9mm magazines for it, one "regular" with the sonic cracks, and one "subsonic" with no sonic cracks. Both seem to zero fine, and the initspeed change is made at the magazine level. Am I missing something, or am I just misreading the discussion?

For MP5 it might be ok ,but only if you dont use initspeed in weapon class - for example in M4 then if you have initspeed in weapon class and you would like to use subsonic magazine then the speed will not change since only weapon's initspeed overwrites the magazine initspeed

[CaptainAzimuth 714]

Just a small tweak BIS. If you guys could have the countermeasures on the To-199 shoot up bit higher, like it does in real life, as of right now it kinda... fails to do that. It looks like it just spawns behind the engines, and doesn't look good.

[da12thMonkey 1943]

What if instead of the weapon muzzle velocity overwriting the magazine's initSpeed, the magazine's initSpeed overwrites the weapon's muzzle velocity? That way you could have differing muzzle velocities for different weapons using a common magazine (such as the MX series), but you could also have subsonic ammunition while retaining the weapon's unique muzzle velocity if using standard ammunition!

---------- Post added at 15:10 ---------- Previous post was at 15:07 ----------

EDIT: Whoops, looks like RH and I had the same idea. :P

Yes but then all those weapons would fire subsonic ammunition with the same initspeed, so there would be no ballistic differences between the different barrel lengths when firing subsonic ammunition. It makes adding initspeed to the weapon to simulate internal ballistics in the first place, kind of redundant if it only works with one kind of magazine.

Using a coefficient in the magazine and saying this ammunition will leave the barrel of any weapon at 20%/50%/70% of the speed that standard supersonic ammunition would leave that same barrel, is more consistent with what would happen IRL.

For any magazine with the coefficient set to 1 they will use the stated muzzle velocity of the weapon, for 'overpressure' loads you will get a % increase in muzzle velocity for all weapons by setting the coefficient >1, and for all 'under-pressure' (subsonic) loads you will get a % decrease in muzzle velocity for all weapons by setting the coefficient <1.

[roberthammer 582]

Yes but then all those weapons would fire subsonic ammunition with the same initspeed, so there would be no ballistic differences between the different barrel lengths when firing subsonic ammunition. It makes adding initspeed to the weapon to simulate internal ballistics in the first place, kind of redundant if it only works with one kind of magazine.

Using a coefficient in the magazine and saying this ammunition will leave the barrel of any weapon at 20%/50%/70% of the speed that standard supersonic ammunition would leave that same barrel, is more consistent with what would happen IRL.

For any magazine with the coefficient set to 1 they will use the stated muzzle velocity of the weapon, for 'overpressure' loads you will get a % increase in muzzle velocity for all weapons by setting the coefficient >1, and for all 'under-pressure' (subsonic) loads you will get a % decrease in muzzle velocity for all weapons by setting the coefficient <1.

you are right - so what about adding initspeedcoef in the magazine class?

[Brisse 78]

How about having an array in magazine config, where you can define several muzzle velocities depending on barrel length, and then defining barrel length in weapon config? Problem solved.

[Robalo 465]

Should be done like this IMO:

class weapon {
class initspeed {
  b_556x45_m855= 850;
  b_556x45_mk262 = 800;
};
};

configure velocity in weapon for each ammo type

[noubernou 77]

Holy crap this has been implemented in the WORST possible way. I don't know who decided this, but wow. This is NOT how you improve weapons configurations, this is how you make them horrible. This is reverting pretty much every improvement BI has made since OFP to magazines and weapons.

Want to know how to fix this?

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

This is how it should be implemented, the current implementation does nothing to make life easier for modders, just harder.

[kllrt 154]

I really like Nou's idea, that would be the best easy and possible way I can think of.

Since we already have some initspeed defined for magazines, that new coef. will weapons inherit from weapon base = backward compatibility. BI pls.

[Sterlingarcherz101 15]

Any word on the broken at lock on. Rocket locks are dropping and hitting the ground infront of targets.

[Robalo 465]

Holy crap this has been implemented in the WORST possible way. I don't know who decided this, but wow. This is NOT how you improve weapons configurations, this is how you make them horrible. This is reverting pretty much every improvement BI has made since OFP to magazines and weapons.

Want to know how to fix this?

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

This is how it should be implemented, the current implementation does nothing to make life easier for modders, just harder.

That'd be great too, sort of what I have proposed here: http://feedback.arma3.com/view.php?id=12125

Still I think per weapon per bullet initspeed would allow most accurate implementation without adding much complexity.

And next implement per weapon per bullet dispersion ;)

Edited January 19, 2015 by Robalo

[da12thMonkey 1943]

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

As I said before the problem with making it a muzzle velocity multiplier/coefficient in the weapon at the moment, is that the game doesn't seem to be taking the coefficient/multiplier into account when resolving zeroing/distancezoom calculations. It only uses the base initspeed value from the magazine (and now weapon).

You can check how something to the effect of adding a coefficient to the weapon behaves ingame with the class MagazineCoef initspeed float in Muzzle attachments. Sticking a muzzle accessory that increases MV of the magazine causes the POI to shift upwards at the range that the sight is zeroed at, and using an accessory that decreases the MV causes the POI to shift downwards so the weapon/sight is no longer zeroed to the range it says it is. This effects the zeroing of all optic modes whether they are the inbuilt ironsights or attachments.

BIS would need to fix the zeroing calculations to accomodate multipliers/coefficients to fix this, because in all instances weapons/optics should be zeroed to the current barrel length when using a predetermined cartridge. The shooter has to make manual adjustments to the POA or re-zero the weapon to accommodate changes in ammunition from the one they were originally using to zero the weapon. That's why I feel it's better to put the multiplier/coef in the magazine than the weapon unless BIS fix the zeroing calculation.

Edited January 19, 2015 by da12thMonkey

[noubernou 77]

That is simple, BIS needs to fix their stuff. Poorly implementing bandaid fixes does nothing but frustrate the mod makers who then have to compensate for it, wasting our time.

The fact of the matter is bullets should be bullets, weapons should be weapons, there should be no requirement between them beyond the fact that they are correctly chambered for that round. Everything else should be independent. Linking the two together is just a frustrating experience for everyone.

[CaptainAzimuth 714]

Holy crap this has been implemented in the WORST possible way. I don't know who decided this, but wow. This is NOT how you improve weapons configurations, this is how you make them horrible. This is reverting pretty much every improvement BI has made since OFP to magazines and weapons.

Want to know how to fix this?

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

This is how it should be implemented, the current implementation does nothing to make life easier for modders, just harder.

Perfectly said. I second (2nd) this resolution.

[DancZer 65]

And if you add a silencer to the weapon, you just add silencer multiplier to weapon's multiplier?

[pettka 694]

One thing that has not been mentioned in the changelog regarding the initSpeed in weapons may be interesting for you: Using negative value for initSpeed in weapons takes the property from magazine as before. We are going to discuss a few possibilities, but feel free to set:

initSpeed = -1;

in the weapon class to have previous behaviour :icon_twisted:

[ImperialAlex 72]

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

Using a coefficient in the magazine and saying this ammunition will leave the barrel of any weapon at 20%/50%/70% of the speed that standard supersonic ammunition would leave that same barrel, is more consistent with what would happen IRL. For any magazine with the coefficient set to 1 they will use the stated muzzle velocity of the weapon, for 'overpressure' loads you will get a % increase in muzzle velocity for all weapons by setting the coefficient >1, and for all 'under-pressure' (subsonic) loads you will get a % decrease in muzzle velocity for all weapons by setting the coefficient <1.

Either of those options seems like an improvement over both the current standard and the new dev branch version. Because of the zeroing issues mentioned, I'd probably even prefer the second version.

The second solution is very simple and elegant and seems to deal with the current zeroing implementation in a more graceful way.

For backwards compatibility, you could keep giving magazines a speed and revert to old behaviour if the gun doesn't have a speed set.

Edited January 20, 2015 by ImperialAlex

[evromalarkey 150]

http://feedback.arma3.com/view.php?id=22344 is this known? Would be good to fix it before 1.38 release. When you're using a lot of mods, tt's kind of annoying to have on screen errors about missing logos, everytime you open something in editor.

EDIT: Never mind, seems to be fixed in latest RC now, thanks! ;)

Edited January 20, 2015 by EvroMalarkey

[roberthammer 582]

Also the SOS, DMS and Nightstalker backup sights blur returned > http://feedback.arma3.com/view.php?id=22337

[St. Jimmy 272]

Added: Config support for the dehardcoding of the number keys and function keys

Changed: Unlocking hardcoded number keys and function keys

Woah woah could we finally make use of number keys as we like in the future? :eek: Big news if so!

/Oh my freaking god it has happened And F-keys are also free!

Though it would be bit better if command menu opend from one key press and you continue there through the menus. It's hard to remember where every command category is when the only way is to find it with trial and error through the number keys. For example I can't remember what is under 4. I could know if a menu pops from key that contains all the main categories and you can easily proceed from there.

So number keys could be hard coded if wanted but they're not in a way because nothing opens from number key alone (unless naturally one of them is the command menu key.) and we could use them also for whatever we want.

Just like in Wolfenstein, CS (likely in every source engine game), Warthunder, Planetside 2 etc. games that have quick chats but in this game it could be commanding menu.

So if I press a command menu key (for example U) this menu opens. When that pops up you can navigate though the menus with number keys and when the menu is open only menu interaction is possble with number keys.

1. Move

2. Target

3. Engage

4. Mount

5. Report

6. Action

7. Combat Mode

8. Formation

9. Team

0. Reply

I don't need to remember where the hell were those combat modes when I can clearly see where they're.

This would be MUCH MUCH MORE USER FRIENDLY solution.

If BIS doesn't do it I hope someone can mod it. Would free 9 keys from a keyboard and make commanding finally bit better.

Edited January 20, 2015 by St. Jimmy

[twisted 127]

Want to know how to fix this?

Add muzzle velocity multipliers to weapons. Each magazine should define it's initSpeed of a muzzle velocity from idealized barrel length. Ammo cartridges have a set, specific impulse of energy, and to drastically simplify, the main thing that affects internal ballistics is barrel length. If you define the initSpeed in the magazines as the muzzle velocity for a "perfect" barrel length you can then define a multiplier for initSpeed in each weapon that scales it up and down for the specific weapon.

This is how it should be implemented, the current implementation does nothing to make life easier for modders, just harder.

nice idea. would allow for exact velocities. On the range i find different ammo each has a different feel and obvioulsy a different muzzle velocity. but i might be misunderstanding how would this system cope with different barrel lengths? what'd be the perfect length? there can be a pretty noticeable difference in each length - here's just one article on it i found quite interesting. http://www.thetruthaboutguns.com/2013/10/daniel-zimmerman/the-truth-about-barrel-length-muzzle-velocity-and-accuracy/ - the conclusion they come to is surprising and I'd say deserves more testing but the changes in velocity are what's more interesting to me.

Edited January 20, 2015 by twisted

[haleks 8206]

So if I press a command menu key (for example U) this menu opens. When that pops up you can navigate though the menus with number keys and when the menu is open only menu interaction is possble with number keys.

1. Move

2. Target

3. Engage

4. Mount

5. Report

6. Action

7. Combat Mode

8. Formation

9. Team

0. Reply

I don't need to remember where the hell were those combat modes when I can clearly see where they're.

This would be MUCH MUCH MORE USER FRIENDLY solution.

If BIS doesn't do it I hope someone can mod it. Would free 9 keys from a keyboard and make commanding finally bit better.

Agreed! Right now it's tedious to lead a squad - I have a hard time keeping my eyes on screen as I have to check what I'm doing on the keyboard each time I give a specific order...

It's getting tiresome to loose men because of stupid mistakes when fiddling with that commanding system (the fun I had yesterday when playing the ambush mission from the campaign...).

[St. Jimmy 272]

Seems like F keys (at least F2) can crash the game.

Anyone else?

I still have default controls so I'm selecting a unit.

Ticket http://feedback.arma3.com/view.php?id=22355

[CraftyBadger 10]

Agreed! Right now it's tedious to lead a squad - I have a hard time keeping my eyes on screen as I have to check what I'm doing on the keyboard each time I give a specific order...

It's getting tiresome to lose men because of stupid mistakes when fiddling with that commanding system (the fun I had yesterday when playing the ambush mission from the campaign...).

I once mentioned a while back about using a simple interface to control squads. This could be optional just like AFM

Example GUI - (KarelMoricky/status)

You could select all these on one screen as selectable icons. with a decent description of what the ai does because it's not always obvious.

Modes Tab

• Fire mode / Engagement
  
• Combat Mode & Speed
  
• Formation
  
• Stance
  

Movement Tab

• Advance
  
• Stay back
  
• Flank Left
  
• Flank Right
  
• Stop
  
• Wait for me
  
• Find Cover
  

You either bind it to a key or have it bound to a number key command. what do people think this system hasn't improved since OF

Someone mentioned about presets/macros so you could do all this complex setup then just save it as a preset. that would be available via another key.

[royaltyinexile 175]

Seems like F keys (at least F2) can crash the game.

Hm, this issue appears to only affect the public development build - we're sorry about the inconvenience.

Up until he makes his first forum post, complaints should be directed here.

Best,

RiE