End Game MP Mode - Feedback

[NoPOW 59]

Really? On our server we play on Elite difficulty with no map markers, 1st person only and no Group IDs and we have no problems at all with team killing. WHY? Because CSAT doesn't look anything like NATO. If you are getting more than 1 TK every 2 or 3 games then you are quite simply playing with the wrong people.

Well... If you're not using those markers, there's not really a big chance you're going to get confused by them, are you? :')

[ratszo 17]

Ok, found the 'dgm' key is defined under "Team Switch".

"Assign Colour" --would be helpful if colours showed on the Hex. Not much point assigning colours if they can't be seen.

--And if they were seen, it would make fireteams, buddy-teams effective.

Also, hexs ought to be configurable for distance, say 50 or 100 meters.

[redgrand 10]

How I can contact administration of the End Game servers? Today on the server End Game #14 (EU-FR) I met a cheater

[rekkless 240]

if you don't find this kind of gameplay exciting and thrilling then I honestly don't know what to say. End game makes for some seriously enjoyable and thrilling engagements.

[lingus 10]

One of the Random kits in the Arsenal had me in just my undergarments!

In addition some have taken to stripping off the uniform to get a speed advantage while moving on foot.

I was wondering if any elite players without the benefit of group markers would be able to identify NATO Jockey shorts from the CSAT underwear?

[ratszo 17]

...,

I was wondering if any elite players without the benefit of group markers would be able to identify NATO Jockey shorts from the CSAT underwear?

CSAT --speedos.

NATO -- boxers.

[sparfell_19 188]

Hi,

Does anyone know if there is a way to use the End Game objective randomizer module outside of an End game scenario. If so, how tu use it ?

Edit : Woops, maybe this thread is more appropriate :

http://forums.bistudio.com/showthread.php?191692-End-Game-Scenario-Guideline&highlight=end+game

Sorry

Edited May 16, 2015 by Sparfell_19

[pete101 10]

The end game revive system is still scheduled for a fix according to my ticket. I don't meant to bug the devs :rolleyes:..but have there been any developments in 1.44 I haven't seen?

[chortles 263]

The end game revive system is still scheduled for a fix according to my ticket. I don't meant to bug the devs :rolleyes:..but have there been any developments in 1.44 I haven't seen?

Not all of the fixes have been pushed to stable yet, i.e. from today's dev branch changelog:

Revive

• Fixed: Incapacitated Post Process effects are now visible with NVGs equipped
  
• Improved: Now possible to set custom revive, force respawn, and bleed out delays
  
• Fixed: respawnOnStart values other than -1 did not work correctly
  
• Fixed: User-defined delays accidentally set the default force respawn delay to 0 seconds
  

[pete101 10]

Thanks very much Chortles! Exactly what I was looking for.

It looks from what I've seen like its coming along nicely and BI are slowly making revive work in more scenarios and making it more robust.

Thanks all!

[pete101 10]

Has anyone else used the revive system with CfgRespawnInventory? I have a small TVT map with the revive system and when you use CfgRespawnInventory and MenuInventory you are revived with the vanilla class for your man, not the selected class from the MenuInventory.

It might be my bad coding so I've included my mission here in case it is. Otherwise I'll make a ticket.

http://s000.tinyupload.com/?file_id=01112983479753486172

Thanks all.

[galzohar 31]

Hi,

I tried using the new group system but found some game breaking bugs:

- Promoting will often show the promoted person as the leader on the left-hand side of the menu, but in practice the group leader is someone else as will be shown on the right-hand side of the menu. After that, nobody can promote anyone until the bugged players leave and re-join the group. This doesn't always reproduce but reproduces very often.

- Promoting creates a new group rather than changing the leader, which means any variables set on the old group are deleted, breaking mission-related scripts that use the group to track mission data (such as group insertion position, rally point, etc).

- Empty groups are not deleted. After leaving and joining enough times, you will reach the group limit, and no new groups can be created.

[neokika 62]

Thanks for the feedback. :)

- Empty groups are not deleted. After leaving and joining enough times, you will reach the group limit, and no new groups can be created.

Nice catch, fixed internally and soon to be on dev branch.

- Promoting creates a new group rather than changing the leader, which means any variables set on the old group are deleted, breaking mission-related scripts that use the group to track mission data (such as group insertion position, rally point, etc).

Unfortunately this is currently one of the weaknesses of current implementation and which we intend to improve/fix but might not be as easy as one would think. Because of the dynamic nature of dynamic groups, mission designer must take into consideration that a player's initial group may not be a reliable way to detect gameplay changes. So the rule of thumb, is to never rely on groups remaining the same, when using a dynamic groups system as the one provided in default functions.

- Promoting will often show the promoted person as the leader on the left-hand side of the menu, but in practice the group leader is someone else as will be shown on the right-hand side of the menu. After that, nobody can promote anyone until the bugged players leave and re-join the group. This doesn't always reproduce but reproduces very often.

Unfortunately I am unable to reproduce this one myself, will send it to QA though.

Edited June 15, 2015 by neokika

[galzohar 31]

Thanks for taking my feedback into consideration :)

Why can't the selectLeader command be adjusted to work globally and be synchronized across the network? That way no need to create new groups. When I was using my own system I used selectLeader locally on each machine based on a global variable setting the leader's unit variable name, which made it possible to synchronize across the network, but required a repeated checks for the variable value to keep the group leader selection up to date locally. If selectLeader was global and correctly synchronized across the network, it would save all that trouble on top of saving the need to create new groups to select a new leader.

I have to use groups to store game-relevant data because I have a lot of per-group scripting, such as squad leader picking insertion position and squad radio channel, as well as signaling to the server his group is ready to start the game. Creating a new group resets all the above to default values. While the scripts can handle it, it would be more user-friendly if they could be saved without extensive workaround scripts.

As for reproducing the promotion, in DTAS mission I get this all the time. However it seems to require multiple players in the group (could not reproduce it with just 2 players, and it seems to sometimes depend on which players join the group). Maybe give it a try with a larger number of players (4-5). Using an improved variation of selectLeader might eliminate this issue, anyway.

[benargee 20]

http://feedback.arma3.com/view.php?id=24537#bugnotes

[neokika 62]

I have to use groups to store game-relevant data because I have a lot of per-group scripting, such as squad leader picking insertion position and squad radio channel, as well as signaling to the server his group is ready to start the game. Creating a new group resets all the above to default values. While the scripts can handle it, it would be more user-friendly if they could be saved without extensive workaround scripts.

But this logic will break if players change groups completely, for example, group A merging with group B, you will end up with group A being deleted because it is empty.

Just think about how to remove group dependency from your game logic, it is really the safest way.

As for reproducing the promotion, in DTAS mission I get this all the time. However it seems to require multiple players in the group (could not reproduce it with just 2 players, and it seems to sometimes depend on which players join the group). Maybe give it a try with a larger number of players (4-5). Using an improved variation of selectLeader might eliminate this issue, anyway.

Please give it a go in the latest version on Dev branch and let us know if it was fixed for you.

[sgtpepper 11]

It's not really a dev-branch related post but I don't know any better place to ask:

I just connected to one of the official end game MP server, left the game and tried to connect to another server (king of the hill). I could not connect and got a battleye restriction #4 kick. I tried several servers - all with the same result. I restarted arma and could connect again.

Can anybody else reproduce this issue and is this connected to end game? Or was it just a random issue?

[galzohar 31]

I'll need to see if I can get some players on the Dev branch for a test. It's hard enough to get enough in for a test on the release branch :(

As for the group logic, it doesn't break when group A merges with group B as long as group A keeps its group and leader. I don't have a problem with groups being deleted, I have a problem with groups being disbanded and re-created without the user requesting it. If the user disbanded his group then he is responsible for configuring his new group: Selecting new spawn location, signaling when his group is ready to start the mission, choosing group radio channel. Those things don't make sense to be saved anywhere else.

On the group I only save group-specific things that can be safely deleted once the group is deleted. However, groups shouldn't be deleted and re-created unless the player disbanded a group. Promoting should simply use the selectLeader scripting commands, which, in turn, should be fixed to work in multiplayer (if it hand't been fixed already). In my opinion, new groups should only be created when players leave/join/disband groups, and not when selecting a new leader or modifying anything else in the group that doesn't involve creating a new group (from the player's perspective).

[fn_Quiksilver 1636]

Unfortunately this is currently one of the weaknesses of current implementation and which we intend to improve/fix but might not be as easy as one would think. Because of the dynamic nature of dynamic groups, mission designer must take into consideration that a player's initial group may not be a reliable way to detect gameplay changes. So the rule of thumb, is to never rely on groups remaining the same, when using a dynamic groups system as the one provided in default functions.

.

Something like this works, to transfer variables from one group to another.

QS_fnc_transferGroupVars = {
private ['_oldGroup','_newGroup','_var','_val']
_oldGroup = _this select 0;
_newGroup = _this select 1;
{
	_newGroup setVariable [_x,(_oldGroup getVariable _x)];
} count (allVariables _oldGroup);
_newGroup;
};

_oldGroup = group player;
_newGroup = createGroup playerSide;

[_oldGroup,_newGroup] call QS_fnc_transferGroupVars;

[player] joinSilent _newGroup;
deleteGroup _oldGroup;

Edited July 3, 2015 by MDCCLXXVI

[twakkie 57]

Good day Everyone

We recently started using the BIS revive script since ACE 3 has been a bit unstable of late. By far the best revive script we have ever used but one thing we found very lacking and that is drag and carry ability. Just not allowing you to move someone out of a firefight to be healed is really a huge problem. Thus I wanted to know if anyone has done the legwork to add drag and carry functionality to BIS revive? I apologise if this isnt the place to ask this, will ask it in the script and Editing forum as well.

C

[twakkie 57]

Good day

So we have a problem where if we revive a player, his backpack would be dropped to the ground and he will have the equipment with what he started with instead of the kit he loaded at Arsenal.

I searched the thread but couldnt get any one who has mentioned something similar. We do run a host of mods on our server. Mostly weapons etc.

Any helps in this regard would be appreciated.

Regards

Twak

[fn_Quiksilver 1636]

3 issues with BIS Revive before I would implement it into public COOP.

1. When a player dies inside a vehicle !((vehicle player) isKindOf 'Man') , they are currently not revive-able. Not sure if this is intentional. Ex. If you are shot while riding a quadbike, you are not revivable.

2. Require ability to limit reviving to only certain classes, such as Combat Life Saver. Medic roleplay drops to zilch when anybody can revive anybody.

3. Lack of move-ability of wounded. Can't drag / carry / load in vehicle / pull from vehicle. This also is required.

^ When those 3 are addressed, it will make its way into lots of scenarios.

[chortles 263]

2. Require ability to limit reviving to only certain classes, such as Combat Life Saver. Medic roleplay drops to zilch when anybody can revive anybody.

According to Zipper5 the lack of medics-only revive is intentional since the revive system is designed around the intended play style of End Game, any usability outside of that is just a bonus (and mission-makers' responsibility).

[neokika 62]

Something like this works, to transfer variables from one group to another.

Thanks. But such solution would work only with either Local or Public variable and it would not work when you have a mix of both (which is the most common) because you cannot detect whether given variable found with AllVariables is public or local.

[phronk 898]

My comment does not pertain to the "End Game" mission, but rather the Revive system BIS has added to ArmA 3.

I'm glad BIS has finally added something like this to sort of expand upon their (still incomplete feeling) medical system and I've recently started using it in my Insurgency-style mission. There's just two things I'd like to request:

1. Carrying / Dragging: I'm sure you guys already have this in mind or have at least been suggested this before, but it would be wonderful if you could enable a carrying/dragging functionality to allow live players to pull wounded players into cover.

2. Teleport Glitch?: There's a weird glitch that seems to make the player no longer considered in that area -- very briefly -- where he was wounded (and put into a Revivable state). In missions like mine, that spawn/despawn units when they detect the player in that area or not, this can cause the AI spawned in the area to be despawned when the player is wounded and then they are spawned again a second or two after.