quackgyver's Forum Posts

  • Bump.

    Bump.

    Hi,

    Would it be possible for whoever is the author of the Sprite Font plugin to add the ability to modify the object properties on runtime? I find that for more advanced projects, I often find myself needing to change the sprite image, character parameters or other such properties.

    Almost all other common objects offer similar functionality so it makes sense to bring the Sprite Font object up to the same level of power.

  • I have a few questions about the JSON object that comes with Construct 3:

    Question 1: Is it possible to use "Has key" to find a child key of a root object without iterating through the object? If so, how? I can't get it to work.

    Question 2: How do you target the root for iteration? Do you just specify an empty string (i.e. "")?

    Question 3: How exactly do you iterate through an entire JSON object?

    I've tried doing:

    json: For each entry in "" set debug to debug&" / "&json.CurrentKey

    But it just keeps printing the root key over and over, without returning the child objects.

    Thanks in advance.

  • if multiple limiting tiles are visible, how is the camera supposed to know which ones apply? and which direction to limit the camera?

    It's supposed to limit it in all directions, and it *should* in my opinion work by checking for overlapping at an offset. I just can't seem to get it to work.

    can you post a sample file so we can see how you are placing the tiles?

    An image would illustrate it better:

    The red shape is the viewport. The yellow tile in the center is the camera. The purple shapes are bounding tiles. The camera should in no way be able to proceed past the bounding tiles if the edge of the viewport collides with it.

  • this is what I would do...

    create Min and Max sprites for X and Y, and clamp the camera coordinates to their locations.

    https://www.rieperts.com/games/forum/LimitCamera.capx

    this puts the limit markers where to stop the camera... you can still see beyond that so you have to calculate where to put them. if you dont want to see anything beyond the edge of the layout, you have to put these far enough in to accomplish that.

    it you want to set these at the limit of what you see, then you have to calculate an offset from them based on the viewport size.

    That doesn't solve the issue, because it confines the camera to a specific bounding box. I'm talking about disallowing the camera from scrolling past *any* bounding tile that's been mapped in my tile grid.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hello.

    This is what I'm looking to achieve:

    • I want to use 16x16 sprites (square tiles) as bounding objects that my camera can't scroll past under any circumstances.
    • In other words, the camera should never be able to scroll so far that it's able to show even a pixel beyond the edges of these bounding tiles.
    • This also means that If I have a room that is smaller than the viewport, the camera should stay right in the center of the room.

    I've been using Construct for about 10 years and I've spent the past four hours trying to figure this out using various approaches (sprite collision, offset algorithms, clamp etc.) and even though I feel like my solutions should work, they just don't.

    If anyone can tell me how to achieve this (i.e. the actual specifics rather than a vague suggestion) then I would be very grateful.

    Thanks for taking the time to read! :-)

  • This has been reported multiple times before.

    The editor still has issues where it scrolls to the top of any panel when you attempt to scroll to the bottom in Safari on macOS.

    When is this going to be fixed?

  • You do not have permission to view this post

  • I mostly just wanted to understand if the issue is known and has a known fix, and how much testing that's being done in macOS/Safari since I've had so many issues with that platform that Construct is barely usable for me. This is just one of many problems I've had with that platform, so it'd be nice to know if macOS/Safari is a secondary platform to you, or if you QA test for macOS/Safari as much as you do for other platforms.

  • I tried to bring it up here 🤷

  • For some reason, every single window that has a scroll bar randomly won't allow scrolling to the bottom, as it will automatically force-scroll to the top as soon as you scroll down.

    See attached GIF.

    This makes the editor completely unusable, as whenever any window gets too long I can no longer work with the data that's outside the viewport.

    Ever since I first started using C3 it has been virtually unusable for me on Safari, so I have to ask, is it really being thoroughly tested by the devs on macOS and Safari the way that I'm assuming that it is in other major browsers?

    Also, is this a known issue? Is there a way around it?

  • I think it's reasonable to say that if you're marketing a car as able to drive on road type A, B, C, D, E and F and also advertise it as having radio if drivers pay a premium, then you can't leave out the fact that the radio won't always work if drivers drive on road type E.

    I accepted that Construct was experimental technology back when HTML5 game design was new and you guys were focusing on creating impressive HTML5 technology stacks, but you're now charging just a few dollars less than companies like Adobe are, and I don't think it's reasonable for you to market Construct as being immensely easy to use for the creation of both mobile games and Multiplayer games, only to have Multiplayer be restricted to a certain set of mobile carriers.

    I've followed your work for 11 years, and this is the first time I've ever raised a concern. I think I (and others) deserve more than a dismissive comment about how it's not your fault.

    Your marketing doesn't match reality. You need to address this, and I say this with good intentions.

  • You're not addressing the core problem here. Construct is heavily marketed as a tool that A) very easily allows the creation of multiplayer games for a specific set of platforms and B) doesn't work as advertised within the scope of how the tool is being marketed.

    I don't understand why you're refusing to acknowledge the marketing side of Construct. Construct doesn't exist in a solely technological silo anymore. You're not just engineers talking to other engineers about engineering things. I'm a customer who bought into what you were trying to sell me, and now you're hitting me with restrictions that goes against what you were communicating in your marketing.

    Whatever technological limitations there are, it needs to be clearly communicated in your marketing material. You don't get to sell me on how easy and great Construct is, take my money and then unload all these caveats on me.

  • The problem is the Internet, not Construct. Any software using the same approach will have the same problems.

    How do you figure that the problem isn't Construct when you're marketing Construct as such:

    "Publish your games to just about any platform out there!"

    "Create Multiplayer Games"

    "Make multiplayer games with our tools and services"

    "The easiest and most powerful tools right at your fingertips"

    "Bring your ideas into reality. Construct's been designed to allow you to build the game you've always wanted to make."

    "Make any game"

    "Publish & Sell Everywhere"

    "In a few easy clicks, you can publish your games to Steam, iOS, Android and a host of other places."

    "Get your games in front of millions of potential players and make the next big hit!"

    "Runs in the browser. Translated into 6 languages."

    Only to have the Multiplayer plugin not actually work unconditionally on mobile devices in the case that a player's mobile carrier has certain NAT restrictions?

    If you're marketing a tool as capable of doing X, Y and Z then the tool needs to be able to do X, Y and Z unless otherwise stated?

    Neither game developers nor end-users will care what technical restrictions there are. If you're marketing X, Y and Z then you either have to deliver X, Y and Z or provide some very clear asterisks. How would you feel if you bought a game, only to have the game not work on your specific (yet common) hardware setup because of some obscure restriction, and have the developer of the game go "sorry, the engine provider's API doesn't work with [setup X] and we bought into the engine thinking that it'd work"? Because that's what I'm going to have to do with my players, and I'm not comfortable treating them like that.