joeykid6's Forum Posts

  • 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?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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!

  • I agree. Ever since I stumbled upon it, I have been recommending C2 to anyone who will listen.

    Please don't get discouraged you guys!! You are making groundbreaking software. At the risk of sounding hyperbolic, I think that when C2 gains widespread use it could be one of the landmark events in the history of video games. This is the software that has the potential to bring game design to the masses.

  • Hi Carminielloz,

    I'm not totally sure I'm answering your question, but...

    Setting Fullscreen in Browser to "Off" means the game window size is set by the "Window Size" property in the Project Settings. You'll find it a couple of lines up from the Fullscreen in Browser property when you click on the main project folder.

    You can set X and Y dimensions.

    Hope this helps!

  • You might try storing the text as JSON. You could use this plugin to move it in and out of C2:

    http://www.scirra.com/forum/plugin-load-json_topic50331.html

    I think there's also some native support for JSON in arrays as of R87.

    To make the data easy to deal with, you could create a database and have it spit out text chunks in JSON format. If you use something like Ruby on Rails...

    http://www.rubyonrails.org

    ...you could create a basic CRUD app to handle the data pretty quickly. When you're ready you could output the data into .json files which you could store in a folder alongside the C2 code. Or, if you can store the database online, you might be able to access it with AJAX requests. I don't know much about C2's AJAx capabilities, though.

    There's some initial overhead with this method, but it would make data entry and keeping track of the structure much easier.

    Edit: There's also XML support in R87, and Ruby On Rails will spit out XML as well. XML has lots more overhead than JSON, though.