Server Help Forum Index Server Help
Community forums for Subgame, ASSS, and bots
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   StatisticsStatistics   RegisterRegister 
 ProfileProfile   Login to check your private messagesLogin to check your private messages   LoginLogin (SSL) 

Server Help | ASSS Wiki (0) | Shanky.com
Managing flag id transfers between players?

 
Post new topic   Reply to topic Printable version
 View previous topic  S2C weapons packet - weapon info Post :: Post ASCCC Chat Client 1.0 Released  View next topic  
Author Message
grazzhoppa
Novice


Joined: Jan 03 2007
Posts: 29
Offline

PostPosted: Wed Aug 19, 2009 3:19 am    Post subject: Managing flag id transfers between players? Reply to topic Reply with quote

My question: anyone guess why the continuum protocol doesn't include flag IDs in the kill/death packet ?

And if you bother to read below, is there an easier way keep a valid association of flag IDs with players despite the protocol's shortcomings?


Below is the headache that justifies the above question:


[S2C 0x13 flag pick-up] and [0x12 flag location] packets give an ID# to the flags involved in the game event.
but
[S2C 0x06 kill/death] packet doesn't give these IDs. The protocol doesn't tell us which flag IDs were transfered from one player to the other after a kill.

If we want to maintain a valid association of flag IDs to players we need to do a lot of data wrangling icon_sad.gif

In the case where the killer always takes all the killed's flags (arenas like Extreme Games' pubs), we can easily assign all flags that were associated with the killed to killer now.

But this is not always the case.
(Subgame server setting: Flag:CarryFlags:0-2:Whether the flags can be picked up and carried (0=no, 1=yes, 2=yes-one at a time))

In arenas with this set to 2 at the reception of [S2C 0x06 kill/death] packet, we check if killer was already carrying a flag. If so, we know that killed's flag will be neuted and we'll get a flag location packet for it soon. Otherwise, we assign the flag ID carried by killed to killer. Until we receive the flag-location packet for the 1st case, we mark that flag ID as "uncertain".
--------------------------------------------------

but what about connecting to ASSS zones like Hyperspace where subgame's limited flag-carrying settings no longer apply? In Hyperspace's pub arena players carry a maximum of 4 flags.

If the killer is carrying 3 flags, and the killed is carrying 4 flags - we won't know which flag ID is transferred until we receive 3 [S2C 0x12 flag-location] packets. While waiting for those packets, we could receive a kill/death packet telling us that the killer (now carrying 4 flags) could be killed by someone carrying 3 flags. And this could continue many times before we actually start receiving flag-locaiton packets.

Keeping track of which flag IDs are certainly carried by killers requires associating "uncertain" flag IDs with "possible carriers" and remembering how many flags were transfered (this # is provided in the [S2C 0x06 kill/death] packet). When a "possible carrier" is killed, we reassociate all of the "possible carrier"'s "uncertain" flags with killer.

If a "possible carrier" kills another "possible carrier", the killed's "uncertain" flags get merged with the killer's. The amount of flags transfered for this new merged group is the sum of both groups that were merged.

As flag-location packets start to come in, we search these "uncertain" flag groups and remove the flag ID that comes with the flag-lcoation packet. After this removal, when the amount of "uncertain flags" in the group equals the amount of flags transfered from the kill/death message, we finally know which flag IDs were actually transfered at the kill event.
----------------------------------------

Here's a struct that associates "uncertain" flags with a "possible carrier". The implemenation of this took about 150 lines; 100 of those are in the handler for the kill/death packet.

Code: Show/Hide

struct FLAG_ {

   uint16_t      id;         /* server's ID for this flag */
   POINT_TILE   location;

   FREQ      freq_owner;   
   PLAYER_ID   carrier;

   /* accounting for continuum protocol's gayness of not giving flag ids
    * in 0x06 (kill/death packet) so flags ids transfered during kills/deaths are unknown
    */
   bool valid;
};


struct FLAG_GROUP_ {

   /* all possible flags carried by possible_carrier
    * due to a kill/death partial flag transfer
    */
   Array/list/tree of flag IDs or pointers to FLAG struct;

   PLAYER_ID possible_carrier;

   /* amount of flags of this group that are carried by possible_carrier */
   uint16_t flags_transfered;
};
Back to top
View users profile Send private message Add User to Ignore List
JoWie
Server Help Squatter


Gender:Gender:Male
Joined: Feb 25 2004
Posts: 215
Offline

PostPosted: Wed Aug 19, 2009 8:36 am    Post subject: Reply to topic Reply with quote

I am pretty sure you can do that in subgame by setting Flag:CarryFlags higher then 2 (i could be wrong, i have never tried it, but since this value is sent to continuum in the settings packet I would expect it to work)

Quote:

cfghelp: Flag:CarryFlags, arena, int
Whether the flags can be picked up and carried (0=no, 1=yes, 2=yes-one at a time, 3=yes-two at a time, 4=three, etc..)




What ASSS' flagcore does when you kill someone is:
1. Internally transfer the killed flags to the killer while the killers flag count is under "cancarry" (cancarry is 255 in CarryFlags=1, 1 in CarryFlags=2, etc).
2. If we reached cancarry in step 1, some flags "overflowed" and do the following:
2a. Have the killer drop all his flags using the S2C_FLAGDROP (0x16) packet
2b. re-pickup all the flags the killer originally had using S2C_FLAGPICKUP (0x13).
2c. Have the killer pickup any flags that fit using S2C_FLAGPICKUP (0x13). (Beginning with the lowest flag id)
2d. Store the remaining flags as dropped

Above is excluding any special rules a flag game may implement like team killing or having a CTF game.

Due to step 2a, the flags of the killer AND the killed were temporarily dropped. This is how it keeps track of the proper flag id's.
Back to top
View users profile Send private message Add User to Ignore List
grazzhoppa
Novice


Joined: Jan 03 2007
Posts: 29
Offline

PostPosted: Thu Aug 20, 2009 3:24 am    Post subject: Reply to topic Reply with quote

If the client was connecting to an ASSS zone, now that I know that ASSS does this, it makes it relatively straight forward for the client to keep the flag-id and player associations.

But what about subgame zones?

The continuum client doesn't keep flag-id to player associations (as far as I can tell) most likely because the protocol doesn't make it easy, and subgame doesn't hack it like ASSS does.

I guess I want to know ways you can think of for clients on a subgame server to keep flag-id to player associations.
Back to top
View users profile Send private message Add User to Ignore List
JoWie
Server Help Squatter


Gender:Gender:Male
Joined: Feb 25 2004
Posts: 215
Offline

PostPosted: Thu Aug 20, 2009 6:06 am    Post subject: Reply to topic Reply with quote

I doubt continuum would decide which flags to transfer randomly, are you sure it isn't something like lowest flag id first?

If continuum does not associate flag id's with players, subgame would HAVE to send something like S2CFlagLocation or S2CFlagPickup each time such a kill occurs. How else does continuum know what flag id to send in C2SFlagPickup?
Back to top
View users profile Send private message Add User to Ignore List
grazzhoppa
Novice


Joined: Jan 03 2007
Posts: 29
Offline

PostPosted: Thu Aug 20, 2009 11:27 am    Post subject: Reply to topic Reply with quote

JoWie wrote:
If continuum does not associate flag id's with players, subgame would HAVE to send something like S2CFlagLocation or S2CFlagPickup each time such a kill occurs. How else does continuum know what flag id to send in C2SFlagPickup?

C2S FlagPickup only happens when picking up a flag dropped on the map, right? I only notice S2C FlagPickup messages when a player grabs a flag sitting on the map.

I think the client is not keeping track of the ids of carried flags. When it receives a kill-death packet and it realizes that it is the killer, the client will just increase the amount of flags it is carrying by the "flags transfered" field of the packet.
That's all it needs to know to calculate the output of ?flags and how many flags each freq has.

I don't believe it needs to keep track of flag ids of carried flags.
The client knows what flags ids are sitting, uncarried, on the map because of S2C FlagLocations. It'll send a C2S FlagPickup only when it realizes it moved over a tile containing a dropped flag.

The S2C FlagsDropped for a player IS followed fairly soon by multiple S2C FlagLocation messages, where it will regain the knowledge of flag ids.


On another note, what the hell does the continuum client do with the flag ids? Are they useful for a Turf arena? I'm not familiar with turf settings.
I can't think what Continuum uses them for in a warzone or capture-the-flag game.

All flags are worth the same points; none give special abilities to players or teams - there's not much gained by giving flags unique IDs. Maybe they are only used to do cheating/game integrity checks on the server side? Maybe to prevent players from claiming ownership of the same flag, which would be completely server side checks.

Quote:
I doubt continuum would decide which flags to transfer randomly, are you sure it isn't something like lowest flag id first?
Maybe that is done only on the server.
Back to top
View users profile Send private message Add User to Ignore List
Samapico
No, these DO NOT look like penises, ok?


Joined: May 08 2003
Posts: 1252
Offline

PostPosted: Thu Aug 20, 2009 11:36 am    Post subject: Reply to topic Reply with quote

Ok, so player A kills player B, A->flags increase.

What happens when player A drops his flags? what ID will the flags have?


As for why there are ID's....

Player A picks up a flag.

I'm player B... some flag has to be removed from my map, which one... I wonder.
_________________
(Insert a bunch of dead links here)
Back to top
View users profile Send private message Add User to Ignore List
JoWie
Server Help Squatter


Gender:Gender:Male
Joined: Feb 25 2004
Posts: 215
Offline

PostPosted: Thu Aug 20, 2009 2:48 pm    Post subject: Reply to topic Reply with quote

It seems like continuum only tracks flag id's for flags on the map not for flags that are carried. This is why ASSS goes to all kind of hoops to maintain consistency in the flag id's.

if you look in flagcore.c, when a player enters the arena, he is only sent flag update's for flags on the map (S2C_FLAGLOC), not for the carried flags. He is notified by the carried flags using S2C_PLAYERENTERING which contains just a flagcount.


So your solution would be to store per flag id a boolean value "onmap", and NOT if it is NONE, ONMAP or CARRIED. Since in reality, flags have no CARRIED state. just NONE or ONMAP.

So when a flag is picked up set it to NONE instead of CARRIED.
When someone is killed, update the flagcarried count (up to the carryflags setting) and do not care about the extra
Back to top
View users profile Send private message Add User to Ignore List
grazzhoppa
Novice


Joined: Jan 03 2007
Posts: 29
Offline

PostPosted: Fri Aug 21, 2009 6:53 am    Post subject: Reply to topic Reply with quote

Well, I believe I finally have a system to do this. There will be 5 states that flags can be in.

Code: Show/Hide
struct FLAG_ {
   FLAG_ID      id;         /* server's ID for this flag */
   POINT_TILE   location;   /* tile location of the flag */

   FREQ      freq_owner;   /* team which this flag is owned/captured by. FREQ_NONE if neutral/unowned */
   PLAYER_ID   carrier;   /* if being carried, the pid of the carrier. PID_NONE if not carried */

   bool valid; /* accounting for continuum protocol's gayness of not giving flag ids in 0x06 (kill/death packet) so flags ids transferred during kills/deaths are unknown  */
};


The five states of flag associations based on the values of a FLAG

  1. .carrier == PID_NONE && .valid == false
    means the FLAG.id has been carried since bot entered arena. No way of knowing which PLAYER is carrying this FLAG.id until it gets dropped and picked up again due to gayness of continuum protocol. FLAG.location is meaningless.
  2. .carrier != PID_NONE && .valid == false
    means the FLAG.id could be part of a FLAG_GROUP. If it is, it is uncertainly carried by that FLAG_GROUP.possible_carrier. FLAG.location is meaningless.
    Code: Show/Hide
    struct FLAG_GROUP_ {
       vector<map<FLAG_ID, FLAG>::iterator> flags;   /* all possible flags carried by
                                                      * .possible_carrier due to a kill/death
                                                      * partial flag transfer (AKA overflow)
                                                      */
       PLAYER_ID   possible_carrier;
       uint16_t   flags_transfered; /* amount of flags of this group that are carried by possible_carrier */
    };

  3. If a flag from #2 is actually not in a FLAG_GROUP,
    it means it was orphaned by FLAG.carrier (ship/freq/arena change), FLAG.location is meaningless, but soon a FlagLocation packet will be received for this flag.
  4. .valid == true && .carrier == PID_NONE
    means the FLAG.id is surely dropped at FLAG.location
  5. .valid == true && .carrier != PID_NONE
    means the FLAG.carrier is surely carrying this FLAG.id. FLAG.location is meaningless. the FLAG.carrier's location is the location of the flag since it's being carried by that player.

Using this system:
when the client/bot enters the arena, flags that are being carried will never have an association to a player until they are placed on the map. The association can only happen when the player changes ship/freq/arena, or they drop flags via expired flag timer.
All other flags that are dropped will be able to be tracked from the time the client/bot enters the arena.

When the "overflow" situation happens: It will break flag associations temporarily. Eventually when enough flags are dropped, we can regain associations.
    Create a FLAG_GROUP, add all the flags carried by the killed. Note the "flags transfered" value in the kill packet.
    Assign ownership (group.possible_carrier) to the killer.
      if killer dies, transfer ownership of the group to the new killer
      if killer dies to a player with ownership of another group, combine the groups and assign this new larger group to the newest killer

    Remove a flag from this group when a FlagLocation packet comes in for it.
      after removing the flag, if the amount of .flags in the group == .flags_transfered, associate all remaining flags to owner of the group and discard the group



This system will allow regaining associations faster, BUT ONLY in SOME cases, than simply disassociating all non-map flags.


Bottom lines are:
(1 For arenas without overflow situations) if a flag never touches the map since the client/bot entered the arena, there is no way to know which player is carrying that flag until there is only 1 flag carrier in the arena.
(2) in overflow situations, if kill events continually generate overflow events all flags will eventually end up in FLAG_GROUPs meaning they are loosely associated with a Player, but in order to certainly know the associations, we have to wait for FlagLocation packets.
Back to top
View users profile Send private message Add User to Ignore List
JoWie
Server Help Squatter


Gender:Gender:Male
Joined: Feb 25 2004
Posts: 215
Offline

PostPosted: Fri Aug 21, 2009 7:35 am    Post subject: Reply to topic Reply with quote

ok, imagine this situation that is possible in the continuum protocol (however ASSS prevents this from happening, don't know about subgame):

Flag game with 4 flags (flag id 0,1, 2, 3). Two players A and B


  1. All the flags are on the map somewhere. S2CFlagLocation
  2. A picks up flag 0 and 1. S2CFlagPickup
  3. B picks up flag 2 and 3. S2CFlagPickup
  4. B drops his flags. S2CFlagDrop
  5. The server decides 2 flags should reappear on the map because of B's flagdrop
  6. The server places flag 0 and 1 on the map. (ASSS would always place 2 and 3 here) S2CFlagLocation


This means the flags player A originally picked up are reused by subgame for the dropping of B's flags.
If the above is NOT the case, then subgame HAS to track the flag id's carried and must do something similar to ASSS' flagcore.

Again, I have no idea if subgame does this, I am just stating this is possible.
Back to top
View users profile Send private message Add User to Ignore List
Display posts from previous:   
Post new topic   Reply to topic    Server Help Forum Index -> Bot Questions All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
View online users | View Statistics | View Ignored List


Software by php BB © php BB Group
Server Load: 429 page(s) served in previous 5 minutes.

phpBB Created this page in 0.667730 seconds : 35 queries executed (80.1%): GZIP compression disabled