eriktrak 76 Posted March 18, 2015 Have you realized that when nighttime comes in the game it turns into a horror movie? Actually it reminds me the Blair Witch Project. If the visual aids would be disabled during nighttime the atmosphere would be perfect. Share this post Link to post Share on other sites
galzohar 31 Posted March 18, 2015 Would all groups created on the server be local to the server? Because I found it rather difficult to predict where a group would be local, and locality seems to change in a way difficult to predict. For example, empty group that was previously local to the last player who left it, will become local to the server only several seconds (or more) after it becomes empty. I guess everything would become easier if all groups are always local to the server. Is joinSilent reliable being executed on the machine where the joining player is local? I can see how things would work better if all is done on server-side, but for now I'm not sure if you can really keep everything local to the server and let the server execute all commands in a way that will work. Even commands that say on the wiki that they are global seem to not always work when the target is non-local, such as setDamage - #11873. Also, it might be a bit network-intensive to broadcast SQF variables instead of using engine synchronization to broadcast data (since it doesn't have the SQF overhead). But then again letting clients do anything with a global effect seems to cause a lot of trouble in Arma... In the end it would be really nice if all scripting commands would be possible to execute on the server rather than when the unit is local, even for commands that currently require locality. Share this post Link to post Share on other sites
das attorney 858 Posted March 19, 2015 (edited) The basic intent for the current version of Dynamic Groups was to make sure clients have no authority over the actual groups data, and only the server.So the clients only send certain requests to the server, then server just validates each request, modifies the data and synchronizes the data with everyone connected. So, because groups are only created, deleted, managed in the server, the behavior should be accurate for every connected client. For example, the selectLeader command seems to be reliable where the group is local, so I make sure of that in the following line: // Set the new leader has the actual group instance leader, must be executed where group is local [[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp; Hi Neo, Thanks for posting in here with very useful info. I looked through the script and tried to get it working in one of my missions but couldn't figure it out (it is 3AM here though so please forgive my tiredness). I tried to invoke the groups system with this: ["Initialize",[]] call BIS_fnc_dynamicGroups; But it didn't start the system so maybe I'm missing something. -- Also, as galzohar mentions, running everything server side seems good (makes sense as only one permanently connected computer can make changes to groups), but then when I start a mission with pre-placed units, they are local to the players machine and not the server, so how do you account for that in your system? (I noted there wasn't any use of setGroupOwner in bis_fnc_dynamicGroups) -- Lastly, in your code example: [[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp; It is sending the request for selectLeader to all members of the group (target param = group), but then you mentioned earlier that the server handles it all and owns the groups, so I'm a bit confused there. AFAIK, selectLeader needs to run on where the group is local, so why wouldn't the server run it (if all the groups are local to the server). target param = false (server only) like this: [[_groupInstance, _newLeader], "selectLeader", false, false] call BIS_fnc_mp; I'm obviously missing something here as what you have coded works, I just can't figure out some of the locality details. Thanks for reading and appreciate it if you could reply and demystify this for me. Edited March 19, 2015 by Das Attorney Share this post Link to post Share on other sites
neokika 62 Posted March 19, 2015 Hi, But it didn't start the system so maybe I'm missing something. You are missing the client initialization: // initServer.sqf ["Initialize"] call BIS_fnc_dynamicGroups; // initPlayerLocal.sqf ["InitializePlayer", [player]] call BIS_fnc_dynamicGroups; Also, as galzohar mentions, running everything server side seems good (makes sense as only one permanently connected computer can make changes to groups), but then when I start a mission with pre-placed units, they are local to the players machine and not the server, so how do you account for that in your system? (I noted there wasn't any use of setGroupOwner in bis_fnc_dynamicGroups) This won't be a problem, because locality of players is handled within, and server also has a non-local version of this object. Unless I misunderstood the question. It is sending the request for selectLeader to all members of the group (target param = group), but then you mentioned earlier that the server handles it all and owns the groups, so I'm a bit confused there. Not really, [[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp; Will selectLeader only where the group is local (group is local to one unique machine). Would all groups created on the server be local to the server? Don't get me wrong :), groups do not stay local to the server forever. The usual group flow in Dynamic Groups is that the group is in fact created on the server (and the abstract data is also set and stored on the server and then sent to the clients), but once the first player (which is remote to the server) assumes command of the group (for example) the group locality changes and becomes local in his machine, and not the server anymore. The system ofc, then needs to make sure to execute the commands where they are required, so if a group is now remote to the server, the server still is the one making modifications etc, but by making sure to do it where the group is now local. Is joinSilent reliable being executed on the machine where the joining player is local? In fact, joinSilent is fully global, both arguments and effects, so it should be reliable to call it anywhere. Share this post Link to post Share on other sites
das attorney 858 Posted March 19, 2015 Not really, [[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp; Will selectLeader only where the group is local (group is local to one unique machine). That's brilliant :) Thanks for coming back to me there - really helpful. Especially the BIS_fnc_MP part. So you're saying if I put a group into the target, then it sends it to the PC where the group is local. I misunderstood the Wiki in that case as it says: Group - function will be executed only on clients where the player is in the specified group https://community.bistudio.com/wiki/BIS_fnc_MP So if we regard this group: units group1 = [john,bob]; // john is group leader I took it to mean that if I put group1 as target, then it requests execution on john and bob's PC's. But you're saying it only executes on john's PC as he is leader. Thanks for clearing that up again Share this post Link to post Share on other sites
neokika 62 Posted March 19, 2015 I misunderstood the Wiki in that case as it says: And the wiki is accurate, I stand corrected. Sorry for this misleading information. BIS_fnc_mp when given group as target, will execute on every client which belongs to that group. You were right, I was wriong, after checking BIS_fnc_mp itself. So the reason why this works in current implementation: [[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp; Is because the selectLeader command runs on every player belonging to the group, but there will always be one player to which the group is local, and selectLeader would be reliable in this situation. This ofc needs to be fixed in the function itself, so what I did was: [[_groupInstance, _newLeader], "selectLeader", leader _groupInstance, false] call BIS_fnc_mp; Which makes sure selectLeader only runs where the group is local, because group is local to the leaders machine. Again, sorry for the misinformation/assumption. Share this post Link to post Share on other sites
das attorney 858 Posted March 19, 2015 No problem Neo, Thanks for following up on that, I've learnt some interesting bits and bobs in this thread :) Share this post Link to post Share on other sites
galzohar 31 Posted March 19, 2015 (edited) Relying on the "group must be local *somewhere*" sounds like a bad idea, because while it might be local to the client when the server tries to execute the local command, the group might no longer be local to said client when he actually gets the BIS_fnc_mp broadcast. Remember that BIS_fnc_mp does not get executed simultaneously on all machines (due to network latency and processing required, which may take different time for different machines), and thus you might "fall through the cracks", so to speak, and the command will not be executed anywhere. We really need a more reliable system, as in make all commands global or at least server-global (as in, have global effect when executed by server). Something like selectLeader shouldn't require broadcasting SQF variables across the network - IMO it should have native support by the engine with a single scripting command executed on the server. Also, something like locking a group (making it private) or other general "join group" handling shouldn't have to be handled by the server - A client script can see the group is private and block the option to join it. Join requests shouldn't have to be sent to the server using SQF variable broadcasting, when joinSilent already synchronizes its results across the network anyway. To be honest, I already have a rather nicely working system for joining groups, but it has absolutely no user interface which makes it pretty ugly pure action menu stuff to call the functions and display the groups, and there are ugly scripted workarounds for engine quirks as well as the more rare engine quirks simply not handled. It would be really nice if the new group system can help bring those needed improvements (less ugly scripting to work around engine limitations and overall less stuff that need to be worked around, and of course the pretty UI), without adding any unnecessary SQF overhead. One more thing about dynamic groups in Arma, is that when a player joins to a slot of a unit that was already in a group, the game will place him back in the old group, which is bad for missions that use dynamic groups as that player probably never wanted to be in that group, plus the group may be private. I had to work around that by leaving the current player's group for all units upon mission init, however cleaner solutions can be implemented with engine support (like rejoining your old group if you are the same player, and not if you are using the same "slot", toggle-able with a description.ext option). Edited March 19, 2015 by galzohar Share this post Link to post Share on other sites
neokika 62 Posted March 20, 2015 Relying on the "group must be local *somewhere*" sounds like a bad idea, because while it might be local to the client when the server tries to execute the local command, the group might no longer be local to said client when he actually gets the BIS_fnc_mp broadcast. Remember that BIS_fnc_mp does not get executed simultaneously on all machines (due to network latency and processing required, which may take different time for different machines), and thus you might "fall through the cracks", so to speak, and the command will not be executed anywhere. This is where having server making the important decisions comes in place, this is the usual MP approach in games, keep in mind the server always has the most up-to-date version of the group, and just tells the clients to maintain this updated version locally. because while it might be local to the client when the server tries to execute the local command, the group might no longer be local to said client I'm unsure why this would be the case? Like I said, server has authority over changes, so server is the one deciding when the group changes locality (by changing it's leader/members). Something like selectLeader shouldn't require broadcasting SQF variables across the network - IMO it should have native support by the engine with a single scripting command executed on the server. The main idea for the scripted solution is to nail all this engine features and discover it's limitations. Also, something like locking a group (making it private) or other general "join group" handling shouldn't have to be handled by the server - A client script can see the group is private and block the option to join it. Join requests shouldn't have to be sent to the server using SQF variable broadcasting, when joinSilent already synchronizes its results across the network anyway. Obviously theres local validation of the data before sending any server request. ;) Share this post Link to post Share on other sites
Maio 293 Posted March 20, 2015 (edited) I think that all the houses that are adjacent to tall rock formations should have some sort of structure added with the purpose of bridging the two. A. It would facilitate ingenious maneuvering game-play. B. Next time Zipper5 spills his near future virtual coffee in my present day MTP clad virtual lap, this can be avoided. Edited March 20, 2015 by Maio Share this post Link to post Share on other sites
millhauz 11 Posted March 20, 2015 this can be avoided. Zozo killed by millhauz. Thats about right :) Also you were talking about some script error during the playsession, could you please send me the errror ( should be in rpt ) ? thx Share this post Link to post Share on other sites
Zipper5 74 Posted March 20, 2015 B. Next time Zipper5 spills his near future virtual coffee in my present day MTP clad virtual lap, this can be avoided. Shit, man, when are you just gonna let that go? ;) Thanks for helping out with the test. Share this post Link to post Share on other sites
superxpdude 1 Posted March 22, 2015 I've been trying to work on a mission using the dynamic groups and revive systems, however I've run into a couple issues which End Game doesn't seem to have; thus I was wondering if someone could help clear these up. 1. I haven't managed to get the revive system to work correctly with respawnOnStart = 1. Players who join are immediately put into an incapacitated state in the middle of the ocean, and I was wondering if there's a way around this. I've set both MenuPosition and Revive as the respawn templates if that changes anything. 2. I've been trying to set up an arsenal gear saving system, however I haven't managed to figure out a way to determine once arsenal closes. Unfortunately using allDisplays to try and figure out a display to watch for didn't work, as the only new display once arsenal was opened was display #-1. I have a gear saving and restoring system working using BIS_fnc_saveInventory and BIS_fnc_loadInventory, but I haven't been able to figure out how End Game saves it automatically. Not sure if this is the right place to ask this, but I thought since End Game uses those features I might be able to get some help here. Share this post Link to post Share on other sites
five_seven5-7 56 Posted March 22, 2015 I get a few not responding Arma 3 when i join the game Game Over MP after the side-class selection. It is worth to open a ticket? Share this post Link to post Share on other sites
neokika 62 Posted March 23, 2015 I've been trying to work on a mission using the dynamic groups and revive systems, however I've run into a couple issues which End Game doesn't seem to have; thus I was wondering if someone could help clear these up.1. I haven't managed to get the revive system to work correctly with respawnOnStart = 1. Players who join are immediately put into an incapacitated state in the middle of the ocean, and I was wondering if there's a way around this. I've set both MenuPosition and Revive as the respawn templates if that changes anything. 2. I've been trying to set up an arsenal gear saving system, however I haven't managed to figure out a way to determine once arsenal closes. Unfortunately using allDisplays to try and figure out a display to watch for didn't work, as the only new display once arsenal was opened was display #-1. I have a gear saving and restoring system working using BIS_fnc_saveInventory and BIS_fnc_loadInventory, but I haven't been able to figure out how End Game saves it automatically. Not sure if this is the right place to ask this, but I thought since End Game uses those features I might be able to get some help here. In EndGame we detect whether Virtual Arsenal was closed by using a scripted event handler (which Virtual Arsenal triggers): [missionnamespace, "arsenalClosed", { // Save inventory for loading after respawn [player, [missionnamespace, "VirtualInventory"]] call BIS_fnc_saveInventory; }] call BIS_fnc_addScriptedEventHandler; Share this post Link to post Share on other sites
zozo 104 Posted March 23, 2015 Just a note. The Revive and Dynamic Groups systems are still subject to change and they are not supposed to be used by the community in their missions. You can, of course, but be careful. Also, that's why there's any documentation yet. Share this post Link to post Share on other sites
superxpdude 1 Posted March 23, 2015 In EndGame we detect whether Virtual Arsenal was closed by using a scripted event handler (which Virtual Arsenal triggers): [missionnamespace, "arsenalClosed", { // Save inventory for loading after respawn [player, [missionnamespace, "VirtualInventory"]] call BIS_fnc_saveInventory; }] call BIS_fnc_addScriptedEventHandler; Thanks a bunch, it works perfectly. Share this post Link to post Share on other sites
Imperator[TFD] 444 Posted March 24, 2015 Just a note. The Revive and Dynamic Groups systems are still subject to change and they are not supposed to be used by the community in their missions. You can, of course, but be careful. Also, that's why there's any documentation yet. Is the plan to have these reasonably finalised before April 8? I finally got around to playing with the revive system last night and I am not overly wowed by it's current implementation although it does suit that specifical game mode well.. The UI is fantastic however. Are BI able to reveal some plans or an end-game (pun intended) for this experimental revive system? For example currently the system does not require any pre-requisites to revive another player; are there plans to potentially limit this to Medics only? Or anyone with a medical kit? Additionally are there plans to have this implemented into a module in the editor that a mission creator can place and customise to some degree via module options? Share this post Link to post Share on other sites
chortles 263 Posted March 24, 2015 Seeing as it's scripted, I would imagine that they're a case of being built specifically for End Game, as you remarked, but allowing mission makers to restrict it themselves (to a degree that BI chose not to by default). Share this post Link to post Share on other sites
Imperator[TFD] 444 Posted March 24, 2015 Seeing as it's scripted, I would imagine that they're a case of being built specifically for End Game, as you remarked, but allowing mission makers to restrict it themselves (to a degree that BI chose not to by default). Can't remember where I saw it but I believe the current iteration is scripted and once BI have nailed it down they will move to a more engine based process. Share this post Link to post Share on other sites
R3vo 2654 Posted March 24, 2015 Is the plan to have these reasonably finalised before April 8?I finally got around to playing with the revive system last night and I am not overly wowed by it's current implementation although it does suit that specifical game mode well.. The UI is fantastic however. Are BI able to reveal some plans or an end-game (pun intended) for this experimental revive system? For example currently the system does not require any pre-requisites to revive another player; are there plans to potentially limit this to Medics only? Or anyone with a medical kit? Additionally are there plans to have this implemented into a module in the editor that a mission creator can place and customise to some degree via module options? Any chance you could give us a hint how you managed to get this to work? Would be much appreciated. Share this post Link to post Share on other sites
superxpdude 1 Posted March 24, 2015 Any chance you could give us a hint how you managed to get this to work? Would be much appreciated. Add the following to your description.ext file. Not sure if it's the correct way of doing things, but it seems to work. respawnTemplates[] = {"Revive"} Share this post Link to post Share on other sites
Wolfenswan 1 Posted March 24, 2015 Can anyone elaborate on how this revive system works in-game? Does it simply freeze "dead" players in a downed state until help arrives? Share this post Link to post Share on other sites
Imperator[TFD] 444 Posted March 24, 2015 All I did was host a dedi server playing the new End Game MP mode and had some mates join in. As far as I can tell the system kills the player (+1 to their death count in the statistics) and then respawns them on the spot where they died but in an 'agony' state. Any player can then revive the wounded player regardless of whether or not a FAK or Medikit is present in their inventory. Share this post Link to post Share on other sites
Zipper5 74 Posted March 25, 2015 Can anyone elaborate on how this revive system works in-game?Does it simply freeze "dead" players in a downed state until help arrives? Officially, you can try it out for yourself in End Game. Unofficially, you can look above for how it's enabled in missions, though do keep in mind the earlier disclaimer that the current state of the system is only guaranteed to work flawlessly in End Game. Players enter an incapacitated state instead of dying, where they can turn their heads but are otherwise immobilized. From here, they can choose to force their respawn or bleed out over time. Damage dealt to the unit is also subtracted from their "blood level" while they bleed out. Meanwhile, non-incapacitated players see an icon hovering over the incapacitated unit, and can move to revive them should they choose to. As a player approaches an incapacitated unit, a prompt to press Space will appear on-screen and the icon will be supplemented with "REVIVE" in white text. While the player holds Space, a progress bar fills for the duration of the revive, pausing the incapacitated unit's "bleeding" (damage is still subtracted). The incapacitated unit is also told who is reviving them. Should a player die while incapacitated, they will see the regular respawn screen. ... are there plans to potentially limit this to Medics only? Or anyone with a medical kit? Units carrying Medikits (Medics/Combat Life Savers have them by default) currently receive a significant buff to their revive time, indicated via special revive icons and a symbol next to the progress bar as they revive someone. We chose not to limit the ability to revive to a specific unit or unit type as we felt that everyone having the ability is the best way for the mechanic to organically foster teamwork among any group of players, with a special emphasis on those operating in smaller groups/squads. However, we still want to encourage role specialization, hence the aforementioned Medikit buff. Additionally are there plans to have this implemented into a module in the editor that a mission creator can place and customise to some degree via module options? The system will operate like the other Respawn Templates, allowing for different (controlled) combinations. It is currently fully compatible with the MenuPosition and MenuInventory templates. However, there are already ways to customize some aspects of the system via parameters in your mission's description.ext file. They are as follows: reviveDelay - The time it takes to revive an incapacitated unit (default: 6 seconds). Having a Medikit will halve this time. reviveForceRespawnDelay - The time it takes for an incapacitated unit to force their respawn (default: 3 seconds). reviveBleedOutDelay - The time it takes for a unit to bleed out (default: 2 minutes). You can also prevent a unit from ever becoming incapacitated by executing: _unit setVariable ["BIS_revive_disableRevive", true, true] Replacing _unit with the variable assigned to the affected unit. With this variable, they will go straight to the respawn menu when killed. Share this post Link to post Share on other sites