I have a doubt about using scripting languages like Lua to implement some stuff in a server, specifically player skills/spells. Is it wise to script such things or should I avoid scripts at all in the server design? What can be scripted and what should definitely not be scripted?
What I always say is, if you are going to learn, then learn the best method. So, I would say that my situation fits in the first case. That means that I should avoid scripts.
Ask yourself what flexibility you get from keeping that logic as scripts, and if you actually need that. You could just as well keep the same logic as plugins, swapping out dll's instead of text files.
Sorry, I should have spcified that the game style is RPG, with PvE and PvP, with large scale battles if possible. So, at some point, the server will be managing two dozens of players casting skills on each other plus summoned NPCs.
I have a doubt about using programming languages like Lua to implement some stuff in a server, specifically player skills/spells. Is it wise to program such things or should I avoid programming at all in the server design? What can be programmed and what should definitely not be programmed?
^I replaced scripting with programming 
"Scripting languages" are still just programming languages. There's no real difference between using Lua and using any other programming language.
e.g. Most of the console games that I've worked on have almost entirely been written in Lua. LuaJIT is very fast 
Use whatever language you're most comfortable with.
There's no real difference between using Lua and using any other programming language.
I would say something like : Depends how complex the application of the scripting (how much logic does it add upto) and how often it has to run (some AI does alot of constant reevaluation of a situation just to select one action).
Also what 'script' features are needed that a native language doesnt do for you (ie garbage collection or soft typing, etc)
Script If there are Huge amounts of logic using scripting to make that logic 'nicer' for semi-programmers (and isnt run excessively to significantly lose performance) Thats if the actual server load is of any significance where that performance drop is important.
My usual solution is a normal native language with macros to do alot of grunt work (and alot of manual restrictions given to the scripters - coding forms and standards) but then I thought ....
IDEA :
A preprocessor to 'scriptify' a native language to 'dumb down' what you can do with it, to cut out alot of the 'gotchas', to sandbox it in various ways to allow use of the language in a simpler script pseudo code-like way and gain direct use of the good compilation (execution speed/codesize/lack of the 2 tier data translations) and direct debugger usage against the preprocessor-passed code.
The preprocessor would enforce the simplification of the language (search for verboten statement types, program constructs, etc.. Simple example is barf if it sees a reviled 'GOTO') but would still spit out ordinary native langauge to feed further down the build chain (and barf immediately in a readable way at a user who tried to use language features not allowed them).
Libraries could be controlled further (like not allowing use of ones not part of the allowed 'script language' specifications)
I suppose there have been more than a few script languages that translate to native code for compilation, but then you lose the advantages of a direct debug ability.
The problem -- since thereare all kinds of 'script' language features that make them used in the first place - can you replicate the ones required ?? Do many of them really never get used or wind up being source of programming problems so that its better off to eliminate them (selectively restrict them in the generalized precompiler)...
.
