Windower V4 - Dev Tracker |
||
|
Windower v4 - Dev Tracker
You should come to our discord for further help
![]() Hello everyone,
another substantial update to Windower was pushed to live this morning. We have had reports of people being unable to launch FFXI as a result. Here is the nuclear solution for it: - go into the Windower folder - delete windower.exe, hook.dll and the updates folder - download windower.exe again from https://www.windower.net/ - put it in place of the old one - log out of all characters, close down FFXI entirely - relaunch windower This should solve your issues. Later today or tomorrow I'll publish a new post with the list of windower updates added to this release. As usual, this thread is not for discussion or support. Open a separate thread, use one of the other specific threads, or come to windower discord for support. Thank you and have a nice day! EDIT: on some systems, it's also possibly needed to update .NET to 4.8. This also applies to Linux/Steamdeck installs. Windower 4.6 UpdateAnother Temporary Post Known issues:
Resolved issues:
Thanks for continuing to maintain it after all these years!
Heads up to anyone still using windows 7, windower is going to stop working on your computer soon. They were going to push an update that stopped it working yesterday, but it was delayed
It's coming soon though, need to find a way to block updates so you're allowed to still use your pc I guess. RadialArcana said: » Heads up to anyone still using windows 7, windower is going to stop working on your computer soon. They were going to push an update that stopped it working yesterday, but it was delayed It's coming soon though, need to find a way to block updates so you're allowed to still use your pc I guess. To de-escalate this a bit, there is no such update planned. We have no plans to break Win 7 support. We will, however, keep developing Windower, and if it turns out that a new feature does not work anymore because Win 7 is no longer being developed, then that will be it. It's the same thing that happened to Win XP, Windower no longer ran on XP after a while, without us even changing anything, simply because the server that hosts all our addons required a newer TLS version which was never implemented on Windows XP. This can happen on Win 7 at any time. This is not Windower specific, but could absolutely happen with Windower as well. *Everything* on Windows 7 can break at any moment, it's really just a matter of time. As for Windower, again, we have no plans to break Win 7. If we ever do implement something that breaks Windows 7 compatibility, we will definitely inform people. Appreciate that, however when I originally asked you gave a reply that was a little more abrupt. I made these posts shortly after.
Quote: RadialArcana — Today at 1:05 AM Will windower always be compatible with Windows 7? with the update today, it made me wonder if there will come a time when it wont. Quote: Arcon — Today at 1:06 AM Almost certainly not, in fact for this very update I pondered if I should switch to .NET 9 for the launcher, which would have broken Win 7 compatibility [1:07 AM] Decided against it, because there was already enough scheduled to update, and I'm definitely not regretting it after this rollout lol Quote: RadialArcana — Today at 8:38 AM Will there be a version of windower available with no forced updates for win7 players? So they can keep using it as is? Quote: Arcon — Today at 8:40 AM Nope, though there are ways around it, like firewalling Windower, or blacklisting the URL, etc. I cannot morally condone using Win 7, so I definitely don't feel like making this easier on people lol ![]() To be fair it was early in the morning after you put a lot of work in on updates, and you clarified after and in the post above after that you would notify and would try to avoid it if possible. So not taking it too much to heart but the first response wasn't too cool imo. Nothing he has said is actually inconsistent. Let alone windows 7, Microsoft makes 10 EOL this fall iirc. I've switched to Ubuntu as a result and honestly regret not doing it sooner.
The team is too small to support all the things that go wrong in EOL versions of windows. A more appropriate response would be to START using the dev build of windower, everything goes to the dev build before it goes live.
if something breaks on dev you can switch to live while it is getting fixed, and as an added bonus we actually know that it broke if more people use it before pushing to live. And in your case specifically radial, you would see it break on win 7 and then know it is time to wall off your live build. Blocking updates with a firewall is an option, but we have said multiple times doing so is not supported. Ok, here's some actual release notes:
Windower 4.6: Apocalyptic Panic EditionIt was an interesting 36 hours. Addon changes:
Plugin changes:
New Addons
Core changes:
WINDOWER: THE UNBOUNDENING...what happened was that a really sneaky sneaky bug snuck its way into the newly written command parser. The gist of the issue was that the "down" key event was registering as the "up" key event. So the game would perform its native function on key press ("down" event), then perform the windower keybind when releasing the button ("up" event). This also completely destroyed the functionality for those people who were actively using the keyup event. The issue has now been resolved (together with a few others, like case-sensitivity), but please let us know if any breakage still occurs. A word on automatic updates and the blocking thereof: Please note that firewalling windower to block updates will mean that the next patch (as I'm writing this, 12th Feb 2025) will break your windower and you'll have to update manually: Gearswap, porterpacker, itemizer, organizer, etc, will all break with the addition of new items, and you won't receive the update, and you will have to update manually. Any client change, you'll have to update manually. Any bug, you'll have to update manually. And updating manually is a pain in the *** for multiple reasons. Unless you know for a fact that your client will never change (which is possible if you're playing on a private server with version locked client, for example), blocking windower from updating is a horrible idea, and certainly not a good way to deal with issues such as what happened yesterday. The best way would be for some of you to start using, here and there, windower dev version, to check if your setup works properly on it, and report any issue. The keybind bug was noticed since late November, but it seemed like a really minor issue because none of us in the development team has setups as complicated and involved as some of you, who were affected the most by the bug, do. Hence why we deemed the update "stable enough". This does not mean switching to windower dev permanently (which we do not recommend), just to keep it in another folder and tweak with it once in a while. This is obviously not obligatory, but until we become billionaires and can afford to hire a QA and Stress Test teams, it's the closest thing to a preventive solution. To close this already long post, thanks to all the people who helped us debug and locate the various issues. As for the doomsayers, the Apocalypse Patrol, and the PAICTYA (Passive Aggressive I-Can't-Trust-You Association), please remember that we do this out of passion and in our free time. This is not the cop-out answer that you think it is, it's the actual reality of windower. If you don't like it, there are alternatives, and if those alternatives make you happier, please use those. If windower makes you happier than those alternatives, please keep it in mind before coming to attack the very same people who keep it alive. Thank you all, and have a nice day. (as usual, this thread is not for support or discussion, so I will prune some of the previous posts and do some thread cleaning for the rest of the day.) Thank you and all the people working on it for the labor of love that is Windower!
Not sure how I would function in the game without it. Thank you all as well for addressing the bug and writing this up for transparency. It is greatly appreciated by the vast majority of the community! Lili said: » A weird post-waypoint stutter was also linked to this and was resolved. Valefor.Philemon said: » Oh my word is this why I've been doing a weird time freeze after warping in Sortie? Can't say for sure, but it's very likely. Basically what happens here is that if you use a same-zone warp, then gain or lose a buff, the server sends your client a packet with *all* your buff expiration timestamps - a sort of "ok let's make sure we're synced" mechanism. This packet triggers the buff_refresh() event within gearswap, once per buff refreshed. The problem was, previously gearswap would refresh its internal variables (stuff like player.mp, player.buffactive, etc etc) every time the buff_refresh() event fired, and for no reason since all those refreshes were triggered by a single packet and thus player status could not have changed between each event. Refreshing globals is a very, very expensive operation in terms of processing power, and triggering it multiple times in a row causes stutter. This is particularly problematic in Sortie and Ody where you easily have 20-30 buffs active at a given time, so warp -> receive Invisible -> refresh globals times twenty in a single packet -> ST-T-T-T-T-TUTTER. Gearswap now properly refreshes global variables only once, when appropriate, thus the megastutter is avoided. This doesn't prevent the various gearswap suites around from being silly on their own, but reduces the issue significantly in general. Pretty sure that stutter is gone, thank you very much.
![]() Short story long.
So for the longest time, I just couldn’t figure out why during sortie, specifically F-H the movement speed wasn’t consistent. F was 92-98, and H 54-66 in any increments of 2%. But then I read somewhere here, maybe not this thread but from Lili, that gearswap has an inner max gears swap (32?!?) per packets (so every .4 seconds). Hmmm interesting, RDM has a lot of gear swapping, extreme fast cast, and maybe not every gear makes it at the end of the packets, explaining my discrepancy and not the GEO. I posted on their discord, but the suggestion to run the debug to show every gear in chat, when I have to gravity/dia and kill the thing while running 9/9 just ain’t happening. Tried to gather the data but no… it’s too fast in a run to hold, look for the data many pages up, if it’s even there by the end of it. So there’s that. Talk to a friend that understands extremely well the mapping, and he agree I should be able to just precast the midcast spell to reduce the data. The fact that’s in sortie, the inner lag, when the mob finally wakes up isn’t helping, it might work in Qufim consistently but not there. So, for a week, I just scrap the precast (FC) set and ran straight to the midcast (full enfeebled) and zero issues. So Lili is right, but it’s just not necessarily only for SIRD, the inability to send every gear in the package might be situational, specially in laggy environments like sortie/odyssey. So something to keep in mind, people might want to “clean up” their precast (FC) set, specifically those extremely fast casting spell. Maybe all those spells. So why am i posting it here, well some people might find that very interesting. I think most people just like to believe all their gear is swapping to justify continuing to play cus, well, I totally need that piece for my precast for this spell!
|
|
All FFXI content and images © 2002-2025 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.
|