Thanks for the responses everyone. I had never run into this before now.

The situation was basically

On Function "create everything"
    --loop
          --create several objects and set their initial private variables according to an algorithm
    --every tick 
          --call function "update everything" 

On Function "update everything"  (used outside the "create everything" function as well)
    --several conditions here checking objects' private variables
          --perform actions on each object based on some algorithm involving each object's private variables[/code:gyfvteju]

So using the 'wait 0 seconds' before the "update everything" in the first function was the cleanest workaround.

Hi everyone. I just wanted to make sure this was a bug (and not a known one) before I reported it. It seems pretty fundamental and like it would have been reported by now, but I couldn't find it with any of the search terms I tried.

Basically, if you create an object you cannot perform any actions on it outside the event that created it (and it's subevents) until the next tick.

This capx is a simple example.

After creating the box the action to set it's scale to half size works since it's in the same event.

The next 'every tick' takes place immediately afterward and sets the size back to normal and changes the angle, but it applies to every box except the one created in that tick.

If you toggle on the 'Wait 0 seconds' action, it works as expected since it is no longer the same tick as the creation.

lucid

So will this reference implementation handle the issues with 1000s of objects if using multiple instances of the same .scml file? Right now, I am using spriter files for destructible objects and we packed each .scml file with multiple entities and character maps so that we could randomize the obstacles easily. The problem is that with just 12 of these scml files in the layout at once, there are 800+ objects created and performance comes to a crawl for mobile devices. This makes it so that spriter becomes less and less useful for our project even though it makes the best animations and visuals we can produce. Are there any guidelines for how many entities to have per scml file or if there are better ways to handle this setup?

The short version is that you should keep entities in separate files if you don't plan to use the Set Entity action in C2. The version of the plugin that will come after the reference implementation will address the issue of multiple objects being created. This was actually a design decision between Ashley and I to allow control over individual character parts. Now that the plugin has been out for a long time and we've gotten feedback, and seen how often the feature is used versus how often it causes performance issues, it seems these situations are the exception rather than the rule. I'll get into it more once I'm working on the new version of the plugin, but at worst it should be possible to choose all separate objects, or no separate objects (all drawn by the single plugin), but I think it might be possible (will have to think more on it, and discuss with Ashley) to specify in Spriter which objects you want separate and have the importer and plugin only generate separate objects for those and draw the rest itself. The difficult part of that last possibility is drawing several body parts, adding a separate c2 object, and then drawing several body parts on top of those. I have a possible solution, but I'd like to test how well it works.

Are there any plans to add ways that Construct can "talk" to Spriter? For example, being able to rotate a characters head towards the cursor would be great.

Yes, I plan to expand in this area quite a bit. I can't get into it now, but again the reference implementation will be the first step to implementing these new features.

Spriter's Kickstarter Campaign! (7:55 min)

https://m.youtube.com/watch?v=MPVR41j9LXE

Freeform image deformation, Skinning and Procedual animation are already integrated?

We're quite a bit behind schedule, but I say 2015 is a safe bet for both to be in Spriter and the C2 plugin. I'm giving myself quite a bit of leeway here so hopefully closer to mid 2015 than later.

Just to add to JamesXXXYZ - We've been mucking around with the FID tools in Spriter Pro which seems like it works fine (still tagged as experimental obviously) but when it gets imported in to C2 it kicks up this error:

Javascript error!
TypeError: tweenedBones[i] is null
http://localhost:50000/Spriter_plugin.js, line 1617 (col 6)[/code:1gyttvqm]

Assuming this is just because the plugin doesn't support the experimental features.

AHHHHH SO LOOKING FORWARD TO IT WORKING!
orrect.  The tools will be much more powerful and easier to use once they're complete in Spriter. 

I am a start up business and the only employee and manager and co executive of my business and would love to buy construct 2 and your spriter program soon. My company is called Falconsoft Industries, as I intend to make it a company that will one day be the next largest and richest company in game design, but construct 2 is not the only tool I will be working with, for professional reasons such as unity provides 3d design easy for programmers that I will hire one day. Also truefalcon is just my name on development software forums. <img src="{SMILIES_PATH}/icon_e_geek.gif" alt=":geek:" title="Geek">

here is a community developerd Unity conversion tool that converts Spriter animations to native Unity animations called Spriter2Unity (https://github.com/bonus2113/Spriter2Unity). The reference implementation will also make it trivial to add Spriter support in any language or on any platform.

Somebody, I will work on it after the reference implementation, which I still can't give an estimate on just yet. The new version of the plugin will be the perfect time to make such changes, so I'll discuss a few possibilities with Ashley at that time. The reference implementation will lay the groundwork for a lot of new plugin features as well.

Hi — It sounds like you don't have the custom save options required for C2 projects. You only have to set this once, but open up the 'File|Other File Actions...|Custom Save Options' dialog, and check all three boxes under 'Additional Data for Authoring Tools':

After that, just make sure you have both an scml and a scon version of your project saved. (just save twice, and choose 'scml' the first time, and 'scon' the second time for the file types.

We will streamline this process in future versions, and there is a detailed tutorial on how to use the C2 plugin linked in my signature.

I gave spriter a go again, followed the instructions from the video and i'm getting a javascript error when first starting the game.

Its a brand new scene with the greyguy example file .scml file being imported.

Javascript Error!

Uncaught Syntax Error: Unexpted token <

line 1 (col 1)

Which video? The tutorial from my signature?

If you just drop the scml file into the layout, does C2 ask you where to import it, and create events (an 'On Initialized' event, with several actions)?

What are the possibilities of an adobe after effects implementation? Currently planning a short film on Construct 2 but Spriter would be the perfect tool to have around AE.

he reference implementation I'm working on will be the basis to expand to as many languages, platforms, tools, etc, as possible. After the reference implementation is complete I'll be focusing a significant portion of my time toward providing tools and support to developers working on porting the implementation. So it's definitely in the realm of possibility, but I wouldn't venture an ETA just yet.

justifun, currently:

works: animation, collision boxes, action points, sound effect triggering, character maps, variables, events

doesn't work yet: sub-entities

Aside from that there's general improvements to the plugin for optimization and additional features, but it supports all Spriter features aside from sub-entities.

Hmm. The scml plugin uses regular C2 sprites to assemble your character, so the images should look the same quality as any C2 sprites. Just make sure they are large enough to look good when your game zooms in (if it does), and they should work fine. It's also possible you have point sampling in your project properties. Please let me know if this helps.

I'll die a happy man if Spriter can have a dedicated interface within C2, less plug-in, more bolt-on. Thoughts lucid?.

Definitely. There's a few requests I have for the plugin system (and it seems from the blog post Ashley is thinking in this direction already). I'll go ahead and respond to thread topic as well, with general requests for c3.

I don't have time at the moment to read back through the thread so I apologize if I'm rehashing anything.

capx based edit-time ui creation

I would like for the edit-time ui programming to be a alot more like runtime programming and eventing. You could include in the plugin directory something like a small limited capx that serves as the ui for your plugin when double clicked or hovered or whatever you set in the edittime. For instance, you could make a capx that has drag and droppable sprites, dials, combobox boxes, etc. There could be an editor ui plugin or system actions that let you set values that can be passed to the edittime of the plugin. Same thing for plugin input parameters. It'd be cool to be able to create an interactive ui for ACE parameters using a capx. You could make it so users could input your color parameters with a color picker, and some numeric values with sliders, dials, spinboxes, etc, instead of typing.

But the real power would come from being able to combine several parameters within a single control. You could make a mini-capx that creates a visual speed (easing) curve editor that sets each control point and curve parameter, or see a preview of an animation at the time you're sliding to between 0 and animation length, or anything else you could create in C3 for game use, would be useable in the parameter input ui. You could make particles show an animated preview using the parameters you're setting with sliders, or a scrolling background showing you the speed that you're setting with an 8 direction behavior.

To avoid plugin UIs becoming too huge and bogging down the editor, there could be a simple restriction that you can only use a shared set of useful ui images for sprites, like triangles, dots, and all ui element type plugins, any images from the current project, and maybe a super small allowance for custom ui images. Maybe it could have a file-size or event limit as well, so they can either be loaded quickly or stored in ram. I believe Ashley mentioned in the blog the idea of being able to make plugins out of events, so if something like this was implemented, it'd make sense to give these same abilities to event sheet based plugins.

plugin access to create lists like the animation name or function name list

This might already be possible, but it would be good to be able to add to a combo_box or autocompletion list at edit-time, so for the Spriter plugin for instance, you'd be able to choose animations, entities, character maps, etc from a drop-down list.

additional variable types

Some of this could be made into plugins and behaviors for C2, but it would be a lot cleaner if it were built in. I'd like there to be dictionaries and arrays as regular variable types for object private variables and global variables. I'd also like to see objects as variable types, and any combination of the above, like a dictionary of arrays of objects as a private variable to another object.

new function object and variable objects

I'd like a function object that can take objects as parameters as well, and a special 'variable object' that you use a proxy to objects used as parameters or variable objects called into it. They would have all the commands that are common to many objects like create, destroy, set width, height, scale, angle, x, y, etc. You could then use this object as a proxy for the object using all the associated actions, conditions, and expressions are. The function object (and may even the global and private object variables) could also specify a specific object type, so you could make a parameter specifically for "sprite" or "particle" types, and then only those would be valid as parameters. In these situations you would get a variable object of that specific type and have access to all of it's functions even though you weren't sure which specific 'sprite' or 'particle' object type you were dealing with. Variable objects could also have set private variable by name, and if the object had a variable by that name it would be set.

behavior universal data sharing

For behaviors, I think it would be extremely useful if there was a concept of universal data sharing. Let's take the 8 direction behavior, the platform behavior, and the physics behavior, which all have the action setVelocityX, and an expression called velocityX (or something similar). Of course, any plugin could ignore the universal settings and keep their own local copies if needed, but each plugin would have access to a setGlobalVelocityX (always pixels per second), and getGlobalVelocityX, and others for rotation speed, etc. Now if you move a sprite with 8 direction behavior, physics behavior knows it's moving at that speed, and behaves accordingly, and vice versa. Or if you want to switch from platform behavior to 8 behavior on a certain event, when you switch over control it will automatically set it's velocity. As an alternative to the functions like setVelocityX, etc, you could just set the behavior to participate or ignore each value, and it would automatically make the velocity calls by checking the x, y, angle, etc, each tick and using those to determine velocity. I also like the idea of being able to set whether to update those values when you use common world object commands like setX or setAngle, so if you manually control your character with commands like setX or angle, the object will have appropriate momentum with any plugins. This universal data sharing for behaviors would also work well with the variable object concept, as you could also have a universal set of commands that could do something similar to all behaviors.

more granular SOL access and object picking

I'd also like to see some additional picking features, like splitting up a single object type into multiple selections, that you could call by a custom tag or index. One example usage would be having an array of objects, all with physics behavior and you want to make a rope bridge. You could just run a loop and say plank[loopindex] create hinge to plank[loopindex+1]. Or if you had a function with the object parameters "attacker" and "defender", then you could access two of the new Variable type object and be able to easily refer to one or the other in any actions, conditions, and parameters. For example, you could say : Set VarObject[attacker] position to VarObject[defender].x, VarObject[defender].y

Awesome program!!! : -)

Thanks!

Can somebody answer me, what are the best settings (visually) for a spriter project and how to prepare my assets correctly? I tried spriter in a test project, but the output ingame is not so smooth (i mean not the animation speed, the animation works very smooth), but the images are jagged or blurred. Is it better to import my images very big in spriter and scale down in C2?

Are you importing using the scml plugin or exporting to pngs from Spriter and importing those?

lucid

I posted back in dec (page 129 of this thread) I did manage to solve the problem. Seems to have been a corupt file. Reverted back to a much earlier version of my project. With both the latest updates of Spriter and the plugin it's working fine. I tried to recreate the problem. again and again without any luck. I must have corrupted the file some how. Thanks for your help regardless everything is ok now:)

Glad everything's working now. Thanks for the update.

lucid - a couple of thoughts - today I was thinking it would be cool if you could put a background image in the spriter window (perhaps jpg to keep the file small?). That would allow you to export gifs and screenshots with more interesting, context appropriate backgrounds.

With the pro version you can choose a watermark for the background or foreground when exporting, though you don't have total control over the exact location. Eventually, some of the longer term features planned for Spriter should make it easy to do something like this, though.

[quote:1eofouw1]The other question is, using character maps, would it be possible to spawn say a certain type of enemy and randomize which body parts are used, making a great variation in the enemies would look?

You could do this. You would have to setup events to handle randomly applying the actions to add character maps, but that's definitely one of the things I envision people using character maps for.

[quote:1eofouw1]One last thing - I'm still wanting to be able to change effects applied to particular instances. That would allow me to create much more variety just by, for instance, changing the hue of an enemy character. It would allow for easy creation of bosses, etc. Thanks, Morgan.

Yes. Unfortunately I can't give an ETA as I already missed the previous. Aside from minor bug fixes, everything plugin related is going to happen after I adapt it to use the reference implementation I'm still working on.

lucid - I've just come across something odd which I think might be a bug.

I've attached the capx file which I've used to demonstrate it.

To demonstrate the issue, press any key when the capx has loaded and you'll see an icon appear in the middle of the screen. It shows a #1 but it should show #2

Thanks for the helpful capx and bug report. That is definitely a bug. I will put it on the todo list.

thansk — Hi Aasmund. Do you mean actually renaming the image files used in the project? Currently, Spriter doesn't currently support changing the file source, but it shouldn't crash, it should just let you know the image is missing. Or do you mean renaming the objects like your sprites and bones?