Lou Bagel's Forum Posts

  • ...and some physics to avoid overlapping...he is knocked out of it with some 8-direction values...the player starts moving by itself in the direction it was already moving. Like if the movement key was being pressed...seems like the x and y vector are moving by themself

    It probably has to do with how you set this up - I condensed your post in the quote above to highlight - and without knowing how you set this up, not sure what advice we can give.

    Are you using 8-direction for the "knockback effect"? If so, you probably simulate movement. I'd look at how that is setup to make sure it doesn't keep simulating.

    Are you using a different movement behavior for this? I'm not sure using two movement behaviors at the same time is recommended, as I'd assume it could result in unexpected/unpredictable behavior. I'd recommend only having one enabled at a time (can switch between them by enabling one and disabling the other).

  • If newly created instances don't spawn with the default properties, that could probably be fixed with a bug report.

    Do you have any instances at all of that particular object that are placed in the layout editor that do have solids set as obstacles? It might be taking from that as the default instead.

    I figured it out based on your two comments - this object was in a different layout, that I hadn't been used recently, so I did not update the settings there as well.

    Once I either updated it or deleted it from that layout, it worked as expected!

    Thank you!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can set default properties by having at least once instance of the sprite places in the layout editor, even if the layout is not used otherwise.

    I did have one instance in the layout but new instances created did not keep those same default properties.

    I figured out a workaround where I can put multiple instances in the layout, one for each container I will need, and they keep the default property. I assume that is because the container uses the existing ones, not creating new ones.

    Not ideal if I want to, for example, dynamically create/spawn enemies using line of sight. For this current situation, I only need a set amount so can continue with this workaround, for now.

    Good note that I can use a different layout, even if not used. I will test that as well.

  • I have a line of sight behavior setup using custom obstacles how I want it.

    New sprites created seem to default to using solids as obstacles. So even if I add the custom obstacles I want, this behavior still uses solids instead of my custom objects.

    There is no action to set the property to custom objects (instead of solids). And there is no expression to even check this.

    Is there a way to have a line of sight behavior created through events (so not in the layout in the editor) to use custom obstacles?

    A further detail in my project - this sprite with the line of sight behavior is in a container. Therefore, it is created via the container functionality.

  • Yes, the tech is all there - but they need to add support for running HTML5 games inside console apps so they can be distributed through the stores.

    Would the concept of how the NW.jS exports basically included chrome work here? Construct exports a console app which bundles a browser that runs the HTML5 game?

  • oh man, I missed these notifications. Thanks everyone!

  • I used Construct 3 to create a music video

    Subscribe to Construct videos now

    YouTube Link:https://www.youtube.com/watch?v=r_gM9vvpOfw

    Project on Itch.io: loubagel.itch.io/heartache

    Blog Post: loubagel.com/blog/heartache-music-video

    Would love to answer any questions anyone has. Made use of Construct's timeline feature as the main thing to map this out.

  • Signal can be triggered like functions in the current 332 beta

    I'm not sure what the intended application or purpose that is referring to. Even though, I'd still say Functions are what you are looking for in this case.

  • I'm not sure what you mean.

    Those images are screenshots of my code, which works to be clear. So not sure why I would change out any values.

  • It sounds like you want Functions.

    Signal is only used in conjunction with "wait for signal", I believe. If there is no blocks of code waiting for a signal, I don't believe it will have any effect. And signal won't trigger that code to re-run.

    As for efficiency, I'd bet that you don't really need to worry about that in regards to functions.

    You can nest an OR block in a function. Not sure why you would need a top level OR block with functions. That is kind of the point of functions - if you need two blocks of code to do the same thing, they can both call the same function.

  • Oh, I switched it from using to Border box properties (BBox). Can't remember why, but important to know if following what I did in the images:

    The origin point for my pathfindingZones sprites are in the top left corner. If the origin is anywhere else that math wouldn't make sense.

  • Do these help?

    Like I said, I'm using pathfinding here, but same concept anytime you are picking an x,y location.

  • If you want the sprite truly anywhere on the layout, you can set the position to:

    random(layoutWidth)

    random(layoutHeight)

    Unless your layout is entirely open, as in no solids or areas sprites shouldn't be (walls, for example), you probably don't want this.

    If you want to do more of a concept of spawning zones, I would make spawn zone sprites. Set the sprites to invisible, so that you can see them in the editor but not while playing.

    In the condition part of your action, use the System condition (select System, not the sprite), and use "Pick Random Instance". This will pick a random spawn zone sprite each time. (if new, you might want to read about "picking" in events)

    If you want them in random spots in the spawn zone, you can use the same concept as I started off with, using set position to:

    random(spawnZone.BBoxLeft, spawnZone.BBoxRight)

    random(spawnZone.BBoxTop, spawnZone.BBoxBottom)

    I do a similar thing, except for movement instead of spawning, in this game: loubagel.com/games/sunnyside-smash

    I wanted the characters to move around randomly, but there are areas sprites can't go - in the water, in solid objects such as houses, and areas I don't want them to be such as right in front of the house doors. So I made a sprite object using the same concept I explained above. I covered the map of areas I wanted them to go with instances of this sprite. The nice thing was that they didn't have to be the same size - if there was a big wide open area, I could stretch one instance of this sprite over it all.

    When a character is ready to move a random "move zone" sprite is picked. Then, a random coordinate inside that sprite is picked. Then I just use the pathfinding behavior to move them to that coordinate.

    I know the example is a bit off topic, but hope it helped.

  • Made a simple little game but got a high scores table up and running. Check it out here and get on the leaderboard: loubagel.com/games/sunnyside-smash

  • loubagel.com/blog/sunnyside-smash-dev-blog-1

    On the blog post above, I posted the project as-is after the game dev stream, which the full video is linked there as well.

    The blog post also includes screenshots of the event sheet and notes on each event. So it isn't exactly like a tutorial but if you want to implement a similar mechanic it could be helpful.

    On that note, feel free to ask any questions if you are looking to implement something similar.

    It was only about 1.5 hours spent on this so nothing too advanced.