Jump to content
gc8

Using initPlayerServer.sqf ?

Recommended Posts

Hi

Using initPlayerServer.sqf is not best option for my mission and the wiki says "initPlayerServer.sqf should be avoided.". So my question is , is there any other way to achieve same result as with the initPlayerServer.sqf? (Maybe some kind of EH)

 

thx!

  • Like 1

Share this post


Link to post
Share on other sites

Thanks guys, this helps me for a project:) 

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, Mr H. said:

You've got the uid so you can retrieve it with https://community.bistudio.com/wiki/BIS_fnc_getUnitByUid

 

Thats good, thx! But my concern is, is the player object properly initialized at the time the connect EH is fired? The player object not being passed to the EH implies it's not. But hope I'm wrong.

Just want to be sure about this :)

 

Share this post


Link to post
Share on other sites
2 hours ago, gc8 said:

But my concern is, is the player object properly initialized at the time the connect EH is fired?

No.

 

You could maybe use the EntityRespawned handler, that might fire on server when a unit spawns.

Unless they don't spawn via respawn, but instead occupy a existing AI unit, in that case the EH will probably not work.

  • Like 2

Share this post


Link to post
Share on other sites
17 hours ago, pierremgi said:

Why not with:

this addEventHandler ["Local", { params ["_entity", "_isLocal"]; }];

 

That runs (also) on server.

 

If that works good but what if for example one player leaves the server and another takes his unit, will it still work? It should fire on server each time player joins

Share this post


Link to post
Share on other sites

As far as another player can take a slot, that means this slot is available on server. So, I guess yes. You'll have a double EH fire:  client1 & server  for disconnection and client2 & server for new JIP.

Share this post


Link to post
Share on other sites
2 hours ago, pierremgi said:

As far as another player can take a slot, that means this slot is available on server. So, I guess yes. You'll have a double EH fire:  client1 & server  for disconnection and client2 & server for new JIP.

 

sounds so complicated that I'll probably stick with initPlayerServer.sqf :dozingoff:

Share this post


Link to post
Share on other sites
26 minutes ago, gc8 said:

 

sounds so complicated that I'll probably stick with initPlayerServer.sqf :dozingoff:

Why not use initPlayerLocal.sqf? :scratchchin:

 

Cheers

Share this post


Link to post
Share on other sites
8 minutes ago, Grumpy Old Man said:

Why not use initPlayerLocal.sqf? :scratchchin:

 

Cheers

 

Isn't that for client? 

Share this post


Link to post
Share on other sites
42 minutes ago, gc8 said:

 

Isn't that for client? 

Yes, but you never spoke about what you intend to do. Just some considerations about "achieving same result as with the initPlayerServer.sqf" .

If you don't want the useful EH "local", you can have an endless loop on your initServer.sqf , name you playable units toto, gugus,...  and waitUntil they are not local (so passed to a player's PC. Not sure it's smarter than the EH.

Share this post


Link to post
Share on other sites
57 minutes ago, gc8 said:

 

Isn't that for client? 

Sure, local to each client and passes player object, as you stated in your second post.

If you need to pass player object to the server you can always use initPlayerLocal.sqf with remoteExec.

 

Be more specific about what you want to achieve, maybe initPlayerServer will work better, the notion that "initPlayerServer.sqf should be avoided" which you quoted is not a general statement and related to a specific use case of CfgRemoteExec.

 

Cheers

 

Share this post


Link to post
Share on other sites

I should have been more clear on what I want, sorry. The reason I referred to initPlayerServer.sqf is because I need to init the player on server and the timing is crucial

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

×