Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[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: [Select]

@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")+lengthNotice 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) [Select]

       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) [Select]

           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: [Select]

i=0
while i < len(events):
    if event_is_state:
        event = events.pop(i)
        events.append(event)
        i -= 1
    i += 1which 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.

[.]

When are you guys going to release this as the official GG2 mod? As 2.5, 2.6, 2.7?

[Dusty]

when it's done.

[Orpheon]

Ok, I'm retracting my promise of a working shared world this week. I'm not going to make it.

After lots and lots of debugging (this is only the result, not the many in-between steps), I just noticed that the ack sytem still has a huge hole, and that the client code isn't really ready for this at all.

I did manage to get the client say it's there, and the server answer "Welcome, and this is how the game looks like". That's as far as I got.

There's still loads of work to be done, and I'm starting to fear for the overall stability of the whole thing. There are some things that just smell hacky, even to me, and although I can't think of any alternative it's still not a good thing.


Also, you guys could/should really read and try to understand the network code. I'm basically making it alone here, and I make mistakes, so I'd be happy if someone else is looking at what I'm doing so that my mistakes don't get noticed a week later.
Note: With network code, I mean everything in "networking/*", "server/networker.py", "server/event_handler.py", "server/player.py" "client/networker.py", "client/event_handler.py", and the de/serialize methods in the engine.

[NAGN]

how do I open the files in a file explorer in komodo edit

[Orpheon]

how do I open the files in a file explorer in komodo edit

1. Open komodo edit.
2. On the left column, go search your folder, right-click on it and press "Make this folder root".
3. Open files by double-clicking on them there.

[Orpheon]

This is a client connected to a server. 

Most of the networking core is now done and working. There are still some small bugs, and lots of stuff aren't coded (like teams or map modes), but the underlying packet and event management is done.

For the interested, stuff is still at the Networking branch, haven't pulled it in yet.


PS: Multi-clienting won't work, because of a architecture decision. Don't be surprised if it doesn't work for you, it shouldn't.

[AcidLead]

Probably unecessary but eh.

[Phantom Brave]

multiclienting not working is a pretty big deal. What was worth sacrificing it for?

[Orpheon]

multiclienting not working is a pretty big deal. What was worth sacrificing it for?

It's probably possible to make it work. And it was for making a distinction between a joining player joining and a packet sent by a former joining player that took a long travel.
Actually, by using ports as identification as well as ip, it should be possible.

Also, I put a print statement in the current server engine (with a client inside and shooting), to print the fps.
50'000 fps.
50'000 FPS!!!!