A functional Swap Player method - Overcoming the limitations of selectPlayer

[madrussian 347]

While trying to solve a locality issue preventing me from using selectPlayer effectively, I happened to stumble upon references to what appears to be three hidden Event Scripts. Many of us are aware of "onPlayerKilled.sqs", "onPlayerRespawnOtherUnit.sqs", and "onPlayerRespawnAsSeagull.sqs", which are very good at... <cough> moving the camera around. Meanwhile, the BIS respawn system works its hidden magic, doing mysterious things like successfully pulling off a functional player takeover to a new unit... that ports identity! And does not lose client player control due to lost locality! And many other exciting and as-of-yet unknowable things! If only we could see inside this crystal ball and unveil the mystical secrets within.

OK, got a little excited there. A total of six references can be found inside "UI.pbo" in "config.cpp", related to player death, respawn, and teamswitch (three new in addition to the original three). Apparently, a whopping eight other people on Google found them too. Here are the six scripts:

playerKilledScript = "onPlayerKilled.sqs";
playerRespawnScript = "onPlayerRespawn.sqs";
playerRespawnOtherUnitScript = "onPlayerRespawnOtherUnit.sqs";
playerRespawnSeagullScript = "onPlayerRespawnAsSeagull.sqs";
playerResurrectScript = "onPlayerResurrect.sqs";
teamSwitchScript = "onTeamSwitch.sqf";

By my reckoning:

• "onPlayerRespawn.sqs" must handle "INSTANT" and "BASE" respawns (and probably "BIRD" as well).
  
• "onPlayerResurrect.sqs" must handle "GROUP" respawn.
  
• "onTeamSwitch.sqf" must handle "SIDE" respawn and player switching via switchableUnits.
  

One can easily do a loadFile or preprocessFile on any of these to check whether or not they actually exist in "mission space" alongside your regular mission directory files. The three regular Event Scripts can be loaded and viewed in-game via a hint. Sadly, the three new and exciting ones do not load via either load command.

So what do you guys think? I'm hoping somehow that the filenames have been changed slightly and these are perhaps old references. If that's the case, these virtual files are waiting out there in your mission directory, taunting you with their hidden secrets, waiting for someone to write a quick file scanner in sqf that looks for them. [And then let it run all weekend, scanning away. :D ]

Or they are simply hard coded in the game engine. Anyhow, only one way to find out! :)

Thoughts?

Edited October 14, 2011 by MadRussian

[twirly 11]

.....Or they are hard simply coded in the game engine. Anyhow, only one way to find out! :)

Thoughts?

I basically have the whole game de-pbo'd and did a search....found these.

teamswitch.sqf is in ui\scripts

onPlayerrespawnOtherUnit.sqs is in Ca\data\scripts

onPlayerRespawnAsSeagull.sqs is in Ca\data\scripts

Hope that's some help for you. Not much in the teamswitch.sqf.... the only line is commented out. The other two are about handling the camera and a switch to INTERNAL view of the seagull or the new player. Much like a SP respawn script I have.

Edited October 14, 2011 by twirly
Shortened post

[madrussian 347]

Thanks twirly. Interesting... somehow apparently I have more code in my "\UI\Scripts\Teamswitch.sqf" than you do, which makes me wonder. I just noticed that all (or pretty much all) the files in the Addons directory are also located in the Common directory. When comparing "Ca.pbo" from one dir to the other, turns out that the one in Addons is bigger, and the one in Common is newer. I kind of assumed that the game loads Common first, and then Addons effectively patches by loading second. Can anyone confirm?

Took a closer look inside my "\UI\Scripts\Teamswitch.sqf", and I made a startling discovery. There's a comment in there that directly refers to one of our three hidden event scripts (onTeamSwitch.sqf):

	//script executed by onTeamSwitch.sqf after unit is switched 
case "CA_TS_onTeamSwitch":
{

};	

This comment pretty much spells out that "onTeamSwitch.sqf" is indeed doing the functional player swap!!! I'd say we have our smoking gun. :)

I also noticed that most of the TeamSwitch dialog buttons are covered in there, including "CA_TS_ViewUnit", but the "Switch" button (the one that actually performs the player swap in-game), is mysteriously missing!

If these three Hidden Event scripts really turn out to not exist anywhere in the file structure, then maybe we can take a top down approach in-game. Set respawn = "SIDE", die in game, get the TeamSwitch dialog up, access it via findDisplay 632, and then try to access that "Switch" button and see exactly what it's code does (via copyToClipboard). Worth a try anyhow.

[.kju 3244]

teamSwitch.sqf is NOT onTeamSwitch.sqf

onTeamSwitch.sqf called teamSwitch.sqf at some point - maybe OFP or never.

In a1 the call is already commented out.

> the game loads Common first, and then Addons effectively patches by loading second

Yes this is common knowledge for a long time. Otherwise CO would not work.

In fact it was designed this way to allow CO in the first place.

Sorry to kill your dreams but there is no black magic involved here.

These are simple strings called by the teamSwitch dialog defined in ui config to decide what to happen:

http://pastebin.jonasscholz.de/1603

Also its everything pure SQF - no internal engine behavior (as far as I can tell).

You will not find group/base/instant respawn handling here.

It is handled by the engine 100% internally (as far as I can tell).

You really need to study the AIO config and extract all BI pbos to learn more about the game.

Use Arma2P.cmd by mikero to do that.

[madrussian 347]

Well I wouldn't call it "black magic", but BIS certainly has managed to implement a functional player swap (no locality issues, etc), and I for one would like to see how they do it! I firmly believe a functional player swap is not only possible, but can accomplished using only the commands available to us in the command ref. We just need to see how BIS does it.

Ran a quick test on the Teamswitch dialog config:

_cfg = configFile >> "RscDisplayTeamSwitch" >> "Controls" >> "CA_ButtonViewUnit" >> "onButtonClick";
hint (getText _cfg);

sleep 5;

_cfg = configFile >> "RscDisplayTeamSwitch" >> "Controls" >> "CA_ButtonContinue" >> "onButtonClick";
hint (getText _cfg);

Sure enough, the "onButtonClick" event shows up for the Teamswitch View button, but not the Switch button.

Looking inside "RscDisplayTeamSwitch.hpp", we can see how the View button has "onButtonClick" implemented, but the Switch button does not:

class CA_ButtonViewUnit : RscIGUIShortcutButton {
idc = 32;
shortcuts[] = {0x00050000 + 2};
x = 0.414724;
y = 0.609076;
text = $STR_TEAM_SWITCH_VIEW_UNIT;
onButtonClick = "_dummy = [_this, ""CA_TS_ViewUnit""] execVM ""\ca\ui\scripts\TeamSwitch.sqf"" ";
};

class CA_ButtonContinue : RscIGUIShortcutButton {
idc = 1;
shortcuts[] = {0x00050000 + 0, 28, 57, 156};
x = 0.770934;
y = 0.609076;
default = 1;
text = $STR_DISP_SWITCH;
};

The Switch button obviously has it's own "onButtonClick" event (which performs the actual player swap), it's just hidden somehow. I wonder if there's a way to hide config info... otherwise events for certain dialog controls may well be hardcoded into the game engine.

teamSwitch.sqf is NOT onTeamSwitch.sqf

Agreed. It seems to be like this with all the Event Scripts. We have access to the stuff that just moves the camera around, etc. Meanwhile the useful code is successfully hidden away, just beyond our reach.

For the record, I don't really feel like I need to modify the existing death/respawn code. It's easy enough to disable, by keeping respawn="NONE", and dropping a "onPlayerKilled.sqs" file into the mission directory with a simple delay:

~100000000

Turns out that one of these Hidden Event Scripts (or their hardcoded equivalent) will end the mission the moment "onPlayerKilled.sqs" terminates, so keeping this script alive keeps the mission going.

In any event...

The whole goal of this undertaking, for me anyhow, is a functional player swap, so that I can implement a reasonable "return to play" feature, where a dead player (in deathcam), can take over as a new (and very important here...) different unit.

Using selectPlayer alone results in locality issues, which prohibit the selectPlayered client player unit from being in the same group with the server player unit, with server unit as lead. This is a serious limitation! It makes selectPlayer essentially useless in an MP environment, without additional and necessary steps to make selectPlayer work properly.

I believe if we could simply see into these Hidden Event Scripts, we could solve the locality issue with selectPlayer. BIS swaps the player without issue in group and side respawn every time we die using these respawn methods. A functional player swap is possible!

Alternately BIS could provide one of the following:

1. A new command: forcePlayerLocality

2. A usable selectPlayer

3. A BIS dev drop in and comment

4. Access to the player swapping code (i.e. Even if we cannot modify it, we can still see how it's done.)

I and many others would be extremely grateful for any of these solutions. That's in addition to all the gratitude we've already got for all your hard work and the end result... your wonderful games. :)

Edited October 14, 2011 by MadRussian

[.kju 3244]

This is a serious limitation! It makes selectPlayer essentially useless in a MP environment

serious limitation - yes

essentially useless in an MP - no

you only need the drop the idea of having the players in groups together

or script them the required/desired group functionality yourself

[madrussian 347]

OK, not useless, but we both agree it is a serious limitation. Believe me, I have spent hours and hours trying to get client/server units together in one group with server as lead, to no avail. But I keep making progress, so I remain undeterred.

PvPscene, you are almost making it sound like you would rather not see into how BIS is performing functional player swap, even if that option was available to you! My friend, we are both on the same team here, along with others in the community who would like to see resolution to this locality issue. Why not be an advocate here towards a shared solution? :)

Edited October 14, 2011 by MadRussian

[.kju 3244]

You are mistaken here. :)

And I've tried to overcome the issues myself, like you are trying.

But if there is a dead end, I do use and promote the CIT to get the attention of BI:

Feature #13265 - Add a simple and robust way to change the player model dynamically.

Feature #13606 - Add scripting command: _unit setSide side;

Feature #4367 - selectPlayer: Not working on remote units in MP

Edited October 14, 2011 by .kju [PvPscene]

[madrussian 347]

Awesome! :)

Let's hope BI can sort some of this (locality loss in particular) by ArmA3, if not yet for ArmA2. In the mean time, if there really is some sort of workaround they are using in the default scripts (hard-coded or otherwise hidden from us), it would sure be nice to know how they are doing it, as we could start doing it too!

(Of course, provided it's all possible via commands available in the command ref)