Couple more questions, :P

Kamazar

I set up a couple attributes that tracks the position for a door for a couple NPC actors to accelerate towards. Apparently, since the screen wraps, they decided just going to the left instead of to the right would be quicker. So I had the screen wrap attributes set to false. But now, they bravely venture off into a mysterious abyss of which there is no return. I can't set-up (ugly and annoying) invisible walls because they'd still accelerate in the same direction. Shouldn't no screen wrap mean that all the actors are confined to the playing field?

1) How can I get them to accelerate towards the door the way I want them to, moving to the right instead of the left wrapping to the right.

2) Can I do away with the wrapping altogether so that actors just bounce of the way? I've thought about changing X and Y velocities to 0, but that takes away any bounce.

harrio

what's cookin,

hey k, are you using a static scene, meaning is everything in the window scene? if so, and this may sound corny, but, you could just extend the size of the scene outside the window, on side you don't want them to go. that way, the shorter distance will be the direction you want them to take.

i admit, it's a hacky solution, but it might work. til you find something better.

Kamazar

The part that bugs me is that my gaming involves blowing up blocks making them fly everywhere. Where's the fun if they just fly off the screen never to be seen again? I guess I'll have to set-up invisible walls, which is really, really annoying. GS devs, if you're reading this, I am angrily shaking my fist as you! Thx, harrio.

CodeMonkey

Could you explain why adding wall actors to restrict movement off the screen is annoying? It would really help me understand the thought process of everyone who thinks that way, and whether a feature needs to be added.

I thought it would just be simple enough to add an actor, make it non-movable, add and resize 4 of them as a frame around the camera view, and give any actor that needs them the collide behavior to hit the wall.

Kamazar

To me, it's a slight OCD thing more than anything. I'd rather have everything streamlined and optimized with a couple simple rules instead of changing a scene's size and adding wall actors. It makes everything simple and cleaner, takes up less space and processing power, and saves me 15 minutes of boring, monotonous clicking and dragging. Just my opinion.

jhaas

Ever try coding objective C with the Apple SDK? GS in it's current form is 100 times simpler.

We are fortunate to have the tools we have so early in GS life cycle. Rather than burning oxygen on what isn't there - I'd hope the GS folks focus on getting the commercial version ready. We can all look forward to new features later.

ktfright

+1

harrio

what's cookin,

i'm afraid i stand on both sides of the fence here...yeah, i know, so brave. i agree with jhaas and kt that we are fortunate to be in on the ground floor of such a great and potentialy profitable piece of software.
but, my ocd heart is with kamazar. especially, because this app has not yet reached maturity, as it's version number would indicate, it's in our best interest to optimize any way we can, and to teach others who don't even realize what optimizing is, how it can benefit them. and since they hope to attract novice as well as experienced programmers, these types of issues are going to get brought up and hopefully hammered out over time.

i am most glad that codemonkey asked the question that he did. it shows that they are paying attention to us and seeking our thoughts as developers, wether we be novices or not. that is encouraging to me.

i hope to see us all make each other better. and i hope to hear of the app store success story of someone from this forum, whom i can tell people in the future," yeah, i knew them way back when..."

Kamazar

All personal preferences and opinions aside, Harrio's solution didn't work. I doubled the width of the scene to the right, and the "runner" is still determined to make the great screen warping journey of nearly 960 in length, opposed to the 480 route. I could reprogram the actor as a bandaid solution, but this might cripple me a little in future level development.

CodeMonkey

ok. I think I got something for you. So the way I read it, your actors are using an accelerate towards behavior to the door. And the door is probably changing position or the actors are already moving away from the door.

So because they are moving away from the door, it is not that they are accelerating towards the door and using the shorter wrap screen direction to get to it(its not that smart without adding behaviors/rules to do that on its own), it is more that the acceleration you gave it was not enough to overcome the velocity to stop it from passing the wrapping border and accelerating the door.

So you could give your NPCs the rule that if their position is greater/less than or equal to some numbers representing just inside of the borders of your view, then to change its linear velocity to 0.

That's my guess.

MillerEP

Just a thought, but maybe you can have your actor use a "move to" or "accelerate towards" method, set within a timer of say every 0.2 seconds or something so that it is constantly reassessing itself and moving towards the X,Y coordinates you have hard-coded in where the door is located. If the door is moving like CodeMonkey suggests than have the door have 2 "Change Attribute" settings where it's in it's own timer constantly changing "Door Position X to self.position.X" and "Door Position Y to self.position.y" Hope that helps.

Kamazar

Or it could just just be that it's acceleration wasn't enough to overcome the friction of going up a slope... hehe, god I feel stupid *groans*

harrio

join the club...im the president.