Opsive.Shared.Events : Event System Problem

[James]

Hi, trying to figure out why I can't get this script to work.

It's attached to the Weapon object which has the ShootableWeapon script.

What I am attempting to do is implement an overheating feature that stops the weapon from firing when overheated. I may need to modify ShootableWeapon, however, this is just my attempt at using the event system but so far no luck.

using UnityEngine;
using Opsive.Shared.Events;

public class WeaponThermalMonitor : MonoBehaviour
{
void Awake()
{
EventHandler.RegisterEvent<GameObject, bool>(gameObject, "OnShootableWeaponShowProjectile", OnFire);
}

void OnFire(GameObject projectile, bool show)
{
if(show)
Debug.Log("Fire Event");

}
}

 

[James]

I seemed to have resolved my issue by adding
EventHandler.ExecuteEvent(m_Character, "OnShootableWeaponShowProjectile", m_SpawnedProjectile, true);

At line 845 in the ShootableWeapon script, was this not intended to be there and will this now cause any possible side affects?

 

[Justin]

Instead of the OnShootableWeaponShowProjectile event I would instead subclass ShootableWeapon and override the Fire method. This is more generic than the projectile event and should work for your use case.

 

[James]

Hey Justin, thanks. I just made some minor mods to the ShootableWeapon class, included a boolean for ThermalWeapon and added a condition on CanUseItem. The Event is still used to call back the custom class used to manage the thermal heat levels but overall its works perfectly.

I add the ThermalWeapon component/script to the weapon object, ShootableWeapon determines if the component exists, if it does, flags the Boolean as true then uses the class to manage the heat levels.

 

[Andrew]

Glad you found a solution, but be careful when modifying base UCC classes (e.g. ShootableWeapon) directly - if you ever update UCC in the future, it's likely that you'll lose your changes. One solution to this that I've used before, is to wrap any changes you've made in comment tags, like so:

// @mycode - start
MyCustomCode();
// @mycode - end

That way when you update, you can just search the code for those tags and copy them over. But as Justin suggested, subclassing where possible is always advised, so that you don't run this risk.