robit_studios's Forum Posts

  • This may be a bug. Do you have an example project I could use as a reference to fix it?

    https://www.dropbox.com/s/ufmjkaosihbjf3s/Spine_BB_Test_3.c3p?dl=0

    Hope this helps. Thanks!

  • Are the Spine-defined Bounding Boxes supposed to scale with the rest of the sprites? I am trying to use the Spine bounding boxes as reference points in Construct but they only seen to work properly if the scale is set to 1. This image demonstrates the issue:

    Is this as intended, am I using the scale-property the wrong way, or maybe a bug?

  • Amazing to see that this plug-in is still being updated!

    I've only just begin digging into what it's capable of and one thing that I haven't been able to work out is how to implement palettes. I don't know Spine TOO well but as far as I can tell there's no way to define palettes within Spine.

    Could anyone explain (or point me in the right direction) on how palettes with with the Spine plug-in and C3.

    Thanks!

  • Was that array value condition nested underneath other events?

    Yes, it is nested under a "For each XY Element". But if you look at the example file I posted (https://www.dropbox.com/s/3ksh1jcubyfkxr6/Sprite.Count.c3p?dl=0) it also happens with a standard For Loop.

  • You could set the layout size to the largest you'd need to use, and then implement custom scrolling boundaries within that to simulate using a smaller layout.

    Thanks! This is what I'm going to try. But is there any chance C3 will get an update to allows us to change the Layout size at runtime? This seems like it should be basic functionality.

  • One simple solution is make the layout size big enough to accommodate your largest possible level. There isn't any particular performance related aspect to layout size, only how much you put on it. Note that you have a good chance of running into issues with pathfinding across a large level though.

    This had a occurred to me and would definitely be the easiest route. I'll try it out and stress test the pathfinding to see how it affects performance.

    Another way would be to move your level around instead of the player, so your player effectively stays in the middle of the layout. This has the advantage of limiting the scope of pathfinding as well.

    This is an intriguing idea and might work well with the way I've designed the levels. Thanks for the advice!

  • As I just discovered in another thread: The pathfinding behavior does not work in "areas outside the layout area".

    In my game the level is generated at runtime and the size can vary quite a bit.

    So, is there a way to change the size of the layout at runtime? That way I could set it to be the proper size based on the level that was generated?

    If not, that severely limits the usefulness of the pathfinding behavior (at least in my case).

    Tagged:

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Probably not.

    Ugh... of course not. I seem to keep running into limitations with C3 that really shouldn't be...

    You can try this addon:

    https://www.construct.net/en/forum/extending-construct-2/addons-29/behavior-easystar-js-96215

    It works with Tilemap object, and as I understand, there size of tilemap is not limited by the layout size. There is a link to C3 version on the last page.

    This does look like it could help, thanks. Thing is, I really don't like using 3rd party plugins, if possible, due to lack of support. I'll try it out, and maybe I'll just have create my own pathfinding code. I don't know what it is but I seem to keep bumping into edge-cases for C3 that need unnecessary work-arounds. It's really making think I need to switch to Unity.

  • From the documentation:

    Ah thanks! I looked through the documentation but must have missed that bit.

    So, for my follow-up - is there a way to change the size of the layout at runtime?

  • I was having a hard time figuring out why the pathfinding behavior for my enemies wasn't working sometimes.

    I finally realized that the pathfinding behavior does not work with Unbounded Scrolling.

    Once an object with pathfinding reaches the edge of the pre-defined layout size it stops moving (even with unbounded scrolling selected). And if the object is outside the layout boundaries it won't be able to find a path at all.

    Here is a C3P I made for testing this: dropbox.com/s/2wvpbl3g6lul808/pathfinding_boundaries.c3p

    Is this intended behavior? My game generates levels of various sizes so having the pathfinding behavior work outside the pre-defined layout is critical. Is there a way to change the layout size at runtime?

    Also, does this mean that the pathfinding behavior can NEVER move to a position less than (0,0)?

  • The object.count does not only return picked instances, it returns all instances. object.pickedcount returns picked instances only

    I was wondering about this, too. Thanks for explaining that. But I have to say.. it's weird that object.count requires objects to be picked even though no matter how many are picked it's always going to give the same number. Shouldn't there be a way to count objects without picking them?

    Objects aren't fully created until the next top-level event. So Enemy.Count won't be updated until the loop finishes. Just use a local variable and set it to Enemy.Count before the loop, then check Variable = 0, and increment Variable for each Create.

    This is what I am going to try. It's just always disappointing when something as simple as counting the number of sprites has to have a workaround.

  • Add a pick all enemy condition before it and it will work.

    This does work, and I think I get why I was getting the result that I was.

    The only problem now is that if there are no instances of the Enemy then Pick All won't trigger the event. I'm sure I can find a decent workaround, though. Thanks!

  • I created a C3P example if anyone wants to test if for themselves. I'm just trying to determine if this is intended behavior or a bug.

    dropbox.com/s/3ksh1jcubyfkxr6/Sprite.Count.c3p

  • Try <1

    I tried that, but I'm getting the same result.

  • Adding Trigger Once didn't change anything, but I think that's because that event runs multiple times as it's going through the array to build the level.

    As another test I added an instance variable to the Enemy that sets it = to the current Enemy.Count right after it is spawned:

    And checking them in the bebugger, they are setting the Count correctly:

    And lastly I made a static variable that hold the current Enemy.Count and then tests that variable as a condition. And that actually works as intended. Now I'm only getting 1 enemy spawning.

    So, how can it be setting the Enemy.Count correctly when setting a variable but then not when used as a Condition? Is this a bug?