Ashley's Forum Posts

  • It could be an equivalent to the Windows "10000 is enough for anybody" limit on OS X, except by the looks of it, a lower limit.

    I assume Apple are aware of any limits in OS X but presumably won't change them, and AFAIK nobody has tested Chromium and there is no bug report at crbug.com, because the focus has been on NW.js.

    I'd suggest:

    • if you can repro it in the Chrome browser on OS X, file it at crbug.com (I think this would be preferable if it reproduces there, since it means the issue is in the Chromium engine)
    • try the --file-descriptor-limit=10000 workaround mentioned in the NW report
    • if you can't repro it in Chromium, try to make a simpler repro to attach to the NW.js report and bump it with that

    Not much we can do with this post here, and it doesn't follow the guidelines and doesn't relate to C2 itself, so closing.

  • Works fine here on an iPad Air 2. You have to touch the screen first though, because Safari won't play sound before it gets user input.

  • Closing as duplicate.

  • But if you have an action that says "for this instance, ignore solids", won't it then fall through the floor if it's standing on a solid? It sounds like the only way is to say "for this instance, ignore solids of <family>".

  • The guidelines describe why we normally cannot help unless you reduce it to a minimal .capx - without that, the bug report is usually not helpful, or too difficult to begin debugging, or it could be caused by one of your third-party addons. The guidelines are quite clear that if you do not follow them, your report will be closed without investigation. We deal with thousands of bug reports and this is the only way it's feasible to actually resolve a reasonable number of issues.

  • I couldn't reproduce the other issue you reported. Sorry, but that means nothing can be done (and possibly it's specific to your circumstances and nobody else's). If you don't report bugs though, don't expect anything to ever change.

  • File a bug report following all the guidelines and I'll look in to it.

    • Post link icon

    Chrome 52 should be out soon, followed shortly by NW.js 0.16 - I'll try again for that version.

  • You just learned the hard way why we recommend daily backups to a Dropbox folder (or Google Drive, or OneDrive, or any other equivalent service).

    If you had done that, you would have at most a 1 day old project in your Dropbox folder which you can simply download to another machine.

    I know this isn't helpful now, but you really, really should learn to do that for any digital work, otherwise you're liable to have this happen again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • But I'm thinking that folk won't have the paid version of construct so won't be able to open it (has way more than 100 events).

    The free edition can open larger projects, and preview them. You just can't edit or export them.

  • Closing, please see the bug report guidelines: the .capx you provided uses several third-party plugins, and the size indicates it is probably not a minimal reproduction of the issue.

  • The Greenworks plugin is still experimental. I'm going to take another look at it soon, but since it's not an official feature yet we won't accept bug reports for it here for the time being.

  • I can reproduce, it's definitely unreliable, especially if you add simulated latency.

    The input prediction algorithms don't seem to be very well suited to the platform behavior, and I think there's a bit of tug-of-war going on between the local platform behavior and the input prediction corrections conflicting with that. There's also the fact that client updates are only sent at ~30FPS but the game runs at 60 FPS (normally) so there's the chance the user can press jump and have it locally simulate, but it does not actually send a message to the host. That could possibly be fixed by events. However I tried myself and it didn't seem to fix everything.

    The timings are very sensitive when you do things like land a jump - input prediction will keep interpolating through the floor, whereas the platform behavior will collide with it and try to land on it. The arc of a jump is also non-linear. I guess it's really designed for top-down linear movement type games.

    I will look in to this further, but it looks like a pretty tricky area. I'm afraid I'm not sure I can give an ETA on when this can be improved to the point it is working smoothly. There could be multiple internal fixes necessary.

  • Fixed for next build.

  • I've looked in to this a little more. I'm still a little confused by this proposal. So it looks like you want the ability to disable the staircase's solidity independent of the enemies - so you can stand on the staircase while enemies pass through it, or pass through it while enemies stand on it.

    However I'm not sure actually how your suggested "disable collision filtering" action would work, and how that would solve this. The only "collision filtering" the platform behavior does is to filter out any disabled solids. If you disable that "filtering", then it will act like all solids are enabled. So then you will always go up the stairs, never through them.

    So I think I kind of see what you want, but I don't really understand what your proposed action would actually do internally, and how that fixes this. My first thought would be to have a Platform action to say something like "disable solid for this instance only", which isn't anything to do with disabling filtering. Alternatively there could be something like the LOS behavior where you can optionally choose a custom object/family to be solids instead of just using the solid behavior, and then you'd have to have two sets of objects for player and enemy collisions, which could then be separately disabled.

    Either way, the Platform behavior has some of the most complex code in the engine, so I doubt this will be straightforward.