[bf1942] Using sqlite with BF2 in Windows

["Einar S. Idsø"]

Hi Andreas,

Thank you for your quick and informative reply!

Andreas Fredriksson wrote:
> pyexpat uses expat in a shared object form, and I think it wasn't
> included at all in the DICE  Python build. Also, because of the so/dll
> loading limitations it's not possible to add it dynamically (which
> you've already found out.)

Right, I see. Guess that rules out using a full-blown xml-parser then.

> I can't speak for DICE (any longer) but I wouldn't bet on it. It takes
> significant effort to rebuild the Python layer and I'm sure a security
> audit would have to happen as well.

Yeah, I guess you are right. They definitely won't be able to do this
for the 1.3 patch, and the system should be up and running soon, so I
guess I'll just have to circumvent the problem.

> I think the pickle module is included, and sockets definitely work, so
> maybe the best option is to build a side-by-side server in "real"
> Python which has unrestricted access to Python modules in general.
> That way you could use a simple form of RPC across a pickle layer
> which works with all Python types.

This is actually pretty much what I am doing: I am making a
servermanager that will be running side-by-side with the server(s), but
the intended communication protocol was planned to be XML over UDP. The
servermanager will then be handling all the MySQL calls and other stuff
that requires external Python libs. The reason I chose XML over pickle,
which you correctly state is included, is that I wanted to take a more
generic approach so that the servermanager can easily be expanded to
other games that have communication abilities but don't use the Python
language. Perhaps I should reconsider this and instead just Pickle a
dict or similar structure.

> With this approach, the bugs in the BF2 build only has to be dealt
> with once, and  servers can use what ever game modes the like. Just
> take care to make the RCP layer asynchronous, or the game loop could
> suffer badly from blocking.

My plan was to have a UDP listen socket bound to a specific port on the
game server. The servermanager will also have a UDP socket bound to a
specific port. The server and the manager will both act as clients and
servers to each other: Whenever the server needs to communicate with the
servermanager, it will fire off a UDP packet and not wait for a
response. The servermanager then handles the request and sends the
response back to the server on its bound UDP port. Is this what you
mean, or can it be made more elegant, yet still asynchronous? Would TCP
be a better option for this? Any suggestions you as the implementor of
the Python-engine may have, will be very highly appreciated.

> This applies to locally connected sockets as well (127.0.0.1) because
> a read/write cycle implies at least two context switches which would
> absolutely drain the server FPS (the default time slice is 10ms IIRC).

This is true for the 2.4 kernel, but for the 2.6 kernel it is 1ms, so a
couple of context switches shouldn't cause much trouble, I hope. For
Windows the default slice is 15.625ms, but this can easily be tweaked to
0.977ms.

Thanks a lot for your help, it is really appreciated! :)

Cheers,
Einar