-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Joint Ammo Magazines A3 #928
Conversation
IRL the HK417 and M14 magazines and mag wells are proprietary and cannot be used with the other rifle. However I have concerns about other mods that end up using the CBA magwells and then all of their M14s and 417s can incorrectly interchange. I would suggest doing an HK417 magwell as well and including the vanilla magazines in both of them as this would give mod makers the option of which class to add their own magazines to.
|
Certainly, we'll need to add SR25 and G3 magwells also. And any other common ones. |
Additionally, shouldn't everything inherit from a base magwell class so that mods can add on?
Should be this:
My_Cool_Mod:
In Game:
|
The base class is pointless if empty. |
As I understand it, if CBA does this:
And then I do this in my own mod
It will be treated as if I am creating a new |
You're wrong about that. That is not what would happen. The class would contain both entries. Base classes only have to be referenced if they exist. |
A RHS compatibility addon would look somewhat like this (not a complete working example):
|
addons/jam/CfgMagazineWells.hpp
Outdated
}; | ||
}; | ||
class CBA_556x45_MINIMI { | ||
BI_boxes[] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the 30-round STANAG mags as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. Because some variants of the Minimi no longer have STANAG mag wells IRL. So when they do, just do as above: magazineWell[] = {"CBA_556x45_MINIMI", "CBA_556x45_STANAG"};
What about mag types? It's something @dedmen brought up. Some mags housing same caliber but are of different design and/or capacity might not fit. |
How deep down the rabbit hole do you want go? Even weapons that are nominally STANAG compliant can have problems with some magazines. |
I don't know and don't really care, just putting it out there because it was a concern on Slack the other day. |
My first thought was splitting the "STANAG"s might be too much. But I wouldn't mind going 100% realistic about it provided some solid info. |
In my implementation I've split stanag small/big. Because sniper rifles only take 5/10rnd mags and not all weapons support 100/150rnd mags. Then left it to the weapon class to include both magwells. |
See, that's the thing, info on that might be hard to find or debatable. For example, why didn't you allow drum mags for HK33 in your implementation when things like this exist ? https://www.xproducts.com/product/x33-hk53-drum-magazine-for-hk33-hk53/ |
My vote would be to keep it reasonably simple. If the weapon and the magazine are at least generally STANAG compliant then have them all be interchangeable. Even for things like the PMAG and the M27. |
Sounds good. Nothing configured in 1.84. I guess they'd be doing it for 3rd party DLC. |
RHS will atleast implement them. Not sure if it would be worth to wait and see how they did it. Edit2: reyhard might push to dev branch next week. And RHS is based on the vanilla implementation. Alternatively I could ask PuFu if he can give us the RHS configs. As they are based on vanilla they should provide us all the info we need to implement it in a vanilla compatible manner. |
IMO it's only a matter of naming the classes. I'd rather see RHS use CBA tags instead of CBA use RHS tags. |
Their implementations are already done. They have nothing to consider no matter when we push this. |
RHS never cared much for vanilla compatibility, their mags didn't work in vanilla weapons nor viceversa. |
that was before RHS had a BI developer in their team.
That "whatever" is the vanilla implementation that we will get in dev-branch soon:tm: and in the next DLC.
No. The Vanilla CfgMagazineWells config classes are what I mean by implementation. Exactly what this PR is about.
But they are doing it already. They are even already mostly done implementing it.
Did a BI developer directly tell you that compatibleItems classes will be there next week? If not then that's not really comparable to this. |
Some good 2 know infos. High hopes for an aging game. Guess we'll wait and see. Thanks ! |
Something didn't add up about dedmen's argumentation, and it just hit me (good ol' showerthoughts): A significant portion of the RHS weapons have no equivalent in vanilla. They are gonna have to introduce class names for Remington 700s (two different ones even), PKs, all the 9x39mm stuff, and a variety of others. For those, other mod makers will once again have to create compatibility code between RHS and the rest of the world. Is it really so hard for them to contribute to this PR? |
Correct. These are the things we will ALSO implement then. Sadly. RHS doesn't require CBA. But I guess they could also add their magazines to our Well's. Or we add our magazines to CBA and RHS then... Or we just ignore that RHS exists and be happy that most people will see CBA as the standard and add their mags to our's. But then we need a RHS->CBA compat that add's the RHS mags to CBA. Actually. We don't need a RHS compat. We can just add their magazine classnames directly into CBA. There are silently ignored if they don't exist. And if RHS is loaded they are where they should be. Waiting for answer from reyhard. |
Silent native compatibility would make it easier on the end user, not having to download a bunch of extra mods. It doesn't however help at all with the development cycle issues behind compats: Every time RHS changes something, like adding a new mag or depreciating an old one, the mod offering compatibility is out of date for a while. Sure, CBA is a bit more organized and a bit more functionality/coding focussed than NIArms, but those compat mods have been missing the 0.4.3 mags for almost a year now. In the end, there is only one acceptable way of tackling this. CBA extends the vanilla 2035 magwells into a 2018 JAM standard, everybody else implements that standard. "Everybody" including CUP, SMA, NIArms, RHS and others as peers. |
@dedmen sadly the game throws errors/warnings for magazine declarations inside CfgMagazineWells which are not available |
Here are the RHS/Vanilla magazine wells. |
Copy-paste of what I wrote to fuxna
As example of that just look at https://github.com/CBATeam/CBA_A3/pull/928/files#diff-ddb5c69e174931ad1c5d4a5d93f8a28bR19 I think for 5,56 we can probably leave out the 5/10 rnd ones. But for 7,62 5 round magazines actually become a thing. Does anyone have anything against splitting it up like that? We could use inheritance to have the 30rnd well inherit the 5,10 and 20rnd wells. But inheritance means people have to actively put a dependency onto CBA if they want to add ..... Wait.. Do they? But even then. I think inheritance is currently broken. But it's already on reyhards list. |
Splitting up, yes. You need to step away from the number of rounds though. Example 1: M24 mags shouldn't physically fit an M40 because only one of them is a "long action" R700 (as in, long enough to support .300 WinMag). You cannot merge these two, not even their 5 round mags. Something like this would work (can't be bothered pulling up the actual class names):
That plus belts (where to my knowledge, only 7.62x51 has two different variants if you pretend everything is a loose strap) should take care of pretty much all cases. |
What is a "Coffin" magazine? Inheritance would come in very handy here as we could |
http://www.imfdb.org/images/7/7d/Avengers3_241.jpg This would be a 100 round coffin. Also known as quadstack. Difference between these and drums is width - they only clip with the weapon model, not the user. Length is a consideration when prone on the ground and because varying follower spring pressure over the duration of a mag could cause differences in how the rounds end up in the chamber, shifting your point of impact. 20 rounds for marksman rifles and 10 (or less) rounds for sniper rifles should be small enough for the latter not not be a problem, and the former is solved by drums being relatively short (often shorter than the standard size stick) plus not really modelled in the game anyway. The only actually longer 7.62x51 mag I am aware of is the OSW FAL 30 rounder - everything else is either 20 or a drum. |
As already said we need to get this in early if we want it to be accepted as a standard. I'm sure someone has a way better idea. Speak out please. |
Just make something. People will complain, and then you can adjust. And now you can even blame them back for not participating when they had a chance to make the initial decissions. |
👍
|
I agree. This PR right now has all combined magazine sizes. We could already merge this and then just add size-splits later. |
It's good to go as far as I'm concerned, I'm no big fan of making it ultra realistic but don't mind going that way too if there's high demand and good info sources. |
My vote is to merge now. In future, the most I would want to see a magwell split into sub groups would be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same. Let's get this in quick and add on in a seperate PR.
Don't close #108 yet
* master: Add Feature Camera Player EH (#982) German brands for JR and JAM components (#988) veteran29 Polish translation updates master (#986) German translation, part 3 (#981) German translation, part 2 (#980) German translation, part 1 (#979) add Joint Ammo Magazines A3 (#928) CBA_fnc_getVolume not calculating volume correctly (#984) ProjectileTracking - Stop tracking stationary objects (#985)
Add JAM.
With a PR open, even if WIP, it is more convenient to see the diffs and discuss the implementation. :~)
-close #108