Please Slain my idea into prespective

[Ringo]

This is REALLY hard to explain, so i will try and be as clear as i can.
Im looking for ideas on why it will/wont work etc.

Anyway, i had the idea of running a single TCP connection to battle.net on a Broodwar client, but having a total of 8 UDP sockets, all bound to different ports.
The first socket would be the "master" socket, witch hosted the game and waited for me and 7 other people to join (making 9 i know).
But when i join on the "bot master's" account, the hostbot sections me into a differnt "room" to any other players who may join.
The host wouldnt notify any other players who joined that i was there, but would notify me they joined via one of its other sockets, and tell "me" that the player is useing that address.
So when a random player joins, the host would tell all the other random players that they have joined (in the main game room) and tell me (in the sectioned game room) that the player is useing the ip and port of one of its other sockets.
Then anything the reall players did in the reall "room", would be fawarded to me via one of the bots other sockets, and everything i did in the "fake room", would be fawarded to all the reall players as a action from the hostbot.

So in effect, once ingame, "me" will be playing souly with bots witch fawarded the reall players packets to "me", and ONE of the sockets fawarding "me" the other players data, would then make the host faward the data sent by "me" to all the reall players as if it was its own.

THis would mean, with in reassion, that the bots could give me the other players vision, filter out any "out of range" clicks that would look like a map hack, tell you whats going on so u dont have to keep checking manualy, do unit and base production why you are busy microing, what ever, the possibilitys are almost endless.

Diogram:

Code Select Expand


Host______________________tmp2____Me
|||||||       \ \ \ \ \ \      /
|||||||        \ \ \ \ \ tmp3__\
|||||||         \ \ \ \ tmp4___/
|||||||          \ \ \ tmp5____\
|||||||           \ \ tmp6_____/
|||||||            \ tmp7______\
|||||||___2         tmp8_______/
||||||__\_3
|||||___/_4
||||____\_5
|||_____/_6
||______\_7
|_______/_8



Ideas?

[Arta]

THis would mean, with in reassion, that the bots could give me the other players vision, filter out any "out of range" clicks that would look like a map hack, tell you whats going on so u dont have to keep checking manualy, do unit and base production why you are busy microing, what ever, the possibilitys are almost endless.

You can do that without going to all that trouble. Just hook the game's message processing routines. Or am I missing something?

[Ringo]

You can do that without going to all that trouble. Just hook the game's message processing routines. Or am I missing something?

I can get a handle to the window, but anything else and i wouldnt have a clue where to start
Would that require reverseing the binary files?

[Arta]

Yes, but in order to do anything meaningful you'd have to do that anyway - otherwise you wouldn't know what the UDP messages do.

[MyndFyre]

So this is like a proxy for Battle.net games?

[QwertyMonster]

Would this actually work? I mainly understand what he is saying, for people who dont:

He wants to play vs bots in other words? Please correct me if im wrong.

And in order to play vs the bots, he is going to make the "real players" packets, which are then sent to him, then sent to the bots making them "be real"? I THINK thats the basic idea of it, like i said.. please correct me if im wrong!

[Ringo]

Yes, but in order to do anything meaningful you'd have to do that anyway - otherwise you wouldn't know what the UDP messages do.

The packets wont be a problem, as i know what 90% of them do already, im more worryed about other problems witch would result in it not working

So this is like a proxy for Battle.net games?

Sort of.
The host socket would be acting like a proxy, in the sence that it will be fawarding all the game data to me via the correct sockets.
So each game beat, my SC would send its data payload to all the tmp sockets, witch the host socket would then hold and send to each reall player when the main game beat goes off.
And when the reall players transmit there data payloads to the host socket, the tmp sockets hold each players payload and transmit it to my sc when the next game beat goes off.
So the players i see in my game are controlled by the reall players witch cant see me, but i can see them through the bots sockets, giving the bot VIP access
(thats if it worked)

And in order to play vs the bots, he is going to make the "real players" packets, which are then sent to him, then sent to the bots making them "be real"? I THINK thats the basic idea of it, like i said.. please correct me if im wrong!

err, somthing like that

[Kp]

In theory, it should work.  But like Arta, I think you're going to a lot more trouble and bandwidth than this requires.  Also, you won't be able to have the other players share vision with you or anything like that.  As soon as you do, your game goes out of sync with theirs and you drop.  Of course, your proxy will need to do quite a bit of NAT too.

[Mesiah / haiseM]

hrm.. didn't think about the NAT thing.. ouch..

[Ringo]

In theory, it should work.  But like Arta, I think you're going to a lot more trouble and bandwidth than this requires.  Also, you won't be able to have the other players share vision with you or anything like that.  As soon as you do, your game goes out of sync with theirs and you drop.  Of course, your proxy will need to do quite a bit of NAT too.

Hm, the host socket would handle any sync problems with the reall players, and the tmp sockets would handle there own sync issues with SC, so all that gets crossed over is data payloads.
That way when it comes to adding/removing packets in the cross over, its just a case of adding or removing the extra data in the payload, before it gets sent by the host or tmp sockets.
Other than useing 3x more bandwith than normal, could that effectively work?

I did a quick test with my bot, making it give my SC vision, but it kinda went messed up, and SC thought my bot had unallied its self (replay here)


And i dont think NAT will be a issue, because all clients other than the real players (witch are on other address) will be ran from one PC, so each would be bound to there own port, so there shouldnt ever be a mix up over what socket recvs from who, and if there was, it could easyly be handled by the bot via the senders port.
But then again, i dont know alot at all about NAT, other than you mean traffic across the network/network-ips etc?

[Kp]

Starcraft passes the in_addr of other players to you when you join.  The bot will need to NAT that so that new players don't talk directly to you.

[Ringo]

Im still not 100% sure what you mean by NAT it.
At the moment im useing this kind of thing and havent had any send/recv direction problems as yet*

Code Select Expand


Public Type sockaddr_in
    sin_family       As Integer
    sin_port         As Integer
    sin_addr         As Long
    sin_zero(1 To 8) As Byte
End Type

Public Type SCPLAYERS
    Addr         As sockaddr_in
    Address      As String
    Port         As Long
    Index        As Integer 'Player ID
    SentOS(2)    As Long
    Sent(2)      As Long
    Recv(2)      As Long
    Account      As String
    StatString   As String
    RoomSlot     As UDPROOMSLOTS
    Race         As SCRACES
    Data(2, 100) As String
    ect ect...
End Type

Public Sub UDP_S_0_0x06(S As SCPLAYERS, ByVal ToPID As Integer)
    If S.Account = SC(ToPID).Account Then Exit Sub
    If Db.Cmd0 = True Then
        ShowChat vbWhite, "Sent Cmd 0 0x06 About Player " & _
                          S.Account & " to " & _
                          SC(ToPID).Account & "    " & _
                          SC(ToPID).Sent(0) + 1 & "/" & _
                          SC(ToPID).Recv(0)
    End If
    Dim IsHost As Byte
    If S.Addr.sin_addr = &H0 Then
        IsHost = &H1
    Else
        IsHost = &H0
    End If
    Dim B As New clsBuffer
    With B
        .InsertDWORD &H32 'urg
        .InsertDWORD S.Index
        .InsertDWORD IsHost
        .InsertDWORD &H0
        .InsertDWORD GameBeats + 2
        .InsertWORD S.Addr.sin_family
        .InsertWORD S.Addr.sin_port
        .InsertDWORD S.Addr.sin_addr
        .InsertBYTE S.Addr.sin_zero '()
        .InsertSTRING S.Account, Chr(0)
        .InsertSTRING S.StatString, Chr(0)
        .InsertHEADER &H6, UDPG_HEADER, SC(ToPID).Sent(0), SC(ToPID).Recv(0), 0, 0, True
        .StoreData 0, SC(ToPID).Index, SC(ToPID).Sent(0), SC(ToPID).SentOS(0)
        .SendPacket sckUDP, SC(ToPID).Address, SC(ToPID).Port
    End With
End Sub

Im guessing it has somthing to do with sin_family? because at the moment, im setting the bot's sin_family to 0 (AF_UNSPEC) and joining players sin_family to 2 (AF_INET).
I was going to set the sockaddr.sin_port to the tmp sockets localport when it came to sending the data to SC, where as all other players would get sent the reall sockaddr for the player.
Also im filling the Addr type on join hail, for future checks on the address and port, to make sure each players ID matchs that of there join IP and port.
Altho i havent really tested this a great deal, would this generaly be ok/work for this kinda thing, or am i missing somthing?

Thanks

[edit]: fixed typos

[Kp]

[edit]: fixed typos

You missed quite a few.

[Ringo]

[edit]: fixed typos

You missed quite a few.

Forgetting the typo's for a second , im not on a network, does that count for anything?
My address for each would for example be like so:
84.9.75.30:6112 - Starcraft
84.9.75.30:6113 - Host
84.9.75.30:6114 - tmp2
84.9.75.30:6115 - tmp3
84.9.75.30:6116 - tmp4
84.9.75.30:6117 - tmp5
84.9.75.30:6118 - tmp6
84.9.75.30:6119 - tmp7
84.9.75.30:6120 - tmp8

[FrOzeN]

Shouldn't it only be ports 6112-6119? Not 6120?