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 / Conditions out of state

Author
Message
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 16th Feb 2011 23:35 Edited at: 16th Feb 2011 23:49
Link
I have a problem with conditions out of state. Let me explain what I mean. Conditions like ALWAYS or WAYPOINTSTATE without a STATE condition in front of it. It seems like its, unstructured programming. Kind of like basic with a lot of goto’s. I have found here on the forum quite of few scripts that use the ALWAYS condition and found them to work better by changing them to a STATE condition.

I have been toying around with waypoints and come up with this little script. It’s not much but I think it a good beginning. The character will remain still until it sees the player. Then it will start following the waypoint until it reaches the end and stop. By adding to the script the possibilities or endless. Correct me if I’m wrong (and you probably will) but I think this will give you much more control. So without further ado here’s the script.



Put the script in your FPS Creator\Files\scriptbank\people folder. Attached is the fpm file i used to test this.

BTW: Please be gentle with me. I have been programming many years. But I am new to FPSC Scripting. Oh it would appear the plrcanbeseen condition initializes true.

Thank you.

Attachments

Login to view attachments
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 17th Feb 2011 23:48
Link
Using or not using states is not unstructured programming. Just as with programming, if you can achieve the same results with or without an "if" check, you would normally go with the route that requires the least amount of code.

In FPI scripting, a state check is used when that line should only be used during a particular moment in time that is tracked through state changes. If the script should be performing this line regardless of the state, then you would not use a state. I'll use the stock waypoint script as an example. There is no state check for the waypoint code because the character should be following and reacting to the waypoints no matter what state the script is in.

It's up to the scripter to determine if a state check is necessary. Personally, I try to achieve as much as possible without relying on states. I always look to see if the same result can be achieved without the use of states. To me, using a state where it's not necessary is the equivalent of programming with "if (true)" which is just a waste of code.


Regarding your script, the value given to "plrcanbeseen" is not a 0 or 1 type deal, it relates to the vertical viewing area of the entity. Perhaps if you just left the value off it would react better?


The one and only,


Only those who sow the seeds of their desires will reap their benefits later.
However, I have seeds of my own to tend to. I don't have time to be someone else's watering can.
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 18th Feb 2011 02:53
Link
Thanks Plystire, I appreciate your time. You have been scripting a lot longer than I. Suppose it really doesn’t matter. Just depends on what you want your script to achieve. So I will remove what I can from the state check and see if I can get it to work that way. As for plrcanbeseen, don’t fully understand what you’re telling me. But by my logic it seemed like I had to make sure the player could not be seen before the plrcanbeseen to make it work.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 18th Feb 2011 06:03
Link
Ah... I thought there was a "plrcannotbeseen" condition. Not sure, haven't read the manual in a while, lol. But the value given to the plrcanbeseen condition is not for "can or can't", it relates to vertical sight of the entity.


The one and only,


Only those who sow the seeds of their desires will reap their benefits later.
However, I have seeds of my own to tend to. I don't have time to be someone else's watering can.
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 18th Feb 2011 06:38
Link
Actually I’ve been working on the script some more. Here’s what I have so far.



Still trying to make it so that when plrcannotbeseen to stop and turn around at the beginning of the waypoint.

Thanks.
Back to top
Profile PM Email
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 19th Feb 2011 00:16
Link
Flatlander just sent me the code behind the plrcannotbeseen condition and I remembered how intensive the "plrseen" conditions were. I think it would be more optimized if you were to mix plrdistance (not intensive) in there, so that you are only performing "seen checks" if the player is even close enough to be seen.

Good luck with your script!


The one and only,


Only those who sow the seeds of their desires will reap their benefits later.
However, I have seeds of my own to tend to. I don't have time to be someone else's watering can.
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 19th Feb 2011 03:04
Link
That sounds like great idea, I'll give it a try, And post my results.

Thanks again.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-24 12:15:09
Your offset time is: 2024-11-24 12:15:09