rank conditions

rank conditions

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

Post Reply
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

rank conditions

Post by Silentwings »

Two suggestions for general discussion:

I think it would be useful to lower the bar for progressing from first to second rank, at currently 5h in-game time, to enable the first->second rank transition to be used as a check by autohosts for "should we tell completely new player info to this guy". I suggest 2h.

Current hours used by uberserver for in-game for rank progression are [5, 15, 30, 100, 300, 1000, 3000]. I suggest adding a new top level, replacing this with [2, 10, 30, 100, 300, 1000, 3000, 10000], which I think better matches the distribution we have. There are already have a few users who reached 10000, and others on the way to joining them (I am not even close...).
abma
Spring Developer
Posts: 3622
Joined: 01 Jun 2009, 00:08

Re: rank conditions

Post by abma »

afaik there is no bit left for rank no. 8.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: rank conditions

Post by Silentwings »

You are right. JSON ftw here. It can wait...
User avatar
MasterBel2
Posts: 347
Joined: 11 Apr 2016, 12:03

Re: rank conditions

Post by MasterBel2 »

Never mind I can't count.
Last edited by MasterBel2 on 06 Sep 2018, 03:51, edited 1 time in total.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: rank conditions

Post by Silentwings »

Actually, there are spare bits, only 7/32 bits are currently used, just the rank bits are currently in the middle so adding more rank bits one would want some re-ordering.

It should work to deprecate the current rank bit positions and use up some of the free positions for a new longer set of rank bits (+compat flag). Could be done entirely in the protocol, no change needed to db. Not sure if its worth the trouble.
abma
Spring Developer
Posts: 3622
Joined: 01 Jun 2009, 00:08

Re: rank conditions

Post by abma »

Silentwings wrote: 13 Sep 2018, 18:55 Actually, there are spare bits, only 7/32 bits are currently used, just the rank bits are currently in the middle so adding more rank bits one would want some re-ordering.

It should work to deprecate the current rank bit positions and use up some of the free positions for a new longer set of rank bits (+compat flag). Could be done entirely in the protocol, no change needed to db. Not sure if its worth the trouble.
why not just change to [2, 10, 30, 100, 300, 1000, 3000]?

IMHO its not worth the trouble as clients have to be changed, too.
User avatar
Jools
XTA Developer
Posts: 2812
Joined: 23 Feb 2009, 16:29

Re: rank conditions

Post by Jools »

Seconded
User avatar
bibim
Lobby Developer
Posts: 913
Joined: 06 Dec 2007, 11:12

Re: rank conditions

Post by bibim »

In case it might be useful to adjust rank conditions:
Image
Spring_ranks.png
(45.11 KiB) Not downloaded yet
abma
Spring Developer
Posts: 3622
Joined: 01 Jun 2009, 00:08

Re: rank conditions

Post by abma »

@Silentwings:

what about to count only time from ingame on hosts with botflag?
User avatar
ThinkSome
Posts: 344
Joined: 14 Jun 2015, 13:36

Re: rank conditions

Post by ThinkSome »

> "should we tell completely new player info to this guy"

What do you mean by this?

The amount of light green in that chart is highly concerning.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: rank conditions

Post by Silentwings »

abma wrote:what about to count only time from ingame on hosts with botflag?
I'm not sure about this because some games will display newbie infos for singleplayer mode and others for online multiplayer (e.g. recall past issues with ZKs system when they were using online battles for singleplayer mode).

More generally, for several reasons I think that the status/battlestatus infos used in the protocol have become a bit outdated. I don't know if this gets in the way of lua menus/missions/lobbies, or if instead its best to wait for people making them to ask for changes. Either way, I would rather wait for a some-time revamp before doing anything.
Post Reply

Return to “General Discussion”

cron