Yea, that one :D 2008/12/22 Skyler Clark <sky3...@comcast.net>
> From an actual game architecture perspective I agree with you, but for ease > of development I don't. > CSDKPlayer is like a second layer BasePlayer. It provides the basics, as > you > say. > > If you wanted to keep it at the same level, you should make your own > extension to the BasePlayer and just copy over any code that you are going > to use. If you're just renaming it you are just accomplishing the same > thing > as extending the class (you get all the same functionality), but your code > will mixed in and hard to maintain. Extending will provide one extra level > of inheritence which will provide no noticable difference in performance > but > will allow your code base to be cleaner and more easily maintained. > > -Skyler Clark > > On Sun, Dec 21, 2008 at 7:27 PM, Tony Sergi <to...@valvesoftware.com> > wrote: > > > Olly is right though. > > > > The SDK layer is the same level as CCSPlayer, CTFPlayer, CPortalPlayer, > > CHL2MPPlayer, etc. > > > > The most ideal thing to do would be to either just leave it as CSDKPlayer > > for porting later, or replace all SDK with your mods prefix. Inheriting > it > > is actually rather silly, since all it is at the moment is a sample > player > > that inherits CBasePlayer and does the basics. It's like a template. > > > > > > -----Original Message----- > > From: hlcoders-boun...@list.valvesoftware.com [mailto: > > hlcoders-boun...@list.valvesoftware.com] On Behalf Of Skyler Clark > > Sent: December-21-08 7:11 PM > > To: Discussion of Half-Life Programming > > Subject: Re: [hlcoders] Best way to mod scratch SDK > > > > The SDK stuff is not a bunch of empty classes, there is code and logic > > provided there. If you don't need that code, you should remove any code > > from > > the SDK layer and only use your own code. > > If you are planning on using the SDK level's code, you should extend the > > class. > > Sure, you're adding an extra layer of overhead, but what you gain from > that > > is complete isolation of your mod's player code. > > > > Every architectural decision has tradeoffs. And in this case, I have > found > > that creating my own SDK_Player extension allowed my team to isolate our > > code and greatly helped to increase our productivity, which greatly > > outweighs the slight extra overhead. The difference in overhead is > marginal > > when you consider the depth of inheritance already present in the source > > engine. > > > > -Skyler Clark > > > > On Sun, Dec 21, 2008 at 6:43 PM, Olly <oli...@gmail.com> wrote: > > > > > The SDK stuff is there to be renamed, its the same class level as > > > CCSPlayer, > > > CTFPlayer, etc. If you extend CSDKPlayer, you are just adding more > > overhead > > > that doesn't need to be there. The SDK files don't contain any base > code; > > > so > > > there is no need to inherit from them. > > > > > > 2008/12/21 Skyler Clark <sky3...@comcast.net> > > > > > > > Olly, what a terrible suggestion. There is much to be gained from > > > extending > > > > the sdk_player rather than just renaming it... > > > > To do it, you just need to extend both C_SDK_Player and CSDK_Player. > > > > The player is instantiated in ClientPutInServer in sdk_client.cpp, > line > > > > around line 80... So make it instantiate your extended player there > > > instead > > > > and you're solid. > > > > > > > > -Skyler Clark > > > > > > > > On Sat, Dec 20, 2008 at 3:59 PM, Olly <oli...@gmail.com> wrote: > > > > > > > > > rename the classes/files > > > > > > > > > > 2008/12/20 Michael Chang <flux.black...@gmail.com> > > > > > > > > > > > Hey all > > > > > > After months (years?) of failing to fix HL2DM I've finally > switched > > > > over > > > > > to > > > > > > scratch SDK, thank heavens for that. > > > > > > > > > > > > I want to know how best to mod scratch SDK. For example I want to > > > > > implement > > > > > > my own player type that inherits SDKPlayer. Where in the code do > I > > > tell > > > > > > gamerules to instantiate my own player type instead of > CSDKPlayer? > > > > > > > > > > > > On that note, even after I traced the calls and hierarchy all the > > way > > > > up, > > > > > I > > > > > > end up at sdk_client. Who calls/instantiates sdk_client? How do I > > > > > implement > > > > > > my own mod_client? Should I even bother? > > > > > > > > > > > > Basically, I want to use everything sdk_ etc but inherit it into > a > > > new > > > > > > class > > > > > > instead. I want to try limiting my edits to SDK_etc and do > > everything > > > > in > > > > > > the > > > > > > "proper" OOP way. So instead of sdk_gamerules, I want my own > > > > > mod_gamerules > > > > > > that inherits that. My own mod_playeranimstate... etc > > > > > > > > > > > > But where does it start? Where is the very beginning of switching > > > over > > > > to > > > > > > my > > > > > > own objects/codebase? > > > > > > > > > > > > Thanks. > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > 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
