Prevent Player as gunner from directing AI driven vehicle

[Carroll]

Done some searching but couldn't find anything specific regarding my latest hurdle.

The vehicle i'm working with is an Empty RHIB

Is there a way to prevent the Player (which is the gunner) of an AI driven vehicle from directing the AI Driver where to go? I have the AI following a waypoint to the beach, but as soon as the Player touches the direction keys of the keyboard the Player assumes control of the vehicle. Well i do not wish for this to be the case, i just want the gunner to gun, while AI driver follows his waypoints.

I thought of using the "DisableUserInput" Command, but this would prevent the Player from aiming the gun wouldn't it? and i have been warned against using this command in case it is not re-enabled properly.

I have no problems getting the Boat to beach itself using "setVelocity", but i need the AI boat driver to stay on task to the last waypoint. But if i accidently touch a direction key while gunning the rest of the gunning mission is ruined because i then have to steer the boat myself from then on. I also tried ungrouping the Player from the Driver and using an Empty Boat, but as soon as i moveInGunner the Player, the AI Driver goes nowhere.

Hope some of this makes sense to somebody...Please let me know if there is a way of getting around this, or if i have overseen a command or something.

[Mandoble]

Make the driver the leader of the group instead of the player.

[Carroll]

Yeah i tried that too, but even if the AI Driver is Ranked a Major, & the Player ranked a Private, Player can still command the Driver (whos the leader of the Group) to go fast, halt, left, right, etc.....thats why i thougt it so weird. My first test i set the AI Driver as leader. After a just one command has been given, the Driver follows that course & does not return to his WP 

[Planck]

It seems according to the config for the wheeled.pbo that the driver is not the commander for the stryker, so that just leaves the gunner as commander.


Planck

[Carroll]

Hey Planck,
              I'm using a RHIB Boat, i guess what that you say, same can be said for all Vehicle Types? By rights, i guess the gunner should have direction control over the vehicle he is in, considering he is the one spotting Units & shooting at them. This would work fine & logical for most normal situations, however i need the AI Driver to stay on task to his WP's.

Do you think there may be a work around to prevent this from happening in my case?

I've read about disabling keyboard keys somewhere in the forums, though i don't know if this is the way to go about it.

> I'll explain my exact situation in a bit more detail so that it is a little clearer, perhaps someone here has came across the same situation & found a cure;

1 Empty RHIB Boat named Boat1
1 Independant AI Pilot named Driver1, Rank: Captain, Init: Driver1 moveInDriver Boat1
1 Independant Soldier named Gunner1, Rank: Sergeant, Init: Gunner1 moveInGunner Boat1 (this unit is the Player)
(I'e tried grouping the Units together, & apart, though same result)

Boat starts about 500 metres to sea, then i have given Driver1 one waypoint that is very near the shoreline, when the boat reaches that WP the boat lurches up onto the beach using a "setVelocity" command. Simulating a mini D-Day type effect type of thing.

Anyway, even tho the Player is not the leader of the group (or not even a member of it), the player can still issue direction commands to the AI Driver , & once this is done, it seems the AI Driver begins to follow this new course & never returns to his assigned WP. Thus the WP which activates the beaching of the Boat is not reached...spoiling the whole thing

[Wolfrug]

Well, as I see it, this is one of those hardcoded features that you need to overcome with a bit of clever scripting ^^

First of all, you need a good way of finding out when the player has inadvertedly "taken control". One way might be via the expectedDestination command. Sorry about linking outside of OFPEC, but the comment by Donnervogel there is quite interesting if it's true. Test it out; see if either the expectedDestination array changes when the player issues move orders, or if any other element of the array changes (such as planningMode).

Once that's done, what you need to do is a simple script which puts the boat back on track - basically to make its "real" commander re-issue the move order it had originally. Yes : the player can do his damndest to try to move the boat around, but the player can always do his best to ruin a mission, so I'm guessing what you want here is more a failsafe against someone accidentally clicking the move key rather than forcing the player to do something. Sort of.

Since you're using a waypoint, one of the more effective ways is simply to move the waypoint slightly - this will prompt the AI commander to reissue the order. In fact, you don't have to move the waypoint at all, but even a setWPPos on its current pos will be interpreted as the waypoint "moving". Anyway, something like:

Code: [Select]

//code here that checks for player interference
_wp = [groupName, 2];
_wp setWpPos (getWpPos _wp);

Note that the _wp = line is supposed to point at a waypoint - that's the format eachWP has, first the group name, then the waypoints number. If I remember correctly, Waypoint Nr 1 is automatically spawned on top of the unit's starting position, waypoint nr 2 is the one after that and so on (alternatively wp nr 0 is spawned on top of the unit etc). Group name is the group's name (made with group1 = group this in a group member's init field). In the above example the group's name is groupName and the waypoint is Nr 2.

If you prefer an -even- easier solution, but one which is IMHO a bit needlessly resource-intensive, a loop like this might work:

Code: [Select]

while {Player == (gunner boat1)} do {(driver boat1) doMove (getpos YourMarkedPosition); sleep 1};

The above -should- issue a constant silent command to move to YourMarkedPosition (for instance a game logic unit named YourMarkedPosition), which -should- override any manual move commands. But I don't know. It's all untested. 

Good luck!

Wolfrug out.

[Carroll]

Thanks everyone for your help, all very interesting.

@ Wolfrug,

Yes : the player can do his damndest to try to move the boat around, but the player can always do his best to ruin a mission, so I'm guessing what you want here is more a failsafe against someone accidentally clicking the move key rather than forcing the player to do something. Sort of.

^Yes this is exactly why i need to acheive this. If someone is going to play the mission, there is always the possiblity that the Player could accidently press some direction button on their keyboard causing the AI Driver to move off course - even if i put a bunch of warning text at the start of the mission, it would do squat to remove this possiblity.

(alternatively wp nr 0 is spawned on top of the unit etc)

^i've worked a little with scripting WP's to markers so i understand what your saying about the WP order numbers...so this shouldn't be a problem hopefully.

while {Player == (gunner boat1)} do {(driver boat1) doMove (getpos YourMarkedPosition); sleep 1};

^This looks something like what i will be needing

I'll get back to it & see what new results i come up with using these insights.....

[Loyalguard]

If expectedDestination does not work as suggested by Wolfrug above, you might also try displaySetEventHandler for display 46 and keydown so that every time the player presses one of the simple command keys (W,A,S,D etc or other keys found with actionKeys) it runs one of Wolfrug's code suggestions.  This is also untested but I thought it was worth considering.

[Mandoble]

Try this:

Code: [Select]

// init.sqf
gunner_code =
{
   private [_keys_to_avoid, _return];
   // W, A, D and S (add more keys if needed)
   _keys_to_avoid = [17, 30, 32, 31];
   _return = false;
   if ((_this select 1) in _keys_to_avoid) then
   {
      _return = true;
   };
   _return
};

_display = findDisplay 46;
_display displaySetEventHandler ["KeyDown","_this call gunner_code"];


// When you are ready to allow all the keys: _display displaySetEventHandler ["KeyDown",""];


[Carroll]

Thanks Loyalguard (& Mandoble, you posted your script while i was replying to the previous) i'll look into this as well, however i had thought about the possiblity that the Player may not be using the default actionkeys....for example i have reconfigured my keyboard to use buttons that are more comfortable to me & are not default....would this be a problem with what you suggest?

~ Also regarding the mission itself, i probably should add that i am trying to build a D-Day type mission which would be to involve a number of cloned invasion boats...though this is as far as i have got, the first boat to test the beaching when i discovered the initial problem i face.
    The plan is to have a number of boats assaulting the shore, before the crews (human cargos) of each boat disembark to capture the defensive MG forts. During testing i wasn't happy with the short-sighted-ness (idiocracy) of the boats AI gunners & anyway thought that putting the Player as the gunner improves the missions interaction properties. When the Players boat is approaching the shore it takes far to much fire to ever make it to the beach, but i have overcome this by using the "setCaptive" command until the last WP which forces the craft onto the shore is reached.....If anyone playing the mission where to discover this it could be used as an exploit, as well as other reasons such as mission fluidity, time constrains, etc. Hence the need to have the Player as being both Gunner (& select targets better then AI), & being unable to interfere with the AI driven boats course.

But back on topic @Mandoble/Loyalguard, i would run into another problem if the Player had keyboard configured away from the default....woes

[Mandoble]

mm effectiveCommander always returns the gunner for RHIB, doesnt matter the group or the rank.

[Spooner]

You could use actionKeys along with the key mapping names (I think you will need "commandLeft", "commandRight", "commandForward", "commandBack", "commandFast" and "commandSlow" which default to A, D, W, S, E and Q respectively) to find out what the player's current key-setting were so that it wouldn't matter if the player was using non-standard keys.

Code: (used with Mandoble's key hander example) [Select]

_keys_to_avoid = (actionKeys "commandLeft") + (actionKeys "commandRight") + (actionKeys "commandForward") + (actionKeys "commandBack") + (actionKeys "commandFast") + (actionKeys "commandSlow");