This lead me to that assumption.
But in my case, I test all of my scripts before posting, then adjusting for any discrepancy that breaks immersion. I generally pick videos that aren’t just speed so there isn’t overstim.
Although I do prefer resting in lower position to prevent catching a cold, which isn’t accurate, but prevents slippage since I don’t prefer filler.
The part you quoted refers to how regular users won’t modify scripts to fit their own preferences, so roa argues for scripters to provide at least one version that fulfills the listed “requirements”.
Most users will only use the script as is, so scripts should be made to satisfy as many users as possible.
Thanks for the clarification. I make mines for The Handy, which I believe is the most common, since it has a low price point and has great customer service.
Only difference Handy to SSR1 is the max speed possible really script wise.
As Rose wrote I am rooting to compile a one page rulebook or suggestions for the good script. Put a team together open a private server on ES Discord and send them in.
I corrected about a hundred scripts now and there is a pattern. I wanted to change speed only but found those recurring mistakes that will make a script worse. Sometimes just one, sometimes all of them.
Alternative solution: use a script player that allows you to limit its speed. MFP has this feature for individual axises even. If too fast strokes are a problem, this can correct it for you.
Maybe you would, i would probably ask her to go on.
Only after an extended duration, numbness can happen which then does require some slowing down. But after that, i can go full speed again and enjoy it.
Not everyone is the same, and some people can endure insane stroking speeds without problems. Some women squeeze harder than others, some create more lube themselve during the action which can also alter the sensation. Nobody is the same, and making a standard thats ‘too weak’ would only end up negative for those that can handle it.
Also, some people arent sensitive towards overstimming, and regardless of slow or fast action will last for similar times. Sex is more of a mind game than it is about nerves being triggered, as its your mind that creates the pleasure.
There is 1 thing though that could have affected many scripts: Some devices dont have any scaling in them, so a script is always played back based on its full stroke length. If that length causes people to slip out, its a problem, and scripters will compensate here.
This is most likely why some tip oriented action rarely reaches the 100 point, and i do agree that its bad. This is after all something that should be resolved at playback level, and not the script source.
Positional issues are things you cannot fix through the script players, hence its bad when they are made.
The playback program, or physical hardware are the 2 places where limits must be involved. As playing back the script for you is their purpose. These tools can know the limits you want, as you configure that. A script maker cannot do this.
Its for the same reason why you dont downscale all videos to 1080p, for the sake of hardware suport, because some people cant watch 4k.
Sure, you can provide an alternative source like most content delivery systems do, or just play it back at 4k, while the pc/hardware scales it down again. But note, those systems only provide the downscaled version because of financial reasons: bandwidth costs money.
Idealy they wouldnt have to bother with this and always send the 4k, but due to physics they cant realy do this without costs. This is why a bluray disk doesnt contain a 1080p source in it. If it looks like it has one, its usualy because the 4k was encoded in a way that does allow downscaling natively from the same source.
And this is exactly what games also do. Graphic settings are usualy just a simple ‘increase limit x to y’. And everyone by default has the highest quality available. You just downscale in the game. Sure, level of detail objects are often made since even on the highest end hardware, you are going to run into limitations too quickly without it, but the settings just say at which range they get applied.
And any speed arguiment is therefor technicaly just invalid, speed is a playback limit. There are plenty of women that can stroke faster, harder and at longer distances than a handy. The only reason for limits is because the hardware has such limit, or because clipping causes strange behaviour. But that nearly always means that the tool is not limiting things properly.
You can optimize for certain devices, but again, this comes at a loss of quality on devices that can exceed that target device. Therefor, usualy when you are going to target towards a device because of significant limitation, should you still provide the unlimited source.
Making the handy the default is a horrible idea, it might be popular now, it might still be in 5y. But maybe they also made new revisions that are significantly faster and even safer. If you then targeted the older device, your script is now forever outdated.
On last poll we got 66% handy and 22% multi-axis OSRs (and 9% SSR1s)
It is the most common, but SSR1 now costs around the same
And we are going to get Handy v2 this year I think
So I think the tide is slowly changing from Handys to more modern devices
Handy has action frequirency cap of around 20-30Hz. SSR1 doesn’t care even if you have 200.
That’s in part why OSRs can vibrate much better
Just make a public topic like this one and collect quotes in OP
Of I can do it later this year
The OG funscript where there was “range” parameter because devices couldn’t reach 0/100 so it was it 5-95 are a good example of this
IMAO:
While i think its good if the video allows it, there are clear cases where this just doesnt work. If a women does rotational stimulation, there is no way for a linear stroker to mimic that. Script wise you therefor do compensate in order to mimic the sensation.
The problem is that you cant realy predict the next generation. Now its tilt/roll/twist that are common for an OSR. But what if multi-linear strokers instead become the default? Multi axis current suffers from needing a fixing mounting point for proper playback, which can definitely be a limitation that never makes it the standard. Linear strokers are more versatile here.
Scripting for linear without looking at multi axis is backward compatible, you can turn axisses off on a multi axis device, so it still functions as the scripter made it. The other way doesnt work as that will leave important motion out of the script.
This is again making wrong assumptions. As where is the vibrator placed in the first place? Buttplugs, cockring, internal sleeve, balls and een your nipples can all be places that could be stimulated. And if we target immersion, the location matters a lot.
While a standard would be nice here, we cant realy use vib1, vib2, vib3, etc as naming, since its still too vague. Atm its down to the scripter to state what each vib targets.
1 advantage of normal vib scripts is that they are technicaly capable for estim as well. intensity is intensity for both. However, you cant change the ‘sound’ of the estim channel though. But thats ompletely lacking in funscripts anyway (and why bother when mp3 does the job).
It just shows how much people can adjust their setup. Standardizing this wont work. At best you could name a script something like script.buttplug.funscript or script.cockring.funscript. That would at least be fine to have a consistent naming acros many scripters,
Users can convert the naming to their devices.
This starts to get to machine learning levels of compensating. Would be nice, and could potentialy be quick. But again, devices will have limitations. And if someone doesnt have a multi axis device, they cannot script for it anyway. If you make a script, make it as you want, let AI figure out what the real intention was when converting it.
Its much more complex as a formula to properly compensate, either use a complete formula intead of just a multiplier, or let machine learning generate something that works instead.
Videos should, not scripts. Chapters are video metadata. And if a chapter cannot be split as video, then the script also shouldnt. It makes no sense to start a chapter in the middle of action after all.
Penis tip barely enough in to not slip out is 100. Its the absolute limit you can safely handle in a script. If you want your dick further in, reduce the range at playback. If you want it to actualy go out, increase the range at playback.
Penis tip in depends on the dick of the person so is not a reliable measure point, 80 is a general decent average though (assuming 14cm with 3cm tip - note a slight margin remaining for the 100pos)
Motion goes tip to base. Making a midpoint as standard is bad. Its at best a decent reference point when scripting.
Misspelt, bottom of the penis head (~2cm from the tip).
Well, yes, but all we have is a script so if there are chapters they should be copied to script metadata. Potato potato (same shit).
I mean more in the sense “each V is a pair of [intensity, frequency]” so it maps well to linear, so L0 scripts don’t have
I think as always I’ve overcomplicated a “obvious” thing because it’s not simple
Exactly, the whole tip is scripted 100. Rim visible give it a 100 not 80. I think this gets derailed a bit by hardware and back to the future stuff. Even player software compensation for bad scripting is not the topic and often not possible as the whole script is altered not just the too fast areas. Software doesnt know if the upper or lower points should be moved. it may even slow down both sides. I have to manually decide when speed editing scripts if I want to move upper or lower points. Choosing the wrong ones will make the script worse or really bad. BJ HJ is mostly lower points limited and other action the top ones.
The problems mentioned above are solvable by simple basic scripting rules that I suggest being used. Also extremes should be customized by editing the script or by using modifiers in the player, not getting a script to normal/usable by most.
Found some chinese study @ https://tau.amegroups.org/article/view/4591/html,
Seems that 0.75 baseline for the baseline may be more correct
I saw scripts that had actions and rawActions. Having action.raw or (another supplementary multi-axis) that shows unscaled position (which it then scaled to action.pos by the scripter himself) may be useful.
Also let me show the most scripty script I’ve seen
and invite @dimnogro into discussion
3.4 / 12.9 = 0.263
on that part math says .74 even. However, i do prefer a slight tip margin in scripts that avoids slipping out. And i think on that 0.5cm margin is generaly better. Anything less is likely to push you out.
Which then means 2.9 / 12.4 = 0.234, or a position of .77
This was from an old OFS version as far as i remember. Newer versions dont use this anymore.
Yet it would potentialy be nice if scripts do enable compensations for certain devices within them. Being json the file format is flexible enough to store such data. The problem here is just having a standard, and that basicly comes down to OFS supporting it. And it not being maintained makes this highly unlikely to ever happen.
Then you havent seen codeScripter’s scripts. Just an example:
https://discuss.eroscripts.com/t/cs-free-0106-toone-aerith-satisfy-me-my-dear-half/252475
Thats 10 scripts for 1 video, using almost every feature the SR6 can handle. And most of his scripted videos have that many scripts with it.
And that doesnt even contain vibrator scripts, which if we only consider using the edge 2 already means +2 scripts potentialy per video.
Its nice to find those sort of scripts though, scripts for uncommon setups can be very interesting scripts. But it just proves how hard it is to get a standard that is easy for people to follow.
Also, if we want more metadata in funscripts, why not also include reference points in the scripts itself? If someone uses a gland bottom of 75, or 80, that can just be meta data in the script. And at playback in portions near the gland, the player could compensate towards the setup.
If someone configured a 16cm cock with 3cm gland, it can easily calculate adjustments regardless of what the scripter used. For full strokes it can still perform smooth strokes, while gland action could be scaled up/down.
I’m pretty sure rawActions are from JoyFunScripter when you record live with a controller/mouse. They could have been sampled at 333hz. They were supported in MFP for a while.
So to put this derailed train back on track some rules of thumb:
more to come…
A few posts ago it was still about things like optimal positions for certain reference points, script variants that can have conflicting names, methods to store metadata to allow far better representation of scripts. And you call this derailed from talking about standards?
And this shows you dont understand how to make a proper standard. Ignoring a few extremely important devices that are highly popular: OSR2, SR6. These are the devices that define standards, these are the ones that try to go for the limit.
400 is not even remotely fast enough to represent some actions in videos. There are enough devices that can go well beyond 400, and there are sleeves that can reduce sensation (smooth/smaller/less tight sleeve).
4 full strokes per second are well doable humanly, yet requires 800 speed.
Note that there are already sex toys that can do 12 full 5cm strokes each second. Yes, 120cm of movement per second. And they dont hurt! Both for dildos on women, or men with a fleshlight. Sure, these currently cannot sync with video. But technology can go very fast.
And as long as its humanly doable, it should be scripted as that. Capping/limiting afterward is then fine to make a handy optimized script.
So why you are stating 400 as standard/guideline i dont know. It makes no sense to go for such outdated slow value. Making it the default is only motivation for toy makers to not improve anything. Because why would they if nothing supports it?
At best a script optimization for certain devices next to the standard unlimited script should be the guideline. But making the handy default means you are automaticly excluding the OSR2/SR6, which are both significantly better.
And not to forget, if they decide to make a handy v2 that can handle 600, you now caused many scripts to be of lower quality.
If you cannot handle more than 400, then limit this on the playback tool. Dont force script makers to take this stupid standard if its not needed.
The handy can playback a speed of 1000 for a second without errors, it surely will cap it (for which sometimes an optimized script is needed), but it wont halt. As long as the script behaves as expected, then that is a fine speed to use.
If toy makers decide to change their firmware, its their own problem if it breaks scripts and causes bad reviews. Who knows they make firmware that after 2 years brings back the limit to 350? Do not rely on their software!
Rely on accurate scripts and a parsing step from the player to handle this. As that is far more reliable at keeping things working properly.
I did seen him, I was talking on multi-device not multi-axis
If you use sines rather then zigzag your top speed will be twice the average speed - so for smooth 400 you need speed of 800
That’s part of why I have different algos for heatmap and heatgraph - 400-speed sines will look like 400 on map but 600 on graph
When I use motion tracking I use 3-4 lines per motion. Endpoinds yep.
We should wait for TwoHandy to set the baseline limits for the next three years I suppose
Yes, I felt you derailed the thread as setting the player to prevent overstim at speeds over 400 was not the topic. The thread was not about compensating bad scripting by software settings.
A sensation reducing sleeve will understim at normal speeds that is not a solution in my opinion.
A thought why the script should run even tip rim involved at 100%: Not scripting to 100% but 80 or 90 is dangerous as users will set L0 to - just doesnt slip out - as you mentioned for good sensation and if the script then goes to 100% they will slip out. So you are forced to lower L0 setting which is understim. So if I open a BJ script and it runs at 90% mostly I can see its badly scripted just looking at the script line. At least this should make it into standard.
Max speed, OK I will hop your train as I am interested if it is possible to have a script be limited by software without changing the script. I understand scripting as seen would be nice so the script does not have to be changed ever again for future devices that can change pressure for example and reduce pressure at higher speeds.
So setting in MFP this will be same as if I manually edit the script to max 400?
If yes then I agree to not speed limit scripts at all when scripting and really script what is seen. So if you script a MagicMuffin highspeed script those 900U/sec and ask the user to limit between 400 and 600 as he likes but make clear that the script is not intended to be used unlimited.
My problem about software limiting is that editing scripts manually and talking to @quickfix about his limiting macros that did not work out from the start I still have to decide which points to move. I fear that MFP will move both points of a fast line to limit speed which is bad. MFP does not know what happens on the screen. If it does not move the right side it damages script playback a lot.
Assuming MFP does not limit speed as it should I put out a feature request to @Yoooi for an option in the speed limiter to always limit the points that are more far away from 0% and 100%. This means not to touch the bottom and top points. This will cover 90% realistically. But it can damage the script play. Lets say we have a 0-100% too fast area. Which side should MFP limit? Both? Nah thats wrong for both HJ and that full stroke tip visible regular action. For HJ the 0% side has to be limited and for regular action the 100% side.
I would propose to script to a unsuceptible 99% and 01% to make it clear to MFP which side to limit. Full HJ script 100-01%, full regular action script 99%-0. This way MFP knows what side to limit.
So yeah a well working MFP speed limit would be far superior to manually editing a script to a fixed limit. Thanks for pointing me there. But it would be only far superior if the right side is limited!
So what would that MFP feature request look like?
I would say a slider indicating balance.
Most of the time when scripts get slowed down, endpoints arent reached. And people can differ a lot on which method they prefer, as this depends on the most sensitive locations.
So lets say we balance it to 100 (tip), then all the tip strokes will try to get reached, yet the bottom ones dont get close.
50 means it will keep the center of the stroke in place, reducing both ends.
0 means it then focusses on the bottom.
0 and 100 being very aggressive here might be suboptimal, but as i suggest a slider, you can finetune this.
It surely will miss a few strokes, but this is nearly unavoidable. Maybe with some algorithm it could adjust the surrounding strokes with it, but this can get complex quickly as time adjustments are also an option here.
Which then makes it even more aggressive. If you set it to bottom, and the normal strokes were like 50 at 0s, 100 at 0.1s, and 0 at 0.2s, it can just freely move the 0.1 node so it ends up at 0.66 (making both strokes equal speed).
Idealy machine learning tricks would be nice here, but thats just going to add too much complexity, while i dont think it will do any good to the script if its not aware of video context (where 0.8s might have been the realistic timing limit.
I think just setting a focus point is going to be enough, it can focus on bottom, tip, or any point in between and tries to balance towards that as much as possible.
Capped speeds never will be realistic, but at least we can still focus on giving the people the most optimal experience, which since everyone is different means there is no real standard that can be used. Some are tip sensitive, some bottom, and whichever it is, they most likely will put the setting closer to that, as they will feel that better.
Your ‘far-away’ method is an interesting one though, since it will amplify outliers, which especialy in clipped content could be the thing that brings most immersion.
“would propose to script to a unsuceptible 99% and 01% to make it clear to MFP which side to limit. Full HJ script 100-01%, full regular action script 99%-0. This way MFP knows what side to limit.”
This makes a lot of sense for automatic speed limiting, so the scripter can force the limiting behaviour.
oh, I see now, every script I have made was based on my instinct to be honest, I would love to be as good as some of the scripters here, but theres not much information, its difficult to imagine a way to script a fast movement from the tip to the base when the speed exceeds the 400 limit, so what I do is set the limit at 500, and it helps a lot, because sometimes the movements are too fast that if you set a lower speed it will feel like vibrations instead of strokes. Is there any advice for situations like that?
We have to keep it as simple as possible and the result has to be as close as possible to the original script. If you limit the wrong points you fubar the script. If you reduce top points in a HJ in a Magicmuffin speedchallenge to limit the speed the script is tuined. Same in a cowgilr where you make her float but in the video she fully sits.
I talked to @Yoooi on discord and asked him if MFP already does the speed limiting correctly.
Example 1: HJ/BJ tip points have to stay low points have to be adjusted
Example 2: regular action top points need to be limited low points have to stay
to
Yoooi said example 1 is happening and 2 is not meaning all regular action the limiting goes sideways. Script is altered. Yoooi wants to change this when he rewrites part of MFP so no ETA.
Why I agree with @quickfix. After realizing with @randomus in the last event that there is overstim I asked quickfix for macros to be able to quickly reduce speed in scripts. The macros needed rules and so will scripting need those. I changed about a hundred scripts to a max of 400U/sec with the macros. I saw a pattern that almost did not make me to look at the video. I could tell which side is to be reduced. I just had to look because of bad scripting. If someone scripted a HJ like in the second image of example two it looks like regular action. This one
I can not see this one as a HJ/BJ and so MFP wont. It will limit the top points to reduce speed. If its HJ the script gets unusable.
So how would you need to script to make it clear to MFP which points to move upper or lower?
@quickfix What I see in OFS, we can not set multiple points to a value after marking them with SelectPeaks. We will also need a Macro for 99 and 01 quickfix. Best would be a MOVE macro that sets any point 10 20 30 etc to 11 21 31. Maybe highlight those nasty same distance 0 and 100 areas so we can just shift-arrow them up or down to indicate which side to move as one point gets closer to 0 or 100 and wins being fixed?
I think this would be an overall very clear and easy way to script full speed as seen and reduce by the player. Good for all devices, sleeve types, future devices and preference.
So what will happen if you set MFP to this:
