I absolutely love Roblox’s Windsock; it was very clear there was a ton of love put into that Widget even though its usage is rarely seen.
I was interested in seeing how it worked - in the past, you would simply just open up the plugin file - but now because of optimizations and in the effort of shorter load times in Studio, those files have been signed and the code pre-compiled into its byte-code.
For the majority of the work I utilized @Maximum_ADHD’s Roblox Client Tracker, they’ve implemented Unluau by atrexus into the pipeline which allows for these byte-code files to be roughly decompiled - and in the case they couldn’t be - just the bytecode instead.
However, after having decompiled the bytecode files myself there was a bug where the Windsock would become distorted randomly. Then @boatbomber shared this GitHub which - in contrast to Maximum_ADHD’s repository - actually had the fully decompiled files.
I compared my decompiled code to that of the newly automated one, and found this single character difference that fixed my problem.
We now have a fully working Windsock:
(Speeds/Directions shown are <1, 1, 0> at 50sps, <0, 1, 1> at 25sps, and <0, -1, 0.5> at 100sps)
The file is below and I hope to see more Windsocks in games everywhere, front-page or not! Windsock.rbxl (57.0 KB)
Note: Barely any of this is commented and it is merely formatted to be readable. I myself don’t have much grasp of what is actually being done so attempting to explain it via comments would be futile; however, I have attempted to appropriately name all the variables to make proper documentation or repurposing easier.
Thank you so much for sending this, in the original bytecode from Max’s GitHub I linked there was a weird 255 value for the Vector3 call which I simply just replaced with 0:
I then looked at the newly decompiled version you just sent and immediately went to see what the value was - and it was not 0 - it was -1!
The only value that needed to be changed to fix the entire behavior was this one value lmfao, I’ll update the post to reflect this now, really appreciate you sending that!
(EDIT: There’s actually some slight behavior issues (new ones) that needs to be adjusted so I’ll be doing more comparisons between mine and the new one and determine what needs to be adjusted before updating)
Hey there, trying to implement this into my game and when I move the windsock from the original location, it completely breaks, any ideas why this is happening?
Facing the same issue and have no idea why it’s happening.
Luckily for me, the game only requires 1 windsock on a static location, so i just based everything on the windsock being at 0, 0, 0
Also resizing it doesn’t seem to work well at all, and my solution was downscaling everything else and making a fork of the camera script to have more support for small players, but this definitely isn’t a proper solution…
@CptMilkk@JohnsonBlu I actually forgot to include the patch that allows for the Windsock to have a different origin other than <0, 0, 0>, I did this for my own game once realizing the Demo file didn’t have this functionality.
I’ve updated the Demo file to include this support, it should automatically handle the “Windsock_Anchor” variable by itself: so it should be plug and play.
@JohnsonBlu As for your sizing issue, I’ve also added a comment to the “RadiusOfStructure” variable that clearly indicates now that if you change the size of the Windsock you must also adjust that variable to match the new radius. As long as you change that variable it should behave properly when resized (from what I’ve tested).
Oh, thank you! I’ve already built a large part of the game based on the player being small, but the game is more of a side project anyway, so it doesn’t really matter!
