Official PyGG2 Development thread

[Nukleus]

We can't offer a progress bar, but we can show what we've done.
- Scout, Soldier, Heavy, Engie, Spy, and as of today, Pyro
- Shooting, animations, rocketjumping
- 2dfortremix
- Orpheon and NC are working on networking
- I'm working on the small stuff.

[A Shogun Named Marcus]

I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/

[Orpheon]

I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/

The mac/windows/linux version is the same: https://github.com/nightcracker/PyGG2

No binary since there isn't really much to test yet.

[nightcracker]

I heard there is a mac version. Can I have the latest one? It's hard to navigate all these pages looking for one thing :/

Getting everything to compile on Mac has been a bitch so far, but it shouldn't be impossible. But for now you're going to have to hang on.

[Nukleus]

HOW TO RUN PyGG2 ON WINDOWS

1) INSTALLING PYTHON 2.7

Download Python 2.7

Install it to "C:\Python27".
Go to "controlpanel>System>Advanced>Environment Variables".

In the "System Variables" box, click on "Path", then click "Edit".
In the "Variable Value" box, add to the end: ";C:\Python27;C:\MinGW\bin".
Click OK, then OK again in the system menu.

2) INSTALLING PIL, PYGRAFIX AND MINGW

Download and install PIL

Download Pygrafix
Unzip, and move to "C:\Python27\Lib\site-packages"

Download and install MinGW

3) INSTALLING PYGG2 AND BITMAP EXTENSION

Download and unzip: PyGG2

Move the folder to My Documents and rename it to "PyGG2".

Go to command prompt (start>accessories>command prompt) and type "cd " (with a space after cd).
drag the PyGG2 folder into the command prompt window and press enter.

Type in "python make.py build" and press enter.

After it is finished, exit command prompt.

4) MAKING PyGG2.bat

Go to notepad (start>accessories>notepad).

Type the following, but change <USER> to your computer's username.

cd "C:\Documents and Settings\<USER>\My Documents\PyGG2"
python make.py testclient


Click file>save, and in the "File Name" box, type "PyGG2.bat", and set the "Save as Type" box to "All Files".
Save it wherever you like.


And you're done! Whenever you want to run PyGG2, you just have to open PyGG2.bat
If you want to update PyGG2, just repeat delete the PyGG2 folder in My documents and repeat step 3.

[Nukleus]

That SHOULD work. Not 100% sure though

[MEDIK]

n0p3

[NAGN]

can you specify what exactly is the issue?

[Nukleus]

I'm installing a completely clean install of windows 7 when I get home, so I'll be able to test if it's 100% working. But I can't find anything wrong with it at the moment, you'll have to post any errors you get

[Nukleus]

The guide worked 100% perfectly on Windows 7.

[Orpheon]

Should the client try to guess spawning and dieing, or should it not do anything about them without the server telling him to do so?

On one side, the cases where they'll disagree and it's going to be noticeable are extremely rare, and the client should be able to extrapolate as much as possible, but on the other hand, when they DO disagree it looks shitty.

In both cases, this is only something that'll appear with a pretty big latency.

Opinions?

[Lorgan]

I see no reason to do that, i can only see this doing weird things.

[MedO]

imo death should not be predicted, it could be quite confusing to die, rage and then notice you are not dead at all. Also causes programming issues, like aborting the killcam (or only starting it once death is confirmed).

[Orpheon]

Ok.

Alright, I set up the bare-bones of server networking. It works, as in doesn't error out when you run it, but it's still lacking the FULL_UPDATE and any kind of handling of joining players.
Right now, I'm working on getting the client up to date with it, and maybe (with a lot of luck) we'll have a shared world by the end of this week.

If anyone wants to poke around the code to spot glaring problems, please do. There's one problem I'm aware of, and it's in networking/event.py:

Code:

@clientevent
class Client_Event_Inputstate(object):
    eventid = constants.INPUTSTATE

    def __init__(self, bytestr):
        self.bytestr = bytestr

    def pack(self):
        packetstr += struct.pack(">H", len(self.bytestr)) # TODO: Implement a better system that doesn't require this length, because it shouldn't be needed.
        packetstr += bytestr

        return packetstr

    def unpack(self, packetstr):
        length = struct.unpack_from(">H", packetstr)
        bytestr = packetstr[:length]

        return struct.calcsize(">H")+length

Notice the TODO. I can't imagine a good system that stays clean and compatible with the rest (this shouldn't pack or unpack it, since that requires access on the game engine, which it shouldn't have, but without it it can't know the length of the event either), but this is a hacky fix.
Any ideas are welcome.


Also, a small design question: Is it ok if I make the Full update just have that information that the snapshot update doesn't, and rely on the fact that it'll never get sent without?
EDIT: Dammit, the system doesn't allow for this, because then knowing when to move SNAPSHOT_UPDATE to the back and when to leave it at the front would get complicated.
I'm just going to make the FULL_UPDATE handler call the SNAPSHOT_UPDATE one, and leave it at that.

[Orpheon]

I need help for a non-hacky way to re-arrange the packet.

We decided to compress the packet with XOR adding and then run-length compression on the last ACKed packet. Since this works better with lots of overlap, we decided to put the state data first in the packet, to get as much overlap as possible (events have a varying length, which isn't good).

My problem is that I'm searching for a clean way to do this:

Code: (networking/packet.py)

       while packetstr:
            eventid = struct.unpack_from(">B", packetstr)
            packetstr = packetstr[struct.calcsize(">B"):]

            if self.sender == "client":
                packet_event = object.__new__(event.clientevents[eventid])
            else:
                packet_event = object.__new__(event.serverevents[eventid])

            eventsize = packet_event.unpack(packetstr)
            packetstr = packetstr[eventsize:]

            self.events.append(packet_event)

Code: (server/networker.py)

           try:
                packet.unpack(data)
            except:
                # parse error, don't throw exception but print it
                print("Parse error: %s" % sys.exc_info()[1])
                continue # drop packet

            # only handle this packet if we know the player
            if sender in self.players:
                for event in packet.events:
                    event_handler.eventhandlers[type(event)](self, game, self.players[sender], event)

Somewhere between that, the events that handle of states have to get pushed to the end. Is there any easy built-in or implicit way to do this, or do I have to use a while loop like this:

Code:

i=0
while i < len(events):
    if event_is_state:
        event = events.pop(i)
        events.append(event)
        i -= 1
    i += 1

which won't even work like that because of the end, but yeah.

Also, I'm not sure I can guarantee that there won't be more than two state events in the same packet. It depends on how we manage them.