Jump to content

RoundShades

Members
  • Posts

    2595
  • Joined

  • Last visited

1 Follower

About RoundShades

  • Birthday 03/04/1991

Personal Information

  • Location
    LunarHalcyon

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

RoundShades's Achievements

Newbie

Newbie (1/14)

95

Reputation

  1. Late by a month, but, Good to see you @RypeL. I suppose if i have any constructive and easy approaches to this, these suggestions could be functional. Suggestions: ---Make UI regurgitate reply buttons below teamchat at all times. So basically, at bottom or top of teamchat, in narrow font or whatevs, display [Chat: Reply - "T" Global, "Y" Team]. Make T whatever the settings mapped to (this is already done in different parts of the UI iirc). ---As a feature, and iirc Planetside2 will sometimes do this based on local playercount, but maybe automatically assign players to other players with a green marker, that the player can then assign/unassign to other players later? Basically, a form of q-marking ally players, that leaves them permanently marked, and the game always automatically marks an ally at game start. For newbies and just general gameplay, this would at least encourage players not to wander around doing things by themselves. iirc, the commander mod already does a version of this just for the commander that iirc became less obvious with newer updates (instead of a unique color it matches other hud elements) I'm frankly saddened to see this topic blew up so badly lately. It could be addressed, but ideas are finnicky, yet moving forward constructively: ---one suggestion, is in most games you can't teamswitch unless a person on each team agrees to switch. in most games, after a victory, players are also split up. So possibly make this default, of course servers can choose to change settings, but at least there's a chance servers with this setting would be desirable? Some effort has to be made by players of course. ---if not the case, and the playerbase doesn't have competitive groups in each team that stand a chance against each other, then maybe players should be balanced by recent wins and losses while game has been running by some background tally, and the server keeping a team balance like this, if not by forcing individuals into teams, then by allowing individuals on one team but providing more of the other players to the other team. If a team stacks, the least they could do is allow the other team 1 or 2 extra of the players that aren't stacking. It's something, for sure. ---otherwise, if nothing is decided that could fix this in-game, then players are going to have to use existing tools at their disposal. That might just have to be accepted with awareness. Use gamechat, rationalize the team situation, and plan ahead. Can't win without being realistic and/or positive. Really, my final suggestion touches on another situation anyway, and that's playercount based on server capacities, another off and on topic. This one is easy to address because my personal opinion is the same on it, and thus too fixes stacks to some degree: ---People populate large server, eventually it gets close to capacity. So add functionality, that at some "large enough" point, on match end, that half the players are migrated to another designated/automatically-chosen server, thus turning 1 full-populated server into 2 fairly-populated servers. Neither one will have enough population to stack, yet stackers and pubbers could both switch servers manually if they like. Nobody is forcing them to stay, and they're not obligated to play where's bugging them, so i'd imagine free will would fix that, NOT TO MENTION servers have more of a chance to fully populate more and more servers rather than just fully populating one and people get stuck waiting around 1 server population instead of successfully expanding to multiple server population. E.g.: People populate FBI server. When server reaches 36 (or 40, w/e), and a match ends, the match-end detects playercount. Detecting the amount of players, it goes through map selection, then that blackscreen. Make half the players receive a trigger that has them connect to another server (either specified by server, or server decides based on server listings in-the-moment), the new server that was empty receives the players and the map choice and launches the chosen map for them. As a result, 2 servers now play the same map, each with half the population, and incoming players can now choose to populate either one. If players LIKE a large playercount, they can all migrate and make one larger again (either make a server only perform a split once, or only every so many matches in a row), while players that don't mind can play the match that's running already as players continue to join. If a large count is reached in either server a few matches later, the match-end detects large playercount again, and searches for yet another migration to execute a divide again. An added suggestion: a map selection (when server doesn't have settings for rotation or vote-any-map), that shows 5 options based on playercount, so that servers with 12 players get snow/walls/canyon, and servers with 32 players get the larger and often new maps. In summary; Player count, is affected by server population, willingness to expand population across multiple servers and thus multiple server-counts, and established stackers within the one struggling server population. It's important for global playercount to overcome the obstacle of single-server playercount, otherwise the future might always be rocky and limited. Just suggestions. Some easy, some not. Sorry I don't type more concise these days lol.
  2. Right, that was firefox in case it wasn't clear. Thought i got the firefox icon in the screenshot somewhere. EDIT: Oh, there's the word Firefox. ANYWAY, yeah, it's webpage cert expiration.
  3. Necro because Happy Easter 2019 Everyone.
  4. I've always been a huge fan of City. I'd like to see the day, for sure.
  5. Also, they do their job very well, if they were limited in some way to how they can defend against infantry, they wouldn't break any and all options by existing without having to obliterate them as step1.
  6. It's also the holidays so people may be away for that, but it would be right about this time of day that people are active and playing it. I'll take a look... EDIT: As of right now, 15 people are in 1 server. That's honestly a server playing for all intents and purposes, and isn't too bad for a holiday. Wednesday and after, it'll probably be 40-60 players in 1-2 servers.
  7. I half ass rather the beacon be disarmable than the missile have a healthbar. Could you imagine just shooting the Nod Nuke or the GDI Ion Cannon Sattelite?
  8. Big publisher games: 3-4 visual/audio/ui cues when something happens. Small developers: 1 cue should be fine, even though the community is asking for at least 2. It's not like the event is game-deciding or anything.
  9. I feel like the smoke and the shoot-down are both copouts to it being strong. Should be useful, sure, but not the single most clinching game mechanic available ingame.
  10. Really, I wouldn't mind grouping it with Airstrike, and allowing 1 of each to be used every minute (along with a cost). Either both being commander power, or both being a PT beacon-like/laser-like. To differenciate both more, just make 1 last 20 seconds and do wide area infantry damage, and the other do pinpoint singletime high-damage. I don't really even like how you can shoot them down inconsistently depending on stuff at the time. Would be more consistent if it had a limit, rather than be spammy but the game might put it in a good spot to have a coin flip to shoot it down. Otherwise, why not shoot down airstrikes too? As far as 1-person power, I don't like how commander power does that, but the added content itself is fine. Commander powers should cut bureaucracy and just let more than 1 player use said tools, even if it's 2-3. That way at least it feels more accessible as a team. Idk if it should be allowing vote for more than 1 person to have tools, color-coding them a bit, and/or just allowing all players to call commander power and put an instant vote up to approve requiring 25% team vote yes. OR something. Just bad to rely on both teams getting 1 good commander to use it in a non-gimmicky non-cheesy non-1sided way.
  11. The biggest problem isn't what people want. It's what they don't want. Some want 40, some want 64, nobody wants 0. Solving that problem, by providing servers with a form of mitosis, lets there be more than 1 server at any given time. Who knows, with enough room, it might have been possible to get 3 60 player servers full this whole time, sans the human element.
  12. 64 players can function, but not offering for vote the choices given. Snow cannot run with 64 players, it should stop being offered when servers reach 64 regardless. It's a simple fix imo, 64 players would be playable with that change.
  13. Both are statistically wrong. What people WANT is also statistically wrong. The game can PLAY with 40 player servers, especially so with migration filling new servers too. The game plays WORSE with a player cap not allowing a new server to populate, or with a player cap so high that a fraction of unwilling players go play god-knows-what-else instead. Democracy is good, but I support a pretty logical right answer. I doubt anyone playing in 60 player servers, are going to leave the moment it gets down to 38 players. There is thus no associated risk with keeping servers populated but not intentionally at constant-60. A close-second option, is map-voting that chooses vote-options that are good for playercount, and maps having a number-setting to compare to playercount. That way, low-pop servers are playable, and high-pop servers are playable. There are 2 right answers, and neither of them are a 40 or 60 player server without additional work.
  14. That was literally higher in this thread, and is what I labeled "as suggested". If that can be done then it's totally the way. To be fair, it wasn't the first time suggested, just the first time provided with a foundation of code to utilize. EDIT: I forgot the link is in a community devs thread from like 2 years ago or more. Still, I suggested the bootleg way of servers just providing a 60 player server, and writing an IRC script where if player count exceeds 56, to close the 60 player server and open two 40 player servers and in-game announce the closing. Then, Agent suggested coding an auto-migration tool for two-60player servers to dump 28 players in the other server when it reaches 56 players. I was always a big fan, if it can be done then may it rain blessings.
×
×
  • Create New...