ZeldaVerde's Forum Posts

  • It does loke like the same!

    Although, that was framed like a very multiplayer specific thing, but here Diego has basically said it is Construct's object destruction logic not dismissing a request to destroy something that has already been destroyed.

    So maybe this can manifest without multiplayer in other scenarios too, depending on how things are implemented.

  • Hi again, I'm kind of late to the party but I still want this very bad.

    So, Ashley, are you considering separate buttons for every batch action? I was imagining just anytime you make some change it prompts you with a popup on whether to make that as a batch change or not. Also we need to be able to filter to what layouts we are doing that in some way: I may want to add a "Player" layer to all my Level layouts, but not to my Main Menu layout. Templates and replicas would solve that.

    No need to replicate content, that is just a more messy version of global layers. But that again goes to show that what we want is "just" global layers that don't replicate objects. Can you really not copy that functionality but just remove the object replication? I obviously don't know what the codebase looks like tho.

    About rearranging layers:

    You could make it so, when you try to move a layer, it looks for every layout that has the same exact layer structure (or, in an alternate implementation, every layout that is a replica of that template layer structure). Then, if any, Construct prompts you with a popup on whether or not you want that changed in a batch, and where to move it would be clear as the layouts' layer hierarchies would be the same.

    About option 2, "Replicate sub-layers":

    I like that, but I'd rearrange that as having layouts be the templates and replicas instead of some layer so we don't have to make a layer just for that. Obviously, instances wouldn't be replicated. Layout's can't be matched by name, of course, but I think it is reasonable you make a new option in the inspector for making layout templates and replicas. Although, now that I think of it, having it per layer would also be convenient for other purposes where I don't want the whole structure copied.

    About the "renaming vs deleting and creating new" problem, I'd identify layers by a special kind of id to verify if it is a new layer or a renamed old layer. That could work like:

    .When the user creates a new layer, check if one already exists in the entire project with that name.

    -> If not, assign the new layer a unique id.

    -> If any do, assign the new layer the found layer's id.

    Now, if layers have a different name but the same id, a rename should be applied when syncing.

    Again, note that any batch change implementation would pretty much need some "layout filtering". Just imagine I have a "Particles" layer in my level layouts, main menu layout, and maybe my lobby layout. They may serve different purposes and maybe shouldn't be changed in a batch. I'd have to rename them all to different things if there was no filtering. Filtering, I think, means either UI that pops up every batch change prompting you to select which layouts are to be affected or some kind of predefined groups of layouts (and that would pretty much be equivalent to templates and replicas, so maybe if you go with that just make the jump).

    Option C is also reasonable enough, I like it.

    Tokinsom It's not a matter of "sending a particular signal". The issue is that the user may rename now and only hit "Replicate" later. That is why the batch changes option doesn't have this issue.

  • Hey Diego, I was on a bug reporting streak here as I procrastinated reporting many earlier and I thought I'd report this as a bug as well. But, I can no longer reproduce it. So, did you work on it? Because if not, I'm going to keep trying.

  • Hey Diego, I'd be happy to report a bug for this on GitHub, so can you please just tell me if this is a bug or some feature I'm misinterpreting? Like, is there some "Z image offset" parameter I'm missing?

  • Thanks for the reply, Diego.

    It is set to Auto.

    The problem is also present in runtime, if that wasn't clear.

    Also, TiledBackgrounds (and Sprites) at the edge of the viewport are disappearing. Which I think is relevant because I think that Construct calculates that they are out of sight, but as they are rendered further back, they, in reality, aren't.

    I think this was a result of the deprecation of the old Z rendering mode I can't remember the name of in favor of "Normalized".

    Edit: I have tested tweaking that option. I think "Auto" is setting it to "Yes" because "Yes" changes nothing. "No" completely screws up everything very badly.

  • I skipped a few versions, recently updated Construct, and now this happens (pay attention to what I'm showing with my mouse).

    drive.google.com/file/d/1WFMbTqh9RgIlcSYLB5O9XEhHOdCqh6jx/view

    It seems like the tiled background's image is being displayed at a Z offset.

    Idk if this is a bug or if I'm just missing something, so that is why I'm posting it here. Also, I can't seem to be able to reproduce it in a new project, so if it is I can't really report it properly.

    So, what the hell is that?

    Tagged:

  • oosyrag to the rescue, as always.

    Thank you for the reply, first of all.

    In my game, everyone will be switching layouts at the same time, to the same layout. Layouts are maps for each round to be played in. So, any specific ideas?

    You've already given me plenty to try anyway, thank you. I'm also thinking maybe I could make all synced objects persist thru layouts then manually destroy them on host, I think this would avoid exceptions.

    Edit: I just realized that the persist behavior isn't what I thought it was. I thought it made objects not be destroyed when changing layouts, for some reason.

  • Hey.

    Just a reminder for if anyone reads this that this is not solved and I really need a response so I can continue work on this project.

    Thanks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hi,

    I'm making a multiplayer game (using Construct's Multiplayer plugin) and the engine seems to freak out about destroying synced objects when I try to switch layouts. My guess is that basically if they are not switched exactly at the same time, the engine has a hard time keeping the same amount of sync objects created on host and peers. What is the intended way of changing layouts for Multiplayer plugin games?

    Thanks!

  • Hey Diego, I'm thankful that you were willing to take the time to try and help me, but I felt bad making you do it so I continued looking and found out the problem.

    What happens is: I have an object with the Fade behavior (fade in: 0, wait: 0.2, fade out: 0.001) that is also synced thru multiplayer, and it appears that when multiplayer tries to destroy it on peers after it is destroyed on the host, both it and the Fade behavior queue the destruction, making for 2 calls (as you've described) that are causing the exceptions.

    On that note, it also seems there isn't a way to disable the Fade behavior in runtime (as in the "time of running", not the runtime object) for me to do it for peers, or am I mistaken?

  • Yes, and I can't just make a minimal project because I have no clue where the issue is. Would you be willing to take a look at it then?

  • So what can I give you to help? Also, I'm pretty sure nothing is being destroyed when it happens, at least not externally (by my code).

  • Yes, exactly. What then?

    edit: could you maybe tell me what methods internally call getInstances() so I can look for places where I use those?

  • Yes that seems logical enough but I tried that immediately as I do and couldn't quite figure it out clearly, seemed a bit "random". Is there any way to maybe log whatever 'e' is, internally, for _FlushInstancesPendingDestroyForObjectClass(e, t) so I can then track it?

  • Hey Diego, thank you for taking the time. I was just looking at the new 3D features btw and I'm super excited, congrats on the work!

    Anyway, what do you mean exactly by "when your game produces the error"? If you mean what occasion causes it, I am clueless.