Forums » Suggestions
VO has enough players engaged in group activities that the 8 person limit is actually hit fairly frequently. If there are no insurmountable technical obstacles, the limit should be raised significantly or even eliminated.
Suggested many many times before. I believe Incarnate wants to create 'meta-groups' which contain groups of... groups, instead of enlarging the group limit. Or something.
That sounds annoyingly complicated. Larger groups would solve real issues for real players right now and probably wouldn't require more than changing a single constant in the code.
It will probably break the HUD at low resolutions though, or at least make it look messy.
So you say you cannot control how much can you group versus how much to display?
You can include resolution condition in the code and display less. Or it can be a client variable.
Or you can make the font smaller. Or you can ...
You can include resolution condition in the code and display less. Or it can be a client variable.
Or you can make the font smaller. Or you can ...
+1
VO has grown up, more players, bigger groups. Naturally we need bigger groups.
About small screen, simply add a scroll bar also as an option. Then it no longer matters how many players are in your group. And order by proximity by default.
VO has grown up, more players, bigger groups. Naturally we need bigger groups.
About small screen, simply add a scroll bar also as an option. Then it no longer matters how many players are in your group. And order by proximity by default.
I agree that there are ways to avoid the screenspace issue, but it's still an issue currently. :P
The problem with a scrollbar, alloh, is that (assuming you havent noticed, as there arent many scrollbars in the normal HUD) the mouse is automatically slaved to ship movement. The scroll wheel is often also slaved to various controls (depending on what the user wants). The only place you can use a pointer/scroll is in the PDA/Station screens. In these screens the group list disappears in favour of the PDA Buddies/Group tab. So basically..the only place a mouse or other device is usable for scrolling is in a mode in which the scroll bar in question wouldnt exist. Adding a completely new scroll up/down group control binding could work, but would be massively cumbersome. The devs suggestions of groups within groups eliminates this issue, and a simple toggle for showing all members or only your own group +group leaders would be a bit more user-friendly imho.
Even if they do a hierarchy system, 8 is still a bit small I think. If you have a casual group of 10 people (not trying to do any serious combat or anything), hierarchy could be overkill.
But this gives me an idea for a plugin - virtual groups could be created with a plugin that would have unlimited capacity. The basics of how it would work are this:
Each member would have his own group, with himself as the only member. They would still chat to the group channel normally. The plugin would then pm anything that they say to each member of the group. Location reporting along with the message (guild-chat style) could be toggled. (Note: unlike real group/guild chat, the location is untrustworthy - a plugin could be modified to lie).
To handle the creating and management of a virtual group, the plugin would listen for s PM with a specific invite format. If received, you could run a command (/vgroup join "BobVeela") and your copy of the plugin would create your empty group, then query the person who invited you for the current members, who it would then add to a list it keeps locally. The inviting person's plugin would also send an update to all other members telling them about the new member. If the group leader kicks anybody, the plugin would send updates letting people know who had been kicked, and would disband the kicked member's 1-man group.
Potential problem: all this pm-ing by the plugins would spam the chat, unless it is possible to intercept a message and prevent it from being printed. I'm not sure that is possible. But IIRC I think it is possible to send a PM without the sending of it being shown in your chat - that would be important so that you don't get hit by a wall of "->message" lines every time you send a line of text to the group and it gets relayed to the many members.
If you can't hide the echo when you send a PM via plugin, you could still get around it by having a bot do the relaying, i.e. you'd send the message to the bot, then the bot would send it to all the members.
Real-time location reporting could also be done, but this could be noisy without a way to suppress PMs. A quieter method would be to allow querying a member's plugin to see where he is on demand, so that it would only spam two people and only on request.
I don't really intend to write a plugin like that unless I get bored. Pretty much the only time I personally use groups is nation war. Otherwise I tend to be a fairly solo pilot. And there are other plugins I'd rather work on that would be more useful to me. So I don't have much motivation to do the gruntwork. But I thought I'd put the idea out there for anybody who does want one enough to do the work, but hadn't thought of this already.
But this gives me an idea for a plugin - virtual groups could be created with a plugin that would have unlimited capacity. The basics of how it would work are this:
Each member would have his own group, with himself as the only member. They would still chat to the group channel normally. The plugin would then pm anything that they say to each member of the group. Location reporting along with the message (guild-chat style) could be toggled. (Note: unlike real group/guild chat, the location is untrustworthy - a plugin could be modified to lie).
To handle the creating and management of a virtual group, the plugin would listen for s PM with a specific invite format. If received, you could run a command (/vgroup join "BobVeela") and your copy of the plugin would create your empty group, then query the person who invited you for the current members, who it would then add to a list it keeps locally. The inviting person's plugin would also send an update to all other members telling them about the new member. If the group leader kicks anybody, the plugin would send updates letting people know who had been kicked, and would disband the kicked member's 1-man group.
Potential problem: all this pm-ing by the plugins would spam the chat, unless it is possible to intercept a message and prevent it from being printed. I'm not sure that is possible. But IIRC I think it is possible to send a PM without the sending of it being shown in your chat - that would be important so that you don't get hit by a wall of "->message" lines every time you send a line of text to the group and it gets relayed to the many members.
If you can't hide the echo when you send a PM via plugin, you could still get around it by having a bot do the relaying, i.e. you'd send the message to the bot, then the bot would send it to all the members.
Real-time location reporting could also be done, but this could be noisy without a way to suppress PMs. A quieter method would be to allow querying a member's plugin to see where he is on demand, so that it would only spam two people and only on request.
I don't really intend to write a plugin like that unless I get bored. Pretty much the only time I personally use groups is nation war. Otherwise I tend to be a fairly solo pilot. And there are other plugins I'd rather work on that would be more useful to me. So I don't have much motivation to do the gruntwork. But I thought I'd put the idea out there for anybody who does want one enough to do the work, but hadn't thought of this already.
NPC convoys and skirmish missions already push the group over 8 members and it doesn't wreck the HUD too badly.
Changing the limit up to say, 12 shouldn't cause that much trouble...
+1 to OP.
Changing the limit up to say, 12 shouldn't cause that much trouble...
+1 to OP.
One small bug - turning off the group display in the hud leaves you with an empty space instead of the normal ship display.....
Adding a local limit to the group display might avoid some of the issues.....
Adding a local limit to the group display might avoid some of the issues.....
There are some good suggestions here for very large groups and such that will take a while to implement and test and might eventually be awesome. I don't want to take away from any of those. I do however want a solution to the immediate problem that can be implemented quickly.
The solution to the immediate problem is to increase the group size limit to say... 16.
The solution to the immediate problem is to increase the group size limit to say... 16.
I agree that a hierarchy system with less then 15-20 people in a group would be a waste of time, I was merely responding to the comment that adding scrollbars to the group list would make a difference. Honestly, while I completely agree that increasing the group size to 10 or 12 wouldn't jack up the HUD, its still a pretty rare occurrence to have that many people flying together, so therefore, not all that high of a priority..but it would be damn nice in those few instances.
Hmm. Noted. Will double check that there isn't some other stuff contingent on group sizes, and look into the possibility.
There were some unforeseen caveats with the group limit. Older technical aspects that need to be handled before we can change it. We still intend to, though, like you said.. we already did the HUD-related stuff and other additions needed.
Ping
bump?
bump
bump in tha face