GeoffB's Forum Posts

  • dop2000 this is a bit of a revelation! I'm building a similar setup to OP, currently passing URL params back and forth which is fine, but not exactly convenient.

    Ashley can you comment on this "hack"? Obviously undocumented features should be avoided at all costs, but are there any issues or caveats you foresee if one were to use this method to share data across apps?

  • This is a common issue among new users. Basically what's happening is the first event runs and sets the music to 0. But the second event will also run (afterwards), see that the music is 0, and then set it to 1.

    So both events are technically running correctly.

    There are a lot of ways to handle this. For simplicity, I suggest breaking it into two parts in a single event:

    1: On M pressed, set music to 1-music. (this way 1 becomes 0, and 0 becomes 1)

    2: If music = 1, do "enable actions". Else, do "disable actions"

    I'm getting the same errors. I wonder if this a build server issue?

  • There is already a feature for this: construct.net/en/make-games/manuals/construct-3/interface/file-editors/array-editor

    The same applies for dictionaries. Just import the project file via AJAX, and away you go!

  • You need to use "for each CommieMinnak". This will check each individual object for its angle and set accordingly.

  • Jumping in here because I've been using Remote Preview for ages and I'd also love to know how to optimise it. I have the same setup as you: computer with Ethernet and phone on Wifi. Oddly, my old Huawei P10 Lite loads the preview muuuuuch faster than my Samsung Note 9, so I suspect there's something that can be set on the phone itself to improve speeds.

    For what it's worth, though, I've found that for tweaking user interactions, setting up some debug sliders and whatnot in the game itself is very useful and makes for quicker testing. Not really a solution to this problem, but good practise for speeding up testing.

  • What you're describing makes sense to me. Loading 6000+ images when the project is first opened and then the first time it's previewed will put a fair amount of load on most PCs. Bear in mind that the first time you preview your project, Construct builds spritesheets in the same way it would do so for export. That process only needs to happen once per session, unless you change your spritesheet size in which case it needs to rebuild them.

    A few things worth doing, if you're not already:

    1) Make sure you're working with a project folder, not a project file.

    2) Add your entire project folder to your anti-virus program's whitelist.

    3) Pause or disable cloud syncing if you have it (OneDrive in particular occasionally kills file read/write performance).

    4) Use the desktop version of C3. I've found it runs a little faster in general.

    5) If you have the option, move your project folder to an SSD.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry for spamming, but I have another update. I reverted and updated both NW.js and C3 multiple times.

    After more testing, I rolled back to NW.js v0.51 and it started behaving itself. But then I updated back to v0.51.1 and now it's working again. That might've been the mysterious fix I stumbled upon previously.

    Anyway, if anyone is having issues, try roll back NW.js, then update to the latest version. There might be more playing around you need to do, but eventually you might find the combination of versions that works for you :P

  • I did a quick test using TheRealDannyyy's Construct 3 Launcher and I can confirm that the issue cropped up with r234 and onwards. Reverting to any release before r234 prevents the issue.

    Unfortunately it's too late for me to roll back to r225 for my current projects, so I'll have to make do without the built-in debugger until the issue is resolved.

    Once again this brings up the concern of forced "stable" updates in the desktop app, but it seems to be an argument that ends with nobody being happy. For this reason, the desktop launcher is an absolutely required tool for anyone working on any commercial projects, and I'd love to see it incorporated in a formal fashion.

  • Hi everyone, so I logged on today after a few weeks away from C3 and realised there was another stable update, and that means obviously that my desktop install breaks :(

    I can't use the debugger, on any project. Anyone else having this issue at all?

    EDIT: Tried upgrading nwjs in case that was an issue, so I have tested on nwjs versions 50 & 51, and debug does not work for me on either since the new updates. Running Debug just results in the application closing with no error.

    Same issue here. Preview works fine, but debugger just causes the app to crash without any error messages, which makes debugging difficult.

    This is on a brand new PC with a fresh installation of Windows 10, but I had the same problem with my previous PC as well. That went away somewhat mysteriously, but I can't find a way to solve this issue now.

    Using the NW.js 0.51.1 and latest stable version of C3.

  • This should work: 

    + Touch: On any touch start
 | Local static number tempRandom‎ = 0
----+ System: While
----+ System: tempRandom = Sprite.AnimationFrame
-----> System: Set tempRandom to int( random(Sprite.AnimationFrameCount))

----+ System: [X] tempRandom = Sprite.AnimationFrame
-----> Sprite: Set animation frame to tempRandom

    It's also a little more flexible than specifying the available animation frames.

  • As far as I know, there's no way to do this directly, but you can use the replace expression to do what you need. Just decide on a naming convention for the tokens that need to be replaced.

    e.g.:

    aString = "Hello, dear $PlayerName"

    replace(aString,"$PlayerName",PlayerName)

  • Thanks plinkie, but this is the exact problem that I'm facing. It seems counter-intuitive to require non-roads as objects, as this means I need a high-cost "tile" (sprite, not tilemap) for each blank space. If I have road tiles, and higher-marked non-road tiles, then I need to fill my layout with non-roads, which seems like it should be an unnecessary thing to do.

    I get that this might be the workaround, but it feels like just that - a workaround, rather than an intuitive way to create a pathfinding system.

  • Hi all, it's been a long time (I was GeometriX on a previous account)!

    I've experienced what I can only describe as unexpected behaviour with pathfinding, specifically path costs.

    I have a little truck that uses the pathfinding behaviour, and I have roads as sprites that I want the truck to travel along preferentially, as opposed to blank space. My thinking was to set the road's path cost to something less than 10, as that is the default cost for objects (or 14). However, no matter what I set the road's cost to, even a negative number, simply setting it as a cost at all means that the truck avoids the roads as much as possible.

    I've tested this in numerous projects, including the template, and the behaviour is consistent. I would expect that any object with a cost set to less than 10 would be considered preferential over nothing (i.e.: no objects).

    Is this normal? Expected? Does anyone have any experience with this issue?

    Thanks!