Jump to content
Sign in to follow this  
Espectro (DayZ)

JIP

Recommended Posts

Is it possible to create new JIP characters on-the-fly? {CreateNewUnit, JIP=true}?

Share this post


Link to post
Share on other sites
On that note:

How come OnPlayerConnected,onPlayerDisconnected doesn't even has the unit that Player joined into as an parameter? Or does that kick off everytime someone connects/disconnects but yet isn't even in the game world  huh.gif .

Maybe that's because we have the Player command? OnPlayerConnected and OnPlayerDisconnected is most likely local, and if that is the case there will only be one Player. And an eventhandler for "Joined" and "Disconnected" doesn't make any sense, nor would they even be needed. Again, you can detect whether or not a unit is a player at any time. A lot of people don't realize that you can put a script on hold if a unit is or is not a controlled by a player just by using the Player command.

Quote[/b] ]Is it possible to create new JIP characters on-the-fly? {CreateNewUnit, JIP=true}?

If the setPlayable command works as it says on the wiki, then you should be able to create a playable role for any unit during the mission, unless it's for something else.

Share this post


Link to post
Share on other sites

Well,if it is local you are completly correct.How does OnPlayerDisconnected work on a client that just disconnected tho huh.gif .

Eventhandlers: So,you expect me to go with the OnPlayerConnected command of which there most likely can only be one per client(Just like OnMapSingleClick), and then try to look through a preset array with my player-references what the hell I wanted to do with that unit.And here again we have the great problem of disconnecting players

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

UnitA addEventHandler [{Joined},{player sidechat {You are UnitA}}]

UnitB addEventHandler [{Joined},{player sidechat {You are UnitB}}]

versus

(Given the thing is executed locally only)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

onPlayerConnected {if(player == unitA) then {blabla};if (player == UnitB) then {blabla}}

Now I think if you have tons of units for which you want to do different things on when some joins into them or disconnects(which most likely would be executed on the server and obviously the player trick doesn't work there) I would think eventHandlers wouldn't be that much of a PITA as having to have a very complicated onPlayerConnected thing,leave alone if 2 script system need to use that

Share this post


Link to post
Share on other sites

Well I noticed another new ArmA command: isPlayer. Supposedly it works for any player, not just the client. Anyway, the eventhandler is totally unnecessary, there are already a few ways to do what you're trying to do. And the eventhandler just doesn't seem practical, since it has no parameters it's only doing the same thing as @ isPlayer UnitA. Also, your example is flawed, since player sidechat {You are UnitA} is only good if it's executed locally, in which case you wouldn't even need for that script to be global. Also, I can assume that using the isPlayer command in the unit's scripting will be more useful than an eventhandler, since that way you constantly know when that unit is and is not a player, rather than the instant a player connects to or disconnects from that unit. And another thing, you're assuming that as soon as a player connects he immidiately takes a role, but as far as I can tell the players enter a pool first, and I'm assuming the OnPlayerConnected/Disconnected commands work when the player connects to the server, not when they take a role. And if players are going to be switching in and out of different units, it's better to have an updating script that utilizes isPlayer to keep track of them. I'm not saying there'd be a problem if these eventhandlers were added, I'm just saying they would probably see limited use, and I'd much rather have more useful ones.

Share this post


Link to post
Share on other sites

Okay,Granted it was a very bad example. But IsPlayer doesn't fix the problem either.

I come up with another example to try to convey the point I am trying to make to you and I guess BIS.

I do not see how it is so hard to acknowledge that a event Joined/Disconnected that is fired of per unit rather than one eventhandler(OnPlayerConnected,OnplayerDisconnected) that is fired of no matter what unit can be considered useless.

I take it you are an addon scripter or SP scripter since in those enviroments you don't have to bother with different eventhandlers for the "same" thing. If your tank/plane-addon needs to do something in MP,all other tanks/planes need to do the same.Like produce some dust or something. But in my opinion if you are doing a MP mission and you want to have different units perform different scripts on said event "Joined"/"Disconnected",then bloody seperate eventhandlers for them make very much sense.

Basically what you are advocating is the same as saying: "OH no!, we don't need killed-eventhandlers,we have the OnPlayerKilled.sqs,OnPlayerRespawnAsSeagulls.sqs,etc scripts,they should be able to handle the killed-event of an player just fine"

Share this post


Link to post
Share on other sites

Maybe I wasn't clear about my point. I'm only trying to say your idea of such an eventhandler wouldn't be very practical. I can see your point, but I think if there is going to be a "joined"/"disconnected" eventhandler it could be made more useful than what you exemplified. No I don't have any ideas for how it can be improved but I guess I just feel it won't be on par with the rest of the eventhandlers. And I have done quite a bit of MP scripting, it's not easy (frustrating describes it nicely), and I would like to see it made easier in ArmA.

Share this post


Link to post
Share on other sites

I will be disabling JIP on my public OFP server after I convert from Resistance to Armed Assault.

I run a coop only public server. I do not want some idiot joining in the middle of a coop map, ruining the map for everyone else, then leaving. That happens now, but at least it is at the beginning of the map and we can start over again without the problem player.

Also, I currently "lock" the server when playing a map to stop the idiots who repeatily connect and disconnect during the map, rather than using OFPWatch, to know when we have finished the current map and are starting a new map.

I do reassign a map for friends and squad members who try to join the server, if we are not too far into the map. Usually, the friends and squad members connect to my teamspeak server before they try to connect to let us know they are available to play on the server. Otherwise, they have to wait for us to finish the map just like anyone else.

Share this post


Link to post
Share on other sites

Options should be for the server host. The host is the person who is catering for a specific type of player.

The host should have server options for:-

Join in progress / no join in progress

player respawn/ No player respawn ( or limited number of respawns ? )

vehicle respawn / no vehicle respawn

tracers on / off

Things like that.

Comming from a squad who are used to games with JIP , im looking forward to Armed assault. The lack of JIP is why we only mess arround with Flashpoint occasionally, and dont play it all the time. its just way too frustrating if you in the middle of a game and your crash out / loose connection etc and then you have to wait an hour to rejoin your team mates.

Personally I wont and my squad wont be touching servers that dont run JIP in full and we wont be running a server without it ether.

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  

×