WackyToaster's Forum Posts

  • Oh yeah they can ! cool, I probably failed my input when i tried doing so on last update r370 (when we didn't have feedback for linking nodes)

    Pretty sure it was somewhat bugged because I also thought you can't have multiple inputs because it just didn't seem to work.

  • Wait is an action, not a condition. You'd put it where you have the sleep right now. Wait can be a bit tricky to get right for various reasons, which is why timers are usually recommendet.

  • Yeah I suppose that's what I gotta do. I just think it's kinda weird to implement it this way. I wish I could hack into the platform behavior and emit some event or something :I

  • I'm gonna give flowcharts a good try once the next beta drops that (presumably) fixes the crashes. I am arguing a little bit in the dark here because I have not yet actually build anything from the ground up or really at all.

    I have however exactly in mind what I would want to build and what functionality I'd want. So I'll attempt to do that and see what comes out of it.

    I'd personally be ok with keeping the logic in an eventsheet entirely BUT only if there's a good interface between the two.

    If there's one thing I can pick I'd want, it's anything that avoids having to glue flowcharts together at runtime. It's probably useful in some cases, but I'd want to avoid it as much as possible.

    If I look at a node, I have no idea if I glue a flowchart to it at some point or not. I can probably guess that I do, but I still have to check through the events to see which one. I'd rather have that connection already established in the flowchart view and be able to enable/disable this connection at will (checkbox in the flowchart view maybe?). It would be immediate visual feedback as to what's happening, rather than it being obscured in the eventsheets.

    In the same vein, branching connections would be important. If I think a coinflip, I really want to avoid having to do the 50:50, then glue the correct following node/flowchart to the out. I'd rather have this already visually connected and somehow communicate which path I want to take. Maybe something similar to function "set return value" there could be a "set branching value" which is than simply compared against when "go to next node" is called.

  • It's hard to say what exactly would be causing the issue just from this alone. It's probably some every tick, for loop thing. You can try disabling individual groups and see if the situation improves. If you disable a certain group and suddenly the game stops stuttering, it's pretty evident that something inside that group is causing the stuttering.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • My concern : i have try the Array, reading and writing it on complexe data seem very troublesome.

    I have tinkered with data-driven stuff before and I always reached the conclusion that it's absolutely possible to do so, but doing it via Events is somewhat cumbersome.

    If you want to do it no-code, I'd probably recommend the json plugin.

    If you bite the bullet and use javascript, classes/subclasses and methods will be your friends, as well as json/array data.

  • It depends a little on the project and what you plan to do but it can absolutely make sense. But it's not strictly necessary, you can re-use the same eventsheet easily in multiple layouts, so if you prefer creating individual layouts and working entirely visually, that's fine.

    If you plan, for example, adding a level editor, creating levels from an array in the first place is probably much better. I also think it's a bit easier/cleaner to work with overall.

    For example, is there a Construct 3 command to draw squares with a solid color and border? Or, do I need to create 5 sprites (Start, End, Path, Open, and Blocked) and then dynamically write them to the layer?

    Technically you could probably use the canvas but don't bother. Just create the 5 sprites and/or use a tilemap.

    In my case I load an array like in this image, then do Array for each and create a bunch of sprites. It's quite easy since my game is based on a grid, so the coordinates are just array coordinates * gridsize.

  • It depends a little on how exactly it's set up but roughly:

    On start of layout

    Array for each Element X -> Create object (by name) Name:Array.At(Array.CurX,0), X: Array.At(Array.CurX,1), Y: Array.At(Array.CurX,2)

  • Our approach with flowcharts is, currently, as a data structure only.

    I have 2 cents in that regard. I've been more and more going into javascript and I'd say handling any kind of data structure, being array or json is so much easier and flexible in javascript.

    One big thing that Construct does very well are the visual editors. 2D/3D array editor, awesome. Flowchart editor, also awesome. Json, well that's just a text editor, but also perfectly fine. But manipulating these data structures in the context of the eventsheet... I dunno, either it just doesn't work for me or it actually is very cumbersome. Flowcharts are shaping up to be easily the most cumbersome data structure to handle in events. Although I have yet to properly test the usability since it's currently crashing a bit too much to test this.

    I don't exactly have a solution here, I just feel like that eventsheets are not that well suited for that type of data-driven work.

  • I don't think this needs a screenshot. Just add "For each Enemy" above the trigger once, that should do the trick.

  • I do use a laptop occasionally but I've not had any of the issues you mentioned in the other thread. Although my laptop also costs 3x as much as you want to spend, but I don't think that's the issue.

    I could imagine that the issues arose due to laptops being often quite aggressive in terms of power-saving, especially when running on battery. They often start to underclock everything and most laptops come with two graphics chips nowadays and you have to specifically tell it to use the powerful chip instead of the onboard one which usually is just enough to run the most basic graphics stuff.

    I can't really give any specific recommendations. There's more to it like size/weight preferences, how much you plan on traveling etc. I personally have an MSI, but realistically Construct should work well on pretty much any random laptop that isn't ancient.

  • Can you press F12 and check the browser console for any errors? Do you export with the latest C3 version, beta or stable? Can you try disabling/enabling offline support (it's an option when you export)

    And just in case: When you upload do you overwrite ALL files? I've had errors before where only uploading some files would result in weird behavior.

  • Try Ctrl+F5 or clearing browser cache maybe.

  • Cool, I'll join if I'm in the right mood!

  • I tried but I actually cannot reproduce this.

    The test project you posted has an error with the events. Your getLayer function returns 0 BUT it is set to return a string. So it fails to create the object in the first place, and then picks all objects by default. This appears to not be the issue in your actual project though where it's the correct type.

    I thought I had an idea at first (that your function doesn't return anything and thus it fails to create the vine, like in your testproject) but since pick last created fixes it I kinda doubt that that's the issue. You can try removing the condition "layerName = 'Neutral'" and just leave the else and see if that also fixes it, that would mean that the projectile field is not created on one of the three layers (Spy, Jun or Neutral) but some incorrect layer initially.