Sorry your browser is not supported!

Does that actually exist? I found that a single line of explanation for every Condition and Action is not very helpful, especially for some obscure conditions like raycastup, or actions like settarget.

It's a pain in the a$$ to understand what something does, and it takes a lot of script attempts and tests.

It would be easier it there were examples and a better documentation like Java API's. Any scripting language has to offer docs to scripters. It's mandatory, in my opinion.

The things are made more obscure from the confusing usage of Actions which use a format like "y=x" and others which use something just like "y" (I'm thinking of settarget which doesn't support variables).

A friendly format would have been something like this, in my opinion:

Scancodekeypressed(Asciicode)=true

or better:

Scancodekeypressed(Asciicode)

opposed to:

NOT Scancodekeypressed(Asciicode)

and so on.

Finally, I don't understand why there's so much things hidden. Simply opening the setuplevel file, shows undocumented uses of the hud functions, with things like hudtype and variables not described in the docs. This is strange.

FPSC is touted as a "no coding necessary" engine. I'm guessing that is at least part of the reason there has never been more than a "one-line" explanation for the conditions and actions. To my knowledge, with the exception of a few member-made scripting tutorials, there is no documentation except what you see in the manual.

It has always been up to those of the community most interested in the fpi language to test and explain the code. There is a great deal of trial and error, sometimes only to find that the particular condition or action has not been implemented in the engine.

Undocumented is an understatement. Welcome to the forum.

Best.

You're right, xplosys, and I've also seen you're the one trying to give others some scripting advices and examples. I think I'll also write a scripting tutorial (a little bit more advanced than the others I've seen so far) but I just thought how easier it could have been for me (a boy that, even with not much talent, studies Science Information) and so for many to use the true potential of FPSC with just a bit of documentation from the authors.

Anyway, being in the topic, I've got a question I'm sure you can answer:

I tried to understand the timerstart function, and I found it's unvaluable when coming to give a class touch to an FPS (flickering lights, time events, time based games). Unfortunately, I think I understood that there's just a global timer, and so (and I checked it putting two scripts using a timergreater check and a timerstart in the same room, with different timings) you can't have two time-based script at the same time. Is that true, or better, is there a way to avoid this issue. Or am I completely wrong and victim of a bug?

The situation in my room was as following:

a guy which looked left and right (time based) and a flickering light. the light started to flicker only when the guy was suspended (killed, in this case).

There is only one global timer so you can't have separate timer-based scripts as one will reset the other.