Forums » Suggestions
I don't know. I think simple is best, especially if we want any hope of this actually getting implemented. There is no real need for 2 grouping systems (3 if you count player guilds). All this added functionality wouldn't hurt the current system any. If players didn't like the new features, they wouldn't have to use them. All we're really suggesting is just access to some extra information.
The only serious challenge to the current system that I foresee would be the persistent group idea, but even that could be worked into the current system more easily than creating an entirely new additional one. Maybe a good solution would be to bestow some of these new features upon the player guild system as well as the group system. Player guilds would then be the persistent group system that you are talking about. Either way, keep it simple!
The only serious challenge to the current system that I foresee would be the persistent group idea, but even that could be worked into the current system more easily than creating an entirely new additional one. Maybe a good solution would be to bestow some of these new features upon the player guild system as well as the group system. Player guilds would then be the persistent group system that you are talking about. Either way, keep it simple!
Strat, if players wouldn`t like the new feature of having their stats being broadcast throughout the group, what would they use to team up easily?
"A guild is an association of craftspeople in a particular trade."[1] Browsing the article, you`ll find that membering a guild involves determination towards a certain career, and that the purpose of guilds is most often to achieve a greater influence upon the outside world to the favour of the guild and its members.
But employment is no more than "a contract between two parties, one being the employer and the other being the employee"[2]. You get hired to do something, and the contract may end at any time. You may have another contract and do something completely different thereafter, and you can even have several contracts at a time.
Guilds are a political thing, employment is not.
[1]: http://en.wikipedia.org/wiki/Guild
[2]: http://en.wikipedia.org/wiki/Employment
"A guild is an association of craftspeople in a particular trade."[1] Browsing the article, you`ll find that membering a guild involves determination towards a certain career, and that the purpose of guilds is most often to achieve a greater influence upon the outside world to the favour of the guild and its members.
But employment is no more than "a contract between two parties, one being the employer and the other being the employee"[2]. You get hired to do something, and the contract may end at any time. You may have another contract and do something completely different thereafter, and you can even have several contracts at a time.
Guilds are a political thing, employment is not.
[1]: http://en.wikipedia.org/wiki/Guild
[2]: http://en.wikipedia.org/wiki/Employment
drazed, unions are fine, but no /group_viewable :)
A union should have properties like a description and flags to toggle the publicity of the union and its combined stats. Commands like the following would be there to maintain a union:
/union create <name of union>
/union disband <name of union>
/union invite <name of player || name of union || name of group>
/union expell <name of player || name of union || name of group>
/union view [name of property]
/union motd <text of description>
/union publish <name of property> <visible || invisible> <public || members>
/union list [regular expression]
/union transfer <entity> <recipient> [amount of entity]
/union showstat <name of player || name of union || regular expression> [stat type]
The statistic types being broadcast throughout the members of a union are summed up for the union, so that union has these statitics as properties. The `/union publish` command is to set such properties as either publically visible or not. Things owned by the union (money, equipment, cargo, ships, stations, members eventually) would always be fully visible to its _particular_ owner, visible to others according to flags set. --- `Particular owner` means that if a union is member of another union, stats would be broadcasted to the other union only according to flags.
The motd of a union is another property that can be published, so with `/union list`, players can retrieve a list of public unions. The list would show the name of the union, the motd, the number of members and the name of the player who owns it.
Entities that can be transfered with `/union transfer` are either the unit itself (to make another player or another unit its owner) or anything that belongs to the union itselfe (like money), provided it would make sense to give that instance of an entity to another player or another unit.
With `/union showstat`, members and owners of a union could view the stats of given members.
That leaves you with figuring out how to set up payments based on events or on time. It`s not so easy to have a command like `/union reward give money 10000 kill pirate` because you would have to specify first what is to be considered as a `pirate`. Maybe have a command like `/union enemy <add || remove> <player name || bot type>`, and whatever is needed. --- Rewards could be anything that belongs to the union like money, cargo, equipment, ships, stations or whatever.
Hm, `/union reward` would have to look like this:
/union reward <function> <argument> <argument> ...
Thus `function` can be used to define types of rewards like scores, or result in an action like actually giving a reward (or penalty) to a player.
Players should be able to give something to the union, and maybe there have to be ways to force players to give things to the union (like taxes). Your students on Queen hunting may have to pay you as an instructor :)
Having an interface to it in the PDA is probably the easiest part of such an implementation ...
Let me add that I think the idea of having subunits to be important. Structuring a (large) union into subunits eases administration in that the (chief) `employer` (entrepreneur) can set up payments/rewards/taxes towards subunits and let ppl in the subunits deal with them themselfes. For example, an employer may want to hire freighter pilots, escorts and patrols. Hire maybe 5 or 6 players for each task, and he suddenly has to deal with 15 to 20 players in his union seperately. But if he hired unions, he had to deal with only three. Unions would build reputation, like transport unions by the amount of cargo successfully transported, patrols by enemies killed vs. losses, patrols by enemies killed over time ...
Maybe that resembles guilds, but it would be up to guilds to make use of the union features.
Any player could run a mining company by making use of unions, for example, with miners and escorts, and be hired by those in need of minerals ...
A union should have properties like a description and flags to toggle the publicity of the union and its combined stats. Commands like the following would be there to maintain a union:
/union create <name of union>
/union disband <name of union>
/union invite <name of player || name of union || name of group>
/union expell <name of player || name of union || name of group>
/union view [name of property]
/union motd <text of description>
/union publish <name of property> <visible || invisible> <public || members>
/union list [regular expression]
/union transfer <entity> <recipient> [amount of entity]
/union showstat <name of player || name of union || regular expression> [stat type]
The statistic types being broadcast throughout the members of a union are summed up for the union, so that union has these statitics as properties. The `/union publish` command is to set such properties as either publically visible or not. Things owned by the union (money, equipment, cargo, ships, stations, members eventually) would always be fully visible to its _particular_ owner, visible to others according to flags set. --- `Particular owner` means that if a union is member of another union, stats would be broadcasted to the other union only according to flags.
The motd of a union is another property that can be published, so with `/union list`, players can retrieve a list of public unions. The list would show the name of the union, the motd, the number of members and the name of the player who owns it.
Entities that can be transfered with `/union transfer` are either the unit itself (to make another player or another unit its owner) or anything that belongs to the union itselfe (like money), provided it would make sense to give that instance of an entity to another player or another unit.
With `/union showstat`, members and owners of a union could view the stats of given members.
That leaves you with figuring out how to set up payments based on events or on time. It`s not so easy to have a command like `/union reward give money 10000 kill pirate` because you would have to specify first what is to be considered as a `pirate`. Maybe have a command like `/union enemy <add || remove> <player name || bot type>`, and whatever is needed. --- Rewards could be anything that belongs to the union like money, cargo, equipment, ships, stations or whatever.
Hm, `/union reward` would have to look like this:
/union reward <function> <argument> <argument> ...
Thus `function` can be used to define types of rewards like scores, or result in an action like actually giving a reward (or penalty) to a player.
Players should be able to give something to the union, and maybe there have to be ways to force players to give things to the union (like taxes). Your students on Queen hunting may have to pay you as an instructor :)
Having an interface to it in the PDA is probably the easiest part of such an implementation ...
Let me add that I think the idea of having subunits to be important. Structuring a (large) union into subunits eases administration in that the (chief) `employer` (entrepreneur) can set up payments/rewards/taxes towards subunits and let ppl in the subunits deal with them themselfes. For example, an employer may want to hire freighter pilots, escorts and patrols. Hire maybe 5 or 6 players for each task, and he suddenly has to deal with 15 to 20 players in his union seperately. But if he hired unions, he had to deal with only three. Unions would build reputation, like transport unions by the amount of cargo successfully transported, patrols by enemies killed vs. losses, patrols by enemies killed over time ...
Maybe that resembles guilds, but it would be up to guilds to make use of the union features.
Any player could run a mining company by making use of unions, for example, with miners and escorts, and be hired by those in need of minerals ...
Wow. This got a lot more complicated than it needs to be. If you don't want people to see how many kills you have, don't join a group (even though anyone can see that info on you now anyway by hitting 'k'). It's not a big deal.
I think you guys have a different suggestion, involving player-run unions or whatever you want to call them. I think you should post a separate thread for that because it clouds the simplicity of the group stats idea and are therefore makes simple group stats much less likely to get implemented (although I don't think your union system is a bad idea at all).
The beauty of this original suggestion, as represented by the first few posts of this thread, is that it is just asking for some information that allows players to create infinite numbers of player-run events and systems ON THEIR OWN, without the devs having to specifically create them. The possibilities are endless. Your union idea has become very specific to one type of player activity and would require the devs to set up a specialized system based on that one activity.
I'm fine with just keeping the basic group system that we have now. Just show me how many kills we have as a group and show me how many kills an opposing group has.
Stats for specific players, including kills, deaths, and credit flow would be really nice but would not be absolutely necessary. You can save player-specific stats along with persistence for your union suggestion. However, I have serious doubts that a union system would ever actually be implemented, in which case individual player stats would fit fine into the normal group system in addition to the overall stats, like drazed originally suggested.
I think you guys have a different suggestion, involving player-run unions or whatever you want to call them. I think you should post a separate thread for that because it clouds the simplicity of the group stats idea and are therefore makes simple group stats much less likely to get implemented (although I don't think your union system is a bad idea at all).
The beauty of this original suggestion, as represented by the first few posts of this thread, is that it is just asking for some information that allows players to create infinite numbers of player-run events and systems ON THEIR OWN, without the devs having to specifically create them. The possibilities are endless. Your union idea has become very specific to one type of player activity and would require the devs to set up a specialized system based on that one activity.
I'm fine with just keeping the basic group system that we have now. Just show me how many kills we have as a group and show me how many kills an opposing group has.
Stats for specific players, including kills, deaths, and credit flow would be really nice but would not be absolutely necessary. You can save player-specific stats along with persistence for your union suggestion. However, I have serious doubts that a union system would ever actually be implemented, in which case individual player stats would fit fine into the normal group system in addition to the overall stats, like drazed originally suggested.
Yes, it`s probably not easy to implement --- though my intention was something easy, it became complicated when thinking about it. It would work for the PCC you have in mind, and for more.
Just showing group kills should be ok, still there would have to be some way to define to whom such groups and their kills should be visible.
Maybe that could be done by `linking` one group to another with a `/group link <group name>` command. Kills could be shown in the target info or character info of the players who are member of such a group.
It would be a makeshift feature, but why not having it when it helps :)
Just showing group kills should be ok, still there would have to be some way to define to whom such groups and their kills should be visible.
Maybe that could be done by `linking` one group to another with a `/group link <group name>` command. Kills could be shown in the target info or character info of the players who are member of such a group.
It would be a makeshift feature, but why not having it when it helps :)
Group stats would be sweet. But some players might like to keep their stats private. So, unions are like groups, with the simple addition that anything you can see the personal stats already in the current PDA (Who went where, and kiled [or got killed by] whom, at what time, and the distance of what ships) for players in your union. If you're really committed to creating a scheme for paying people by the hour for whatever tasks, I'll bet you could make a pretty sweet bind for it using all the information thought up in these last two pags, but that'll remain the freedom of the player.
Well we can agree that no one would want how many kills they have kept secret. You can already see that information by looking at how many kills someone has when they enter a group and comparing it to how many they have when they leave it (by hitting 'k').
At the very least they could add an option to display the total kills for a group and the individual kills of each player in the group. That would simply make information we already have access to easier to view.
However, I don't see how privacy is important to this topic. If you don't want people to see your stats, don't join a group. Even so, I'm not sure why anyone would want to keep their cash flow a secret anyway.
If you want to make a separate grouping system that tracks this info and call these info-groups "unions", that's fine I guess. It just seems silly because no one would ever use the old grouping system. In every situaution in which I've been in a group, it would have been useful to have access to our total number of kills. You mind as well get rid of the old info-less system, or you mind as well just give the grouping system we have now access to these stats.
Either way, access to some basic info about people you are grouped with would be incredibly valuable. This along with the ability to access the overall stats for other groups would create countless possibilites for player-run content.
At the very least they could add an option to display the total kills for a group and the individual kills of each player in the group. That would simply make information we already have access to easier to view.
However, I don't see how privacy is important to this topic. If you don't want people to see your stats, don't join a group. Even so, I'm not sure why anyone would want to keep their cash flow a secret anyway.
If you want to make a separate grouping system that tracks this info and call these info-groups "unions", that's fine I guess. It just seems silly because no one would ever use the old grouping system. In every situaution in which I've been in a group, it would have been useful to have access to our total number of kills. You mind as well get rid of the old info-less system, or you mind as well just give the grouping system we have now access to these stats.
Either way, access to some basic info about people you are grouped with would be incredibly valuable. This along with the ability to access the overall stats for other groups would create countless possibilites for player-run content.
Strat, agreed.
Groups will become the non-private form.
Unions will become the private form.
Groups will become the non-private form.
Unions will become the private form.
I like the idea of having seprate groups/unions and perhaps even others. But for the short term I strongly feel that the current group system just needs access to some basic stats.
Unions and the like would require a good deal of work to create, adding group access to some basic stats should be pretty easy though?
I think the following set of steps could be used to bring this in quickly,
1. *NOW* Add a group tab to the PDA, this group tab has a list of the people in your group along with some very basic stats (eg, #kills since joining group, #pk's since joining group, credit gain/loss since joining grou). This doesn't seem hard especially since these stats are already ingame and player accessible.
2. *SOON(tm)* Make each player in the PDA's group tab selectable with a tab/window of their own. In here you could have more detailed stats on the player (eg. # and type of bots killed, player kill list + load out of both players, which stations/sectors money was made lost at and maybe how?.....). Perhaps make many of these stats hidable by the user when they join the group? I could see how some people might not want others to know where/how they made money, but maybe they shouldn't be in a group then?
3. *NOT SOON(tm)* Bring out seprate Group/Union/Guild interfaces for this PDA tab. Add automated group memeber billing/wages to the group/union/guild bank, public/private groups, persitant (log on/off) groups. Lots more to come up with here but I think this could be left off till well after the introduction of all the nifty other goodies we get soon(tm) like dynamic economy faction standing and glubbdubdrib to name but a few.
Unions and the like would require a good deal of work to create, adding group access to some basic stats should be pretty easy though?
I think the following set of steps could be used to bring this in quickly,
1. *NOW* Add a group tab to the PDA, this group tab has a list of the people in your group along with some very basic stats (eg, #kills since joining group, #pk's since joining group, credit gain/loss since joining grou). This doesn't seem hard especially since these stats are already ingame and player accessible.
2. *SOON(tm)* Make each player in the PDA's group tab selectable with a tab/window of their own. In here you could have more detailed stats on the player (eg. # and type of bots killed, player kill list + load out of both players, which stations/sectors money was made lost at and maybe how?.....). Perhaps make many of these stats hidable by the user when they join the group? I could see how some people might not want others to know where/how they made money, but maybe they shouldn't be in a group then?
3. *NOT SOON(tm)* Bring out seprate Group/Union/Guild interfaces for this PDA tab. Add automated group memeber billing/wages to the group/union/guild bank, public/private groups, persitant (log on/off) groups. Lots more to come up with here but I think this could be left off till well after the introduction of all the nifty other goodies we get soon(tm) like dynamic economy faction standing and glubbdubdrib to name but a few.
Sometimes players drop out of a group for no apparent reason. They must /group leave then, be reinvited and rejoin. That`s something that would have to be handled somehow.
Ok, so no group stats for now. Could we at least get a Group tab in the PDA for the group member locations (like the buddy locations). That would at least make me think group stats are in the works ;)
On a side not, the buddy list locations and group locations still broken? I can't track anyone down, always in the wrong sector. Are the buddy/group locations supposed to be a jump back? Or is my client broken in some way?
On a side not, the buddy list locations and group locations still broken? I can't track anyone down, always in the wrong sector. Are the buddy/group locations supposed to be a jump back? Or is my client broken in some way?
I'd really love to see some of the ideas in this thread.
The group listing seems to break sometimes when you enter a sector where a member is docked; it shows you his last location instead of the current one. Maybe it's caused if the player arrives and docks before the system "notices" his action or something, I dunno. Apart from the that, they work properly on Windoze.
Bump!!!
But seriously, we have a "Comm" section in the PDA with a subsection for "Buddies" and "Guild" but we don't have a subsection for "Group"? Do I need to post this in the bugs forum? I need to undock from a station to see who's in my group? WTF??? Speaking of quick-n-dirty.... oh look at the time, gotta run ;)
But seriously, we have a "Comm" section in the PDA with a subsection for "Buddies" and "Guild" but we don't have a subsection for "Group"? Do I need to post this in the bugs forum? I need to undock from a station to see who's in my group? WTF??? Speaking of quick-n-dirty.... oh look at the time, gotta run ;)
I think drazed and I will continue to bump this thread until the end of time unless it is implemented. We want group stats and a nice tab in the PDA for it!
I'd include this in my HUD improvements, but it's primarily a PDA improvement.
Well it can be part of the HUD too. Your group's kills should be viewable right on the HUD, as well as another group's.
I totally agree. One of the best suggestions I've read, and a quick win.
It would also solve the problem of groups being size limited to 8.
It would also solve the problem of groups being size limited to 8.
[Stamp of Approval]™