There have been a fair few threads about scripting, so I'm just going to give you a quick overview of how it works at the moment - from what I have heard from Lee/Mike. It is quite possible that this is subject to change in the future. (Lee/Mike: If I have made a mistake, feel free to correct me.)
All scripts are stored in .FPI files which can be associated with certain entity actions. For example, an enemy would have one for when it is created, a main one which it runs through all the time, one when it shoots the player, and one which is run when it is destroyed.
FPI syntax is very basic, consisting of a series of IF-THEN-type statements (using ":" instead of "IF" and "THEN"). In an IF statement, you can test the value of a variable, and set the value of variables or call a function as a result:
eg:
:state=0,plrdistwithin=100:state=1
If run on an enemy, this script would set "state" to 1 if the player was withing 100 units of the enemy.
The flexibility of FPI scripts is mainly limited by the "functions" and variables that you can access within the IF statements, hence there is plenty of room for expansion. If it turns out that users of the Early Adopter (EA) release want more functionality or access to more engine data, then it may be possible for TGC to add it for release.
As far as I understand, FPI scripts are converted to a kind of bytecode, and any media referenced in them is loaded when the level is loaded. This makes running the scripts very fast. In order to keep the performance as fast as possible, FPSC assigns different priorities to different entities depending on their distance from the player, and other factors. So an entity on the other side of the level may only "think" once every 2 seconds, whilst an enemy busy shooting you is "thinking" all the time.
BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.