Sorry your browser is not supported!

Alright, it seems to me that there are some missing pieces to our so-called Scripting Manual provided by TGC.

I've taken it upon myself to scavange the source code for anything out of the ordinary, and possibly provide some answers to why some commands don't work.


Let's first take a look at how many Commands there are in the manual as opposed to the actual source, shall we?


In Manual:

58 Conditions

143 Actions


In Source:

59 Conditions

146 Actions


Hmmmm, looks like there's some things that we were not informed of.

1 Condition is missing from the manual, and I just recently ran across it. It is:



Wow, that sounds very useful, especially for puzzles!

I think the reason that this command was left out is because (for some odd reason) they decided not to include the "Use Key" property for zones.

As most of you know, this can worked around by editting the fpe file of a zone, or, as I would recommend, make a new zone and edit IT'S fpe file.

This isn't very dynamic, and I would have LOVED to have a trigger zone with a "Use Key" field just for this specific use. Maybe, with enough begging, Lee will throw in the property for V2 of FPSC Classic. =D


Okay, what Actions are we missing in the manual?

.
.

Found them, and I've given some brief descriptions on what they do.








Okay, that does it for the commands not shown in the manual.

What else is hiding from us?


Well, for starters, let's look at what the manual says about "ACTIVATEIFUSEDNEAR":



No... wrong... who wrote this thing?

The fact is, there is actually a hidden property in each entity called "ifusednear", and it functions exactly like the "If Used" property, except... none of the entities allow you to change this property in the editor.

You can change this property by adding it an fpe file by simply adding:

ifusednear = <name of an entity>

Exactly like we've been doing to alter the if used field for entities that don't have one.

Make no mistake, this command has NOTHING to do with how close or far away the entity is. It might as well have been named "ifused2"

Now, WHY TGC decided to include this in the manual but not provide any support for the property is beyond me. I figured that was the reason they excluded "ANYKEYWITHINZONE" from the manual, but... w/e.


Let's now talk about another command that I've had the ... pleasure... of dealing with:



Now, this sounds very useful, especially for fading in music! Only problem is, it doesn't function exactly like it says it does.

I dunno what the person was thinking when they coded this command, but it doesn't sound like they trusted scripters to know what they were doing, so guess what?

This command ACTUALLY sets the volume anywhere from 80-100... and the value you provide determines where the volume will be in that range.

Let's look at the formula used for this:

80 + (X / 5)

Where X is the value you've given to the command. So if you wanted to mute the music and gave it a value of 0, you've ACTUALLY set the volume to 80.

So, long story short, do a little algebra and you'll find that if you WANT the volume to be muted, you actually have to give this command a value of -400.

This was a big mistake in FPSC, as it prevents users from accurately controlling music volume.

Welp, now that you know what mute level REALLY is, you should now have the control you need.


Next on my list of things to talk about (and this one may just help out those who were trying to deal with 3D sounds) is:



Well, there isn't actually anything wrong with the description, its just that some people may not have noticed this in the manual or may have been confused by it's meaning.

This command will make 3d sounds in FPSC louder or quieter depending on the value you've given it.

The default value of this is "100", or normal volume. If you give this command a value of "200", then all 3d sounds will be twice as loud as they were before. As such, a value of "50" will make all 3d sounds half as loud as they were before.

Sounds like a great command right?


While we're on the topic of sounds, let me make one thing of note on the 3d sounds and the 2d sounds in FPSC.

In the manual, this is what's written:



This .. is .. FALSE!!!

This is what the manual SHOULD SAY:



This is how they actually work. If you were to try and use "3dsound" in a script, you will not hear anything. This is because it IS NOT A COMMAND! The command to play a 3D sound is "sound", and the command to play a sound heard from anywhere (2d sound) is "plrsound".

Keep that in mind.


Next up on my list is a command that just stuck out at me like a sore thumb when surfing through the source.



Well, guess what boys and girls? This command never got programmed. That's right! In the source there is a big "TODO" in the section of code for this command.

From what the manual says, I'd think that this command would function exactly like the "ANYWITHINZONE" command. If this is what you were desiring, then you may want to use that command instead.

Just know that this command never made it out the starting gates.



This concludes my brief tutorial on "Scripting Mis-Mentions".

Have fun, everyone!



The one and only,
~PlystirE~

Hey, thanks PlystirE. Very informative. Although I have been spending all day trying to still figure out "ANYWITHINZONE" and haven't figure it out yet.

Here's what I am looking for. The player is able to activate anything at all. Zones, when player is close to another entity you can do something. However, I want to be able to have an entity, especially a character be able to activate something. I can't seem to come up with a working solution using the mentioned condition. When the character gets close to another entity or when the character walks into a zone.

Here is what happens when I use the "ANYWITHINZONE".


First here is the map:




Now here is the code that I put in the main of the character.



Here is the code that I put in the zone main.



Now the door is a remote door with the name "Remote Door". I put the name of the door in the "If Used" parameter of the zone.

The above code is an fpi file that comes with one of the revisions of FPSC called "zoneanyactivate.fpi". The description states:

Zone Activate if any entity enters it

This tells me that if any entity enters the zone then it will activate it. If you look at the map you will see that the character entity will walk right through the zone towards the player. So, does it work? See for yourself in the following image.



Shouldn't the door now be open? The entity apparently did not activate the zone so that the door will open. I don't get a sound either.

So if this is supposed to work what am I doing wrong? Or am I presupposing that a character entity will be recognized?

Sign me,
Totally confused

Hmmm, the code seems to be correct. Obviously, the character script functions correctly, since he made it over to you.

Since the sound being played by the zone is a 3d sound, try altering it to be a 2d sound (just for debugging purposes) and see if you can hear the sound being played.

I'm thinking the problem lies with the door. Perhaps the door needs you to be closer to it in order for it's script to begin running? If this is the case, you can overcome that by making your door "Always Active".

Sorry I can't be of more help, but that is a rather tough issue you've hit.


The one and only,
~PlystirE~

Plystire,

Is this the extent of commands/conditions mentioned in the manual that are not coded? I thought there were more? I'm going to update the scripting info on my site.


F l a t,

This is something I ran into before as well. Here is something you can try. It won't fix the problem, but might show you a little more concerning it. Place an entity in the room on your side of the zone. Anything will do, a battery, tire, etc. Pick it up and toss it into the zone, and see if the door opens.

BTW, your forum name is a pain to type. LOL

Best.

Plystire in another thread you said:



This is especially true using FPSC scripting

@ xplosys

Two things. First, you don't have to put the spaces in between the characters. When I chose that name they had it set up not to accept a name more than so many characters long without any spaces and therefore it rejected "Flatlander" So I said OK I'll just put spaces in between the characters. I thought that was kind of reflective of being flat as well ... you know .... stretched out. Anyway, you don't have to put the spaces in there. You can also call me FL. I also think you are kidding around anyway.

The second thing is to Plystire as well. I have been doing a lot more testing and have come to the realization that it does not recognize a character as an entity in this case. It does recognize other objects that are in the entity category, however. In all of the testing, just throwing an entity into the zone will not always (consistently) cause the zone to activate. Not sure why that is but then again I didn't write the code to for FPSC. However, if the player carries the entity into the zone it works everytime. Interestingly, if I threw the entity into the zone and it didn't work (opening the remote door in this case); but, I, the player goes into the zone and picks up the entity it will open the door. Apparently there is something in the FPSC code that associates the player with the entity to make it work consistently in that manner. However, if you put, say, a hole, in the floor, and put a room segment underneath (haven't tried it without a room segment) and put the zone in the lower layer; it will work by just dropping the entity into the "hole". It seems to work consistently in this manner. I am only guessing but it might be that if you "throw" the entity it might be traveling too fast for the FPSC code to work. Dropping it in or pushing it into the hole, the entity doesn't seem to be traveling as fast. This is just an observation.

Even though it doesn't work with a character -- thats why I thought maybe the "ENTITYWITHINZONE" condition would work with the character -- I already have a use for this and am thrilled to be able to have it available.

BTW, I created a waypoint into the zone and placed a SciFi "platform" to follow the waypoint. I then tried putting an entity on top of the platform. It carried the entity into the zone but it didn't activate the zone. I saw some possibilities with that but it doesn't work.

I hope this helps some other folks. And thanks for the discussions as it helped me in doing different tests. I was concentrating more on the character entity rather than the other entities.

Flat:

Zones are treated differently than other entities, which makes them rather unpredictable.

I don't think the speed of the object has anything to do with it, because the AI is processed on every frame, and unless the entity went so fast that it skipped over the zone entirely, the speed shouldn't be effecting this outcome.

Zones (On some occassions) are usually Always Active, but I've run into a few that refused to always do what they're told. You might have found one of those. When I run into one, I usually recode the zone, remake it, put it in a different area, change the way i wanted it to work... or try to think of different ways that I can make it work.

According to the code, all entities should be effected by the command. Have you tried standing in the zone WITH your character entity?


The one and only,
~PlystirE~

The fact that the command to drop a weapon doesn't work (pet peeve) is worth mentioning.
This is very helpful.I wish I had this info when I first started using FPSC.

@FredP:

Well, it's not that it doesn't work... it DOES work, actually.

I've gotten the weapon to drop, but the problem is that the entity has already been deactivated and so... physics don't work on the entity (so it'll be floating in mid-air) and the script doesn't work after dropping it (so you can't pick it back up).

Yes, I do suppose this is worth mentioning, and is definitally worth fixing. I've tried to fix it many times before, but the coding behind it extends deeply into the engine itself.


The one and only,
~PlystirE~

Well, it's like a scripter's Christmas here......3 new commands and a new condition to play with.....

I was very interested to find SETTARGETNAME=X as a still live action, I always thought that was removed at V1.04, never to return, if this isn't the case, then Sensei should work with V1.07, (this is the V1.07 source you're looking at, right?)....

Also, ACTIVATEIFUSEDNEAR=X and SOUNDSCALE=X should be very useful, especially ACTIVATEIFUSEDNEAR=X, as now I could have a single control entity deliberating whether to activate 1 entity or another.....

Like this:


....Or something similar, the applications are literally endless....

Yup, there are many applications for these commands, which makes me wonder why proper support for them was never implemented into FPSC.

Having an "If Used Near" property for entities would make the command very dynamic, and having a "Use Key" field for zones would also open up opportunities for the "ANYKEYWITHINZONE" command.


Maybe I can email Lee about it and see if he'd be willing to alter the editor a little bit to help us out here.


The one and only,
~PlystirE~

Hey Ply, could you just clarify these up so I can place them in the next guide edition? Basically a sum up of what works, what doesn't and name corrections. Thanks.

Sure thing, Nicky!

Commands missing from the manual:

Conditions:


Actions:



Incorrectly Documented commands (As well as a corrected decription):




Mis-Named Commands:




Commands that never got programmed (Don't work):





There may be some more, and I just recently stumbled across "MOVEBACK" as not being programmed.


Good luck with the new Guide, Nickydude! It will continue to be the pinnacle of FPSC Referencing and Guiding.


The one and only,

Thank you Ply.

I've also now noticed there are two conditions each having 2 different meanings!

ANYWITHIN = x: is true when any other entity moves within X quarter tiles

yet further on:

ANYWITHIN = x: is true when any entity is closer than X to it

and

ANYFURTHER=X: is true when no within X quarter tiles

(Note that the above is taken from the manual, I haven't made an grammatical errors.)

and, again, further on:

ANYFURTHER=X: is true when any entity is further than X from it

Perhaps it would be time for a complete re-write of the manual as it hasn't been updated since V1.0 and a hell of a lot has changed since then.

Well, here's what the source shows.

The second definition of ANYWITHIN=X is correct.


For ANYFURTHER, though... I don't think either of them can be dcalred as correct. I mean, it has nothing to do with quarter tiles, that's for sure. However, if ANY entity is further than X from it, that'd be mean the only time it would be false is if ALL entities are WITHIN the specified X distance.

Here's my definition for it:




So, it's just the reverse of "ANYWITHIN". It'll be true if no entities are within X of it. It'd be more accurate to name it "ALLFURTHER=X".


Good eye, and thanks for pointing those out.


The one and only,

Thanks for clearing that up.

Ply, would it be possible for you to check over the conditions / actions section of my guide to see if anything is missing or could be explained better? If so I'll send over an advanced copy of the next version.

I'll certainly find some time to look it over.

Can't up an opportunity like this, now can I?


The one and only,

OK, I'll send you an email when it gets nearer the time.

Cool, I'll be looking forward to it.


The one and only,

@ F l a t l a n d e r



I was wondering, perhaps when you throw stuff at your trigger zone it slides under it. It looks like, in the editor, the trigger zones are slightly off the ground, floating per-se.

@ Plystire


I'm having a hard time wrapping my head around the ACTIVATEIFUSEDNEAR=X action. Can you provide a little further explanation, perhaps an example of its use?

THX

P.S. Is this stickied?

ActivateIfUsedNear acts exactly like "ActivateIfUsed"... it just sets a different variable is all. The problem with this is, it sets a property that you can't set in the Editor.

The "IfUsed" property in the editor is where you tell an entity what OTHER entity to effect when you use "ActivateIfUsed". Just like that, the "IfUsedNear" property tell an entity what other entity to effect when you use "ActivateIfUsedNear". But, the "IfUsedNear" can't be set in the Editor, you have to set it directly into the entity's FPE file.

It's basically a command that had potential but ended up being forgotten along the line.


The one and only,

On the note of mismentions, these aren't scripting related, but rather for the setup.ini:



I have no idea what indieditor is, might be something completely not useful or something but the godmode caught my eye. I can't imagine an external cheat being very useful though.

Also kinda interested by this one:


And I'm curious about this one aswell:


I've got all of about 5 seconds to finish this post so I can't go digging now but I will when I get back. I doubt they'll be terribly interesting but you never know...

EDIT: Squeezed some time anyways

All of those but godmode and ingorefastbone are only referenced where the variables are initially defined and when the setup.ini is read. So they're useless.

Godmode just lets you press "i" to get 99999 health even during a built game.

Ignorefastbone apparently ignores the fastbone shader...the only reference to it was what the comments looked like a speed check thing, although if ignorefastbone is set to 1 it might ignore it all together and let normal lighting take over. I'll mess with it later.

On a side note - love this variable name:


Broken up that's t-this-ent-obj-shall-be-textured