I created a topic for this already, but deleted it because my description was bloated and unhelpful.
Long story short, without using acceptOnce every frame, is there a way for me to only throw an again event for a from object when another from object associated with the first is actively colliding with a valid target?
I should mention that I want one class to handle several instances of this, so that one objects “checker” doesn’t give the go-ahead to another object’s “doer”.
Hmm… Offhand, the only way that I see of doing this as you describe (aside from modifying the engine) is by using the “in”- and “out”- collision-events of the second object to register and unregister events for the first object.
However, this could become clunky if you intend to have more than one such pair of objects–especially as it would call for separate events for every “first object”.
What I’d suggest instead is to allow the “again” event to fire regardless of the state of the second object. Then, within the method that said event calls, have a check that only runs the code within when the second object is in the desired state.
As to making a class to handle this behaviour, one could do that, I daresay. You might have instances of the class store the two objects, and use Python-tags to associate the them with their class-instance. That would allow you to access the class-instances within the collision-events that are generated for the objects, and thus set or check a boolean value stored within those instances.
(But be careful to clean up those Python-tags on destruction of the class-instances–if left in place, the tags would create a cyclic reference that can interfere with garbage collection, I believe!)
I’m sorry for being slow to mark this as the solution been busy with school.
Reworking my spawn player function so it is instead a class that inherits from nodepath would have some additional advantages, like making it easier to store player information.
It’s not a problem! 
Actually, I’d hesitate to inherit from NodePath, specifically: NodePaths (As opposed to the nodes that they reference) may be constructed by the engine on the fly. Thus, if you were to attempt to access your NodePath at a later point by a means other than just using a reference stored in a variable by yourself–such as by searching the scene-graph, or, I imagine, in a collision-event–you might well end up with a new NodePath that is not of your new sub-class, but that nevertheless points to the intended node.
PandaNodes have their own problems, too, I believe, stemming from the fact that they’re C++ classes beneath a Python wrapper.
What I’d suggest instead is that you create a class of your own that manages the logic side of things, and that stores a reference to your NodePath within a variable. I would then suggest that your NodePath store in a Python-tag a reference to the associated instance of this new class.