-- [ Picked text/plain from multipart/alternative ] Thanks, Marine! I skipped the four by accident. Had I skipped 3 as well I supposed I could have claimed it was a Monty Python reference of some sort... Oh well. :)
To answer your question from #3, I'm trying to get a good understanding of the various base classes so that I use the correct ones in the right situations. The reason I was under the impression that I could not move a CBaseEntity was because, if I remember correctly (I don't have the code in front of me at the moment), I couldn't call a SetVelocity(?) function of some sort as it was undefined. I'll take a look at my code when I get the chance and verify that my memory isn't failing on me (again). Overall, these questions come about both from understanding what I've learned so far and from trying for the last week to create an entity, placed by hammer, which itself can move and spawn more entities (or more specifically, particle effects) that follow it. I can code the two base entities, and I can create particle effects. However, I'm stuck at getting the first entity spawning the second, entities following entities, using existing particle effects, and which base classes should be used where. I, of course, haven't asked that question directly because I still want to figure it out on my own. The questions I have asked are an attempt to fill in the blanks enough to make it all fit together nicely. - Josh On Thu, Feb 21, 2008 at 2:30 PM, Tom Leighton <[EMAIL PROTECTED]> wrote: > I can answer some, not all of your questions. Someone else should reply > aswell unless they're all sleeping or eating, or firing off emails to > Mike and the other VALVe guys. > > 1) C_BaseEntity can be used on its own (As a client-side only entity > object), so if you derive an entity from that without a server-side > partner, it will just be clientside. > Only variables in its network table will be synchronised, so you could > have a clientside property that you set yourself, etc. > > 2) The engine will create the entity server-side (And then propagate it > to clients). The reason we have 2 entities usually for weapons and > players, is so that they can be predicted (I.e. on a weapon playing the > fire animation before the server gets it) > > 3) What do you want to know? Mostly everything in the game is an entity, > take a look at all the triggers (triggers.cpp ?) for some more juicy code > :P > > 3a) Also CLogicalEntity you can inherit from. No, apart from that you > might be re-inventing the wheel if you write some code that another > entity already has that you can inherit from (I.e. a button entity or a > trigger) > > 3b) You can move a CBaseEntity entity. CBaseAnimating, i believe, is > used for things like prop_dynamic where the model is walk-throughable, > no physics involved) > > 3c) CPointEntity is the entity that has no world model, physics, or > interaction. Things like spawn points for maps, the plus side being you > dont have to make a new cpp+h file for every spawn point entity :P > > 4) You dont have a four, just i like numbers in order :P > > 5) I dont deal with particles, someone else will respond :) > > 6) Entities will get destructed / removed / deleted dynamically when > they get destroyed (I believe). The RPG is an example, the rocket when > it blows up gets deleted from the entity list. (Which is why you also > keep pointers on things, so that you can get to them again, especially > entities that dont blow up.... -- gEntList is the entity list) > > Hope that helps :P A more advanced / experienced coder should also > respond :D > > Marine > > Josh Rehm wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > Hello everyone. > > > > <snip> > > > > 1) This is related to the client/server architecture of the engine. I > > realize that a networked entity class should have a CBaseEntity derived > > class on the server and a C_BaseEntity derived class on the client, each > > with the correctly configured network table. From what I understand, > any > > code related to the chosen model displayed (if any), movement of the > entity, > > interactions with other entities (including players), Inputs, Outputs, > etc, > > are all controlled by the CBaseEntity on the server. In summary, > anything > > that may need to be broadcast to all clients to keep them synchronized. > The > > C_BaseEntity is responsible for handling any client side events related > to > > changes in the server entity. Is this correct? Other than displayed > > effects, where it doesn't matter if its synchronized with the other > clients > > (rendering of particle effects for example), what other things the > > C_BaseEntity is responsible for? > > > > > > 2) Related to my previous question, I've noticed that even if I don't > > network a CBaseEntity derived class on the server, it appears on the > client > > (i.e it's drawn, can be interacted with, etc). This seems to imply that > > there is a lot of behind the scenes work being done to handle these > entities > > in a general sense. As such, by not using DECLARE_SERVERCLASS, a > generic > > client side entity object is managing this server entity on the client > side > > and using the DECLARE_SERVERCLASS() macro is just a means of overriding > (or > > extending) that behavior. Is this correct? > > > > > > 3) These questions are related to the Entity classes provided by the > SDK. I > > understand how to do the things I've been shown from the Valve > Development > > Community through their tutorials, but there is no detailed information > > related to what more can be done with the base classes. So far I've > made > > guesses based on what I've seen in the SDK. > > > > 3.a) CBaseEntity: It seems I would inherit directly from this class for > a > > Logical Entity. Aside from developing a whole new type of entity, are > there > > any other reasons for inheriting this class directly? > > > > 3.b) CBaseAnimating: From what I can tell, this class is used when I > need to > > display and move a model. Is that correct? Are there other uses for > > CBaseAnimating? > > > > 3.c) CPointEntity: I haven't used this yet, but from the SDK it appears > as > > if its used for something like a particle effect. What is the purpose > of > > this entity class? > > > > > > 5) When it comes to attaching particle effects to entities, I'm > completely > > lost. I know little pieces of things here and there, but not enough to > form > > a solid understanding of how to use particle effects. I can even create > a > > server/client entity and have it emit some effect, but I can't figure > out > > how to use an existing effect (i.e evn_sparks). For example, let's say > I > > created an entity that can be given a velocity, a duration, and assumes > it > > will be sliding along the flat ground. I decide that for "coolness" I > want > > my box to emit sparks from the bottom it slid. Since there is already a > > particle effect that emits sparks (env_sparks), I figure I should be > able to > > just use that. > > > > 5.a) Can I use env_sparks, or do I have to create a new effect? > > > > 5.b) If I can use it, where can I find information about how to do so? > I > > can't seem to find any resource and nor can I find any information in > the > > Source SDK itself. > > > > 5.c) If I can't use it, could the effect be created as an entity > > (CPointEntity?), using CSimpleEmitter and CSimpleParticle, that can be > made > > to follow any other entity? Is this a reasonable approach and if so, > how > > would I go about making the entity follow another? > > > > 5.d) Is there a summary somewhere that can clear all this up for me? > > > > > > 6) My last question is related to the dynamic creation and destruction > of > > entities. I assume weapon_rpg.h/.cpp would be a good example of this. > I'm > > trying to figure out how to spawn a new entity programatically, and then > > destroy it when it is no longer needed (so it doesn't sit around, > invisible, > > using up resources). Is the weapon_rpg.h/.cpp a good place to see this > > behavior? Are there any pointers anyone can give for this? > > > > > > Thanks in advance, > > - Josh Rehm > > -- > > > > _______________________________________________ > > 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
