Jump to content
diehardfc

Variable names failing in multiplayer

Recommended Posts

I have a weird problem that I've been unable to solve and I was hoping I could trouble the community for some assistance. I design multiplayer missions for a community of about 50 players and we play on a dedicated server. During missions, players typically respawn at the base or location where they start, which can be many kilometers from where they died. To get them back to their team in a timely manner, we have them go into a "medical redeployment" tent and click on a sign. The sign has some code in its INIT field that uses the moveInCargo command to send the player to the back of a medical vehicle. Then they hop out and rejoin the fight. The system works great when the vehicle is parked, and continues to work even after someone initially drives it. At some point after a driver exits the vehicle, however, the moveInCargo command seems to stop working. As near as I can tell, the code in my sign's INIT field can no longer find the variable name of the medical vehicle. It's a stab in the dark, but I'm guessing it has something to do with locality? The medical vehicle is named in the Eden Editor, so I assume it's owned by the server when the game starts. When a player enters the vehicle, the locality switches to their machine. I'm not sure what happens when there are multiple people inside. I also don't know for sure that ownership reverts back to the server when a player exits. Does anyone know why this happens or how it can be avoided? Should I be assigning these variable names in another way? Do the names need to be updated? I can re-assign the variable and get the code to work again, but it will always fail again after a while. It's terribly confusing! Thanks in advance for any assistance you can offer.

Share this post


Link to post
Share on other sites
3 hours ago, diehardfc said:

moveInCargo

is a AL EG command, there's a couple of reasons that I can think of to cause it to fail:

A. Either of the parameters are invalid.

B. The unit being moved is not local.

C. The vehicle cargo is full.

 

I imagine you have already ruled out C. B is unlikely since you are moving a player from, I presume, his own action call which is local to the player's machine.

So A it is then. Well this seems the most obvious anyway since you can temp fix it by re-assigning the value.

 

Couple of questions you should find an answer to before moving on:

Does the vehicle have respawn enabled? Did it stop working after a respawn?

Did the player(s) who experience the issue JIP or were they there from mission start?

Does it only happen for one person or several?

Does it stop working for everyone at the same time?

What's the value of the variable when it has stopped working on the client? (If it only breaks for some players check on their clients)

What's the value of the variable when it has stopped working on the server? (Use the server exec feature in the debug console to run something like: format ["Variable: %1", variable] remoteExec ["systemChat"];)

 

Let us know if you need more assistance.

Share this post


Link to post
Share on other sites
6 hours ago, mrcurry said:

is a AL EG command, there's a couple of reasons that I can think of to cause it to fail:

Couple of questions you should find an answer to before moving on:

Does the vehicle have respawn enabled? Did it stop working after a respawn?

Did the player(s) who experience the issue JIP or were they there from mission start?

Does it only happen for one person or several?

Does it stop working for everyone at the same time?

What's the value of the variable when it has stopped working on the client? (If it only breaks for some players check on their clients)

What's the value of the variable when it has stopped working on the server? (Use the server exec feature in the debug console to run something like: format ["Variable: %1", variable] remoteExec ["systemChat"];)

Thank you very much for your response. I wanted to reply to your questions inline, but I don't appear to have that level of talent, so here it is in bullet form:

  1. The vehicle is a medical vehicle (an RHS MRAP) but does not have respawn enabled. All players are respawning at a traditional "respawn_west" system marker.
  2. Affected players are a mix of those who were in the mission at the start of the game and those who JIP. I'm not sure if one player type went through first or not, though.
  3. Once it breaks, it seems broken for everybody trying to move into that vehicle.
  4. We've had two vehicles and two redeployment signs running at the same time, and it's possible to have one not working and the other working.
  5. I would love to know this, but getting that value exceeds my skill level. Is that a thing, where a variable can stop working on a client or server but continue working on the other?
  6. If there was a way to discreetly run this code during a mission so that it's not disruptive to players and only I saw the messages, I'd be happy to give it a try. If I plug your proposed code in, what locality would I execute in?

I sincerely appreciate you taking the time to discuss this issue. Thanks again!

Share this post


Link to post
Share on other sites

Having done this sort of thing on a bigger scale, here's what I would use to temporarily debug players moving about. It'll tell you each time someone clicks the button, who it was, and where they're heading.  Also try moveInAny as it allows the player to be put in any open seat.

//Add this to function to init.sqf or just execute it locally using debug

fn_diagnosis = {

	//params sent by player when button clicked
	params [_name, _targetvehicle];

	//Exit if not you, comment this out if you wish it to be seen on all clients
	if !(getplayerUID player == "YOUR UID HERE") exitWith {false};

	//You'll see this each time someone has a go at teleporting
	systemChat (format ["%1 has attempted teleporting to %2",_name,_targetVehicle]);

};

//Add this to code when player clicks button to teleport.

[(name player), _targetVehicle] remoteExec ["fn_Diagnosis", allPlayers];


 

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×