Combat 2.1 Teams
tracked
Nexii Malthus
This is putting the teams part of what Rider had drafted up as a proposal into a feedback.
---
Right now it is very difficult to clearly identify combatants except for using groups which is a hassle. It requires someone to join a group, set it as active, etc.
Or systems that implement Teams via scripts like the Combat2 DevKit can be cumbersome and hard to maintain.
Requiring the hacky group checks, a lot of listeners and messages for anything that cares about team assignment, such as a restricted door, a forcefield, a claymore that checks friendlies or enemies in a sensor.
And if group checks are used then you need to distribute and update all the scripts involved if something changes. A military has an extra group? Update the entire armory. Want to play with 3 or 4 teams against eachother? Update all the scripted objects deployed in the battlefield, sometimes across multiple sims.
Even the Pew Pew combat 2.0 party we had with the lindens showed the issues greatly affecting the event, as the feature was rushed out and it wasn't possible from a lot of strangers in many different groups as to who which team they were fighting for.
Experience based respawn systems also need to manage identification, to know where to put someone. We had an issue where a group wanted to have an internal fight, people had to change their active group, ... which then led to problems because army-specific equipment can have required group identification that ties it to the active group as authorisation, we resolved that (since we had a militia group that it allowed usage with) thankfully but it showed the cracks in the system from lacking a fundamental system.
---
So I would like to see Rider's implementation of Teams. Which allows some predefined teams to be configured (8 but hopefully up to 12-16 personally).
See the thread for more details:
Log In
Jeremy Duport
Rider's teams concept is suited to tightly controlled ecosystems, e.g. a single gamified estate. Done well, I can see them being beneficial for much more than just combat. However if they don't require land experience permissions to control, it dumps the terrible burden of interoperability for highly contested resources (team numbers - indeed,
enabled
team numbers) on disparate content creators with differing intentions, which instantly reduces them to mush. More than one of the pain points above would go unsolved either way. Teams should go hand in hand with expanded script-group querying and user-group privacy permissions, because they are not a single pie.
Nexii Malthus
Jeremy Duport it should definitely require land experience permission, I can't see this making any sense otherwise.
Expanded group querying and privacy permissions would be awesome but it would turn a simple proposal with great utility into a massive project and also create a dependency on groups. Groups in SL are somewhat feature frozen, stuck and hard to change or improve -- why aren't groups more like discord with persistent text and voice channels and forums instead of a single chat room that forgets everything as soon as you logout? They should have been improved a really long time ago but had already built a lot of technical debt and became immovable.
So it is better if we create new systems and mechanics that synergise well instead of interleaved features. That's why I really like the Teams proposal, if the aspects of control are sorted out. It could benefit way more communities and projects outside of combat than in it.
Even non-combat or non-game environments, such as having a simulation of a bunch of city traffic and NPC characters, by giving them teams you could assign aspects like civilians vs police vs criminals to all the scripted objects to add some entertainment or living background life to a cyberpunk city. This would be much harder to sort out having to send listen messages around when all but two functions like llSetTeam and llDetectedTeam would vastly simplify everything. Less is more, as someone once said.
Jeremy Duport
Nexii Malthus I brought up the need for permissions since it didn't seem mentioned in the concept OP, but I admit I only skimmed the signatures. :thumbsup:
Nexii Malthus
Jeremy Duport it's definitely a valid concern because I asked about it in that thread before as I was very concerned about the lack of mention, but since Rider deftly avoided it maybe it's something they are still needing to think about and wanted feedback on
Tamiya Starling
I have been in SL a long time and have come to view "less is more." That is, according to Nexil "Right now it is very difficult to clearly identify combatants except for using groups which is a hassle. It requires someone to join a group, set it as active, etc." and which I believe indicates that groups are more than sufficient. We don't need new features in SL to accommodate small niche sets of users. So, perhaps we need to better understand why 'groups are a hassle.' Joining a group and setting it as active is a pretty trivial set of actions. Furthermore "set is as active, etc." -- what's the et cetera mean? Is there some other activity that must occur, or is Nexil simply exaggerating and trying to make groups seem far more complicated than they are?
I laugh at some of these ideas, like "a claymore that checks friendlies or enemies in a sensor" - um, claymores are an explosive device, trigged by a handheld "clicker" or tripwire and don't differentiate who activated the trip wire. Furthermore, when triggered, the blast affects everyone, not just "enemies" as explosives are not selective in any way.
As for "update all the scripts if 3 or 4 teams play" (wording was paraphrased) suggests to me that the scripts are poorly written. "Requiring the hacky group checks" -- I have no clue what this even meant. Is the author trying to suggest that a script that checks group membership is perhaps computationally intensive (which it isn't to my knowledge, any more than most LSL functions).
"Army specific equipment can have required group identification" -- again, I start to giggle. No weapon that I know looks at which uniform one is wearing. It seems to me that these proposals support some strange, unrealistic and stylised combat system that doesn't really enhance SL.
I'd prefer to see the LL staff working on things that matter to all users instead of supporting some quirky, unrealistic combat system.
And for the record, I did serve in the military and respect others who have.
Nexii Malthus
Tamiya Starling Well aside from your snarky comments and lack of experience, lets look at the current picture:
You got 3 public combat sims that are Concord, No Mans Land and Lexington, these are setup by LL towards a simple Red Team vs Blue Team scenario
But there is no way to join a team.
The respawn mechanism just teleports everyone to the same location without differentiation. So if you went from Blue team over to the Red team base and die there you are respawned at the Red team base suddenly.
There's your strange and unrealistic combat system, the very sims owned by Linden Lab themselves. Groups ain't fixing that.
Since you lack knowledge on the subject: Group specific equipment is actually very common in the Second Life Military Community (are you sure you served a military?), it's been so since at least 2008 from personal experience. It's what makes these separate communities work. Recruiting members and offering the perk of unique arsenal of equipment and uniforms. Having equipment tied to group keys hasn't been always been the case, but it IS something that is always reliable. Some equipment has been made to rely on external databases, however these databases are not around forever, so what happens? The equipment becomes unable to communicate and is stuck in a dead end. So keep giggling because "less is more" and that's true here in that group identification has worked very well even if it has flaws such as having to have the group set as active.
Nexii Malthus
It is common sense that claymores, unlike tripwires or landmines, are traditionally triggered by a llSensor with a group check, this has been the case for decades in SLMC and additionally in many games, which feature foe or friendly checks for claymores, since that is where the concept comes from. And how else would you tell foe and friendly apart? What if you want to mix people up in teams regardless of their group? We just don't have good underlying mechanisms for scripts so that we have less complex systems, less is more. Groups just don't really fundamentally work for game projects.
Team systems are important beyond combat but also in many game projects and places that don't have damage enabled. Since there is no way to have an easy way to create a reliable, shared list of agents or allegiance identification easily between many disparate objects without creating a complex system of secure communications, especially so across neighbouring sims. If you have 200 doors in your sim build but they locked to a specific allegiance, how do you manage that? Add dynamic elements like NPCs and vehicular traffic that spawn and disappear and can also be tied to allegiances themselves, e.g. if an NPC tried to get into a building but was locked behind a keycarded door.
I could keep going and come up with many, many usecases that a Teams system would greatly simplify, from combat to roleplay and gamedev in SL, but this comment would end up being way too long -- and it did in that canny told me my comment was too long so had to split it up.
Jeremy Duport
Nexii Malthus
Tamiya: "I did serve in the military and respect others who have"
\- I presume this means real military service, which bears mentioning since you might have taken it as being relevant to the discussion :P
--
Tamiya Starling If you run into a conversation about gameplay aspects of SL/LSL and see "military" bandied around, it's in reference to basically competing clans that've been doing twitch shooter and milsim scifi in second life since early 05. Without stopping.
It's notable basically because as platform users go, they've been doing a lot more with a lot less for a long time- performance is key when you want to mutually support potentially 60+ people in a region throwing tens of bullets per second each at one another, driving vehicles with complex behaviors, etc, on TCP both ways for the client experience.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.