DiegoM's Forum Posts

  • This isn't possible, you can however, define your properties in the constructor and initialize them to default values and then define an initialization method that receives your custom data.

    Something like this: 

    	class Projectile extends ISpriteInstance {
		constructor()
		{
			super();

			this._foobar = null;
		}

		Initialize(foobar)
		{
			this._foobar = foobar;
		}
	}

    Then you can do this 

    	let projectile = runtime.objects.projectile.createInstance("main",playerObj.x,playerObj.y, true)

	projectile.Initialize(/*your custom data goes here*/);

  • Ah ok, I was asking because that fix wasn't specifically related to your issue, so the problem you were having might still persist.

  • Have you tried it out to see if it solved your problem?

  • dop2000

    If I recall correctly I didn't do it the first time around just to get something out.

    In the mean time, it is now possible to copy and paste animations between object types. You can copy them using the context menu options of the animations panel or keyboard shortcuts (make sure focus is on the animations panel by clicking on it), close the Animations editor, open it again for a different object type and paste in the animations panel.

    You can copy individual animations or sub folders.

  • Not really sure exactly how you plan to save and load all the data, but as far as creating inheritances in Javascript, just go with classes.

    Prototype inheritance (and everything surrounding it) is legacy at this point. Classes will do the same (and a few extra things) and are much easier on the eye.

    One thing to note is that, even though prototypes are legacy, they are fully supported, so you can use them if the opportunity arises. If you are still figuring things out though, just go with classes they will likely cover 99% of the cases.

    Depending on your needs you might be able to get away with something easier though.

    If your data objects don't have nested properties (properties which are objects or arrays with more data in them), you can rather easily use Object.assing to create a new object with the properties from a list objects. 

    Object.assign(
// the new empty object were all the properties will be applied
{}, 
// The first source object to copy properties from
{
	x: 0,
	y: 1,
	name: "foo"
},
// The second source object to copy properties from
{
	name: "bar"
	damage: 5
}
// As many source objects as needed can be added
);

    Something like that, will create a new object that looks like this: 

    {
	x: 0,
	y: 1,
	name: "bar",
	damage: 5
}

    The properties of the first source object are copied into the target (first empty object), then the properties of the second source objects are applied onto it, any existing properties are overwritten and new ones are added.

    Using this approach you can allow the player to select a base item, then a specific one, merge them and the result becomes the new item.

  • Been meaning to respond to this, but just could not write a comprehensive answer.

    The short answer is that there is no built in method to do this with the JSON plugin.

    Any solutions would need to be through Javascript scripting and even then it wouldn't be trivial. Definitely possible, but not obvious.

    What you are describing is basically this

    stackoverflow.com/questions/27936772/how-to-deep-merge-instead-of-shallow-merge

    I think it would be much easier to have a file with the common properties for items, that everything will use, and also properties which refer to specific "classes" of items. Something like this: 

    {
	item: {
		common: {
			"a": "common-prop-1",
			"b": "common-prop-2",
			"c": "common-prop-3"
		},
		classes: {
			"axe": {
				"a": "axe-prop-1",
				"b": "axe-prop-2",
				"c": "axe-prop-3"
			},
			"sword": {
				"a": "sword-prop-1",
				"b": "sword-prop-2",
				"c": "sword-prop-3"
			},
			"bow": {
				"a": "bow-prop-1",
				"b": "bow-prop-2",
				"c": "bow-prop-3"
			}
		}
	}
}

    Then have another file with the specific items, which have their own unique properties and an ID to the common properties for the class of item. Something like this. 

    {
	items: {
		"hand-axe": {
			"a": "hand-axe-prop-1",
			"b": "hand-axe-prop-2",
			"class": "axe"
		},

		"great-axe": {
			"a": "great-axe-prop-1",
			"b": "great-axe-prop-2",
			"class": "axe"
		},

		"excellent-axe": {
			"a": "excellent-axe-prop-1",
			"b": "excellent-axe-prop-2",
			"class": "axe"
		}
	}
}

    So when you want to look up information for an item, first you look up in the specific file, then you look at what is the "class" of the item, and use that to do another look up in the first file. The common properties don't need a specific lookup, you could just get them because you known before hand every item will have them.

    This could also be arranged in a single file, this was just an example.

  • So reallizing that they are supposed to behave the same in editor (which they sadly don't fully do yet). I agree that this distinction is more confusing then helpful.

    What do you mean by "don't fully do yet"?

  • brushfe

    I understand what you are getting at, it's a detail which is not really important for the end user.

    In hindsight, the distinction should have been left as an internal detail, and just call all the layers involved global as far as the UI is concerned.

    But since the information was already exposed to begin with (this is a pretty old feature at this point), in the Properties Bar, I decided it was better to be consistent.

  • A layer that is not global, but it is taking it's content from a global layer, by having the same name, is marked as Overriden, because it's own content is being replaced by that of the global layer.

    Before, this detail could only be seen in the Properties Bar next to the Global property of a layer.

    Now the information is more visible, because it is also shown in the Layers Bar. It's only a cosmetic change, to make the information a little bit more clear.

    Do mind that in the current beta there is bug where if you try to rename a layer which is global (or overriden), the part which is in parenthesis can become part of the real name of the layer. That has already been fixed.

  • When you preview ads locally, what you are seeing are test web adverts.

    Asides from being test ads, they also simulate frequency capping, so you are able to adjust your logic in the case an ad can not be shown. It alternates between a successful request and a failed request.

    If you handle both cases properly then your game will behave properly when it is showing real ads.

  • I see, maybe try picking a any random image point if the enemy is far enough, doesn't matter what the end position will be. When they get at a certain minimum distance make them move in directly into the player position.

    In the case the player walks away from the minimum distance, then pick another image point randomly so the enemy will take a slightly different direction.

    You could also try changing the image point they are following midway, so they won't go in a straight line.

  • Have you tried to make them follow a point different to the player position?

    You could set up a hierarchy of invisible placeholder instances around your player character.

    Then at runtime, instead of telling each enemy to go directly to the player position, you can pick one of the placeholder instances at random and tell the enemy to go to that position instead.

    Doing that they will all go into the players general direction, but they won't cluster in a single point.

  • Try looking at what the GamepadID expression returns when connecting different types of controllers. Mind that these strings will not be just be "Xbox" or "PS4". Likely they will be more cryptic, but if you connect different types of controllers you should be able to find a pattern.

    Ideally try connecting as many different types as possible, Xbox 360, Xbox One, Series S, Series X, PS2, PS3, PS5 anything you can get your hands on. Likely wired and wireless will yield different results. If you do that you will be able to better handle what ever is connected.

  • dop2000 That's definitely possible. Can't really promise when that will happen though. I have been meaning to improve the importing options for sprite sheets, but I haven't been able to get to that either!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • pandabear7413

    The reason a folder is created for each animation is because the importer just tries to replicate what was dropped. So if you drop a folder with a bunch of images inside, that is exactly what the importer will create, a subfolder with an animation inside.

    In your case, I think you will find using zip files useful.

    The importer treats zip files just like a folder, with the key difference that it doesn't create a sub folder for it's contents.

    Ej. 1: Create a folder, put two zip files inside of it with different images, now drop the folder into the animations pane. Doing this creates a sub folder with two animations inside of it.

    Ej. 2: Drop two zip files with image content onto the animations pane. Doing this will create two different animations at the root level.

    Just like a folder, a configuration file can be placed at the root of a zip file and it will affect the files down the file structure.