Jump to content
Sign in to follow this  
TheTranscendentOne

Init field of a unit seems to be firing more than once

Recommended Posts

Hey all,

Has anyone noticed a playable unit fire its init field, multiplied by the number of times a player has gone through role selection(disconnect) : (fire x #of times gone through role selection).

It's being designed for a dedicated server as a persistent battlefield. I'm trying to notify the player of what the current mission is, after he first logs in using BIS_fnc_showNotification. The init field of the player is executing a script, which waits for the player to spawn and then notifies him of the current mission. Everything seems to work as intended. However, if I for some reason disconnect and come back into the server, spawn and wait, I get the notification twice in succession, 10 times if I've connected 10 times during the course of the mission. The script that is fired by the player init is only calling BIS_fnc_showNotification ONCE. I don't see where this loop is coming from.

This is an example mission:

• Player named Alpha_1

• Init field

Alpha1Init = player execVM "playerInit.sqf";

• playerInit.sqf

waitUntil {!(isNull player)};
sleep 5;

["flTaskAssigned",["DEPLOYMENT", "Prepare while your Commander chooses the mission"]] call BIS_fnc_showNotification;

• description.ext

dev = "Developer";
author = "Author";
briefingName = "Test 2";
onLoadName = "Test 2";
onLoadMission = "On Load Mission";
overviewText = "Overview Text";
respawn = 3;
respawnDelay = 3;
disabledAi = 1;
joinUnassigned = 1;

class CfgNotifications
{
   class flTaskAssigned
   {
       title = "%1";
       iconPicture = "\A3\ui_f\data\map\mapcontrol\taskIcon_ca.paa";
       description = "%2";
       duration = 8;
       priority = 7;
   };

};

It's a weird problem that I'm having with a larger mission and after making it simplified like this the problem still persists. I've noticed the players old bodies are still lying around, could it be firing the script for each dead body as well as the current player?

Any help would be greatly appreciated! Thank you.

Share this post


Link to post
Share on other sites

Hello,

not sure why this is, you could be right with the old bodies, although bodies usually get deleted after a player disconnects. (Pretty much immediately)

You could check if player is unit:

if (player == this) then { Alpha1Init = player execVM "playerInit.sqf"; };

Or local:

if (local this) then { Alpha1Init = player execVM "playerInit.sqf"; };

I'd go with the first in this case.

Why not just execute playerInit.sqf from mission's init.sqf? Should be no need for using init line.

Share this post


Link to post
Share on other sites

What sxp2high says - also:

if (isServer) then {this setObjectTextureGlobal [0,'#(argb,8,8,3)color(0,1,0,1)']};

Is exactly the same as:

this setObjectTexture [0,'#(argb,8,8,3)color(0,1,0,1)'];

The first one tells only the server to execute the Global version of the command: setObjectTextureGlobal

The second runs the local variant on every joining machine: setObjectTexture

You can exploit conditions to have certain useful effects on init:

if (not isServer) then {RunMyClientSideCodeOnlyOnThePlayersMachines};

You can get round a lot of problems very easily by popping down a logic and adding some init code.

Share this post


Link to post
Share on other sites

Anything put in the init field of a unit will be executed every time someone joins the server.

I would not advise using the init field for anything other than commands which are known to be local (moveindriver for example).

Share this post


Link to post
Share on other sites

Thanks everyone. Using init.sqf, you have to bar the server from reading it. In the init field, you have to bar the dead bodies from reading it. So I suppose it doesn't really matter. I chose to use the init.sqf method for easy editing purposes (I don't have to open the editor up to remove the init field, I just comment that out of the init.sqf instead, enabling me to keep in the multiplayer lobby and test new changes quick).

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
Sign in to follow this  

×