Ragezone Open Development Server.

[bobsobol]

Those that add new functionality must also add new code =P

Ofc. I just keep thinking that you shouldn't have to change the source and recompile the DLL to fit it to a different client.

I understand why you have done it this way, and a couple of attempts at avoiding that have illustrated to me how hard it is to avoid. But it's still a downfall. The most successful method was adding "exports" to the client executable which the DLL picked up on and used... but there aren't any convenient tools to do that, and it's a major hex job which is actually *way* more work than changing the source and recompiling. XD

Another, and easier, idea I have for 2 way communication is something similar to the old TSR API tables in OS like DOS / CP/M / TOS / Amiga OS etc. The way they work is that each API has an index in a jump table. When it is called it is called by the address at it's index in the jump table. (not dis-similar to PE Exports, except that the addresses are a linear array, not a pointer to a pointer) An "override" API (code to be run before, after, or instead) will modify the jump table to point to it's code. If it is "instead", job done. If it should happen *before* the usual code, then it records the old pointer internally, does it's stuff and then jumps to the old pointer. If it should run after, then it does the same, but rather calls the old pointer before doing it's new stuff.

This method enables multiple overrides, since each override routine will record the address of the last one to patch that routine and call it as if it where the original. ^_^

Nice for code.

The problem with your DLLs is more the Data offsets in the executable. If they are recorded in a table (perhaps in a new section you add to the client executable) then they should not be altered, the way code pointers would.

All of this involves modifying the client and... as I said, your base server should not require you to do that. (ideally) Some of it may be possible with an "in memory" patcher. But making that intelligent enough to fit any client will be quite difficult. Just passing out an added section of pointers to add to the executable would be quite doable, and something some people could get into doing on a regular basis. It's a challenge, but repetition makes it easier.

 

[gzuz]

Initially i plan to have the server completely rewritten but the client will obviously have to rely on a build up of dll's until we manage to get more object orientated programmers who know the ins and outs of fully implementing a 3d mesh interface. But then i guess when it comes to that you might as well really just write your own complete game and just model it around a more efficient and up to date version of PT. I have no issues about changing the name, as i said what i put there was only so i could get a working frame up and not look empty.

 

[bobsobol]

Actually, implementing the 3D meshes in the server are the primary downfall of every server emulator we have, and several I know of in private development. (never released)

You can throw a 3D engine (pre-made FOSS one) into any game client and it will JFW. (Just flippin' work) But getting 3D implemented in the server so AIs work and your don't float through things and stuff is much more difficult because most engines don't support "bounding boxes" in multiple 3D spaces which are never rendered. :

 

[snoopgal]

+1 zuz ! send me your msn please bro i need to talk to you...