Ashley's Recent Forum Activity

  • Physics defaults to framerate dependent, because around the time it was first introduced (and this is going back years), people had issues with making deterministic physics. The problem with framerate independent physics is because the time step has small random variations due to timer imprecision, it can result in random variations in physics simulations. This resulted in bug reports like "my tower of physics objects falls down a different way every time". People wanted their physics simulations to be predictable, which is what you get when using a fixed time step, so I (with some unease, knowing the downsides of fixed time steps) changed it to default to fixed. The downside of a fixed time step is, predictably, that it's framerate dependent, so now the physics simulation speed depends on the display refresh rate.

    Now that different display rates are more common, the default Physics setting probably needs to be changed back to framerate independent. But now we have the problem of figuring out a way to do that without breaking all existing projects which use the default and rely on deterministic physics.

  • This sounds like a bug we already fixed. Try the latest beta.

  • This is another case of the "newly created instances are not fully available until the next top-level event" quirk.

    If you create an object, you can use it in the same event and sub-events, but not in sibling events, until the next top-level event. Since those events are all in a group, the newly created object is not available in subsequent events, until the end of the group (which is the "next top-level event" point).

    The reason for this is to make the event engine fast, it assumes the internal data structures do not change while running events. Creating an instance changes the internal data structures, but this change is delayed until the next top-level event when it is safe to update the internal data structures, because it's not half-way through running events. We could remove the limitation by slowing down the entire event engine for everyone (i.e. adding regular checks for "did the internal data structures change" through the entire event engine). But that makes all Construct games slower just to solve this quirk, so it doesn't seem a reasonable thing to do. And if we break the assumption that internal data structures do not change, it ends up with crash bugs - and user reports of exactly those crashes is what led to the current "wait until next top-level event" workaround. So the quirk lives on.

  • Pinning width and height was already added in one of the recent betas.

  • Sorry, my code was wrong, you have to assign the whole saveData object yourself like this: 

    function OnSave(e)
{
	// Save myVariable by adding it to saveData
	e.saveData = {
		"myVariable": myVariable
	};
}

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's entirely up to third-party developers where they publish their addons. Ask the developer if you think they should publish it to the Addon Exchange - that's what we designed to be the one place to find addons.

  • Mirror is negative width and flip is negative height. So you should already inherit mirror/flip if you pin the width/height.

  • It should always copy in that case. If it doesn't, please file a bug. I did just check it on Safari and it seemed to be working fine.

  • Your screenshots also show you still using the older and much slower Construct 2 runtime. Switching to the C3 runtime could help a lot. It sounds like the game might be bottlenecked on the GPU hardware bandwidth though, which is typically the result of using too many images and effects.

  • The engine does already provide an efficient line-of-sight capability. So it should be possible to customise it to your needs already.

  • FYI when you see the "browser blocked copy" message, you can click the "Copy" button on that dialog, and it still works.

  • You could take this even further, and pin instance variables, behavior properties, effect parameters, and so on and on. But I think it's unweildly to keep adding more and more. Eventually you end up with huge lists that you have to scroll through, and it undermines our goal to make a simple tool that's easy for beginners to understand. So we have to draw the line somewhere, and I think what we have now is a good point to leave it. Pinning values is easy to do in events as well so it's really just a convenience behavior, I don't think it needs to try to solve this for everything.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,769,865 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs