DiegoM's Forum Posts

  • It's difficult to tell exactly what is happening, but since you said you are using some javascript, is it possible that some of those snippets are using the await keyword?

    If that is the case, the javascript is asynchronous and needs to be waited for before continuing if you want to keep things running sequentially.

    construct.net/en/make-games/manuals/construct-3/scripting/using-scripting/scripts-in-event-sheets

  • I think the problem is that "On key release" is a trigger, you can tell by the little green arrow next to it.

    Triggers are only executed when they actually happen, in this case when the key is released. This is in contrast to regular conditions, like "Key is down", which are checked continually.

    In your case you can use an inverted "Key is down" event. This will continually check if the chosen key is NOT pressed. Then you can do what you need while the key is not pressed.

  • This is a rather simple example showing how you could organize the steps to start and complete a quest.

    dropbox.com/s/yp6skx37lr0uvky/SimpleQuestSystem.c3p

    There are comments for all the important parts, so hopefully you can use it as a building block for something bigger.

    Not too sure what the best way be to handle multiple quests on the same layout would be... I'll leave that to you :)

  • There is a relatively new Tilemap action, called "Set tile with brush" which basically does the same as the editor.

    The action just needs the coordinates and a brush to be set in the editor.

    This is a very simple example on how to use it to set a patch of 3x3. Try it out with the pre-configured brushes for the default tile set. 

    + Mouse: On Left button Clicked
----+ System: For "x" from 0 to 2
--------+ System: For "y" from 0 to 2
---------> Tilemap: Set tile (LoopIndex("x") + Mouse.X ÷ 32, LoopIndex("y") + Mouse.Y ÷ 32) with brush Brush 1

  • Sounds like you already tried storing the coordinates and they seem to not be useful, but you can make them useful.

    Try turning the absolute coordinates into relative coordinates, that way you will be able to use them for different instances.

    After you store all the player positions into an array, you can then create a new array with the corresponding relative coordinates.

    The first element of the relatives coordinates array will be 0,0 because that is the starting position. Each subsequent element is the difference between itself and the previous element.

    Ej.

    absolute coordinates: 100;100, 200;100, 300;300, 400;500

    relative coordinates: 0;0, (200-100);(100-100), (300-200);(300-100), (400-300);(500-300)

    You can then use the relative coordinates to tell any instance to follow the same path but from their own position. So the first place is 0;0, so they stay in place, then you add the following offset to your current position. You continue moving by the offsets until you reach the end.

  • This feature is still not supported. Can't really tell when it will, but it is in the TODO list. I wouldn't suggest waiting for it though.

    In the mean time you'll need to rely on doing any kind of mesh animations using events, which is less than ideal, but I can't think of anything better.

  • WackyToaster That note was for the editor only. I meant that in the editor, adding or removing children from a template will not be reflected in the corresponding replicas. I'll update the original post to make it clearer.

  • I would try setting up an endpoint on your website so that you can ask for the information from it by using the AJAX plugin and making a GET request from your game.

    That means that your website could have something like this

    https://www.your-website.com/my-end-point

    When you make a request to that URL, it should return the information you want.

    You would need to make sure this endpoint, asides from responding with the data you want in the body of the response, also responds with the header Access-Control-Allow-Origin: *, so your game can request the cross origin content.

    That last bit is important because AJAX requests to a domain different to the one the game is hosted in, will be blocked by default.

    Not sure how familiar you are with anything of that. It shouldn't be too difficult... as long as you know what you are doing.

  • LetTheMiceFree

    Right now they are independent features.

    If an instance is set to be a template, even if it is on a family with other object types, it will only affect other instances of the same object type.

    We went with just working with instances of the same type to simplify the initial implementation.

    Maybe this can be added in the future if more people think it's useful.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • At the end of your event sheet keep track of the last mouse X position in a variable. At the beginning of the event sheet, compare that value with the current X position of the mouse.

    If the current position is greater than the last position you saved, then you are moving to the right, if the last position is greater than the current one, then you are moving to the left. If there is no change, the mouse is not moving.

  • hcatarrunas

    Scoremonger

    The idea behind not highlighting is that in the case the replica is using it's own value, then nothing unusual is happening, it's just the normal behaviour.

    The UI aspect is not set in stone though, it's not like we spent a lot of time deciding how to show it :P It's mainly like that because timeline editing already is handled in a similar way. In fact, you might want to check out how it looks when you are animating a replica instance in a timeline.

    birdboy

    I have been concerned about colour blind users, and noticed that the light colours we are using for highlighting in here and in timeline editing, are probably not very useful in that regard.

    Using an icon on top of the colour change would be quite good to solve that problem.

  • brushfe

    As of the latest beta, r286, there is a new option you can use in the configuration file. Adding the "use-raw-folder-names" property with a value of true will make the importer use the folder names as they appear in the imported files.

  • Introduction

    This new feature comes in to address a few rather old issues with Construct, which are the following:

    1. Updating several instances of the same object type with different initialization properties could prove to be time consuming and prone to error. Specially in large layouts or across multiple layouts.
    2. No way to define pre-sets when creating an instance at runtime using the Create Object action. Up until now you had to create the instance and then set it's properties in the event sheet.
    3. No way to choose a specific hierarchy to create at runtime, if multiple were created in the editor using the same type of instance as the root. This forced you to use unique instances as roots in order to guarantee the hierarchy that would be created at runtime.

    Granted those three issues could be worked around, from now on you won't have too anymore.

    New terms

    There are two new terms that will be used in this guide.

    1. Template: an instance that has been set to be the source of property values for other instances to use. These include, common instance properties, plugin properties, instance variables, behaviour properties and effect parameters. A template can also be used to decide what values a new instance created at runtime should take when using the Create Object action. Modifying a template in the Layout view or through the Properties bar will immediately be reflected in all instances which are replicas of it.
    2. Replica: an instance that has been set to use an instance already defined as a template. A replica takes it's values from the source template unless they are explicitly modified, at which point the replica's own values are used.

    How does it work?

    The Properties bar now shows a few new properties when selecting an instance.

    Properties bar Property descriptions
    • Template mode: an instance can be turned into a template by selecting the "Template" value from the drop down menu. If there are any instances in the object type which have already been set to be a template, then the "Replica" value will also be available in the drop down menu.
    • Template name: the name to identify a template. This input is only active when Template mode equals to "Template".
    • Template source: the name of the template a replica is using. Only shows templates of the same object type as the replica. The drop down is only active when Template mode equals to "Replica".

    To start using this feature the first thing you will need to do is set an instance to be a template. To do that, follow these steps:

    1. Select the instance you want to be a template in the Layout view.
    2. Pick the "Template" option from the Template mode dropdown in the Properties bar.
    3. Give the template a name using the Template name text input.

    That's all you need to do to set an instance to be a template.

    Now let's see how to set other instances to use the template in the editor:

    1. Select the instance you want to be a replica of the template in the Layout View. The instance must be of the same object type as the template.
    2. Pick the "Replica" option from the Template mode dropdown.
    3. Select the template the replica instance should use from the Template source dropdown.

    After doing that you will notice that some of the properties in the Properties bar are highlighted, this indicates that the instance is taking that value from the source template.

    From now on, when the template is modified, all replicas using it, will reflect the changes. If a replica is modified individually, the affected property will stop taking the value from the template and instead will take the value from the replica itself. To indicate this, the property will no longer be highlighted.

    Miscellaneous options

    Layout view context menu options

    Template context menu Replica context menu
    • Template instance context menu options:
      • Apply template to all replicas: force all replicas using this template to use the values of the template.
      • Select all replicas in layout
      • Open all layouts with replicas: opens all layouts with replicas of the selected template.
    • Replica instance context menu options:
      • Use all values from template: forces the selected replica to use the values from the template.
      • Select all replicas in layout
      • Open template layout: open the layout containing the template the selected replica is using.

    Properties bar context menu options

    When a replica's property is modified and because of that it starts using it's own value, it is possible to individually set it back to use the template value by right clicking on the property name in the properties bar.

    Runtime actions

    The Create Object system action now has an additional Template parameter. When specified the new instance being created will be made to be a clone of the template instance, rather than an arbitrary one.

    Asides from using the properties of the template instance, the new instance will also pick up the hierarchy from the template, if one exists. This means that it is now possible to create different hierarchies in the editor that use the same type of instance as a root, while also being able to choose which one to create at runtime.

    Considerations

    This is the first version of this feature so there are still a few things to iron out. The following are a few things which are not immediately obvious.

    • By default, replicas do not use the position properties of the template. In most cases it is more useful for these two properties to remain individual for each replica.
    • The Spawn another object action of Sprite is not yet supported.
    • At runtime, replicas are no longer connected to their templates as they are in the editor. This means that changing a template at runtime, will not affect the replicas. This applies for properties and hierarchy changes.
    • In the editor, adding or removing children from a template will not be reflected on the replicas. This could be added in the future.

    Here is an example project that can be opened in r286, showing how the feature is used.

    dropbox.com/s/ewh9h1js5ocu46a/Templates%20Example.c3p

    This is it for now. This is the first version, so there is still work to be done.

  • What operating system are you using?

    Recently there was an issue in our tracker that sounds very similar to what you are describing, it was only affecting OSX.

    You can see the report here

    If you are using OSX, you can try what is mentioned in the issue to see if it works for you. Unfortunately if that is the case, there isn't much we can do as it would be an OS level problem affecting C3.

  • Try reporting the issue to Last Pass and see what they tell you.

    We don't work around problems caused by extensions because there are potentially thousands out there causing issues and it would be unrealistic for C3 to handle all possible problems.