api standardisation

[genjix]

Hi,

Some standardisation for interfaces should be made somewhere. For instance:

1. When loading something from vfs, sometimes path and filename are used and sometimes not. Imo only filename should exist and it should be clever enough to split them internally (via a cs helper function).

2. Directional movement- except in special cases, this should use the same kind of format.

iPcActorMove: RotateLeft (bool)
iPcWheeled: SteerLeft ()/SteerStraight ()
iPcCraftController: StartTurnLeft ()/StopTurnLeft ()

The last 2 examples there are more or less the same. I think the first one simplifies the method list and looks most intuitive.

Please add more examples :)

[genjix]

3. Another one is the many camera systems- it seems pcdefcamera is the favoured one, but from what I see pcnewcamera has a better structure and does some colldet (stopping it flying into walls). I never even tried simpcam...

4. Xml is very pervasive throughout the design of CEL.

5. blxml.cpp is very large. Some sort of template instancing which instantiates an object that registers itself with some hash table would be nice prehaps. :) [This is an implementation detail- but thought it worth mentioning here]

6. blpython breaks often. Everytime I update, older exported celzips fail to work (the most recent one with CameraPositions stopped working).

[anonymous]

About 1. Don't agree at all. Rather the opposite. Only with path and file should exist. Not the other one. Splitting automatically does NOT work. Because in CC I often use the situation where path = /foo/bar and the filename itself still contains a path element (i.e. textures/bla.png). This is very common with world files generated from b2cs. There the path is used to set the path to the world file but inside that the textures and factories still need to use a relative path.

3. pcnewcamera needs someone to look at and see how good it is compared to the default camera. After that we can switch.

4. What exactly about 4? Is that a problem?

5. I don't understand this. Ok it is large. But what do you suggest exactly?

[DarekDawidowski@…]

1. agree about unification whatever to which method 2. agree with you too 3. yes, but it should be more complex project in future, big redesign not only simple unifying (also worth another ticket and more talk) 4. disagree, why ? 5. agree I thought soem day about pointers to functions 6. no idea about this one

[genjix]

5. Theres a globally accessible string:functor map (in the scope of blxml).

You can define a template (with string and functor parameters) which will instantiate an object of itself where its defined, calling its constructor at the start which just simply adds the string,functor to the global string:functor map.

This can be then macro'ed, and the xml stuff can be spread over several files or however necessary.