UserAction class in config.cpp

You can add lines into the user action menus by...

1. Calling the AddAction command

2. Adding one into the UserActions class in the addon config.

If you are making the addon yourself the 2nd option would be more convenient, but it seems to be much less flexible. At least for these I haven't found a solution when using the UserAction class...

- How the get the person trying to access the menu ('this' is the object to which the menu is tied)?

- How to hide menu item from showing automatically when approaching?

Should I start putting AddAction commands into the init event handler? :confused:

Hi there,

how to catch who called the user action in a config file. Here I can quote the source code of my VFAI.ControlPanel:

class CfgVehicles {
class CaManbase
{
	class UserActions
	{
		class VFAICpanel
		{
			displayNameDefault = "VFAI Control Panel";
                               showWindow = 0;
	                hideOnUse = 1;
			displayName="VFAI Control Panel";
			position="action";
			radius=0.10000;
                           	onlyForPlayer = 1;
			condition="(alive this) && (this == leader group this)";
			statement="this execVM ""\VFAI_ControlPanel\vfaictl.sqf""";
		};
	};	
};
};

The "condition" part btw checks whether the caller is alive and the group leader. Noone else should inherit that UserAction.

Secondly, visibility of user actions. With my config above nobody else is able to see or use my useraction.

Cheers,

VictorFarbau

Thanks for the comments. Already thought nobody knows or nobody cares.

That showWindow is one of the things I was chasing :o

The other thing...your case is bit different as it is tied to the person who is accessing it. In my case it is tied to a vehicle. It starts a script which needs both the vehicle and the person who selected it. I think I have to rethink it.

The fact that nobody else sees your menu must be that you cannot get within 10cm of the person while he is alive (collision).

correct inheritance would be

class Man;

class CAManBase: Man

{

...

@Aqu:

nobody knows or nobody cares.

No spring time depression, please :D

And interesting, are you sure about the 10cm radius? At least when adding the action by script (AddAction) it places a bigger radius, I thought. But as I was happy with the outcome now I didn't check any further.

So you need caller and calling vehicle? I believe in the engine's rationale the caller is always the object the trigger is attached to (in your case the vehicle). I guess the only useful thing to do is to try all scenarios and dump the current value of "this" repeatedly. Maybe at some point it changes to an array. In my config it always just returns one object.

@kju: I think you're referring to the standard config.cpp right? Because as an addon the useraction is being placed under CAmanbase under CfgVehicles for some reason. And this is code that works...

Cheers,

VictorFarbau

And interesting, are you sure about the 10cm radius? At least when adding the action by script (AddAction) it places a bigger radius, I thought. But as I was happy with the outcome now I didn't check any further.

Well, just looked your code...

"radius=0.10000;"

That's 10cm, right? The default radius is something bigger (1-2m?).

The annoying thing is that the UserActions class and the addAction are not fully interchangable. For example addAction cannot be given that radius. If you wanted that, you would have to code it into the condition but BIS left that out too (VBS2 addAction has it) :(

So you need caller and calling vehicle? I believe in the engine's rationale the caller is always the object the trigger is attached to (in your case the vehicle). I guess the only useful thing to do is to try all scenarios and dump the current value of "this" repeatedly. Maybe at some point it changes to an array. In my config it always just returns one object.

In your case that assumption sounds reasonable, but you cannot expect e.g. the house with an open door action to be the caller. In the UserActions condition 'this' seems to point the object where the action is attached to. In the addAction you get an array like [target,caller,menu id] into the script. I guess mostly you can live with just the 'target' (e.g. hardly maters who opens the door - which door is much more important). In some cases, like an ATM machine, both are needed in an action "insert card".

Well, just looked your code...

"radius=0.10000;"

Gosh, I fiddled around with too many configs lately; getting blind apparently. Yes, the 0.1 radius is of course the choice when adding triggers to people.

Anyway, I had a look at the AddAction command again. Have you considered the long parameter version already?

In my view the "showWindow" parameter basically describes what you're looking for. Haven't tried it now but it sounds as if it turns off the automatic display of that entry when approaching; nonetheless it should still be there when manually opening that menu. That doesn't address the issue with radius but at least people wouldn't have that action text in their face all the time.

Given that it really does what the description implies.

Cheers,

VictorFarbau