As just discovered, support for Spine 4 is still being worked on, but that's not a problem. Just in case someone is a blind and stupid person, such as myself, here's a helpful tip. You don't need to search the internet and use weird commands with skeletonviewer.jar, you can just pick an export version in the export screen :zipper:

Yep! Glad you found that, but please be warned that going from 4.0 to an earlier version will lose the Bezier curves in your animations.

Yes, the exporter warned me about that. During development it's gonna be fine, I can easily change it later. But I am looking forward to having pretty pathways again, such as the smoke in this test

https://studiospektar.hr/cavehikers/bigcity_test/

I might be missing something, so I better ask. Is there a way for me to know where the character at it's default animation will be positioned? The position looks weirdly arbitrary. I would expect the root bone to be in the center or something. Is there a way for me to define the center in Spine, maybe?

Spine doesn't do any repositioning of your skeleton during export if you pick the .json or .skel format. The root bone position inside your Spine project relative to the origin will be the position that's applied when importing into the runtime.

The size of your skeleton at runtime is separate from the origin. It is common to scale your skeleton (either by scaling the root bone or scaling the data when loaded) to match the units used in your game. For example, some Unity users scale the skeleton using 0.01 when loading the data.

The origin is world 0,0 in Spine. At runtime your skeleton's world 0,0 corresponds to where you position the skeleton (note the root bone can be placed elsewhere). I can't tell what is going on from your screenshot because it shows only a box around the skeleton (note the skeleton's bounding box can vary depending on the skeleton's pose), not the origin (which is a single point). Unless you mean the red arrow is the origin? In that case it looks like something in the Construct plugin is incorrect.

Oh... It might be also because I shrunk the root bone. Okay, that might make sense! Thanks

It's me again with more stupid questions

I want a particle system on top of the staff, so it follows the staff. But I'm not sure I'm making the right syntax. Instead of X being on bone, X becomes zero

The target bone is called staff_particles obviously.

I also tried "root" and "torso1", it always turns to zero

Interestingly, when I break the animation (like, remove it's name from the atlas, json etc), particle system stays where I put it. It doesn't become zero.

Oh btw the test object didn't work with the new version of the plugin until I added a Bounding Box. Maybe it's a coincidence.
**edit: Nvm it was the Enable Worker thing. Main project runs beautifully now <3

Anyway, I did the Bounding Box and it didn't help, particles still reset to 0,0. I'm probably doing something incredibly stupid, but I have no idea what D:

NOW IT WORKS!!! kinda... Thank you <3
Here, you can see the experiment.
https://porcupine-parkour.hr/goblinwave/
As you might have noticed, I'm more of an animator, not really a programmer, so I get hung up on basic things

There is also a fair number of errors and they seem to be connected to BBox

Also, I found this in the example project, it's going to be very helpful in the future since I tend to resize things a lot.

first of all, great job!
Secondly, In JS runtime you can change any slot skins in runtime by creating new custom skin or even replacing the single slot.
( https://github.com/pixijs/spine/blob/master/examples/change_skin.md )

There is a way to do that in construct? (except from use the js sdk directly)

Case of use: a character with different skin and I would like to mix-and-match slots

Interesting information