Hi, this is probably something really basic - I've got a sprite with the timer behaviour attached and an instance variable that is meant to control the timer on a per-instance basis. The timer toggles a boolean variable which in turn switches between a frame on the sprite. I want these to switch on and off at different rates dictated by the instance variable blinktime. When I test the layout, at first it appears to work - I have 3 instances set up with 1, 2 and 3 set up for the blink time and each one blinks on as needed - but instead of looping on and off at the designated time, the instances then seem to sync and the timing goes a bit weird. Can anyone take a quick look at this and let me know what I'm doing wrong? I figure it's something to do with "for each" but I can't quite put my finger on it.

link to capx

https://dl.dropboxusercontent.com/u/703 ... inker.capx

> Even though Flash has a skeletal animation system you won't be able to use it in construct, instead you will need to export each frame as a separate image...[ ]

>

Small correction: Flash CC and CC2014 no longer have any bones - the skeletal animation system was removed due to the shoddy implementation. And only the latest version of Flash has a good graph editor.

You also do not have to use Flash to draw your character parts for later use in Spriter - any app that you can draw in can provide those, including InkScape, Illustrator, Krita, Photoline, etc. As long as those parts can be converted to bitmap cut-outs for import in Spriter.

Cheers, I didn't know that Adobe had removed it - haven't checked Flash out for a while - seems like a step backwards, but it's true that the skeletal animation system in Flash did leave a lot to be desired and it was difficult to get a nice workflow going with it.

Studio One has a free version. I haven't tried it but apparently it's pretty full-featured for an entry-level DAW https://shop.presonus.com/products/studio-one-prods/Studio-One-Free I use a combination of Renoise and Reaper, both of which are reasonably priced but have a significant learning curve.

famekrafts you you need to create the art in either flash or photoshop first and then import it into Spriter (and if you create it in Flash you'll have to export it as a raster image as spriter doesn't support vector graphics yet as far as I know). It's basically an animation tool, not a drawing tool. Flash is far more advanced, but is really for different purposes than Spriter.

It really depends what you need. Photoshop, Flash and Spriter are three completely different programs with little overlap. Photoshop is primarily for raster image design/manipulation. Flash is a development environment with a robust vector graphics and animation engine and spriter is primarily for skeletal 2d animation aimed at games.

The advantages for using something like Spriter instead of Flash or Photoshop in your game is huge though. Even though Flash has a skeletal animation system you won't be able to use it in construct, instead you will need to export each frame as a separate image and import them into construct (for smooth/complex animations this will put your VRAM usage through the roof), with spriter however you build up a character say from several small parts and then spriter itself manipulates these so the VRAM footprint is miniscule in comparison (comprising only of the few images making up a character for instance). There are other advantages too, as the spriter plugin is integrated into the Construct engine you can blend animations and the animations will also react correctly to time-scaling - allowing for some very polished effects.

Basically, if you want polished, complex animations in your construct game that aren't pre-drawn/rendered and which react correctly to the game environment Spriter is pretty much a must have.

I don't know if this is what you want but I have a sort of flip-screen camera set up that scrolls smoothly when the player hits a certain part of the screen. Basically if the player is within a certain x/y range the camera will move smoothly to the center of that particular screen and stay there until the player exits that boundary, whereby it will then float (using lerp) over to the next designated 'center of the screen'. I've attached a screenshot of my workings - It's probably a horribly inefficient way to do things, but it actually works very well for my purposes. The downsides to this method is it's locked in to a particular resolution (1366 x 768 in this case) and all the values are hard coded and probably getting triggered per tick. If I knew what I was doing I could probably set them up in an array or work out a formula etc, but for now it's doing the trick for me.[attachment=0:3ofrias3][/attachment:3ofrias3]

In your project properties (get there by clicking on a blank area of the screen then look in properties window), put PIXEL ROUNDING to off and it should fix the jittering.

Thanks Lucid, I'd completely forgotten about the plugin, all good now

I'm having issues importing correctly. I'm using the latest beta of construct and the latest version of Spriter pro. I have the special exports checked in Spriter and am exporting an scml and a scon file - when I import to construct it seems to work, but all the spriter images default to invisible. Is anyone else having this issue? I thought it might have been my file but I downloaded the spriter player example and imported that, the coordinates are messed up when it's brought in to Construct 169, but then if I resave it in the latest version of Spriter it also goes invisible.

If you break your collision objects down into basic shapes such as triangles or squares and make them invisible you could run a script at the beginning of the layout to pin each collision area to the correct shape (sorry bout the pseudo script but something like)

On Start of Layout - Triangle_Object - spawn Triangle_Collision on layer 0 (image point 0)

For each Triangle

I don't know if it would be more or less efficient than other methods though as I guess you'd essentially be doubling your objects.

helena, actually you're right I can't seem to work out how to change drive either. I have autotilegen installed to F drive and all my image files are also on this drive and it works fine, but it's true I can't seem to switch to other drives - so I guess the solution for now is to install it to the drive where you're images are and it will work. I contacted the dev via indiegogo https://www.indiegogo.com/individuals/6316373 - just click on 'contact user' (you may need an indiegogo account to do this not sure, but it beats going on twitter).

I picked up a copy last week and it's an excellent time saver, the developer is also really good to deal with. I believe slopes may be implemented in further releases (it's still in beta) which will really make this thing powerful. One thing not apparent in the demo videos is that you can load your own images in there, you don't necessarily have to push pixels, so you can get everything polished up in you main image editor and then not have to worry about spending time on the fiddly technical bits like making all your tiles seamless.