-- [ 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
