The point of this system is so that you DON'T have to network anything. You don't create an entity, and you don't network any information. If you start doing that, you might as well just make entities, and do it the same as usual, as you then lose the whole point.
In theory, you could just make one entity for using the render handle, it just becomes messy to maintain, but I had thought of doing the same thing. -Tony On Mon, May 21, 2012 at 9:44 AM, Psy_Commando <psycomma...@gmail.com> wrote: > Thanks for the answer. > > But after looking at that solution, I have a few more questions: > Any ideas on how to network an array of structs with their own sendtables > ? I want to network the bullet info struct for each bullets from the server > to the client. > > And, instead of creating many client entities, can I just have one, with > multiple models ? I saw I could call the model renderer with model data. > > Also, what do you mean Adam by "assigning the sprites your particle > manager"? > > > On Sun, May 20, 2012 at 1:26 AM, Tony "omega" Sergi > <omegal...@gmail.com>wrote: > >> I did something similar to this in Project Valkyrie for all projectiles >> that don't need special functionality like seeking. >> Essentailly I have a manager that runs on both the client and the server, >> which handles the projectiles moving and doing traces for damage etc, and >> the client handles the visual representation. >> You still have to create a client-side entity for each projectile if you >> want to display a model though. >> >> Additionally, I have a system in the gamerules that networks a projectile >> index to keep them in sync; Every projectile when it's created is then >> assigned the same ID ( ie: when a client projectile is created in >> prediction, it gets the new ID from the networked gamerules list) which the >> server also pulls from. Eventually this number gets cycled back down. >> Then when the client receives an event from the server saying the >> projectile has impacted, it has an ID so that it knows which one to >> terminate. >> >> This system works really well, and if you're not using a lot of model >> based projectiles, or insane particle effects, it's capable to have >> thousands of projectiles active without any major perf hit. >> Unfortunately, in Valkyrie, some of the effects are a little heavy, and >> due to the development time taken, they were never really optimized, so >> Valkyrie still hits a rendering bottleneck with them. >> >> I had done another test for simulating just "bullets" (only the impact >> rendering, and occasionally a tracer if desired) for a properly simulated >> ballistic system, it worked quite well, but I never rolled it out into any >> production environment, as nothing I have ever worked on has really needed >> it. It still has some issues with losing synchronization over drastic angle >> changes, but it performs extremely well. >> -Tony >> >> >> On Sun, May 20, 2012 at 1:35 PM, Psy_Commando <psycomma...@gmail.com>wrote: >> >>> Hello, I was wondering if it was possible to use the technique the >>> left4dead devs used for the infected, to handle non hitscan bullets ? >>> The technique I'm talking about was referenced in an article on the vdc : >>> "If you're creating lots of individual objects all the time, consider >>> rolling them all into a single manager entity. This is how Left 4 Dead >>> handles huge numbers of infected: they are all "finger puppets" of the >>> director."(https://developer.valvesoftware.com/wiki/Entity_limit ) >>> >>> Essentially I'd want to create simple "entities" for each bullets and >>> have them handled by a manager entity. But I was also wondering how to get >>> the simple entities to transmit to the client, along with their data ? >>> >>> The main reason I want to do this is because I have a lot of sprite >>> based projectiles to handle. >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >>> >>> >>> >> >> >> -- >> -Tony >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders >> >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > > > -- -Tony
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
