Messaging system changes

[satoon101]

Just a heads up for future changes to the messaging system. We are no longer simply using functions for messages. They are now utilizing class objects:

Syntax: Select all

from events import Event
from messages import SayText2
from players.helpers import index_from_userid

# Create a message to send to non-living terrorists
# Could also use [['t'], ['alive']] for the [users] argument
message = SayText2('\x01This\x02 is\x03 a\x04 test.', users=['t', 'alive'])

@Event
def player_say(GameEvent):
    # Get the player's index
    userid = GameEvent.GetInt('userid')
    index = index_from_userid(userid)

    # Set the message's index
    # Note that this index will remain the same if you send it again without changing the index
    # If you never set an index, it will always use 0
    message.index = index

    message.send()

Syntax: Select all

from events import Event
from messages import SayText2

# Create a message without any [users] being passed
message = SayText2('\x01This\x02 is\x03 another\x04 test.')

@Event
def player_say(GameEvent):
    # Pass the users when sending
    message.send(['t', 'alive'])

Syntax: Select all

from events import Event
from messages import SayText2

# Create a message without any [users] being passed
message = SayText2('\x01This\x02 is\x03 another\x04 test.')

# Set the [users]
message.users = ['t', 'alive']

@Event
def player_say(GameEvent):
    message.send()

The "users" arguments has been moved in all usermessages from the first argument to either the last or next to last argument, so take special note of that. Here are the arguments, which are also attributes, for the current classes (note that <> around an argument means it is "required" when getting an instance, and [] around an argument means it is optional when getting an instance):

• Fade
  • <fade_type>
  • <fade_time>
  • <hold_time>
  • <red>
  • <green>
  • <blue>
  • [alpha]
  • [users]
• HintText
  • <message>
  • [users]
  • [tokens]
• KeyHintText
  • <message>
  • [users]
  • [tokens]
• SayText2
  • <message>
  • [index]
  • [users]
  • [tokens]
• Shake
  • <magnitude>
  • <time>
  • [users]
• TextMsg
  • <message>
  • [type]
  • [users]
  • [tokens]

For TextMsg "type", there are class attributes for Echo and CenterMsg, so you can use it like:

Syntax: Select all

from events import Event
from messages import TextMsg

example1 = TextMsg('This is a test')

# The types are class attributes
example1.type = TextMsg.CenterMsg

# You can also pass it in as the second argument (only as a class attribute)
example2 = TextMsg('This is a test', TextMsg.Echo)

example3 = TextMsg('This is a test')

# Once you have an instance, you can also set using the instance's attribute
example3.type = example3.Echo

There is still quite a bit of work to be done on this new system, including adding in the ability to use tokens and lang strings (though a "rough" lang string implementation has been added, for now).

Once we get some Linux build issues resolved, we will post another release build for CS:GO and a build that will work for Valve OrangeBox games!!

Satoon

[Mahi]

I think that messages should also be included to the PlayerEntity so you could just do <player>.sendMessage(...), but then again if that's needed, it's not too hard to implement myself.
May I ask the reasons behind this change? It would be good to hear some reasons behind most of the major decisions as you make them. Just out of curiosity

[satoon101]

This will probably not be added to PlayerEntity, but we will discuss that possibility internally before making a final decision. Thank you for the suggestion, though.

As far as why the change, there are a few reasons. We really want, as much as possible, to use OOP in this plugin. The one-to-one relationship between the plugin and the engine dictates that we "should" be using the actual names of the UserMessages as the object names (like SayText2 instead of chat and TextMsg instead of echo/centermsg). This change also allows scripters to easily store messages and send them as they need (even with small changes that might need made that can be done through changing the attributes). Overall, I think people will like these changes once they get used to them.

Satoon

[Baster1985]

sp for css sounds good

[satoon101]

Yup It already works properly, on Windows, for Valve OrangeBox games. If you know how to build it yourself, feel free to do so, and try some stuff out. We still need to add more data for the other games, but base support already exists for CS:S.

*Edit: until the wiki is back up and fully operational, you can use this guide to build the plugin yourself on Windows:
http://www.sourcepython.com/showthread.php?26&p=129&viewfull=1#post129

Satoon

[Tuck]

Yup It already works properly, on Windows, for Valve OrangeBox games. If you know how to build it yourself, feel free to do so, and try some stuff out. We still need to add more data for the other games, but base support already exists for CS:S.

*Edit: until the wiki is back up and fully operational, you can use this guide to build the plugin yourself on Windows:
http://www.sourcepython.com/showthread.php?26&p=129&viewfull=1#post129

Satoon

Is CSS prioritized before internal sp features (Such as client cmds, stripping weapons.. so on)?

[satoon101]

Stripping weapons is already available, just use the DropWeapon and Remove dynamic functions.

It is not prioritized before internal features, but it just happened to be the next thing that got added once ynh came back to the team. Client commands will come soon enough, as I know it is already being worked on.

Satoon

[ashbash1987]

(Slightly off-topic, just answering about client commands)
Yes client commands are nearly here, I've been working on it over the past couple of weeks, and it looks ok. I might submit it later today to see what you all think of it. It seems to be in a stable condition.

[Tuck]

Satoon101 could you show me an example with the new code doing the same as i did bellow:

Syntax: Select all

chat((), 'MESSAGE', user.index)

i don't get how you set receivers and afterwords set the index of the player team color u would use?

[satoon101]

It would be just like in the first examples. You do not "have" to create the object in the global scope, however. You can also simply use:

Syntax: Select all

from events import Event
from messages import SayText2
from players.helpers import index_from_userid

@Event
def player_say(GameEvent):
    userid = GameEvent.GetInt('userid')
    index = index_from_userid(userid)
    SayText2('Message', index).send()

Since you are not passing any users on instanciation or when you use the send method, like in the above example, "all" players are sent the message.

For your example, you can also create the instance in the global scope:

Syntax: Select all

from events import Event
from messages import SayText2
from players.helpers import index_from_userid

# Notice we did not pass any users or an index
message = SayText2('Message')

@Event
def player_say(GameEvent):
    userid = GameEvent.GetInt('userid')
    index = index_from_userid(userid)

    # Now, we want to set the index to the chatting player's index
    message.index = index

    # So, now when we send the message, we still haven't passed any users,
    # so all users will receive the message
    # Also, the index is of the chatting player, so the "team" color (\x03)
    # will be the color for the chatting player's team
    message.send()

Satoon

[satoon101]

To be more help, you really need to think of these messages as "objects". A SayText2 instance has 4 attributes, of which, currently you only need to worry about 3:

Syntax: Select all

from messages import SayText2

# Let's create a message that uses -1 for the index, and will be sent to dead terrorists
# In some games, -1 is a different color than either team's color or the default color
# In CS:S, for instance, it is grey
message = SayText2('\x01This\x02 is\x03 my\x04 test\x05 message.', -1, [['dead', 't']])

# Now, if for some reason we wanted to change the message, use the "message" attribute of the object
message.message = '\x01This\x02 is\x03 another\x04 test\x05 message.'

# Then, we can want to change the message to be sent to alive counter-terrorists,
# so we use the "users" attribute of the object
message.users = [['alive', 'ct']]

# Now, we want to use the "default" color for the team color,
# so we need to change the "index" attribute of the object to 0
message.index = 0

# So, when we send the message now, it will only be sent to alive cts,
# will use the new message, and will use the "default" color for \x03
message.send()

# Now, we want to send the message to everyone instead of just alive cts,
# so we pass an empty tuple as the "users" argument for the "send" method.
# You could also just set the "users" attribute of the messages object to ()
# and then use the send method without any arguments
message.send(())

Satoon

[Tuck]

Ight now i got it

SayText2(<message>, <"color" index>, <recipients>)
SayText2.send([optional: users])

thanks for the further explanation

[Tuck]

what about from messages import hudhint ?

nevermind i guess it changed name to hinttext

[satoon101]

Just like the actual name used by the engine, it's HintText. For CS:GO, HintText and KeyHintText are the exact same thing. In OrangeBox games, the KeyHintText is on the right side of the screen.

Satoon

[La Muerte]

does this mean we have to create a new object every time we want to send a new message?
isn't there a reason for which the Python developers made a __call__ function?

[L'In20Cible]

Hey La Muerte,

Yes you have to create a new object every time. But if you plan to send the same message multiple times, it may be wise to you to globalize it.

L'In20Cible

[La Muerte]

I don't really see the point of doing it that way

[L'In20Cible]

→ http://www.sourcepython.com/showthread.php?145-Messaging-system-changes&p=975&viewfull=1#post975

[La Muerte]

ok, i'll start to get used to it then

[satoon101]

does this mean we have to create a new object every time we want to send a new message?
isn't there a reason for which the Python developers made a __call__ function?

If you are really worried about that, you "could" also just create one instance for a given UserMessage type, and prior to sending the message, change the users, message, etc... That way, you would only need one instance of the object to send all messages of that type. I wouldn't necessarily recommend that, but if that is what you wish to do, by all means do it that way.

Satoon