Say Team

ID:150510
 
Sep 9 2001, 11:18 am
I know I saw this somewhere a while back, but I can't find the post. I just wanna know how to allow a player to talk to his team, I tried this..

say_team(msg as text)
if(team == 1)
team << "[usr] : [msg]"

When a player logs into blue or red, ill say blue it makes their team == 1.
Sep 9 2001, 11:31 am
Oblivian wrote:
I know I saw this somewhere a while back, but I can't find the post. I just wanna know how to allow a player to talk to his team, I tried this..

say_team(msg as text)
if(team == 1)
team << "[usr] : [msg]"

When a player logs into blue or red, ill say blue it makes their team == 1.

Thats not even close :P
Anyways, you need to do a for loop through the people with the team var equal to 1, then give the message to those people

Alathon
Sep 9 2001, 6:47 pm
Why not try creating an object for the team?

obj/team
var/list/players

proc/add(M as /mob)
players.Add(M)
players << "[M] joins the team."

proc/remove(M as /mob)
players << "[M] leaves the team."
players.Remove(M)


Of course, this code is completely untested and I'm so new to BYOND that I have no idea if any of this works. But in general, the idea of using an abstract object to manage your team is sound. Each team can be defined as an object like obj/team/red and obj/team/blue. You can set a team variable in your mobs, and whenever you want to talk to the team, it should be a simple matter of saying:

if(team!=null)
team.players << "Hello, team!"


Lummox JR
Sep 9 2001, 8:52 pm
In response to Lummox JR
Lummox JR wrote:
Why not try creating an object for the team?

It's a good approach...and lets you store things like who the team creator is in one location that everyone has access to, rather than having every player carry around a batch of team variables, as some people do.


Of course, this code is completely untested and I'm so new to BYOND that I have no idea if any of this works.

The code is fine...but you might consider using the list operators. Personally I find them easier to read than Add() and Remove():

players += M
players -= M


This is a feature that some other languages need to steal from DM.
Sep 10 2001, 5:19 am
In response to Deadron
The list operators were my preference but I thought it'd be good to play it safe. :)

You're right, though, the team-as-object approach has other advantages--ones I didn't even think of at first. Among them, you can also define who leads your team, if anyone has authorization to use admin commands on your team, and what the team's objectives are. It's also possible to put things in team.contents as a group inventory, like shared food rations and supplies; one can even design the system so that the last person on a team inherits that inventory.

Lummox JR
Sep 10 2001, 6:48 am
In response to Lummox JR
Lummox JR wrote:
You're right, though, the team-as-object approach has other advantages--ones I didn't even think of at first. Among them, you can also define who leads your team, if anyone has authorization to use admin commands on your team, and what the team's objectives are. It's also possible to put things in team.contents as a group inventory, like shared food rations and supplies; one can even design the system so that the last person on a team inherits that inventory.

Great ideas!

A team object is a simple concept, but I hadn't thought of it before...though in my defense I haven't done any grouping implementation yet (we'll probably have one for L&D at some point).

In many RPGs, one of the challenges becomes how to handle it when a team member ends up in a different zone/handled by a different process or computer. For example, in EverQuest if you die, you go back to your bind point, which may be handled by a different computer, therefore you don't have access to the team object.

I think the answer is to copy the team object to the other zone, but make it a slave...it receives updates from the main team object when things change.

Anyway this detail won't matter for most BYOND games anyway.
Sep 10 2001, 7:12 am
In response to Deadron
Deadron wrote:
Lummox JR wrote:
You're right, though, the team-as-object approach has other advantages--ones I didn't even think of at first. Among them, you can also define who leads your team, if anyone has authorization to use admin commands on your team, and what the team's objectives are. It's also possible to put things in team.contents as a group inventory, like shared food rations and supplies; one can even design the system so that the last person on a team inherits that inventory.

Great ideas!

A team object is a simple concept, but I hadn't thought of it before...though in my defense I haven't done any grouping implementation yet (we'll probably have one for L&D at some point).

In many RPGs, one of the challenges becomes how to handle it when a team member ends up in a different zone/handled by a different process or computer. For example, in EverQuest if you die, you go back to your bind point, which may be handled by a different computer, therefore you don't have access to the team object.

I think the answer is to copy the team object to the other zone, but make it a slave...it receives updates from the main team object when things change.

Anyway this detail won't matter for most BYOND games anyway.

Will for mine, as Im using some of the concepts Everquest use(very few mind you) one is the general setup of zones/areas/whatever, so Il have to keep this in mind

Alathon