Sign in or 
Location: Sharendipity Discussion Forum
Discussion: Are Collisions broken?
Category:
Discussion Forum /
General Discussion
Share this
Showing 8 posts
JRsays |
|
greg.tracy |
1. RE: Are Collisions broken?
Jul 16 2009, 11:15 PM EDT
Can you post an example? The example I just created worked fine. In the following application, look at the behavior defined on the red circle...http://games.sharendipity.com/assets/3081/ Do you find this valuable? |
|
JRsays |
2. RE: Are Collisions broken?
Jul 17 2009, 1:50 PM EDT
Here's the quick sample... which I've tweaked in a few different ways to try to get the collisions working - making the colliion behavior sit on the "myguy" rectangle, or the "bigball" or the "world"...So it's in some simple state now with the same behavior you had on your sample... http://games.sharendipity.com/assets/3096/ But - I notice a "problem" (upper left message" "remote behavior 3095 require recompilation" - and when I "compile all" it doesnt seem to help. Thanks or responding ! JR Do you find this valuable? |
|
greg.tracy |
3. RE: Are Collisions broken?
Jul 17 2009, 6:24 PM EDT
There are multiple layers to the onion here.... I will try to highlight how you can avoid mistakes going forward and where we need to make improvements and in some cases fixes on our side. 1. The primary problem was in the definition of the behavior itself. Anytime you share a behavior that has a reference to "this" in its logic, you must define the "descendant type" so we can determine what "this" is the next time it is referenced. When it is a local behavior, it's easy, but when it is referenced remotely, we can't tell what someone else may use the behavior on. In your case, we had no idea what "fill color" referenced. If/When you want to share a behavior like this again, you can set the descendant type by clicking the "+" sign at the top of the behavior builder. You usually want to pick 'Actor' for collision related behaviors. I recognize that this isn't obvious... We can improve the workflow by requiring you to set the descendant type before sharing. I've fixed your behavior already so this should be working for you now. 2. There is a bug when you access specific object instances in the collision filter. We weren't aware of this and are looking at a fix now. However, since you've defined a class for your actor - "badball" - you can reference that instead. Just drag the purple class reference to the right hand side of the filter.... "When [this] collides with [badball]" The actor references are on the 'actor' tab inside the behavior builder. I have not changed this in your behavior so you'll have to do it until we fix the bug. Do you find this valuable? |
|
JRsays |
4. RE: Are Collisions broken?
Jul 17 2009, 8:45 PM EDT
I think I get it - but some weirdness persists...1 - The "destroy my guy" behavior is now disabled - I can't select it to see/edit it - and in the Class - I can see the name, and select it, but can't edit it (the "edit" button is disabled when it's selected). 2 - There are now 2 entries for this game when I click "open" - but they look the same... and have the same base URL (aid=3096) And one further question : I didn't know I shared that behavior - it sounds like your solution for defining a descendant type was due to the fact that this was a shared behavior. I didn't intend to do that... I'll keep trying - but please tell me if you think it's too early for this new flash version and I'll back off and wait for v1.1 ;) BTW - the way I found this was due to the spreadsheets integration. That's one of the things I *really* want ot understand how to create! Thanks for sticking with me on this JR 1 out of 1 found this valuable. Do you? |
|
greg.tracy |
5. RE: Are Collisions broken?
Jul 17 2009, 11:21 PM EDT
The editor has a lot of power and depth to it. That's its strongest asset. However, it presents several workflow challenges that we're working through. It takes a couple of iterations to get the presentation right so the power is not only accessible but easier to understand. These conversations are very helpful for us to get there. I would say that it's NOT too early for you. We have lots of great content getting created right now. Granted, there are gotchas that we need to document until they are addressed, but there really aren't many bugs that put you in a bad state.1. It isn't disabled actually... it's grayed out because it's remote (shared) and it was added that way. To edit it, you should access it via the explorer. Just go to the behavior tab and you'll have access to it. 2. I noticed there were two copies and assumed you did a save-as at some point to branch it. However, they do not have the same ID. One is 3096 and the other is 3063. You're right that the descendant type solution was only required because it is remote. In general, it will probably be pretty rare that you'll share behaviors. Especially the ones that reference local objects as yours does in the contact filter. Note that if you use the "Save" option in any of the components - like a behavior, method, or actor - you are saying "make this remote". If you want to keep the changes local, just use the "Ok" button in those builders. Do you find this valuable? |
|
JRsays |
6. RE: Are Collisions broken?
Jul 20 2009, 6:05 PM EDT
So with a little more playing around I found (i think) that collisions really only work (without a descendant type) when using the object class reference for both actors in the behavior test, rather than the actor instance itself... but then to use the actor instance when changing properties. I tried a few combinations and never using any remote/shared objects or behaviors (started from scratch). Does that sound right?
Do you find this valuable?
|
|
greg.tracy |
7. RE: Are Collisions broken?
Jul 21 2009, 10:55 AM EDT
Instance references are supposed to work in the collision filter. We've fixed that and should get the upgrade posted soon. Regardless of the references you use in the filter, the most optimal way to access the object's properties is to use the "Event" reference in the behavior builder. You'll find it on the "other" tab inside the values view. This gives you direct access to the details of the actual collision that caused the behavior to fire including the objects involved in the collision. Do you find this valuable? |
