Thinking of object orientation

Discuss API design here.
Chrisber
Junior Member
Posts: 21
Joined: Thu Jul 19, 2012 10:25 pm

Thinking of object orientation

Postby Chrisber » Fri Jul 20, 2012 7:16 am

Hello everyone,

I've seen that you are designing the core and the API. We all know how EventScripts worked - and of course we like it.
But EventScripts was contaminated with the old EventScripts Shell language (this is not being ment negative). And now you have the chance to stop thinking of old behaviours and patterns.

Why do you agonize about userids, steamids, client indices, serial numbers when they ALL express the same thing: a player. And a player is an entity, even when it's a very specialized one. What about to forget that there are different ways to identify the same object? That is against typical oop patterns and does not promote the simplicity of python.

What I want to say: forget about event variables like userid, steamid. Think of passing objects to the callbacks. Think of accepting entity / player objects only to API functions.

It would make the life so much easier here. Every entity has an index and a serial number. It's perfect, since every player has the same attributes. You are perfectly allowed to derive a player class from an entity class.

This is - in my opinion - the great chance to be better than EventScripts and even than SourcePawn (I do not speak against the SourceMod community and their developers here!).

I do hope you get my point and you guys may start a discussion here ;-)

Chris
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Fri Jul 20, 2012 3:07 pm

Chrisber wrote:Hello everyone,

I've seen that you are designing the core and the API. We all know how EventScripts worked - and of course we like it.
But EventScripts was contaminated with the old EventScripts Shell language (this is not being ment negative). And now you have the chance to stop thinking of old behaviours and patterns.

Why do you agonize about userids, steamids, client indices, serial numbers when they ALL express the same thing: a player. And a player is an entity, even when it's a very specialized one. What about to forget that there are different ways to identify the same object? That is against typical oop patterns and does not promote the simplicity of python.

What I want to say: forget about event variables like userid, steamid. Think of passing objects to the callbacks. Think of accepting entity / player objects only to API functions.

It would make the life so much easier here. Every entity has an index and a serial number. It's perfect, since every player has the same attributes. You are perfectly allowed to derive a player class from an entity class.

This is - in my opinion - the great chance to be better than EventScripts and even than SourcePawn (I do not speak against the SourceMod community and their developers here!).

I do hope you get my point and you guys may start a discussion here ;-)

Chris


Eventscripts was contaminated by more than just the ES shell language. Its design encouraged bad coding practices which in turn also encouraged bad performance. It individually wrapped each source engine function using complicated macros that would not make sense to an outsider. I don't fault Mattie for this at all. He was a busy guy and he didn't have much time to refine ES.

Source.Python intends to move away from all of this. We're not going to have a shell language. Our design and approach to python in the Source Engine is going to be fundamentally different.

We are using player objects Chrisber. There is a 1 to 1 correlation between our python API and the Source Engine. For example, you are able to use edict_t directly within our python code. You can deal directly with player objects without screwing around with userids and whatnot. What you're asking for is already implemented and is the design goal for the future. I implore you to look at my source code which will help you understand what's going on. :)

A dumb example that you can do in Source.Python if you compile it yourself:

Syntax: Select all

from Source import Shared
from Source import Engine

def load():
# Get the source engine interface
SourceEngine = Engine.GetEngine()

# Create a recipient filter and add all players to it.
Recipients = Shared.MRecipientFilter()
Recipients.AddAllPlayers()

# Create a user message.
UserMessage = Engine.UserMessageBegin(Recipients, 22, "HudMsg")

# Write data into the bf_write object.
UserMessage.WriteByte(255) # Player index?
UserMessage.WriteString("Sup")
UserMessage.WriteByte(1)

# Done.
Engine.MessageEnd()

def unload():
pass


EDIT: Someone should correct my usermessage usage as I can't find a good reference on it.
Chrisber
Junior Member
Posts: 21
Joined: Thu Jul 19, 2012 10:25 pm

Postby Chrisber » Fri Jul 20, 2012 8:47 pm

Oh, well. Then I totally misunderstood the idea of Source.Python. Sorry ;-)
your-name-here
Developer
Posts: 168
Joined: Sat Jul 07, 2012 1:58 am

Postby your-name-here » Fri Jul 20, 2012 9:15 pm

Chrisber wrote:Oh, well. Then I totally misunderstood the idea of Source.Python. Sorry ;-)

All good :)

Yeah, it's a complete change from Eventscripts. Our goal is to maintain some similarities with ES, but we're largely going to redo python integration with Source.

Return to “API Design”

Who is online

Users browsing this forum: No registered users and 15 guests