See image.

Use a cooldown timer and count down per tick (subtract the cooldown timer by `dt` -- delta time). Only when cooldown timer is <=0 can the player attack.

In the image above I did not cap the cooldown_timer to 0, so it will keep on counting down. You should put something like, if cooldown_timer < 0, then cooldown_timer=0.

That's just my Windows 7 classic theme colours. Then in C2, I use either the 'Basic' theme, or the VS 2008 theme.

Here's a cheat.

The deceleration is always constant. So assuming your actual moving speed is always the same (like you said), the braking distance is constant, too. You can actually measure the braking distance by capturing the X position of the Sprite when the key is released, and then capturing the X position again when the Sprite stops.

EDIT: whoops, looks like R0J0hound's got the legit answer.

Just reporting in after 2 weeks of working in C2. Btw, for context, my observations are based on working full 12-18 hour days, 7 days/week. I happy to report that after 2 weeks after switching from R256 to R250 I have not encountered the Save lock-up bug. This, more or less, confirms my recollection that this bug was never present in R250 to begin with.

Because this is an Editor bug, I'd be willing to road-test R251 up to R253 (it is known that R254 has this save lock-up bug) in the same conditions as I've been using R250, if only to have a behavioural comparison for some 'speculative' debugging of the Editor's code between the builds -- to know in which build the save lockup bug started ocurring. But I can only do this if there was some interest in solving this bug. If not, I won't be inclined to risk the integrity of my work.

Thanks for listening.

+1. I didn't know about this. Thanks for the info !

R250 is ok?

Yes: I've been using r250 for a long time before I had recently tried to upgrade to r255, that's why I had to 'report' it. There was/is no saving issue with r250 as far as I know.

[quote:4amru9uv]but I have several projects saved with r254, so it wouldn’t work downgrade to r250.

Do you know you can change the requirements in a capx (and caproj)?

A capx is only a zip file; so you open the capx in 7-zip, extract the caproj inside that zip, then open it in a text editor. Near the beginning of the caproj look for this tag:

<saved-with-version>25400</saved-with-version>[/code:4amru9uv]

.. and change the value to 25000. Then drag the caproj back into the capx (zip).

[quote:4amru9uv]But it would be helpful to find if it happens randomly when it saves, or if it’s related with something, like project size, any particular event/behavior added before the bug happens.I’ll dig a little bit more to see if I can get any clue on this.


I had this *feeling* that it may have been related to the removal of a lot of assets (and possibly the resulting removal of events). But, actually, it also happened on a ordinary situation. I can't reliably produce it.

cesisco, yeah, I've not also filed a bug report because it's just not reproducible; where do you start? But it is happening. I couldn't work like that so the r250 downgrade was necessary. The problem I have is that I'm not willing to upgrade for possible future bug fixes if this fundamental issue of saving is not addressed.

It's only a hope, but I wish the Ashley will take a look to do some speculative debugging on this issue. I *know* that r250 does not freeze. At least that's a clue.. I think?

Your issue might not be the same, but when using r255/r256, C2 freezes during save. It was slightly helped by turning off Auto-save and (using a custom backup solution as an alternative). Unfortunately (for me) the freezing came back, and so I downgraded to r250 and haven't had the problem again.

In the way Construct is working, it does make sense.

Sure, I understand, but I think it is a question of benefit; which is more beneficial/advantageous.

[quote:24rzefc8] It also allows you to make any modification for special case (imagine in Layout 3 you would want a different animation frame to display. Or to change some text, with this, you can and are not blocked to an UI you have set once and cannot modify afterward).

In the case of Layout 3: if Global Layers could persist (not destroy) objects, then the changes I would like to do for GUI elements will be executed under a Layer 3 event sheet. It's an 'additive effect' of applying changes to existing objects rather than recreating objects from scratch and then applying attributes again. The most clear and efficient place to make a change is the place where the change should happen (in the event sheet under the Layout that is executing it).

[quote:24rzefc8]I'm not sure how to set it "easier" considering Construct is an engine that has to cover a lot of possibilities and minds at once.

Sure, but I'm also a programmer, so I'm speaking more about how data being destroyed and how that even makes sense on an application design level.

Global Layers can be discrete entities in themselves, only concerned with the settings of layers. If Global Layers did not do anything with the objects at all then it would be fine. For example, if a Global Layer contains non-Global objects, then those objects will be destroyed, which is fine, because that's expected. But, it should not try to recreate it. Why? Because it allows me to be specific with what I want to be Global Objects. If I make them Global Objects, the Global Layer only cares about it being a layer, so it applies the layer setting but nothing else. So the result is I have a Global Layer with correct settings which contains Global Objects; all my data is preserved.

But what is currently happening is that Global Layer insists on creating objects that was put under it. If I set my objects to Global, the Global Layer will duplicate it nevertheless.

That's what I mean by 'application design'; the data handling is not neat or logical. I'm just discussing this as a matter of discussion only, because, like I said, I do 'application design', and I guess I'm still ranting.

[quote:24rzefc8]TBH though, with included event sheets, it is working pretty OK.

If you add a new layout, all you need to do is add the proper layer and include the event sheet, and your UI is done for this new layout.

Yes, I know the technique is sound and is elegant. But to be fair, I have tried that setup in other projects, but the one I'm doing is a different use-case with a lot of external data and moving parts. It was just too much data-man-handling to work.

Hi Kyatric thanks for taking the time to set-up a capx.

Object's destruction is linked to how layouts are working.

In the absolute, I understand your discussion and the point you are trying to make, but you are discussing it for a software that won't have new features at this time.

Yes, I understand that. I suppose it's a sort of a catharsis for me.

[quote:v045ys3w]

Pin behavior doesn't need a UID. An expression of its do provide the UID of the object it is pinned to.

Otherwise, it absolutely does not need a UID to work.

Add an instance variable to your objects, if they are reused elsewhere where they need to not be pinned, so that you will pick only the appropriate instances to pin.

The important thing to note about your capx is that you run the Pin operation (in esUI) every time you go to a new Layout, which you must do if you want the Pinning effect to remain. That is what I wanted to point out: that the Pin operation requires to be repeated, which is not logical in a workflow sense. However, I also understand that you are demonstrating a workaround for me, and I appreciate that very much. Thanks.

[quote:v045ys3w]Again, it would be easier to help out if you did provide the actual content of your project to point out where you might have gone wrong.

I really appreciate the helpfulness, however my content is a bit complex (and huge). I have used the Global Objets workaround because there is so much initialisation that's going on both external data and computed data that initialising the variables and relationships (ie Pins and others) everytime I change layout becomes too crazy and convoluted.

This post was partly just a rant. But like you said, there's no point, because C2 won't get that sort of change.

[quote:v045ys3w]I invite you to open this discussion for Construct 3 if you feel like it.

Might do; could do some good...

Thanks for replying, oosyrag

I can see how the naming can cause confusion, their function is significantly different.

If you are using events to set up your GUI global layer, you can have those events included in other layouts' event sheets as well.

I understand that their function is different as a matter-of-fact. However, I am emphasizing that though Global Layers have a generic functionality/behaviour, they were intended to solve a specific problem with GUIs. But the destruction of objects is not 'logical' from that respect of GUIs. Object destruction significantly narrows down the choices you can have in creating GUIs and using Global Layers to do so.

For example, if we were storing variables in these GUI items, you will lose them. You need to store values in a persistent object (e.g. Dictionary). Though this is a trivial example, the rationale is clear: Global Layers, meant to address the persistent GUI workflow problem, need to persist its data beyond the Global Layer settings or the mere existence of its objects. It needs to also retain the integrity of the data of those objects.

[quote:1eu4kl8y]

Generally speaking you shouldn't be referring to a specific UID where it would matter if the UID changes, but without seeing your specific setup I am unable to give any advice on how to work around this.

The best example is what I described in my first post: a Pin behaviour needs a UID, and that's behaviour-specific; nothing I can do about it. If my 'parent' is destroyed, the Pin is nullified. I need to pin again. By pinning again, I set up my GUI in the layout I just jumped into, which makes setting it up in a separate GUI layout pointless.

(Even if Global Layers recreated the variable data from the objects it destroyed, the Pin behaviour needs to re-associate the Pinned UID with the new object UID. And that route is buggy route; so why destroy objects in the first place?)

Therefore, it seems that the workflow/dataflow logic behind Global Layers is not designed thoroughly enough, unless there was a specific reason why objects had to be discarded.

My current setup has changed. I have no more Global Layers as its logic introduces more opportunities for inconsistent data. Global Objects are easier to manage on their own and I'm rolling with that. Because of this issue, my solution is simply limiting the number of layouts I have, so setting layer properties is workable.

(When the C3 Editor SDK was announced the first time, I really hoped it was an Editor SDK in the likes of Unity. It would have offloaded so many run-time issues by automating stuff in the Editor. Alas...)