faulknermano's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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...)

  • I've got bitten by a behaviour related to Global Layers and Global Objects and I wanted to open a discussion about understanding how these two work, especially in conjunction with each other.

    My case is about making a GUI. In its simplest form, the GUI has a 'frame' and has 'buttons'. The 'buttons' are Pinned to the 'frame' and the 'frame' animates up and down; the 'buttons' being pinned, follow the 'frame'.

    As recommended by the manual for GUIs, I make my GUI layer Global, and set things like Parallax, Transparency, etc, so that the layer settings carry itself to other layouts. The problem that arose, however, was that Objects inside the Layer were getting destroyed, and then recreated again. And that's a problem because all the Pinning setup I did at the start of the layout is broken because the Pinned UIDs all changed.

    Then I tried making the Objects Global, too. But that wasn't correct either, because the objects started doubling up. The Global Layer kept on creating its objects, assuming that the objects that was on that layer was going to be destroyed, but they weren't, because they were Global.

    So I switched off Global Layers altogether and manage everything as Global Objects.

    However, this behaviour is a bit counter-intuitive for one reason. If Global Layers were going to recreate the Objects on the new layout, why destroy them in the first place?

    (A.) I think it would have been better to separate the 2 features of propagating layer settings separate vs 'propagating' objects through layouts. In this way it is apparent to the user what is being 'persisted' in a Global Layer.

    (B.) Like I said above, if Global Layers were intended to retain Objects then it is expected that those actual objects are considered global, in the same sense that Global Objects are global; they are not destroyed, and whatever parametric options attached to them are unchanged.

    I could have lived without (B), but because of (A) Global Layers have suddenly become unworkable; I can't even use them for unifying Layer settings because the Global Layer wants to keep on recreating its objects. I can't turn off that behaviour.

    However, if I'm missing something here, I'd appreciate any thoughts.

    Thanks.

  • Set the Layout Size (Project Properties) as the same as your Window Size (or vice-versa, whichever is applicable).

  • Well, as a follow-up -- for the sake of historical records, I guess -- the Auto-save/Auto-backup seemed to have a helped for the past days since turning off Auto-save. At least it was saving quite quickly. Unfortunately, it has done it again. And, like before, it stops on 'Saving project settings...'. The progress bar is up, but shows no activity.

    As a last-ditch effort, I will downgrade to r250 which is the build I was on before upgrading recently.

  • In the same Condition in which you pick ansBox, you can put another Condition which selects the 'trueFalse' Text instance. Put something like:

    Pick trueFalse instance loopindex("i")[/code:mebxa4zi]

That's assuming that `loopindex("i")` corresponds with the 'trueFalse' Text instance number.

  • I think you need to pick a 'trueFalse' Text instance also. I think that's why everything is set to True.

  • Stab in the dark: the things I think of when something is not showing up when it seems like it should:

    • Layer is invisible or opacity=0
    • Object is out of screen
    • Object size has been reduced to a very small dimension
    • Object is behind another element (ie hidden)
    • Object blending modes
    • Object animation is not in expected frame