oosyrag's Recent Forum Activity

  • A local variable/number/value is not normally held in memory outside of the event block it is used in, so yes it resets to 1 each time. This is a key property of how local variables work as opposed to global variables. Note that this can be overwritten with the "static" option set, as described in the manual.

    construct.net/en/make-games/manuals/construct-3/interface/dialogs/event-variable

  • When a return type (when creating the function) and value (return value action) is set, the function can be used as an expression, where it will return the return value when used.

    = 5!

    = 5 * 4 * 3 * 2 * 1

    = (5-0) * (5-1) * (5-2) * (5-3) * (5-4)

    Where n=5 and loopindex is the number of times the loop has repeated, starting from 0. Each iteration of the loop is multiplied by the result of the previous one, stored in output. We're starting with output=1, so the first iteration of the loop is 1*(5-0) (1*n-loopindex), which results in 5. The next loop will be 5*(5-1), and so on.

    Once the loop is complete, it then takes output and makes it the return. The return is then returned to the expression that we typed earlier and inserts it into the parameter parenthesis, so that it basically says "Set result to Function.Factorial(120)". return is then set to whatever is inside the parenthesis.

    To clarify, it doesn't really replace and insert into the parenthesis. The number in the parenthesis is the parameter used to run the function. The entire "Function.Factorial(5)" function, as an expression, equals (or is replaced by, if you want to use that wording) whatever is set as the return value inside the function.

    So in the end that action is in effect "Set result to 120". Note this is different than "Set result to Function.Factorial(120)", which would be... a very big number.

  • That's what layers are for. There are system conditions to help you handle and manage layers.

    You can even use a dedicated event sheet for ui that is included on other event sheets for other layouts.

    Global layers can be used so that you don't have to recreate them in multiple layouts, and only need to edit the base one once to make changes.

    Otherwise I'm still not quite sure what the problem you're trying to address here is.

  • You use as many layouts as you need that makes sense, and you put your ui on global layer(s).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • My problem is I can't seem to find a system option for if the boolean hungry is true or false to add the follow up commands.

    You have found the system condition already, as it is being used in event 30 to test if true. So what's your question? If it's how to test false, right click the condition and select invert.

  • construct.net/en/make-games/manuals/construct-3/system-reference/system-conditions

    Is boolean set

    Test if a boolean event variable is set to true. To test if it is false, invert the condition.

  • Of course it depends on your target device, but modern devices will generally cache graphics memory into storage now so there's not much of a hard limitation for overall memory use. Generally speaking, the lower the better for performance, as much as possible. There is the 4000ish pixel limit to width and height for any given sprite enough.

  • No, the list box is a browser element, which uses rasterized text.

    You can try to recreate the listbox functionality with sprite/spritefont objects instead.

    Edit: There may be a way, to export the entire list item/word as an image, and use that as a css background image for the list item.

  • If you don't want to destroy/remove the button after fading, add a condition to the button on clicked event to check if opacity is greater than 0.

  • The manual pretty clearly states "If different objects use different values, then the Pathfinding behavior must generate multiple obstacle grids in memory, and pathfind along them separately."

    For starters, the cell border size (what I'm assuming you're talking about regarding padding), does not have any affect on the actual pathfinding grid itself at all. So if you take that out of the equation, it should be clear enough that a 32 grid size is not going to be the the same as a 31 grid size.

    As for which grid used when finding a path for a particular object, its simply one that is defined by the pathfinding behavior properties that are attached to that same object.

    While I'm not sure if rewriting the manual entry would help someone understand these things any more than it already does, I do think an in editor visualization sure would help a lot.

  • This sounds like a bug, and will probably be fixed shortly if a proper bug report is made. Or maybe after the holidays anyway.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

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

22/44
How to earn trophies