Jump to content
Eternal Lands Official Forums
Diealot

Suggeston to add a party/team system with a specific UI

Recommended Posts

Would be nicer to just implement a proper formal party system and party specific GUI to go along with it.

 

Have a separate box that shows partied player names, hp, mana (and AcP).

An icon as to who is party leader (if applicable).

Show party members location on tab map

Have party chat (@@Party)

 

Could then add in an entire host of other party features:

Implementation for auto-split of drops, rolling for drops (if party sets up to do that instead of the current situation).

Target spells on player via party window. etc.

 

Almost all modern MMOs have systems like this. Even if the features end up mostly cosmetic (show partied character's hp/mana in a separate box and show everyone's location on a map), this would be a huge update to the current 'all you get is a separate chat channel that anyone with the number can join' system we currently have.

Edited by Diealot

Share this post


Link to post
Share on other sites

There's some simple stuff we could do client side towards this, such as a quick way to share your status into a chat channel, or even some of the party type features.  But more advanced stuff would be a lot easier, and we could do more perhaps, with some support from the server.  Here's some ideas for the needed server support:

 

Create / join functions

  • Party leader can create a new party, specifying a party name and pass-phrase or pin
  • Party leader can destroy the party
  • Other users can join the party by specifying the name and pass-phrase or pin, to become members

Or, an alternative set-up create / join functions

  • Party leader can create a new party, specifying a party name
  • Party leader can invite a new member to join the party
  • Party leader can kick a current member
  • Party leader can destroy the party
  • Optionally, members can invite others to join the party

Member functions:

  • (For the alternative set-up) Users can accept an invite to join a party
  • Members can leave the party
  • Members receive status information on other members, including if they are the leader, and their actor id if they are in range
  • Members can send and receive chat from a shared party channel

The server would need to maintain the state of the party .  Perhaps there would be a limit on the number of party members, and a time-out where the server destroys the party.  Perhaps a user is limited to creating and joining one party at time.  It would be useful to hold your party membership across client restarts.  It would be useful to queue join offers (alternative set-up) for when you start your client.  A lot of client side functionality could be built on top of something like this.

Share this post


Link to post
Share on other sites

:P the good thing there is with that party system we could remove the dependency of people having to join a channel for instances.

just look how many people of the party are online.

Quote

 

2 hours ago, bluap said:

Or, an alternative set-up create / join functions

  • Party leader can create a new party, specifying a party name
  • Party leader can invite a new member to join the party
  • Party leader can kick a current member
  • Party leader can destroy the party
  • Optionally, members can invite others to join the party

this would have the beauty that you could reuse the buddy system for the party system.  A party should only exists for say 6 hours at most, since all instances should be done inside 3 hours (not sure right now how long wtf max time is.)

Share this post


Link to post
Share on other sites

If you are talking about your being not able to party without someone in your buddies, I think that would be bad since we have limited amount of buddys avaliable.

 

But bluaps being onto this subject... just gave me hope now. :D

 

Love you bluap! <3

 

Kaddy.

Share this post


Link to post
Share on other sites

I think a party system would be best if it was separate from the buddy system.  Its a temporary group of players and would allow for more flexible teaming up.  We could of course make a simple change to the buddy window to enable you to easily invite a buddy to a party.

Share this post


Link to post
Share on other sites
4 hours ago, bluap said:

There's some simple stuff we could do client side towards this, such as a quick way to share your status into a chat channel, or even some of the party type features.  But more advanced stuff would be a lot easier, and we could do more perhaps, with some support from the server.  Here's some ideas for the needed server support:

 

Create / join functions

  • Party leader can create a new party, specifying a party name and pass-phrase or pin
  • Party leader can destroy the party
  • Other users can join the party by specifying the name and pass-phrase or pin, to become members

Or, an alternative set-up create / join functions

  • Party leader can create a new party, specifying a party name
  • Party leader can invite a new member to join the party
  • Party leader can kick a current member
  • Party leader can destroy the party
  • Optionally, members can invite others to join the party

Member functions:

  • (For the alternative set-up) Users can accept an invite to join a party
  • Members can leave the party
  • Members receive status information on other members, including if they are the leader, and their actor id if they are in range
  • Members can send and receive chat from a shared party channel

The server would need to maintain the state of the party .  Perhaps there would be a limit on the number of party members, and a time-out where the server destroys the party.  Perhaps a user is limited to creating and joining one party at time.  It would be useful to hold your party membership across client restarts.  It would be useful to queue join offers (alternative set-up) for when you start your client.  A lot of client side functionality could be built on top of something like this.

What happens if the Party Leader Grues or logs out? The next step is to think about worst case scenarios like that and try to address them.

Share this post


Link to post
Share on other sites

Bluap,

Whatever server-sided things gets the system implemented I think would be fine. Otherwise, yes. (:

 

I think a 'invite' function is generally better than a name/passphrase. Also I'm not sure why parties would need names, Guilds have names and these should be different than guilds.

 

Needs to be independent of buddy system as that's limited in number.

 

Could have a max number of people. What's the biggest party typical for wtf instance? That would be a good starting place.

 

If party leader logs out (for any reason, grue included) leadership would pass to the next most senior party member (whoever joined first).

 

If all party members log out, party is destroyed (possibly wait for next in game minute?)

 

If only one party member is logged in, party is destroyed within  a certain timeframe (the server shouldn't punish you for gruing, but shouldn't keep track of your party forever if only one person is online either).

 

Over time, the party system could potentially be how you join instances, but for starters, should keep how instances are joined currently as that works. If parties get implemented and work well can shift joining instance into party functionality. There's no reason you couldn't party with your instance group, even if that's not how you join (while party system is still new).

 

First features of a party system (aside from all the creating/inviting/destroying parts) in my opinion should be:

Viewing mana of party members within sight (if turned on)

Viewing hp/mana of party members in separate window (in the party list)

Viewing position of party members on tab-map

A party chat (so obvious almost left it out)

 

Edited by Diealot

Share this post


Link to post
Share on other sites

Parties would also be useful for just teaming up for an invasion, lenny hunting, or some other project.  Setting a max limit based on instances might hurt that.  And definitely don't use the buddy list, that's too small as it is.  I'm not sure I agree with setting a time limit on it, but if there is only 1 person in it, or no one in it, then it is destroyed after maybe 15 min to allow time for people to get back from grues or what have you.

Share this post


Link to post
Share on other sites
19 minutes ago, Aislinn said:

Parties would also be useful for just teaming up for an invasion, lenny hunting, or some other project.  Setting a max limit based on instances might hurt that.  And definitely don't use the buddy list, that's too small as it is.  I'm not sure I agree with setting a time limit on it, but if there is only 1 person in it, or no one in it, then it is destroyed after maybe 15 min to allow time for people to get back from grues or what have you.

I agree that keeping it independent of other features like instances would be best, allowing it to be use for all types of teaming up.  A time limit based on usage would work, I'm guessing it would be bad to keep unused parties around for too long clogging up the server.  Limiting characters to being in one party at a time will help, but if no-one from the party logs in for a a while, it should also probably get deleted.  I would hope its possible to keep the party active even if the leader is logged out so having others able to invite etc would be useful.  We need to see if there is interest from Radu to do the server side bits.  I'll happily do the client side stuff.

Edited by bluap

Share this post


Link to post
Share on other sites

Sorry i just meant with the buddy system, in the way of code re usement. the way that you handle the accept buddy and the list system would be good for a party system for up to say 20 people. it would need of course adjustments and be a separate system. I was more thinking about something that would make the need to code for the server less.

Share this post


Link to post
Share on other sites

I don't see any issue with making the buddy window also house party information. Can make tabs on it for buddy/party similar to how other windows have tabs.

 

If some of the code can be re-used from how buddies get accepted, great!

Share this post


Link to post
Share on other sites

This gave me an idea, since we're talking about tabbing the buddy list.  Is it possible to add a second buddy list into a tab fashion?  I had asked radu if we could increase the size of the buddy list but he said it can't be done.  Could that be fudged by adding a second one?

Share this post


Link to post
Share on other sites

Buddy list is at least partly server-side, so if radu says it can't be done, it probably needs changes in the data format for the character

(cf. storage slots, radu had the same objection there).

 

Now, you could always add a second one, but that way lies madness: you get essentially the same data split in two parts in your data files,

do that for a few different things and you get a maintenance nightmare.

 

Don't forget that an error in the handling of those datafiles might mean a character loses part of the data concerned (like part of a buddy list,

or part of an inventory), or gets rubbish in the character, or the server just refuses to accept the datafile, i.e. the character.

Try and explain that to the owner of a high level character...

Share this post


Link to post
Share on other sites

'what you describe depends solely on how you manage your data, and the sane way would be make a second system that is seperated from buddy system but is based on the same code base and data structure that worked so far.  But who says the data needs to be saved in a file just make a party membership vanish x minutes after a char logs out

. and you will be able to hold the data in an stack of objects that contain the info for a party system. there is no real need that a party system needs to survive a server restart

 

 

Edited by vinoveritas

Share this post


Link to post
Share on other sites

No need to survive server restart, no. Client restart, though, is a different story, which implies a log-out and subsequent log-in.

Character data are stored on log-out...

Share this post


Link to post
Share on other sites

So what revi, if the server has the data and a simple client request on am i in a party would get the info to the client. like so many other datas. the data does not need to be saved in the server files of a character.

 

And actually it would not need to survive a client logoff. We could make a character loose the state of a party on log off, they can join back after a log on so. after all this would have the benefit of people not logging off their alts during instances, to keep them as save bags. but have to risk them by letting them sit around awake. the server would not need to track the instance team members awake through a designated channel anymore, but by who is in the party.

Edited by vinoveritas

Share this post


Link to post
Share on other sites

I thought instances finished when too many participants logged off.

And are you sure that after the initial start, instancers have to stay in the channel?

 

All this, like my assumption that extension of the buddy list was "impossible" (according to radu) because it needs changes in the char file format,

is pure conjecture; only those with access to the server code can know about how it works in detail.

 

As for risking alts in instances, I think there are more serious problems with instances than that, like it being possible to do them with a party of only alts in the first place, and non-stop at that (in theory).

Edited by revi

Share this post


Link to post
Share on other sites

Yes revi, i did run once in the trap, that we only had 2 people active in the channel even if 4 chars where online and on the instance map.

And i did not wanted to suggest the buddy system as a storage file, but as the server code base that could be copy and pasted and at a few points adapted to a second system next to the buddy system. In that case the restrictions that radu has with his flat file character storage system would be avoided. and the development would cost less time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×