Or, for the laziest, just hit Delete with a variable selected - if there are Events associated with it, it will complain and list the Events - like in Jase00's case.

Use dt in the formula for the increment.

Say, if your current formula is "increment by 1", change it to "increment by 1 * dt " - this will make it framerate independent, but take note that you may have to change the "1" to a number that gives you the increment speed you're after.

As Ashley wrote, Chrome is most likely configured to wipe session data on browser restart. If that's the behavior you want overall, you can always use Site Settings to keep the data just for Construct .

A source file is perfectly fine - great demo - thank you, newt and Merry Christmas!

Set Front face object to a Sprite, and use the Sprite's animation?

I'm just going to suggest something out the left field...

Firstly, I had the same issue and need (consistent mouse pointer position) - what I found out was that the actual canvas size was different from the size specified in Construct - strangely only horizontally, and by a very weird amount - I got that "correct" value using the PlatformInfo Object - PlatformInfo.CanvasCssWidth/Height - piping that into my pointer formula gave me consistent behavior.

Sidetracking aside, why not use the Pointer Lock feature coupled with On Movement and Mouse.MovementX/Y to drive the cursor sprite? Along with saving last position when doing any layout switching, that should give you full control.

Mikal

Hmm, I have not really thought about that. Do you mean updating the model's texture during runtime like an animation?

Yup - originally, I thought the ideal way would be to handle it like Q3D Model/Sprite do - allow for animation folders/sequences/playback controls... But for performance and simplicity, the approach R0j0Hound is using in his Rojo3d engine is actually better:

There is a single action to apply a Sprite's current texture to a model - the link is non-dynamic, so when the texture on the Sprite changes, the model retains the texture give at the time of the action's execution.

Using this action and the already existing Sprite conditions, animated textures could be implemented very easily and in a flexible manner.

megatronx

The simplest way, assuming your terrain is a regular grid as seen from the top (only Z values differ) would be to store position or Displacement Point coordinates and z height values of the terrain into a 3-dimensional Array (x=posx/disp point x, y=posy/disp point y, z= z height) and then, on runtime, calculate the position of the player in relation to 4 nearest points on the grid and calculate the player's Z by averaging the 4 Z values based on distance to player.

I'm suggesting Array for faster lookup but you could also read the point data directly off the distorted Sprite - but in my tests, it's slower than the Array method.

R0J0hound

No worries - I'm glad you're still on it.

megatronx

Not to sound like a buzzkill, but I don't think you should post pieces of Q3D publicly - it is a commercial plugin.

In lieu of proper raycasting, since you mention it's for terrain snapping, you could cache height data into an array and do positional interpolation. For anything more 3d, spherical collisions would still be doable...

Mikal

Quick questions on features:

-are you planning on removing the limitation of the object's texture being larger than spritesheet size?

-are you planning on allowing for texture/image sequences (ideally something like Q3D, handling it like the Sprite object)?

I know about letterboxing, but ideally I need my project to work on devices with a variety of aspect ratios and resolutions - due to the style, it should run in device native res without any black bars, filling up the whole screen.

Currently, I have a starting event group that checks for resolution and distorts every sprite according to that - it is not efficient nor elegant and that group will continue to grow as the number of unique distortions increases, but it works...

However, I believe that now, with a fully controllable 3d camera, distorting some scene elements non-uniformly, based on resolution, is not really the proper behavior.