Thanks for the quick responses.
I'm still not clear on the distinctions between server.dll and
client.dll.
client.dll
- provides extension points for graphics?
- handles user input?
- <fill in as you see fit>
server.dll
- controls game flow?
- weapons characteristics?
- <fill in as you see fit>
So I further understand their relationships...
----------------- -----------------
| Player 1 | | Player 2 |
| - client.dll | | - client.dll |
| - server.dll | | - server.dll |
----------------- -----------------
\ /
--------------------
| Dedicated Server |
| - server.dll |
--------------------
/ \
----------------- -----------------
| Player 3 | | Player 4 |
| - client.dll | | - client.dll |
| - server.dll | | - server.dll |
----------------- -----------------
In that client.dll and server.dll are always loaded *except* for
dedicated servers?
Again, please forgive my ignorance,
Michael
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly
> Sent: Tuesday, September 06, 2005 2:11 PM
> To: [email protected]
> Subject: RE: [hlcoders] architecture questions
>
> The main entry points to each DLL are interfaces that the DLL
> exports to the engine.
>
> For the server, these are:
> IServerGameEnts
> IServerGameClients
> IServerGameDLL
>
> These are defined in public/eiface.h. For objects, you'll
> also need to implement IServerNetworkProperty and
> ICollideable (or use the included implementations of those).
> There are also general hooks for client & server through IGameSystem.
>
> The client has to implement the following interfaces:
> IBaseClientDLL
> IClientLeafSystemEngine
> IClientEntityList
> ICenterPrint
> IPrediction
>
> and can also implement game systems. In general the server
> interface is simpler to override/implement. Some of the
> client DLL architecture has made tradeoffs where simplicity
> was sacrificed to make features configurable by mods (like
> control over the studiomodel renderer, parsing game data from
> BSP files, and the client leaf system & shadows).
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Tuesday, September 06, 2005 7:50 AM
> > To: [email protected]
> > Subject: RE: [hlcoders] architecture questions
> >
> > 1. Yes
> > 2. The DLLs themselves are compiled from your client/hl VS
> projects.
> > So it's not really a question of "entry points"
> > per se; those DLL's _are_ your code.
> > 3. The client is the client-side code, and the server is the
> > server-side code. For example, a dedicated server only
> requires the
> > server DLL (or SO, if it's a *nix box.)
> >
> > Original Message:
> > -----------------
> > From: Newcomb, Michael-P57487 [EMAIL PROTECTED]
> > Date: Tue, 06 Sep 2005 09:54:19 -0400
> > To: [email protected]
> > Subject: [hlcoders] architecture questions
> >
> >
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ] Hello Half-Life
> > community,
> >
> > I'm currently working on my first mod and have some basic
> architecture
> > questions.
> >
> > 1. Does all my mod code reside in client/server.dll? Looks that way
> > because of VS solution, but just making sure.
> > 2. What are the entry points into these DLLs? Callbacks?
> > Thread bodies?
> > Both? I see DLLInit for server.dll and Init for client.dll and I am
> > assuming those are called first, but after that?
> > 3. What is the relationship between client.dll and server.dll?
> > Difference between them? Purpose of each?
> >
> > Please forgive my ignorance,
> > Michael
> >
> > --
> >
> > _______________________________________________
> > To unsubscribe, edit your list preferences, or view the
> list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> > --------------------------------------------------------------------
> > mail2web - Check your email from the web at http://mail2web.com/ .
> >
> >
> >
> > _______________________________________________
> > To unsubscribe, edit your list preferences, or view the
> list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
