Ashley's Forum Posts

  • Can you send the .cap to ashley@scirra.com? I'd be interested to look at both disappearing events and the lagging runtime...

  • You can do this with the function object. Call a function, eg. "DoStuff" and forget picked objects. Then add an event like:

    + On function "DoStuff"

    + Sprite UID is 2

    : Sprite: do something...

    Because the picked objects are wiped clean for the function call, you can then pick the sprite with the UID you want from a clean slate and do something with it. Remember, after the function call the picked objects from the old event are restored <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

    If the object of the UID you want to specifically modify is already picked, you can add a subevent 'Sprite UID = 2' and do something with it there. It will then pick the sprite with UID 2 so long as it was picked in the parent event.

    Out of curiosity, why do you need actions on specific instances? Just wondering the circumstances, in case we can better design a solution (or if one already exists).

  • Yes, as I thought: the colliding objects have the Physics movement. Objects with the Physics movement automatically collide with each other.

  • Woops, made a mistake in the expression validator. Will try fix soon...

  • Thanks Deadeye, you've done some great work <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /> I'm going to split Common properties in to its own article from Sprite properties though, because it applies to all objects.

  • Yeah sure youtube whatever you want. The monsters use a bullet movement which doesn't respond to solids, instead, you can use an event like this:

    Monster collides with Wall: set Monster angle to Monster.Angle + 180

    This just means whenever a ghost touches the wall, it will flip round to the other direction.

    I don't think kickit.cap comes with Construct so I can't remember how it does collisions, but there are lots of different ways of making collisions work. You can use the Physics movement, events like above to handle collisions, the Solid attribute, etc.

  • I think no matter what scripting language we pick, X people would say "OMG awesome!!" and Y people would say "no way not that one!!". We've investigated a few, and picked python for several reasons, one of which being it has got very good C/C++ integration which makes it very flexible for Construct.

    Also for highly algorithmic stuff (tight loops with lots of variables), Python is almost certainly faster. In Construct if you add to a counter or global variable or whatever, you still have the overhead of jumping in to an action, whereas Python just knows to increment a variable and probably does this in a very optimised fashion. That's part of the use of having Python. There will also be bindings to call actions (and possibly conditions and expressions) from Python itself, but when you do this you still get the overhead of jumping in to an action.

    As for SDKs, Python plugins etc. we have plans to significantly improve the modularity of coding with events, and python fits in to this rather neatly. We'll be announcing more stuff in future <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Hi, just add a sprite and under 'Attributes' in its properties, tick 'Solid'. Now the player can't walk through it <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • I'll try and get something sorted soon!

  • That's odd... what conditions are disappearing?

  • Memory usage stays constant here, just the CPU increases as I move the mouse around. The task manager's figures for memory are pretty approximate, it could be normal behaviour, unless the memory leak is significant (ie. you can add 100mb to the memory usage just by waving the mouse). How much does memory increase by, which objects did you try it with (I used sprites and tiled backgrounds), and does closing the layout free the memory?

  • Setting a colour filter on a sprite can tint a whole object, so if you want to tint just parts of an image, you can use separate sprites for the areas to be tinted on top of the main sprite.

  • If it was changed at all, some plugin developer might go and use the "proper" system of 0 degrees being right, and you will still find yourself adding to angles in places to make angles compatible. IMO keeping it 0 degrees right is the best way of ensuring things like Sprite angles, the Angle expression, angles of motion etc. all work the same way. Being able to set angle of motion to Sprite.Angle is a lot nicer than ((Sprite.Angle*-1+270)%360).

  • I'd prefer not to change it. Mathematically, 0 degrees is right. Consider that movement at 0 degrees is X + D cos(0) on the X axis and Y + D sin (0) on the Y axis. cos(0) is 1 and sin(0) is 0, meaning movement right on the X axis at an angle of 0 degrees. It is very much beneficial to keep it plainly mathematical like this: if you hack it so 0 degrees is up, the formula begin to look like cos(angle - 90), with a modification to the angle. This means you can no longer express in your events custom movement as being X + D cos(angle): you will have to also apply the hack to make it compatible with Construct's built in angles, and any modification would not be obvious to a game developer. Even worse if people can invent their own angle systems: in any given game, you simply would have no idea what an angle actually means (would 0 degrees mean up? left? down? south-south-west?). I certainly want to avoid situations where people have to invert, offset and normalise angles just to make them compatible with some other angle system, I've had to do that before for games and it's nontrivial.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This one's gonna be even better! (When it's done...................)