newt's Forum Posts

  • Yes, and overlapping is already every tick by definition. Collisions are for a single trigger.

    Yes, all objects have collisions enabled by default. If you want to stop them offscreen use else.

    You might also try a different approach of not using collisions at all.

    The array object can mimic a grid of objects, and can simplify comparisons.

    value of arrayAt(1,1) > arrayAt(1,2) etc.

    You just have to worry about picking objects after that. In which case instance variables work well.

  • There are several open source game engines out there.

    The time it takes to learn one of them might actually take less time than it would to save up for a license.

    It just depends on your level of commitment.

    Judging from the number of o's you might just have enough.

  • FYI

    The full screen effect xml is giving an error message that its a duplicate id.

    Also the meta fields seem to show data for one of R0J0hound's other fx.

    I say that as the directions from the template say to never change the id.

    Kind of confusing actually.

  • Yeah, solid really wasn't designed for multiple players.

    Then again in a tile based system you should be able to compare x, and y positions.

  • Yeah, and they need to sort the licensing pretty quick, as noone is going to buy C2 if they think a C3 is in the works.

  • Needs more cowbell.

  • You don't see any issues with multiple forks of plugs named Scrollto?

  • In a way thats what already happens.

    Someone makes a suggestion, and Scirra will make a change.

    Using someone elses code is unlikely, as they would have to then buy the rights to publish that code.

    There is no reasonable way to do that without some weird contract.

    Change our code, and then we will use it, and not give you anything..., can't happen.

  • Its about backward compatibility. Something like a fork of an official plug would be hard to maintain, and Scirra can't guarantee it as always usable.

    For example there are countless third party plugs that are not maintained, and subsequently no longer work.

    Also, many of the bare minimum plugs are like that because you can replicate them easily in events.

    Scroll to for example is as easy as using the system scroll.x, and scroll.y.

    The plugs simply offer a quick and dirty way to get something up and running, while keeping you from having to commit resources to something you're not 100% sure about.

    That being said, an official git type repository for third party plugs would be a good idea.

    It might make it easier to keep some of them up to date.

  • So glad you didn't decide to go into medicine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I was thinking, from a plugin standpoint, you might be able to do that if you were able to change where the hotspot was.

    Im pretty sure we can't access that in the sdk.

    On the other hand:

  • You can either change the size of the object and it will change based on where the hotspot is, or use one of the blend modes.

    For an occlusion like your first image its a dummy object with either blend mode, or an fx.

  • A good test is: stick a sine behavior on a sprite with movement set to width.

    Preview that, then change the hotspot, preview again.

    It always grows from the hotspot.

  • It just depends on where the hotspot is.

    As far as I know we don't have the ability to change it in the sdk.

  • Physics.

    Google inverse kinematics.