Separation of Multi-axis and syncbot tags?

Just bringing this up for topic as I’ve seen that some of the new syncbot scripts come with a multi-axis tag as well.

Due to the already multi axis nature of the toy, I find it redundant to also add a multi-axis tag. Also down the line it would make it harder (as if clicking a link and not seeing the right scripts can be defined as hard lmao) for OSR+/SR6 users to find scripts.

8 Likes

Maybe in the future. As of now, the program to combine the multiple axis scripts is not available yet. Only a few people have access so i wouldnt say it is by default . Plus, just because it can do multi axis doesnt mean a scripter will do multi axis anyway. They might be just satisfied with the auto for the other axes so its just the normal up and down script. Therefore imo, i think the tag is appropriate. Whats wrong with another device having the ability to have multi axis? Its not just an osr thing. If you want, you can maybe filter out the syncbot tag so you cant see em.

2 Likes

If people would do it like you described, the multi-axis tag would be redundant in general, as people could simply add device-specific tags for the OSR2/SR6. Additionally, since it is a multi-axis device natively, they would not require a separate tag.

Based on what I have seen, people already declare fairly well which multi-axis scripts are for the syncbot and which are not, usually in the script title.
It got me confused at first aswell, because of the spike in released multi-axis content, but you get used to it pretty fast.

Still, it would be nice if there were a way to differentiate better between the devices in general, but I can’t really think of a good solution. :thinking:

1 Like

Tags would be the easy solution.
But given the 6 tag limits, that might be an issue.
I’m sure advance search with multi axis tag and people labeling ‘syncbot’ in title or somewhere in post would probably help.

2 Likes

Thats sounds like a pretty good solution actually, just do away with the multi-axis tag and replace it with the device.

1 Like

May rename multi-axis into T-Code or OSR, and add Syncscript.

2 Likes

To me multiaxis should be the tag that defines that multiple axises are seperately scripted (and therefor can potentialy be converted to specific devices). Nothing more. What devices implement is up to the maker.

If you make a multiaxis script involving: up/down, rotation, suction, contraction, but misses tilting… its still a perfectly fine multiaxis script for the tag. So on that i would keep the tag as generic as it is now. It just states there are multiple axises in use.

A seperate tag group to mention tested devices would be a nice feature, but should not replace the current tags. But even then i think there is a better way:
Have all the axises in use as a seperate tag group. In that case you can always see how detailed the multi axis part is, and whether your device supports it.
Those who modify the OSR to have suction then for example would also be able to use that part. It keeps it future proof.

But yeah, that must be a seperate tag field as otherwise its going to be a mess (tag limits)

3 Likes

My question is that if OSR/SR multi-axis and Syncbot ones differ so much so that if you do mess up will it cause problems with the devices? E.g risk of dick getting super squeezed or shaken side to side that it’s nearly getting ripped off.

They are incompatible with one another. Syncbot uses .syncscript whilst OSR uses funscripts.

Syncscripts are made by combining multiple funscripts together. Some scripters also provide these funscripts. There’s no point in using these with the OSR because they are not made for the device.

(If they do use them, it can cause the OSR to tilt more than usual and potentially get hurt. But this can just happen with any poorly configured OSR.)

1 Like

Ah…right so I say have an separation between two then…as I wouldn’t really say that the multi-axis tag suits/fits Syncbot scripts then. (I am presuming that other devices use funscripts to do other axis as well if this isn’t the first first clash as I’m not familiar with other devices)
Especially as if I understand correctly funscripts are useless to Syncbot owners and the toy’s scripts are by default have an multi-axis component to them. (unless they don’t)

As a result…I would say that this suggestion is probably best after some refinement since T-code wouldn’t say to me that the script is for OSR and SR so nor would OSR work either in my mind. Maybe Fun-multi?

That is me presuming that we can’t just have multi-axis and Syncbot tags be mutually exclusive.

1 Like

+1 for letting synchbot have it’s own script tag. It’s its own beast, whereas all of the Tempest Multi Axis devices, and likely any upcoming commercial stroker devices that add a twist axis, can work with the multiple script format that currently exists.

And therefor rewards using a non-standard encoding by being marketed all over the site. That alone is for me a reason to not reward that. It can push other developers to take the same route.

I rather have syncbot posts cause people to be anoyed about the device, and through that motivate syncbot to make and keep converting in both directions possible. Bad marketing is a good way to push devs towards changing their ways of handling.

If we get 4 diffirent script types, this site will become a lot less usable. Its realy worth it to push towards just well standardized 1 format. Syncscript is in this case inferior since it only targets 1 device. And funscripts already have competing devices within its format.

Multiaxis scripts work on a handy and launch, even though some axises are dropped. Syncscript conversion could be the same here, but it should at least be possible (which afaik currently isnt). And once possible, since you can now convert it, the device tags might not even be needed anymore.

Hence, just display the axises, device owners will be aware of which ones they can use.