Depends I would personally have made the key press on top level, just because they are "triggers" but that's just my way of doing it. But you can still do it if you add it to a function, then you can reuse your code if needed as well.

Function Create_Smoke

---- Pick sprPlayer.UID = Function.Param(0)

(Create smoke)

You then just pass the sprPlayer.UID to it and if you find out you would like enemies or whatever to create smoke as well you can just extend the function

Function Create_Smoke

---- Pick sprPlayer.UID = Function.Param(0)

(Create smoke)

---- Pick sprEnemy.UID = Function.Param(0)

(Create smoke)

From you code that should work as far as I can see.

Instead of using trigger once, cant you just add the smoke effect to the key press? Think that should solve it and you get rid of the checks every tick etc.

> "Is dragging" not trigger on mouse clicks.

>

Let's say, in my project i already have an event "is dragging" that should trigger on mouse click, me and everybody use it like this since r78, if this will be changed i need to rewrite my project. Now let's say it's not about me, about 10-100 or more c2 users. So a breaking change, that will affect almost everyone who use dragdrop, like this, can be applied only if this change will fix a major bug, "dragging behaviour in C2 should work as it does in every other single computer application" is not really a major bug.

Yes of course if a program rely on the dragging behaviour to work with mouse click it will cause problems if fixed and its annoying.

Its not about it being a major bug or not but whether the behaviour works as intended and it might very well do that as Ashley haven't commented on it, so you might be right that it works as they thought it should and then ill disagree with that, but can accept it.

But a lot of bug fixes and new features in C2 might cause problems in projects as C2 is being developed on the fly. Meaning when I bought it, it couldnt do half the stuff it can now. Looking at the page where you download C2 there are links to a stable version and a beta version. How many programs do you know of that you buy, that constantly release Beta versions? they release updates or patches to fix an already fully functional program with all the feature already available. This is not to say that the way Scirra does it is bad, just that when you release a program this way, making fixes and adding new features all the time things can go wrong that annoys users and causes them to having to change certain things.

For instant I have not long ago made a lot of bug reports regarding the video object causing all sorts of problems, where I had to make lots of workarounds to make my program work. Then I made a report about some audio problem and video, that was fix in r207 and suddenly most, if not all, the other video problems that I made bug reports for have been fixed as well, even though its not stated in the r207 release, so now my program contain a lot of workaround code that needs to be removed. Yeah its a bit annoying now, but its much better that these things now work as you would expect them to whatever the changes Scirra made in r207 that solved them. Then I should complain about that to Scirra as well, because I have to remove my workarounds in my project? that would make little sense, I think its great that they are now fixed.

This is not a bug, it's by design, you're asking for a behaviour's new functionality, not for a bug fix, so better post it to Construct 2 General forum as a feature request, but i don't think that everyone will agree with your vision of how dragdrop should work, just imagine how many projects are already rely on the way it works right now.

Not sure what you mean or how many projects would be affected. In theory the only change is to make "Is dragging" not trigger on mouse clicks. Despite that I don't see why anyone would disagree that the dragging behaviour in C2 shouldn't work as it does in every other single computer application out there, including C2 it self?

Isn't it more important that things work as you would expect them to rather than trying to invent your own way of doing it, especially when its been done like that for ages and is expected behaviour for anyone using a computer today. Im sorry but I don't get your point why this should be suggested as a new feature, unless you ofc is correct that it is made this way by Scirra, because they believe a dragging behaviour like in C2 is much better than the normal way, but I seriously doubt that to be the case.

Aquadijoib solution should work.

However you are better off getting used to not use every tick for something like this. Even though it in this case shouldn't hurt to much, but as you start adding more and more things to every tick events then you will loose performance in the end.

Since you only need the score to update whenever the score changes making a function that update it for you will be a better solution. And you just call this function whenever it have changed same goes for your Health bar.

If you are unsure how to use functions I would highly recommend you to learn how to before you get to far into your game.

what you mean is: if the object is not moving and it was a single click and release then "Is dragging" should not be triggered, but if the mouse click holds for a sec then "is dragging"?

Well what I mean is that it should work exactly as dragging a window/program/browser around in Windows. So "Is dragging" should trigger when dragging is currently taking place, as you would expect from the name "Is dragging". As you mentioned yourself with "On drag start", that could to some degree be triggering when a click happens, even though it still wouldn't be correct in my opinion. Because from the name "On drag start" it would be more correct that it triggered the moment Dragging was happening and not when a mouse click happens, because a mouse click is not a drag event, but a click event. But it would be more correct I think if "On drag start" triggered when a mouse click was encountered rather than "Is dragging". Because "On drag start" is a trigger once condition like "On created" etc. Where "Is dragging" is a trigger that is tested against every tick, so it shouldn't activate on a trigger once condition in this case.

drag means it will move with mouse you dont need to tell it to move to that position, you have to do "on drag start" set position to mouse.x and mouse.y to center it, then it will move by it self thanks to the dragndrop.

I don't agree with you, because if you look at the normal behaviour of any program, like your browser and you press and hold the mouse button down on the top part of it you can drag it around.

If it worked like the dragging behaviour in C2 you could press anywhere on the top bar where you drag it and the browser would jump to the mouse cursor position, which I at least, wouldn't refer to as dragging the window around. I think its normal for anyone when the words "dragging something" is used, that you would expect a behaviour like you see in windows and not stuff suddenly jumping around depending on where you click.

So "On drag start" is not a solution as I see it. Because the behaviour you expect is nothing like it is in C2 currently.

This is not a bug, its normal picking in C2. When the red square overlap the blue squares it picks all blue squares that meets the conditions in the case as you overlap both it picks both of them and then execute the code, so the counter should be 1 as you write.

Since you are working with several blue squares you have to add a "For each Blue square" to the condition, then it will count them separately and the counter will be 2 when you overlap both.

Problem Description

When using the dragdrop behaviour and you use "Is dragging" it is triggering on just a mouse click as well as when being dragged. Which seems wrong as you already have a condition for "On drag start" which you would expect to trigger on mouse click and "Is dragging" should work only with mouse down for instant.

The problem with having "is dragging" trigger with mouse click is if you are making a snapping functionality the object snapping will move as you click it. And also the functionality doesn't seem to match what you would expect when the word "Is dragging" is used.

Attach a Capx

https://dl.dropboxusercontent.com/u/109921357/DragDrop_bug/DragDrop.capx

Description of Capx

A sprite with dragdrop behaviour that will snap to the mouse position when "Is dragging"

Steps to Reproduce Bug

Single click anywhere on the sprite and it will trigger the "Is dragging" and jump to the position. But single clicking the sprite should not be considered dragging.

Observed Result

Sprite jumps to mouse click position

Expected Result

That nothing would happen, meaning the sprite would simply stay put.

Affected Browsers

• Chrome: (YES/NO)
• FireFox: (YES/NO)
• Internet Explorer: (YES/NO)

Operating System and Service Pack

Windows 7

Construct 2 Version ID

r207

Not sure if its possible to change color of the form control progress bar, maybe with CSS. But its just a guess.

You can turn a sprite into a progress bar like this:

Sprite width = 500 (Just the original width of you sprite)

Max_health_Player = 100

Current_health_Player = 20

Set Sprite.width = (500 / Max_health_Player) * Current_health_Player

In this case the Sprite width would be 100 px

If Current_health_Player is 50 the width would be 250 px

You could still make it easier to deal with this type of bug report: it unnecessarily refers to paths that don't exist on my computer. This means I can't just open the .capx and press run to see the issue - I am forced to make changes, and that increases the chance I do something differently to you and don't reproduce the issue. I could not reproduce the problem with the file deleting, it deleted just fine after I made the changes for anything useful to happen. The audio-keeps-playing issue actually reproduces with a project file in Chrome so you didn't need NW.js, hard-coded paths or file deletion. Please take this seriously as I deal with a very large number of bug reports and it can really slow things down if bug reports take extra work to deal with. Anyway, the issue should be fixed for the next build.

Appreciate that it gets fixed.

Regarding the whole bug report thing, I take it seriously and report a lot of issues, which normally gets closed even though the bugs still exist. I fully understand that for you to fix bugs you want simple programs to test. And in most cases I provide them, except when the issues requires to add 1-2 objects and follow the description in the bug report.

Regarding you having to change path in order to test it, I don't see how I could get around that. In earlier bug reports where I have used a path to a generic location such as "C:\" the bug reports have been closed because it should be in my user folder. Since my username is different from yours, what exactly can I do? If I use "C:\" you close it because it needs to be in the user folder, and if I put it in the user folder you complain that you have to change it, because it doesn't match your path, it doesn't exactly leave a lot of options.

From another bug report you answered:

[quote:20ksxuzc]

The original report still has a few issues:

• you are not sharing the images you are testing with (i.e. the Test.jpg file). You need to share everything your bug report uses to ensure I can reproduce exactly what you are doing.
• you are still submitting reports based on accessing files in C:\, which is normally an admin-restricted folder. To rule out admin permissions as the cause of any problem, only access files in the application folder or user folder. (A global variable with the root path would be a good idea, so it can easily be changed if need be.)

I'm going to close this report again, please file new issues (one issue per thread) respecting the above if you want this investigated further.

When someone make a bug report, they do it because they are not always sure what the problem is and where exactly the problem occurs, so in some cases several issues might be in the report, its not always easy to know exactly what is relevant or not, so you make the report as close to what you did when you experienced it, and if your test capx does the same as the original problem, then you provide that capx or description, regardless of whether all of it is related to the problem. You can't always expect your users to know exactly what causes certain issues, before they make a bug report, I think.

So if you test the provided capx or read the description and you can reproduce it, and some things turns out to not be related to the problem, that's just good, then its easier for you to focus on the actual problem. No one expect bugs to be fixed straight away, but to see your bug report getting closed, due to something that is not even related to the bug it self, is really annoying for the user, because they didn't make the report to annoy you. But it gives the impression that your bug report was closed because there was a spelling error or something and therefore you don't care. (Know that's not the case, but just to underline it)

When it comes to bugs that involves files, how can you be sure that the files used are not copyright protected and therefore users are not able to share them or the size of the files are to big like in my case etc.?

So even though I wrote that the file was a gift to you as a bit of a joke, I actually meant it. Because I don't get why you don't have a set of test files that you use, that you know works, since you know that the one I send you works, you can use that. If the files (Audio, video, image) people are using were corrupted they would most likely not work in the first place, so wouldn't be reported anyway.

So as I said, no one expect bugs to be fixed straight away, just that they at least gets looked at, I bet you that in 99% of the cases if you instead of closing reports made a dialog with those reporting them, if you can't reproduce it or think something is missing, you would get far better feedback and happier users, you answer people before closing bug reports anyway, so whether they are in closed forum or in the open, shouldn't really matter, especially if the user reporting the bug, still experience it.

> Bump.

>

> I'm loading some assets externally for an editor. If an image is loaded, then the source image modified, then uploaded again, nothing happens. I can only assume this is because C2 is loading the image from memory instead of reloading the source image. If that is correct, then I support this request.

>

If you are using file chooser to pick the file and picking the same file it's quite likely this (it's not even loading):

Have the same problem, but as I recall the reason for this being so, is to minimize the amount of data needed to be downloaded, which makes sense if that Is what you are worried about. But if its not, the consequence is that you need to make a memory inefficient workaround, which makes little sense to me. I fully understand why it original is designed to work as it is in regards to the problem is trying to solve, but not why it justify that if that is not your problem, then being able to unload from memory is not needed, as its two different problem/issues that clearly doesn't share the same worries.