Great plugin and behavior Rexrainbow! Thanks for all of your excellent work.

I'm writing this quick note to save others some grief. I spent a couple of hours struggling with the SID mode of the nickname behavior before I realized that all nicknames must be passed as strings, even in SID mode (where the variable returned is a number). So, to call the SID properly, you need to wrap Family.Nickname.Nickname in a str() function or it won't work. Of course, once I realized this, I checked the API and of course discovered that Nickname is listed as a string.

Live and learn.

The green platforms work fine (as they should) on my machine. The blue platform (which should not work correctly, since it's using standard sine behavior) continues to be broken when jumping.

Are you experiencing something different?

Here's a quick example which I think does what you want:

http://dl.dropbox.com/u/47015043/construct2/radar-example.capx

The example changes opacity rather than visible/invisible, just so it's easier to see what's going on. I've also pinned each radar instance to a sentry object, but you could just as easily use the radar without those.

Here's an example I put together which I think does what you want:

http://dl.dropbox.com/u/47015043/construct2/sentry-example.capx

It's for a top-down configuration rather than a platformer, but the principles should be the same.

It uses invisible sprites pinned to the sentries which act as radar/sight. I've made the sprites visible in the example so it's easier to see the effect. Also, I've only used 8 collision points in the radar, but you could use more to make it more like a circle.

I just posted an example in another thread that I think is similar to what you're after.

I suspect you may need to switch your "on collision" condition for an "is overlapping another object" condition.

edit: actually, Brent's answer makes more sense.

Here's a quick example of how to get individual enemies to respond using an invisible sprite for range of sight. I've kept the sprites visible in the example so you can see what's going on:

http://dl.dropbox.com/u/47015043/construct2/range-of-sight-example.capx

Welcome!

I looked at your capx, and I'm thinking that instead of testing for distance using the distance function, you might pin an invisible sprite to each glob to simulate each one's range of sight. You can make it as big or small as you want.

Whenever the player collides with it, the individual glob it's attached to will react by attacking or fleeing or whatever.

Is this what you're after?

http://dl.dropbox.com/u/47015043/construct2/pinned-container-example.capx

Hold down the space bar to attach, then tap space again to detach.

Thanks R0J0Hound and Ashley. Sorry to waste time on something that's already available. I swear I did actually read the performance tips section a while back. Oh well, I'll read more carefully next time.

Hi All,

I tried to find this in the forums, but no luck...

I'm trying to get a better sense of how imported images perform at runtime based on size. I'm not talking about filesize or using different image formats or compression, but strictly height X width in pixels.

Ashley has already given me a great explanation of how images are converted to PNG-32 for use in the editor, and then can be exported to PNG-32, PNG-8 or JPG for final projects. What I'm after now is a best approach to sizing (height, width) an image for import into C2.

So here are three cases where an image is imported into a new sprite object:

1) A 128x128 image is imported and used at full size in the image editor and layout

2) A 256x256 image is imported, then immediately resized in the image editor to 128x128, then placed in a layout

3) A 256x256 image is imported, then placed in a layout, then resized in its object properties to 128x128

Can anyone tell me what the runtime differences are (if any) between these cases? I'm asking because I would expect case #1 to offer a performance benefit over #2 and #3. I would also think maybe there's a performance benefit to #2 over #3. I say this because I'm thinking that the larger image is stored and used at runtime in case #3, but not necessarily in cases 1 and 2.

It would be useful to know what the differences are between the cases (and if there are specific or general performance benefits).

Basically, If I have to, I'll get all my artwork down to the smallest usable height and width before I import it into C2, but it would be nice to know whether that's required.

Thanks for any help, and as always, thanks for a great product and great user community!

Thanks for the quick reply, Ashley! This is a helpful summary of the format issues. I should've tested some actual exports before I posted. I will try that shortly to get some more data.

Specific to the sprite strip importer: can you say quickly what it does to the strip during the import? Is it slicing it into pieces and resaving individual files for every cell?

Hi All,

I haven't found this information in my searches of the forums, so here goes...

I have been using the "import sprite strip" function because it's a quick and easy way to get animations into C2. Up until now, I haven't thought much about its impact on project size.

I have the same sprite strip in 2 different formats, PNG-8 (150Kb) and JPEG (65Kb). The strip is 6 cells long. I have tested importing each format into C2 using "import sprite strip" and have gotten new estimates of project size that don't make sense to me.

When I import the PNG-8, the project size estimate increases by 400Kb. When I import the JPEG, the project size estimate increases by 600Kb. This is a larger increase than I was expecting. Also, it seems odd to me that the JPEG strip, which is smaller, would increase the project size more than the PNG-8.

So, here's my question: What is the exact process when a sprite strip is imported? Specifically, what does C2 save besides the original sprite strip?

Knowing this would help me to decide whether to import the frames one at a time.

Thanks so much for any help, and, as always, thanks for a wonderful tool in C2!