neokika
-
Content Count
1160 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by neokika
-
We now have a second official server available: Unfortunately, we still did not have the chance to documentate the new systems used in EndGame for community use, although you can expect it very soon.
-
This should be possible to setup, let me get back to you in a while. EDIT: There are now two official EndGame servers, #1 is on Veteran difficulty and #2 is on Regular difficulty. Have fun! ;)
-
Thanks to all who could join. Session is now over but server is back up without password.
-
It is MP_Marksmen_01.Altis. Thanks. ;)
-
Yes, this is a known issue that somehow is not described in the notes. Thanks for letting us know. ;) Thanks for the feedback. ;) The carrier is currently visible when not under geometry (a building, tree, object) to the enemy side, although, friendlies always see their carrier marked. Although, we want to add a visual indicator for the carrier to know when he is visible/not visible to the enemy, which is currently missing completely.
-
Yes, this will be possible in future iterations. There will be a strong connection between SquadXML and Dynamic Groups. More info soon.
-
Nice, thanks! ;)
-
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;
-
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. 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). The main idea for the scripted solution is to nail all this engine features and discover it's limitations. Obviously theres local validation of the data before sending any server request. ;)
-
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.
-
Hi, You are missing the client initialization: // initServer.sqf ["Initialize"] call BIS_fnc_dynamicGroups; // initPlayerLocal.sqf ["InitializePlayer", [player]] call 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. 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). 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. In fact, joinSilent is fully global, both arguments and effects, so it should be reliable to call it anywhere.
-
These notes are great, thanks a lot for this piece of feedback! I would strongly discourage jumping to our early version right away, the current version of Dynamic Groups is not yet considered stable or close to feature complete. Much may change/be added. With that out of the way, expect proper documentation on how it works and how to use it when a more stable version becomes available. At that point we will make a public announcement somewhere on the forums. 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; While we haven't found any of the issues you've just reported to have come across with, it doesn't mean they don't exist. Check BIS_fnc_dynamicGroups for more info. Again, thanks for your great feedback. ;)
-
Expect it very soon. You will be able to change equipment at the FOB.
-
Name tags can certainly be added. About the the unbinarized ebo, I'm not sure, will see if it is possible, but note that the game mode will be fully customizable, so mission makers will be easily be able to setup a whole different mission (different types of download intel objectives), using the EndGame framework. ;).
-
Thanks for the feedback. This is already implemented in the interface too, you just need to select the player in your group (right side) and then click Promote. ;)
-
Thanks! I mostly agree on the respawn, it will be optional in the future, and hopefully, the current system will also be improved. We have ideas for Waves of respawn, limiting on player respawn to leaders only, no respawn on leaders which have enemies near, etc.
-
Thanks for the feedback! Yes, currently both default loadouts and virtual arsenal ones are missing NVGs, will be added in next iteration. Also, loadouts are not final, expect some improvements soon, and major improvements once Marksmen DLC reaches the Dev-Branch. ;)
-
Thanks for this initial feedback! Yes, this is expected behavior, because the opposing side had no players, and since the last phase of the mode (Secure Schematics) is PvP only, if one of the sides has no players, the mission will end after phase two (Download Intel). Currently, after you Establish FOB, you will be able to find there a couple of ammo boxes which allows you to access the Virtual Arsenal in-game. Which allows you to customize your character in-game. The current limitations though, are that the loadouts in these virtual ammo boxes are currently placeholder (not final) and the loadout you select, won't be currently saved (so if you respawn you get the default loadout), but this will be fixed soon. We have plans to have a livestream playing it, but because the current state is still very work in progress, we won't show it in the next livestream, but the one after. ;)
-
Awesome, thanks. :D
-
Interesting, will take a look. ;) Yes, in future iterations you should be able to see who exactly took the assignment.
-
Thanks for letting us know, a fix is inbound. Thanks for this initial feedback! Current object compositions are work in progress, expect much better compositions overall in the next few days. ;)
-
You could try to disable most AI features and set it to careless mode, something like: _unit disableAi "FSM"; _unit disableAi "TARGET"; _unit disableAi "AUTOTARGET"; _unit setCombatMode "BLUE": _unit setBehaviour "CARELESS"; group _unit enableAttack false; Unsure if this will bring you the desired effect, but might be worth a try.
-
Change Yaw on moving vehicles
neokika replied to Falsche9's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Well, there's nothing classified, I can assure you. ;) Currently, there is no proper support for such through scripting. -
How to take out the stamina for soldiers or make it infinite stamina?
neokika replied to Coolinator's topic in ARMA 3 - MISSION EDITING & SCRIPTING
One should try to avoid unnecessary loops and new threads as much as possible. I would suggest you to approach this issue the following way: 1. In your mission folder, create a file and name it initPlayerLocal.sqf (Runs at mission start for every client, when they join the mission) 2. Inside initPlayerLocal.sqf disable the fatigue player enableFatigue false; 3. Also inside initPlayerLocal.sqf add a respawn event handler (is executed every time player respawns) player addEventHandler ["Respawn", { (_this select 0) enableFatigue false; }]; So what this will do is disabling the fatigue when the Player joins the mission, and every time he respawns the fatigue is also disabled. See also: Event_Scripts Arma_3:_Event_Handlers - Respawn -
POLPOX's Calm Animations Script
neokika replied to POLPOX's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Hi Legolasindar, Have you checked BIS_fnc_ambientAnim and BIS_fnc_ambientAnimCombat?