DiegoM's Recent Forum Activity

  • This happens when you open the latest beta and then go back to using the stable version. The latest betas are adding a little bit of extra information to the Animations editor save state. Older versions don't understand that, and crash when they try to load it.

    Clearing the browser cache works because it allows C3 to start from scratch again.

    Since most of the user base only uses stable versions, most people aren't seeing this problem.

  • This issue has been mentioned before, but we haven't been able to figure out what the problem is. On top of that it doesn't seem to affect a lot of people so it's harder to find out what the problem might be.

    I mentioned Firefox as a workaround, because we are not really sure how to fix this one, mainly because we haven't been able to reproduce it ourselves.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Have you tried using a different browser? Firefox would be a good try, as it is completely different from Chrome. Other browsers, like Edge or Opera might run into the same problem as they use the Chromium engine under the hood, which makes them pretty much identical to Chrome.

  • Do you have any browser extensions installed? If so, you can try disabling them all to see if the problem stops happening.

    If that works, you can try disabling them one at a time to figure out which one is causing problems.

  • Yeah sure, you can send it to diegohqc@scirra.com

  • Can you share your example project?

    Maybe there are some performance improvements that can be done on Construct's side.

  • The position of the tiles in the brush tileset is not indicative of what the auto tiling will do. That's just the place each tile needs to have so the algorithm works.

    The tiles are chosen such that the outer region of the drawn tiles always have the "grass" part and any inner part has "water".

    Notice that whenever a tile is placed on the tilemap, all edges of the tile which have an adjacent space which is an empty tile, end up being some form of "grass" while any inner space is "water".

    Ej 1. A single tile with 8 empty tiles around it will always be tile "8". All "grass" in the edges and "water" in the middle.

    Ej 2. A single tile with 8 drawn tiles around it will always be tile "64". All "water" no "grass".

  • Since this was a very simple fix, it will go out in the next beta.

  • Just took a look and the system timescale is applied to the main delta time of the runtime to calculate the playback speed of a timeline.

    The problem with that is the the runtime delta time already has the time scale applied to it by the time it is used by a timeline, so it's using a value that is multiplied twice by the current timescale.

  • With the conditions available right now, if you use unique tags, you can use the On tagged node change trigger and perform your actions or functions when a specific node is reached.

    You can also use the On any node change trigger coupled with the GetCurrentNodeTag expression to achieve the same effect.

    Even though the current feature set is pretty bare bones, most of the things suggested up until now, can already be achieved.

    Whatever method you choose to determine what node has been reached on a trigger, it is reasonable to have a unique event sheet that just checks which node has been reached and depending on that execute additional conditions and actions.

    On a different note, there is a feature which the current example doesn't explore. The Flowchart Controller plugin is not single global, that means it can be added to a container, that means you can have unique flowcharts instances for a bunch of instances and manage them relatively easily. I was thinking of creating a different example showing a possible way to use that.

  • I think the fundamental problem with adding the functionality to execute logic to nodes is that the more logic capabilities flowcharts had, the more they would overlap with event sheets.

    That poses two problems.

    The first is having two different ways to handle logic, which in on itself is not great because it would be confusing. Specially for new people. The immediate question someone new would have is "What are better, Event Sheets or Flow charts?" and the answer would inevitably be "It depends on what you are doing, both have pitfalls... bla bla bla" :)

    But the second problem is that Event Sheets are just better for programming and are Construct's way of doing things. Flowcharts could be used for small bits of logic, but they don't scale. If you have boxes connected with lines to handle logic, things become spaghetti rather quickly. I pray for the soul that has to debug that kind of visual systems.

    So, if the best practice is to use the feature for relatively small systems, I think it's ok to have to use event sheets to glue things together.

  • XHXIAIEIN

    6) Allow top-down organizational structure (Flowchart properties)

    I don't think that will happen.

    When I first started developing the feature, the diagrams I drew on paper had the outputs at the bottom of the node and the input on top, instead of the left and right respectively. That is how most people would draw tree diagrams.

    The problem with that was that text fields are horizontal so having each output to the side of each name and value pair makes much more sense visually and because being on the side makes sense for the outputs, it becomes natural for the input to be on the opposite side rather than the top.

DiegoM's avatar

DiegoM

Member since 24 Apr, 2015

Twitter
DiegoM has 1,382,064 followers

Trophy Case

  • 9-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

15/44
How to earn trophies

Blogs