Behaviours depricated according to iPcActorMove Struct Reference?

[KK]

I was looking through the api documentation for the iPcActorMove interface, since I wanted to know what possibilities it offers for character control (I'm new to CEL, and I'm trying to move past the starting tutorial stage). I've noticed that it has the following line:

Note! Since behaviours are deprecated this property class can now also listen to messages from pclinmove directly.

What does this mean? I'm guessing that behaviours are not being deprecated for the entire CEL framework, since I never seen it mentioned anywhere else in the documentation. Does this just mean that you don't have to use the behaviour layer anymore to translate between input and movement, unlike you had to in the walktut example?

[jorrit]

I was looking through the api documentation for the iPcActorMove interface, since I wanted to know what possibilities it offers for character control (I'm new to CEL, and I'm trying to move past the starting tutorial stage). I've noticed that it has the following line:

Note! Since behaviours are deprecated this property class can now also listen to messages from pclinmove directly.

What does this mean? I'm guessing that behaviours are not being deprecated for the entire CEL framework, since I never seen it mentioned anywhere else in the documentation. Does this just mean that you don't have to use the behaviour layer anymore to translate between input and movement, unlike you had to in the walktut example?

This basically means that eventually the behaviour layer will go away completely. The new way to do things is using property classes. Everything a behaviour can do you can do just as well in a (self-written or not) property class. So for new CEL apps you should try to avoid using the behaviour layer for anything.

Greetings,

[KK]

I was looking through the api documentation for the iPcActorMove interface, since I wanted to know what possibilities it offers for character control (I'm new to CEL, and I'm trying to move past the starting tutorial stage). I've noticed that it has the following line:

Note! Since behaviours are deprecated this property class can now also listen to messages from pclinmove directly.

What does this mean? I'm guessing that behaviours are not being deprecated for the entire CEL framework, since I never seen it mentioned anywhere else in the documentation. Does this just mean that you don't have to use the behaviour layer anymore to translate between input and movement, unlike you had to in the walktut example?

This basically means that eventually the behaviour layer will go away completely. The new way to do things is using property classes. Everything a behaviour can do you can do just as well in a (self-written or not) property class. So for new CEL apps you should try to avoid using the behaviour layer for anything.

Ah, that is interesting to know. Do you know if there are any examples on how to do character control without using the behaviour layer? The tutorials in the manual still use it.

[jorrit]

Yes the tutorials are a bit outdated. I have no really easy ready to use examples at this moment
but Ares does this right now. The way ares does this is having the following property classes:

• pcinput.standard: taking care of input
• various pclogic.wire property classes taking care of receiving messages from pcinput.standard
  and sending them to the application logic property class (which is a custom property class made
  by ares that handles main game logic).
• pcmove.actor.dynamic: this is a physics based movement class that directly understands
  messages from pcinput if you use the right names (like 'strafeleft' and so on). If you don't
  want to use physics you can also the actormovement property class. It has a Subscribe
  message that you can use from xml (or from code too if you want). When you call that it will
  also understand the messages sent by pcinput.standard directly without the need for
  an intermediate behaviour layer

There are many ways you can set this up. The way above works fine for Ares. You may also opt
to let your custom property class do the mapping between keyboard events and movement. In that
way it would act like what many behaviour layers do now.

The behaviour layer system is really redundant because everything you can do with this can
also be done with property classes using the new message system.

If you need more detailed information then tell me.

Greetings,

[KK]

Thank you for the information. I got everything working.

For others interested in an example, I modified the walktut app to control the motion of the character + camera mode thought the Subscribe action.

There were three changes that I had to make to the example:

The key change was to add the following code to the end of the CreatePlayer function. It  basically adds a wire that pipes actions from pcinput.standard to pcmove.actor.standard.

Code:

  csRef<iPcWire> wire=scfQueryInterface<iPcWire>(pl->CreatePropertyClass(player_entity,"pclogic.wire"));
  wire->AddInput("cel.input.forward");
  wire->AddInput("cel.input.backward");
  wire->AddInput("cel.input.rotateleft");
  wire->AddInput("cel.input.rotateright");
  wire->AddInput("cel.input.cammode");
  wire->AddOutput(pl->FetchStringID("cel.move.actor.action.Subscribe"),0);

I had to include propclass/wire.h to use the iPcWire interface. However I also had to move the physicallayer/propclas.h include to the top. With it after the wire.h include, I got a compile error:[/li]

Code:

C++ ./out/linux/optimize/apps/tutorial/walktut/app.o
In file included from /home/kkrizka/Sources/cel-svn/apps/tutorial/walktut/app.cpp:10:0:
./include/propclass/wire.h:54:48: error: ‘iMessageChannel’ has not been declared
In file included from /home/kkrizka/Sources/cel-svn/apps/tutorial/walktut/app.cpp:10:0:
./include/propclass/wire.h:67:47: error: ‘iMessageChannel’ has not been declared
./include/propclass/wire.h:68:7: error: ‘iCelParameterBlock’ has not been declared

I'm guessing the error is from a missing include inside wire.h that will be fixed sometimes later?

Remove action handling from BehaviourPlayer. The behaviour layer is still needed for the inventory stuff, as the ShowInventory() is a custom function.

Is there any interest in me writing an update to the manual, so this information could become more readily available to new users of CEL like me?

The full patch is as follows (SVN revision 4903):

Code:

Index: apps/tutorial/walktut/behave.h
===================================================================
--- apps/tutorial/walktut/behave.h      (revision 4903)
+++ apps/tutorial/walktut/behave.h      (working copy)
@@ -115,15 +115,6 @@
 class BehaviourPlayer : public BehaviourCommon
 {
 private:
-  csStringID id_pccommandinput_forward1;
-  csStringID id_pccommandinput_forward0;
-  csStringID id_pccommandinput_backward1;
-  csStringID id_pccommandinput_backward0;
-  csStringID id_pccommandinput_rotateleft1;
-  csStringID id_pccommandinput_rotateleft0;
-  csStringID id_pccommandinput_rotateright1;
-  csStringID id_pccommandinput_rotateright0;
-  csStringID id_pccommandinput_cammode1;
   csStringID id_pccommandinput_drop1;
 
   csStringID id_pcinventory_addchild;
Index: apps/tutorial/walktut/app.cpp
===================================================================
--- apps/tutorial/walktut/app.cpp       (revision 4903)
+++ apps/tutorial/walktut/app.cpp       (working copy)
@@ -1,13 +1,14 @@
 #include <crystalspace.h>
 
 #include <celtool/initapp.h>
+#include <physicallayer/propclas.h>
 #include <propclass/zone.h>
 #include <propclass/camera.h>
 #include <propclass/mesh.h>
 #include <propclass/linmove.h>
 #include <propclass/actormove.h>
 #include <propclass/input.h>
-#include <physicallayer/propclas.h>
+#include <propclass/wire.h>
 
 #include "app.h"
 #include "behave.h"
@@ -101,6 +102,15 @@
   pcinput->Bind ("m", "cammode");
   pcinput->Bind ("d", "drop");
 
+  // Setup the inputs using wires
+  csRef<iPcWire> wire=scfQueryInterface<iPcWire>(pl->CreatePropertyClass(player_entity,"pclogic.wire"));
+  wire->AddInput("cel.input.forward");
+  wire->AddInput("cel.input.backward");
+  wire->AddInput("cel.input.rotateleft");
+  wire->AddInput("cel.input.rotateright");
+  wire->AddInput("cel.input.cammode");
+  wire->AddOutput(pl->FetchStringID("cel.move.actor.action.Subscribe"),0);
+
   return true;
 }
 
Index: apps/tutorial/walktut/behave.cpp
===================================================================
--- apps/tutorial/walktut/behave.cpp    (revision 4903)
+++ apps/tutorial/walktut/behave.cpp    (working copy)
@@ -93,15 +93,6 @@
 BehaviourPlayer::BehaviourPlayer (iCelEntity* entity, BehaviourLayer* bl, iCelPlLayer* pl)
   : BehaviourCommon (entity, bl, pl)
 {
-  id_pccommandinput_forward1 = pl->FetchStringID ("pccommandinput_forward1");
-  id_pccommandinput_forward0 = pl->FetchStringID ("pccommandinput_forward0");
-  id_pccommandinput_backward1 = pl->FetchStringID ("pccommandinput_backward1");
-  id_pccommandinput_backward0 = pl->FetchStringID ("pccommandinput_backward0");
-  id_pccommandinput_rotateleft1 = pl->FetchStringID ("pccommandinput_rotateleft1");
-  id_pccommandinput_rotateleft0 = pl->FetchStringID ("pccommandinput_rotateleft0");
-  id_pccommandinput_rotateright1 = pl->FetchStringID ("pccommandinput_rotateright1");
-  id_pccommandinput_rotateright0 = pl->FetchStringID ("pccommandinput_rotateright0");
-  id_pccommandinput_cammode1 = pl->FetchStringID ("pccommandinput_cammode1");
   id_pccommandinput_drop1 = pl->FetchStringID ("pccommandinput_drop1");
 
   id_pcinventory_addchild = pl->FetchStringID ("pcinventory_addchild");
@@ -177,25 +168,7 @@
 {
   GetActorMove ();
 
-  if (msg_id == id_pccommandinput_forward1)
-    pcactormove->Forward (true);
-  else if (msg_id == id_pccommandinput_forward0)
-    pcactormove->Forward (false);
-  else if (msg_id == id_pccommandinput_backward1)
-    pcactormove->Backward (true);
-  else if (msg_id == id_pccommandinput_backward0)
-    pcactormove->Backward (false);
-  else if (msg_id == id_pccommandinput_rotateleft1)
-    pcactormove->RotateLeft (true);
-  else if (msg_id == id_pccommandinput_rotateleft0)
-    pcactormove->RotateLeft (false);
-  else if (msg_id == id_pccommandinput_rotateright1)
-    pcactormove->RotateRight (true);
-  else if (msg_id == id_pccommandinput_rotateright0)
-    pcactormove->RotateRight (false);
-  else if (msg_id == id_pccommandinput_cammode1)
-    pcactormove->ToggleCameraMode ();
-  else if (msg_id == id_pccommandinput_drop1)
+  if (msg_id == id_pccommandinput_drop1)
     Drop ();
   else if (msg_id == id_pcinventory_addchild)
   {

[jorrit]

Thanks a lot! I will incorporate your changes today.

An update to the manual would be very welcome.

Greetings,

[jorrit]

Ok, I put your code in svn. Thanks a lot!

[KK]

Thanks a lot! I will incorporate your changes today.

An update to the manual would be very welcome.

Greetings,

I did write a quick update to the tutorial and attached the patch. It contains the following changes:

• I updated all of the code snippets in the tutorial to reflect the code inside the repository. This means
  
  • Using the pclogic.wire property class for controlling the character.
  • Using celQueryPropertyClassEntity function instead of the CEL_QUERY_PROPCLASS_ENT macro to get a property class. From what I understand, the macro was pre-CEL-2.0 stuff.
• Wrote a blurb about how wires work when describing the CreatePlayer function.
• Removed references to player movement from inside the behaviour layer.
• I updated the tutorial code a bit.
  
  • I bind all pcinput.standard messages to the wire's input by using "cel.input" as a mask. Just to show that one doesn't need to write each action that they want to respond to.
  • Removed GetActorMove() from PlayerBehaviour, since it wasn't used anymore.
  • Tried to follow CEL's coding convention a bit better. I saw I had a few missing spaces.

I hope I understood how everything works and you will find this update useful.