Sorry, afk. Your saying that the 0s returned in actually less than 0?

What I am expecting is any one touch to return a unique ID that whilst that touch remains is used to distinguish it from additional touches, the incrementing seen in edge/ie is not required, but to be an id it must be unique.

I have a mechanic built in edge where I use multiple moving touches, each traced by their IDs to reposition a sprite. This falls over in chrome and Firefox. Chrome at least did generate IDs to be fair and I suspect since it I recycling them (arguably unique for that moment, but not useful for recording, that would need an accessory method), I just need to clear variables on touch ends to ensure it knows a repeated number is a new one. Perhaps clearing them to a negative number to work with both ie/edge and chrome. I don't know what Firefox is doing (I don't normally use it perhaps touch is not enabled in the sameway?). It only returns 0 and therefore would be useless - are you saying it works in Firefox?

Thx for helping

Sorry, I didn't see reference to this elsewhere. Thanks for investigating.

Problem Description

TouchID should return an arbitrary and unique number to identify a specific touch.

Attach a Capx

https://1drv.ms/u/s!AnzkE7yFwDAQgepoehUyuxH86oYhjQ

Description of Capx

This capx has a single code line and one text box

Event: Touch/ on any start-----Action: Text/Set text to "TouchID: "&Touch.TouchID

it should update the TouchID on every touch and display it.

Steps to Reproduce Bug

• Run capx in each browser and touch away.
• Observe the reported TouchID numbers displayed on the screen
• Repeat in other browsers Observed Result In Edge/IE first TouchID gives you an 'arbitrary number' which is incremented by 1 with every subsequent touch. Other browsers do their own things: chrome returns a number that could be similar to the index or count, but I didn't determine. Firefox just doesn't do much. Expected Result TouchID to give you an 'arbitrary number' which is incremented by 1 with every subsequent touch in every browser. Affected Browsers
  • Chrome: (YES)
  • FireFox: (YES)
  • Internet Explorer: (NO)
  • Edge: (NO)

Operating System and Service Pack

Win 10 anniversary update 64bit

Construct 2 Version ID

C2 v233

Hi PixelPower, and thanks for the nice comments. We can see a couple of tweaks we can make after judging, but I had been considering that if only to test the exporting processes!

Thanks again.

Hey heyguy,

Thanks for playing and for the feedback (we've noticed a few c2 games in the jam).

They are judging the jam now, so I don't think we can change anything. 4 colours was the limit, but I expect that could be improved, but we also liked the fact that some of the moving floor patterns could confuse also.

There were two of us. I can guess I put in 20 hours, mostly programming and my colleague more, he also did the majority of sprites and sound.

Thanks again.

Our first long running Construct 2 project just got briefly delayed for a GBJam.

Rules were 160x144 screen, 4 colour pallete and all assets made from scratch.

It's an auto runner in a casino where you gamble to prolong your existence (not real money!) - there is a hole in your loot bag so you need to keep replenishing money to keep going:

https://wertandrew.itch.io/casino-heist

Nice to hear what you think.

Cheers

I would always say work on the core mechanic using crude placeholder sprites, if the game is fun/works, then the art time is justified. I think I would change that rule only if the art was essential to the mechanic. Once core mechanic is fine, move onto next accessory mechanics.

I haven't seen your capx, but it sounds like simplest option would be rather storing uid as global, set a boolean or similar on the instance. Then you can identify all projectiles that meet the criteria by their instance variables. At the moment it sounds like subsequent grenades overwrite the uid of their predecessors, which are then lost.

It is the same as this?

Ashley closed it before a capx was loaded, but it was reproduced recently.

I reported this odd Edge bug here:

key-down-events-with-a-physics-tilemap-can-fail-in-edge_t180804

Unconnected reported a similar bug with the 8 direction behaviour that I could reproduce in a simple form:

viewtopic.php?f=146&t=181063&p=1063895#p1063895

Out of curiosity I switched a minimal capx to car movement behaviour and also platform behaviour. Both have the same 'key down' bug in Edge.

This seems to be a pretty fundamental fail with Edge that will affect many games and is not unique to the oddity I first reported.

Ashley suggested filing a report to MS and I have since found what seems like a related (confirmed) bug already reported: https://developer.microsoft.com/en-us/m ... s/7979936/

I wanted to add to this bug report, or file a new, but am pretty computer ignorant and wondered if anyone would care to help to describe exactly the environment and problem observed. My lay description being "key events stick in html5 games"

Thanks for any more technically convincing descriptions.

Unconnected,

I think from html14 you are on win 10 anniversary update? I have suspicions this is a new issue in Edge

PS. I can reproduce this, but on quick testing the key down fails are only on the 8-direction behaviour controls not another key that is unrelated.

Are you previewing in a specific browser and do you get the same problem in all browsers?

I experienced something similar in Edge under fairly specific circumstances: .

I'd be a bit concerned about developing a project with a core mechanic issue, personally.