PyOT updates, and looking for people.

[Convidado Avuenja]

Well, I'm testing PyOT right now on my computer.

 

I will verify its functionality a bit and everything. So you can have something in mind.

Within the AAAC, I'll be seeing this and the tools also going to Python 3. Ok? 

[Yamaken 41]

Hail stian

 

Its has been a long time since the last time i talked with you. My english has not improved still i will try to explain a "new" concept that maybe will be useful to pyot.

 

Has i programmer, i would like to change core behavior without changing core code. Today we can do it with events, buts its not cool. I see events more like a notification than a callback to change behavior. Because there is two type of use for events: I want to modify login behavior( choose if a player can login ) or i want to be notified when a player login. Events that modify behavior should be called first and then if player can login the notification event will be called. 

 

I would name "hooks" the type of event which modify behavior. Hooks will be called first, if they return true, then the notification event happens.  Its called "hook" because its hooks core behavior and change it. Notification events are just to know that something in the game happen.

[Convidado Avuenja]

 

Is alive! \o/

 

 

I'm checking here at the moment the error...

[stian 7]

My mistake, i thinked that 'El diablo' was a player name k

But no, it's just a event name, right?

This system is very usefull, I like it

Note quite.

@register('lookAt', 1234) - Itemid

@register('lookAt', "Some string") - Itemname, monstername, playername (you can use thing.isPlayer(), thing.isNPC(), thing.isMonster() or thing.isItem() to truely find out)

@register('lookAt', "30000") - Converted actionids.

 

You can bind to multiple things by supplying a list:

@register('lookAt', [1234, 1235])

 

Or a range:

@register("lookAt", range(1234, 1300)) - All itemids in range 1234....1299.

 

You can even make dynamic events on all online players right now.

@register("lookAt", game.player.allPlayers.keys())

 

@register("lookAt", "player") - Matches any player

@register("lookAt", "monster") - Matches any monster

@register("lookAt", "npc") - Matches any npc

@register("lookAt", "creature") - Matches any creature

@register("lookAt", "item") - Matches any item

 

It's:

@register(EVENTNAME[, TRIGGER])

 

 

("lookAt" is just used as an example, it can be replaced by any thing event)

 There is one slight rule tho, you should never allow a monster, npc or player to be named "creature", "player", "item", "npc". As that'll bug (maybe we should have a check for that when loading monsters, npcs and items?)

Editado 17 Outubro, 2014 por stian

[stian 7]

Hail stian

 

Its has been a long time since the last time i talked with you. My english has not improved still i will try to explain a "new" concept that maybe will be useful to pyot.

 

Has i programmer, i would like to change core behavior without changing core code. Today we can do it with events, buts its not cool. I see events more like a notification than a callback to change behavior. Because there is two type of use for events: I want to modify login behavior( choose if a player can login ) or i want to be notified when a player login. Events that modify behavior should be called first and then if player can login the notification event will be called. 

 

I would name "hooks" the type of event which modify behavior. Hooks will be called first, if they return true, then the notification event happens.  Its called "hook" because its hooks core behavior and change it. Notification events are just to know that something in the game happen.

This kinda does both, as the return value tends to be honored (or should). No Return value would then be such a notification event. In general the return value should perhaps only be updated if it's "not None". And yes, return value IS optional. It's a good idea to check for False and cancel execution at that stage in scriptsystem.py tho.

 

You also got @registerFirst(EVENT[, TRIGGER]) which can be used to truly get your core hook in first.

 

There is no problem modifying core functions tho, you can actually override them. You can override, and do stuff directly into the core if necessary. The war system does that etc.

 

One example from the war system (this was not put in as a core feature just to provide this example =P):

    _oldGetEmblem = game.player.Player.getEmblem
    # New emblem function.
    def getEmblem(self, creature):
        guildId = self.data["guild_id"]
        if guildId:
            if guildId == creature.data["guild_id"]:
                # Same guild.
                return EMBLEM_GREEN
            if guildId in wars:
                if creature.data["guild_id"] in wars[guildId][0]:
                    # We are at war with this guild.
                    return EMBLEM_RED

                # We are at war, but not with him.
                return EMBLEM_BLUE

        # Call default function.
        return _oldGetEmblem(self, creature)

Editado 17 Outubro, 2014 por stian

[dalvorsn 46]

Note quite.

@register('lookAt', 1234) - Itemid

@register('lookAt', "Some string") - Itemname, monstername, playername (you can use thing.isPlayer(), thing.isNPC(), thing.isMonster() or thing.isItem() to truely find out)

@register('lookAt', "30000") - Converted actionids.

 

You can bind to multiple things by supplying a list:

@register('lookAt', [1234, 1235])

 

Or a range:

@register("lookAt", range(1234, 1300)) - All itemids in range 1234....1299.

 

You can even make dynamic events on all online players right now.

@register("lookAt", game.player.allPlayers.keys())

 

@register("lookAt", "player") - Matches any player

@register("lookAt", "monster") - Matches any monster

@register("lookAt", "npc") - Matches any npc

@register("lookAt", "creature") - Matches any creature

@register("lookAt", "item") - Matches any item

 

It's:

@register(EVENTNAME[, TRIGGER])

 

 

("lookAt" is just used as an example, it can be replaced by any thing event)

 There is one slight rule tho, you should never allow a monster, npc or player to be named "creature", "player", "item", "npc". As that'll bug (maybe we should have a check for that when loading monsters, npcs and items?)

OMG, It's perfect!

If you didn't use a string to represent the classes you should not be a bug

instead you use strings, you can use the classes like parameter

Is it possible?

[Yamaken 41]

 

This kinda does both, as the return value tends to be honored (or should). No Return value would then be such a notification event. In general the return value should perhaps only be updated if it's "not None".

 

You also got @registerFirst(EVENT[, TRIGGER]) which can be used to truly get your core hook in first.

 

There is no problem modifying core functions tho, you can actually override them. You can override, and do stuff directly into the core if necessary. The war system does that etc.

 

One example from the war system (this was not put in as a core feature just to provide this example =P):

    _oldGetEmblem = game.player.Player.getEmblem
    # New emblem function.
    def getEmblem(self, creature):
        guildId = self.data["guild_id"]
        if guildId:
            if guildId == creature.data["guild_id"]:
                # Same guild.
                return EMBLEM_GREEN
            if guildId in wars:
                if creature.data["guild_id"] in wars[guildId][0]:
                    # We are at war with this guild.
                    return EMBLEM_RED

                # We are at war, but not with him.
                return EMBLEM_BLUE

        # Call default function.
        return _oldGetEmblem(self, creature)

Still, we need separate hooks from notification events. Actually they are on the same list, and them are called in the same sequence they are added to the list. Its need separation because i want to control behavior first and then do the notification event. Hooks function should have a different function definition, they need a mechanism to let the system know which hook will handle the call. Only one behavior/hook per time.

 

About overriding, in python you can even override a whole class( like Player ) to put your own player behavior. Very powerful, still a hack. Plugin-like would be better

Editado 17 Outubro, 2014 por Yamaken

[stian 7]

OMG, It's perfect!

If you didn't use a string to represent the classes you should not be a bug

instead you use strings, you can use the classes like parameter

Is it possible?

It would, but it violates the pythonic way of doing things. If it quacks like an item, and talks like an item, but doesn't subclass an item, it wouldn't be identified as an item. How sad.

 

We can use bytes to avoid this =P,

@register("lookAt", b"player")

or even a wrapper or our own subclass of str.

@register("lookAt", objType("player")) # Which just subclasses a string, but isnt a string.

 

 

 

and then are called in the same sequence they are added to the list.

Tried telling you we have @registerFirst() which put it first in the list. This would allow you just that, return False here stops the execution (as of my lastest commit ). This shouldn't be used for any other purpose than just this. We might rename registerFirst to registerHook or something tho if it feels more logical. The underlaying mechanics doesn't have to change.

Editado 17 Outubro, 2014 por stian

[dalvorsn 46]

It would, but it violates the pythonic way of doing things. If it quacks like an item, and talks like an item, but doesn't subclass an item, it wouldn't be identified as an item. How sad.

 

We can use bytes to avoid this =P,

@register("lookAt", b"player")

or even a wrapper or our own subclass of str.

@register("lookAt", objType("player")) # Which just subclasses a string, but isnt a string.

 

Or small number,  i guess that actionids, uniqueids and itemids didn't use numbers smaller that 100

So we can use enums to define the class

 

Example:

players = 1

monster = 2

...

[Yamaken 41]

Tried telling you we have @registerFirst() which put it first in the list. This would allow you just that, return False here stops the execution (as of my lastest commit ). 

See, it needs a mechanism to know which hook will handle the call because it will use the returning value to control behavior( like true/false to know if something is allowed ). it needs to know from which hook will come the return value. If the first hook will not handle it, then the system will call the next, if the next handle it, then it will return the return value from this hook. Inside the hook the programmer can define the conditions to handle it and then choose which will be the return value. Like i said, only one hook can handle/modify the behavior. Its more powerful and clean.

Editado 17 Outubro, 2014 por Yamaken

[stian 7]

Or small number,  i guess that actionids, uniqueids and itemids didn't use numbers smaller that 100

So we can use enums to define the class

 

Example:

players = 1

monster = 2

...

Ye, that could work.

 

See, it needs a mechanism to know which hook will handle the call because it will use the returning value to control behavior( like true/false to know if something is allowed ). it needs to know from which hook will come the return value. If the first hook will not handle it, then the system will call the next, if the next handle it, then it will return the return value from this hook. Inside the hook the programmer can define the conditions to handle it and then choose which will be the return value. Like i said, only one hook can handle/modify the behavior. Its more powerful and clean.

Feel free to start a branch for this

[Yamaken 41]

Feel free to start a branch for this

 

Yes, i will do it. Do you think this concept is good?

[stian 7]

The idea is good, but it needs to have some real uses. Ideally, start with a real problem (a script which you need this hooking), and start implementing what you need for this to work.

 

The worst hooking systems I know try to solve all kinds of issues in various projects, which makes alot more problems,  phpbb3's hooking system is one example, most script still had to rely on various modifications.

 

And however you want to solve this, never ever build a system which does eval() everywhere you feel like patching in some code, it's a debug nightmare. With insanely poor performance in any language. This is far too common in the PHP world.

[Loser. 1]

I would like to help in project, but I'm benniger programmer(Python). If possible, I would help in scripts...

[Nully 1]

It's good to hear news about PyOT, i really like how it is coded in python and the powerful scripting ability. I was already enjoyed with PyOT some time ago and it still need a lot of improvement, besides i don't like how the TFS is coded him is pretty stable and for a working server is better than PyOT. I'm already making my server but i could help in development of the PyOT in future, i don't have much skill in Python but it's a good thing to learn.

 

Then i'm looking forward for this, hopefully someday see PyOT stable sufficient for a working server

 

Edit: It's good if we could make a complete server with PyOT for download and run, could be a good thing for fix bugs and core improvements, what you think about that?

Editado 18 Outubro, 2014 por Nully

[Lordfire 110]

Great to see you here, Stian

 

It's nice to read that it was updated to Python 3 and I'm looking forward to contribute.

 

Although I don't use BitBucket that much, I prefer it over GitHub and mercurial over git too. I'm https://bitbucket.org/ranisalt

 

Thanks!

[stian 7]

 

 

Edit: It's good if we could make a complete server with PyOT for download and run, could be a good thing for fix bugs and core improvements, what you think about that?

It would certainly be helpful, especially since scripts can be a bit more realistic than what some of them are now.

 

 

Then i'm looking forward for this, hopefully someday see PyOT stable sufficient for a working server 

The major delay is rather that we trie to do everything before making half of it work. Etc, multi lingual, multi platform, async sql, with a heck of a lot of twisted ideas. Like extserver, webserver (this actually worked in the python2, haven't been ported to python3 yet tho), and the web-client.

 

 

 

Although I don't use BitBucket that much, I prefer it over GitHub and mercurial over git too. I'm https://bitbucket.org/ranisalt

Added

[Nully 1]

Stian, can you tell what PyOT have, what you plan to implement and what you want which PyOT to be?

[stian 7]

 

 

Stian, can you tell what PyOT have, what you plan to implement and what you want which PyOT to be?

Much lower memory footprint than TFS, you can host a real map in like 250MB ram with some settings tweaks. It uses much less CPU as well. Sadly I don't have the pypy data for this, but it'll come.

 

A few strongpoints:

- The ability to use multiple game protocols, everything from 8.6 to 9.xx (currently), can be logged in to same server.

- Much simpler script system (TFS is seriously confussing, and hard to work with, xml files is such a waste).

- Async SQL, that is, TFS run an sql query and it takes 20ms, it "lags" for 20ms, in this, there is no lag. Just pure processing time.

- The ability to use multiple languages (say you want a native portuguese server, with the ability to also use english).

- Ability to run multiple words in one server (instances), get rid of mapping multiple rooms onto your map, do it once and load it in as many times you need.

 

It does have bugs, it does have places where it can be much better. It lake long time production testing.

 

EDIT: There is also the need to support 10.x clients, if anyone are up for it

Editado 18 Outubro, 2014 por stian

[Yamaken 41]

Supporting more clients should not be the focus now. Async programming is not so easy.. a new architecture is needed. Refactoring model( sql ) stuff on a class would be good...

Editado 19 Outubro, 2014 por Yamaken