-- [ Picked text/plain from multipart/alternative ] I wish I knew why my E-mails have been turning into ugly plain text and removing my formatting... so ugly. Fair enough, I should probably have stated a bit more about this is general, but thank you for pointing this out as I've obviously left out important reference info.This project is, in fact, it's own mod (and that's an understatement). That being said, a server plugin making changes to entities can network entity data and change the client, if required. This is why it was an option for the port IO.Interfaces still make a good side option for communicating directly with the client, or perhaps better phrased as the client requesting data from the interface.Anywho, now I'm just reiterating myself. Thank you luckyduke for the response and feedback. Does anybody else have suggestions as to what would be the best method of implementation?> From: [EMAIL PROTECTED]> To: [email protected]> Subject: Re: [hlcoders] Server Plugin vs. Interface> Date: Thu, 16 Aug 2007 10:04:08 -0600> > --> [ Picked text/plain from multipart/alternative ]> Server plugins run on the server only. You can't create "client-side"> plugins.> > You will have to write your own mod to do anything on the client.> > > > On 8/16/07, Meow Mew <[EMAIL PROTECTED]> wrote:> >> > --> > [ Picked text/plain from multipart/alternative ]> >> > Hey, I was hoping I could get some advice from some of you fellow> > coders. Actually writing up the code isn't a problem, but I was having> > difficulty with design and following the structure already in the Valve> > engine.Here's the laydown of what I'm doing:So basically, I'm writing an> > interface for optional port IO for independent hardware to control signal> > pulses. Scent machines, fMRI scanners, head tracking, basically any random> > piece of hardware should be able to plug into a port and send data> > bits. All in all, it's just port IO that I want to be able to hook into the> > logical entity connections. Something like "OnTriggerPulse" or something,> > no big deal. Also, it'll need an input along the lines of> > "SendTriggerPulse". I'm sure the entity can store it's own port number and> > data bits.There's also another module that needs implemented that might be> > hardware specific. Eye tracking has it's own SDK dlls that are vendor> > specific, the client needs to get a HUD update (maybe from server) and the> > server needs to parse the last known position to track entity locations when> > projecting 2D eye positions to 3D (which requires the client view matrix).So> > the design questions are:Should either of these be implemented with the> > plugin interface? The eye tracker is vendor specific, so additional vendors> > may need to create their own plugins for compatibility. This is much more> > extensible, but plugins seem to have inappropriate communication with the> > server and client for passing large datasets.Should either of these use> > the IBaseInterface interface to allow the server or client to access the> > data being polled by these abstract pieces of hardware? This could easily> > resolve an issue of collecting data on the server and client, but adds a> > dependability and a limit to the extensibility that involves the interface> > ID. There can only be one INTERFACEVERSION_VENGINESERVER afterall, and thus> > there could only be one INTERFACEVERSION_VEYETRACKER active at one> > time. This would be much more limiting to the port IO in the event that> > multiple external hardware's would wish to send data bit pulses to control> > logic.Is there a proper combination of the two for either of these> > modules?Would adding more data to CUserCmd be advisable? I know that this> > class actually has a limit to it's size on the engine (which isn't apparent> > on the client or server) that is related to saving replays, and the dynamic> > sized vectors required for the eye tracker to store all possible fixations> > could cause problems. Also, the advantage to a plugin or interface is they> > are possible to remove or have invalid, but CUserCmd must have predictable> > size, meaning the data can be empty, but not removable.Anyway, any> > suggestions are appreciated. I could use some feedback just to wrap my head> > around the methodology I'd want to implement, and to get a better feel for> > the intent of the Valve design.> > _________________________________________________________________> > Recharge--play some free games. Win cool prizes too!> > http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink> > --> >> > _______________________________________________> > 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> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink --
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
