LukeW's Forum Posts

  • Considering this further, it might be that I'm getting this issue due to being on an older build of C3 (317.2). Judging by Ashley's comment here, this might be a non-issue now, I'm not sure.

    github.com/Scirra/Construct-bugs/issues/7921

  • I've had this issue reported by a couple of users running my game on older laptops. They report that during moments when the game experiences frame loss, sometimes the button presses from the gamepad do not register.

    This seems like a pretty serious issue as missed button presses are going to result in a lot of frustration for players. Thankfully, my game has no fail states, so the worst thing that happens in this case is that the player has to press the button again. But I imagine in certain game-types (i.e., action games), missing button presses would be a major problem.

    When discussing this issue on Discord, Federico points out that gamepad input is polled, which is the cause of the issue.

    For reference, this is where the issue was reported to me: steamcommunity.com/app/1526370/discussions/0/4407418033223539057

  • Layer order preservation when spawning hierachies from an object bank seems like something that'd be a big improvement to the overall hierarchy system.

    This is a bit of a pain currently, especially if one of the instances are spawning into a z-sorted layer and the others aren't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I've spent a few days working with flow charts to implement a simple dialogue system in my next project. After working on Bilkins' Folly and dealing with all the complex dialogue trees in that game (composed in Dialogue Designer), I really wish flow charts were a thing a few years ago!

    I have a few recommendations, at least some of them I suspect are already planned.

    • Select multiple nodes at once using drap and drop. Right now, it seems like only one node can be moved at a time, which is a problem when trying to organize large charts.

    • Drag from a node to create a new node. Much like how Unreal's BP allows you to quickly create a new node if you drag from a pin to an empty space.

    • Duplicate nodes - dragging a node while holding alt should create a copy of that node.

    • More workspace – preferably infinite. Creating nodes left-to-right, it didn't take long to reach the end of the workspace. It doesn't help that the default node starts in the middle of the workspace instead of over to the left.

    • More zoom out. Right now it seems you can infinitely zoom in, but zoom out gets stopped before revealing the full canvas.

    • A mini-map. Once devs start making huge flowcharts, it's useful to have a minimap available that can be used to quickly pan through the workspace.

    • Commenting an area. Preferably in the style of BP that allows colour coding and grouping of nodes.

    Other node types and tweaks. This is probably a bit more specific to treating flow charts as a dialogue builder, however I feel these suggestions would make flowcharts even more powerful:

    Character fields - Specifically for a dialogue system, you often need to know what character is speaking and what animation (or frame if it's a static image) to display. A character field (or some other way of accessing additional data on a per-node basis) would be handy for this. Right now, it's possible to do this by utilizing the default field, but that's kind of annoying as you're always making new fields on node creation.

    The 'execute code' node - Right now, I'm using the tag field to execute specific pieces of code using tokens. It's a bit clunky as an entire node needs to be created in order to access this. An 'execute code' would essentially just be a tag and nothing else. It would help reduce bloat and is actually a super powerful way of handling logic inside of a dialogue loop. For Bilkins, I had over 30 different codes that I could call from a simple tag-like node and signal the game to do something.

    Conditional branches - a binary node that outputs either true or false based on a condition. Could either take in a global Boolean (or flowcharts could be given their own variables) or it could remain up to the developer to determine how to feed conditions into it. This can be expanded with logic operators to make it more powerful.

    Random branches – this node has multiple outputs and randomly picks one to go next. Useful for dialogue in situations like greetings where you might want an npc to mix up their message each time the player interacts with them.

    Ta!

  • > However, I do know that the dev for Repella Fella was able to get it working.

    I actually can't say as they all come up as secret. I played for a bit and nothing unlocked, so maybe they aren't working either?

  • I gave up on achievements in the end.

    However, I do know that the dev for Repella Fella was able to get it working. One thing I noticed in their export was that they had not packaged assets. I'm actually wondering if that's part of the reason the wrapper wasn't working for me.

    I didn't bother to see if that actually made any difference though as by that stage I was already over it, but it might be something to try?

    ***edit*** if you're referring to the game crashing on startup, I didn't have that issue. I used nwjs 0.71, Steamworks sdk150 and Armaldio's Greenworks files. All the GOG overlay stuff seems to work except for the achievements.

    I was stuck on an old C3 version though (pre-Steam exports options) - r317-2 and had to add those arguments manually.

  • > I'll come back here hopefully this year to confirm we can port C3 games to all consoles.

    :)

    Awesome!

  • Did you ever get this to work? I was starting to look into it now.

    Nah, I gave up on it in the end. GOG sales are a small % compared to Steam and it was taking up a lot of time for no result.

  • C3 is not FREE. That is the only "problem".

    No amount of clever marketing, learning material or whatever you can think about can get around that.

    Honestly, I don't get why the trial version of C3 is as limited as it is. There's a ton of great features that you can't even access from the trial version and the tiny limit on events doesn't make sense from my POV.

  • I'm struggling with this one a bit. I have achievements set up in my project using Greenworks, and it works fine in Steam. So according to the GOG Dev portal:

    "If you already have a Steam version of your product, you can get it up and running on our platform within minutes, not hours. No API methods need to be replaced in the code — all you need is to use our Steam SDK Wrapper (Beta)."

    docs.gog.com/steam-sdk-wrapper

    However, I've had no luck getting this to actually work. I'm following the 7 implementation steps as listed in that link. When I place the GalaxyConfig.json inside package.nw with steam_api64 the game boots up then crashes instantly.

    I'm using a correct version of the Steam api as listed in the docs (150).

    Is this even possible?

  • Hey folks, I am currently building a project with a popup that contains scrollable text and just wanted to mention: be super aware how you set the parent-child relationships in your elements.

    As long as I have a static window with scrollable text, all is fine, but as soon as it starts moving into the screen, together with a bunch of other elements (e.g. the scrollbar, or a background texture, or a picture...), things get very weird.

    E.g.: I had a scrollviewport on a popup window. I moved the scrollviewport up and down, and I made it the parent to the background. This lead to the whole background being the limiting area for the scrolling, not only the viewport.

    I got around around this using the pin action (back when hierarchies didn't exist). Had to pin everything at start, unpin on tween finish, repin when hiding, etc... A big old pain in the butt.

    It works, and I don't want to mess with that by changing it over to a hierarchy system, so I'm just leaving it as is.

  • I think there are three porting houses that have ported construct games in the past, maybe there are more that I never heard of, would be cool to have a list

    https://www.seaven-studio.com/

    fedca Turns out Seaven's homepage isn't quite correct. Just spoke to the producer for them and it looks like they're not ready for Construct 3 yet. They did say hopefully later this year.

    So with them currently out and mp2 booked years in advance - we're currently back to one option. Again, the idea that there's only one studio currently taking on jobs is pretty worrisome, especially when a project is typically a 2-3+ year investment on our sides.

    Who's to say what things will look like in a few years time? Hopefully it'll be better, but I don't think I'm willing to take that gamble for the next one.

  • I think that tutorial is out of date. You only need to tick 'Export for Steam' when exporting - you don't need to modify the Chromium arguments as it now automatically configures it.

    Thanks for the response.

    I've been on 317.2 for a while due to the porting process, so never saw that 'export for Steam' button. I'll add those lines manually though and see how things go.

  • I ran this test today on two separate PCs. My scores were:

    PC 1:

    editor: 158,000

    nwjs: 54,000

    PC 2:

    editor: 80,000

    nwjs: 30,000

  • Right, so after a bit of help from Mikal over in the Discord channel, we've been able to find the root cause of all these frame drops.

    I'd been using the Construct-Team provided tutorial for getting our games ready for Steam, and one of the things that is mentioned there is that you need to add '--disable-direct-composition' to the Chromium arg line.

    construct.net/en/tutorials/using-greenworks-steam-2853/page-4

    Once I deleted this from the arguments, the frame stutter issue disappeared entirely.

    Laura_D, sorry to ping you over this, but as the author of the tutorial I thought I'd bring your attention to it. It seems that this line is causing some really nasty performance issues on certain machines. From my testing, I've only seen it on AMD-based gpus, but that's a pretty limited pool.

    It sort of creates a bit of a conundrum for Steam exports though. We can omit that line and have smooth games across different hardware types but that limits certain Steam functionality (though from what I can see, does this only stop the achievement icon from popping up... is there anything else it does?).

    Alternatively, we could have a separate 'beta' build for players who have the issue, that they can then opt into (losing the Steam popups in the process). Of course, that assumes that players who experience this issue will actually go to the appropriate forum and make the change themselves which, honestly, is probably not the best way to handle this.

    Also, I get the feeling that this is a separate issue to the performance differences that I mentioned earlier when comparing full frames between in-editor previews and nwjs exports, which VinniePin just started a thread on. I just noticed that frame difference while trying to chase this issue down.

    Also also, I'm aware that this is now falling out of the scope of Construct in the sense that it appears to be an nwjs specific issue. But it's certainly something that's going to affect the majority of Construct users until a proper fix is in place.