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