M4A1Improvements Mutator

[Olethros]

As it seems the probably best way to add MagCheck functionality IMO is to look if the magcheck mutator is present (I tried in weapon class PostBeginPlay() and it seems to work), set a variable accordingly, which then allows the MagCheck functions.

As I mentioned in the AKS74U thread, the best way to check for the presence of MagCheck is to use DynamicLoadObject to load the MagStateMessage class. If MagCheck is not installed on the server, it will simply return 'none' and this is a far easier and - most importantly - package-independent way of checking whether to activate MagCheck-functionality. This is why I've stated earlier that people should look at the C7 source code for examples of how to implement MC in their own weapons, and not the main INFMagCheck weapon classes.

Of course, without having had a look at your source code I can't tell if you've managed to find a different way of avoiding package-dependency, but I inferred from your post that you have not.

 

[Snakeye]

Of course, without having had a look at your source code I can't tell if you've managed to find a different way of avoiding package-dependency, but I inferred from your post that you have not.

Threadjumper .

As mentioned I check the mutator list in PostBeginPlay and check if the mutators class (converted to string) is named "INFMagCheck.INFmc_Mutator"(sp?) and set a boolean accodingly. In code I do then something like:

if(bMagCheckPresent)
    Pawn(Owner).ReceiveLocalizedMessage( "INFMagCheck.MagStateMessage", 1, None, None, Self );

While this does work for MagCheck active/inactive, I'm not sure it will work with MagCheck files not present on the system; guess I'll swap to the more elegant and safe way you recommend.

 

[Olethros]

ReceiveLocalizedMessage(class'INFMagCheck.MagStateMessage', ...) = Referring MagStateMessage class directly = Package dependency = Bad.

Checking the mutator list for IMC's class name and setting bMagCheckPresent has the advantage that magcheck functionality is dependant on the mutator actually running, while simpy loading INFMagCheck.MagStateMessage dynamically only depends on IMC being installed. You'll notice that the C7 and INFmc_AKS74U will have magcheck functions activated even if IMC isn't running (as long as INFMagCheck.u is present in the System/ drawer, of course). I figured that relatively few servers would have IMC installed if they didn't intend to actually use it, so I didn't bother with this extra check.

 

[Snakeye]

Thanks for the support. I guess I'll keep the check if the mutator is active in addition, so people can deactivate MagCheck if they don't like it, instead of having to delete it.

 

[[5thSFG]Mitchell]

Umm... I'm trying to follow what you're saying, and there is one main thing which remains a bit unclear: how are you implemeting the compatibily with INF MC.

FWIK, not everyone uses it, but if you do, it's nice to make it working with most of weapons, but are you going to make a simple "link" about "what to do when pressing the MC buttoms" or are you creating a personal MC for every weapon?

 

[Snakeye]

Umm... I'm trying to follow what you're saying, and there is one main thing which remains a bit unclear: how are you implemeting the compatibily with INF MC.

FWIK, not everyone uses it, but if you do, it's nice to make it working with most of weapons, but are you going to make a simple "link" about "what to do when pressing the MC buttoms" or are you creating a personal MC for every weapon?

Basically all that is needed to add MagCheck functionality is to add a statement to the SwitchWeapon Mode function, that sends you into AmmoCheck state if the grab key is pressed, the AmmoCheck state itself (basically a shortened reload sequence) and adding the MagCheckMessage to the reload state (called NewClip, should be called NewMag ). You do not actually "link" to MagCheck, but you do use one class that's defined in MagCheck - so you have to be careful or you end up needing the MagCheck package (INFMagCheck.u) in your UT\System folder even if you don't have MagCheck active - the package dependency that Olethros warned about and showed me how to circumvent.

So in a way you have to add an own MagCheck for every weapon (since the functionality must be present in the class) and link to MagCheck itself (for the Message). It's a bit difficult to explain - I guess it's best if you take a look at the code.

 

[Olethros]

Yes, having to add the code for magazine checking to each and every weapon is unfortunately necessary, and that is exactly why it hasn't really caught on as much as people's enthusiasm for it would indicate.

But at the moment I'm rewriting the MagCheck addon for the SS bonus pack with a radically different and much cleaner way of replacing the weapon classes. Basically, it's similar to the INFmc_AKS74U mutator I posted in the other thread. All that's left is adding some really ugly tweens to the MP5K, as the necessary animations doesn't really exist for that model. (Same as the G3A3 - the charging handle is pulled back and locked in the open position before changing magazines. Which you would NEVER EVER DO outside a shooting range or similarly controlled environment!) Then afterwards I might think about revisiting that writhing nest of serpents that is the Mod Team's weapon pack.

Speaking of checking whether INFMagCheck is running, here's what I'd use:

var class<PickupMessagePlus> MSM;

Event PostBeginPlay(){
	local Mutator M;
	
	Super.PostBeginPlay();
	
	// Determine if the INFMagCheck mutator is running.
	for(M = Level.Game.BaseMutator; M != none; M = M.NextMutator){
		if(left(M.GetHumanName(), 13) ~= "INFmc_Mutator"){
			MSM = Class<PickupMessagePlus>(DynamicLoadObject("INFMagCheck.MagStateMessage", class'Class', true));
			break;
		}
	}
}

function SwitchWeaponMode(){
	if(INFc_SMaleBase(Owner)!=none && INFc_SMaleBase(Owner).bINFGrab == 1 && MSM != none &&
	!(Pawn(Owner).Physics == PHYS_Swimming || Pawn(Owner).Physics == PHYS_Falling || Pawn(Owner).Physics == PHYS_Flying)){
		if(RoundsInClip > 1) INFGotoState('checkAmmo');
		else Reload();
	}
	else super.SwitchWeaponMode();
}

Rather than adding another variable like bMagCheckPresent to the class, I'd dynamically load the MagStateMessage class in PostBeginPlay() and then just see if MSM != none to determine whether MagCheck stuff should be performed or not.

 

[Corporal_Lib [BR]]

Olethros, if you could make Magcheck compactible with all weapons available, it would be a bless... and I just love the way you´ve made the AKm and AKMSU mags&drum and Mini and MicroUzi mags interchangeable (as they should be IRL)... hope to see this feature between Mp5A2 and MP5K too

 

[[5thSFG]Mitchell]

I noticed one "curious" thing: when checking the G36 mag, he justs touches it, and it quickly says "your mag is X status", while the STANAG mag he removes it (and it disappears from view) then he put it back and only then the message appears...
Why's that?

 

[Lethal Dosage]

Ohhh! i know the answer to that one! It's a feature! It's because the G36 has a transparent magazine, the player doesn't actually have to pull the magazine out and feel it's weight as he can just look through the magazine wall to see how many rounds are in it. I think it also happens for the SG551 and P90 as well.

 

[Snakeye]

Speaking of checking whether INFMagCheck is running, here's what I'd use:...

Looks good to me - though I usually compare the whole class string (i.e. packagename.classname) - it seems like less demanding on brain energy and probably not much more demanding on characters used.

Concerning AKM and AKMSU mags: weren't they already interchangable?

 

[Olethros]

Looks good to me - though I usually compare the whole class string (i.e. packagename.classname) - it seems like less demanding on brain energy and probably not much more demanding on characters used.

I use the GetHumanName() function mostly because it's A) easy to type, and B) not affected by the package name changing with new versions. Of course, since the IMC package doesn't do this, and also you have to refer to the full class name to load the MagStateMessage anyway B is pretty much a moot point in this particular case.