DiegoM's Forum Posts

  • I am not super familiar with PHP, but if you need to do DOM parsing, you are better of using a library. Avoid rolling your own regular expressions like the plague, it will only cause you trouble in the future.

    Looking around I found this PHP DOM manipulation library github.com/ivopetkov/html5-dom-document-php/, have never used it, but it looks promising and has a bunch of stars in github. And it seems to have documentation, which is always a plus.

    Even if you are using a library, the problem with scraping is that it depends on the layout you are trying to get data from, so if that changes, you need to update your code. Because of that reason, in the past I found that it is better to keep your queries just specific enough to get what you want, in the case the layout changes a little bit, but not too much, you might get away without changing anything on your side.

    What does this has to do with C3?

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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