*nod* yes that makes sens, that's similar changing the revision of the external link in your working copy and not checking that change in. I don't think that core developers can make much use of this, it's rather useful for users that wish to build from source or developers that don't deal much with crystalspace. One example of this I already mentioned on IRC is that you don't need to specify revision numbers in the compile guide, instead you can just say "checkout crystal-stable"

Apparently each revision of planeshift is firmly tied to a specific revision of crystalspace. I think maintenance could be greatly simplified by using revisioned external definitions. That way developers and testers could automagically pull the correct CS version without having to bother about revision numbers themselves. It also has some other nice benefits, please read http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html for details.

example "patch":
Property changes on: trunk
___________________________________________________________________
Name: svn:externals
   + crystalscpace -r30564 https://crystal.svn.sourceforge.net/svnroot/crystal/CS/trunk


this will pull CS rev 30564 into trunk/crystalspace when you co/up trunk. You can use svn:propedit to change this to a different version in your working copy, and when you check in everyone pulling trunk will update to the changed revision as well (unless they also changed svn:externals, in which case they will have to resolve the conflict first, just like with a regular file). When you later use svn merge or svn copy to make/update a stable branch, the svn:externals property will be preserved just like a regular file, so users pulling the stable branch will always pull the correct revision of CS, regardless of what you do in trunk.

Here's the patch for CEL. CS simply removed the CS_CONST_METHOD define in 1.4, so it's safe to do this in CEL

--- plugins/tools/celconsole/celconsole.h       2008-07-31 00:09:35.000000000 +0200
+++ plugins/tools/celconsole/celconsole.h       2008-07-31 00:10:31.000000000 +0200
@@ -145,12 +145,12 @@

     CS_EVENTHANDLER_NAMES("cel.tools.celconsole");
     CS_EVENTHANDLER_DEFAULT_INSTANCE_CONSTRAINTS
-CS_CONST_METHOD virtual const csHandlerID * GenericPrec
+virtual const csHandlerID * GenericPrec
 (csRef<iEventHandlerRegistry> &, csRef<iEventNameRegistry> &,
  csEventID) const {
   return 0;
 }
-CS_CONST_METHOD virtual const csHandlerID * GenericSucc
+virtual const csHandlerID * GenericSucc
 (csRef<iEventHandlerRegistry> &r1, csRef<iEventNameRegistry> &r2,
  csEventID event) const {
   static csHandlerID succConstraint[2];
The ebuilds don't update $PATH and ld.so.conf ... is that intentional?

* There is no reason to overwrite /etc/env.d/90crystalspace by dev-games/cel. Please create /etc/env.d/90cel instead.
* CEL also misses a #define CS_CONST_METHOD (leaving it empty should do), causing the compile to fail. I guess CS removed it and this is a leftover occurance in CEL. Maybe use a patch until it's fixed upstream or bump the ebuild if it already is.

Who speaks about removing? I like riddles and I'd like even more of them in quests.  But maybe those that play around with words and spelling should not be        favourised too much (when new ones get into the game), and currently it seems they make up the vast majority.

Oh, and these are chestnuts:
Also note that chest has two meanings, "big box" and the upper front part of your torso. "To put hair on your chest" is an idiom which may be regional.

P.S. Also note that culture is regional. I never heard this riddle in any language. Neither I can find it anywhere on the web. (Although it's not too hard to solve, but the point is there is more than one solution).

In the first post, you name the "Brintec fur research quest" as marked for "the next fix". It is never mentioned as fixed later, what's the status of this quest?

Well my Monitor is calibrated for graphical work I only need a (\"wrong\") lighter Gamma for PS.