Re: [crossfire] 2.0 object-type refactoring

2006-10-29 Thread Alex Schultz
Alex Schultz wrote: For a while now I've been throwing the idea of separating the server's object-type-specific code by object types. Currently things are rather disorganized with code for how an object type works being spread all around the code. I plan to begin to implement the plan on the

Re: [crossfire] Client-side scripting

2006-10-29 Thread Nicolas Weeger (Laposte)
Just a thought, I'm thinking that perhaps the LUA patch should be put in trunk for 2.x but not in 1.x. Also, to me it would make a bit of sense to also remove the current scripting system in 2.x in favor of that provided that the LUA engine can be supported on all platforms and is built-in.

Re: [crossfire] Client-side scripting

2006-10-29 Thread Andrew Fuchs
On 10/29/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: ... Removing existing scripting, well, I'm not too eager, I think people are used to it... I have a strange feeling that this might evolve into a plugin system. :-/ -- Andrew Fuchs ___

Re: [crossfire] 2.0 object-type refactoring

2006-10-29 Thread Mark Wedel
Few questions: Use form of server/types/foo.c or server/types/foo/bar.c depending on if the object type requires multiple C files to be clean. With the fact that the SVN repository is called server, it is unclear exactly what server refers to. If we include the repository name, is it:

Re: [crossfire] 2.0 object-type refactoring

2006-10-29 Thread Alex Schultz
Mark Wedel wrote: snip IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone