Author Topic: PChase doesn't seem quite right  (Read 4144 times)

0 Members and 1 Guest are viewing this topic.

Offline Cloudee1

PChase doesn't seem quite right
« on: November 25, 2015, 10:13:14 PM »
When using PChase to have an actor chase after ego, and ego is on the move, then the other actor seems to stutter. When ego stands still, the other actor moves fluidly. It seems that when the ego is moving then the other actor is to busy trying to figure out where to go than actually go somewhere.

Code: [Select]
(offerGuy:setCycle(Walk)setMotion(PChase gEgo 20 offerScript))

As a side note, PFollow seems to suffer from the same stuttering issue while ego is on the move. Something I didn't realize before now, PFollow does not take the cue at the end.

Code: [Select]
(offerGuy:setCycle(Walk)setMotion(PFollow gEgo 10)) // correct
(offerGuy:setCycle(Walk)setMotion(PFollow gEgo 10 offerScript)) // oops error

Not that there is anything wrong with that, just didn't know.


Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline troflip

Re: PChase doesn't seem quite right
« Reply #1 on: November 25, 2015, 10:20:30 PM »
With PFollow, the client is constantly following the target, so it never reaches the destination. Hence no cuee. The docs are live ;-) : http://scicompanion.com/Documentation/Classes/PFollow.html?highlight=pfollow

Although I guess they don't spell it out explicitly.

It's possible there's been a decompilation bug with PFollow/PChase, I'll have to take a look and see if I can repro this. Thanks for bringing it to our attention!

[edit:] Hmm, I'm not seeing any stuttering... I actually used this as I was writing a tutorial for Motion classes. It doesn't seem to be any different when the ego is moving or not. What does the stutter look like?
« Last Edit: November 25, 2015, 10:28:23 PM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Cloudee1

Re: PChase doesn't seem quite right
« Reply #2 on: November 25, 2015, 11:23:42 PM »
Here you go. You will want to open script 35 and start from there.

After pulling into the screen, ego will hop off the skimmer and a guy will appear from the north. That's the guy.

Simply walk around and you should see the issue that I am referring to.
« Last Edit: November 25, 2015, 11:46:30 PM by Cloudee1 »
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline Cloudee1

Re: PChase doesn't seem quite right
« Reply #3 on: November 25, 2015, 11:41:35 PM »
Those are some pretty nice docs you've got going there Phil. I am assuming that you have a template game that you have been working on as well. The reason I say that, I noticed this description of aimtoward that claims to be a public procedure in main but I sure can't seem to find it in there.

http://scicompanion.com/Documentation/Procedures/AimToward.html
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline troflip

Re: PChase doesn't seem quite right
« Reply #4 on: November 25, 2015, 11:52:08 PM »
Ugh, yeah, that stuttering is awful. I can't immediately see why it's happening.

If you just create a basic new room and make an actor follow the ego, I suspect it won't happen. So something in that room is causing it, presumably.

Those are some pretty nice docs you've got going there Phil. I am assuming that you have a template game that you have been working on as well. The reason I say that, I noticed this description of aimtoward that claims to be a public procedure in main but I sure can't seem to find it in there.

http://scicompanion.com/Documentation/Procedures/AimToward.html

It's proc0_8 in your Main.sc. It has a name now :-)
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Cloudee1

Re: PChase doesn't seem quite right
« Reply #5 on: November 26, 2015, 12:11:59 AM »
So it was apparently the large views. Ship1, Ship2, and the doorway. I used them because it turns out I was to lazy to fight with the priority and the polygon combinations to get it right. I hate it when things don't line up with the priority bands lol. Anyway, with a small tweak I got the stutter to go away.

I changed them from Prop's that were init'ed to use addToPic instead and the stutter has gone away.

However if I remember correctly, I can now no longer use a noun property on them, only when they are init's. So I will have to go in and add a couple of features so that I can register clicks on them now.
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline Cloudee1

Re: PChase doesn't seem quite right
« Reply #6 on: November 26, 2015, 12:22:28 AM »
By the way,  that AimToward... that kicks ass. I went ahead and changed the procedure name in my main script to match. Then I made use of it in the very script and scenario that we were looking at.

Code: [Select]
(case 0 (offerGuy:setCycle(Walk)setMotion(PChase gEgo 20 offerScript)))
(case 1 (send gGame:handsOff())
        (send gEgo:setMotion(NULL))
        AimToward(gEgo offerGuy offerScript)
)
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline lskovlun

Re: PChase doesn't seem quite right
« Reply #7 on: November 27, 2015, 10:01:08 AM »
I changed them from Prop's that were init'ed to use addToPic instead and the stutter has gone away.
You could also have called stopUpd on them.

Offline Cloudee1

Re: PChase doesn't seem quite right
« Reply #8 on: November 27, 2015, 09:39:43 PM »
Thanks for that Lars, that does indeed work as well. This is the approach that I am going to use as it restores the ability to set the noun property of the instances rather than going through and creating features taking up the same space.

Code: [Select]
(ship1:init()ignoreActors()stopUpd())
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.137 seconds with 22 queries.