Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/cel: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

Introduction

A number of proposals follow, that all go in the direction of making cel more coherent, and enabling high level control of the components to allow the more powerful logic editor on earth :) Some of the proposals are more directly related to quest system, which is our current graphical editing backend (but shouldnt be the main one in the end).

Filters for quest message trigger

Quest Message Trigger can listen to messages that arrive in a certain MessageChannel (in entities actually), but the messages carry a lot of information both in parameters and sender that could be used to discriminate messages.

So, basically, two kind of filters can be implemented:

Filtering on message parameters

<fireon entity="player" mask="cel.trigger.entity.enter">

<par name="entity" string="a_certain_entity">

</fireon>

Filtering on sender

As atm most senders are pc's the following filters would be implemented easily: Based on sender entity class or name. Based on sender pc name. Based on sender pc tag.

Allow forwarding of message parameters to rewards (in quests)

This task is done: notation is @par. The message trigger sends out all its parameters like this. The mesh select, trigger, and inventory triggers also send in the information about the entity.

This should allow to use an input parameter from a message trigger (and maybe from other triggers too), and use it in a reward. For example entity name, to apply rewards on the entity specified on the message (which now is basically impossible).

Its not clear what notation should be used, probably something different than $parameter as that could easily lead to naming conflicts.

Allow quest parameters to be mapped to pcquest properties

This task is done: notation is =expr and through the expression you can access properties out of the current entity (in pcproperties) using the ?prop notation.

This is very useful and I agree but I wouldn't use pcquest properties. Instead I would use properties out of the properties property class. That is the preferred way to store properties with an entity.

Either using $prop style, or some new style. Right now when designing a quest one can specify a number of parameters for such quest, but the parameters can't be changed afterwards. This could be a very powerful addition, and "just" needs a way to map the properties from pcclass to quest parameters, this way after designing a quest one could still control the properties.

Also this could make quest a full powered citizen in the property class world, as it could define its own messages and properties, thus in a way equivalent to creating property classes in python or c++ (although with more limited syntax of course).

Property change notification on property classes

As is right now, one can subscribe to changes in celPcProperties changes, but not to pc properties changes in general

The main problem is that it's easy for properties to change without cel knowing, as they can come from external libraries. One possible solution would be to have only some properties syncable, so the implementor of the property class would specify if a property is syncable, and then means external users could subscribe to it and get notified. Of course the implementor would have to make sure that the property is not changed without notification (basically by always changing them through property api).