Hi,

Im not really sure why this isn't already in, or what the limiting factor could be. Currently I want to send data to my code via events I can send 1 int, 1 float and or 1 string. This is rather limiting and forces multiple (usless) events to be called if I need 5 ints. Strings aren't too bad as they can be parsed, at the moment we do: [somevalue][anothervalue]... but this is non the less, still annoying.

It would be really useful if you could create new instances of the data types to store data in.

Thanks

5 ints where just an extreme example.

An example might be that you want to spawn a bullet from a certain place in the skeleton. You can use a bone to locate the barrel of the gun, this bone will always follow the gun, no matter where it is aiming. It would be advantageous to have an event which the animator could key which specified the bone name, so it can be found from the skeleton, and which bullet to fire. That way it is data driven rather than hard coding which bullet comes from which gun from what bone, which bone etc. etc.

Hi,

Sorry for late reply, was ill Thursday and Friday last week.

Pharan wrote

Whether you specify the bone in Spine or in your own separate data structure, as a reference or as a string, it's still data-driven.
The things you mentioned could easily be defined in your own object, class or structure. Build it yourself, format it yourself, save/load it yourself, or is that what you're trying to avoid?

Yes, this is what we are trying to avoid. It would be silly to have a new object for each and every type of effect/object/whatever, and check which one to use and where and when. Instead being allowed to have fields passed through an animation (this settles the when part), to designate the where and what is useful.

Pharan wrote

Of course, you know data-drivenness is really a spectrum. And way before going overboard in either direction, you'll know that Spine's systems is far from the ideal place you should be keeping your data.

Of course, we could just use the string to point to a file directory, which would load the information. But this is just going to bloat the amount of files the developer uses. which in general is harder to manage and edit. Spine already provides the export of all the information to do with the sprites and animation.

Pharan wrote

If you're saying a Spine event should be able to pass a bone object to an event handler, that's actually interesting, since bones are definitely Spine's concern. But it's not exactly a mess to implement using a bone without this feature in Spine Events. In some ways, it's actually cleaner.

I had not thought about spine being able to pass through bones via events, this indeed would be a nice feature. At the moment, if you wish to do this you have to pass through the name and find it that way.

Pharan wrote

What about your current problem leads you to believe that Spine is the place to keep your data?
I'm also curious: "which bullet" and "which gun" seems a bit vague as animation data. Is this for some kind of tank with 5 guns on it that can each fire many kinds of bullets?

There is no 'problem' as such, it just seems that this basic, extremely usful functionality has been left out of spine. It is not like it is uncommon for tools to allow you to create your own fields, which will export with the rest of your export. An example that I have to hand is Tiled.

Image removed due to the lack of support for HTTPS. | Show Anyway

Here you can click a button, and Name the extra field you. Then you are free to fill the value box.

Image removed due to the lack of support for HTTPS. | Show Anyway

Here you can see I have created 3 new fields. Now I am free to read these properties in game.