-
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
WIP: Arma vanilla magwells #1030
Conversation
Inherit CBA ones from BI ones, remove 1 or 3 versions later. |
Drop the "This is" and just write |
You should name "the vanilla one". |
|
I would like to see how the vanilla classes look like. Where are they ? Dev ? RC doesn't have any. |
My 0.02€ Unless vanilla implementation promises to get as developed as the current CBA one, deprecation should work the other way around. Deprecate vanilla classes and use a the complete and consistent CBA classes. |
@robalo They look like this https://pastebin.com/bfa806BH |
What’s about e.g. the 100 Round MX magazines? The are commented out in the pasteboard but belong to the same config like the 30 round MX. Would be easier for us to stay on CBA-only magwells |
Weapon and magazine mod makers will always want to use the Vanilla variant, because they also want to be compatible with users who are not using CBA. |
I'd rather have just a few duplicates - seeing how few the vanilla classes are (if those are real) - than confuse the hell out of everyone with a mixed approach. |
@Kllrt is a BI dev btw. |
I had no idea :D 🙇 |
If we are going to keep vanilla magwells I guess we might want something like
|
Btw why do we indent everything in the include files by one level? |
Waste of space. |
Noticed the magwells were added in latest update. IMO to keep the implementation clean we should go with inheriting from the base classes. Even if it will cause some updating classes RPT errors, for existing JAM-based configs, it won't break the game and they will be spotted and fixed easily. What I don't like and expect will happen regardless of how we do it is modders throwing all their mags in the vanilla classes without care for the standard/large/drums etc distinction we have already. I still think that we should inverse the deprecation messages and say for example don't use AK_762x39, use CBA_762x39_AK and CBA_762x39_RPK instead. |
Inheritance was broken. And I didn't hear of a fix so far. Theoretically.... Could we do both? Have a inherited CBA class (once inheritance is fixed) and a seperate one too? Nah... I guess that will make things worse? Not sure. So far I'm on the "deprecate vanilla ones" side too, even though I still don't like having everything twice... @commy2 seperate PR to fix that someday? |
won't that lead to problems with mod load order? |
class GL_3GL_F : UGL_F { | ||
magazineWell[] = {"CBA_40mm_3GL", "CBA_40mm_M203", "CBA_40mm_EGLM"}; | ||
magazineWell[] += {"CBA_40mm_3GL", "CBA_40mm_M203", "CBA_40mm_EGLM"}; |
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.
There is no 40mm magwell in vanilla.
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.
+= won't break if the array exists right? So it doesn't really matter
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.
Yep, but that's the thing, doesn't exist, same thing on the UGL_F parent.
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.
Actually meant the opposite as what I said. So does += here break in it's current state? or is it just a minor issue?
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.
Last I checked this kind of array addition combined with inheritance was really finicky.
The above bits seem fine though, did a quick check and magazineWell is populated.
How about this stupid idea: we go with all new untagged classes, vanilla style, extending current vanilla implementation, deprecating everything CBA_ in magwells. |
It might work, but it'll be kind of a pain. |
Ideal would be if we could give extra classes to BI to add to vanilla... @Kllrt! |
Yes. But Arma doesn't see it that way. The magazine code doesn't look through parent entries.
And take a month or two everytime someone notices that something is missing? Ideal would be to put everything of CBA into vanilla... Sooo... |
Well that's what you get, it's in vanilla, that's a big enough pro for a small wait of 2-3 months. |
So which way from here:
For 1. I still feel that we should not deprecate existing CBA magwells in favor of vanilla, Keeping them may cause some duplication to pop up but don't see what harm that may cause really. |
I vote 2, 1 if 2 won't go through. |
Voting for vanilla in parallel with CBA. |
Is this obsolete now? Close? |
@commy2 yes. |
This is how it would look if we replace our magwells by the vanilla ones.
Need feedback. What do we do?
Leave the BI magwells be and just make our own duplicates?
Add inheritance? Problem with that is, mods that already add onto the CBA classes will break when we add inheritance. But right now it's soon enough that we can still do it.
Also the BI magwells are missing the reload tracers
30Rnd_556x45_Stanag_green, 30Rnd_556x45_Stanag_red and the mx variants.