Help with selectPlayer

[madrussian 347]

Pretty stumped here and hope someone can help! The trouble is regarding selectPlayer and having two players co-habitate the same group.

First off, for those who have yet to attempt the selectPlayer command in MP, let's just say it's... fraught with hazard. The primary complication is that if you selectPlayer to a unit that is not local to your client computer, the takeover will occur but the player will be left with no control over the intended unit.

Fortunately, I was able to get selectPlayer working correctly on a MP client by first making the desired unit local to the client, as specified in the selectPlayer notes (via a Game Logic created on the client, which is always local), using this code:

_tempGrp = group Loon;
ClientLogicGrp = createGroup sideLogic;
"Logic" createUnit [[0,0,0], ClientLogicGrp];

[Loon] join ClientLogicGrp;
selectPlayer Loon;
[Loon] join _tempGrp;

Good so far. Client computer has taken over Loon with full control, as expected.

Here's where the trouble comes in. At this point, if I join the server player to the group (so the players are together), both players maintain distinct locality (and thus control), provided that the client unit is the group leader, which is good. HOWEVER, as soon as I make the server unit the leader, the client computer loses locality over the client player unit and thus control. :eek:

For those interested, I'm working on a Group Linked Respawn system, similar to the one in Ghost Recon 1 MP. Works just like "GROUP" respawn in ArmA2, only when you lose your last unit in one group, you takeover a man in the next group. There's also a death cam and the ability to return to play as a new unit if mission allows (i.e. remaining players find survivors, reinforcements provided upon objective completion, etc). It's going better than I expected (streamlined and user friendly) and I'd like to finish and release it to the community, but for now I've hit this snag.

It is absolutely critical to be able to have two players in the same group, with either the server unit or the client unit as group leader after a character takeover. BIS does this routinely with both "GROUP" and "SIDE" respawn, so I know it's 100% possible.

Any ideas on how to maintain client unit locality when the server unit takes over as group leader?

When there's a will there's a way! Any help is much appreciated! :)

Edited October 13, 2011 by MadRussian

[twirly 11]

For those interested, I'm working on a Group Linked Respawn system, similar to the one in Ghost Recon 1 MP

Still play this online with friends to this day...you cannot beat the immersion in GR!... So I'm interested. Sorry can't help you though because I haven't done any MP programming at all. As soon as I realised that the AI was warping in Arma (many years ago) and the problem wasn't with me.... I decided it was really just a waste of time. My friends won't play it even after I bought it for them... and I really can't blame them. I won't either.

The new Betas seem to be doing something about the warping....but I guess I have to put my trust in the people who know what they are doing in MP to test that.

EDIT: Not sure if you've seen this post or not... but this might help. It seems you have to fudge it in some way!

http://forums.bistudio.com/showpost.php?p=2035973

Edited October 13, 2011 by twirly
Clarity

[.kju 3242]

Not possible AFAIK (to overcome the locality limitation/issue).

Why are you not just coding your own group respawn instead?

[madrussian 347]

Oh the good old days of GR1, 3 groups of 3 men each. Perfect for a nice co-op with you and just a friend or two! Thanks for that thread link twirly. :) I checked it out... Interesting and informative, but not related directly to selectPlayer and locality.

So to summarize the issue above:

• I can get a selectPlayered client player and server player into the same group, with both players maintaining respective locality and thus in control of their respective units.
  
• When selectPlayered client player is the group leader and server player is his subordinate... both players retain control of their units.
  
• But when server player is made leader and selectPlayered client player is his subordinate... client player's unit locality is magically switched back to the server, resulting in loss of control on the client computer.
  

If only I could see exactly what BIS is doing when they perform a team-switch or a "GROUP" respawn death / subsequent unit takeover. I spent a considerable amount of time pouring over "CA.pbo" contents. Found all the "Event Scripts" related to respawn in there, including "onplayerkilled.sqs", "onPlayerrespawnOtherUnit.sqs", "onPlayerRespawnAsSeagull.sqs", but these don't actually do any player switching. They mostly consist of what the camera does. The selectPlayer or similar (facilitation of character takeover) that BIS is doing is located somewhere else apparently.

Anyone know where I might find the BIS code for unit takeover? Certainly it's not hard-coded?!?

Alternately, I wonder if there is any way to detect in-game the default code that gets run upon certain events, such as the default "killed" event handler, etc.

In any event, I am confident if we can see what BIS is doing to maintain player control during a unit takeover, we can do it too!

EDIT:

@PvPscene

I'd wager that it is indeed possible. Otherwise, how is BIS doing it? :)

Regarding my group linked respawn, my goal is to have multiple player lead groups, with "GROUP" respawn style automatic unit takeover and the groups linked in the sense that when you lose the last man in one group, you takeover a unit in another. Also the ability for dead players to "return to play" (from deathcam) when new playable units appears later in the mission, which regular "GROUP" and "SIDE" respawn do not permit. For various reasons, it is important also that the players be allowed in the same group.

Edited October 13, 2011 by MadRussian

[.kju 3242]

Intercept a kill event with the killed EH or HD EH.

And handle the events yourself from there.

Ditch the idea of (fully) working groups with selectPlayer.

You could consider to use high command instead for some basic team management.

[madrussian 347]

The important thing to re-emphasize here is that BIS are somehow able to perform functional unit takeover without any lost control on client computers (via "group" and "side" respawn). Players on any machine (client or server) routinely takeover as group leader, while other players remain in the same group as subordinates. All the while no one ever loses control!

It's not magic. How are they doing it?

[.kju 3242]

In group respawn your (id)entity is moved into the new unit.

With selectPlayer not (fully). See the difference?

Yes BI could fix it - if/when they do, we have to wait and see.

[madrussian 347]

Yes, I'm aware of the identity transfer issue with selectPlayer, and I too hope they address it someday. However, selectPlayer will work just fine for what I'm trying to accomplish despite the identity issue.

It's the client losing locality that is the deal-breaker currently. I'm almost certain there is a workaround, as BIS takeovers work 100% as expected. If I could just get one quick look at that BIS player unit takeover code! Does anyone suspect it is indeed hardcoded in the game engine and not in a PBO somewhere? Any way of finding out definitively?

[madrussian 347]

Alright... made some major progress towards solving this (I hope). Managed to get both the selectPlayered client unit and the server unit in the same group... with both players simultaneously as group leader! No loss of control for either player. Each player can command the AI in the group. Yeah, it's kinda strange, but certainly a step in the right direction. :D

Also, I uncovered references to some Hidden Event_Scripts. Three new and mysterious files in addition to the three regular event scripts. Here are the new and exciting ones, which I am certain actually execute the working default "GROUP" and "SIDE" unit takeovers:

• "onPlayerRespawn.sqs"
  
• "onPlayerResurrect.sqs"
  
• "onTeamSwitch.sqf" (not to be confused with the onTeamSwitch command, which does something after the teamSwitch is complete).
  

If I can find a way to see inside these hidden Event Scripts, I should be able to smite this selectPlayer "lost locality -> lost control" issue in short order.

I will not be deterred.