Suggestion for tags: automaticly adding axis specific tags

General
1

While we have multiaxis as tag, the problem is you cant see which axisses it involves. And this is specificly anoying when a certain axis isnt supported by the device you have. And it can help searching for specific support by searching for specific tags that many devices dont have.

While there can be many axisses, i do not think having all of them detected is going to help. but there are a few where i think it helps:

The tags i would suggest are:

  • pitch_roll
    This is a very commonly supported set for the OSR2, and generaly a minimum for any rotation based system.
  • surge_sway
    this is better if you are searching for SR6 scripts. These are more niche, but this is therefor a good tag to use in searches if you have such device
  • twist
    while the OSR2 can support twist, its not default, and there are devices that do support twist, but do not support any rotation, making this a good tag to look for.
  • vibrator
    While this tag is already used manualy (which is good). Automaticly applying this for any .vib.funscript containing post wouldnt harm. While this isnt technicaly multiaxis, i dont see a problem supporting this as vibrators can optionaly still be used in multiaxis context.

These tags should be possible to get automaticly added to a post based on the scripts provided, since it involves reading the filename to know which it involves. Any unknown axis does not need recognising at all. And if even only 1 of the 2 (for example just pitch, or just sway) is involved, this tag still can be usefull.

They should not be strict either. If someone made a vibrator script and uses the main axis, then its still fine to tag it for vibrators. If they would be strict, im worried it might cause some conflicts instead where someone made a pure vibrator script, but as its not named .vib it wouldnt be recognised as such. For this manualy adding the tag should be possible. The same for pitch_roll, even if such script isnt in there, if someone added that tag, so be it (moderating will fix this if its abused).

Im only suggesting automaticly adding these tags, not demanding users to do this, while still giving them the option to do so if they desire.

2 Likes
2

I second this, except I would take the tags as single axes instead of having a theoretical forest of combination options. This would also include estim devices which by nature are very individually assembled. But even the OSR2 in its basic form only adds roll, without a pitch axis.

Also multi-axis is not only ambiguous (what axes are included) but also strictly speaking it means a minimum of three axes, which can be any number of combinations. So only roll or only twist which are becoming more common would - strictly speaking - not fall under it.

3

yeah i think youd have to do them as single axes instead of doubles or w/e cause I have seen a script with roll and twist but no pitch, or pitch and sway,

4

We do somewhat have a solution already, being device specific tags. The issue is the tags aren’t used as commonly as just sticking multi-axis on the post. I’m also guilty of this as I rarely tag my posts OSR2+.

Instead of adding roll_pitch and surge_sway I would vote for automatically adding Handy, OSR2, OSR2+, SR6, Twist, and maybe another catch all for less commonly used axes (suck, valve, lube, vibration, etc.). This way even newcomers to the interactive device scene can search by their device, without knowing about the specific funscript naming schema.

Considering the site already parses the JSON’s to create merges and svg’s I don’t think it would be that hard to do. Throw a check on axes present and add the tags that it fits.

5

This isn’t something the mods would have to do. This is more of a community discussion so I’m moving this to General

6

Except some devices have diffirent versions with the used axes, you cant realy put all devices as tags, let alone the part that an OSR2 multiaxis script can have the linear script still be useful for a handy. I think devices are only helpful for indicating a certain target, but they are not going to work to find scripts that work for your device using all axes.

Its also not going to help if a thread shows: Handy, OSR2, OSR2+, SR6 if it has linear, sway, pitch, roll, surge. And if it only shows SR6… Anyone searching for handy wont find it, yet the linear script can still be perfectly usable. Being more specific on the axis does allow people to set their own filters for this.

Multiple means more than 1 in most definitions. Just like multitasking is performing 2 or more tasks at the same time.

Well, if we want such system (and yes, that does rely on the if a lot), having a server mod in place that does add these tags is something we as community cant do. Thats why i thought it doesnt belong in general. It being feedback in how we could potentialy improve an aspect on this site i found site feedback a suitable location.

Single axis is also fine for me, i was only thinking about avoiding too many tags existing, a an SR6 could get quite a lot.

The idea is mainly identifying the sort of multiaxis we are looking at from the thread list, as from my own experience. Its usualy either linear+twist, or linear+pitch+roll. Sure, some have a bit more, but these 2 types seem to be dominating the multiaxis list.

For me twist is useless (as i dont have it), and i can imagine that an SR6 owner would at least like more than 3 axes. Being able to quickly identify this in the thread list can do wonders, or just being able to search on the most important axis (for example pitch or roll for me).

Now i need to open the thread, only to realize it being a twist script, which makes the multiaxis search essentialy void as i found a linear script that works on my device. And to me that feels like waste of time to open it, but its also a waste on the server, as everything it loaded is then just discarded.

7

That’s not true at all.

  1. You can make your own tags as you make a post
  2. Users of high enough trust can update any posts tags
8

Wait, so i have multi-axis tag notification enabled, and some topic with just twist can go without that tag added by author and it’s fine by site rules?

Slightly confused, cause i often see just linear+twist topics appear via multi-axis tag i subbed

9

Not in the scripting section afaik. At least they show no results when trying to add. But they are easily created.

I would split that. Automatically tag the topics for single axes and then have a template for devices in the search. I.e. for OSR2+Twist it would be something like stroke && (roll || pitch || twist) . This way there’s a simple solution for newcomers and precision for those wanting to search for specific combinations.

I believe the idea is to retroactively and automatically add topic tags depending on the scripts present in the topic (external links notwithstanding). That certainly sounds like a one-time script an admin would have to run.

Not wanting to open an unnecessary can of worms of arguing the actual semantics, but it seems that different people have different definitions. Inconsistency is the result and I have both seen it done and handled it in different ways (which I should probably rectify for my own posts).
The thing is: Someone with a twist device will get a lot of false positives if looking for multi-axis. On the other hand, someone with an OSR2(+) will get false positives of stroke+twist.

Whether this merits some measures to have it consistent is a different question. I don’t think there’s a description page for the tags except for the more controversial ones and it would probably not be very effective either, if not included directly in the mandatory tagging process and made as easy as possible.

Yeah… there’s also the twist tag, so there could be combinations of stroke+twist without the multi-axis tag. Don’t know how commonly though. I myself stopped using multi-axis for only stroke+twist a while back to make a distinction, but I’ll change that again, if that is the prevalent understanding. Probably a good idea to subscribe to twist either way.

10

This is definitely possible. I’ll investigate with @Dimava

1 Like
11

Thats why i would rather use the axes themselve rather than multiaxis. If you can use an axis you know is often combined with other common ones for your device (for example pitch and roll for an OSR2, and surge/sway for an SR6), you mitigate the confusion multiaxis gets as tag.

Multiaxis while it works to some degree, fails at many. If you have a twist device, it doesnt matter if there would also be the axes for pitch and roll, you got the twist axis at least. Thats the benefit a twist tag gives. But if you dont have any twist, any script that says twist, and twist only is easily identified as not being multiaxis for you.

Well, the semantics are on that an even bigger can of worms, since doing 1x1 is still called multiplication, even though the result is not a multiple of anything. But i used what most organizations use, and that is to identify anything of which you have more than a single one (like multiple cars vs single car, or multiple houses vs single house).

Even if we go by your 3 axis definition. We can have a handy+edge2 combination (which is 3 axes, of which 2 are vibrators), again a unique combo. And one conflicting with the other 2 known ones. And in this case, we get another issue: 2 vibration axes. This is something even my solution wont resolve, as it only says vibrator once.

Dont worry too much about it, since for now it does do the job of identifying non-single-axis scripts, which is still the biggest key diffirence we have. The problem is that multiple as term itself is too vague to identify scripts, and if we find a good solution, it might become a completely obsolete tag.

Another thing it wont cover is device speed limitations, or inverted action. And i still think this is fine. The set of tags is what identifies potentialy matching devices. And if its needed speed limiters or inverse action is something that can be adjusted on the script itself (for now the tools might be limited, but if something becomes common as issue, the solution will generaly be made over time).

And i dont know what we want to do with all the extra rare axes that could be created at some point, or already exist: suction, squeeze, lube, valve, shock. Too many of these can cause other conflicts, and these are also more likely to not match the devices as they can very often be homemade solutions. Especialy since some tags will be very similar to some video descriptions themselve, making people very likely to add thoes tags thinking its about the video itself.

And a video with 20 tags wont make it easy to scan the tags either. I almost think it would be better if these get separated somehow, but that might require a plugin, and therefor become cumbersome for maintenance.

So yeah, there is still plenty to consider for a reliable solution here.

1 Like
12

We’re in agreement ^^

I don’t think this is a problem, since the values alone don’t necessarily translate into intensity anyway. For example introducing some vibration into the stroke axis adds a lot to the average speed, but not necessarily to the intensity. Also depending on the absolute position and individual factors like sleeve geometry, the intensity is different. So the calculated speed values alone don’t tell the real/full story (love the new heat-graph plugin btw, because it offers so much more information). So that number could only serve as a rough estimate in conjunction with other information. And if we start by tagging by intensity levels it is very subjective again.

One place to start would be to properly define them ^^. For real though, I do believe they should be tagged, as long as it’s not a unique machine built only once by a mad scientist. I’m pretty sure some are a bit ill-defined or at least used wrongly, but that is to be expected from a DIY/individual build space. If we would want to tackle this properly, it would have to probably be at the protocol level (T-Code).

Good point: How about naming the tags axis:stroke, axis:twist, ... or some form that is more clear?

I’m not sure how the tags are ordered, when displayed. There’s already mandatory tag groups. Maybe the axes can fall into a seperate mandatory tag group and be displayed last. This way human readability is still there, while having all the upsides of machine tag searches.

Indeed. So thank you for making this topic! (And in the correct category too :see_no_evil_monkey:)

13

Except T-Code is currently also not optimal, as its very specificly designed towards 1 device. It doesnt realy have a nice way to handle a 2nd linear axis, or multiple vibration axes. The numbering in this standard very quickly becomes odd when we would apply that, and it now being just <A-Z><1-9> (although numbering can go beyond (probably), it doesnt even match script names.

T-Code is a good baseline to consider default support, but a custom axis wont have a fixed code in here. Thats why my preference goes to just using filename. <scriptname>.<code>.funscript

Sure, we can display these as T-Code codes in the heatmap/overview. Thats completely fine. But the filename itself to me sounds more reliable at detecting axis name. A custom axis might not be detected, but if its good naming, it will catch on.

Too long text for tags. For a 6axis script, this already means 5 tags. And optimaly you want to keep this compact. If tags end up like a wall, quickly scanning these wont work when browsing the list.
Optimaly i would have liked it if these somehow get separated from the regular tags, or a diffirent highlight color. As that way, even if there end up being many, this should make them stand out. Maybe in that case the longer names do still work, and with javascript the axis: potion can be removed from its display.

I know CSS to some degree is able to read attributes, and apply a basic ‘text starts with’ check. But i dont know how flexible it is at detecting these axis tags then. But it should be enough to move them around.

So in that case order shouldnt matter much.