1StepCloser's Forum Posts

  • Here's another test of the same situation but with a more obvious true condition. However, the presence of the dictionary checks prevent it from running. As soon as I remove the dictionary checks it works. Am I misunderstanding OR in this context? From my understanding if any of the conditions in an OR stack is true the event will proceed, however this does not appear to be the case in this situation.

  • When there is only one instance of an object isn't picking the instance based on one of its values the same as comparing the value (in terms of condition check outcome)?

    Even if it isn't the same, the fundamental confusion is how picking an instance (even if failed) would prevent the OR setup from running if the other condition is always true. Are there situations in which the condition you place in the OR setup can disrupt the condition check of the other, always true condition?

  • I've run into what appears to be another odd issue with condition setup, but maybe I'm missing something glaringly obvious this time?

    Doesn't Work

    Works

    The compare dictionary value condition does not seem to work properly here unless I'm missing something obvious, as these two should be the same check using different means.

    Note that the itemToBuy = "forge" is true in either case. However, the mere presence of the other condition (compare dictionary value) prevents the event from running properly despite the Or setup.

  • I've had a bug in my game that I was unable to figure out for months. Today I managed to, (or so it seems), get to the bottom of it. However, I still don't understand why the change I made works. I was hoping someone could bring to light why this change works.

    The issue: A sprite is set to visible in a function, and then a function below this action is called and checks if this sprite is visible. AKA:

    Call first function: set sprite visible (within first function then call second function which checks if sprite is visible)

    The confusion:

    This image was how I managed to solve (works so far) the issue. Instead of placing the check if sprite is visible nested in the top of the function, placing it as a sub event beneath the top of the function with NO other change allows it to work. There are no actions in the top part of the function that precede this conditional check and thus the ONLY difference is placing it within the functions start or below as a sub event. Did I miss something in the manual that makes note of this, is it most likely a timing issue, are conditions placed within the top of the function ran a tick earlier?

    Just trying to improve my understanding of the engine.

    Thank you for your time,

    1Step.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • > if fGravity's water state is set to "active" then the error will commence.

    Then I think, the problem must be in some other event, where you are picking fGravity with "active" state and doing something with them.

    .

    Yeah, I went down that rabbit hole:

    dop2000

    If I disable the set y actions no error

    If I disable the set x actions no error

    In either case, the key is that this error ONLY occurs if I am using debug preview, so it appears to be specific to the debug console.

    P.S. just tried to make my project smaller, it quickly gets to the point where it is no longer even working enough to get to the problem at hand (so many connections at this point), this might be a puzzle just to get it down to a small enough size without breaking it.

  • Are you saying that if you disable this entire event, the problem goes away?

    Try to narrow it down even further - remove "Pick fWater" subevent, test, then remove "For each fGravity" line, test.. Maybe you could find the exact condition or expression that causes the game to freeze.

    Also, why are you setting waterUID to ""? If it's a numeric variable, it should not accept string.

    dop2000

    I have used the method of disabling each condition in the event, all the matters is that if fGravity's water state is set to "active" then the error will commence.

    Also, the waterUID to "" is just set there to ensure no residual effects linger from having a previous waterUID (since UIDs can't be strings, then no fWater.UID can be selected) when no longer active, it's rather irrelevant in this context.

    Thanks for the replies, to my knowledge bug reports are open to the public, so I'm not sure how others have handled heavily invested projects and then just showing the project file freely to the masses?

    If there is a more private way to do it then I'm all for it.

    I'm also aware of the advice to break the project down into the smallest portion that still produces the error. I might end up going that route.

  • Could you post a screenshot of the events in question? (loops etc.)

    Done dop2000

  • I'm very deep into a project of mine (over a year or so) almost 100 event sheets, and I have managed to figure workarounds to most problems however the solution to this issue evades me.

    I understand it's hard to diagnose certain issues without the project file, but at least, from a Construct 3 context, what sort of setup would cause such an error?

    Key Points:

    1) When I run my project in the normal preview there is no freezing point, no errors.

    2) When I run the debug preview,

    a) The Event: I have a water tile background that if instances of the player object are in a certain distance from the water become "waterActive"

    b) There is a loops section that displays as incomplete when the players run into the water, at which point the game freezes, and it is specific to one object (the player object). It displays as such: 14/16, in which out of the 16 players in the game, there are two that are "waterActive".

    c) Whenever this loops section appears, I open the console window and it displays the error shown in the image above, if I prevent the event that sets the players to water active then there is no issue, however, I have yet to figure out what exactly is causing the issue.

    The main curiosity is why it happens only in the debug console preview, considering how large my project is right now, the use of the debug preview is necessary for any worthy development to continue.

    It reminds me of a certain quirk, if I click the local storage object in the debug console it will essentially break the preview. Not sure if this is a similar case as my project issue is specific to events.

    P.S. If I open up the console window in a non-debug preview no errors show in the exact same circumstances tested so it seems something is happening in the debug console that is disrupting the preview, just not sure what.

  • Ditto.

  • With C3, previewing in the browser is usually gonna give some jank, and is not indicative of web hosted or exported performance. Just use it as a rough guide.

    It's not so much that there is "some" jank it's more so the binary nature of its occurrence. One session: smooth, the very next janky, then the very next smooth, with no discernible change in the environment in which I am previewing the game. So in other words, if the browser is capable of previewing the project smooth without jank, it would be great to pinpoint what exactly is resulting in this binary occurence. Again, if the export to NWJS is fine, then I'm not really that worried. However, I did export this as an HTML5 and uploaded to itch.io and did experience the jank, so does it stand that Construct 3 (An HTML5 based engine) will be prone to this potential jank/stutter problem regardless of the optimization set forth in the development of the game if the browser is involved? I honestly have no idea, again there are a lot of variables to consider.

    If you're running Windows ctl-alt-del and bring up task manager. Select the performance tab. Keep a watch on the charts as your app runs. If you're seeing some wild spikes in say disk activity or cpu usage, then it's likely a background process causing the stutter or even the browser itself.

    I ran with task manager 20% CPU, however unlike in debugger mode where it displays about 12% GPU it shows 60%, is this difference worth mentioning? In both cases with and without jank the performance graphs looked similar, no significant spiked associated with the janks/stutters.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey Ashley, thanks for the response. In a non-deterministic case, in which a multitude of activities can lead to what we perceive as jank in any given session, what do you think would result in the session-long jank, rather than a transient situation? Presumably, the activities that resulted in the jank would eventually be resolved, yet in my experience, if I see jank in the first few seconds I will continue to experience this jank until the session ends. Is there some technical aspect that would essentially label the session as ("jank"), and would no longer update this label/state once the background or even foreground processes are resolved?

  • Yeah, I was actually surprised by the export scenarios performance. I recall experiencing the stutter/jank on a previous NW export so I was not overly optimistic. If the export does not have the issue, I can "deal with it" for now.

    It's still quite puzzling how essentially at the beginning of the session it is decided whether or not there will be stutter/jank for the remainder of the play session.

    I'd feel way more comfortable with development if we could nail down this issue (assuming it's a fundamental one, as there are a lot of variables to consider)