DiegoM's Forum Posts

  • This is a regression bug introduced in the latest beta, will be fixed in the next beta.

  • You do not have permission to view this post

  • Here is a very contrived example showing DrawingCanvas's Save Image action to save the state of the canvas, then uses the On Saved Image trigger plus the Saved Image URL expression to set the saved image into an empty Sprite instance.

    dropbox.com/s/0y7zm42smt7zhcw/DrawingCanvasSaveImage.c3p

    For the case that you are describing, I think what you would need to do is keep track of the url of the saved image on the trigger, so you can retrieve it later on, outside of the trigger.

  • If you were able to set depth to more than 100, that was definitely a bug. Not being able to do it is the correct behaviour.

    I don't think there is any particular reason for the limit being at 100, it seems like it was just set as a sensible limit. Obviously it can not be infinite as that could eventually lead to running out of memory.

    The thing with the depth property is that each additional increment is essentially adding a whole extra sheet. If you are using relatively small sheets, let's say 10x10 for example, that is fine. In that case each depth increment would be adding an extra sheet with 10 rows and 10 columns, which would add up to a total of 100 new cells. If your sheets are larger though, each increment could potentially be incrementing the total cell count dramatically.

    The limit for width and height is currently set at 1000, in the case of using a sheet of 1000x1000, each depth increment would be a million extra cells, which could rack up memory pretty quickly if left unlimited.

  • Just checked this to be sure, and seems that 100 depth has been the limit since the feature was implemented. So I am not really sure how you were ever able to do more than that.

  • Can you file an issue in our tracker?

    github.com/Scirra/Construct-3-bugs/issues

  • Thanks for filing the issue.

  • Just recently I realised the problem you are having with the total time marker and with dragging keyframes, I was surprised that neither of those things were doing what I thought they should be doing!

    What OS and Browser are you using? Normally we develop in Windows Desktop running Chrome, so the scrollbars are pretty chunky.

    I don't think there is an easy workaround for small objects, you can select the instance in the layout by clicking on it's corresponding track in the Timeline Bar, but the changes need to be made on the instance itself, either by modifying it with the various handles or through the Properties bar, that's just how C3 works.

    Can you explain what you had in mind for the MoveTo behaviour + Timeline, I am imagining an expression, but please explain.

    I'll go look at our error tracking specifically for timeline errors, normally we pay attention to the big offenders and the small ones slip through the cracks.

  • More often than not there is no right answers on how to implement a certain feature. The templates are meant to give a hint for beginners as to how a certain type of game might be implemented, but they are not the only way to go about it.

  • Originally we wanted to make sure that the transformation properties were handled properly, because they are the most important. Having said that, visibility opacity and color sound like reasonable additions.

    There has been a suggestion/expectation that changes to the z index of an instance should affect all children in a hierarchy, which sounds like a reasonable option to have as well, so I think that at some point all of those things will be added. Not to sure when though.

  • Not too sure if there is an easier way of doing this, but you could do it with a relatively simple script 

    try
{
	// Get the url for the font in the project files
	const fontUrl = await runtime.assets.getProjectFileUrl("project-font-name-goes-here.woff2");
	
	// Create a FontFace object. Make sure to use the correct font format, in this example it's "woff2"
	const fontFace = new FontFace("ExampleFont", `url(${fontUrl}) format("woff2")`);
	
	// Load the font
	const font = await fontFace.load();
	
	// Add the font to the document
	document.fonts.add(font);
	
	// Apply the fontFamily style to your input element
	document.querySelector("#myInput").style.fontFamily = "ExampleFont";
}
catch (e)
{
	console.log("something went wrong");
}

    Instead of applying the style directly after loading the font, you could create a stylesheet in Project -> Files and then load it using the Load stylesheet action of the Browser Plugin.

    The stylesheet would look something like this 

    	#myInput{
		font-family: "ExampleFont";
	}

    After the font is loaded, the style will take effect.

    Here is an example project doing all of that. https://www.dropbox.com/s/gzy5zdkghp7w5yu/FontLoading.c3p?dl=0

  • This is a bug. Thanks for bringing it up. A fix for it will come in the next beta release.

  • This feature is available in the latest beta. Eventually it will make it's way to a stable release.

    You can check it out in https://editor.construct.net/beta

  • Hello and thanks for the feedback!

    1) Keyframe manipulation could use a little bit of extra work.

    You can select multiple keyframes at the same time and move them all together. You can either pick them one by one, using Ctrl + Click or Hold Alt to use the keyframe selection tool to select all the keyframes in a rectangular area (is this what you mean by selection range?). If you then drag a selected keyframe it will drag all the selected ones as well.

    The feedback is the same as moving one keyframe though (marker and relative and absolute time tags) and it can be quite cumbersome to select an amount of keyframes that do not fit on the screen, because the zoom level does not go below 1x (which is a very doable feature)

    2) Keyframes are set for all selected instances that have received changes. So if you make changes in multiple instances they all need to be selected before setting the keyframes. That is how it works... but looking at it, it doesn't seems like the best workflow :P Keyframes should be set on instances that have received changes, regardless of being selected.

    I think that covers everything. We are always looking for this kind of fine grained feedback, so thanks again!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There is still no easy way of doing this.

    As an experiment you could try saving the JSON information of the root instance, and use that as a template to clone the whole hierarchy. Each instance holds a list of all the UID's which are it's children.

    So, you could:

    1) Clone the parent

    2) Look up all the UID's of it's children (get the JSON from the AsJSON expressions)

    3) Make clones of the children, add them to the cloned parent (using the existing runtime actions)

    4) Repeat steps 2) and 3) for each child until the whole tree has been cloned.

    I am not going to go into the specifics of the JSON format C3 uses, because all of this is not a great idea to begin with :P

    There could be hidden issues I am not foreseeing. I can already see that before setting the JSON for each clone you would need to NOT pass any hierarchy information, because it would be for the old one.

    I guess it can be an interesting thing to try out, but I wouldn't recommend it.

    I am thinking the runtime action that is going to end up doing all of this work will do pretty much what I just described.