oosyrag's Recent Forum Activity

  • Yes, but I believe the ram usage for a text based object like an array is generally negligible. At some point you will not be able to hold an infinite amount of data in memory, but that should be given.

    You're more likely going to run into cpu limitations first when trying to process the all the data in huge arrays, which again emphasizes minimizing the scope of whatever you are doing to only what is relevant at any given point.

  • Normally I maximize the use of instances, given that all the instances of the object in question logically have the same scope or function as far as events go.

    However, if using all separate objects works and makes it easier for you, there is no reason not to unless you can actively notice or measure a performance difference.

    I don't think 100 objects would have any measurable impact on performance. On the other hand, slider bars objects are html form elements and those don't always play by the rules. Anyways I wouldn't bother worrying about performance.

    I'd go crazy building events for 100 separate objects if I could do it just for one instead though. Then again, you've got families to make up for that as well. This engine gives you a lot of flexibility to work in whatever way you feel most comfortable.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hmm if you need to keep track of modifications to the noise, then you might want to have it in an array after all. I personally would still approach it by recording only what is necessary rather than everything at once though.

    Again, you could break it into chunks, Minecraft style, where you keep an array instance per chunk and have a system to keep track of the relative location of each array/chunk

  • I am filling one z axis of the array with perlin noise values so I have a feeling that if I broke the map into many arrays that the noise wouldn't be so perliny on chunk edges

    With the same seed, as long as you're consistent with your coordinate system, there should not be any seams at whatever chunk edge you define.

  • Well I can't answer the array size limitation question... but I can say normally I wouldn't store what is I'm assuming your entire world's procedurally generated values in an array to begin with. You should be able to look up a value at any given position for a particular seed any time you want, so just get the relevant values as you need them from a function.

    Alternatively, if you must have the values in an array, you can split your arrays into chunks (can still be a single array object, with multiple instances). Use x/y instance variables to keep track of the relative position of each array, and have each array's size be whatever you're comfortable with that doesn't crash.

    I'm just guessing here, but I think the array size limitation is based on your system, so I'd stay well away from that threshold if I were you, since your end users' systems might not be as capable as your own.

  • If you mean you have a JS variable you need to get from the parent page, since HTML doesn't have variables, you would right click in an event and choose add script, then 

     runtime.globalVars.myGlobalVar = variableFromWebsite

    Assuming you have a global variable in your project called myGlobalVar, and your JavaScript has a defined variable called variableFromWebsite. This would set myGlobalVar to variableFromWebsite, which you can then use in your project as normal.

    See editor.construct.net for more examples of how to integrate JS in the event sheet, via local variables. There is also a construct.net/en/forum/construct-3/scripting-51 forum you can ask questions on with people much much more familiar with JS than I am.

  • The "Pick Nth Instance" system condition works as described, picking only out of currently picked instances. So we kinda do already have it.

    The object(n) expression does not seem to care about picking, but can reference the full instance list of that object.

    The suggestion is about referencing UID in an expression. But its probably more of a quality of life niche case type of thing, as picking by UID can already be done by condition as well. Might save a few events here or there. The example Tacker gave could simply be done with a For Each player instead, or add an instance variable to narrow the scope by picking as normal.

    The ability to specify only picked IID's (they call them SOL ID?) in expressions might facilitate the whole "how to I refer to and manipulate two instances of the same object colliding or otherwise interacting" without resorting to the common object and family workaround though! Maybe. That would be the fireball part of Tacker's example, and that's where I would be really interested. But that is what Ashley dismissed as already existing, which doesn't seem to be the case, so it's probably good to call attention to it.

  • I believe you want to use the new(ish) "Tag" property of solids, and the associated "Set solid collision filter" action of sprite objects to determine what solids those sprites can interact with.

  • Yes... you would just do exactly as you said. On clicked on level 1, go to checkpoint 1. Did you run into a problem doing so?

    You can set the destination checkpoint as a global variable upon selecting the level, and on start of layout position your player character based on that global variable.

  • Huh. I always assumed object(iid) let you use values from any object, not just the ones that were picked (which is what is currently happening). Also I didn't see the manual specify that IID list changes based on picked instances (then non picked instances wouldn't have an IID during picking?). Clearly IIDs can get changed as instances of any given object get created and destroyed, but I didn't think that would happen during picking.

    But based on Ashley's comment this doesn't seem to be intended... Maybe just slipped his mind about how index based expressions were set up? Just checked the earliest version of C3 that still worked and C2 and the current behavior is consistent across them, so changing this would decidedly be a breaking change... and the suggestion was talking about something else anyway.

  • Or even better, you can use a tiled background the same size as the viewport on a zero parallax layer, and simply set the Y offset to -1*minScroll every tick.

  • Even though the layout in the layout editor is small, it is still actually scrolling at runtime. So you would just need to create the next background object in the proper position (every multiple of background.height), based on the viewport position (you can use the minScroll global variable for this).

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies