Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Scripts / Better documentation for API?

Author
Message
socrates
17
Years of Service
User Offline
Joined: 16th Jul 2005
Location:
Posted: 17th Jul 2005 13:34
I've looked at the documentation for the API in the manual on pages 71-76, and most of it is pretty straightforward, but I found a few things that seam to me to really warrant better explainations. For instance, the STATE=X condition. In the manual, it states:
STATE=X | is true when the value stored in the fpi script is equal to x

Ok, but what value? Obviously it is some kind of "state" value, which can also be set with action statements, implying that there are different states, perhaps each with it's own number? Are we supposed to guess what these states are? I'm guessing 0 means dead? I don't know. It doesn't say. It just says "value stored in the fpi script". Aren't all variables "values"? Aren't they all "stored" in the fpi script? Will this only change if I explicitly set the state to X in an action or is the state variable more than just a customizable variable with a fixed name?

I don't know. This is only one example. What I would like is full-fledged documentation of the API (if you can call this an API), fully explaining in agonizing detail what's what. Is there anything like that around? Maybe something a LITTLE bit more thourough than the few pages they have in the manual?

"Who in their right mind would ever need more than 640k of ram!?"
-- Bill Gates, 1981
Merranvo
17
Years of Service
User Offline
Joined: 24th May 2005
Location: That ^ is a Orange
Posted: 17th Jul 2005 16:40
Because you are new I will let you off easier, but don't ask questions like these... It hurt's my head.

First off.. it is FPI, not API.

Second... State is a variable. You put a number in it, and it becomes that number.

Third... PLEASE read up on FPI scripts by reading this fourm and the scripts provided in fpsc before asking anothother question like this.

Welcome to the World of FPI Programming. It is a place to enjoy.

Blasting, Shooting, and Maiming. Aspects of Modern Gamming.
socrates
17
Years of Service
User Offline
Joined: 16th Jul 2005
Location:
Posted: 18th Jul 2005 11:49
Wow.
Quote: " First off.. it is FPI, not API."

API stands for "Application Programming Interface", and is a universally accepted term for the commands relating to a set of commands used for a specific purpose, like scripting FPIs, for instance.

Quote: "Second... State is a variable. You put a number in it, and it becomes that number."

The answer to my question is actually that STATE is the ONLY user-defined variable. I knew it was a variable, hence the "aren't all variables values" comment. WHILE READING DIFFERENT FPI SCRIPTS, It seamed like STATE was more significant, but I guest I was wrong. Anyway, my issue was with the lack of clarity in the documentation and I used that as an example.

So the answer to my original question, if you understood my original question, is "NO, there isn't any more detailed documentation of the API for FPI scripts". Got it.

"Who in their right mind would ever need more than 640k of ram!?"
-- Bill Gates, 1981
Merranvo
17
Years of Service
User Offline
Joined: 24th May 2005
Location: That ^ is a Orange
Posted: 19th Jul 2005 04:33
Actually there are MORE user defined variables then state. Like Activate, you can also use move and raycast to create a thrid variable if you need it, the concept is good but it may create errors.

And API has no relivance to the topic. You are right that it can be consitered API, technically (and technically not, FPI scripts aren't directly processed into the system), but you don't need to change what is already in place. FPI is the ACCEPTED term, we don't need others.

Yes I did read your post. But I think you should take some time to think it though...

:STATE=0:STATE=1
:state=1,plrdistwithin=500:state=2
:state=2,ifweapon=0:state=10
:state=2,ifweapon=1:rotatetoplr,useweapon,state=1
:state=10:reloadweapon,state=1

simple non-mobile Enemy AI.

State is always zero when the script is first run.
State can not change by use of mathamatics

ifweapon has the values 0 1 and 2
0 means that it can not be used
1 means it can be used
2 is unknown, but it appears to be there

plrdistwithin = x
x is 1/100th of one tile.

Most of it IS self explanatory... there are a few commands that give people head aches, but if you take the time to read the scripts and WORKOUT how they work, it becomes alot easier. problem is, most people don't bother.

Blasting, Shooting, and Maiming. Aspects of Modern Gamming.
uman
Retired Moderator
18
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 19th Jul 2005 05:07 Edited at: 19th Jul 2005 05:07
The point is quite rightly that the scripting reference in the manual could well be improved - with more in depth explanations of whats what and how each reference works in practical terms. - This at least for the mass audience that TGC is aiming at with its product, many of whom will be less than a master programmer.

- just like me, duh.

Better manuals are invariably needed for many game engines and asking for such must be a resonable request.
socrates
17
Years of Service
User Offline
Joined: 16th Jul 2005
Location:
Posted: 20th Jul 2005 22:19
I've decided to start a wiki for it. Maybe we can all put are notes there? I think that would be better, IMHO.
[href]http://en.wikipedia.org/wiki/Fpi_script#FPI_SCRIPTING_LANGUAGE
[/href]
Right now, there are just a few of the CONDITIONS and ACTIONS listed. All of the conditions are listed, but not the descriptions for them. I'm taking them directly from the manual most of the time, and adding question about specific commands when I find them to be ambiguous. If you would like, you can add to or change anything in it. It would be greatly appreciated.

"Who in their right mind would ever need more than 640k of ram!?"
-- Bill Gates, 1981

Login to post a reply

Server time is: 2022-12-07 00:26:43
Your offset time is: 2022-12-07 00:26:43